ChatGPT WorkにData agent、社内データの権限は引き継ぐ
テクノロジー・イノベーション 2
退職者とともに消える仕事の勘、UiPathは「業務地図」に残す
UiPathは2026年9月23日、ラスベガスで Cartographerの提供開始 を発表した。文書、手順、規則、例外を集め、業務の実態を表す「Map of Work」を作る製品だ。UiPathが目指すのは、担当者の記憶に依存してきた判断を組織が所有する記録に変え、承認された内容を自動化やAIエージェントの設計に渡すことである。
Reworkedの現地報道 によると、製品はUiPathの顧客向けイベントFUSIONで紹介された。既存の手順書や方針、業務図、画面記録を照合し、食い違いや不足があれば専門家に質問する。最初にできる地図は、人が内容を確かめるための下書きであり、観察された作業がそのまま正式な規則になるわけではない。
文書と現場の判断をどう一つにするか
Cartographerが扱う情報は、出所によって意味が違う。方針や手順書は組織が定めた進め方を示し、業務図は役割や作業の受け渡しを示す。一方、現場の記録や担当者への聞き取りは、標準の手順から外れた処理と、その場で使われた判断を明らかにする。
例えば、同じ例外処理が繰り返されていても、それが正式に認められた対応か、担当者だけが知る便法かは、操作の記録だけでは判別できない。Cartographerは資料の不一致を隠して一つの説明に整えるのではなく、確認すべき点として浮かび上がらせる。ここで必要なのは、何をしたかに加え、どの規則を踏まえ、なぜ別の経路を選ばなかったかという理由だ。
Map of Workには、仕事を担う役割、関係するシステム、適用する規則、例外時の経路、判断の根拠を結び付ける。手順書だけを集めた場合に抜け落ちやすいのは、規則を現実の案件に当てはめる部分である。ただし、経験者の説明も常に正しいとは限らない。正式な方針と証言が食い違えば、どちらを採用するかを業務側が決める必要がある。
地図の変更を承認するのは誰か
UiPathが示すMap of Workには、変更を承認する名前付きの所有者がいる。Cartographerは情報を集めて案を作るが、案を自ら承認して公開する役割は持たない。業務担当者や専門家が事実関係を確かめ、業務に責任を持つ人が、変更を採用するか退けるかを判断する構造だ。
この区別がなければ、よく見られる慣行ほど地図に残りやすくなる。仮に承認を省く処理が何度も観察されても、その頻度だけで承認手順を削除する根拠にはならない。現行規則に反する行為なのか、規則が想定していない正当な例外なのかを分けて扱う必要がある。現場で起きた事実と、今後認める手順は同じではない。
地図には版の履歴が残り、以前の版に戻せる。したがって変更管理では、最新版の内容だけでなく、どの記述を何に基づいて変え、誰が承認したかが重要になる。UiPathの説明は所有者による承認を示しているが、異議を申し立てる窓口、規則の所管部門との調整、変更を審査する頻度まで一律に定めてはいない。これらは導入する組織の業務と権限に合わせて決める部分だ。
承認された定義は自動化へどう渡るか
Map of Workは、閲覧するための業務図だけにとどまらない。承認した定義から、業務側の確認に使うプロセス設計文書と、開発者向けのソリューション設計文書を作る。同じ定義を起点にすることで、聞き取りの内容、設計文書、実装の間で例外の扱いが別々に書き換わる余地を減らす狙いがある。
開発者とコーディングエージェントは、その定義を参照してケースやワークフローなどを構築する。構築後の処理を、人、ロボット、AIエージェントの間で動かす役割はUiPath Maestroが担う。Cartographerが業務の意味を整理し、別の製品が実装と運用を担うという関係であり、地図を作るだけで自動化が完成するわけではない。
判断を伴う例外では、情報を渡すことと権限を渡すことも分けなければならない。どの条件なら処理を進め、どの条件なら人へ戻すのかを定義して初めて、エージェントが参照する知識は業務上の制約と結び付く。地図の所有者が承認する対象には、手順の文章だけでなく、例外の扱いと判断権限も含まれる。
退職後も残せる知識と、まだプレビューの更新機能
UiPathの創業者ダニエル・ディネス氏は 発表当日の解説 で、担当者が去ると、その人の頭の中にあった例外処理や判断も組織から失われると説明した。引き継ぐべきものは「この場合はこうする」という答えだけではない。なぜその処理を選び、誰に判断を仰ぎ、どの規則を例外として扱ったかという背景も含む。
そのため、聞き取った内容を大量に保存するだけでは後任者の判断材料にならない。後任者が参照する版は承認済みか、判断の理由をたどれるか、未解決の食い違いを誰が引き受けるかが明確であってこそ、個人の経験を組織の知識として残せる。退職前の聞き取りと退職後の変更承認をつなぐのは、地図の所有者という役割である。
一方、業務中の判断を記録するDecision Ledgerと、その記録から地図の変更案を作って反映する一連の流れは、プレビューおよび今後の計画として示されている。想定される仕組みでは、判断時の証拠や理由を残し、規則と実際の処理がずれたときに所有者へ変更を提案する。所有者が採用するまで地図は自動で書き換わらない。
Cartographer自体の提供は始まったが、日々の判断を取り込む更新ループまで一般提供されたとはいえない。現時点で確かめられるのは、資料と人への質問から承認対象のMap of Workを作り、その定義を設計と自動化へ渡すという範囲だ。退職者の判断を継続して生かせるかは、更新機能の提供状況と、各組織が定める所有者、異議の扱い、改定の時期に左右される。
関連記事:
関連記事
ニュースレターを購読
Web3、AI、暗号資産の最新ニュースを受信箱にお届けします。
0