Maestro Case について

ケース管理のユース ケース、ツール サーフェス、コア設計コンポーネントなど、例外を大量に使用する長期実行の作業向けの Maestro Case の概念。

	Maestro Case	Maestro BPMN	Maestro Flow
適用されるコンテンツ	✅	❌	❌

概要

Maestro Case は、特定の状況 (ケース) に関する長期にわたる目標主導の作業をオーケストレーションします。ケースには、返金、請求の決定、調査の終了などの監査可能な結果を推進するためのデータ、ルール、タスク、履歴が保持されます。Maestro BPMN が構造化されたシーケンシャル オーケストレーションを得意としているのに対し、Maestro Case は、例外が多く非線形で、重要な意思決定ポイントで人間と AI エージェントの判断に依存するシナリオに対処します。

このドキュメントでは、Maestro の別機能としての Maestro ケースについて紹介 するとともに、このケースで解決される ビジネス ユース ケース と、Maestro BPMN ではなく Maestro ケースを選択すべき状況について説明します。また、使用する ツールセット の概要を説明し、最初のエージェンティック ケースを構築する前に理解しておく必要 のある基本概念 を示します。

対象者: 初級から中級者 — Maestro Case を評価する、または Maestro Case を使い始めるソリューション アーキテクト、ビジネス アナリスト、開発者

ケースマネジメントが選ばれる理由

従来のプロセスの自動化は、作業フローが予測可能で反復可能である場合に最適です。しかし、多くのビジネスシナリオはそうではありません。数日から数週間にわたり、複数のチームが関与し、完全に自動化できない意思決定が必要になることもあります。このような状況では、 例外は珍しくなく、予期されるものです。

ケース管理は、硬直性のない構造を提供することで、この課題に対処します。これにより、自動化と AI が定型業務や反復可能な作業を処理できると同時に、判断やポリシーの決定が必要なときに人間が介入できるようになります。

ケース管理が解決する問題点

ペインポイント	ケース管理による対処方法
永続的なケース構成やライフサイクルの追跡はありません	ライフサイクル、ステート、履歴をすべて含む ケース エンティティ [近日公開] を導入します
ネイティブステージモデリングなし	シーケンシャルなステージと遷移を定義する ためのビジュアルステージキャンバス を追加します
設計時の遷移やターゲットを絞った再突入がない	ルールベースのステージ遷移と、前のステージ内の正確なタスクへの再エントリを可能にします
制限付きの SLA とエスカレーションの制御	ケース、ステージ、タスクレベルでの SLA 追跡をサポートし、エスカレーションルールと一時停止/再開を使用
ケースワーカーとマネージャーの統一されたエクスペリエンスがない	コラボレーション、ToDo 管理、および可視性のための ケースアプリケーション を提供
アドホックな作業に柔軟性がない	例外または追加のレビューのための 実行時のアドホック タスクの作成 を許可する

ケース管理を使用する状況

ケース管理は、作業を 事前に完全に定義できない場合に最も効果的です。このようなシナリオでは、多くの場合、複数の段階、頻繁な意思決定ポイント、異なるユーザー グループやシステム間のコラボレーションが伴います。進歩は、タスクを完了するだけでなく、結果を評価し、次に何をすべきかを決定することにかかっています。

ビジネス シナリオ

シナリオ	ケース管理が必要な理由
保険金請求	長期実行、複数当事者 (請求者、損害査定人、検査官)、頻繁な例外 (ドキュメントの紛失、不審請求の申請)、SLA 主導
異議申し立てとチャージバック	当事者間のやり取り、証拠収集、エスカレーションパス、非線形進行
ローンの組成と引受	複数のレビュー段階(クレジット、コンプライアンス、引受)、リスクスコアに基づく条件付きパス、規制要件
KYC/AML修復	複数の段階にわたるドキュメント収集、規制上の意思決定ポイント、監査証跡の要件
顧客のエスカレーションと苦情	段階的な解決、修正が成り立たない場合の再エントリ、SLA コミットメント、複数チームのハンドオフ
注文フルフィルメントの例外	バックオーダー、部分出荷、返品 — SLA追跡によるマルチシステム調整
公共部門の調査と照会	アドホック承認、部門間の調整、ポリシー依存ルーティング
ベンダーのオンボーディング	多段階の審査 (法務、コンプライアンス、財務)、ベンダーの種類に基づく条件付き段階、ドキュメント収集

ケース管理は、次のような場合に価値を付加します。

• 仕事は、数秒ではなく、数時間、数日、または数週間にわたる 長期にわたる ものです。
• このプロセスは 例外が多く 、次のステップは何が起こったかによって異なり、1つのフローチャートですべてのパスをキャプチャすることはできません。
• 複数の 役割とシステムが 関係しており、ケースワーカー、マネージャー、AIエージェント、外部連携がすべて貢献します。
• SLAの追跡とエスカレーション は重要であり、期限は重要であり、違反は特定のアクションを引き起こす必要があります。
• 監査証跡 が必要であり、すべての決定、データ変更、移行を記録する必要があります。
• 再突入と再作業のループ は一般的であり、症例は修正や追加の調査のために以前の段階に戻ることがよくあります。

次の場合、ケース管理は必要ありません

すべてのプロセスにケースマネジメントが必要なわけではありません。プロセスが短命で予測可能で、毎回同じシーケンスに従う場合は、多くの場合、Maestro BPMN の方がシンプルで効率的です。

注:

クイックテスト: 次のステップが今起こったことによるものであり、1 つのフローチャートですべてのパスをキャプチャできない場合は、ケース管理を検討してください。プロセスが毎回同じパスをたどる場合は、Maestro BPMN を使用します。

共有基盤

どちらの種類のプロジェクトでも、同じ UiPath Platform サービスとタスクの種類が再利用されます。

• レガシ システムでの UI Automation 用の RPA ワークフロー
• システム間運用のための API ワークフローと連携。
• 非決定論的なタスクのための AI エージェント (UiPath または外部)。
• アクション アプリを使用した人間のタスク で、フォーム、承認、レビューを行います。
• ビジネス データ管理とデータ接続のための Data Fabric
• デザイン環境としての Studio Web。

主な違い

Dimension	Maestro BPMN	Maestro Case
作業体制	BPMN 表記法でモデル化された定義済みの一連のステップ	ルールベースの遷移を持つ名前付きステージ実行時のパスは動的に決定されます
ライフ サイクル	通常、短命から中命。あらかじめ決められたフローに従う	長命で目標主導型。新しい情報が利用可能になると進化する
非線形流れ	BPMN ゲートウェイおよびループを介して可能だが、変数が大きく変化するシナリオ向けにモデル化するのは複雑	再突入、セカンダリステージ、スキップルール、アドホックタスクの組み込みサポート
データ モデル	インスタンスにスコープが設定されるプロセス変数	インスタンスをスコープとするケース変数 + 永続 ケース エンティティ [近日公開] — すべてのステージ、タスク、および条件の読み取りと書き込みを行う、一元的な型付けされたビジネス レコード
SLA とエスカレーション	プロセス レベルでネイティブにモデル化されていない	ケース レベルとステージ レベルの両方で一流の構成概念、リスクのあるエスカレーション ルールと違反のエスカレーション ルール
ユーザー エクスペリエンス	オペレーターの [Maestro Monitoring] タブで監視	ビジネス ユーザー専用のケース アプリ (ケース リスト、詳細ビュー、タスク受信トレイ) とオペレーター向けのケース インスタンス管理
ロールベースのアクセス	プラットフォームの標準的な権限	ステージを意識したペルソナ — 各ステージ内で誰が表示および行動できるかを定義します
アドホック作業	サポートされていません。すべてのステップは設計時に定義されます	サポート — Case Manager または人間のユーザーが実行時にタスクを作成できます

ケースではタスクの種類の 1 つとして Maestro BPMN を呼び出すことができ、Maestro BPMN ではタスクの種類の 1 つとしてケースを呼び出すことができます。これにより、この 2 つのプロジェクトの種類が競合するのではなく補完し合うようになります。明確に定義されたサブプロセスには Maestro BPMN を使用し、全体的なフローが動的な場合は、Maestro Case を外部オーケストレーション レイヤーとして使用します。

設計によるエージェンティックファースト

ケース管理は、例外を多用する長期にわたる作業に適した形状ですが、それ自体では、ほとんどのルーティングと判断の呼び出しを人間のナレッジワーカーに依存しています。Maestro Case is agentic first and AI native: AI エージェントはケースの第一級の参加者であり、次の 2 つの異なるレベルで動作を行います。

• データの分類、異常のフラグ付け、ドキュメントからのフィールドの抽出、回答の下書き、ポリシーの検証など、段階内のタスクワーカーとして。各エージェントはタスク内で実行され、ケース エンティティ [近日公開] から必要なものを読み取り、それぞれの作業を行い、結果を書き込みます。
• ケース自体のオーケストレーターとして 、 Case Manager エージェントは ケースの作成からクローズまでを主導し、次にどのステージをアクティブ化するか、そのステージ内でどのタスクを実行するか、タスクまたはステージが完了するか、または早期に終了する必要があるか、エスカレーションするタイミングなど、ステージとタスクの両方のレベルで決定を下します。これは、決定論的なルールが存在する場合はそれに沿って機能し、存在しない場合はケースデータやポリシーに対する理由と連動します。

これにより、ルーティングの決定、例外の処理、ケースの前進を人間のナレッジワーカーのみに任せるという従来のボトルネックが解消されます。人間は、政策、判断、説明責任が必要なときに介入しますが、人間なしでは事件を動かせないからではありません。

Maestro Case ツールセット

Maestro Case は、次の 3 つの補完的なサーフェスを通じて、エンドツーエンドのケース ライフサイクルにまたがります。

ケース プラン デザイナー (Studio Web)

対象者: オートメーションの開発者とビジネス アーキテクト

これを使用して、ケースプラン (ステージ、移行、SLA、エスカレーション、ステージレベルのアクセス) を作成または更新します。実装をタスクにアタッチします (Human、RPA、API、AI エージェント、エージェンティック プロセス、子ケース)。入力と出力をマッピングし、再入力動作を設定します。出力は、 公開して展開する準備ができているバージョン管理されたケースプランです。

ケース インスタンス管理 (Maestro)

対象者: プロセス オペレーター、インシデント マネージャー、およびプロセス オーナー。

ライフサイクル制御 (一時停止、 再開、 キャンセル、 移行) と完全な監査を使用して実行中のケースを操作するために使用します。失敗したタスクを再試行するか、インスタンスを新しいケースプランバージョンに移行して、インシデントを解決します。ライブインサイト、ヒートマップ、 プロセスマイニング を使用して、ボトルネックを特定し、改善を設計にフィードバックします。

ケース アプリ (Maestro)

対象者: ケースワーカーとケースマネージャー。

これを使用して、すべてのケース、ケースの詳細 (タイムライン、ケース データ、ヒューマン タスク) を表示し、 完了 や 再開などのクイック アクションを実行します。ケースアプリケーションは、リスト、詳細、ToDo ビュー、SLA ビューなど、ケース中心の独自のワークスペースです。ヒューマンタスクフォームは、引き続き アクションアプリ を使用して構築され、ケースタスクによって参照されます。

Case App には次の 2 つのオプションがあります。

オプション	説明	使用すべきタイミング
すぐに使えるケースアプリ	Maestro Case に付属する既製のノーコード ケース ワークスペース。リスト、詳細ビュー、タスク受信トレイ、およびSLAビューは、ケースプランとエンティティから自動的に設定されます。	デフォルト — コードを書かずに迅速なケース操作に使用します。
カスタムのコード化されたケース アプリ	プロコードのTypeScript SDKを使用して構築するオーダーメイドのケースアプリ。カスタムビュー、レイアウト、ワークフローを同じケースランタイム上で作成できます。	すぐに使用できるアプリで公開されているもの (ブランド化されたワークスペース、カスタム ダッシュボード、ドメイン固有のケース エクスペリエンス) を超える UI が必要な場合。

注:

ケース アプリは UiPath Apps とは異なります。ケースアプリケーションは、ケース操作専用に構築されています。UiPath Apps は、完全にカスタムまたは複合的なビジネス アプリ用の汎用ローコード ビルダーです。ケースアプリケーションを使用して、迅速なケース操作を行います。UiPath Apps は、ケースの操作を超えたカスタム UI が必要な場合に使用します。

中心となる概念

エージェンティック ケースを設計する前に、以下の概念を理解することが不可欠です。

大文字と小文字と大文字と小文字のキー

ケースは、請求、紛争、調査など、解決する必要のある現実のビジネス状況を表しています。従来のプロセス インスタンスとは異なり、ケースは、新しい情報が利用可能になり、意思決定が行われるにつれて、時間とともに進化します。

各ケースは、 ケース キーによって一意に識別されます。

キーの種類	説明	例
システム キー	ケース作成時に Maestro によって自動生成されます	HC-1234, CLM-00891
外部 (ユーザー定義) キー	作成時に渡されるアップストリーム ID により、同じ現実世界のケースがツール間で認識されます	CRM ケース番号、ポリシー番号、ERP 注文 ID

ケースが別のシステム (CRM、ERP、チケット ツール) で発生した場合は外部キーを使用して、個別のマッピング テーブルを維持することなく、人間と連携がツール間でケースを関連付けられるようにします。

Case entity

サポート案件エンティティ [近日公開] は、すべてのサポート案件の中心にある永続的な型指定されたビジネス レコードです。これは、ケースのライフサイクル全体を通じて、ステージ、タスク、および移行条件が読み取りおよび書き込みを行う信頼できる唯一の情報源です。

すべてのケースプロジェクトには、次の 2 つの追加ですぐに使用できるデータオブジェクトも含まれています。

• ケース文書 — ケースに関連する添付ファイルとファイル (領収書、写真、契約書)。
• ケース コメント — 実行時にケース ワーカーとマネージャーによって追加されたメモ、注釈、およびコミュニケーション。

3 つのオブジェクトはすべて、ケースの作成時に生成された不変の caseID システム フィールドを共有します。

ケース エンティティを Maestro ケースに取り込むには、次の 3 つの方法があります。

ソース	説明	使用すべきタイミング
ネイティブ Data Fabric オブジェクト	ケース プロジェクトでケース エンティティのトグルを有効化すると、ネイティブの Data Fabric ケース エンティティが自動的に作成され、ケースにリンクされます	データ モデルを所有する新しいプロセス
VDOによる記録システム	外部ソースを Data Fabric の仮想データ オブジェクト (VDO) として登録し、ケース エンティティのトグルを有効にして、Data Fabric の VDO とケース エンティティ間の関係を確立します	エンティティ データは外部システム内に存在し、重複せずに参照する必要がある
ケーストリガーによる記録システム	ケース作成トリガーで既存のデータを渡します (API コネクタ経由など)。フィールドは、ケース全体で使用できるケース フィールドになります	作成時にケースをハイドレートする軽量な連携

ステージ

ステージ は、ケースの名前付きフェーズです ( 例: 取り込み、 レビュー、 和解、 クローズ)。ステージは、実際には、ケースをステージの完全な状態に向けて前進させる タスクの集合 です。

一次段階と二次段階

Maestro Case では、次の 2 種類のステージがサポートされています。

ステージの種類	目的	到達方法	ケースアプリケーションの表示
プライマリーステージ	ケースの予想される進行 ( 例: Intake → Review → Settlement → Closure)。	キャンバス上の前のステージのエッジから入力するか、設定された入力条件によって入力できます。	ケースアプリケーションタイムラインに コアステージノード として表示されます — これらは、ケースワーカーがメインライフサイクルと見なすステージです。
セカンダリ ステージ	ケース中にいつでも発生する可能性のある例外または代替パス ( 情報の要求、 拒否、 取り下げ、 キャンセルなど)。	入力エッジなし — ステージを セカンダリ として切り替えると、エッジが削除されます。この段階は、エントリ条件が true と評価された場合にのみ到達し、ケースが現在どこにあるかに関係なく、その状態が発生するたびにアクティブ化できます。	コアステージのタイムラインの一部ではありません。アクティブな場合 (例外パス インジケータなど) は、いつでも起動する可能性があるため、個別に表示されます。

言い換えれば、ステージを二次的なものとしてマークするということは、私をメインのライフサイクルに縛り込まないで、エントリー条件が満たされるたびに自分自身を活性化させることを意味します。これにより、ケースはレビューの途中で リクエスト情報 にジャンプしたり、デザイナーが考えられるすべてのソースからエッジを描画したりすることなく、どこからでも 取り下げ ることができます。

ステージの属性

各ステージでは、以下を定義します。

• エントリー条件 — このステージが始まったとき。
• 完全な状態 — ステージを完了としてマークし、前進するために何が真実でなければならないか。
• 出口条件 — ステージを早期に退出するタイミング(例えば、ベイルアウトやルート変更のシナリオ)。
• 再突入条件 — 再作業または原点への帰還経路がここに戻る方法。
• ステージ SLA とエスカレーション — 期限、警告のしきい値、エスカレーション通知と E メール受信者。

ステージは、 必須 または オプションとしてマークできます。必要なすべてのステージが完了するまで、ケースは完了できません。オプションのステージは、エントリー条件が満たされた場合にのみアクティブになり、ケースをブロックせずにスキップできます。

並列ステージ

同じケースで複数のステージを同時にアクティブにすることができます。たとえば、 顧客とのコミュニケーション ステージは 引受 と並行して実行でき、 決済 はバックグラウンドで準備されます。ステージを並行して実行するか、順番に実行するかは、エントリー・ルールによって制御されます。

タスク

タスクは、ステージ内の作業単位です。

タスクの種類

Maestro Case では、以下のタスクの種類がサポートされています。

タスクの種類	説明
人間のアクション	個人に割り当てられたフォーム、承認、および明確化
RPA ワークフロー	レガシ システムの UI オートメーション、抽出、照合
API ワークフロー	ワークフローによるシステム間運用
コネクタを実行	コネクタ アクティビティを呼び出す (例: 通知の送信、外部システムでのレコードの作成)
AI エージェント (UiPath)	判断に基づく作業のためのデータに対する自律的な推論
外部エージェント	API 経由で呼び出されるサードパーティの AI エージェント
Maestro のエージェンティック プロセス	タスクとして呼び出される、複数ステップの BPMN プロセス
子ケース	別のケースは、独自のライフサイクルを持つ子として生成されます
Wait for Timer	期間が経過するか、目標日に達するまで一時停止します
コネクタ イベントを待機	コネクタ経由で外部イベントが到着するまで一時停止します

実行モード

すべてのタスクは、その種類に関係なく、開始 するタイミング を決定する 3 つの実行モードのいずれかで実行されます。

実行モード	動作	例
順次	タスクは、ステージ内で定義された順序で実行されます。シーケンスには、展開して次のステップの前に再結合する 並列分岐 を含めることもできます。	引受段階: Verify income → (Run credit check ∥ Pull employment history) → Calculate DTI → Generate decision
イベント ドリブン	タスクには エントリ ルール があり、イベントによってルールが true と評価されるたびに、ステージが飛行中であったり、シーケンスがすでにそのポイントを過ぎていたりしても、起動します。イベントが繰り返された場合は、複数回起動できます。	請求処理ステージの場合: Request additional documentsは、ステージが現在シーケンスのどの段階にあるかに関係なく、検証タスクが欠落しているドキュメントに IF のDocuments.Missing == trueフラグを立てたときに発生します
アドホック	タスクはケースプランで定義されますが、実行時にユーザーが手動でトリガーしたときにのみ開始されます。アドホック タスクには、上記の任意の種類のタスクを使用できます。	顧客エスカレーションステージ:Escalate to supervisorまたはAdd fraud review — ケースワーカーが判断を下して開始

同じステージで複数のタスクを同時にアクティブにすることができます。シーケンシャルな分岐は、並列パスに展開し、次のステップの前に再結合できます。イベントドリブンなタスクは、シーケンスとは独立して起動 し、多くの場合、実行中の他のタスクと並行して実行されます (トリガー イベントが繰り返されると、同じイベントドリブンなタスクの複数のインスタンスが同時に起動するなど)。アドホック タスクは、実行中のタスクと並行していつでも開始できます。

一度だけ実行

ステージが再開始されたら、各タスクで 1 回のみ実行 フラグを使用して、どのタスクを再実行するかを制御します。

• 一度だけ実行 = true — タスクは再エントリ時にスキップされます。以前の出力は保持され、タスクは再度実行されません。
• 一度だけ実行 = false (デフォルト) — タスクは、ステージが再入力されるたびにリセットされて再実行され、新しい出力が生成されます。

例:ドキュメント コレクション ステージでは、Send document checklist to customerタスクは 1 回だけ実行済みとマークされるため、別の理由でステージが再開されるたびに顧客に電子メールを再送信する必要はありません。Validate documentsタスクは既定のままであるため、新しい提出ごとに新たに検証されます。

その他のタスク設定

各タスクは、ケース エンティティにマップされた 入力と出力 もサポートします。

ルール

ルールは ライフサイクルの移動を制御し、ケース管理を非線形にするメカニズムです。これらはCMMN(Case Management Model and Notation)パターンに従い、イベント駆動型です—ルールは、ポーリングスケジュールや固定シーケンスではなく、ケースで関連するイベントが発生したときにのみ起動します。

すべてのルールには次の 3 つの部分があります。

• WHEN — 評価をトリガーするイベントです。イベントには 2 種類があります。
  • ケースのライフサイクル自体によって出力される内部イベント (CaseCreated、StageEntered、StageCompleted、StageExited、TaskCompleted、CaseSlaAtRisk、CaseSlaBreached、StageSlaAtRisk、StageSlaBreached、およびタスクによって書き戻されたケースのエンティティ フィールドの変更。
  • ケースの外部から受信する外部イベント — Integration Service コネクタのイベント (Webhook、キュー メッセージ)、タイマーの起動、子ケースの完了または終了、ケースへの直接 API 呼び出し。
• IF (任意) — ルールが有効化されるためには true でなければならないケースエンティティの条件です。省略すると、ルールは一致するすべての WHEN イベントで発生します。
• アクション — ルールが起動したときに行うこと(ステージの開始、ステージの完了、ステージの終了、ケースの完了など)。

ルールのスコープは、 ケース、 ステージ、 またはタスクの 3 つのレベルのいずれかになります。

ケース レベルのルール

ルール	目的	例
ケースの完了	ケース全体を完了 (成功の結果) としてマークします。	必要なすべての ステージが完了したとき IF Outcome == "Approved"
ケースの終了	通常の完了(キャンセル、出金、詐欺)に達する前にケースを終了します。	WHEN Application.Status 変更 Application.Status == "Withdrawn"

ステージレベルのルール

ルール	目的	例
エントリ	ステージ開始時のゲート。	WHEN Application.Submitted IF Application.Type == "Mortgage" && Documents.Count > 0 イベントが到着します
完了	ステージが正常に終了するタイミングを決定します。	ステージ内のいずれかのタスクが完了したとき 必要なすべてのタスクがDoneされ、UnderwritingDecision != null
終了	たとえそれが不完全であっても、早めにステージから脱出する。	WHEN UnderwritingDecision 変更 UnderwritingDecision == "Reject"
再エントリ	以前に完了したステージに戻り、制御された再作業を行います。	WHEN Verification.Result 変更 Verification.Result == "Failed" && DocsComplete == false

エントリ ルールには、エントリ ルールが true と評価されたときに他のアクティブ ステージに何が起こるかを制御する 中断 トグルがあります。

• 中断 = true — 現在アクティブなすべてのステージが自動的に終了し、ケースは新しく入るステージに強制されます。これは、 取り下げ や 不正ホールド など、すぐにケースを引き継ぐ必要があるハード例外パスに使用します。
• 中断 = false — 新しいステージは、既存のアクティブなステージとともにアクティブになります。ケースでは、複数のステージを並行して実行できます。

デフォルトはステージの種類によって異なり、 プライマリステージのデフォルトは interrupting = false (並列結合 — 通常の作業の進行) です。セカンダリステージのデフォルトは interrupting = true です(セカンダリステージは例外パスまたは代替パスを表すため、ケースを引き継ぎます)。どちらのデフォルトもステージごとにオーバーライドできます。

完了 ルールと 終了 ルールには、ステージ終了後のケースの処理方法を決定する アクション もあります。

• ケースの完了 / ケースの終了 — ここからケースを終了または終了します。
• 手動選択を待つ — 一時停止して、ユーザーに次のステージを選択させます。
• 原点への復帰 — ケースを、このケースを最初に起動したステージに戻します。

タスクレベルのルール

ルール	目的	例
エントリ	ステージ内でタスクが開始されたときにゲートします。イベント ドリブン タスクによってトリガー イベントが発生したときに起動したり、必要に応じて順次またはアドホックのタスクによって実行を保護したりするために使用されます。	検証タスクが欠落しているドキュメントにフラグを立てた場合 IF はDocuments.Missing == true

ルールはイベント駆動型であるため、ケースは固定されたシーケンスを実行しません — ステージとタスクは、 WHEN イベントが到着し、 IF 条件 (存在する場合) が現在のケース エンティティに対して true と評価されるたびに、ステージとタスクがアクティブ化、完了、終了、または再オープンされます。ステージの再エントリ時のタスクの再実行は、上記の「タスク」セクションで説明した「一度だけ実行」フラグによって制御されます。

Case Manager

ケースマネージャーは、ケースのオーケストレーターであり、イベントに基づいてライフサイクルの決定を推進するエージェントです。次にどのステージをアクティブにするか、どのタスクを開始するか、ステージを早期に完了または終了するタイミング、およびエスカレーションするタイミングを決定します。

このオーケストレーションは、次の 2 つの補完的な方法を使用して行われます。

1. ルール (プライマリ) — すべての意思決定ポイントについて、ケースマネージャーはまず、ケースプランで定義された決定論的な CMMN ルールを評価します。ルールが決定を解決する場合、それは取られます。これにより、大量のハッピー パスを予測可能、監査可能、かつ安価に維持できます。
2. エージェント (フォールバック) — 状況 (ギャップ、例外、または判定コール) をカバーするルールがない場合、ケース マネージャーは、ケース エンティティ、ケース プラン、および使用可能なポリシーと知識を考慮して、次のアクションを選択します。これにより、発見されたすべての分岐に対して人間にエスカレートすることなく、ケースを動かし続けることができます。

ケースを駆動するには、 Case Manager エージェントは 、読み取ることができるケースの状態、イベント、ポリシー、および発行できるステージ/タスクの決定を指定する定義済みの 入出力コントラクト に準拠している必要があります。完全な仕様については、 Case Manager エージェント契約 を参照してください。

SLA とエスカレーション

SLA とエスカレーション ルールをケース レベルとステージ レベルの両方で定義します。

• ケース レベルの SLA — 全体的な解決目標 (例: 48 時間以内に解決する)。
• ステージレベルのSLA — ローカライズされた期日(たとえば、24時間以内のレビュー)。
• SLA の状態 — 順調に進んでいる、リスクがある、または違反している。これらの状態は、ケースリストと詳細ビューでバッジとして表示されます。
• エスカレーション — SLA が危険にさらされている、または違反した場合にトリガーされるルールです (例: 再割り当て、管理者への通知、優先度フラグの作成)。
• 一時停止/再開 — SLA タイマーは、ケースが外部入力を待機しているときに一時停止し、再びアクション可能になったときに再開できます。

ケースのペルソナ

Maestro Case では、ペルソナを通じて ステージに合わせたアクセス を適用することで、適切なユーザーが適切なタイミングで見て行動できるようにします。

ケースペルソナは、ケースタイプ (インテークエージェント、アジャスター、スーパーバイザーなど) 内の役割を表す設計時の抽象化です。ペルソナは、ケースのアクセスニーズを組織の ID 構造から切り離し、ケース定義を組織やテナント間で移植できるようにします。

• 設計時に、ケース デザイナーはペルソナを作成し、それぞれを特定のステージにスコープします。
• デプロイ時に、システム管理者が各ペルソナをユーザまたはユーザグループにバインドするため、同じケースタイプでも環境ごとに異なる範囲を持つことができます。
• 実行時にユーザーのペルソナが解決され、それに応じてステージ スコープが適用されます。複数のペルソナを持つユーザーは、ステージスコープの和集合を取得します。

たとえば、ローン処理のケースでは、次のように定義できます。

ペルソナ	アプリケーション	認証	引受	支払い
ローン・オフィサー	○
検証アナリスト		○
引受査定人			○
支店長	○	○	○	○

ステージ内のタスクは、特定のユーザーではなくペルソナに割り当てられます。実行時にペルソナがロール/グループからユーザーに解決され、タスクの可視性と割り当てが決定されます。

注:

完全なケースのユーザー ロールとアクセスのサポートは、近日中に開始される予定です。

請求と消費状況

Maestro Case は Maestro と同じ請求に従います。ケース内で実行される作業は、使用するタスクの種類 (AI エージェント、RPA ワークフロー、API ワークフロー、Integration Service コネクタ) のネイティブの消費ライセンスを消費します。

次のステップ

• 最初の Maestro ケース プロジェクトを構築する — 損害保険請求ケースをゼロから作成、デプロイ、テストするステップ バイ ステップのチュートリアルです。
• コア構造の参照 — すべての Maestro ケース 構造 (ケース エンティティ [近日公開予定] )、ステージ、タスク、移行条件、SLA、ペルソナ) の詳細なリファレンスです。
• ステージ遷移と再突入の設定方法 — 入口、出口、および再突入条件を持つ非線形ケースフローをモデル化するためのハウツーガイド。