Maestro Case のライフサイクル: イベント トリガーからアプリのエクスペリエンスまで

Maestro Case のライフサイクル イベントトリガーから、ケースエンティティデータ、ケースプランルール、Case Manager の決定、タスクの実行、ケースアプリエクスペリエンスまで。

概要

ケースとは、請求、紛争、調査、ローンなど、存続期間の長いビジネス オブジェクトであり、単一のタスクやセッションよりも長く存続し、データと意思決定が蓄積されるにつれて段階を非線形に移動します。Maestro Case はライフサイクルをエンドツーエンドで推進します。イベントによってケースが作成され、ケースプランでは移行を管理する可能なステージとルールが定義され、Case Manager はルールファーストオーケストレーションと Case Manager エージェントのフォールバックを使用して次に何が起こるかを決定し、ケースアプリケーションはライブ作業をビジネスユーザーに公開します。

このドキュメントは、スタックのすべてのレイヤーでデータをトレースし、ケースプラン→ケース→プラン → トリガー→ケースプラン、ランタイムエクスペリエンス→タスクを行うため、最初のケースプランを設計する前に正確なメンタルモデルを形成できます。

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

フルスタックを理解する理由

Maestro Caseは単一の機能ではありません。これは、設計時の定義 (ケース計画、ケースエンティティ [近日公開])、ステージ、タスク、ルール) とランタイムエンジン (ケースマネージャー、ケースアプリ、ケースインスタンス管理) の協調したシステムです。ライフサイクル全体を理解することは、次のことに役立ちます。

• 現実世界の仕事の非線形性を考慮した堅牢なケースプランを設計します。
• 厳密なステージシーケンス、不明確なフィールド所有権、再突入ロジックの欠落などの一般的な落とし穴を回避します。
• Studio Web でステージをモデル化する開発者から、ケースアプリケーションでタスクを完了するケースワーカーまで、さまざまな役割でコミュニケーションを取ります。

アーキテクチャの概要

Maestro のケース スタックは 5 つのレイヤーで構成されています。データは、イベント ソースからオーケストレーションと実行を経て下向きに流れ、ビジネス ユーザー エクスペリエンスに上向きに浮かび上がります。

以下のセクションでは、データが移動する順序で各レイヤーを順を追って説明します。

レイヤー 1 — イベント トリガー (ケースの開始方法)

イベント トリガー は、ケース インスタンスを作成し、ケース エンティティ [近日公開] を初期データでハイドレートするエントリ ポイントです。1 つのケースプランで複数のトリガーを定義できるため、同じタイプのケースを異なるチャネルから開始できます。

トリガー ソース	説明	例
Data Fabric エンティティ	Data Fabric エンティティまたは VDO の「行の作成」イベントがケースを開始します。エンティティ フィールドは case フィールドになります。	Home Claims エンティティの新しい行により、損害保険のケースが作成されます。
コネクタを待機	Integration Service のコネクタ イベント (API 呼び出し、Webhook、メッセージ) によってケースが開始されます。API ペイロードはケース エンティティとして扱われます。	Microsoft Teams チャネル メッセージによって、取り下げステージがトリガーされます。
ポータル/フォーム	ユーザーが Web フォームを通じてデータを送信します。	従業員がセルフサービス ポータルから経費精算書を提出します。
メール	受信メールが解析され、そのデータがエンティティ フィールドにマッピングされます。	転送された領収書メールにより、新しい請求品目が作成されます。
API	外部システムがケース作成エンドポイントを呼び出します。	ERP システムは、保険契約イベントで請求ケースをトリガします。
スケジュール	時間ベースのトリガーは、ケースの作成またはフォローアップを行います。	毎日のジョブは、古いアイテムのフォローアップ ケースを作成します。

各トリガーは、受信データを ケース エンティティのフィールドにマッピングします。この初期マッピング ( ハイドレーション と呼ばれることもあります) によって、すべての下流のステージ、タスク、および遷移条件で使用できるデータが決まります。

注:

ケースプランには複数のトリガを含めることができます。たとえば、保険金請求のケースでは、ポータル、メール パーサー、電話の文字起こし API からの提出を受け付けます。これらはすべて同じ AutoInsuranceClaim エンティティにマッピングされます。

レイヤー 2 — ケース エンティティ (信頼できる唯一の情報源)

ケース エンティティ (近日公開) は、すべてのケース インスタンスの中心となる、永続的で構造化されたデータ オブジェクトです。これは、ケースの存続期間全体にわたって存続し、すべての段階、タスク、および移行条件が読み書きする唯一の真実の情報源として機能します。

すぐに使えるデータ オブジェクト

すべてのケースプロジェクトでは、次の 3 つのデータオブジェクトが自動的に作成されます。

オブジェクト	目的
ケース エンティティ	中心的なビジネス データ モデルです。条件とタスクで使用される構造化データを保持します。
ケースドキュメント	ケースに関連付けられた添付ファイルとファイル (領収書、写真、契約書)。
ケースコメント	ライフサイクルを通じて参加者が追加するメモ、注釈、およびコミュニケーション。

3 つすべてが、ケースの作成時に自動生成され、すべてのケース データを関連付ける不変の caseID システム フィールドを共有します。

データがエンティティに到達する方法

ソース	メカニズム
Data Fabric ネイティブ (推奨)	Data Fabric でビジネス エンティティを作成し、ケースにリンクします。
Data Fabric の VDO	外部データソースを仮想データオブジェクトとして登録し、VDOをリンクします。
ケース トリガーのペイロード	トリガーを介してデータを渡します (API コネクタなど)。ペイロードフィールドはケースフィールドになります。

中央の実体が重要な理由

• タスクの独立性 — タスクはお互いについて知る必要はありません。各タスクは、入力/出力マッピングを介してエンティティとの間で読み取りと書き込みを行います。
• オーケストレーションコンテキスト — Case Manager は、エンティティフィールドに対して移行ルールを評価します。タスクがエンティティに adjusterDecision = "approve" を書き戻すと、 adjusterDecision を参照する下流のエントリ ルールがすぐに評価されます。
• 監査証跡 — エンティティに対するすべての変更は、誰が、いつ、何を変更したかで追跡されます。
• 信頼できる唯一の情報源 — どの参加者やシステムについても、事件の現在の状態について曖昧さはありません。

書き戻しパターン

書き戻しパターンは、ケース内でデータを移動するための主要なメカニズムです。

1. タスクは、 入力マッピングを介してケース エンティティから特定のフィールドを読み取ります。
2. タスクは作業 (検証、エージェントによる推論、人間によるレビュー、RPA の抽出) を実行します。
3. タスクの結果は、 出力マッピングを介してケース エンティティに書き戻されます。
4. エンティティの値が更新されると、移行ルールが再評価され、次のステージまたはタスクがアクティブ化される可能性があります。

Task A writes → Case Entity updates → Rules evaluate → Next stage activates

このパターンでは、タスクが分離された状態が維持されます。「ポリシーの検証」コネクタタスクと「写真の分析」エージェントタスクは、直接通信しません。代わりに、それぞれがエンティティをエンリッチし、ケース マネージャーはエンティティを読み取って次に何が起こるかを決定します。

注:

各フィールドが正確に 1 つのタスクで書き込まれるようにエンティティ スキーマを設計します。複数のタスクが同じフィールドに書き込むと、最後のライターが優先され、以前のデータは失われます。競合を防ぐには、名前空間フィールド ( validation.result と categorization.resultなど) を使用します。

レイヤー 3 — ケース プラン (設計時のブループリント)

ケース プランは、Studio Web で作成する視覚的な詳細計画です。ケースが通過できる 可能性のある フェーズと、移行を管理するルールを定義します。線形ワークフローとは異なり、ケースプランは単一の固定パスを規定しません。実際のパスは、データと決定に基づいて実行時に決定されます。

ケースプランは、次の4つの要素で構成されています。

• イベント トリガー — ケース インスタンスを作成または影響を与えるイベントです (レイヤー 1 で説明)。
• ステージ — ケースの名前付きフェーズです。
• タスク — 各ステージ内の作業項目。
• ルール — ステージとタスクの開始、完了、終了、および再開始を管理する WHEN/IF/ACTION の定義。

ステージ

ステージは 、ケースが通過する主要なフェーズであり、 たとえば、インテーク、 レビュー、 和解、 クローズなどです。ステージは、事実上、ケースをステージの完全なルールに向けて前進させる タスクのコレクション です。Maestro Case では、次の 2 種類のステージがサポートされています。

ステージの種類	目的	到達方法	ケースアプリケーションの表示
プライマリーステージ	ケースの予想される進行 ( 例: Intake → Review → Settlement → Closure)。	キャンバス上の前のステージの端から入力するか、設定されたエントリ ルールによって入力できます。	ケースアプリケーションタイムラインに コアステージノード として表示され、ケースワーカーが確認できるメインのライフサイクルが表示されます。
セカンダリ ステージ	例外またはいつでも発生する可能性のある代替パス ( 顧客とともに保留中、 拒否、 取り下げなど)。	入力エッジなし — セカンダリを切り替えると削除されます。エントリ ルールが true と評価された場合にのみ到達し、ケース内の任意の時点でアクティブ化できます。	アクティブになると個別に表示されます(コアタイムラインの一部ではありません)。

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

• エントリールール — ステージがアクティブになったとき。引き継ぎ動作を制御する 中断 トグルを備えています。デフォルト: プライマリ ステージ = false (並列)。二次段階= true (乗っ取り)。
• 完全なルール — 通常の終了(たとえば、必要なタスクが完了したとき)。アクションを実行します(ケースの完了/終了、手動選択の待機、原点への復帰)。
• 出口ルール — 処理を継続することが無意味な場合の早期救済。完全ルールと同じ アクション オプションを保持します。
• 再エントリルール — 再作業によってケースが以前に完了したステージに戻る方法。
• ステージ SLA とエスカレーション — 期限時間、警告のしきい値、エスカレーションの受信者。

ステージは、 必須 または オプションとしてマークできます。必要なすべてのステージが完了するまで、ケースを閉じることはできません。省略可能なステージは、エントリ ルールが満たされた場合にのみアクティブになり、エントリ ルールなしでケースをクローズできます。

同じケースで複数のステージを同時にアクティブにすることができます。ステージを並行して実行するか、順番に実行するかは、エントリルールとその中断トグルによって制御されます。

タスク

タスクは、ステージ内の個別の作業単位です。各タスクには、作業の実行方法を決定するタイプがあります。

タスクの種類	機能
人間のアクション	ケースアプリケーションのユーザにフォーム、承認、またはレビューを提示します。
AI エージェント (UiPath)	UiPath AI エージェントを呼び出して、データに対して自律的に推論します。
外部エージェント	UiPath の外部にあるサードパーティの AI エージェントを (API 経由などで) 呼び出します。
RPA ワークフロー	レガシ システムの UI Automation 用の UiPath Robot をトリガーします。
API ワークフロー	カスタム API 要求を介して外部システムを呼び出します。
コネクタを実行	構築済みまたはカスタムの Integration Service コネクタを介して外部システムを呼び出します。
Maestro のエージェンティック プロセス	Maestro BPMN を、独自のオーケストレーションを使用してタスクとして呼び出し、結果を親ケースに返します。
子ケース	個別のケース定義を子として生成し、 caseIDを介して親にリンクします。
Wait for Timer	期間が経過するか、目標日に達するまで一時停止します。
コネクタ イベントを待機	コネクタ経由で外部イベントが到着するまで一時停止します。

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

• 順次 — タスクはステージ内で定義された順序で実行されます。シーケンスには、展開して再結合する並列分岐を含めることができます。
• イベント ドリブン — タスクにはエントリ ルールがあり、イベントによってルールが true と評価されるたびに起動します。イベントが繰り返される場合は、複数回起動できます。
• アドホック — タスクはケースプランで定義されますが、実行時にユーザーが手動でトリガーしたときにのみ開始されます。

同じステージで複数のタスクを同時にアクティブにすることができます (順次並列分岐、シーケンスとは無関係に起動するイベント駆動型タスク、実行中の作業と並行して開始されるアドホックタスクなど)。

各タスクは以下で構成されます。

• 入力/出力 — ケース エンティティとの間でマッピングされます [近日公開]。
• 必須フラグ : 親ステージがこのタスクを待機する必要があるかどうかを決定します。
• エントリルール — イベントドリブンなタスクに必要です。シーケンシャル タスクおよびアドホック タスク (ガードとして機能する場合) では省略可能です。
• 一度だけ実行 — trueの場合、タスクはステージの再エントリ時にスキップされ、以前の出力が保持されます。 false (既定) の場合、タスクは再入力のたびに再実行され、新しい出力が生成されます。
• 割り当てとSLA — 人間の行動に対して、誰がいつ作業を行うべきか。

ルール

ルールは 、ライフサイクルの動きを制御するメカニズムです。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 つのレベルのいずれかになります。

スコープ	ルールの種類	目的
ケース (Case)	ケース完了、ケース終了	ケースを終了または終了します。
ステージ	エントリ、完了、終了、再エントリ	ステージの起動、通常の完了、早期救済、および再作業を管理します。ステージエントリールールには 中断ト グルがあります。[完了] ルールと [終了] ルールには アクション (ケースの完了/終了、手動選択の待機、原点への復帰) が含まれます。
タスク	エントリ	タスクの開始時にゲートします。イベント ドリブン タスクによってトリガー イベントが発生したときに起動したり、必要に応じて順次またはアドホックのタスクによって実行を保護したりするために使用されます。

ステージ レベルで の [終了 ] と [完了 ] の違いは重要です。[完了] ルールは、作業が正常に終了すると実行されます。終了ルールは、データの変更によって継続的な処理が不要になったときに起動し、サーキットブレーカーとして機能します。どちらの結果も、Case Manager がルールのアクションを適用し、次に何が起こるかを評価します。

レイヤー 4 — ケース マネージャー (ランタイム オーケストレーション)

ケース マネージャーは、各ケースのイベント ドリブンなオーケストレーターです。これは、ケースに到着したイベントに基づいて、ライフサイクルの決定 (次にどのステージを有効にするか、どのタスクを開始するか、ステージを早期に完了または終了するタイミング、エスカレーションするタイミング) を促進します。

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

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

ケース マネージャーがイベントを処理する方法

次のシーケンスは、ケースの有効期間を通して繰り返されます。

1. イベントの受信 時 — トリガーの起動、タスクの完了、Case エンティティ フィールドの変更、タイマー イベントまたはコネクタ イベントの到着、またはステージの遷移。
2. ルール評価 — ケースマネージャーは、 WHEN がイベントに一致し、 IF 条件 (存在する場合) が成り立つ、適用可能なすべてのケースレベル、ステージレベル、およびタスクレベルのルールを評価します。一致ルール ・アクション が適用されます (ステージのアクティブ化、ステージの完了、ステージの終了など)。
3. エージェントのフォールバック — 決定論的ルールでカバーされていない決定の場合、Case Manager エージェントはケースの状態とポリシーを推論して次のアクションを選択します。
4. 状態の更新 — ステージとタスクの遷移ケース エンティティが更新されます。新しいイベントが発行され、次のサイクルがトリガーされる可能性があります。
5. ケース完了 — ケースレベルの ケース完了 ルールまたは ケース終了 ルールが開始されると (またはエージェントがケースが完了したと判断すると)、ケースがクローズされます。

ルールとエージェントは連携します

ルールは、「査定人が承認し、金額が 50,000 ドル未満の場合、決済」という予測可能なものを対象としています。エージェントは、明確なポリシー パスのないドキュメントの欠落、エッジ ケースの不正行為パターン、または異常な条件の組み合わせなど、予測不可能な事態をカバーします。ケースマネージャは常に最初にルールを試行し、ルールが一致しない場合にのみエージェントにフォールバックします。

Case Manager エージェントの設定

Case Manager エージェントは、以下を使用して構成されます。

• モデル (エージェントを強化する LLM)。
• ユーザー プロンプト (ポリシー、制約、および動作の指示)。
• ツール (ステージの移動、エスカレーション、エンティティの更新など、エージェントが実行できるアクション)
• コンテキスト (実行履歴、タスクの結果、エンティティの変更から自動的に累積されます)。
• エスカレーション ポリシー (エージェントが自律的に動作するのではなく、人間にエスカレーションする条件)。

注:

あいまいなデータ、矛盾するポリシー、またはエージェントの権限外のシナリオが原因で、ルールも Case Manager エージェントも決定を解決できない場合、Case Manager は構成されたペルソナを介して人間にエスカレーションします。

レイヤー 5 — ランタイム エクスペリエンス

実行時には、2 つのインターフェイスによってケース データとコントロールがさまざまな対象ユーザーに公開されます。

ケースアプリケーション (ビジネスユーザー向け)

ケースアプリケーションは、ケースワーカーとケースマネージャーがライブケースインスタンスを操作するビジネスユーザ向けのワークスペースです。それは表面的にします:

• ケースリスト — ステータス、優先度、SLA インジケーター (順調、リスクあり、違反) を含むすべてのケースインスタンスのフィルタリング可能なビュー。
• ケース詳細ビュー — 現在のステージ、ケースのエンティティ データ、タスクのステータス、イベントのタイムライン、完全な監査証跡です。
• タスク受信トレイ (自分の仕事) — アクションを待っている保留中の人間のタスク (フォーム、承認、レビュー)
• クイックアクション — 役割と現在のステージに基づいてコンテキストに応じたアクション (完了、再開、再割り当て、エスカレーション、メモの追加)

Case App には、 すぐに使えるケース アプリ (Maestro Case に付属する既製のノーコード ワークスペース) と 、カスタムのコード化されたケース アプリ (プロコードの TypeScript SDK で構築され、オーダーメイドのビューとワークフロー用に構築) の 2 つのオプションがあります。すぐに使えるこのアプリは設計時に設定可能です。Studio Web で、Maestro の [ケースの設定] から [ ケース アプリを設定 ] を選択して、ケースのタイトルとケースの詳細のレイアウトを定義します。

1 つのケースプラン定義で、ライフサイクルのそれぞれ異なる時点にある何千もの個別のケースインスタンスを処理するケースアプリケーションが生成されます。

ケース インスタンス管理 (オペレーター向け)

ケース インスタンス管理 は Maestro のオペレーション コンソールです。プロセス オペレーターは、実行中のすべてのケースの健全性を監視し、問題が発生したときに介入します。

オペレーターのアクション	説明
一時停止	実行中のケースを一時的に停止します。SLA タイマーが一時停止します。再開されるまでタスクはアクティブ化されません。
再開	一時停止したケースを再開します。SLA タイマーは、停止した場所から再開します。
キャンセル	ケースを永続的に終了する。実行中のタスクはすべて停止します。
移行	修正または更新後にライブケースインスタンスをケースプランの新しいバージョンに移動し、現在の状態とデータを保持します。
リトライ	失敗したタスクまたは遷移を再実行して、一時的なエラーから回復します。

ケースがエラー状態 (タスクの失敗、統合のタイムアウト、ケースのスタック) になると、 ケース インシデントになります。オペレータは、インスタンス管理コンソールを使用して、上記のアクションでインシデントを診断および解決します。

注:

• ケースアプリケーションは、個々のケースで作業する ビジネスユーザ (ケースワーカー、マネージャ) 向けです。
• ケースインスタンス管理は、システムの健全性を監視し、問題が発生した場合に介入する プロセスオペレーター 向けです。

データをエンドツーエンドで追跡する: チュートリアル

ライフサイクルを具体的にするために、財産保険請求のケースを考えてみましょう。

1. イベント トリガーが起動します。Home Claims Data Fabric エンティティに新しい行が作成されます。トリガーは、エンティティ フィールド (保険証券番号、請求者名、損失の説明) をケース エンティティ [近日公開 ] にマッピングし、キー HO-1234を持つケース インスタンスを作成します。

2. Case Manager は第 1 ステージをアクティブ化します。[取り込み] のエントリ ルールは、true (イベントが到着したとき) CaseCreated評価されます。ステージがアクティブになります。

3. タスクはインテーク内で実行されます。抽出タスク (AI エージェント) は、要求の詳細を処理します。ルックアップタスク(コネクタを実行)はポリシーを検証します。異常検出エージェントは、過去の要求をチェックします。各タスクは、結果をケース エンティティに書き込みます。

4. インテークが完了し、レビューが有効になります。必要なすべての取り込みタスクが完了して validationPassed == trueすると、取り込み 完了 ルールが起動します。ケースマネージャーは、次のステージのエントリルールを評価し、 レビューを有効にします。

5. タスクの実行を確認します。カバレッジチェックコネクタ、人間の請求担当者の検証タスク、および監査エージェントによって出力が生成されます。請求担当者は、 decision = "Approve" をエンティティに書き戻します。

6. レビュー時の条件付きルーティング。[確認]、[完了]、および [終了] ルールは、decisionフィールドを評価します。"Approve"すると、完了ルールが適用され、ケースは和解に移ります。"Reject"すると、終了ルールが起動し、ケースが第 2 の拒否ステージにルーティングされます。"Claim is missing key incident reports"の場合、再エントリルールはケースをインテークに送り返し、runOnlyOnceがfalseタスク(インシデントレポートロボットや異常エージェントなど)のみを再実行します。

7. 決済タスクが実行されます。フルフィルメントプロセス、決済プロセス、およびコミュニケーションエージェントが支払いと通知を処理します。それぞれがエンティティに書き戻します。

8. ケースは終了します。必要なすべてのステージが完了すると、ケースは最終状態になります。完全な監査証跡 (すべてのタスクの実行、エンティティの変更、決定、タイムスタンプ) が保持されます。

9. ライフサイクル全体を通じて、ケースワーカーはケースアプリケーションの [私の仕事 ] 受信トレイで割り当てられた ToDo を表示します。ケース マネージャーは、ポートフォリオの監視、タスクの再割り当て、エスカレーションの処理を行います。オペレータは、ケースインスタンス管理コンソールでインシデントを監視します。

ライフサイクル全体にわたる SLA とエスカレーション

SLA は、ライフサイクルに時間ディメンションを追加します。

SLA レベル	スコープ	例
ケースレベルの SLA	作成からクローズまでの全体目標。	48時間以内に解決してください。
ステージレベルの SLA	特定のステージのローカライズされた期限時間。	24時間以内にレビューを完了してください。

SLA の状態 (順調、リスクあり、違反) は、ケースアプリケーションのリストビューと詳細ビューにバッジとして表示されます。エスカレーション ルールが自動的にトリガーされます。

• リスクあり — SLA は限界に近づいています。ケースの所有者とスーパーバイザーに通知します。
• 違反 — SLA を超えています。シニア ワーカーに再配置するか、管理にエスカレーションします。
• 一時停止/再開 — SLA タイマーは自動的には一時停止されません。外部入力を待機しているケースでは、オペレーターがケース インスタンスを明示的に一時停止するまで、SLA 時間が蓄積され続けます。

ライフサイクルにおけるユーザー ロール

Maestro Case では、 ステージを意識したアクセス が強制されるため、適切なユーザーが適切なタイミングで見て行動できます。

ロール	責任
ケースワーカー	人間のタスクを完了し、アクセス権を持つステージ内の許可されたフィールドを更新します。割り当てられた作業を [マイ ワーク] に表示します。
Case Manager	ポートフォリオを監督します。再割り当て、エスカレーション、(ポリシーごとに) 再開できます。一時停止や再開などのステージレベルのアクションを実行できます。

ケースプランでは、各フェーズで、どのペルソナが 表示 でき、どのペルソナが 行動 できるか(タスクの完了、再割り当て、エスカレーション、一時停止)を定義します。タスクはステージ設定を継承しますが、担当者をさらに制限できます。

注:

完全なケースのユーザーロールとステージレベルのアクセス制御はまだ利用できません。

アーキテクチャの主要な原則

原則	説明
エージェントファースト	AI エージェントは、ステージ内のタスクワーカーとして、またケース全体をオーケストレーションする Case Manager エージェントとして、一流の参加者です。人間は、政策や判断がそれを必要とする場合にのみ介入します。
設計による非線形	再エントリルール、セカンダリステージ、イベント駆動型タスク、およびアドホックタスクにより、ケースは厳格なシーケンスではなく、データが指示するパスをたどることができます。
エンティティ中心	ケースエンティティ [近日公開] は、信頼できる唯一の情報源です。タスクは、エンティティ データのプロデューサーとコンシューマーを分離したものです。
ルールが先、エージェントが 2 番目	決定論的 CMMN ルールは、大量のハッピー パスを処理します。Case Manager エージェントは、例外とあいまいさを処理し、ルールもエージェントも決定できない場合は人間にエスカレーションします。
設計時と実行時の分離	ケース プランは、Studio Web でデザインします。ケースアプリケーションとインスタンス管理コンソールは、ビジネスユーザとオペレータが毎日使用するものです。1 つのケースプランで何千ものケースインスタンスに対応します。

関連リソース

• Maestro のコア概念 ケース — ケース キー、エンティティ、ステージ、タスク、ルール、SLA のリファレンス定義。
• ケース プラン デザイナーの概要 — Studio Web でケース プランをモデル化する方法。
• ステージルールの設定 — エントリ、完了、終了、および再エントリのルールに関する詳細なガイダンス。
• ケースアプリケーションの概要 — ビジネスユーザに表示される内容と、ケースアプリケーションレイアウトの設定方法。
• ケースインスタンス管理 — 監視、インシデント解決、ライブマイグレーションのためのオペレーターアクション。