複数のAIエージェントが協働すると、「前の仕事を少し直して」という依頼が増えます。このとき、完了済みのタスクを再び動かす設計は、一見すると効率的です。しかし、入力・出力・責任の対応関係が曖昧になり、監査や障害解析を難しくします。
A2A Protocol v1.0の公式ドキュメントは、終端状態に達したタスクを再開せず、修正や追加依頼を同じ文脈に属する新しいタスクとして扱う考え方を示しています。これはプロトコルの細部に見えて、AI業務を追跡可能にする重要な設計原則です。
A2AのTaskは「会話」ではなく作業単位です
A2A（Agent2Agent Protocol）は、異なる基盤や組織のAIエージェントが通信・協調するためのオープンなプロトコルです。公式資料では、すぐ終わる応答にはステートレスなMessage、継続的な管理が必要な処理には状態を持つTaskを使うと説明されています。
Taskには識別子と状態があり、処理中だけでなく、追加入力待ちや認証待ちも表現できます。一方、completed、canceled、rejected、failedは終端状態です。公式の「Life of a Task」は、Taskがこれらの状態に達した後は再開できないと明記しています。
なぜ完了済みTaskを再利用しないのか
例えば、エージェントAが「月次レポートを作る」TaskをエージェントBへ依頼し、成果物が完成したとします。その後に「欧州部門を追加して」と頼まれた場合、元のTaskを書き換えると、最初の依頼と最終成果物の対応が崩れます。
A2Aの考え方では、元のTaskは完成時点の記録として固定し、追加依頼には新しいTaskを作ります。関連性は、会話や業務のまとまりを示すcontextIdと、参照元を示すreferenceTaskIdsで表現できます。
- taskId：一つの作業単位を識別する
- contextId：複数のMessageやTaskを同じ文脈にまとめる
- referenceTaskIds：新しい依頼がどの過去Taskを参照するか示す
つまり「履歴を消して上書き」ではなく、「元の結果を残したまま差分の仕事を追加」します。製品開発で、承認済み仕様を直接書き換えず、変更要求を別票で管理するのに近い考え方です。
成果物の最新版はクライアント側で管理します
注意したいのは、Taskを分けるだけでは成果物の版管理が完成しないことです。A2A公式ドキュメントは、派生したArtifact（成果物）のつながりをプロトコル自体では管理せず、どの版を採用するか判断できるクライアント側が履歴を持つべきだと説明しています。
サービス側のエージェントには、更新版でも一貫したArtifact名を使うことが推奨されています。クライアント側では、少なくとも次を保存すると追跡しやすくなります。
- 依頼Taskと生成Artifactの対応
- 参照した元Task・元Artifact
- ユーザーが採用した最新版
- 各Taskの開始時刻、終端状態、承認者
ただし、A2Aを採用すれば自動的に監査要件を満たすわけではありません。保存期間、アクセス制御、個人情報の扱い、承認ルールは、利用組織が別途設計する必要があります。
並列化にも効く「不変なTask」
元のTaskを固定すると、完了した成果物を起点に複数の後続Taskを並行して開始できます。A2A公式ドキュメントも、同じcontextIdの中で別々のTaskを作る並列フォローアップを説明しています。
例えば、出張のフライト予約結果を基に、ホテル手配と現地移動の手配を別Taskとして進められます。片方が失敗しても、もう片方や元の予約記録を巻き戻す必要はありません。依存関係をTask間の参照として扱えるため、再実行の範囲も限定しやすくなります。
実装時の4つの確認点
- 終端状態のTaskを更新しない：修正依頼は新しいtaskIdで受けます。
- 会話と作業を分ける：contextIdをTaskの代用にせず、一つの文脈に複数Taskを許します。
- 参照関係を保存する：referenceTaskIdsとArtifactの採用履歴をクライアント側で記録します。
- 重複実行を別途防ぐ：Taskの不変性だけに頼らず、依頼受付時の冪等性や業務側の一意キーも設計します。
まとめ
AIエージェント間の仕事を安全に増やすには、会話が続いていることと、同じ作業を続けていることを分けて考える必要があります。A2A v1.0が示すように、完了したTaskは固定し、修正や派生作業は同じ文脈の新しいTaskとして記録します。この小さな境界が、追跡可能性、並列実行、障害からの切り分けを支えます。
AIの回答を「最新版だけ残す」のではなく、「どの依頼から、どの成果物が生まれ、何を採用したか」を残すことが大切です。これは、マルチエージェント時代の運用設計で、モデルの賢さより先に決めておきたい台帳のルールです。