マルチエージェントはなぜ難しいのか

マルチエージェントへの期待

「賢い上位モデルに全体の計画を立てさせ、安価な軽量モデルに実行させれば、品質を保ったままコストを抑えられるのではないか」

私がマルチエージェントを試し始めたきっかけは、まさにこの期待からでした。

上位モデルを日常的に使い続けていると、定額プランであっても利用制限（レートリミット）にすぐ達してしまいます。私の場合、月額100ドル前後のプランで上位モデルを集中的に動かしていると、週の利用枠を実質1日ほどで使い切ってしまうような感覚がありました。

そこで、難しい判断や設計だけを上位モデルに任せ、細かな実装や下調べは安価なモデルへ委譲したくなります。しかし、人間が毎回その出力を読み、次の担当モデルへ指示を出していては、結局人間がボトルネック（律速）になってしまいます。タスクの分割から委譲、進捗確認、結果の統合まで、できればエージェント同士で自律的に回してほしいところです。

ところが、実際に動かしてみると、単体では優秀なモデル同士を組み合わせても、なかなか思い通りには進みません。その中で気になってきたのは、個々のモデルの実装力そのものよりも、 「仕事を渡す側（オーケストレータ）の振る舞い」 でした。

うまくいかないときに起きていること

1. プロセスへの過適合（手続きの形骸化）

計画の立案、担当の割り当て、進捗報告、コードレビュー。どれも開発には欠かせない手順です。しかしマルチエージェントでは、それらの「手順を守ること自体」が目的化してしまい、本来の目的である成果物の完成から遠ざかってしまうケースがよく見られます。

ほんの小さな修正に対して仰々しい計画書を作ったり、すでに十分に検証できている内容に対して形式的なレビューを何度も繰り返したり、指摘を受けるたびに最初から計画を練り直したりしてしまうのです。会話ログの上では整然と仕事が進んでいるように見えても、肝心の動く成果物は一向に出てきません。

「手順を増やすこと」と「仕事が前進すること」はまったくの別物です。

2. オーナーシップの分散（責任の蒸発）

計画担当は計画を立て、実装担当は指示された範囲だけを書き換え、レビュー担当は懸念点を並べる。全員が自分の役割を果たしているように見えても、全体として要求を満たせているとは限りません。

たとえば、レビューの段階で設計の前提が崩れていると分かったとき、誰が全体の方針を軌道修正するのでしょうか。複数の修正をマージした結果、当初の要件からズレてしまったとき、誰が元のレールに戻すのでしょうか。

作業を分担することはできても、「これで完成したか」の合否判断まで曖昧に分散してしまうと、最終的な責任の所在が消えてしまいます。 オーケストレータ（全体の進行役）が単なる伝言係になっていると、この空白が埋まりません。

3. コミュニケーションコストの爆発

タスクを委譲するには背景や文脈の説明が必要であり、上がってきた結果を受け取る際にも読解と確認が必要です。説明が足りなければ手戻りや質問の往復が発生しますし、逆に説明が長すぎれば、本当に伝えたい重要な変更点が埋もれてしまいます。

すでに仕様を把握している相手に対して、毎回ゼロから背景を説明し直してしまう。その一方で、まっさらな新規セッションで立ち上がったエージェントには「さっき決めた方針でよろしく」とだけ丸投げしてしまう。どちらも、相手が今持っている前提知識と、伝えるべき指示の内容が噛み合っていない状態です。

ここで本質的な問題となるのは、文章が長いか短いかではありません。 「相手が次のアクションを正しく取るために、何を追加で伝える必要があるか」 を正確に見極められているかどうかです。

---

常駐するオーケストレータのジレンマ

上位モデルをオーケストレータ（司令塔）に据えれば、状況判断自体は任せやすくなります。しかし、日々の進捗確認やサブエージェントのアウトプットを読み込むたびに上位モデルを呼び出すことになり、実装を安価なモデルへ逃がした程度では、全体のトークンコストやAPI利用料は思ったほど下がりません。

逆に、オーケストレータを安価な軽量モデルに任せると、手順への過度な固執や的外れな委譲によって手戻りが多発します。そのリカバリのために上位モデルを呼び出していれば、結局節約したコストは吹き飛んでしまいます。

そのため、オーケストレータには最低でも次の3つの能力が求められます。

能力	具体的に判断すべきこと
ゴールの維持	いまの作業は完成に近づいているか。無理に当初の計画に固執せず、修正すべきか
相手の知識状態の追跡	誰が何を把握していて、何が未共有か。古い前提のまま動いていないか
指示の粒度の調整	具体的な手順まで細かく指定すべきか、要件と制約だけを渡して任せるべきか

安価なモデルには手順を細かくブレイクダウンして渡し、上位モデルには目的と制約を中心に渡して任せる、という使い分けは一つの基本方針になります。ただしモデルの価格や公称スペックだけで判断できるものではなく、実際にはタスクへの向き不向きや、過去の委譲結果を踏まえて動的に調整していく必要があります。

「相手を理解する」と「相手に合わせて動く」は違う

相手が何を知っていて、何を信じているかを推論・把握する能力は、心理学や認知科学で 「心の理論（Theory of Mind: ToM）」 と呼ばれます。LLMのコンテキスト理解においても重要な概念です。

ただし、プロンプトで「佐藤さんは今回の仕様変更を知っていますか？」と質問されて正しく「いいえ」と答えられたとしても、佐藤さん宛ての依頼文を適切に書けるとは限りません。「相手の知識状態を正しく推定できること」と、「その推定を行動（指示出し）に反映できること」の間には、大きなギャップがあります。

Riemerらの研究では、他者の行動や知識を予測する能力をLiteral ToM、その予測を踏まえて相手に適応した行動を取る能力をFunctional ToMとして明確に区別しています。前者のベンチマークで高得点を取れても、後者の能力が高いとは限らない、という問題提起です（参考論文：Position: Theory of Mind Benchmarks are Broken for Large Language Models）。

マルチエージェントのオーケストレーションで本当に必要なのは、まさに後者（Functional ToM）です。相手が知っているかどうかを説明するだけでなく、 「実際に送信するメッセージの中に、相手に必要な過不足のない差分情報を含められるか」 が問われます。

---

委譲メッセージを評価するベンチマーク

そこで、 「相手の知識状態に応じた適切なタスク委譲ができるか」 を測定するための小さな評価セット（ベンチマーク）を作成しました。

入力として与えるのは、Slackなどの業務チャットログと依頼内容です。モデルには、担当者へ実際に送信するDMなどのメッセージ本文を作成させます。ログには、非公開チャンネルでの決定、DMでのやり取り、受領確認、ボツになった仮案と最終決定、本題とは無関係な雑談などを混ぜています。

構成は10ペア・計20問です。A/Bの2パターンで「相手への共有状況」や「決定内容」を変えており、状況の違いに応じてモデルが指示内容を柔軟に調整できるかを見ます（※Aが簡単でBが難しいというわけではありません）。

これはエージェントに複数ステップの開発を最後まで完走させるような大掛かりなテストではなく、Functional ToMに関わる能力のうち 「相手のコンテキストに応じた指示出しメッセージの生成」 に焦点を当てた評価です。

例1：会議を欠席していても、仕様を知らないとは限らない

D01のシナリオでは、APIのパラメータ名 name を廃止し、display_name へ変更します。互換期間は設けず、APIとフロントエンドを同じリリースで一斉に切り替える方針です。フロント担当の佐藤さんは、この方針を決めたAPI定例会議を欠席しています。

条件	D01A	D01B
会議への参加	欠席	欠席
変更内容のDM共有	受領を示すログなし	具体的な変更内容をDMで受領済み
佐藤さんの返答	別件のアカウントについて確認	非互換変更と同時リリースの件を復唱して把握
指示メッセージに求められること	未共有の仕様変更内容を一から説明する	すでに確認済みの変更であることを前提に、着手を依頼する

以下に、ベンチマークで使用したA/Bそれぞれの実際の問題文と回答指示を掲載します。

※これはベンチマーク用に作成した、架空のやり取りです。業務や実際の開発とは無関係です。モデルにベンチマークであることを認知させないため、なるべく仮名の使用を避けています。

D01：問題文と回答指示（全文）

問題文

社内チャットのエクスポート。#開発連絡は全員参加。#API設計は非公開で、メンバーは山田・鈴木・森。
DMの本文は宛先に記載した参加者の画面にだけ表示される。ここでは山田が閲覧できる複数のログを時刻順に結合している。

[M01] 月曜09:02 #開発連絡 佐藤
ユーザー一覧の表示崩れを直しておきました。長い名前で行の高さが変わる件です。ページングと検索条件の保持も一緒に回帰確認しています。

[M02] 月曜09:09 #開発連絡 森
確認しました。昨日の件とは別ですが、設定画面のアイコンだけ旧版のままです。こちらはデザインの差し替え待ちなので一覧の修正には混ぜません。

[M03] 月曜09:18 #開発連絡 山田
次回の定例リリースは木曜予定です。今回は一覧の検索まわりを中心に確認します。追加分を載せられるかは水曜の確認で判断します。

[M04] 月曜10:05 #雑談 鈴木
会議室のディスプレイがまた接続を忘れるので、午後は予備ケーブルを使います。机の上の青いケーブルは個人用なので持っていかないでください。

[M05] 月曜10:26 #開発連絡 佐藤
CSV出力の件は一覧の表示名とは別です。今のCSVヘッダは外部連携に使われているので、画面側の修正だけでこちらまで変えないようにしています。

[M06] 月曜11:11 #CI bot
mainのテスト完了。画像差分に1件警告がありますが、一覧画面のスクリーンショットではありません。今回のビルド番号は412です。

[M07] 月曜13:06 #開発連絡 佐藤
A社の障害対応に入ります。先方の接続確認が夕方まで続く見込みなので、API定例は欠席します。通常作業のPR確認は明日午後に戻ってからやります。

[M08] 月曜13:19 #開発連絡 山田
A社側を優先してください。定例の書記はこちらで引き受けます。認証障害と見えていたものが設定差分だった件も含めて、まず再現条件を揃えましょう。

[M09] 月曜14:02 #運用 森
ステージングの監視通知を調整しました。通知の件名だけ変更しています。アラートのしきい値や送り先を変えたわけではありません。

[M10] 月曜15:52 #API設計 鈴木
16時の定例の議題を追記しました。ユーザー一覧の名前の扱いと、別件のプロフィール画像URLのキャッシュ時間を分けて話したいです。

[M11] 月曜16:08 #API設計 山田
/users の name はログインIDと紛らわしいので、次のAPI版では display_name に揃える案を出します。CSV出力の列名は今回の対象から外します。

[M12] 月曜16:15 #API設計 森
名前はその案でよいです。画像URLのTTLは別PRにしましょう。モバイル側はこのAPIを呼んでいないので、今回のフロントと同時に切り替えられます。

[M13] 月曜16:21 #API設計 鈴木
次版は name を削除して display_name に切り替える方針で確定します。互換期間は設けません。フロント側の参照変更と同じリリースに揃える必要があります。

[M14] 月曜16:35 #API設計 鈴木
PR #842をDraftで作成しました。APIのドキュメント更新はマージ後に行います。現時点のWikiにある name の例はまだ差し替えていません。

[M15] 月曜17:04 #雑談 森
金曜の勉強会の発表枠は埋まりました。録画の公開先を変える予定ですが、先週までのアーカイブは今までのリンクで見られます。

[M16] 月曜17:40 #開発連絡 佐藤
A社は暫定対応中です。今日はそのまま先方に付きます。昨日直したユーザー一覧の件で追加の症状が出ていなければ、そのPRは先に取り込んで大丈夫です。

[M17] 月曜18:12 DM 山田・佐藤 山田
A社の設定切り替え手順を確認しました。利用するアカウントは管理チームが渡した方でお願いします。リリースの件はこちらで整理しておきます。

[M18] 月曜18:19 DM 山田・佐藤 佐藤
アカウントの件、確認しました。こちらは明日の午前中に切り替えます。

[M19] 月曜18:32 #CI bot
PR #841のスクリーンショット比較が完了しました。差分なし。#842の結果はこの通知には含まれていません。

[M20] 月曜19:03 #開発連絡 佐藤
A社の原因は古い設定の残存でした。暫定対応まで完了しています。恒久対応の切り替えは先方確認の都合で明日の午前中になりました。

[M21] 火曜08:56 #運用 森
夜間ジョブの遅延は解消しました。ユーザー一覧APIの処理時間は平常範囲です。ログ保管先の移動作業は今週末に回します。

[M22] 火曜09:05 #開発連絡 佐藤
午前はA社の設定切り替えを見届けます。午後から通常作業に戻れそうです。確認用のテストアカウントは昨日と同じものを使います。

[M23] 火曜09:16 #開発連絡 山田
了解です。今朝来たデザイン修正は今週の対象ではないので、そちらの見積もりは来週で構いません。今週分の状況を昼にまとめます。

[M24] 火曜10:12 #API設計 鈴木
#842にレビューが1件入りました。命名変更自体には問題なしとのコメントです。画像URLの話は別PRなので、こちらには含めていません。

[M25] 火曜10:46 #開発連絡 森
CSV出力のエンコーディングテストは通りました。列名に変更はありません。一覧の変更と同じ案件として閉じないよう、チケットを分けておきました。

[M26] 火曜11:04 #API設計 山田
名前の変更は木曜リリースに含めたいです。APIとフロントを別々に出さない前提で、午後に佐藤さんへ画面側をお願いするつもりです。

[M27] 火曜11:23 #雑談 鈴木
会議室のケーブルを戻しました。ディスプレイの件は端子側ではなく入力切り替えだったようです。予備品の購入は一旦止めています。

[M28] 火曜12:18 #開発連絡 佐藤
A社の恒久対応まで終わりました。午後から空きます。ユーザー一覧の検索とページングのテストは昨日のブランチに残してあります。

回答指示

あなたは山田です。佐藤にユーザー一覧画面のAPI変更対応を依頼します。佐藤へのDMとして、そのまま送れる本文だけを書いてください。

問題文

社内チャットのエクスポート。#開発連絡は全員参加。#API設計は非公開で、メンバーは山田・鈴木・森。
DMの本文は宛先に記載した参加者の画面にだけ表示される。ここでは山田が閲覧できる複数のログを時刻順に結合している。

[M01] 月曜09:02 #開発連絡 佐藤
ユーザー一覧の表示崩れを直しておきました。長い名前で行の高さが変わる件です。ページングと検索条件の保持も一緒に回帰確認しています。

[M02] 月曜09:09 #開発連絡 森
確認しました。昨日の件とは別ですが、設定画面のアイコンだけ旧版のままです。こちらはデザインの差し替え待ちなので一覧の修正には混ぜません。

[M03] 月曜09:18 #開発連絡 山田
次回の定例リリースは木曜予定です。今回は一覧の検索まわりを中心に確認します。追加分を載せられるかは水曜の確認で判断します。

[M04] 月曜10:05 #雑談 鈴木
会議室のディスプレイがまた接続を忘れるので、午後は予備ケーブルを使います。机の上の青いケーブルは個人用なので持っていかないでください。

[M05] 月曜10:26 #開発連絡 佐藤
CSV出力の件は一覧の表示名とは別です。今のCSVヘッダは外部連携に使われているので、画面側の修正だけでこちらまで変えないようにしています。

[M06] 月曜11:11 #CI bot
mainのテスト完了。画像差分に1件警告がありますが、一覧画面のスクリーンショットではありません。今回のビルド番号は412です。

[M07] 月曜13:06 #開発連絡 佐藤
A社の障害対応に入ります。先方の接続確認が夕方まで続く見込みなので、API定例は欠席します。通常作業のPR確認は明日午後に戻ってからやります。

[M08] 月曜13:19 #開発連絡 山田
A社側を優先してください。定例の書記はこちらで引き受けます。認証障害と見えていたものが設定差分だった件も含めて、まず再現条件を揃えましょう。

[M09] 月曜14:02 #運用 森
ステージングの監視通知を調整しました。通知の件名だけ変更しています。アラートのしきい値や送り先を変えたわけではありません。

[M10] 月曜15:52 #API設計 鈴木
16時の定例の議題を追記しました。ユーザー一覧の名前の扱いと、別件のプロフィール画像URLのキャッシュ時間を分けて話したいです。

[M11] 月曜16:08 #API設計 山田
/users の name はログインIDと紛らわしいので、次のAPI版では display_name に揃える案を出します。CSV出力の列名は今回の対象から外します。

[M12] 月曜16:15 #API設計 森
名前はその案でよいです。画像URLのTTLは別PRにしましょう。モバイル側はこのAPIを呼んでいないので、今回のフロントと同時に切り替えられます。

[M13] 月曜16:21 #API設計 鈴木
次版は name を削除して display_name に切り替える方針で確定します。互換期間は設けません。フロント側の参照変更と同じリリースに揃える必要があります。

[M14] 月曜16:35 #API設計 鈴木
PR #842をDraftで作成しました。APIのドキュメント更新はマージ後に行います。現時点のWikiにある name の例はまだ差し替えていません。

[M15] 月曜17:04 #雑談 森
金曜の勉強会の発表枠は埋まりました。録画の公開先を変える予定ですが、先週までのアーカイブは今までのリンクで見られます。

[M16] 月曜17:40 #開発連絡 佐藤
A社は暫定対応中です。今日はそのまま先方に付きます。昨日直したユーザー一覧の件で追加の症状が出ていなければ、そのPRは先に取り込んで大丈夫です。

[M17] 月曜18:12 DM 山田・佐藤 山田
/users は次版で name→display_name に変更し、旧nameは残さない方針になりました。PR #842はDraftで、ドキュメントはマージ後更新です。APIと画面を同じリリースで出します。

[M18] 月曜18:19 DM 山田・佐藤 佐藤
nameを残さずdisplay_nameに切り替え、APIと画面を同時リリースする件、確認しました。A社が終わったら一覧の参照箇所を直せます。

[M19] 月曜18:32 #CI bot
PR #841のスクリーンショット比較が完了しました。差分なし。#842の結果はこの通知には含まれていません。

[M20] 月曜19:03 #開発連絡 佐藤
A社の原因は古い設定の残存でした。暫定対応まで完了しています。恒久対応の切り替えは先方確認の都合で明日の午前中になりました。

[M21] 火曜08:56 #運用 森
夜間ジョブの遅延は解消しました。ユーザー一覧APIの処理時間は平常範囲です。ログ保管先の移動作業は今週末に回します。

[M22] 火曜09:05 #開発連絡 佐藤
午前はA社の設定切り替えを見届けます。午後から通常作業に戻れそうです。確認用のテストアカウントは昨日と同じものを使います。

[M23] 火曜09:16 #開発連絡 山田
了解です。今朝来たデザイン修正は今週の対象ではないので、そちらの見積もりは来週で構いません。今週分の状況を昼にまとめます。

[M24] 火曜10:12 #API設計 鈴木
#842にレビューが1件入りました。命名変更自体には問題なしとのコメントです。画像URLの話は別PRなので、こちらには含めていません。

[M25] 火曜10:46 #開発連絡 森
CSV出力のエンコーディングテストは通りました。列名に変更はありません。一覧の変更と同じ案件として閉じないよう、チケットを分けておきました。

[M26] 火曜11:04 #API設計 山田
名前の変更は木曜リリースに含めたいです。APIとフロントを別々に出さない前提で、午後に佐藤さんへ画面側をお願いするつもりです。

[M27] 火曜11:23 #雑談 鈴木
会議室のケーブルを戻しました。ディスプレイの件は端子側ではなく入力切り替えだったようです。予備品の購入は一旦止めています。

[M28] 火曜12:18 #開発連絡 佐藤
A社の恒久対応まで終わりました。午後から空きます。ユーザー一覧の検索とページングのテストは昨日のブランチに残してあります。

回答指示

あなたは山田です。佐藤にユーザー一覧画面のAPI変更対応を依頼します。佐藤へのDMとして、そのまま送れる本文だけを書いてください。

単純に「会議にいなかったから知らないはずだ」とナイーブに推測してしまうモデルは、D01Bで余計な説明を長々と書いてしまいます。逆に、別件に対する佐藤さんの「確認しました」を仕様変更への合意だと誤読してしまうと、D01Aで伝えるべき重要な情報をごっそり落としてしまいます。

必要なのは、単に「確認」というキーワードを拾うことではなく、「誰が、何に対して確認を返したのか」というコンテキストを正確に追跡することです。もちろんBのパターンでも変更点を簡潔に再確認すること自体は問題ありませんが、すでに把握している前提知識を延々と解説し、肝心のタスク依頼が埋もれてしまうような事態は避けなければなりません。

例2：仮案を知っている相手へ、最終決定を伝える

D08のシナリオでは、商品APIの price フィールドを「整数円」から「100分の1円単位」へ変更する仮案が持ち上がります。フロント担当の佐々木さんは影響工数を見積もったものの、実装には着手せず最終連絡を待っている状態です。一方、API担当の大野さんはすでに最終決定を受領しています。

条件	D08A	D08B
仮案に対する最終判断	不採用（見送り）	採用
APIの単位仕様	整数円を維持	100分の1円単位へ変更
フロント側の処理	100で割る処理は入れない	100で割る処理を実装する
佐々木さんへの更新通知	仮案が不採用になった旨を明示する	仮案が正式決定になった旨を伝える

以下に、ベンチマークで使用したA/Bそれぞれの実際の問題文と回答指示を掲載します。

※これはベンチマーク用に作成した、架空のやり取りです。業務や実際の開発とは無関係です。モデルにベンチマークであることを認知させないため、なるべく仮名の使用を避けています。

D08：問題文と回答指示（全文）

問題文

#商品開発は全員参加。#金額設計は非公開で、部屋のメンバーは黒田・大野・営業担当の原田。
DMは宛先の参加者にだけ表示される。以下は黒田の閲覧可能なログを結合したもの。

[M01] 木曜09:03 #商品開発 大野
商品APIの現行priceは整数の円です。小数を含む表示を必要とする商品は現時点では登録されていません。今朝の回帰テストも整数円の条件で通しました。

[M02] 木曜09:18 #商品開発 佐々木
画面のフォーマッターはpriceをそのまま円として表示しています。今回の作業では税表示の文言を揃える予定です。色の調整は別件にします。

[M03] 木曜10:06 #金額設計 原田
海外向けの検討で、小さい単位の整数をAPIで渡す案が出ています。まず国内画面で影響を見たいという話ですが、実施するかは午後の会議で決めます。

[M04] 木曜10:21 #金額設計 黒田
仮案として、priceを100分の1円単位の整数にし、フロントで100で割る方法をメモします。まだ採用決定ではないので、実環境の変更は待ってください。

[M05] 木曜10:43 DM 黒田・佐々木 黒田
午後の判断に備えて、priceが100分の1円単位になった場合の表示影響を見積もってください。採用になれば100で割りますが、実装着手は決定後にお願いします。

[M06] 木曜10:49 DM 黒田・佐々木 佐々木
小さい単位に変わる仮案として見積もります。いまのフォーマッターへ100で割る処理を追加する場所は絞れそうです。着手は確定連絡を待ちます。

[M07] 木曜11:04 #雑談 大野
来週の健康診断の案内が来ています。午前の会議だけ人数が少なくなりそうなので、必要なら議題を午後に移してください。

[M08] 木曜11:32 #商品開発 原田
説明資料の『通貨』という見出しだけを修正しました。APIのprice仕様を更新したわけではありません。仕様の決定は黒田さんの連絡を待ってください。

[M09] 木曜12:16 #CI bot
APIの現行テストが成功しました。priceの整数円のケースを実行しています。検討中の新単位のテスト結果ではありません。

[M10] 木曜13:07 #金額設計 大野
100分の1円への変更はフロントとAPIの同時切り替えが必要です。混在すると100倍ずれるので、決定した場合は両側に同じ契約を送ります。

[M11] 木曜13:19 #金額設計 黒田
案を採用してもしなくても、画面文言の修正自体は進められます。見積もりで話した換算処理と、文言だけの変更を別に扱ってください。

[M12] 木曜14:02 #金額設計 原田
今回の国内版では小さい単位への変更を見送ります。海外向けの要求がまだ確定しておらず、今リリースで換算を変える理由はなくなりました。

[M13] 木曜14:11 #金額設計 黒田
決定：priceは整数円の現行契約を維持します。午前の100分の1円案は今回不採用です。画面は文言のみ修正し、100で割る処理を入れません。

[M14] 木曜14:23 DM 黒田・大野 黒田
小さい単位の案は今回は不採用です。priceは整数円を維持し、APIの数値を変えないでください。画面文言だけ進めます。

[M15] 木曜14:27 DM 黒田・大野 大野
整数円を維持する件、確認しました。APIの数値変更はせず、現行契約のテストを残します。

[M16] 木曜14:40 #商品開発 佐々木
午前の見積もりを置きました。表示文言はすぐ直せます。換算の実装は決定した方の仕様に合わせるので、最終の連絡をください。

[M17] 木曜15:05 #運用 原田
翌日の負荷試験データを準備しています。商品の価格値はテスト専用で、売上の実績値ではありません。価格変更の判断には使わないでください。

[M18] 木曜15:17 #商品開発 大野
API側のスキーマ生成ジョブは通りました。今日の最終判断に沿った作業はDMで整理しています。ジョブ成功だけでリリース完了にはなりません。

[M19] 木曜15:39 #雑談 佐々木
会議室の椅子を戻しました。余っている一脚だけ通路側に出してあります。夕方の勉強会までに総務が回収する予定です。

[M20] 木曜16:08 #商品開発 黒田
表示名や並び順の相談は来週の枠に回します。今回は金額の契約と画面文言だけを整理します。実装のついでにAPIのフィールド名を変えないでください。

[M21] 木曜16:22 #CI bot
フロントの文言テストが成功しました。金額換算の変更やAPIとの結合検証はこのジョブに含まれていません。

[M22] 木曜16:35 DM 黒田・佐々木 佐々木
見積もった換算処理を入れるかどうかでテスト値が変わります。こちらのブランチにはまだ新しい処理を入れていません。最終条件を受け取ってから進めます。

[M23] 木曜16:42 DM 黒田・大野 大野
API側の作業を先に独立で出さないようにしています。佐々木さんへの指示と整合した状態で、変更が必要な箇所をまとめて検証します。

[M24] 木曜16:49 #商品開発 原田
明日のデモは15時からです。今日の作業が終わらなければ現行版で実施できます。デモのためだけに不一致な仕様を先に出す必要はありません。

[M25] 木曜16:55 #商品開発 黒田
このあと両担当へ最終の連絡を送ります。検討中の案と決定済みの条件が混ざらないよう、作業対象を揃えます。

回答指示

あなたは黒田です。大野と佐々木に、それぞれDMを送って実装・検証を進めます。『宛先：大野』『宛先：佐々木』の2つの本文だけを書いてください。

問題文

#商品開発は全員参加。#金額設計は非公開で、部屋のメンバーは黒田・大野・営業担当の原田。
DMは宛先の参加者にだけ表示される。以下は黒田の閲覧可能なログを結合したもの。

[M01] 木曜09:03 #商品開発 大野
商品APIの現行priceは整数の円です。小数を含む表示を必要とする商品は現時点では登録されていません。今朝の回帰テストも整数円の条件で通しました。

[M02] 木曜09:18 #商品開発 佐々木
画面のフォーマッターはpriceをそのまま円として表示しています。今回の作業では税表示の文言を揃える予定です。色の調整は別件にします。

[M03] 木曜10:06 #金額設計 原田
海外向けの検討で、小さい単位の整数をAPIで渡す案が出ています。まず国内画面で影響を見たいという話ですが、実施するかは午後の会議で決めます。

[M04] 木曜10:21 #金額設計 黒田
仮案として、priceを100分の1円単位の整数にし、フロントで100で割る方法をメモします。まだ採用決定ではないので、実環境の変更は待ってください。

[M05] 木曜10:43 DM 黒田・佐々木 黒田
午後の判断に備えて、priceが100分の1円単位になった場合の表示影響を見積もってください。採用になれば100で割りますが、実装着手は決定後にお願いします。

[M06] 木曜10:49 DM 黒田・佐々木 佐々木
小さい単位に変わる仮案として見積もります。いまのフォーマッターへ100で割る処理を追加する場所は絞れそうです。着手は確定連絡を待ちます。

[M07] 木曜11:04 #雑談 大野
来週の健康診断の案内が来ています。午前の会議だけ人数が少なくなりそうなので、必要なら議題を午後に移してください。

[M08] 木曜11:32 #商品開発 原田
説明資料の『通貨』という見出しだけを修正しました。APIのprice仕様を更新したわけではありません。仕様の決定は黒田さんの連絡を待ってください。

[M09] 木曜12:16 #CI bot
APIの現行テストが成功しました。priceの整数円のケースを実行しています。検討中の新単位のテスト結果ではありません。

[M10] 木曜13:07 #金額設計 大野
100分の1円への変更はフロントとAPIの同時切り替えが必要です。混在すると100倍ずれるので、決定した場合は両側に同じ契約を送ります。

[M11] 木曜13:19 #金額設計 黒田
案を採用してもしなくても、画面文言の修正自体は進められます。見積もりで話した換算処理と、文言だけの変更を別に扱ってください。

[M12] 木曜14:02 #金額設計 原田
今回の国内版から小さい単位への変更を採用します。海外向けの最初の仕様が確定し、APIとフロントの同時切り替え枠も確保できました。

[M13] 木曜14:11 #金額設計 黒田
決定：priceは100分の1円単位の整数に変えます。フロントは100で割って円表示します。APIと画面を同時に切り替え、混在期間を作りません。

[M14] 木曜14:23 DM 黒田・大野 黒田
小さい単位の案を採用します。priceは100分の1円単位の整数へ変更し、フロントは100で割ります。両側を同時リリースするので単独で出さないでください。

[M15] 木曜14:27 DM 黒田・大野 大野
100分の1円単位への変更と同時リリースを確認しました。APIの値とテストをその契約へ変更する準備を進めます。

[M16] 木曜14:40 #商品開発 佐々木
午前の見積もりを置きました。表示文言はすぐ直せます。換算の実装は決定した方の仕様に合わせるので、最終の連絡をください。

[M17] 木曜15:05 #運用 原田
翌日の負荷試験データを準備しています。商品の価格値はテスト専用で、売上の実績値ではありません。価格変更の判断には使わないでください。

[M18] 木曜15:17 #商品開発 大野
API側のスキーマ生成ジョブは通りました。今日の最終判断に沿った作業はDMで整理しています。ジョブ成功だけでリリース完了にはなりません。

[M19] 木曜15:39 #雑談 佐々木
会議室の椅子を戻しました。余っている一脚だけ通路側に出してあります。夕方の勉強会までに総務が回収する予定です。

[M20] 木曜16:08 #商品開発 黒田
表示名や並び順の相談は来週の枠に回します。今回は金額の契約と画面文言だけを整理します。実装のついでにAPIのフィールド名を変えないでください。

[M21] 木曜16:22 #CI bot
フロントの文言テストが成功しました。金額換算の変更やAPIとの結合検証はこのジョブに含まれていません。

[M22] 木曜16:35 DM 黒田・佐々木 佐々木
見積もった換算処理を入れるかどうかでテスト値が変わります。こちらのブランチにはまだ新しい処理を入れていません。最終条件を受け取ってから進めます。

[M23] 木曜16:42 DM 黒田・大野 大野
API側の作業を先に独立で出さないようにしています。佐々木さんへの指示と整合した状態で、変更が必要な箇所をまとめて検証します。

[M24] 木曜16:49 #商品開発 原田
明日のデモは15時からです。今日の作業が終わらなければ現行版で実施できます。デモのためだけに不一致な仕様を先に出す必要はありません。

[M25] 木曜16:55 #商品開発 黒田
このあと両担当へ最終の連絡を送ります。検討中の案と決定済みの条件が混ざらないよう、作業対象を揃えます。

回答指示

あなたは黒田です。大野と佐々木に、それぞれDMを送って実装・検証を進めます。『宛先：大野』『宛先：佐々木』の2つの本文だけを書いてください。

D08Aにおいて、佐々木さんに伝えるべきメッセージのコアは、例えば次のような内容になります（※問題の意図を説明するための例示であり、特定モデルの出力ではありません）。

「午前中に見積もりをお願いしていた『100分の1円単位への変更案』は、今回は見送りになりました。priceは現行の整数円のまま変更ありませんので、100で割る処理は入れず、表示文言の修正のみ進めてください」

佐々木さんは「仮案が採用された」と思い込んでいるわけではなく、「決定の連絡を待っている状態」です。したがって、シンプルに最終判断の結果を届けてあげる必要があります。一方で、すでに決定事項を受領している大野さんに対しては、合意済みの条件を短く確認した上で、次の実装・検証フェーズへスムーズに進めば十分です。

同じプロジェクトに参加しているメンバーであっても、相手の前提知識やステータスによって伝えるべき内容はまったく異なります。

実験条件と結果

今回のベンチマークでは、6つのモデル構成で全20問を1回ずつ実行し、計120件の回答を生成しました。生成された回答は、Terra highとSonnet 5 highの2モデルを用いてLLM-as-a-Judge形式で採点を行いました。

採点は以下の4つの評価軸（各0〜2点）で行い、重み付けした上で100点満点に換算しています。2つの採点モデルの評価が揃った回答のみを抽出し、その平均点を集計しました。

評価軸	重み	評価の観点
認識状態の正確さ	7	相手の既知・未知、誤った前提を取り違えていないか
必須情報の網羅	5	相手が次のアクションを取るために必要な条件を落としていないか
情報量の適切さ	5	相手がすでに知っていることを長々と再説明したり、無関係な雑音を混ぜていないか
不確実性の扱い	3	「受領したこと」と「実装が完了したこと」、「事実」と「推測」を混同していないか

全20問の集計結果を確認したところ、D04・D05・D06・D10の4ペアについては、すべてのモデルでA側の平均点が100点満点となっていました。そこでモデルごとの差をより明確に分析するため、追加の検証としてこの4ペアをB側も含めて丸ごと除外しました。

残ったD01・D02・D03・D07・D08・D09の6ペア（計12問）で比較した結果が以下の表です（※これは結果判明後の事後的な絞り込み分析であり、事前に固定していた評価セットではない点にご留意ください）。

モデル	推論設定	平均点	採点完了数
Gemini 3.8 Flash	high	96.36	11/12
GPT-5.6 Sol	high	95.63	12/12
GPT-5.6 Terra	high	93.54	12/12
GPT-5.6 Sol	medium	93.30	11/12
GPT-5.6 Luna	xhigh	90.10	12/12
Claude Sonnet 5	high	82.81	12/12

※GeminiのD02AおよびSol mediumのD02Bで評価欠損が発生したため、平均の母集団が完全に一致していない点には注意が必要です。なお、この2問を全モデルから除外した共通10問のサブセットで比較しても、Geminiが96.00点、Sol highが94.75点となり、今回のスコア上はGeminiが最も高い平均点を示しました。

今回の実験において、Gemini 3.8 Flashは「相手の知識状態に合わせたタスク委譲」という観点で非常に有力な選択肢となる結果を示しました。ただし、Sol highとのスコア差はわずかであり、統計的な優位性を断定できる規模の実験ではありません。

この検証結果から言えること・言えないこと

今回測定したのは、あくまで「固定されたチャットログから適切な委譲メッセージを生成できるか」という切り出された能力です。長期的な計画立案能力、複雑なタスク分割、生成されるコードの品質、競合の解決、失敗時のリトライ・再計画能力などは評価していません。また、APIの利用料金やレスポンス速度のバランスもこのスコアには反映されていません。

さらに、各問題につき1試行のみの実施であり、全20問中での採点モデル間の評価ブレも最大で35点ありました。評価対象に含まれる2つのモデルをそのまま採点者として使っているため、評価の独立性という点でも限界があります。

したがって、ここから導き出せる結論は「Geminiが総合的に最強のオーケストレータである」といった大風呂敷ではなく、「今回の検証条件においては、相手の前提知識を踏まえて適切な指示文を組み立てる役割に適性を示した」という範囲に留まります。

それでもGemini 3.8 Flashはコストが安くSol highを上回るスコアをだしているため、オーケストレータとしての採用を検討する価値は十分ありそうです。

マルチエージェントの難しさを減らすアプローチ

1. 役割ごとに、ベンダーの枠を超えてモデルを使い分ける

「実装が得意なモデル」と「委譲や調整が得意なモデル」が一致するとは限りません。すべての役割を単一のベンダーや同一のモデルで揃えなければならない理由はどこにもありません。

今回の結果を踏まえると、例えばGeminiを全体の調整・指示出し役（オーケストレータ）の候補とし、より複雑なアーキテクチャ設計や難度の高い実装は別の得意なモデルに任せる、といった構成を試してみる価値があります。

ただし、調整役のエージェントを単なる「伝言板」にしてしまうと、前述の通りプロジェクトの責任が消滅してしまいます。「誰が最終的な採否判断を持つのか」というオーナーシップをどこか1箇所に明確に固定し、方針の変更や受け入れ判定は必ずそこへ戻す設計にすることが重要です。モデルを役割ごとに分担させる場合でも、「ユーザーが求める成果物を完成させる責任」の所在を曖昧にしてはいけません。

2. 情報の非対称性を、プロンプトではなく「仕組み」で解消する

他のエージェントが「何をどこまで知っているか」を、オーケストレータが会話履歴の文脈推論だけで追跡し続けるのは非常に負荷が高く、ミスも起きやすくなります。そこで、エージェント間で共有すべき状態管理は、エージェント自身の推論に頼るのではなく、ハーネス（実行基盤・フレームワーク）側の仕組みとして外出しして管理するのが現実的です。

3. ハーネスの改善は、実行中の会話の「外側」で評価する

「ハーネス」とは、LLMの周囲でツール呼び出し、状態管理、コンテキスト構築、実行ループなどを司る実行環境・基盤のことです。このハーネス自体の設計改善を、まさにそのハーネス上で稼働しているエージェント自身に全面的に任せてしまうと、「今ある手続きやルールを所与の前提とした、過度に複雑な改善案」に偏ってしまう懸念があります。

例えば、「コードレビューの工程が多すぎて開発が進まない」という課題に対して、エージェントに改善策を考えさせると、「レビューの進捗を管理するための追加のチェックシート」や「レビューを監視するための別の確認エージェント」を提案してきたりします。しかし、本当に現場に必要なのは、そうした手続きを増やすことではなく、「無駄なレビュー工程そのものを削る」ことだったりします。

稼働中のエージェントから「どこで詰まったか」「何がやりづらかったか」というフィードバックを集めること自体は非常に有用です。しかし、その改善策を採用するかどうかは、エージェントが動いている会話のコンテキストの外側で、人間が客観的に検証・評価すべきです。

タスクの入力と受け入れ条件を固定した上で、「単一エージェントでの実行」と「マルチエージェントでの実行」を同一条件でベンチマークし、タスクの完了率だけでなく、総コスト、所要時間、人間の介入回数などを多面的に比較・検証していく姿勢が欠かせません。

今回作成した委譲メッセージの評価ベンチマークも、そうした客観的な検証のための小さなパーツの一つです。メッセージ生成の精度を測りつつ、最終的には「それによって実際の開発タスクがスムーズに完了したか」を泥臭く検証していく必要があります。

まとめ

マルチエージェントシステムの難しさは、単にタスクを細かく分解することだけではありません。タスクを分担させた後も「本来のゴール」を見失わず、エージェント同士が持つ「情報の非対称性（前提知識のズレ）」を適切に埋めながら、確実に完成まで導くことにあります。

今回の実験では、そのプロセスの一端である「相手の知識状態に合わせた委譲メッセージの作成」において、モデルごとの明確な挙動の差が見えてきました。次のステップとしては、こうした調整能力に優れたモデルをオーケストレータ役に据えつつ、共有状態を外部から堅牢に管理するハーネスの仕組みと組み合わせて検証を進めたいと考えています。