退場規則と早期解雇

Exit Rules in Case for terminating stages early when conditions change, including differences from Complete Rules and downstream routing effects.

対象者: 中級者 — 自動化開発者、ビジネス アーキテクト、ソリューション アーキテクト

概要

In Case, every stage can end in one of two ways: it finishes its work normally through a Complete Rule, or it terminates early through an Exit Rule. Exit Rules act as circuit breakers — they cut a stage short the moment conditions change in a way that makes continued processing pointless or incorrect. Understanding the difference between these two mechanisms is essential for designing case plans that handle both happy paths and exception paths cleanly.

ステージのライフサイクルの概要

ステージがどのように終了するかを調べる前に、ステージがどのように始まり、進行するかを理解するのに役立ちます。ケースプランの各ステージは、そのライフサイクルを制御する一連のルールタイプによって管理されます。

ルールの種類	質問への回答
エントリールール	このステージはいつアクティブにする必要がありますか?
ルールの完了	この段階はいつ終わりますか?
Exit Rule	この段階はいつ早期に救済されるべきですか?
Re-entry Rule	ケースはいつ再作業のためにここに戻すべきですか?

ステージは、エントリルールがtrueと評価されると、 使用可能 から アクティブ に移行します。アクティブになると、ステージのタスクは、独自のエントリルール(イベント駆動型タスクの場合)またはシーケンス内の位置に従って実行を開始します。このステージは、完了ルールまたは終了ルールのいずれかが起動するまで、アクティブのままです。どちらの結果も、ケースマネージャーは、ルールのアクションに基づいて、次にどのステージに入るかを評価します。

完全なルールとは何ですか?

「完全規則」は、ステージの通常の終了条件を定義します。ステージが設計されたことを達成したときに発火します。ほとんどの場合、完全ルールは、必要なすべてのタスクが完了し、有効な出力を生成したかどうかを評価します。

完全なルールは、「この段階は役目を終えたのか」という問いに対する答えだと考えてください。

一般的な完全ルールは次のようになります。

WHEN event("AllRequiredTasksDone")

または、特定のデータの結果が重要なステージの場合:

WHEN event("AdjusterDecisionMade")
  IF adjusterDecision != null

完全ルールが適用されると、以下の処理が行われます。

• ステージは 完了 状態に移行します。
• タスクのすべての出力は、ケース エンティティ [近日公開] に保存されます。
• ケースマネージャは、ルールの アクション (次のステージのエントリルールに従って進める、手動選択を待機する、原点に戻る、またはケースを完了する)を適用し、後続のステージのエントリルールを評価します。

完全なルールは 、設計した期待される結果を表します。ステージが進み、作業が行われ、その結果は次に来るものの準備ができています。

出口ルール、つまり「サーキットブレーカー」とは何ですか?

終了 ルール は、 早期終了条件を定義します。ステージの途中で何かが変更され、処理の継続が不要になったり、無効になったり、逆効果になったりした場合に起動します。[終了ルール] がトリガーされると、ステージは 直ちに 終了し、[完了ルール] を満たさずに終了します。すでに実行中のタスクは、ステージ出口によって停止されません ( 実行中のタスクはステージ出口によって停止されません)。

エグジットルールは、「この段階を今すぐ停止する必要があることを意味する何かが変わったか」に対する答えと考えてください。

「サーキットブレーカー」という用語は、この動作を正確に捉えています。電気工学では、回路ブレーカーは危険な状態を検出した瞬間に電力を遮断します—回路が意図した作業を完了するのを待たずに。終了ルールは同じように機能します:条件がさらなる処理を間違えたり無駄にしたりした瞬間にステージを中断します。

典型的な終了規則は次のようになります。

WHEN PolicyCheckCompleted event arrives
  IF policyValid == false

WHEN 句では、ケースのライフサイクルによって出力される内部イベント (タスクの完了、ステージの開始または終了、エンティティフィールドの変更、SLA のat-riskまたはbreached) またはケースの外部から到着する外部イベント (コネクタ Webhook、タイマーの起動、子ケースの完了、 直接 API 呼び出し)。終了ルールは、ほとんどの場合、内部タスク完了イベントをリッスンし、それらのタスクが生成するケースエンティティフィールドを更新します。

終了ルールが起動した場合:

• タスクの進行状況に関係なく、ステージは直ちに終了します。ステージでは新しいタスクは開始されません。
• すでに実行中のタスクは引き続き実行されます。すでに書き込まれたタスクの出力は保持されます。実行中のタスクも停止するには、引き継ぐステージのエントリー・ルールで 「アクティブな作業の中断 」がオンになっている必要があります (以下を参照)。
• ケースマネージャーは、ルールの アクション (完了と同じセット:ケースを完了または終了し、手動選択を待機し、原点に戻る)を適用し、通常の完了後と同様に、次に何をすべきかを評価します。
• ケースは必ずしも終了するわけではなく、別のステージ、セカンダリ (例外) パスにルーティングされるか、決定論的なルールが状況をカバーしない場合に Case Manager エージェントが 次のアクションを決定する場合があります。
• 早期終了は、ケースの 監査証跡に記録されます。つまり、実行ルール、それをトリガーした WHEN イベント、IF 句を満たしたケース エンティティの値、および実行されたアクションです。このエントリは、ケース アプリのタイムラインとケース インスタンスの管理に表示されます。

実行中のタスクは、ステージ終了によって停止されません

ステージの出口はステージを終了するものであり、すでに進行中の作品ではありません。ステージが終了したときに実行中だったタスク (タイマー タスクや長期実行エージェントなど) は、元のスケジュールで自動的に完了するまで続行されます。

実行中の作業を取り消すには、引き継ぐステージのエントリ ルールの [ アクティブな作業を中断 ] トグルを使用します。このトグルがオンになっているエントリ ルールが true と評価されると、ケースは他のすべてのアクティブなステージを終了し、新しいステージに入る前にケースで実行中のすべてのタスクをキャンセルします。二次段階は常にアクティブな作業を中断します。このトグルをオフにすることはできません。プライマリ ステージでは、既定でこのトグルはオフになっています。

注:

ステージをループして戻すと (終了してから同じステージに再入ります)、前回の活動化からまだ実行中のタスクは、出口によって停止されず、元のスケジュールが維持されます。各アクティベーションを新規に実行する必要がある場合は、[ アクティブな作業を中断 ] をオンにしてエントリ ルールを使用してステージに入ります。これにより、ケース内で実行中のすべてのタスクがキャンセルされ、前回のアクティブ化から残ったタスクだけでなく、他のすべてのアクティブなステージが終了するため、ケース内の他の場所で実行されている並列作業も停止することに注意してください。

どう違うか

次の比較は、完全ルールと終了ルールの基本的な違いをまとめたものです。

Dimension	ルールの完了	Exit Rule
目的	作業が完了すると、ステージが完了としてマークされます	条件が変わるとステージを早期に終了します
発射時	必要なタスクが完了し、有効な出力が生成されたら	タスクの進行状況に関係なく、監視対象の条件が true になるとすぐに
タスクとの関係	タスクが完了するまで待機します	タスクが完了するまで待機しません。次のステージのエントリ ルールによってアクティブな作業が中断されない限り、実行中のタスクは続行されます
表す	正常な、期待される結果	異常、条件付き、またはショートカットのシナリオ
次のステージの状態	完了	終了 (早期終了)
次に起こること	Case Manager は、ケースデータに基づいて次のステージを評価します	Case Manager は、ケースデータに基づいて次のステージを評価します

通常の完了と早期終了の両方のパスは、同じダウンストリーム動作につながります:ケースマネージャーは現在のケースエンティティの状態を読み取り、次にアクティブ化するステージを決定します。違いは、ステージが終わった 理由 と 時期 にあり、その後に何が起こるかではありません。

注:

1 つのステージで、完了ルールと終了ルールの両方を定義できます。実行時に、最初に true になった条件によってステージの終了方法が決まります。これらは構成において相互に排他的ではなく、実行において相互に排他的です。

出口規則が重要な理由

終了ルールがなければ、ケースプランは、ステージがすべての作業を終了し た後 、すべての例外を処理する必要があります。これにより、いくつかの問題が発生します。

• 無駄な労力。ステージは開始を続け、結果が関係のないタスクを待機します。たとえば、調査段階では、フィールド検査官を派遣し、保険契約がすでに無効であることが判明した請求の写真を分析するのに何時間も費やす場合があります。[終了ルール] はステージを停止します。次のステージで中断入力ルールと組み合わせると、すでに実行中の作業もキャンセルされます。
• 遅延ルーティング。現在のステージが完全に完了するまで、ケースは正しい例外パスに移動できず、ケースの全体的な解決に不要な待機時間が追加されます。
• 複雑で完全なルール。個別の終了メカニズムがない場合、完全なルールは通常の終了と異常な終了の両方を考慮する必要があり、読み取り、保守、およびデバッグが困難になります。

終了規則は、「完了」信号を「停止」信号から分離することにより、これらの問題を解決します。完全なルールは、成功を説明するシンプルなままです。エグジットルールは、成功がもはや不可能または関連性がなくなる条件を記述します。

必要な段階と早期退出

必須とマークされたステージが、ケースが通常のケース完了ルールを満たすには、完了ステートで終了する必要があります。必要なステージで終了ルールが発生した場合、そのステージは完了ではなく終了ステートで終了するため、「必要なすべてのステージが完了しました」のチェックには寄与しません。

つまり、必要なステージの終了ルールは常に次のいずれかとペアになる必要があり、そうしないと、ケースがスタックします (必要なステージが完了しず、それを拾うように構成されたダウンストリーム ステージはありません)。

ペアリング	動作のしくみ	使用すべきタイミング
下流のステージが引き継ぐ	別のステージのエントリー・ルールは、同じイベント (多くの場合、セカンダリ・ステージで、そのエントリー・ルールは常に Interrupt active work on) で起動され、ケースをクローズに導きます。終了ルールはステージを終了します。[中断エントリ] ルールは、実行中の作業をキャンセルします。	ほとんどの例外パス — 拒否、 不正ホールド、 取り下げなど。事件は続き、どこか別の場所で続くだけです。
終了ルールアクション = ケースの終了	終了規則のアクションは、ケースを直接終了します。下流工程は必要ありません。	早期終了とは、訴訟に意味のある継続がないことを意味します(たとえば、保険契約が無効である、請求者が取り下げた、詐欺が確認されたなど)。

オプションの段階では、早期退出はそれ自体で問題ありません - ケースはそれなしでも完了することができます。

一般的な出口ルールのパターン

ナレッジベースとL300コース教材には、退学規則が重要な価値を提供するいくつかの繰り返しパターンが説明されています。

パターン 1: 無効な前提条件

ステージの早い段階で、タスクは基本的な前提条件が偽であることを発見します。残りのタスクを実行する理由がない。

例—FNOLインテークステージ:

WHEN PolicyCheckCompleted event arrives
  IF policyValid == false
  ACTION Exit the case

請求者のポリシーが無効である場合、請求の詳細を抽出したり、請求番号を作成したりしても意味がありません。終了ルールは、インテークステージを直ちに終了します。ポリシーが無効であるため、ケースには意味のある継続がないため、アクションは ケースの終了 — ケースが終了し、ダウンストリームの終了フックが拒否通知を送信できます。

パターン2:中期拒絶反応

ステージ内の意思決定タスクは、ステージの目的を無効にする否定的な結果を生み出します。

例 — 評価ステージ:

WHEN AdjusterDecisionMade event arrives
  IF adjusterDecision == "deny"
  ACTION advance

査定段階で損害鑑定人が請求を却下した場合、支払い段階は有効になりません。[終了ルール] は、評価を早期に終了します。アクションは 前進 です。同じイベントが [拒否] セカンダリ ステージのエントリ ルール ( adjusterDecision == "deny"で起動) に到達します。[拒否] はセカンダリ ステージであるため、そのエントリ ルールはアクティブな作業を中断するため、まだ実行中の評価タスクはすべてキャンセルされ、[拒否] が通知を送信してケースをクローズします。

パターン 3: 不正またはリスクの検出

自動チェックでは、通常のステージの完了を迂回して、即時のエスカレーションを要求する重大度の高いリスクシグナルが検出されます。

例 — 調査段階:

WHEN FraudCheckCompleted event arrives
  IF fraudScore > 0.9
  ACTION advance

不正スコアがしきい値を超える場合、ケースは直ちに調査段階を終了する必要があることを意味します。アクションは 事前 です。 不正ホールド のセカンダリ ステージが同じイベントでアクティブ化され、アクティブな作業を中断して、ケースを引き継ぎます。フィールド検査または警察のレポートの取得が完了するのを待つと、時間とリソースが無駄になり、エントリ ルールによってアクティブな作業が中断されるため、実行中のタスクはキャンセルされます。

パターン4:ファストトラックのショートカット

すべての早期退場がネガティブなわけではありません。終了ルールは、残りのタスクが不要であることがデータで示されている場合に、処理を高速化することもできます。

例 — レビューステージ:

WHEN ValidationComplete event arrives
  IF totalAmount < 500 AND validationResult.status == "pass"
  ACTION advance

価値の低いクリーンな提出物には、完全なレビュー段階は必要ありません。エグジットルールはステージを短絡させます。アクションは advance であるため、ケースはプライマリ フローの次のフェーズに直接進みます。このパターンでは、レビュー ステージが必要なケースのプランから削除されることなく、単純なケースのサイクル時間が短縮されます。

パターン 5: 外部システムの障害

統合タスクは、ステージが意味のある結果を生成できないことを意味する方法で失敗します。

例 — 決済ステージ:

WHEN PaymentProcessed event arrives
  IF paymentFailed == true
  ACTION Wait for manual selection

支払いシステムがトランザクションを拒否した場合、請求者通知(支払いの成功を参照)を続行することは正しくありません。終了ルールはステージを停止します。アクションは [手動選択を待機 ] であるため、プロセス オペレーターは回復パス (支払いの再試行ステージ、代替の支払いチャネル、または手動の解決パス) を選択できます。

終了規則とケース・マネージャーの関係

終了ルールが発生すると、ケースマネージャーが引き継ぎます。この動作は、ステージ終了後に使用するのと同じメカニズムに依存します。つまり、終了ルールのアクションを適用し、ケースエンティティ [近日公開] の現在の状態を評価して、次にどのステージに入るかを決定します。

つまり、終了規則はケースが どこに行くか を指定する必要はなく、ステージがいつ停止 するか を指定するだけです(アクションは、前進、ユーザーを待機、原点に戻る、またはケースを終了するという高レベルの意図を記述します)。ルーティングロジックは、ダウンストリームステージのエントリルールと Case Manager のオーケストレーションロジックに存在します (最初に決定論的ルール、 フォールバックとしての Case Manager エージェント の推論)。

たとえば、拒否のために評価ステージが早期に終了した場合、次のようになります。

1. 評価ステージの終了ルールが発生します — AdjusterDecisionMadeイベントが到着したとき IF adjusterDecision == "deny"。ステージが終了します。まだ実行中の評価タスクは、現時点では実行を継続します。
2. 同じ AdjusterDecisionMade イベントは、 WHEN が一致する他のすべてのルールに到達します。拒否されたセカンダリ ステージのエントリ ルール (WHEN AdjusterDecisionMade arrives IF adjusterDecision == "deny") が true と評価され、ステージがアクティブ化されます。Denied はセカンダリ ステージであるため、そのエントリ ルールには Interrupt active 作業がオンになっているため、他のアクティブなステージは終了し、Denied が入力される前にケースで実行中のすべてのタスクがキャンセルされます。
3. 拒否ステージは、そのタスク (拒否パケットの送信、監査レポートの生成) を実行します。すべての必須タスクが完了すると、[ ケース完了 ] ルールを使用してケースがクローズされます。

この懸念の分離(終了規則は いつ停止するかを定義し、開始規則は いつ開始するか を定義する)は、ケースプランをモジュール化し、保守可能に保ちます。各ステージは、完全なルーティング グラフではなく、独自のルールのみを知る必要があります。ケースマネージャーはケースエンティティをポーリングしません:すべてのルールは イベント駆動型 であり、そのWHENイベントが到着したときにのみ評価されます。

注:

Case Manager エージェントは、早期終了後に状況をカバーする決定論的ルールがない場合のフォールバックとして機能します。予期しない状況で終了ルールが実行され、ダウンストリームのエントリルールに一致するものがない場合、エージェントはケースエンティティデータと設定されたポリシーを推論して次のアクションを決定します。正しいパスを判断できない場合は人間にエスカレーションします。

注:

終了ルールは ステージ専用です。タスクには [開始] ルールのみがあり、タスク レベルの [完了] ルールや [終了] ルールはありません。タスクの完了は、基になる作業 (フォームの送信、エージェントの完了、RPA の返送など) によって決まります。ステージを途中で終了するには、ステージ自体に終了ルールを定義します。まだ実行中のタスクもキャンセルするには、[ アクティブな作業を中断 ] をオンにしてエントリ ルールを使用して次のステージに入ります。

設計ガイドライン

終了規則をケースプランに組み込むときは、次の原則を考慮してください。

• 完全なルールをシンプルに保ちます。完全なルールでは、「必要なすべてのタスクが完了した」または「予期された決定が下された」というハッピーパスを記述する必要があります。完全ルールには例外ロジックを埋め込まないでください。
• 例外的なものには終了規則を使用してください。続行処理を真に無効にする条件のために、終了規則を予約します。すべての条件分岐に終了ルールが必要なわけではありません — 一部の条件は、通常の完了後にケースマネージャーのルーティングロジックによってより適切に処理されます。
• アップストリームの出力を監視します。終了ルールは通常、ステージの前の段階でタスクによって書き込まれたフィールドを評価します。終了ルールが監視するフィールドが特定の識別可能なタスクによって書き込まれるように、ケースエンティティスキーマを設計します。
• 出口規則と下流入口規則をペアにします。終了規則は処理を停止します。ダウンストリームエントリルールはケースをキャッチし、正しいパスにルーティングします。これらをペアで設計して、ステージを終了しても行き場がないケースを回避します。
• 意図を文書化します。終了規則は強力ですが、ケースプランを初めて読む人にとっては驚くかもしれません。わかりやすい名前とコメントを使用して、各終了ルールが存在する理由と、それが処理するシナリオを示します。

関連リソース

• ステージとステージルール — エントリ、完了、終了、再エントリルールを含むすべてのステージルールタイプの詳細なリファレンス。
• 30 分で完了する保険金請求ケースの作成 — ケース プランの構築と展開に関するエンドツーエンドのチュートリアルです。
• Case Manager の設定 — Case Manager が最初にルールを使用し、Case Manager Agent の推論をフォールバックとして使用して、ステージが完了または終了した後にケースのライフサイクルを調整する方法。