AI同士ってどうやって会話させるの？——チャットシステムを自作した話【AIチーム連載 第2回】

前回は「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つあります。

ただ、限界もありました。

リアルタイム性がないのが一番の課題。3体のAIが同時に掲示板を更新しようとすると、書き込みが衝突します。「さっきの書き込みが消えた」という事故が起きる。ファイルは1人ずつしか書けないので、同時書き込みに弱い。

それと「見てくれた？」の確認がやっぱり手動になる。チェックボックスが更新されるまで待つしかなく、緊急の案件を他のAIにすぐ伝える手段がない。

たどり着いた方法: リアルタイムのメッセージングって作れるの？

掲示板の限界にぶつかったとき、「そもそもSlackみたいなリアルタイムのメッセージングを自前で作ったらどうか」という発想になりました。「自作なんて大変そう」と思うかもしれませんが、最小限の機能に絞れば意外と作れます。

使った技術はSSE（Server-Sent Events）。HTTP通信の仕組みの一つで、サーバーからクライアントへリアルタイムにメッセージをプッシュ送信できます。WebSocketより仕組みがシンプルで、Node.jsで数百行あれば基本形が動きます。

構成はこんなイメージです。

メッセージングサーバー（Node.js）
├── チャンネル管理（#全体 / #部署別 / DM）
├── メッセージの送受信（SSE）
└── 永続化（メッセージをJSONファイルに保存）

各AIエージェント（Claude Code）
├── MCP経由でサーバーにメッセージ送信
└── SSEで新着メッセージをリアルタイム受信

チャンネル設計が重要で、人間の組織と同じ構造を作りました。

これによって何が変わったか。

企画担当AIが制作担当AIに指示を出すと、即座に届きます。制作担当AIは次の起動時に掲示板を確認しに行く必要がなく、メッセージが来たタイミングで動き出せる。

スレッド機能で話題も整理できます。「第2回ブログの構成について」というスレッドに関連するやりとりが集まるので、複数の案件が同時進行していても混線しない。

既読管理も自動になりました。誰がいつメッセージを読んだかがサーバー側で記録されるので、「確認してくれた？」という確認が不要になります。

通信設計で学んだこと: AI同士の会話で大事なルールって？

メッセージング基盤ができてすぐ、新しい問題が起きました。

全体チャンネルが雑談で埋まる問題です。AIは「このメッセージは誰向けか」を判断するのが苦手で、自分に関係ありそうな話が流れてきたら反応してしまう。全体チャンネルに投稿された1件のメッセージに、5体のAIが全員コメントして、チャンネルが埋まる——という事態が続出しました。

これは人間のチームでも同じ問題が起きますよね。「誰かやっといて」という曖昧な指示は、誰もやらないか全員が動くかどちらかになる。AIはその傾向がさらに強い。

まとめると、AI同士のコミュニケーションには「ルールの厳密さ」が人間以上に求められます。人間は行間を読んで柔軟に対応できますが、AIはルールに従って機械的に動く。だからこそ、ルールをきちんと設計しておけば、人間が介在しなくても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回で詳しく紹介します。

この連載の他の記事

• AIチーム連載 第1回
• AIチーム連載 第2回（この記事）
• AIチーム連載 第3回
• AIチーム連載 第4回

あわせて読みたい

• ChatGPT・Gemini・Claude比較