これまでAIへの依頼は、人が一つずつ指示を渡す形でした。いま語られ始めたのは、マネージャー役のAIが別のAIに仕事を割り振る「エージェント間委任」です。依頼を流れる仕組みにするという観点でいうと、これは受け渡しの経路が人からAIへ、さらにAIからAIへと枝分かれする話です。枝分かれが増えたとき、問題が起きたら誰の依頼だったかをたどれるか。この記事はその一点を扱います。
AIがAIに仕事を振り始めている
エージェント間委任(Agent-to-Agent Delegation)とは、人が直接指示するのではなく、あるAIが別のAIにタスクを割り振って進めさせる構造を指します。マネージャー役のAIが、作業役のAIを立ち上げ、仕事を配り、結果を受け取ります。
これは一部の実験ではなく、つなぎ方の標準化が進んでいます。Googleは2025年4月にエージェント同士が互いを見つけて仕事を委任し合う通信規格「Agent2Agent(A2A)」を公開し、同年6月にLinux Foundationへ移管しました1。A2Aでは、割り振られた仕事は「submitted(受付)」「working(作業中)」「completed(完了)」「failed(失敗)」といった状態を持ち、判断が必要な場面では「input_required(入力待ち)」で人に戻す穴も用意されています2。仕事を渡す相手がAIでも、状態を追い、途中で人に戻せる前提が規格に組み込まれています。
ここで読者が持つ反論は「うちは大きなAIを1つ使うだけで、AIがAIに振る話は関係ない」でしょう。当面はそのとおりです。ただ、この構造は外部への業務委託ですでに起きています。ある会社に仕事を頼み、その会社が別の会社に再委託する。誰が最後に手を動かしたか分からなくなる場面を、多くの管理者が経験しています。エージェント間委任は、同じ枝分かれをAIの速さで起こします。
委任が枝分かれすると、責任はどこで消えるか
委任そのものは問題ではありません。責任が消えるのは、枝分かれの途中に「誰の指示で、いつ、何をしたか」の記録が抜ける瞬間です。
人が1人のAIに頼むだけなら、たどる線は「人 → AI」の1本です。ここにマネージャー役のAIが入り、作業役のAIへ再委任すると、線は「人 → マネージャーAI → 作業役AI」と伸びます。作業役がさらに別のAIを呼べば、もう一段伸びます。どこか1段で記録が途切れると、その先で出た結果を元の依頼者まで戻せなくなります。事故が起きたとき、原因のAIは特定できても、それを誰の依頼として動かしたのかが宙に浮きます。
この問題は研究でも名指しされています。認証付き委任を提案する論文「Authenticated Delegation and Authorized AI Agents」は、AIがAIに仕事を渡すたびに委任の証跡を引き継がせ、各AIの行動を元の人間の依頼者までさかのぼれる形に保つ設計を示しています3。裏を返すと、証跡を引き継がない委任は、その場では速く回っても、後から責任の出どころをたどれません。
だから、委任を許すかどうかより先に決めることがあります。再委任がどこまで枝分かれしてよいか、その各段で状態変化を残すか、そして最終的に戻す先の人を1つ固定しておくか。ここが決まっていない委任だけが、責任を溶かします。
PATHWORKで、再委任しても元の依頼者まで戻す
PATHWORKは、依頼の状態・担当・期限を1画面で扱う業務支援ツールです。エージェント間委任の文脈では、枝分かれした委任を1本の依頼の流れとしてつなぎ直す器として使えます。
やることは3つです。1つ目に、AIやチームに委任した作業を、独立したタスクではなく元の依頼にひも付けて起票する。2つ目に、誰から誰へ渡り、いつ状態が変わったかを、その依頼の履歴として残す。3つ目に、判断や公開が必要な場面で戻す先の人を、依頼ごとに1人決めておく。再委任が何段に伸びても、戻す先が1つ決まっていれば、責任の出どころは消えません。
限界も書いておきます。委任の枝分かれを1本につなぐのは、記録を残す運用があって初めて成り立ちます。AIが証跡を残さないまま独自に別のAIを呼ぶ経路までは、外側のツールからは追えません。だから、証跡を残す委任だけを許す、というルールを人の側で先に決める必要があります。記録の器そのものについては監査ログの記事を、戻す先での承認の置き方については承認ポイントの設計を合わせて読んでください。
委任を許す前に決めておくこと
- 再委任をどこまで許すか(何段まで枝分かれしてよいか)を先に決める
- 委任した作業を、独立タスクにせず元の依頼にひも付けて起票する
- 誰から誰へ渡り、いつ状態が変わったかを依頼の履歴に残す
- 最終的に戻す先の人を、依頼ごとに1人固定する
- 証跡を残さない委任経路は許さない、というルールを人の側で決める
まとめ
エージェント間委任は、AIがAIに仕事を振る構造で、A2Aのように標準化も進んでいます。結論として、委任が何段に枝分かれしても、元の依頼者まで一本でたどれる記録があれば、最終責任は残せます。標準はつなぎ方を揃えますが、たどれる記録と戻す先の人を決めるのは運用側の仕事です。
当てはまらない範囲もあります。AIを1つしか使わず再委任が起きない現場に、暗号署名まで備えた仕組みは要りません。まず必要なのは、任せた作業を元の依頼にひも付け、戻す先の人を1人決めることです。委任の速さが上がるほど、この1本の線を先に引いておく価値が増します。
委任した作業を1本の依頼として追える形にする
AIや外部に振った作業が枝分かれして、誰の依頼だったか追えなくなっていませんか。委任の各段を1つの依頼の流れにつなぎ、戻す先を決める運用を、レペリオが一緒に設計します。
サービス導入の相談をする参考
本文中の番号をクリックすると、その数字の根拠にした原文にジャンプします。原文は改変せず、そのまま載せています。
-
Linux Foundation Launches the Agent2Agent Protocol Project(Linux Foundation、2025年6月23日)
DENVER - Open Source Summit North America - June 23, 2025 - The Linux Foundation ... today announced the launch of the Agent2Agent (A2A) project, an open protocol created by Google for secure agent-to-agent communication and collaboration. ... The A2A protocol is a collaborative effort launched by Google in April and with growing support from more than 100 leading technology companies.
プレスリリース冒頭(本文の「2025年4月にGoogleが公開」「同年6月にLinux Foundationへ移管」の根拠) 本文の該当箇所へ戻る -
Agent2Agent (A2A) Protocol Specification
TASK_STATE_SUBMITTED Indicates that a task has been successfully submitted and acknowledged. TASK_STATE_WORKING Indicates that a task is actively being processed by the agent. TASK_STATE_COMPLETED Indicates that a task has finished successfully. This is a terminal state. TASK_STATE_FAILED Indicates that a task has finished with an error. This is a terminal state. ... TASK_STATE_INPUT_REQUIRED Indicates that the agent requires additional user input to proceed. This is an interrupted state.
仕様 4.1.3 TaskState(本文が挙げた状態の根拠。現行仕様では TASK_STATE_ 接頭辞つきで定義されている) 本文の該当箇所へ戻る -
Authenticated Delegation and Authorized AI Agents(arXiv:2501.09674)
We introduce a novel framework for authenticated, authorized, and auditable delegation of authority to AI agents, where human users can securely delegate and restrict the permissions and scope of agents while maintaining clear chains of accountability.
論文アブストラクト(本文の「委任の証跡を引き継がせ、元の人間の依頼者までさかのぼれる形に保つ」の根拠) 本文の該当箇所へ戻る