退場規則と早期解雇

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

概要

Maestro の場合、すべてのステージは 2 つの方法のいずれかで終了できます。 完了ルールによって通常どおり作業を終了するか、 終了ルールによって早期に終了します。出口ルールは サーキットブレーカー として機能し、条件が変化した瞬間に段階を短くし、継続的な処理を無意味または不正確にします。これら2つのメカニズムの違いを理解することは、ハッピーパスと例外パスの両方をきれいに処理するケースプランを設計するために不可欠です。

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

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

ルールの種類	質問への回答
エントリールール	このステージはいつアクティブにする必要がありますか?
ルールの完了	この段階はいつ終わりますか?
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 エンティティに既に書き込まれているタスクの出力は保持されます。処理中であるがまだ出力を書き込んでいないタスクは、「 終了 」として記録され、その部分的な作業は破棄されます。
• ケースマネージャーは、ルールの アクション (完了と同じセット:ケースを完了または終了し、手動選択を待機し、原点に戻る)を適用し、通常の完了後と同様に、次に何をすべきかを評価します。
• ケースは必ずしも終了するわけではなく、別のステージ、セカンダリ (例外) パスにルーティングされるか、決定論的なルールが状況をカバーしない場合に Case Manager エージェントが 次のアクションを決定する場合があります。
• 早期終了は、ケースの 監査証跡に記録されます。たとえば、実行ルール、トリガーとなった WHEN イベント、IF 句を満たしたケースエンティティの値、実行されたアクション、終了したタスクのリストです。エントリは、ケースアプリケーションタイムラインとケースインスタンス管理に表示されます。

どう違うか

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

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

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

注:

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

出口規則が重要な理由

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

• 無駄な努力。タスクは、結果が重要でない場合でも実行を継続します。たとえば、調査段階では、フィールド検査官を派遣し、ポリシーがすでに無効であることが判明している請求の写真を分析するのに何時間も費やす場合があります。
• 遅延ルーティング。現在のステージが完全に完了するまで、ケースは正しい例外パスに移動できず、ケースの全体的な解決に不要な待機時間が追加されます。
• 複雑で完全なルール。個別の終了メカニズムがない場合、完全なルールは通常の終了と異常な終了の両方を考慮する必要があり、読み取り、保守、およびデバッグが困難になります。

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

必要な段階と早期退出

必須とマークされたステージは、ケースが通常のケース完了ルールを満たすために完了状態で終了する必要があります。終了規則が必要なステージで起動すると、そのステージは完了ではなく終了状態で終了するため、"必要なすべてのステージが完了しました" というチェックには影響しません。

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

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

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

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

ナレッジベースと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"interrupting = trueに発生)に到達し、拒否されたが引き継いで通知を送信し、ケースをクローズします。

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

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

例 — 調査段階:

WHEN FraudCheckCompleted event arrives
  IF fraudScore > 0.9
  ACTION advance

しきい値を超える不正スコアは、ケースがすぐに調査段階を離れる必要があることを意味します。アクションは 事前 であり、 不正ホールド のセカンダリステージ(interrupting = true)が同じイベントでアクティブになり、ケースを引き継ぎます。現地調査や警察の報告書の回収が完了するのを待つのは、時間と資源を浪費することになる。

パターン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と評価され、ステージがアクティブになります。拒否は第 2 段階であるため、その開始規則はデフォルトで interrupting = trueに設定され、他のアクティブな段階は終了します。
3. 拒否ステージは、そのタスク (拒否パケットの送信、監査レポートの生成) を実行します。すべての必須タスクが完了すると、[ ケース完了 ] ルールを使用してケースがクローズされます。

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

注:

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

注:

終了ルールは ステージ専用です。タスクには開始ルールのみがあり、タスクレベルの完了ルールや終了ルールはありません。タスクの完了は、基になる作業 (送信されたフォーム、エージェントの完了、RPA の返却など) によって決まります。ステージの途中で作業を停止するには、ステージ自体で終了ルールを定義します。ステージ内で実行中のすべてのタスクを終了します。

設計ガイドライン

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

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

関連リソース

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