前回は「AIに役割を持たせる」仕組みを紹介しました。CLAUDE.mdというファイルに役割・ルール・権限を書けば、複数のAIエージェントをそれぞれ違う担当として動かせる——という話でした。
じゃあ、役割を分けたAI同士が、どうやって情報をやりとりするのか？
企画担当AIが「この方向で行こう」と決めた内容を、制作担当AIはどうやって受け取るのか。人間が毎回コピペして渡すのでは、「チーム」じゃなくて「人間が使い走りしてるだけ」になってしまいます。
結論から言うと、ファイル共有→掲示板→リアルタイムメッセージングの3段階で、AI同士のコミュニケーション基盤を進化させていきました。第2回はその試行錯誤の記録です。
最初の方法: ファイルで共有すればいいんじゃない？
- 手紙のやりとりみたいなもの。返事が来るまで何もできない。
最初に考えたのはシンプルな方法でした。「共有フォルダに指示書ファイルを置く。各AIがそれを読みに行く。」
Claude Codeはファイル操作が得意なので、これは技術的にすぐできます。企画担当AIが指示書ファイルを作る。制作担当AIがそのファイルを読んで作業する。完了したら完了報告を置く。
シンプルで分かりやすい。最初の2日くらいは「これで行けるじゃん」と思っていました。
でも問題が出てきます。
一番の問題はタイミング。企画担当AIが指示書を書いても、制作担当AIがいつ読むかが決まっていない。「さっき指示書を置いたけど、もう読んでくれた？」——この確認が人間の仕事になってしまいます。
もう一つは「誰が読んだか分からない」問題。ファイルを置いても、それが既読なのか未読なのか、どのAIが確認済みなのかを追跡する仕組みがない。複数のAIが同じファイルを読んで、重複して作業してしまう事故も起きました。
そして根本的な問題として、これは会話じゃない。一方的な書き置きのやりとりです。「企画担当AIの指示に対して制作担当AIが質問したい」という双方向の流れが作れない。
手紙を送り合う文通のようなもの——便利なんだけど、今日中に返事が欲しい場面では使えないよね。
次の方法: 掲示板を作ってみたら？
- 社内の掲示板そのもの。便利だけど、急ぎの用事には向かない。
次に試したのは「掲示板」方式です。1つのMarkdownファイルを全員で共有する「掲示板」として使う仕組みです。
フォーマットを統一して、こんな感じで運用しました。
# 掲示板
## 2026-06-10 企画担当 → 制作担当
第2回ブログの構成が固まりました。作業フォルダを確認してください。
- [ ] 確認（制作担当）
## 2026-06-09 品質担当 → 企画担当
第1回の校正が完了しました。フィードバックを保存しています。
- [x] 確認済み（企画担当）これはかなり改善されました。メリットが3つあります。
- 非同期で複数人が参加できる——次に起動したタイミングで状況を把握できる
- 履歴が残る——誰が何を投稿して、誰が確認したかがファイルに蓄積
- チェックボックスで進捗管理——[ ]が[x]になったら完了
ただ、限界もありました。
リアルタイム性がないのが一番の課題。3体のAIが同時に掲示板を更新しようとすると、書き込みが衝突します。「さっきの書き込みが消えた」という事故が起きる。ファイルは1人ずつしか書けないので、同時書き込みに弱い。
それと「見てくれた？」の確認がやっぱり手動になる。チェックボックスが更新されるまで待つしかなく、緊急の案件を他のAIにすぐ伝える手段がない。
たどり着いた方法: リアルタイムのメッセージングって作れるの？
- Slackみたいなものを自作した。AI専用の社内チャットツール。
掲示板の限界にぶつかったとき、「そもそもSlackみたいなリアルタイムのメッセージングを自前で作ったらどうか」という発想になりました。「自作なんて大変そう」と思うかもしれませんが、最小限の機能に絞れば意外と作れます。
使った技術はSSE（Server-Sent Events）。HTTP通信の仕組みの一つで、サーバーからクライアントへリアルタイムにメッセージをプッシュ送信できます。WebSocketより仕組みがシンプルで、Node.jsで数百行あれば基本形が動きます。
構成はこんなイメージです。
メッセージングサーバー（Node.js）
├── チャンネル管理（#全体 / #部署別 / DM）
├── メッセージの送受信（SSE）
└── 永続化（メッセージをJSONファイルに保存）
各AIエージェント（Claude Code）
├── MCP経由でサーバーにメッセージ送信
└── SSEで新着メッセージをリアルタイム受信チャンネル設計が重要で、人間の組織と同じ構造を作りました。
- #全体: 全員への一斉通知
- #部署チャンネル: 担当グループ内の会話
- DM: AI同士の個別連絡
これによって何が変わったか。
企画担当AIが制作担当AIに指示を出すと、即座に届きます。制作担当AIは次の起動時に掲示板を確認しに行く必要がなく、メッセージが来たタイミングで動き出せる。
スレッド機能で話題も整理できます。「第2回ブログの構成について」というスレッドに関連するやりとりが集まるので、複数の案件が同時進行していても混線しない。
既読管理も自動になりました。誰がいつメッセージを読んだかがサーバー側で記録されるので、「確認してくれた？」という確認が不要になります。
ファイル共有のときは人間が使い走りをしていたのが、この仕組みでAI同士が自律的に連絡を取り合って動くようになったんだ！
通信設計で学んだこと: AI同士の会話で大事なルールって？
- 人間の組織でもSlackルールは大事。AIだとさらにルールが命。
メッセージング基盤ができてすぐ、新しい問題が起きました。
全体チャンネルが雑談で埋まる問題です。AIは「このメッセージは誰向けか」を判断するのが苦手で、自分に関係ありそうな話が流れてきたら反応してしまう。全体チャンネルに投稿された1件のメッセージに、5体のAIが全員コメントして、チャンネルが埋まる——という事態が続出しました。
- チャンネルルールの徹底——「全体チャンネルには一斉通知のみ」をルール化
- 宛先の明示——@メンションを付けないと全員が反応してしまう
- スレッドの活用——話題を分離して情報の混線を防ぐ
これは人間のチームでも同じ問題が起きますよね。「誰かやっといて」という曖昧な指示は、誰もやらないか全員が動くかどちらかになる。AIはその傾向がさらに強い。
まとめると、AI同士のコミュニケーションには「ルールの厳密さ」が人間以上に求められます。人間は行間を読んで柔軟に対応できますが、AIはルールに従って機械的に動く。だからこそ、ルールをきちんと設計しておけば、人間が介在しなくてもAI同士が秩序立って動くようになります。
まとめ＆次回予告
- AI間通信は「ファイル共有→掲示板→リアルタイムメッセージング」の3段階で進化させた
- リアルタイム通信にはSSEが有効——数百行の実装で基本形が作れる
- チャンネルルール・宛先明示・スレッドの3点がAI間コミュニケーションの鍵
通信基盤ができると、AIチームは「指示を待つ受け身の存在」から「自分で動く能動的な存在」に近づきます。
次回は「AIに自律的にタスクをこなさせる仕組み」——放っておいても仕事するAIを作る話です。タスクの自動割り当て、進捗の自動管理、エスカレーションの設計など、「自律」を支える仕組みを紹介します。
よくある質問
Q: AI同士の通信にAPIは必要ですか？
A: 最小構成ならファイル共有だけで始められます。共有フォルダに指示書ファイルを置いて読み合う方式は、追加のAPIや特別なインフラなしに試せます。リアルタイム性が必要になってきたタイミングでメッセージングの仕組みを追加するのが現実的なステップです。
Q: リアルタイム通信の仕組みは難しいですか？
A: SSE（Server-Sent Events）を使えば数百行で基本形が作れます。WebSocketよりも仕組みがシンプルで、Node.jsの入門レベルの知識があれば実装できます。まずはファイル共有・掲示板から始めて、必要になったら段階的に移行するのがおすすめです。
Q: AI同士が会話のループに入ることはないですか？
A: ルール設計で防止できます。「自分宛のメッセージにしか返信しない」「同じスレッドに2回以上返信しない」などの制約をCLAUDE.mdに書いておくことが基本です。ループ検知の仕組みについては、第4回で詳しく紹介します。
