UiPath Maestro（旧：Agentic Orchestration） は、企業が 人間、ロボット、AIエージェント をまたいで長期間にわたる複雑なエンタープライズプロセスをオーケストレーションし、システム全体にわたって大規模に運用できるようにします。
UiPath Maestro を活用することで、企業は 業務プロセスのライフサイクル全体（モデリング、実装、監視、運用、最適化） を管理することが可能になります。
本記事では、UiPath Maestroの概要と、その基盤となる BPMN（Business Process Model and Notation） 2.0 の記法について解説します。 BPMN 2.0 の基本概念を学びつつ、UiPath での具体的な適用方法や活用例を紹介します。
📝 UiPath Maestroとは？
UiPath Maestro は、以下の3つの要素を統合することで、企業の業務プロセスを高度に自動化・最適化します。
- AI エージェント（AI Agent）：プロンプトを計画に変え、計画を実行
- ロボット（Robot）：計画を効率的かつ正確に実行
- 人間（People）：プロセスを監督し、必要に応じて介入
これらを統合し、全体の制御を取る役割を果たすのがMaestroです。UiPath Maestro は、以下の5つのフェーズで業務プロセスを管理します。
| フェーズ | 説明 | 主な対象者 |
|---|---|---|
| Model（モデリング） | 業務プロセスを BPMN などの標準表記でモデル化 | 業務プロセスオーナー |
| Implement（実装） | RPA、AIエージェントを組み合わせて実行可能なプロセスを構築 | IT部門・自動化CoE |
| Operate（運用） | 実行中のプロセスの監視、例外処理 | 運用チーム・管理者 |
| Monitor（監視） | KPI 分析、プロセスのリアルタイム監視 | 分析チーム・管理者 |
| Optimize（最適化） | ボトルネック分析、シミュレーションを実施し、業務改善を推進 | プロセス最適化チーム |
以下の画面は、UiPath Maestro を使用して 請求書の照合プロセス を実行しているものです。BPMNに基づいて、請求書の処理フローが可視化されています。
UiPath Maestroの機能の詳細を紹介する前に、その基盤となるBPMNの記法について解説します。
📝 BPMNとは？
BPMN（業務プロセスモデリング表記法） とは、業務プロセスを視覚的に表現するための標準化されたモデリング言語です。
正式名称は "Business Process Model and Notation" で、業務フローの可視化、設計、分析、最適化を目的としています。
UiPath Maestroでは、業務プロセスが BPMN でモデル化されています。以下のように、新入社員オンボーディングの業務フロー全体を図でまとめたものです。
BPMNを活用するためのツールは多数存在します。UiPath Cloudでは、Maestro（プレビュー版、2025/3/14時点）を利用して、BPMNによる業務プロセスを作成できます。
UiPath Maestroがまだ利用できない場合は、以下のツールをライセンスなしで使用し、プロセスの可視化や設計を行うことができますので、ぜひお試しください。
📝 UiPathにおけるBPMN 2.0の要素と記号
BPMN では、ビジネスプロセス図において以下の５種類の要素を用います。
🔍ご注意：
以下のBPMNの記号や名称は、UiPath Maestroに基づいたものです。他のシステムとは若干の違いが生じる可能性がありますので、ご了承ください。
| 要素 | 意味 | 用途 |
|---|---|---|
| イベント（Event） | プロセスの開始・中間・終了を示す要素 | プロセスのトリガー（開始）、条件待機（中間）、完了処理（終了）を管理する |
| タスク（Task） | 業務プロセス内の個別の作業やアクション | 具体的な業務（データ入力、メール送信、承認作業など）を実行する |
| ゲートウェイ（Gateway） | プロセスの分岐や統合を制御する要素 | 条件に応じた処理の振り分けや並行処理の開始・終了を管理する |
| データ（Data） | プロセス内で扱う情報 | タスクやイベント間でのデータのやり取りや、業務の入力・出力データを管理する |
| 参加者（Participants） | 業務プロセスに関与する個人や組織 | 役割を明確化し、タスクやデータの責任を区分する（例：営業、経理、顧客など） |
以下では、これらの個別の要素をビジネスプロセスに用いる方法を説明しています。
1️⃣ イベント（Event）
BPMNのイベントは、プロセスを開始、変更、または終了するトリガーです。開始イベントはプロセスを開始し、中間イベントはプロセス中に発生し、終了イベントはプロセスを終了します。
| 種類 | 意味 | 用途 |
|---|---|---|
| 開始イベント | プロセスを開始するイベント | プロセスのトリガー（開始条件）を定義する。例：メッセージの受信、スケジュールに基づく自動開始。 |
| 中間イベント | プロセスの途中で発生するイベント | プロセスの流れを一時停止、条件待機、通知の送信などを行う。例：一定時間待機、メッセージ受信待機。 |
| 終了イベント | プロセスを終了するイベント | プロセスの完了を示し、後続の処理を行わない。例：プロセスの正常終了、終了通知の送信。 |
また、Catch（キャッチ） と Throw（スロー） という概念があり、イベントが情報を受け取る（Catch） のか、発生させる（Throw） のかを区別します。
| 種類 | 意味 | 用途 |
|---|---|---|
| キャッチ | 何かを「待つ」イベント | 条件が満たされるまでプロセスを一時停止し、条件が発生すると処理を進める。例：メッセージの受信待機、タイマーの時間待機、条件成立待ち。 |
| スロー | 何かを「発生させる」イベント | メッセージやシグナルを送信し、他のシステムやプロセスに通知を行う。例：メッセージの送信、エラーの発生、プロセスの終了。 |
イベントには、メッセージ、タイマーと日付、トランザクション、エラー、エスカレーション、リクエストなどがあります。
よく使われるイベントは以下の通りです。
開始イベント（Start Events）
プロセスの開始を示すイベントです。
| イベント名 | 種類 | 説明 | 用途 |
|---|---|---|---|
| 開始 イベント | キャッチ | プロセスを開始する一般的なイベント | 条件なしに業務プロセスを開始する |
| メッセージ開始 イベント | キャッチ | メッセージを受信したらプロセスを開始する | 外部システムや他のプロセスからのトリガーを待機 |
| タイマー開始 イベント | キャッチ | 指定した時間やスケジュールでプロセスを開始する | 定期的な業務開始（例：毎日9時にレポート生成） |
| 条件付き開始 イベント | キャッチ | 条件が満たされたときにプロセスを開始する | 事前設定された条件を満たしたら処理開始（例：在庫数が一定以下になったら発注） |
中間イベント（Intermediate Events）
プロセスの途中で発生するイベントです。
| イベント名 | 種類 | 説明 | 用途 |
|---|---|---|---|
| メッセージ中間キャッチ イベント | キャッチ | メッセージを受信すると処理を進める | 外部システムや別プロセスからのメッセージを待機 |
| 中間 イベント | スロー | 一般的な中間イベント。特定のアクションなし | プロセス内の一時停止や制御用のマーカー |
| メッセージ中間スロー イベント | スロー | メッセージを送信し、他のプロセスやシステムに通知 | 別のシステムやプロセスにイベントを伝える（例：注文完了通知を送信） |
| タイマー中間キャッチ イベント | キャッチ | 指定された時間が経過したら処理を進める | 一定時間の待機後にタスクを実行（例：30分後に自動返信） |
| 条件付き中間キャッチイベント | キャッチ | 条件が満たされると処理を進める | 事前設定された条件を満たしたら次のステップへ進む |
終了イベント（End Events）
プロセスの終了を示すイベントです。
| イベント名 | 種類 | 説明 | 用途 |
|---|---|---|---|
| 終了 イベント | スロー | プロセスを終了する一般的なイベント | 正常終了のマーカー |
| メッセージ終了 イベント | スロー | メッセージを送信してプロセスを終了する | 外部システムや他のプロセスへ終了通知を送る |
2️⃣ タスク（Task）
人の作業やITシステムの処理を表すアクティビティにはタスクとサブプロセスの２種類があります。UiPath Maestroでは、サブプロセスもタスクに分類されています。
以下がUiPath Maestroで利用できるタスク一覧です。
| タスク名 | 意味 | 用途 | 補足 |
|---|---|---|---|
| タスク | 基本的な作業単位 | 汎用的なアクション（例：データ入力） | 詳細な分類が必要ない場合に使用 |
| ユーザータスク | 人間がシステムを介して実行 | 例：承認申請、フォーム入力 | システムUI操作が必要な作業 |
| 手動タスク | システムを介さない人間作業 | 例：機械の物理的メンテナンス | 進捗をシステムで追跡できない |
| サービスタスク | 外部システムが自動実行 | 例：API呼び出し、DB更新 | コード/Webサービス連携が必要 |
| スクリプトタスク | 内部スクリプトの実行 | 例：データ変換、計算処理 | プロセスエンジン内で完結 |
| ビジネスルールタスク | ルールエンジンによる判定 | 例：与信審査、割引率決定 | DMN（Decision Model and Notation）と連携 |
| コールアクティビティ | 別プロセスを呼び出し | 例：共通処理の再利用 | 親プロセスとサブプロセスの連動が必要 |
| サブプロセス | 内部に詳細フローを含むタスク | 例：注文処理の詳細ステップ | 折りたたみ（⚪）と展開（⚪+内部フロー）で表現 |
| トランザクション | 原子性のある処理グループ | 例：支払いと在庫更新の一括処理 | 補償イベントでロールバック可能 |
| 送信/受信タスク | 非標準タスク（注意） | 例：メール送信/受信 | BPMN標準ではメッセージイベントで表現すべき |
3️⃣ ゲートウェイ（Gateway）
ゲートウェイは、ビジネス・プロセスをさらに進める前に選択を行う必要がある意思決定ポイントです。
UiPath Maestroには、以下の五つ種類のゲートウェイがあります。
詳細な意味と用途は以下の通りです。
| ゲートウェイ名 | 意味 | 用途 | 補足 |
|---|---|---|---|
|
排他的ゲートウェイ (XOR) |
条件に応じて1つの経路のみを選択 | XOR条件。 （例：顧客の購入額が一定以上なら割引適用、それ以外は通常価格） |
デフォルト経路を設定可能 |
|
並列ゲートウェイ (AND) |
全経路を同時に実行 | AND条件。 （例：書類作成と承認プロセスの並行実行後、両方が完了して次へ進む） |
開始時と終了時のペアで使用 |
|
包括的ゲートウェイ (OR) |
1つ以上の経路を条件に応じて選択 | OR条件。 （例：注文金額が5,000円以上「送料無料」、会員ステータスがプラチナなら「特別割引」、クーポン使用なら「クーポン割引」 |
全条件を評価し、該当経路をすべて実行 |
| イベントベースのゲートウェイ | 発生したイベントで経路を決定 | （例：顧客からの「承諾」メッセージか「拒否」メッセージのどちらが先に到着したかで分岐） | データ条件ではなくイベント待機が特徴 |
| 複雑なゲートウェイ | 数式やルールで経路を制御 | （例：「A部門とB部門の両方の承認がある、かつ予算内」の場合のみ経路許可） | 実務では代替手段推奨（可読性低下のため） |
排他的ゲートウェイ
排他的ゲートウェイはビジネスプロセスを評価して、フローを2つあるいはそれ以上の相互に排他的なコースに導き、そのフローを正確にアウトプットの支流に行かせます。
特徴：
- 1つの経路のみ選択（条件に合致する最初のパスを実行）
- デフォルト経路（条件未設定）を設定可能
- 分岐と合流の両方で使用（合流時は無条件で進む）
用途：
- 条件分岐（例：YES/NO判定）
- 例外処理の分岐（例：エラー発生時のみ特定フローへ）
例えば、以下のオンライン決済プロセス：
判定ルール：
| 支払いリクエスト | 即時決済 | エラー通知 | 保留フラグ設定 |
|---|---|---|---|
| 残高充足 | ✅ | ❌ | ❌ |
| 残高不足 | ❌ | ✅ | ❌ |
| デフォルト | ❌ | ❌ | ✅ |
UiPathのMaestroを用いて、上記のプロセスを可視化します。
上記のオンライン決済の分岐ゲートウェイでは、以下のように、条件を設定して分岐させます。
並列ゲートウェイ
並列ゲートウェイはビジネスプロセスを分割し、すべての経路を同時に実行するための分岐点です。フローを複数の並行的なコースに展開し、すべてのアクティビティが完了後に同期化します。
特徴：
-
全経路を同時実行（AND条件）
分岐時は条件を設定せず、すべてのパスが必ず実行されます。 -
開始時（分岐）と終了時（合流）のペアが必須
単独で使用できず、分岐後に必ず合流用の並列ゲートウェイを配置します。 -
合流時は全経路の完了を待機
いずれかのパスが遅延しても、すべての処理が終わるまで次のステップに進みません。
例えば、以下の契約書作成プロセスプロセス：
判定ルール：
| 契約条件確定 | 法務チームが書類作成 | 経理チームが費用計算 | 営業が顧客確認 |
|---|---|---|---|
| A社との契約 | ✅ | ✅ | ✅ |
UiPathのMaestroを用いて、上記のプロセスを可視化します。
包括的ゲートウェイ
包括的ゲートウェイはビジネスプロセスを評価して、フローを1つ以上の条件に合致する複数のコースに動的に導き、実行時に有効な経路をすべて実行します。
特徴：
- 複数の経路を選択可能（条件を満たす全パスを実行）
- 条件の独立性（各経路の条件は排他的でなく、複数が同時に成立し得る）
- 分岐と合流の両方で使用（合流時はアクティブな全経路の完了を待機）
例えば、以下のECサイトの注文処理プロセスプロセス：
判定ルール：
| 注文タイプ | 送料無料を適用 | 10%割引を適用 | 追加5%オフを適用 |
|---|---|---|---|
| 10000円以上・ゴールド・クーポン有効 | ✅ | ✅ | ✅ |
| ゴールド・クーポン有効 | ❌ | ✅ | ✅ |
| 10000円以上・クーポン有効 | ✅ | ❌ | ✅ |
| ゴールド | ❌ | ✅ | ❌ |
UiPathのMaestroを用いて、上記のプロセスを可視化します。
上記の金額確定の分岐ゲートウェイでは、以下のように、条件を設定して分岐させます。
イベントベースのゲートウェイ
イベントベースのゲートウェイはビジネスプロセスを中断し、外部イベントの発生を待機して、最初に発生したイベントに対応する経路を選択します。
特徴：
- イベントトリガーで経路決定（データ条件ではなく、メッセージ/タイマー/エスカレーションなどのイベントを監視）
- 分岐のみで使用（合流時は排他的ゲートウェイやイベントで処理）
- 非同期処理向け（例：顧客応答待ち、システム間連携）
例えば、以下の顧客サポートプロセスプロセス：
UiPathのMaestroを用いて、上記のプロセスを可視化します。
上記可視化には三つのイベントがあります：
- メール返信（メッセージキャッチイベント）：ユーザーの問い合わせに対して、サポート担当者がメールで返信する場合に使用。
- チャット接続（メッセージキャッチイベント）：問い合わせを受けた後、リアルタイムでのチャット対応が発生する場合に使用。
- 72時間経過（タイマーキャッチイベント）：72時間（3日間）経過した場合に自動的に問い合わせをクローズする場合に使用。
複雑なゲートウェイ
複雑なゲートウェイ（Complex Gateway）は、複雑なプロセスを制御するために使用されるゲートウェイです。
単純な排他的（XOR）、包括的（OR）、並列（AND）ゲートウェイでは表現できない、より柔軟で高度なルールに基づいた分岐を制御します。
しかし、可読性・保守性・実装のしやすさを考慮すると、基本的には「排他的（XOR）、包括的（OR）、並列（AND）ゲートウェイを優先するべき」とされています。複雑なゲートウェイを使わなくても、XOR, OR, ANDを組み合わせることで解決できることが多いです。
本記事では、複雑なゲートウェイの詳細な解説は割愛し、より一般的なゲートウェイ（XOR, AND, OR）に焦点を当てます。
BPMNゲートウェイの比較表（設計時の判断基準）
以下は、BPMNの主要なゲートウェイ（排他的、並列、包括的、イベントベース）を比較した表です。設計時の判断基準としてご活用ください。
| 特徴 | 排他的ゲートウェイ（XOR） | 並列ゲートウェイ（AND） | 包括的ゲートウェイ（OR） | イベントベースのゲートウェイ |
|---|---|---|---|---|
| 分岐の性質 | 1つの経路のみ選択 | すべての経路を同時実行 | 1つ以上の経路を選択可能 | どのイベントが発生するかで経路を決定 |
| 条件評価 | 最初に成立した条件のみ適用 | 条件なしで全経路を実行 | すべての条件を評価し、該当する経路を並行実行 | 最初に発生したイベントに対応する経路を選択 |
| 合流動作 | 合流時に即時進行（待機不要） | すべての経路が完了するまで待機 | アクティブな経路の完了を待機 | 通常は排他的ゲートウェイで合流 |
| デフォルト経路 | 設定可能（条件がすべて満たされない場合の保険） | 不要（すべて実行） | 通常は設定しない（特定条件の優先をしないため） | 不要（イベントの発生に依存） |
| 最適用途 | YES/NO型の単純な分岐 | 並行処理が必須なフロー | 複数の条件が成立する可能性がある処理 | 外部イベントの応答待ち（非同期処理） |
| 分岐と合流の関係 | 合流が不要な場合もあるが、制御のために使われることが多い | 分岐と合流が必ずセットで必要 | 合流が必要になるケースがある | 特定のイベントが発生しない場合、フローの継続に考慮が必要 |
| エラーハンドリング | デフォルト経路なしで、条件が成立しないとフローが停止する | 一部のタスクが完了しないとプロセスが滞留する可能性がある | すべての条件が満たされない場合、未処理の経路が発生する可能性 | タイムアウト処理を適切に設計しないと、イベント待機でフローが進まなくなる |
4️⃣ データ
BPMNにおけるデータは、タスクやイベント間のデータや書類の受渡しを明確にするために、データストアやデータオブジェクトなどの図形で表現されます。
標準のBPMN 2.0では「データ入力（Data Input）」や「データ出力（Data Output）」も存在しますが、UiPath Maestroでは、データの表現がBPMNよりもシンプルになっており、「データストア（Data Store）」と「データオブジェクト（Data Object）」の2つのみが使用されます。
そのため、データ入力やデータ出力は、明示的な要素としては存在せず、データオブジェクトで代用されます。
データの定義
データストアはプロセスが終了しても保持されるデータに適用され、データオブジェクトはプロセス内での一時的なデータ管理に使用される。
| データ要素 | 説明 | 用途 |
|---|---|---|
| データストア（Data Store） | 永続的に保存され、プロセス間で共有されるデータ（データベース、ファイルシステム、クラウドストレージ） | プロセス全体で共有されるデータや、長期的に保持する必要がある情報を管理（顧客情報DB、在庫管理システム） |
| データオブジェクト（Data Object） | プロセス内で利用・更新される一時的なデータ（例：注文書、請求書、タスクの入力データ） | タスク間で引き継がれる情報や、一時的な計算結果を保持（例: 注文データ、承認結果、エラーメッセージ） |
データの使い分け
データオブジェクトはプロセス実行中の一時的なデータ管理に適し、データストアはプロセス終了後も保持され、異なるプロセス間で共有される長期保存向けのデータ管理に適しています。
詳細な使い分けと用途例は以下の通りです。
- 使い分け：
| 項目 | データオブジェクト | データストア |
|---|---|---|
| ライフサイクル | プロセス実行中のみ存在 | プロセス終了後も保持される |
| データの範囲 | プロセス内でのみ利用 | 異なるプロセス間で共有可能 |
| データの保存方法 | ワークフロー実行時の一時データ | データベースやクラウドストレージに保存 |
| 適用例 | 請求書作成プロセスの一時データ | 顧客情報、注文履歴など長期保存が必要なデータ |
- 用途例：
| 用途 | データオブジェクト | データストア |
|---|---|---|
| プロセス実行中のデータの一時保存 | ✅ | ❌ |
| プロセス終了後も保持されるデータ | ❌ | ✅ |
| 異なるプロセス間でデータを共有 | ❌ | ✅ |
| データの更新と削除が可能 | ✅ | ✅ |
| ワークフロー内でのデータ参照・利用 | ✅ | ✅ |
顧客サポート対応プロセスの可視化
例えば、以下の顧客サポート対応があります。
- サポート依頼受付(サポート窓口): 顧客からの依頼を受け、不具合調査依頼を作成し、技術チームに共有。
- 不具合調査(技術チーム): 技術チームが調査を実施し、調査結果を長期保存・サポート窓口に共有。
このプロセスでは、不具合調査の進行中は調査依頼表（データオブジェクト） が用いられ、調査完了後は調査結果を不具合データベース（データストア） に保存されます。
UiPathのMaestroを用いて、上記のプロセスを可視化します。
⚠️ご注意：
UiPath Maestroはまだプレビュー版であり、上記の参加者（サポート窓口...）や業務名（サポートセンター）の表示に不具合があります。次のバージョンでの修正を予定しています。
5️⃣ 参加者
UiPathのMaestroにおける参加者（Participants）は、BPMNのプール（Pool）とレーン（Lane）を統合した概念で、プロセス内の異なる役割や組織単位を明確に表現するために使用されます。
UiPath Maestroでは、参加者のアイコンは以下のとおりです。
UiPath Maestro における「参加者（Participant）」のレイアウトを示しているもの です。
- Pool（プール） に 複数の Lane（レーン） が配置されていることが分かります。
- それぞれの Lane は、異なる役割（例：部門・チーム・システム）を表し、プロセスの担当範囲を視覚的に整理するために使用されます。
BPMNのプール（Pool）の説明
プール（Pool） は、ビジネスプロセス全体を包む区画を示します。
通常、組織・部門・システムなどの単位を表現 し、プロセスの範囲を明確にするために使用されます。
主な用途：
- 組織（例：企業A vs 企業B）の間のやり取りを表現
- 社内部門（例：営業 vs 技術 vs 経理）間のプロセスを整理
- 外部システムとの連携を示す（例：RPA、AI、ERPなど）
プールは、異なる組織やエンティティ間の業務のやり取りを可視化する際に役立ちます。
BPMNのレーン（Lane）の説明
レーン（Lane） は、プール内で役割や部門ごとに業務を整理・分割するための区画 です。
各レーンには、特定の役割（例：担当者、部署、チーム）が割り当てられ、業務の流れが整理されます。
主な用途：
- 部門ごとに業務を整理（例：営業・サポート・技術・経理）
- 個人ごとのタスクを分ける（例：担当者A・担当者B・担当者C）
- システム間の業務フローを整理（例：人 vs RPA vs 外部システム）
レーンを利用すると、誰がどのタスクを担当するのかを明確にできます。
BPMNのプールとレーンの使い分け
上記の説明をまとめて、プールとレーンの使い分けが以下の通りです。
| 項目 | プール（Pool） | レーン（Lane） |
|---|---|---|
| 目的 | プロセス全体 の範囲を定義 | プール内の役割や業務分担を整理 |
| 対象 | 組織・企業・外部システム | 部署・チーム・担当者 |
| 活用例 | A社とB社のやり取り、社内と外部システムの連携 | 営業・技術・サポート間の業務分割 |
BPMNでは、プールで全体の業務領域を示し、レーンで具体的な業務の担当者を整理します！
参加者（Participant）利用例
上記の顧客サポート対応プロセスの可視化例を拡張し、顧客もプロセスの可視化に含めます。
- 問い合わせ（顧客）：サポートセンターに問い合わせ
- サポート依頼受付(サポート窓口): 顧客からの依頼を受け、不具合調査依頼を作成し、技術チームに共有。
- 不具合調査(技術チーム): 技術チームが調査を実施し、調査結果を長期保存・サポート窓口に共有。
- 結果受け取りと回答（サポート窓口）：技術チームより調査結果を受け取り、顧客に回答
- 問題解決（顧客）：サポート窓口より回答を入手、問題解決になる
UiPathのMaestroを用いて、上記のプロセスを可視化します。
📌この図には 2つのプール が存在します。
-
顧客プール（最上部）
顧客の行動を表すプール であり、「サポートセンターへの問い合わせ」から「問題解決」までのプロセスが含まれています。 -
サポート業務プール（下部）
企業のサポート業務全体を表すプール で、サポート窓口・技術チーム・システム(データ管理) の各レーンに分かれています。
📌サポート業務プールの中に、3つのレーン が定義されています。
- サポート窓口（上段のレーン）
- 技術チーム（中央のレーン）
- データ管理（最下部のレーン）
これでプールとレーンを活用し、各関係者やシステムの役割が明確に示されていました。
🏁 最後に
ここまで、UiPathにおけるBPMNの要素の概念とその使い方を紹介しました。
次の記事では、実際の業務プロセスを例に、UiPath Maestroを用いたビジネス プロセスの作成方法を解説します。