CodexやClaude CodeでのA2Aの最適な活用術
AIエージェントを日常業務や開発現場で使う人が増えるほど、「A2A」という言葉を見かける機会も増えています。ただし、ここで注意したいのは、A2Aが一つの意味だけで使われていないことです。
ある場面ではAgent2Agent Protocolのような、独立したエージェント同士を接続する標準プロトコルを指します。別の場面では、CodexやClaude Codeの中で複数の担当エージェントに作業を分ける運用を指します。
この二つを混同すると、設計が一気に崩れます。ローカルの作業分担で済むものに大げさなプロトコルを持ち込んだり、逆に組織やシステムをまたぐ連携を単なるプロンプト分業で済ませようとしたりするからです。この記事では、CodexやClaude CodeでA2A的な運用を実務に落とすための考え方を整理します。
A2Aには二つの層がある
A2Aを使いこなす第一歩は、「いま自分が解きたい問題はどの層の問題なのか」を分けることです。多くの失敗は、ツール名や流行語から設計を始めることで起きます。CodexやClaude Codeで複数担当に仕事を分ける話と、A2A Protocolで別システムのエージェントと通信する話は、似て見えても目的が違います。前者は作業設計、後者は相互運用設計です。
ローカル分業層は、親エージェントの仕事を軽くする設計
CodexやClaude CodeでのA2A的な使い方は、まずローカル分業として理解すると実務に落としやすくなります。親エージェントが全体目的を持ち、調査、設計、実装、レビュー、資料化などの一部を専門担当に渡す形です。ここで重要なのは、サブエージェントは最終責任者ではないという点です。
たとえば「新機能を作る」という依頼を一つのエージェントに丸ごと渡すと、調査、設計、実装、テスト、ドキュメント更新が混ざります。これを「仕様確認担当」「実装担当」「テスト担当」「レビュー担当」に分ければ、各担当の成果物が小さくなり、検証もしやすくなります。
外部連携層は、別のエージェントシステムと安全に会話する設計
A2A ProjectのAgent2Agent Protocolは、独立したエージェントシステム同士が、内部状態やツールの詳細を見せずに協働するための標準として設計されています。仕様では、能力を説明するAgent Card、作業単位としてのTask、やり取りを表すMessage、成果物としてのArtifact、ストリーミングやPush Notificationなどの概念が整理されています。
混同すると、過剰設計か丸投げになる
ローカル分業と外部連携を混同すると、二つの失敗に寄ります。一つは過剰設計です。まだ一人の開発者の端末内で完結する作業なのに、最初からプロトコル実装やサーバー間連携を考えてしまうケースです。もう一つは丸投げです。本来は権限、成果物、監査ログ、認証を設計すべき外部連携を、プロンプトだけの「別AIに聞いて」で済ませてしまうケースです。
CodexでA2A的に使うなら、AGENTS.mdを司令塔にする
CodexでA2A的な運用をするなら、最初に整えるべきはプロンプトの言い回しではなく、プロジェクト側の指示ファイルです。Codexはリポジトリ内の文脈、制約、検証コマンド、保存先、禁止事項を読みながら作業します。したがって、毎回チャットで同じ注意を書き足すより、AGENTS.mdに作業規約を置く方が再現性が高くなります。
AGENTS.mdには、作業の目的よりも完了条件を書く
AGENTS.mdでよくある失敗は、抽象的な心構えだけを書いて終わることです。「品質を高く」「丁寧に」といった指示だけではA2A的な分業には足りません。必要なのは、担当範囲、成果物、保存先、検証、未完了条件です。
SkillやMCPは、親エージェントを置き換えるものではない
Codexでは、SkillやMCPを使うことで、特定ワークフローや外部ツール連携を強化できます。ただし、SkillやMCPは親エージェントの判断を置き換えるものではありません。使える道具が増えるほど、どの条件で使うかを決める責任が重くなります。
Codexで委譲する依頼文は、担当範囲を狭くする
目的: A2A解説記事の技術的正確性を確認する
入力: article-draft.md と参照リンク一覧
担当範囲: A2A Protocol、Codex、Claude Codeの説明に矛盾がないかを見る
出力形式: 重大度順の指摘リスト。修正文案も付ける
禁止事項: 本文全体の書き換え、未確認の数字追加
検証方法: 指摘ごとに根拠となる公式情報または本文箇所を書くClaude CodeでA2A的に使うなら、subagentsを専門職として設計する
Claude Codeのsubagentsは、専門タスク向けに事前設定されたAI担当として使えます。Anthropicの公式ドキュメントでは、subagentは専用の目的、別のコンテキストウィンドウ、許可ツール、カスタムsystem promptを持てるものとして説明されています。これはA2A的なローカル分業と相性がよい一方、設計が甘いと担当が増えただけで混乱します。
subagentsは一つの責任に絞る
良いsubagentは、名前を見ただけで「何を任せる担当か」が分かります。code-reviewer、test-runner、debugger、docs-writer、migration-plannerのように、仕事の種類が明確なものです。万能担当は一見便利ですが、親エージェントとの境界が曖昧になりがちです。
ツール権限は、信頼ではなく役割で決める
調査担当に編集権限があると、調査のつもりでファイルを書き換える可能性があります。レビュー担当に広い実行権限があると、レビューではなく修正まで進めてしまうことがあります。権限は「このエージェントを信頼しているか」ではなく、「この役割に必要か」で決めます。
自動委譲と明示委譲を使い分ける
自動委譲は日常作業、明示委譲は高リスク作業に向いています。認証、決済、個人情報、デプロイに関わる変更では、担当、権限、完了条件を明示した方が安全です。
A2A活用の実務手順
A2A活用は、ツールを増やす前に作業を分解するところから始めます。人間が普段、頭の中でやっている「調べる」「考える」「作る」「疑う」「直す」「出す」という流れを、エージェントが扱える単位にする作業です。ここを飛ばすと、どれだけ高性能なツールを使っても、結果は長いチャットログと散らかった差分になりがちです。
1. タスクを直列部分と並列部分に分ける
仕様の解釈、設計方針、データモデルの決定などは、後続作業の前提になるため直列に置くべきです。一方で、競合しない調査、SNS展開案、画像案、テスト観点の洗い出しなどは並列化しやすい作業です。
2. 成果物契約を作る
サブエージェントに渡す仕事には、必ず成果物契約を付けます。Markdownで返すのか、JSONで返すのか、ファイルに保存するのか、指摘リストにするのか、修正文案まで含めるのか。ここが曖昧だと、分業の効果が薄れます。
3. 親エージェントが統合と矛盾チェックを持つ
親は作業を配るだけではありません。成果物を読み、矛盾を取り、過剰な断定を削り、重複を統合し、最終的にユーザーへ出す形に整えます。
4. 外部A2A化する基準を決める
外部A2A化を検討するのは、別のシステム、別の組織、別の権限境界をまたぐときです。ひとつのリポジトリ内で記事やコードを作るだけなら、AGENTS.md、subagents、Skill、MCPの範囲で十分なことが多いです。
失敗パターンと回避策
A2A運用の失敗は、モデルの性能不足よりも設計不足から起きることが多いです。特に、丸投げ、並列化しすぎ、権限過多、レビュー省略は、どのツールでも起きます。CodexやClaude Codeで再発しやすい失敗を実務目線で整理します。
丸投げして、結果を統合できない
悪い依頼は「A2Aについて徹底的に調べて」「いい感じに記事にして」のように、目的も成果物も曖昧です。回避策は、問いを分け、それぞれの成果物形式を決めることです。
並列化しすぎて、調整コストが増える
同じファイルを複数担当が編集したり、同じ論点を別々に調べたりすると、調整コストが増えます。調査、SNS案、画像案のように成果物が分かれる作業は並列にしやすく、設計と実装のように依存関係が強い作業は順番に進めます。
権限を広く渡しすぎる
読み取り、編集、実行、外部連携、公開を分けます。特に外部投稿、デプロイ、APIキー入力、破壊的コマンドは、人間承認を残すべきです。
まとめ：A2Aは責任境界を設計するために使う
CodexやClaude CodeでA2Aを活用する最適解は、エージェントをたくさん動かすことではありません。最初にやるべきことは、仕事を分け、成果物を決め、権限を絞り、親エージェントが統合する流れを作ることです。CodexではAGENTS.mdを司令塔にし、SkillやMCPを必要な能力として組み合わせる。Claude Codeではsubagentsを専門職として設計し、単一責任と最小権限を徹底する。
そのうえで、別システム、別組織、別ベンダーのエージェントと連携する必要が出てきたら、Agent2Agent Protocolのような外部A2Aを検討します。ローカル分業は作業設計、外部A2Aは相互運用設計。この二層を分けて考えるだけで、導入の順番はかなり明確になります。
A2Aは魔法の自動化ではなく、責任境界を明文化するための設計技術です。誰が何を受け取り、何を返し、どこまで実行でき、誰が最終判断するのか。そこを決めたチームほど、CodexやClaude Codeを単なる便利ツールではなく、再現可能なワークフローの一部として使えるようになります。