第9章　AI同士が連絡するとき、何が必要か

9.1　導入：測定結果の伝達に定型は要るか

物理実験の授業で、隣の班から次のような報告を受けたとする。

「温度を測ったら、けっこう高かった」

この報告から、何が分かるだろうか。ほとんど何も分からない。すぐに疑問が浮かぶ。

  • 何の温度か（水か、空気か、金属か）
  • どの温度計で測ったか（水銀か、熱電対か、赤外線か）
  • 精度はどの程度か（±0.1℃か、±5℃か）
  • 単位は何か（℃か、Kか）
  • いつ測ったか
  • 「けっこう高い」とは何℃以上を指しているのか

これでは、測定結果をもとに自分の班の計算を進めることができない。

同じ状況を、定型の報告書式で伝え直すとどうなるか。

表 1: 定型の報告書式の例
項目 内容
測定対象 ビーカー内の水
測定器 デジタル温度計（分解能 0.1℃）
測定値 78.3℃
測定時刻 14:22
備考 加熱開始から15分後

同じ「温度を測った」という事実でも、書式が決まっているだけで受け取り手が計算に使える情報になる。

AI 同士が仕事の結果をやり取りする場面でも、まったく同じ問題が起きる。第7章で導入したサブエージェント（別担当）は、司令塔に要約を返すだけの一方通行であった。しかし、複数の担当が対等に連携して仕事を進めるとき——「調査結果をもとに構成を変えたい」「点検で見つかった問題を調査担当に差し戻したい」——相互のやり取りが必要になる。

口頭で「よろしく」と言うだけでは、誰が何を頼んだか、返事はどの依頼への応答か、承認されたのか保留なのかが曖昧になる。物理実験で危険な操作の指示を口頭だけで伝達したら事故の元であるのと同じように、AI 間の連絡にも定まった書式が要る。

本章では、この書式——プロトコル（protocol）——を設計する方法を学ぶ。

9.2　自由会話とプロトコルの違い

まず、自由会話と構造化されたプロトコルの違いを明確にする。

自由会話は、日常の対話と同じ形式である。相手に言いたいことを自然な文章で伝える。

「グラフできたよ。あと、文献リストも途中まで作ったから見てくれる？ それと、さっきの件は大丈夫だったよ」

この1文には、少なくとも3つの情報が混在している。

  1. グラフ作成の完了報告
  2. 文献リストの確認依頼
  3. 以前の依頼への応答（「さっきの件」）

人間同士なら文脈で分かるかもしれない。しかし、複数の担当が同時に動いているとき、「さっきの件」がどの依頼を指すかは曖昧である。担当が3人、4人と増えれば、混乱は加速する。

プロトコルは、やり取りに一定の形式を与える取り決めである。自由会話と異なり、「何について」「誰から誰へ」「どの依頼への応答か」を明示する。

block-beta
  columns 1
  A["<b>自由会話</b><br>A: 「グラフできたよ、あと文献も途中。さっきの件は大丈夫」<br>B: 「了解。じゃああれも頼む」 / C: 「え、何の件？」<br>→ 何の報告か、誰への依頼か、曖昧"]:1
  B["<b>プロトコル（構造化メッセージ）</b><br>#001 A→B  報告: グラフ作成完了<br>#002 A→B  依頼: 文献リストの確認<br>#003 A→C  応答: 依頼#098 に対し「完了」<br>→ 誰から誰へ、何について、どの依頼への応答か明確"]:1
  style A fill:#f8d7da,stroke:#dc3545
  style B fill:#d4edda,stroke:#28a745

自由会話と構造化メッセージの対比

自由会話は速いが記録が残りにくく、後から追跡しにくい。プロトコルは多少の手間がかかるが、やり取りの全体像を後から再構成できる。

物理実験の比喩で言えば、自由会話は「口頭での測定報告」、プロトコルは「実験ノートへの記録」に対応する。口頭の報告は速いが、後で「あのとき何を測ったか」が分からなくなる。実験ノートに定まった書式で記録しておけば、1年後でも再現できる。

ノートプロトコルは創造性を殺すのではなく、誤解を殺す

書式が決まっていると窮屈に感じるかもしれない。しかし、プロトコルの目的は表現を制限することではなく、解釈のずれを排除することにある。内容は自由に書ける。ただし「誰から」「誰へ」「何について」「どの件の続きか」だけは、必ず形式に従う。

9.3　メッセージの構造

プロトコルの中心にあるのはメッセージ——やり取りの最小単位——である。構造化されたメッセージには、少なくとも次の5つの要素が含まれる。

表 2: 構造化メッセージの5要素
要素 意味 例
送信者 誰が送ったか 調査担当
受信者 誰に向けた連絡か リード
種類 依頼・応答・報告・全体通知のいずれか 依頼（request）
依頼番号 どの依頼についての連絡か #003
内容 伝えたい本文 「文献調査の方針案を確認してください」

この5要素は、物理実験の測定記録と対応づけられる。

表 3: メッセージ要素と測定記録の対応
メッセージの要素 測定記録の対応
送信者 測定者の名前
受信者 報告先（班長、教員）
種類 測定報告・追加測定依頼・校正確認
依頼番号 測定番号（#M-003 等）
内容 測定値・条件・単位

なぜ依頼番号が重要なのか。複数のやり取りが同時に進行すると、「応答」がどの「依頼」に対するものか分からなくなる。依頼番号があれば、どんなに長いやり取りでも、1対1の対応が追跡できる。

物理実験で測定番号をつけるのと同じ理由である。100回の測定を行い、後から「第47回の測定条件を確認したい」となったとき、番号がなければ探しようがない。

メッセージの種類は、次の4つに分類できる。

  1. 依頼（request）：相手に仕事を頼む
  2. 応答（response）：依頼に対する返事（承認・却下・完了報告）
  3. 報告（report）：結果や進捗を伝える（特定の依頼に紐づかない）
  4. 全体通知（broadcast）：チーム全員に向けた連絡

この分類は、実験室の連絡でも自然に対応する。「追加測定をお願い」は依頼、「測定完了、結果は78.3℃」は応答、「装置の調子が悪い」は報告、「昼休憩に入ります」は全体通知である。

たとえば、実験チームで「本日の測定はすべて中止」という全体通知を送る場合、宛先を「全員」にして、送信者と内容を明記する。

ブロードキャストは便利だが、頻繁に使うと全員の作業が中断される。緊急連絡や全体方針の変更など、全員が知るべき情報に限定すべきである。

9.4　状態遷移：依頼から完了まで

依頼を送ったら、それで終わりではない。依頼には状態がある。

最も基本的な状態遷移は次の通りである。

stateDiagram-v2
    pending : 依頼送信 (pending)
    approved : 承認 (approved)
    rejected : 却下 (rejected)
    running : 実行中 (running)
    completed : 完了 (completed)
    reverted : 差し戻し (reverted)

    [*] --> pending
    pending --> approved
    pending --> rejected
    approved --> running
    running --> completed
    running --> reverted
    reverted --> pending : 修正して再依頼

依頼の状態遷移

図: 依頼の状態遷移図

それぞれの状態を説明する。

表 4: 依頼の状態一覧
状態 意味 次の遷移
保留中（pending） 依頼が送られたが、まだ受理も却下もされていない 承認 or 却下
承認（approved） 受け手が「引き受ける」と返答した 実行中
却下（rejected） 受け手が「引き受けない」と返答した（理由つき） 修正して再依頼 or 取り下げ
実行中（running） 作業が進行している 完了 or 差し戻し
完了（completed） 作業が終わり、結果が返された （終端）
差し戻し（reverted） 結果に問題があり、やり直しが求められた 修正して再依頼

重要なのは、状態がメッセージに明記されることである。「さっきの件、やっておきました」では、保留中の依頼が3つあった場合にどれのことか分からない。「依頼 #003 を completed に変更。結果は〜」であれば、曖昧さがない。

第4章で学んだ ToDo の3状態（未着手・進行中・完了）と構造は同じである。違いは、ここでは2者間のやり取りに状態がつく点にある。ToDo は自分の仕事の管理であったが、ここでは依頼と応答の対に対して状態を管理する。

物理実験で言えば、装置の使用許可申請が近い。

  • 申請書を提出する → 保留中
  • 教員が許可する → 承認
  • 教員が「条件を変えてください」と返す → 却下
  • 実験を実施する → 実行中
  • 実験完了の報告書を出す → 完了
  • 教員が「データに不備がある」と指摘する → 差し戻し

状態遷移を明示することで、「いま何が止まっているか」「次に誰が動くべきか」が一目で分かる。

9.5　物理実験の測定プロトコルとの対応

ここまでの概念を、物理実験の測定プロトコルと対応づけて整理する。

物理実験の測定プロトコルとは、測定結果を正しく記録し、正しく伝達するための取り決めである。実験室で暗黙に守られている規則の多くが、AI 間の通信設計と共通の構造を持つ。

表 5: 測定プロトコルとAI通信プロトコルの対応
測定プロトコルの要素 AI通信プロトコルの対応 なぜ必要か
単位の統一 メッセージ形式の統一 「高い」と「78.3℃」では情報量が違う。形式が揃わないと、受け手が処理できない
校正手順 送受信の動作確認 測定器を校正せずに測ると値が信用できない。通信も、形式通りに送受信できるか事前に確認する
測定番号 依頼番号（request ID） 100回測定して番号がなければ、どの結果か特定できない
報告形式の標準化 メッセージの5要素 報告書式が人によって違えば、集計できない
異常値の取り扱い規則 エラー・却下の手順 異常値を黙って捨てると全体の信頼性が崩れる。却下にも理由と手順が要る
記録の保存 メッセージ履歴の保持 実験ノートを捨てたら再現できない。通信記録がなければ、判断の根拠が失われる

この対応表から見えてくるのは、プロトコルの本質は「あとから追跡できること」にあるという点である。

実験の測定プロトコルは、「いま測定している人」のためだけにあるのではない。後から別の人が結果を検証し、再現し、疑問があれば遡って確認できるようにするためにある。AI の通信プロトコルも同じである。やり取りの最中に便利なだけでなく、後から「誰が何を依頼し、何が返り、どう判断されたか」を再構成できることに価値がある。

重要通信は文章力の問題ではなく、追跡可能性の問題である

AI 同士の連絡がうまくいかないとき、原因は「言い方が悪い」のではなく「構造がない」ことにある。追跡可能な構造——誰から、誰へ、何について、どの依頼への応答か——があれば、内容の表現が多少荒くても伝わる。逆に、どんなに丁寧な文章でも、構造がなければ後から再構成できない。

9.6　テンプレートで見る：構造化メッセージの送受信

9.3節のメッセージ構造を、テンプレートで確認する。構造化メッセージは、次の6項目を持つ受け渡し票として設計できる。

表 6: 受け渡し票テンプレート
項目 内容 例
送信者 誰が送ったか リード
受信者 誰に送るか 調査担当
種類 依頼 / 応答 / 報告 / 全体通知 依頼
依頼番号 やり取りを追跡するための番号 R-001
内容 メッセージの本文 文献調査の方針案を提出してください
状態 pending / received / completed pending

このテンプレートを使ったやり取りの例を示す。

表 7: やり取りの記入例
手順 送信者 受信者 種類 依頼番号 内容 状態
1 リード 調査担当 依頼 R-001 文献調査の方針案を提出してください pending
2 調査担当 リード 応答 R-001 方針案を作成しました。確認をお願いします completed

テンプレートの要点を整理する。

  1. 受信箱は担当ごとに管理する。自分宛のメッセージだけを確認する
  2. 6項目をすべて記入する。省略すると、後から追跡できなくなる
  3. 依頼番号（R-001） が送信と応答の両方に含まれるため、後から対応を追跡できる
  4. 状態を更新する。メッセージを削除するのではなく、pending → received → completed と状態を遷移させる

核心は、6項目を持つ受け渡し票を、担当ごとの受信箱を通じてやり取りすることである。

手順モデル：受信確認（ACK）の仕組み

  1. 受信箱を確認する
  2. 各メッセージの状態を「received（受信済み）」に更新する
  3. メッセージは削除せず、状態の更新だけを行う

メッセージを削除するのではなく状態を更新する点が重要である。これは第4章の ToDo 板と同じ発想だ。

9.7　第10章への橋渡し

本章では、AI 同士の連絡に構造化されたプロトコルが必要な理由を学んだ。自由会話では「誰から誰へ、何について、どの依頼への返答か」が曖昧になり、担当が増えるほど混乱が増す。メッセージの5要素と状態遷移を導入することで、やり取りの全体像が追跡可能になる。

ここまでの道具を振り返る。

  • 第7章：役割分担（サブエージェント）——仕事を別担当に切り出す
  • 第8章：依存関係——タスクの前後関係を設計し、並列化する
  • 第9章：通信の型（プロトコル）——担当同士のやり取りを構造化する

これで、複数の担当がそれぞれの仕事を持ち、依存関係に従って進め、構造化されたメッセージで連絡を取る——という仕組みが揃った。

しかし、ここまでの設計には共通の前提がある。「仕事は人間（またはリード）が割り振る」という前提である。タスクを分解するのもリード、依頼を送るのもリード、結果を確認するのもリードであった。

では、リードがいちいち指示しなくても、担当が自ら次の仕事を見つけて動くことはできないだろうか。

次の第10章では、共有されたルールとタスク表を見て自分で仕事を取る自律（autonomous）の仕組みを扱う。自律とは「自由放任」ではない。サーモスタットが設定温度の範囲内で自動的に動作するように、定められた規則の範囲内で自ら判断するという、制約つきの自発性である。

演習：紙のメールボックスでAIチームを動かす

形式：3〜5人1組、30分

役割：次の5つの役を割り振る（人数が少なければ兼任してよい）。

表 8: 演習の役割一覧
役割 仕事内容
リード 全体を統括し、依頼を出し、結果を承認する
調査担当 テーマに関する情報を集め、方針案を提出する
構成担当 調査結果をもとに資料の構成を設計する
点検担当 成果物を確認し、問題があれば差し戻す
記録係 すべてのメッセージカードを時系列で記録する

テーマ：以下から1つ選ぶ（または自分で設定してよい）。

  • 「高校生向けに”エネルギー保存則”の説明資料を作る」
  • 「新入生向けの大学生活ガイドを作成する」
  • 「研究室紹介のポスターを作成する」

準備物：

  • 各役に「個人ポスト」（封筒や箱）を1つ用意する
  • メッセージカードを20枚程度用意する

メッセージカードの書式：すべてのやり取りは口頭ではなく、メッセージカードで行う。カードには必ず次の5項目を書く。

項目 記入例
送信者 調査担当
受信者 リード
依頼番号 #003
種類 依頼 / 応答 / 報告 / 全体通知
内容と状態 方針案を提出します（pending → approved を待つ）

手順：

  1. タスク割り振り（5分）：リードがタスクを分担し、各担当に依頼カードを送る
  2. 作業と連絡（15分）：
    • 調査担当が方針案をまとめ、リードに「依頼（plan request）」として送る
    • リードが内容を確認し、「承認（approved）」か「却下（rejected＋理由）」を返す
    • 構成担当が調査結果をもとに構成案を作る
    • 点検担当がリードに「停止依頼（shutdown request）」を送る例も入れる
  3. 振り返り（10分）：記録係が集めたカードを時系列に並べ、全体を振り返る

振り返りの問い：

  • 口頭で済ませたくなった場面はどこか。なぜ口頭が「楽」に感じるのか
  • 依頼番号がなかったら、応答の対応づけはできたか
  • 承認・却下のような重要な判断を、口頭だけで行うとどんなリスクがあるか
  • 記録係のメッセージ一覧から、全体の流れを再構成できたか

発展（アプリで試す）：Codex App で、2つのスレッドを並列に開始し、それぞれに「調査担当」「構成担当」の役割を指示せよ。両方の完了後、差分を確認し、どの変更を採用するかを記録せよ。

章末課題

課題：自分の学習支援AIチームの通信規約を設計する

自分の学習や学生生活に関わる課題を1つ選び、そのための AI チームの通信規約を設計せよ。

想定するチームの例：

  • 実験レポート作成支援チーム
  • 発表資料作成支援チーム
  • 卒研の文献整理支援チーム
  • 就活書類作成支援チーム

必須項目：

  1. チーム構成：メンバーの役割一覧（3〜5名）。各メンバーの担当範囲を明記する
  2. 共有タスク表の項目設計：タスク表に載せる項目（タスク名、担当者、状態、依存関係、期限など）を定義する
  3. メッセージに必ず含める項目：9.3節の5要素を参考に、自分のチームに必要な項目を決める
  4. request-response が必要な場面を2つ：どんな依頼に対して、誰が承認・却下する必要があるかを具体的に記述する
  5. 承認・却下の基準：approve / reject を判断する基準を明示する
  6. 最終的に人間が確認すべき通信：すべてをAIに任せず、人間の判断が必要な場面を特定する

提出形式：通信規約の設計書（A4で1〜2枚相当）。図を含めてよい。

評価観点：

  • 通信が追跡可能か（依頼番号、状態管理がある）
  • 依頼と応答が対応づくか（request-response の対が明確）
  • 高リスク操作（提出・削除・大幅な方針変更）に承認手順があるか
  • 通信規約が簡潔で運用可能か（過剰に複雑でないか）
  • 第7章（役割分担）、第8章（依存関係）の考え方と整合しているか

第9章のまとめ

本章では、AI 同士の連絡にプロトコル（protocol）——構造化された通信の型——が必要な理由と、その設計方法を学んだ。

要点を整理する。

  1. 自由会話は速いが曖昧さが残り、担当が増えるほど混乱が加速する。構造化されたプロトコルを導入することで、やり取りの全体像が追跡可能になる
  2. 構造化メッセージには5つの要素がある。送信者、受信者、種類（依頼・応答・報告・全体通知）、依頼番号、内容。特に依頼番号は、複数のやり取りを追跡するための鍵である
  3. 依頼には状態がある。保留中→承認→実行中→完了、あるいは却下→再依頼、差し戻し→修正。状態をメッセージに明記することで、「いま何が止まっているか」が一目で分かる
  4. 物理実験の測定プロトコル（単位の統一、校正手順、測定番号、報告形式の標準化）とAI間の通信プロトコルは、同じ構造を持つ。いずれも「あとから追跡できること」が本質である
  5. AI 同士の協力は「話せること」ではなく、「通信を追跡できること」で成り立つ。通信の問題は文章力の問題ではなく、構造の問題である

次の第10章では、「自分で仕事を見つけて動く AI」——共有ルールの範囲内で自律的に判断するエージェントの設計を扱う。