Maestro Case について

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

	Maestro Case	Maestro BPMN	Maestro Flow
コンテンツの適用対象	✅	❌	❌

概要

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

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

対象となるユーザー: 初級から中級者 — Maestro Case の評価や Maestro Case の使用開始に臨むソリューション アーキテクト、ビジネス アナリスト、開発者

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

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

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

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

解決できる問題 (ペイン ポイント)	ケース管理による対処方法
永続的なケース構造やライフサイクルの追跡がない	ライフサイクル全体、ステート、履歴などのケース エンティティ (近日公開) を導入する
ネイティブなステージのモデリングがない	ステージの視覚的なキャンバスを追加して、逐次的なステージと移行を定義する
設計時の移行や目標を設定した再開がない	先行するステージで正確なタスクへのルールに基づくステージ移行と再開を可能にする
SLA とエスカレーションの制御に制限がある	エスカレーション ルールと一時停止/再開を使用して、ケース、ステージ、タスクの各レベルでの SLA 追跡をサポートする
ケース ワーカーとマネージャー向けの統一したエクスペリエンスがない	ケース アプリを提供して共同作業、タスクの管理、可視性を実現する
アドホックな作業に対応する柔軟性がない	例外や追加レビューに備え、実行時にアドホック タスクを作成できるようにする

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

作業の全面的な事前定義ができない場合に、ケース管理が最も効果的です。多くの場合、このようなシナリオには、多数のステージ、意思決定ポイントの多発、さまざまなユーザー グループやシステム間の共同作業が伴います。タスクを完了するだけで全体が進捗するとは限らず、結果を評価し、次に何をすべきかを判断することが求められます。

ビジネス シナリオ

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

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

• 作業が長期間にわたる — 作業に数秒ではなく、数時間、数日、数週間を要する。
• プロセスに例外が多い — 先行の手順で発生した現象によって次の手順が決まるので、すべての作業経路を網羅した単一のフローチャートがない。
• 複数の役割とシステムが関与する — ケース ワーカー、マネージャー、AI エージェント、外部連携のすべてが関係している。
• SLA の追跡とエスカレーションが重要である — 期限、問題、違反によって特定のアクションを開始する必要がある。
• 監査証跡が必要である — 意思決定、データ変更、移行をすべて記録する必要がある。
• 再開と再作業の繰り返しが普通になっている — 修正や追加の調査のために、ケースを頻繁に以前の段階に戻している。

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

すべてのプロセスでケース管理を必要とするわけではありません。プロセスが短期間で、予測可能であり、毎回同じ手順に従う場合は、Maestro BPMN の方が簡潔で効率的であることが普通です。

注:

簡単なテスト: 現在の手順の結果によって次の手順が決まり、すべての作業経路を網羅した単一のフローチャートがない場合は、ケース管理の導入を検討します。プロセスが毎回同じ作業経路をたどる場合は Maestro BPMN を使用します。

共有基盤

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

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

主な違い

Dimension	Maestro BPMN	Maestro Case
作業の構造	BPMN 表記でモデル化した定義済みの一連の手順	ルールベースの移行を設定した名前付きステージ。実行時の作業経路は動的に決まる
ライフ サイクル	多くの場合、短期から中期。事前定義のフローに従う	長期で目標主導型。新しい情報が得られるたびに進化
非線形フロー	BPMN のゲートウェイとループを介して可能であるが、変動性が高いシナリオのモデル化が複雑	再開、セカンダリ ステージ、スキップ ルール、アドホック タスクを組み込みでサポート
データ モデル	インスタンスに対してスコープを設定したプロセス変数	インスタンスに対してスコープを設定したケース変数と、永続的なケース エンティティ (近日公開) — 一元化して種類を指定したビジネス レコードとの間で、すべてのステージ、タスク、条件を読み取り、また書き込み
SLA とエスカレーション	ネイティブではプロセス レベルでモデル化されていない	リスクと違反に対処するエスカレーション ルールを備え、ケース レベルとステージ レベルの両方で第一級の構成
ユーザー エクスペリエンス	Maestro の運用者向け [監視] タブで監視	ビジネス ユーザー専用のケース アプリ (ケース リスト、詳細ビュー、タスク受信トレイ) と、運用者専用のケース インスタンス管理
ロールベースのアクセス	Standard Platform の権限	ステージ対応のペルソナ — ステージごとに誰が表示と処理ができるかを定義
アドホック作業	サポート対象外。すべての手順を設計時に定義	サポート対象 — ケース マネージャーまたは人間のユーザーが実行時にタスクを作成可能

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

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

ケース管理は、例外が多い長期実行作業に適した形態ですが、ルーティングと判断のほとんどは人間の知識作業者が行う必要があります。Maestro Case はエージェント ファーストで AI ネイティブです。AI エージェントは、ケースで第一級の関与要素であり、次の 2 種類のレベルで動作します。

• ステージでのタスク作業者 — データの分類、異常フラグの設定、ドキュメントからのフィールド抽出、応答の提案作成、ポリシーの検証などを実行します。各エージェントはタスクの中で稼働し、ケース エンティティ (近日公開) から必要なものを読み取り、それぞれの作業を遂行して結果を書き込みます。
• ケース自体のオーケストレーター — ケース マネージャー エージェントは、ケースをその作成から終了まで主導し、ステージとタスクの両方のレベルでさまざまな判断を下します。たとえば、次にどのステージをアクティブ化するか、そのステージでどのタスクを実行するか、タスクやステージが完了しているか早期段階での終了が必要か、どの時点でエスカレーションするかなどがあります。このような判断は、決定論的なルールがあればそれに従い、それがない場合はケース データやポリシーに基づきます。

これにより、ルーティングの決定、例外の処理、ケースの進捗を人間の知識作業者のみに頼ることで発生していた従来のボトルネックを解消できます。ポリシー、判定、説明責任が必要なときには人間が介入しますが、それは人間がいないとケースが進捗しないからではありません。

Maestro Case ツールセット

Maestro Case は、次の 3 つの相互に補完的な機能を通じて、ケースのライフサイクルをエンドツーエンドで扱います。

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

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

この機能を使用して、ケース プランを作成し、また更新します。ステージ、移行、SLA、エスカレーション、ステージレベルのアクセスなどが対象となります。タスクに実装を関連付けます。人間、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 エージェントとその動作モードは パブリック プレビューの段階です。

ケース マネージャー エージェントが 判断します。エンジンは実行します。 判断を返します。ケースを直接変更することはありません。これは管理された UiPath エージェントです。システム プロンプトと入出力コントラクトが事前に定義されています。モデル、コンテキスト、メモリ、ツール、エスカレーション パスを設定し、運用前に評価を使用してテストします。完全な仕様については、 Case Manager エージェントの構成とテスト を参照してください。

SLA とエスカレーション

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

• ケース レベルの SLA — 全体的な解決目標 (例: 48 時間以内に解決する)。
• ステージレベルのSLA — ローカライズされた期日(たとえば、24時間以内のレビュー)。
• SLA の状態 — 順調に進んでいる、リスクがある、または違反している。これらの状態は、ケースリストと詳細ビューでバッジとして表示されます。
• エスカレーション — SLA が危険にさらされている、または違反した場合にトリガーされるルールです (例: 再割り当て、管理者への通知、優先度フラグの作成)。
• Pause/Resume — SLA timers are not paused automatically. An operator can pause a case instance explicitly to stop its SLA timers, and resume it to restart them from where they stopped.

ケースのペルソナ

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

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

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

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

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

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

注:

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

請求と消費状況

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

次のステップ

• 最初の Maestro ケース プロジェクトを構築する — 損害保険請求ケースをゼロから作成、デプロイ、テストするステップ バイ ステップのチュートリアルです。
• コア構造の参照 — すべての Maestro ケース 構造 (ケース エンティティ [近日公開予定] )、ステージ、タスク、移行条件、SLA、ペルソナ) の詳細なリファレンスです。
• ステージ遷移と再突入の設定方法 — 入口、出口、および再突入条件を持つ非線形ケースフローをモデル化するためのハウツーガイド。
• ケース マネージャー エージェントを設定してテストする (プレビュー) — AI Orchestrator をケースに追加し、その動作モードを選択して、モデル/コンテキスト/メモリ/エスカレーションを設定して、運用前に評価を使用してテストします。
• コーディング エージェントを使用して Maestro Case を構築する (プレビュー) — Claude Code や GitHub Copilot などのコーディング エージェントを使用して、プロンプト、BPMN モデル、プロセス マップ、PDD からケース計画の下書き、構築、デプロイを行います。