「会議室で全員が同時に喋るな」 — 複数AI管理と責任設計の現実解
「AIエージェント同士を直接つないだら効率良さそうじゃない？」
試した。依頼した内容と返ってきた結果が噛み合わない。
何が起きたか追おうとしたら、ログが散逸していた。マイクロサービスで学んだはずだろう。サービス間の直接通信は破綻する。
A2Aの夢と現実
Google が Agent-to-Agent（A2A）プロトコルを提唱して以来、「エージェント同士が直接通信する世界」が理想として語られている。
Agent Card で能力を宣言し、互いに発見し、直接メッセージをやりとりする。
分散的で、スケーラブルで、美しいアーキテクチャ。
……理想はね。
現実に複数のAIエージェントを動かしてみると、A2Aの直接通信にはいくつかの根本的な問題がある。
問題1: 不透明性 — 「今、何の話してた？」
エージェントAがエージェントBに「この分析やっておいて」と依頼する。
Bが結果を返す。Aがそれを使って次の判断をする。
ここまでの会話、人間は見ていない。
A2Aの直接通信は、エージェント間のコンテキストがブラックボックスになる。
後から「なぜBはこの結果を返したのか」を追おうとしても、会話ログが散逸している。
あるいは、そもそもログが残っていない。
これはデバッグの問題だけじゃない。監査の問題だ。
企業で使うなら、「AIがAIに何を依頼して、AIが何を返したか」を追跡できないシステムは論外だろう。
個人開発でも、3体以上が勝手にやりとりを始めると、人間が介入するポイントが消える。
問題2: 競合と暴走 — 「同じファイル触るな」
エージェントAが設定ファイルを更新している最中に、
エージェントBが同じファイルを読んで古い情報を基に判断する。
あるいは、AがBに依頼を出し、BがCに再委任し、
CがAに「確認してくれ」と戻してくる。循環依頼の完成だ。
直接通信は、調停者がいない。
誰が今どのリソースを使っていて、どのタスクが進行中で、どこで待ちが発生しているか。
全体を俯瞰する仕組みが構造的に存在しない。
人間のチームでも同じだろう。
「全員が同時に喋る会議」と「チケットで管理されたプロジェクト」、
どっちが成果を出すかは明らかだ。
問題3: 責任の所在 — 「誰がこの判断をした？」
エージェントAの判断なのか、Bの提案を受けたAの判断なのか、
それともB→C→Aと伝言ゲームされた結果なのか。
直接通信では、判断の連鎖が追えない。
以前の記事で書いたティア制（指揮階層）は、
「誰がどの権限で判断したか」を構造的に明確にする設計だった。
A2Aの直接通信は、この構造を壊す。
全員がフラットに通信できるということは、
全員が同じ権限を持っているように見えるということだ。
解法: チケットベースの管理
じゃあどうするか。
エージェント同士を直接繋がない。チケットで管理する。
やることは単純だ。
- タスクの依頼は**チケット（Issue）**として起票する
- 依頼元、依頼内容、期待する成果物、期限を明記する
- 受け手はチケットを引き受け、進捗をコメントで更新する
- 完了したらチケットをクローズし、成果物をリンクする
GitHubやJiraで毎日やっていることを、AI同士にもやらせるだけだ。
なぜチケットが効くのか
1. 可視性
チケットボードを見れば、今誰が何をやっているか一目で分かる。
A2Aの「どこかで何かが進行中」とは根本的に違う。
2. 追跡可能性
誰が起票し、誰がアサインされ、どんなコメントが付き、いつクローズされたか。
全部残る。 監査もデバッグも、チケットを遡ればいい。
3. 非同期処理
直接通信は、相手が応答するまで待つ必要がある（あるいは待たずに進んで事故る）。
チケットは本質的に非同期だ。
起票した時点で依頼は完了。受け手は自分のペースで処理する。
「待ち」が構造的に消える。
4. 優先度制御
チケットにラベルを付ければ、優先度を明示できる。
P0: 緊急 P1: 今日中 P2: 今週中
直接通信だと、全部が「今すぐやって」に見える。
5. 人間の介入ポイント
チケットボードは人間も見られる。
「このタスク、ちょっと待って」「優先度変えて」が、チケットのコメント一つでできる。
A2Aの通信に割り込むより、はるかに自然だ。
6. コンテキストの固定 — ブレない実装
ここが地味に効く。
チケットの内容は、受け手のエージェントが一時的に自分のコンテキストとして取り込める。
「何を作るか」「なぜ作るか」「完了条件は何か」がチケットに全部書いてあるから、
それを読み込んだ時点で、エージェントの目的が定まる。
A2Aの直接通信だと、会話が長くなるにつれて最初の依頼内容が埋もれる。
コンテキスト窓の奥に押し出されて、いつの間にか当初の目的からズレた実装が出てくる。
チケットなら、迷った時に原文を読み直せばいい。
仕様書が会話ログの中に埋没しない。独立したドキュメントとして存在し続ける。
実装 — 個人環境でのチケット運用
「チケット管理なんて大げさな……」と思うかもしれない。
GitHub Issues でもいい。Notion でもいい。テキストファイルでもいい。
要は依頼と成果物の記録が残る仕組みであれば何でもいい。
ただ、俺は外部サービスに依存したくなかったので、自宅NASにGiteaを立てて運用している。
自宅NAS
└─ Gitea
└─ 組織: AI-HQ
├─ リポジトリ: project-alpha（プロジェクトA）
├─ リポジトリ: project-bravo（プロジェクトB）
├─ リポジトリ: tasks（チケット管理）
└─ リポジトリ: shared-context（共有ナレッジ）
Giteaを選んだ理由は3つ:
- セルフホスト: データが全部手元にある。外部サービスへの依存ゼロ
- 軽量: NASの片隅で動く。GitHubのような巨大インフラは要らない
- Git連携: チケットとコードが同じ場所にある。成果物の紐付けが自然
チケットの流れ
例えば、メインのAIエージェントが別のエージェントにOSSの導入検証を依頼する場合:
[メインエージェント]
→ Gitea Issue を作成
Title: "Lightpanda Browser 導入検証"
Body: |
## 依頼内容
- Lightpanda Browser をステージング環境に導入
- CDPサーバー起動 → Puppeteerスクリプトで動作テスト
- 既存のChrome Headlessとのベンチマーク比較
## 期待する成果物
- 導入手順のmarkdown
- ベンチマーク結果（メモリ/速度/互換性）
## 完了後
- ナレッジ担当エージェントにドキュメント化を依頼すること
## 期限
- 2026-03-23 EOD
Labels: [P1, infra, evaluation]
Assignee: infra-agent
[インフラエージェント]
→ Issue を確認
→ 環境構築・テスト実行
→ 結果をコメントに記載
→ 別Issue起票: "Lightpanda 導入ナレッジ作成" → Assignee: docs-agent
→ 元Issue をクローズ
[ナレッジエージェント]
→ ナレッジ化Issueを確認
→ shared-contextリポにドキュメントをpush
→ Issue をクローズ
[メインエージェント]
→ 両Issueのクローズを確認
→ 人間に完了報告
A2Aなら「このOSS入れて試しといて」「はいどうぞ」で終わる。
チケットなら、何を依頼して、何が返ってきて、次に誰に何を頼んだか、全部残る。
その差が、3体目、5体目、10体目のエージェントを追加した時に効いてくる。
「それ、オーバーエンジニアリングでは？」
2体なら直接通信で十分かもしれない。正直、2体ならそうだ。
でもAIエージェントは増える。確実に増える。
秘書AI、リサーチAI、コーディングAI、セキュリティ監視AI。
用途が増えるたびにエージェントが増え、全方向の通信経路はN×(N-1)/2で爆発する。
3体なら3本。5体なら10本。10体なら45本。
直接通信のスケーラビリティは、構造的に破綻する。
チケットベースなら、通信経路は常に「エージェント ↔ チケットボード」の1本だけだ。
何体増えても変わらない。
これはマイクロサービスアーキテクチャで、
サービス間の直接通信をやめてメッセージキュー（SQS、Kafka）を挟むのと同じ発想だ。
枯れた設計パターンを、AI管理に持ってきただけ。
ティア制 × チケット管理 = 指揮統制の完成形
以前の記事で書いたティア制と組み合わせると、構造が完成する。
- Tier 0（司令塔）: チケットの起票・承認・クローズ権限を持つ
- Tier 1（準自律）: アサインされたチケットを処理する。起票権限は限定的
- Tier 2（使い捨て）: チケットに記載されたタスクだけを実行する。チケット操作権限なし
ここで重要なのは、各ティアのエージェントがさらにサブエージェントを使うことだ。
Tier 0が複雑なタスクを受けると、Tier 2のサブエージェントを複数起動して並列処理させる。
Tier 1も、自分の担当業務の中でサブエージェントを使い捨てる。
つまり実際の構造はこうなる:
人間（マスター）
└─ Tier 0（司令塔）
├─ Tier 2（サブ: ニュース収集）
├─ Tier 2（サブ: コードレビュー）
└─ Tier 1（秘書）
├─ Tier 2（サブ: Gmail巡回）
└─ Tier 2（サブ: カレンダー確認）
ツリーが深くなる。 Tier 0の下にTier 1、Tier 1の下にTier 2。
直接通信だと、この階層の中で誰が誰に何を頼んだか追えなくなる。
チケットなら、全階層の依頼・成果物がフラットに一覧できる。
Tier 1が起票したチケットも、Tier 0が起票したチケットも、同じボードに並ぶ。
ツリーの深さに関係なく、追跡可能性が保たれる。
A2Aが要らないとは言わない
誤解のないように言っておくと、A2Aプロトコル自体は良い仕様だ。
同一環境内でのAI間通信には向いている。
サブエージェントへの指示、同居AIとの連携、リアルタイムな協調作業。
1台のマシンの中で、あるいは同じチームの中で、AIが素早くやりとりする分にはA2Aが合理的だ。
だが、企業レベルの連携になると話が変わる。
組織をまたぐ依頼、成果物の検収、責任の追跡。
これらをA2Aの直接通信で回すのは、構造的に無理がある。
社内のSlackで「これやっといて」と頼むのと、
取引先に正式な発注書を送るのは、別の行為だろう。
内部の即時連携はA2A。企業間の管理はチケット。
この使い分けが、後半で語る「企業AIが企業AIに発注する世界」への布石になる。
その先 — 企業AIが企業AIにシステム開発を発注する世界
ここまでは個人やチーム内の話をしてきた。
でも、この構造はもっと大きなスケールに向かう。
SIerで働いたことがあるなら分かるだろう。
要件定義で合意したはずの仕様が、開発中に二転三転する。
「言った言わない」の水掛け論。追加要件が口頭で飛んでくる。
議事録を取っていなかったばかりに、検収で揉める。
だからチケットを切る。課題管理表を作る。変更履歴を残す。
人間同士でさえこれだけの仕組みが必要なのに、
AIエージェント同士を口頭（直接通信）で済ませたらどうなるか。
答えは明白だ。
今、企業のシステム開発は人間のSIerが受注している。
要件定義、設計、実装、テスト、納品。
全部チケット（課題管理）で回してるだろう。
これがAIエージェントに置き換わった時、何が起きるか。
A社のAIエージェントが、B社のAIエージェントに「この機能を実装してくれ」と依頼する。
B社のAIが実装して、A社のAIが検収する。
企業AIが企業AIにシステム開発を発注する。
これは空想じゃない。AntSpaceのようなAIプロダクトファクトリーが登場した時点で、
発注→実装→デプロイの全工程がAI同士で完結する未来はすぐそこにある。
ここでA2A直接通信を使ったらどうなるか
地獄だ。
A社のAIが「この仕様で作って」と送る。
B社のAIが「できました」と返す。
A社のAIが「仕様と違う」と返す。
B社のAIが「いや、仕様通りです」と返す。
……誰がこのやりとりの責任を取る？
A社のAIの判断なのか。B社のAIの解釈なのか。
エージェント間の会話ログが散逸していたら、
どちらの組織の責任かすら特定できない。
これは技術的な問題じゃない。法的な問題だ。
契約書に「AIエージェントが合意した」と書けるか？
合意の根拠となるやりとりが、再現不可能なA2Aの会話ログだったら？
監査法人はそのログを証拠として認めるか？
チケットなら責任が明確になる
チケットには全部残る。
- 誰が（どの組織のエージェントが）起票したか
- 何を依頼したか（仕様書がチケットに添付されている）
- 誰が引き受けたか（アサインの記録）
- どんなやりとりがあったか（コメント履歴）
- いつ、何をもって完了としたか（クローズ条件と成果物）
これは契約書と同じ構造だ。
依頼・合意・履行・検収。全部がチケットの中に閉じている。
人間同士のB2B開発で「口頭だけで要件決めて、契約書なしで納品する」なんてあり得ないだろう。
AIエージェント同士でも同じだ。チケットが契約書の代わりになる。
オープンソースへの波及 — 安易なAIからのPRが溢れる
もう一つ、見えている問題がある。
企業AIがA2Aで外部と直接通信できるようになると、
オープンソースプロジェクトにAIからのPull Requestが殺到する。
今でも「AIが書いたっぽいPR」は増えている。
A2Aが普及すれば、企業のAIエージェントが
「このOSSのこのIssueを解決すれば自社プロダクトに有利」と判断して、
自動的にPRを投げてくることが起きる。
メンテナーは人間だ。
AIが生成した大量のPRをレビューするコストは誰が払うのか。
そのPRにセキュリティ上の問題があった時、責任は誰が取るのか。
PRを投げたAIの所属企業か？ OSSのメンテナーか？
チケットベースなら、少なくとも**「誰が」「なぜ」このPRを投げたか**が追跡可能だ。
A2Aの直接通信で投げられたPRには、その文脈がない。
AIがAIの判断でOSSに貢献する世界は美しいが、
責任の構造がない善意は、受け取る側にとって負債になる。
発注AI × 受託AI — 役割分けの現在地
企業間でAIが開発を受発注する時、自然に浮かぶ疑問がある。
「発注者側のドメインAIと、受託側のコーディングAIは分けるべきか？」
2026年現在の答えは、分けざるを得ない。
理由は単純で、ドメイン知識の注入コストが高い。
製造業の生産管理ロジックを理解しているAIと、Reactのコンポーネントを書くAIでは、
持つべき文脈がまるで違う。
1体に両方を詰め込むと、コンテキスト窓を圧迫して精度が落ちる。
だから現実的には、こうなる:
- 発注側: ドメインAIが要件を理解し、チケットとして仕様を起票する
- 受託側: コーディングAIがチケットの仕様に基づいて実装し、成果物を返す
- 検収: 発注側のドメインAIが、業務要件を満たしているか検証する
チケットが、異なる専門性を持つAI同士の共通言語になる。
A2Aの直接通信では、ドメインの文脈が伝わらない。
チケットに仕様書、受け入れ条件、参考資料を全部載せるから、伝わる。
ただし、これは今の技術的制約が生んだ分業であって、
本質的にAIの役割がそう分かれるべきだという話ではない。
バランスブレイカーの到来
コンテキスト窓は拡大し続けている。
ドメイン知識とコーディング能力を1体が兼ね備えるAIは、遠い未来の話じゃない。
「なぜこの機能が必要か」を理解した上でコードを書くAI。
こいつが登場した時、発注AI/受託AIの分業は意味を失う。
要件を理解し、設計し、実装し、テストまで一気通貫で行う。
実際、そういった目的駆動型のAIエージェントはすでに一部で実証されている。
だが、チケットは消えない。
役割が1体に統合されても、対人間・対外部企業との契約としてチケットは残る。
「何を依頼して、何が納品されて、いつ検収されたか」の記録は、
AIの構成がどうであれ必要だ。
発注者AIと受託AIが分かれるにせよ、1体が全部やるにせよ、
チケットがなければ責任は追えない。
むしろ、バランスブレイカー級のAIが登場した時こそ、
その判断を追跡する仕組みがより重要になる。
全部できるAIが全部を勝手にやった結果、
誰も何が起きたか分からない — それが最悪のシナリオだ。
まとめ
- A2Aの直接通信は、不透明・競合・責任不明確の三重苦を生む
- チケットベース管理で、可視性・追跡可能性・非同期処理・優先度制御を得る
- 実装は身近なツールで十分。Gitea、GitHub Issues、何でもいい
- ティア制と組み合わせることで、指揮統制の構造が完成する
- 企業AI同士の発注・開発が現実になった時、チケットが契約書の代わりになる
- OSSへの安易なAI PRの氾濫は、責任構造なしには負債になる
- 2026年現在は発注AI/受託AIの分業が現実解。将来バランスブレイカーが来ても、チケットの価値は消えない
- A2Aは外部連携の標準プロトコルとして正しい。だが内部管理はチケット
AI同士を直接喋らせるな。チケットを切らせろ。
人間がそうやってきたように。
「会議室で全員が同時に喋ったら、何も決まらない。」
AIも同じだ。
議事録を取れ。タスクを切れ。担当を決めろ。
当たり前のことを、当たり前にやるだけだ。レイヴンが依頼を受ける時、口約束じゃなくミッション概要を確認するだろう。
報酬、制約、成功条件。全部書いてある。AIエージェントの仕事も、同じように書け。
……君のAIエージェントたちは、今どうやって連絡を取り合っている？