UiPath Maestroとは？BPMNでエージェントとロボットと人を束ねる実装と導入判断

UiPath Maestroは、BPMNで描いた業務プロセスの図をそのまま実行エンジンとして動かし、AIエージェント・ロボット・人の作業を1本の流れとして走らせる基盤です。Orchestratorが「どのロボットにどのジョブを割り当てるか」を管理するのに対し、Maestroが管理するのは「その業務の1件が今どこまで進んでいるか」になります。この記事では両者の分界、Service taskの実行対象、実行時に使えないBPMN要素、セルフホストの基盤要件、消費単位を2026年8月時点の公式ドキュメントで実測して整理しました。

まとめ：Maestroを入れる条件とOrchestratorだけで足りる場面

判断の分岐は、AIエージェントを使うかどうかではありません。1件の業務が複数のシステムをまたぎ、途中で人の判断を挟んで数時間から数日そこに留まるかどうかで決まります。この形なら、進捗を1件単位で追える実行基盤が要ります。

逆に、1つのシステムの中で完結し、数分で終わる定型処理なら、Maestroを重ねる意味は薄いはずです。Orchestratorのキューとトランザクションで、失敗した件の再実行まで回せます。図を別レイヤーで持つ分、設計物と運用対象が増えるだけになります。

入れると決めたら、最初に確かめるのは描きたいフローが実行時のサポート範囲に収まるかどうかです。BPMN 2.0の記法にはSignalやCompensationのように実行できない要素があり、知らずに設計を進めるとやり直しになります。以降、分界・タスク種別・非対応要素・提供形態・消費単位の順に見ていきます。

MaestroとOrchestratorの分界：プロセス管理層とジョブ管理層の役割

Maestroの説明が分かりにくいのは、Orchestratorも「オーケストレーション」を名乗るからです。同じ言葉で違う対象を指すため、管理単位を突き合わせると整理できます。

Orchestratorが持つ資源とMaestroが持つプロセスインスタンスの違い

公式ドキュメントでは、Orchestratorの担当は実装段階のロボット・キュー・トリガーの管理と、運用段階のスケジューリング・アセット管理と書かれています。扱う単位はジョブ、つまり「1本のワークフローの1回の実行」です。キューやアセット、フォルダー権限といった設定単位はUiPath Orchestratorとは？キュー・権限設計とロボット集中管理の導入判断で扱っています。

対してMaestroの単位はプロセスインスタンスです。受注1件、申請1件といった業務の1件がインスタンスとして生成され、どのタスクまで進んだか、どの分岐に入ったか、どこで止まっているかを保持します。1つのインスタンスの中でOrchestratorのジョブが3本走り、人のアクションが2回挟まる、といった構造になります。

この違いは運用画面にそのまま出ます。Orchestratorで見えるのは「ジョブ12件が失敗」、Maestroで見えるのは「申請番号A-1042が承認待ちで36時間滞留」という単位です。前者は再実行の判断に、後者は詰まりの発見に使います。製品全体の三層構成はUiPathとは？三層構成・ライセンス・LTS運用から導入判断までで整理しました。

BPMNモデルが設計図と実行エンジンを兼ねる構造と運用上の制約

Maestroの中心にあるのは、描いたBPMN図がそのまま実行されるという構造です。業務部門のフロー図と開発側のワークフローが別物になり、図だけが更新されず実態と乖離していく、という従来の状態が原理的に起きません。

ただし、これは制約でもあります。図を書き換えれば業務の挙動が変わるため、業務部門が気軽に線を引き直せる状態にすると本番の処理順が意図せず変わります。2026年5月にProcess RepositoryがAutomation Hub内で一般提供となり、BPMNモデリングエディタとバージョン管理、共同コメントが揃いました。設計の議論はこちらで回し、実行対象への反映は承認を通す運用が安全です。

なお、BPMN以外にも開発者向けのFlowと、長期実行の例外対応に向いたCase Managementがあり、ビジネスルールはDMNで別建てにできます。製品非依存の概念としてのエージェント連携はエージェンティックオートメーションとは？RPA・AIエージェントとの違いと導入判断にまとめました。自社の業務が対象になるかを先に判断したい場合はそちらを参照してください。

BPMNタスク種別の使い分け：エージェント・ロボット・人の呼び分け

Maestroの実装作業は、BPMNのタスク要素に「何を呼ぶか」を割り当てる作業です。ここが分かると実装の見通しが立ちます。

Service taskで選べる実行対象と子ジョブがOrchestratorで走る構造

Service taskは、プロセスエンジンの外側の処理を起動して完了を待つタスクです。2026年8月時点で選べる実行対象は次の10種になります。

• RPA workflow：Orchestratorへ発行済みの無人処理
• Agent：UiPathテナント上のエージェント
• External agent：外部でホストするエージェント
• External workflow：外部システム側のワークフロー
• API workflow：APIファーストのワークフロー
• Agentic process：別のMaestroプロセスの呼び出し
• Business rule：DMNのデシジョン実行
• Queue items：Orchestratorのキューへの投入・取得
• Connector activity：コネクタの動作
• Script：スクリプトの実行

実装で押さえておきたいのは、Start and wait for RPA workflow と Start and wait for agent を選んだとき、子側は別のOrchestratorジョブとして走る点です。既定ではデプロイ先フォルダーで空いているIDが使われます。特定のアカウントやマシンで実行させたい場合は、MaestroプロセスのPackage Requirementsタブ内にあるExecution settingsで指定してください。資格情報がマシンに紐づく構成では、この指定を省くと実行のたびに違う端末へ飛びます。

もう1つ、Orchestrator側の挙動で注意が要ります。Maestroプロセスから使うキュートリガーは、最初のジョブ起動に必要な件数が1件、追加ジョブ1本あたりの件数も1件に読み取り専用で固定されます。通常のRPA運用でよく使う「100件溜まったら起動」というまとめ処理の設定は、Maestro配下では効きません。1件=1インスタンスが前提のためです。

人の承認を挟むUser taskとhitlTask出力変数の受け取り方

人の判断を挟む箇所には、Create action app taskを割り当てます。実行時にUiPath Action Center上へタスクが作られ、担当者が入力または承認を行うまでインスタンスはそこで待機する挙動です。待機中もインスタンスは生きているため、滞留時間の計測対象になります。

2026年5月の更新で、Human-in-the-Loopタスクの完了時に応答内容の全体をhitlTask出力変数として受け取れるようになりました。差し戻し理由やコメントを後続の分岐条件に使いたい設計では、この変数から取り出します。人が待つ箇所を図に置くか外側の運用で受けるかは設計判断で、図に置けば滞留が数字で見える代わりに、承認者へAction Centerを開いてもらう運用が要ります。

分岐条件をDMNのビジネスルールへ外出しする設計と改修時の効果

金額の閾値や取引先の区分といった分岐条件をBPMN図のゲートウェイに直接書き込むと、条件が変わるたびに図の改版が要ります。Maestroでは、この条件をDMNのデシジョンとして切り出し、Business rule taskから呼べます。

効いてくるのは改修のときです。「50万円以上は部長承認」が「30万円以上」に変わっても、デシジョン側の表を書き換えるだけで済み、図は無改版で通ります。図を変えると実行中のインスタンスの扱いを考える必要が出るため、変更頻度の高い条件ほど外へ出す価値があります。

ただし、後述するとおりビジネスルールの実行には消費単位が発生します。変更頻度が高い条件だけを外出しし、固定的な分岐はゲートウェイに残す使い分けが現実的です。エージェント側にどこまで判断させるかは、UiPath Autopilot for everyoneとは？機能・使い方・必要ライセンスのファミリー構成と併せて切り分けてください。

BPMN 2.0の対応範囲：実行できる要素とできない要素を先に確認する

BPMN 2.0は記法としては広い仕様ですが、Maestroが実行時にサポートするのはその一部です。先に確認せずモデリングを始めると、後から書き直しになります。

実行時にサポートされるイベント・タスク・ゲートウェイの対応範囲

2026年8月時点で実行時にサポートされる要素は次のとおりです。

• イベント：None（開始）／Message（各種）／Timer（開始・中間キャッチ）／None（終了スロー）／Error（終了）／Terminate（終了）
• タスク：Undefined／User／Service／Receive／Send／Business Rule／Script／Manual
• ゲートウェイ：Exclusive／Parallel／Inclusive／Event
• その他：Multi-instance（並列・順序）／Sub-process／Call activity／Event sub-process

この範囲でも、実務で必要になるパターンはおおむね組めます。承認の分岐はExclusive、並行して2部門へ回すのはParallel、返信待ちはEvent、明細行ごとの繰り返しはMulti-instanceです。タイムアウトはTimerの中間キャッチイベントで受けられるため、「3営業日で応答が無ければ督促」も図の上で完結します。

実行時にサポートされない要素の書き換え方と設計段階で置く回避策

実行時にサポートされないのは、Signal、Conditional、Escalation、Compensation、Cancel、Link、Multiple、Complex Gateway、Loop、データオブジェクト、Pool、Lane、Transactionです。既存のBPMN資産をそのまま持ち込むと、この一覧で引っかかります。

実際に詰まりやすいのは3つです。1つ目はPoolとLaneで、担当部門をレーンで表現した既存図は実行対象になりません。担当の割り当てはUser task側のプロパティで持たせ、図はフローだけを表す形に描き直します。2つ目はCompensationとCancelで、「後続が失敗したら前段の登録を取り消す」という補償処理を記法で書けません。取り消し用のService taskを置き、Errorイベントからそこへ線を引く形に展開します。

3つ目はSignalです。1つのイベントを複数のプロセスへ同報する設計は、Messageイベントの個別送信かAgentic processの呼び出しへ置き換えてください。いずれも「記法で暗黙に表していたものを明示的なタスクとして置き直す」という同じ方向の書き換えになります。既存図の移行を見積もるときは、この手数を先に数えておくと精度が上がります。

提供形態とバージョン：Automation Cloudとセルフホストの選び分け

Maestroは当初Automation Cloud上のサービスとして提供され、その後セルフホストへ広がりました。データの持ち出し制約がある案件では、この違いが判断材料になります。

Automation Suite 2.2510.2でのセルフホスト提供と基盤要件

2026年4月15日にリリースされたAutomation Suite 2.2510.2から、Maestroをセルフホストで導入できるようになりました。対応する基盤はEKS/AKSまたはOpenShiftで、すでにKubernetes上でAutomation Suiteを運用している構成へ載せる形になります。

要件として押さえておきたいのは、Temporal as a Service（TaaS）を含むクラスタ・ノード要件が別途ある点です。Maestroは長期実行のインスタンスを保持するため、ワークフロー実行基盤を追加で必要とします。既存のAutomation Suite環境へノードの追加なしで有効化できるとは限りません。オンプレミス前提の見積もりでは、この基盤分のリソースを最初から含めてください。

2026年に入って追加された機能のうち設計判断に効いてくる変更点

2026年に入ってからの更新のうち、設計判断に効くものを挙げます。4月はData Fabricのクエリでqem:プレフィックスが使えるようになり、条件に合致するレコードを最大1,000件の配列として受け取れます。5月はProcess Repositoryの一般提供とNotification Service taskの追加、6月はUiPath Functions（Python）のプレビュー提供です。プレビュー段階の機能は本番前提で組み込まず、着手時点で当該版のリリースノートを確認してください。

機能が届く時期の差も判断材料です。Automation Cloud側は毎月の更新で機能が入り、コミュニティ向けの公開から企業向けの反映までは3日以上の間隔が置かれます。セルフホスト側は版単位の提供です。

コスト構造：Platform Unitはプロセスインスタンス単位で減っていく

Maestroの費用感は、ライセンス本数ではなく処理件数で決まります。この構造を外して試算すると、実運用で想定と乖離します。

1インスタンス1単位・ビジネスルール0.2単位という消費の内訳

前提として、Maestroの利用にはPlatform license、User license、Consumption licenseの3種が全プラン共通で必要です。Unified Pricingでの消費は次のように定義されています。

デバッグがPlatform UnitもAgent Unitも消費しない扱いは、開発フェーズの費用を読むうえで効きます。費用をかけずに試せる範囲そのものはUiPath Community Editionとは？無償枠の中身・商用利用の条件・有償へ移る境界に整理しており、Communityプランではフロー実行が月10,000回まで（プレビュー扱い）という上限が置かれています。設計と検証の反復では単位が減らず、本番でインスタンスが生成された時点から消費が始まる構造です。Process Miningと連携して「Maestro + external data」を使う場合は10,000イベントの無料枠が付きます。

気をつけたいのはビジネスルールの0.2という係数です。1インスタンスあたり5回デシジョンを呼べば、それだけでインスタンス本体と同額の1 Platform Unitが乗ります。前章の「変更頻度の高い条件だけを外出しする」という方針には、費用面からも裏づけがあります。

月間処理件数から必要な単位数を見積もる手順と外部委託の判断基準

見積もりの手順は単純です。月間件数を数え、1件を1インスタンスとして換算し、デシジョン呼び出し回数×0.2を足します。月1,000件の申請でデシジョンを平均3回呼ぶなら、1,000＋1,000×3×0.2＝1,600 Platform Unitが目安です。再実行やテスト投入分は別途上乗せしてください。

判断が要るのは、その件数がRPA単体の運用と比べて割に合うかです。ライセンス種別と割当単位はUiPathの料金・ライセンス｜種別と割当単位・本数見積もりで整理しました。ロボット本数側の費用と並べると全体像が掴めます。

件数の想定が立たない、既存のRPA資産をどこまで載せ替えるかが決めきれないという段階なら、業務プロセスの棚卸しから一緒に設計するほうが手戻りは少なくなります。当社ではRPA×AIエージェント連携（インテリジェントオートメーション）として、既存ロボットとエージェントの役割分担の設計から実装まで対応しています。対象業務の絞り込み段階からご相談ください。

Maestroを採用する条件と、Orchestratorのキューで足りる場面

ここまでの内容を導入判断の形に落とします。機能の多寡ではなく対象業務の形で決めてください。

採用に踏み切ってよい3条件：システム跨ぎ・長期滞留・人の判断の混在

採用してよいのは、次の3つが同時に成り立つ業務です。1つ目は、1件の処理が2つ以上のシステムをまたぐこと。基幹システムへの登録とSaaS側の更新、文書生成が連なるような流れを指します。2つ目は、1件が数時間から数日そこに留まること。承認待ち、外部からの返信待ち、締め日待ちのような滞留です。

3つ目は、途中に人の判断が混じることです。すべて機械で完結するなら1本のワークフローで書けますが、人が入ると待機と再開の管理が要り、そこがMaestroの担当範囲になります。この3条件が揃うと、Orchestratorのジョブ単位の管理では「今この申請がどこで止まっているか」に答えられません。

逆に言えば、AIエージェントを使うかどうかは採用条件ではありません。1つも使わない構成でも、システム跨ぎと滞留と人の判断が揃えばMaestroは働きます。ここを混同すると、エージェントの精度検証に時間を取られて本来の効果が測れません。

見送ってよい場面：単一システム完結と例外の少ない定型処理の扱い

見送ってよいのは、次のいずれかに当てはまる場合です。第一に、1つのシステムの中だけで完結し、数分で終わる処理。日次のデータ取り込みや帳票出力がこれにあたり、キューとトランザクションで再実行まで管理できます。第二に、例外がほとんど出ず、失敗したらやり直せば済む処理です。

第三に、既存のBPMN資産がPoolやLane、Compensationを前提に描かれ、書き直しの工数が導入効果を上回る場合です。まず対象を1業務に絞り、非対応要素の置き直しを一度やってみてから範囲を広げてください。

迷ったときの目安は「この業務の滞留時間を誰かが知りたがっているか」です。知りたい人がいるなら、可視化のためにインスタンス管理を入れる価値があります。誰も見ないなら、図を保守するコストだけが残ります。是非はこの一点で決めてください。

よくある質問

UiPath MaestroはOrchestratorの代わりになりますか？

代わりにはなりません。MaestroはOrchestratorの上に載る層で、Service taskから起動したRPAワークフローは別のOrchestratorジョブとして実行されます。ロボットの登録やマシンの割り当てはOrchestrator側に残るため、両方を持つ構成が前提だと考えてください。

Maestroを使うにはAIエージェントが必須ですか？

必須ではありません。Service taskの実行対象にはRPA workflowやAPI workflow、Queue itemsが含まれ、エージェントを1つも使わない構成でもプロセスは組めます。既存のロボット資産をBPMNの流れに配置し、人の承認を挟むだけの使い方から始めてもかまいません。エージェントは後から差し替える形で足せます。

オンプレミス環境でMaestroを動かせますか？

2026年4月15日リリースのAutomation Suite 2.2510.2から、EKS/AKSまたはOpenShift上でのセルフホスト導入に対応しました。ただしTemporal as a Service（TaaS）を含むクラスタ・ノード要件が別途あり、既存環境へリソース追加なしで有効化できるとは限りません。

既存のBPMN図をそのまま取り込めますか？

取り込める範囲は限られます。実行時にサポートされない要素としてSignal、Conditional、Escalation、Compensation、Cancel、Link、Multiple、Complex Gateway、Loop、データオブジェクト、Pool、Lane、Transactionが挙げられています。特にPoolとLaneで担当を表現した図は書き直しが必要で、担当の割り当てはタスク側のプロパティへ移してください。

費用はロボットの本数で決まりますか？

決まりません。Unified Pricingではプロセスインスタンス1件あたり1 Platform Unit、ビジネスルール実行1回あたり0.2 Platform Unitという消費で、処理件数に比例します。デバッグは消費対象外です。ロボット側のライセンス費用とは別枠のため、件数ベースと本数ベースの試算を分けて積み上げてください。

関連記事

• UiPath Orchestratorとは？キュー・権限設計とロボット集中管理：Maestroの下で動くジョブ管理層の設定単位です。
• UiPathとは？三層構成・ライセンス・LTS運用から導入判断まで：Studio・Robot・Orchestratorの全体像です。
• エージェンティックオートメーションとは？RPA・AIエージェントとの違い：製品非依存の概念と導入判断の考え方です。
• UiPath Autopilot for everyoneとは？機能・使い方・必要ライセンス：エージェント側の製品ファミリーの違いです。
• UiPathの料金・ライセンス｜種別と割当単位・本数見積もり：ロボット本数側の費用の積み上げ方です。