ラスベガスで開催された UiPath FUSION 2026 に参加してきたのでレポを書いていきます。今回は製品基調講演「Innovation Across the UiPath Platform: What's New, What's Next」編、その前編です。
- 前編（この記事）：Raghu の問題提起 → Map of Work → UiPath Cartographer の GA → coding agent が 1時間で Maestro Case を組む デモ → UiPath for Coding Agents の GA
- 後編：業界ソリューション（Source-to-Pay）、Test Cloud の「ダークファクトリー」、AI ネイティブな自動化機会の発見
目次
- 最も難しい問題は AI モデルの選択じゃない！！
- Map of Work って何それ？！
- Map の始め方は3つ。ゼロからは（ほぼ）無い
- Cartographer デモ：保証対応の Map を 45% → 68% → 実装へ
- Cartographer、GA 来ました！！
- coding agent が Maestro Case を1時間で組んだ。ヤバすぎる！！
- UiPath for Coding Agents も GA！！
- 人の判断が資産になる：Decision Ledger で 93% → 96%
- 前編で発表された機能まとめ
- おわりに
最も難しい問題は AI モデルの選択じゃない！！
Raghu が最初に出した一枚がこれ。
「AI モデルはかつてないほど優秀で、毎年賢くなっている。それなのに、企業の AI 投資の多くは止まったままだ」
これ、皆さんも身に覚えありませんか？ PoC は動く、モデルは賢い、でも本番に載らない。
Raghu の答えはシンプルで、モデルは自社のビジネスがどう動いているかを何も知らない から。承認の階層も、ポリシーも、どこで人が判断に入るべきかも知らない。これを 「プロセスコンテキストの欠如（missing process context）」 と呼んでいました。
しかもそのコンテキスト、社内のどこにあるかというと……
- Slack のスレッド
- 「Thresholds_Final_v9」みたいな名前のスプレッドシート
- 最終更新が 2020 年の SharePoint フォルダ
- 録画された会議
- 担当者の頭の中にある 9 年分の判断
全部、非構造化データ。エージェントも自動化も、ここには手が届かない。「それが皆さんのビジネスを動かしている」と Raghu。耳が痛い。
Map of Work って何それ？！
じゃあどうするの、の答えが Map of Work です。直前の Daniel Dines のキーノートでも出てきたキーワードで、Raghu はここで「復習」として構成要素を説明してくれました。
今ある UiPath プラットフォーム（Foundation / Task / Process の3層）は「仕事を 実行する」ために作られてきた土台。Map of Work はその上に載って、「仕事を 理解する」ためのコンテキストを与える。Raghu の言葉を借りると「土台に、皆さんの仕事を理解することを教える」ってこと。
特徴は3つで、Live（ビジネスが変われば最新化）、Customer-owned（100% 顧客が所有）、Governed（変更は全部監査可能でバージョン管理）。
中身も3つ。
| 構成要素 | 中身 |
|---|---|
| Structured Knowledge | ケースプラン、ビジネスポリシーとルール（何が許され、何に承認が要り、しきい値はいくらか）、ビジネスオントロジー（顧客・請求書などの業務オブジェクトとその関係の共有定義） |
| Operating Knowledge | ベテランが知っていること。先例、実例、頭の中の指針。退職とともに失われがちなアレ |
| Decision Ledger | すべての判断の背後にある根拠と理由。誰が、何の証拠で決めたか。エージェントがプロセス改善に使う |
3つ目の Decision Ledger（意思決定台帳） がこのセッションの隠れ主役で、後半のデモで効いてきます。
誰が Map を描くの？
Raghu の答えは「人と製品の両方」。人の側は Cartographer（地図製作者） という新しい役割なんですが、ここが大事で、
「新規採用ではありません。ビジネスアナリストがいるなら、その人たちがすでに皆さんの Cartographer です。この役割を格上げするのが製品、UiPath Cartographer です」
Raghu の言い方だと BA の仕事が製品で格上げされる、という話（自分の受け止めは「おわりに」で）。人の Cartographer が成果・KPI・SLA を決めて主導権を持ち、製品の UiPath Cartographer が「ここが埋まってないよ」「この2つの資料、矛盾してるよ」と導いてくれる。現状（as-is）を描くだけじゃなく、あるべき姿（process re-engineering）まで一緒に設計する、という説明でした。
全体は4ステップのループ
- Capture：UiPath Cartographer で Map を描く
- Build：UiPath for Coding Agents が Map を入力に、自動化成果物を 全部 構築する
- Run：UiPath Maestro が同じ Map から動くすべてをオーケストレーション
- Learn：例外処理・上書き・人の判断が Decision Ledger に記録され、Map の改善にフィードバック
「ライブで自己改善するループ」。ここから先のデモは、この4ステップを Cobalt Ridge という架空の会社で順番に回していく構成になっていました。
Map の始め方は3つ。ゼロからは（ほぼ）無い
「で、Map をゼロから描くの？ 無理でしょ？」ってお思いのあなた！ Raghu の答えは「ほとんどの場合、ゼロからではない」でした。
| 始め方 | 対象 | 状態 |
|---|---|---|
| Prebuilt maps with UiPath Solutions | 業界内でどの会社でも形が同じプロセス。Map も自動化成果物も丸ごと構築済み | Deployed（初日から完成） |
| Process Atlas with expert attestations | ばらつきが大きくて事前構築はできないけど共通性はあるプロセス群。専門家がキュレーションした Map を初期実装として渡してくれるので、自社の Cartographer が組織知を足す | Adapted（今回の新発表） |
| Build your own map | 自社固有のプロセス。UiPath Cartographer でゼロから描く | Customized |
スライドには 「UiPath has curated Maps of Work for 100+ verticalized processes」。Healthcare、Manufacturing・Telecom・Utilities、Financial Services、Cross-Industry の4領域が並んでいて、Insurance は Coming Soon。「継続的な投資で数百にまで増える」とのことでした。
Cartographer デモ：保証対応の Map を 45% → 68% → 実装へ
デモの題材は架空の産業機器メーカー Cobalt Ridge Inc. の 機器保証対応（Equipment Warranty Resolution）。プロダクトマネジメントのリーダー Anvita（Anvita Dekhane）が Cartographer 役、エンジニアリングのリーダー Scott が保証担当者（warranty officer）役です。
| 指標 | 値 |
|---|---|
| 年間クレーム件数 | 7,400 件 |
| P1 ライン停止時間 | 96 時間 |
| 保証適用判断まで | 4.2 日 |
| 初回修理成功率 | 61% |
| 年間保証支出 | $41.2M（売上の 2.8%） |
| 解決までの平均時間（FY2026 ベースライン） | 11.4 日 |
| 目標（FY2027） | 3.5 日 |
11.4 日を 3.5 日に。ざっくり 3 分の 1 です。しかも実態は Line down → Contain → Coverage → Fix → Settle の6つの箱じゃなくて、断片化して例外だらけのケースが常に数千件動いている、と。
デモの流れ
- Process Atlas から出発：Manufacturing を選んで「Warranty resolution」を選ぶと、ステージ、タスク、条件分岐、各ステージの担当者、典型システム、標準ルールが構築済みで出てくる。この時点でカバレッジ 45%
- 文書を投入して as-is を文書化：ワークショップの文字起こし、SME インタビュー、経営層向けブリーフ、SME が停止時間を手で注記したクレーム記録を UiPath Cartographer に渡して「現状を文書化して、情報源同士の矛盾を示して」と指示。エージェントは Process Atlas のスキルを呼びながら、Anvita の承認を取って Map を埋めていく
- 欠けたステージを発見：「否認（denial）」「撤回（withdrawal）」の2ステージが Atlas には無くて Cobalt Ridge には必要、とエージェントが気づき、承認のうえ追加。カバレッジ 68% に
- ゴール指向エージェント：最初に現行 KPI（11.4 日）をベースラインとして Map に固定して、目標に向けてタスクとステージを足していく
この画面、地味にすごくて、11.4 日の内訳が Intake 2.3 日 / Evidence & coverage 4.2 日 / Parts & substitution 3.1 日 / Dispatch & repair 1.8 日と分解されていて、「一番幅の広い区間（Evidence & coverage）は誰も分解したことがない」と赤字で指摘してくれてます。コンサルの初回ヒアリングでやる仕事が、8 つの文書からほぼ自動で起きてる。
- SME への引き渡し（Teams 連携）：「1万ドル超の高額クレームは VP 承認」までは分かるけど、具体的な手順が分からない。そこで Cartographer エージェントから保証担当者 Scott に質問を引き渡す。質問文・必要な証拠・求める判断があらかじめ埋められて、Scott の Teams に通知が飛ぶ
- Scott の回答：説明する代わりに 画面録画で実演。5万ドル超のクレームを SAP 上で CFO 承認要とマークして、レポートを Teams チャンネルに投稿して、部門ポリシー文書を添付
- Map への書き戻し：エージェントがポリシー文書と画面録画のステップを読み取って、更新箇所を 赤線（redline） で示しながら Map に反映
「参加者の少ないワークショップをしながらチームメンバーからの入力を手で追いかける数か月の作業が、数週間、いや数日にまで縮まりました」（Anvita）
「参加者の少ないワークショップ」、みんな経験あるやつですよね。
Cartographer、GA 来ました！！
デモを受けて Raghu が UiPath Cartographer の一般提供（GA） を発表。
「私は身びいきかもしれませんが、これは最も変革的な瞬間のひとつになりうると思っています」
スライドの2本柱は「Build your Map of Work, collaboratively」と「Build with UiPath Process Atlas」。Cartographer 単体で描くのもいいけど、Process Atlas を出発点にするのが本命の使い方、と読みました。
coding agent が Maestro Case を1時間で組んだ。ヤバすぎる！！
ここから録音の2本目。Anvita が今度は Cobalt Ridge の AI 開発者役 で登場します。Cartographer から引き渡された保証対応の Map of Work を、Maestro Case として実装するデモ。
使ったのは coding agent の Claude Code と、エディタの Visual Studio Code。プロンプトは画面上に 「Build a Maestro case plan from warranty-resolution-map-of-work」 の一行。で、出てきたのがこれ。
| 項目 | 値 |
|---|---|
| 所要時間 | 1時間以内 |
| ステージ | 10 |
| タスク | 41（各ステージに SLA 付き） |
| ルール | 76（ステージ開始・終了、タスク開始・終了の条件） |
| バインディング | 28（API ワークフロー、エージェント、プロセス、アプリの 14 リソース） |
| ケースアプリ | 保証担当者向けに 11 の人間アクション を持つアプリも自動生成 |
画面には、タスクごとに「(api)」「(agent)」「(process)」「(action)」と種別が付いた一覧、94 のケースインスタンスフィールド、Warranty Triage や Decision Ledger Summary といったエージェント、BPMN プロセスへのバインディングが表示されていました。Maestro Case を手で組んだことがある人なら分かると思うんですが、76 ルール 28 バインディングを1時間 は、計算するだけ馬鹿らしくなる数字です。
Raghu が「これデモ用の作り物（demo-ware）じゃないの？」と突っ込むと、Anvita は「お約束します、作り物ではありません。手作業なら数か月かかったかもしれないプロセスを、1時間かからずに構築できました」。で、Raghu の返しがこれ。
「私はまだ信じられないし、皆さんも信じるべきではない。全員、自分で試してみるべきです」
CPTO が自社デモを「信じるな、試せ」って言うの、良くないですか。
変更もプロンプト一言
「開発者が気に入らない部分を変えたいときは？」への回答デモも。「証拠の欠落・矛盾のフラグ付け」というタスクがエージェントとして実装されていたのを、「CRM のテーブル参照で済むから API ワークフローに差し替えて」とプロンプト。UiPath のスキルと設定が起動して、同じ入力・出力のタスクがエージェントではなく API ワークフローにバインドされた形で再生成されました。「手で変えてたら数日かかった」と Anvita。
UiPath for Coding Agents も GA！！
ここで Raghu が UiPath for Coding Agents の GA を発表。スライドの表記は、
- プラットフォームの 隅々まで、Codex、Claude、Windsurf などお好みの coding agent から構築・運用・管理・ガバナンス・改善ができる
- デプロイまでの時間 3〜5 倍 高速化
- 開発生産性 59% 向上
- 「Build at agent speed. Run at enterprise scale.」
DevCon India のときに「UiPath for Coding Agents 正式発表」を聞いてから4か月。あのとき Studio と Claude Code で publish and deploy まで完走してたのが、今回は Maestro Case をまるごと生成 まで来た。進みが速い。
人の判断が資産になる：Decision Ledger で 93% → 96%
ここからが個人的に一番刺さったパートです。
保証担当者の日常：自律処理率 93%
Scott が保証担当者として、実際に運用しているケースアプリを見せてくれました。
開いているケース 41 件のうち 38 件が人手なしで進行中（93% autonomy）、今日 Scott が見るべきものは 3 件（P1 が 1 件）、SLA リスク 10 件。口頭では「ストレートスルー処理率 90%」と言っていました。
推移はこう。
- 導入前：クレームを 6 つのシステム に手で通していて、自動化率 ゼロ
- 初回デプロイ後：約 50%（簡単なクレームが流れるようになった）
- その後：チームがアプリを使い、判断が Decision Ledger に記録されるにつれて 毎週改善
デモでは、エージェントが「保証適用を否認」と推奨したクレームに対して、Scott が「数か月後に契約更新がある」「この顧客は過去すべて承認されている」という追加情報を与えて、経験に基づいて 部分承認に上書き しました。ここでの Scott の一言。
「これは以前なら新人にコーヒーを飲みながら説明していたようなことです。でも今は、私の判断と理由が日常業務の中で自動的に記録される。私を遅らせることもない」
「コーヒーを飲みながらの説明」が資産になる。属人化に悩んでる日本の現場、これ全部じゃないですか。
Cartographer に戻ると、改善提案が届いている
Anvita が Cartographer 役に戻ると、Scott の判断が Map of Work の Decision Ledger に現れています。
- Cartographer エージェントが台帳の人間シグナルを分析し、「手動対応ケースの 約 50% は、高額な契約更新が近い顧客への好意（gesture of goodwill）として承認されている」というパターンを検出
- ERP の顧客履歴と CRM のライセンス履歴を参照して、こういうクレームを自動承認する 新しいビジネスルール を提案（画面では SI-0008「Approve claims for customers nearing contract renewal with clean history」）
- 適用すると、評価（evals）を自動生成・実行 して何も壊してないことを確認したうえで、効果を予測
- ストレートスルー処理 93% → 96%、人へのエスカレーション 7% → 4%（適用前後 30 日、各 258 件の判断で比較）
「私が今追加したビジネスルールは Map に書き戻され、この Map を生きて呼吸する文書としての資産に保ち続けるのです」（Anvita）
Raghu の締めは「コンテキストを集め、自動化を構築し、運用し、ガバナンスし、そして最も重要なことに、改善し続ける。UiPath はそのための完全なプラットフォームを提供する」。前編はここまでです。
前編で発表された機能まとめ
| 機能 | 何をするもの？ | 提供状況（講演内の表現） |
|---|---|---|
| Map of Work | プロセスコンテキストを Structured Knowledge / Operating Knowledge / Decision Ledger の3要素で構造化した、ライブで顧客所有でガバナンスされた資産 | 概念・成果物。Cartographer の GA とともに使える |
| UiPath Cartographer | Map of Work を構築・維持する製品。ゴール指向の Cartographer エージェント、文書からの as-is 文書化と矛盾検出、SME への Teams 引き渡し、赤線での書き戻し、Improvements と Ledger のタブ | GA（本日） |
| Process Atlas | 専門家の検証を受けた業界プロセスの Map 集。Healthcare、Mfg・Telecom・Utilities、Financial Services、Cross-Industry。Insurance は Coming Soon | 発表（スライド「100+ processes mapped」） |
| Prebuilt maps with UiPath Solutions | 業界共通プロセスの Map と自動化成果物を丸ごと事前構築 | Deployed（詳細は後編） |
| UiPath for Coding Agents | Codex、Claude、Windsurf など好みの coding agent から、UiPath プラットフォーム全体を構築・運用・管理・ガバナンス・改善。デモでは Maestro Case をプロンプトから生成 | GA（本日、プラットフォーム全体） |
| Decision Ledger と改善提案 | 人の判断と理由を記録し、Cartographer エージェントが新ルール・新プロンプト・新自動化を提案。適用時に評価を自動実行して効果を予測 | Map of Work の一部として Cartographer 内で動作 |
おわりに
というわけで、製品基調講演の前編でした。
聴く前は「Cartographer ってプロセスマイニングのリブランドでしょ？」くらいに思ってたんですが、全然違いました。問いの置き方が「どのモデルを使うか」から「自社のプロセスコンテキストをどう構造化して渡すか」に変わった、というのがこのセッションの全体像で、Cartographer も Process Atlas も coding agents も、全部その一点に向けて組まれてます。
日本の現場に持ち帰るなら、この3つ。
- BA の仕事に、エンジニアも手が出せるようになった：Raghu は「BA の仕事が製品で格上げされる」と言ってましたが、自分の受け止めは逆側もあります。要件定義書を Word で書いて開発者に渡す流れが、Map of Work を Cartographer で作って coding agent に渡す流れに変わるなら、その Map を描く仕事は BA だけのものじゃなくなる。エンジニアが業務側に踏み込む入口にもなる、ってこと
- 「1時間で 10 ステージ 41 タスク 76 ルール」はデモの数字：Raghu 自身が「信じるな、試せ」と言ってます。再現性は Map of Work の質、つまり投入する文書と SME の協力にかかっているはず
- 人の判断が資産になる：Decision Ledger は、ベテランの「コーヒーを飲みながらの説明」を日常業務の中で記録して、次のルール改善に使う仕組み。属人化で困ってる現場に一番刺さるのはここだと思います
Cartographer で気づいてしまったこと
いいところだけ書いて終わるのもアレなので、Cartographer を見ていて気づいてしまったことを一つ。
画面1枚が抱えている情報量が多すぎる。 情報密度、とでも呼ぶべきか。Business KPIs の画面ひとつに、8つの文書の出自、11.4 日の内訳、赤字の指摘、左には数十行のナビゲーション。Process board に行けば 12 ステージ分のタスクとルールがびっしり並んでる。
AI でできることが増えた。それは分かる。AI をちゃんと動かすには、たくさんの情報が要る。それも分かる。
ただし、自分の持論。人間こそが最大のボトルネック だってこと、忘れちゃいないかね？
情報量が増えると、それを自分が理解する、人に説明する、という 人間にしかできない仕事 がそのまま増えていくんですよ。Map of Work が厚くなればなるほど、Cartographer（人）の頭に載せなきゃいけないものも厚くなる。Decision Ledger が「コーヒーを飲みながらの説明」を記録してくれるのはありがたいけど、その台帳を読んで判断するのは結局人間です。
この矛盾をどう解消していくのか。Cartographer で一番強く感じたのは、ここでした。答えはまだ無いです。でも、たぶんこの先 UiPath が向き合わされる問題だと思うので、後編でも、そのあとのセッションでも、この目線で見ていきます。
みんな Cartographer 触って、自社の Map of Work を書いてみよう！！ ただし、描いた Map を誰が読むのかまで考えてから。
次回は後編。Martijn による UiPath Solutions（Source-to-Pay）のデモ、Test Cloud の「ダークファクトリー」構想、AI ネイティブな自動化機会の発見について書きます。お楽しみに！