何が起きたか
Coral AI Labsと複数大学の研究チームが、AIエージェント間の非同期メッセージ通信層「AgentRadio」を発表しました。Apache 2.0ライセンスでGitHubに公開されており、Claude CodeやCodex CLIといった既存のエージェント実行環境そのものに手を入れる必要はありません。
検証には、本番稼働中のリポジトリに対する自然言語の長時間タスクを集めたベンチマーク「SWE-Atlas QnA」から124問が使われました。設問はシステム設計、根本原因分析、セキュリティ、API連携にまたがり、コードを読むだけでは解けず、実際にソフトウェアを動かして複数のコマンドを実行する必要があります。
結果は明快です。Claude Opus 4.6上のClaude Code単体が32.3%、AgentRadioを使ったフル構成が62.1%。DeepSeek V4 Proでも29.0%から50.8%へ伸びています。そして単体エージェントをOpus 4.8という上位モデルで走らせた57.2%を、4.6ベースのチームが上回りました。
なぜ重要か──「働いているエージェントは、聞いていられない」
論文がボトルネックとして名指ししたのは、モデルの知能ではなく構造です。「作業中のエージェントは、同時に聞くことができない」。ここが核心です。
単体エージェントが破綻する理由は「カバレッジ問題」と説明されます。1体はリポジトリを一本の直列パスで辿るしかなく、コンテキストが膨らむほど最初の計画を修正しにくくなり、調査の終盤で見つけた発見が全体に伝播しないまま終わる。難しいのはコードを読むことではなく、長い調査を通じて「未処理の宿題、依存関係、矛盾する証拠」を全部アクティブに保ち続けることだ、というのが研究者の見立てです。
既存のマルチエージェントは3つの欠陥パターンに分類されています。通信のない並列、ラウンドの境界でしか話せない同期型並列、そしてトップダウンのタスク配布だけで横方向のピア間チャネルを持たない「非同期の似姿」。要するに、作業の途中でヨコに話す手段がなかった、ということです。
3つのプリミティブと「受動的な気づき」
AgentRadioが提供するのは3つだけです。会話を開くcreate_thread、送信側をブロックせずに投稿するsend_message、そして自分宛のメンションが届くまで待ち、届いた時に全スレッドのスナップショットごと受け取るwait_for_mention。
この組み合わせが生むのが「passive awareness(受動的な気づき)」です。エージェントは本業を続けながら、実行ステップの合間に情報を受け取って知識を更新できる。実行中のコマンドを中断せずに、次の作業ステップで矛盾を取り込める設計です。
実装は、スレッドとメッセージを保持する独立プロセスのメッセージサーバーと、プリミティブごとに1本ずつ用意されたシェルスクリプト3本。要件は「エージェント環境がシェルコマンドをバックグラウンドで実行できること」だけで、あとはシステムプロンプトで監視役を1つ常駐させるよう指示します。ただしワーカーの起動、識別子の割り当て、共有サーバーへの接続、最終統合を担う薄いアダプタは別途必要で、これはモデルの外側に置かれる作業です。
MinIOの1問が示した差
最も雄弁なのが、オブジェクトストレージMinIOの実タスクです。正解にはリクエスト単位のサーバーログを確認する必要があり、これは初期計画の段階では誰も想定していませんでした。
非同期通信のないL2構成では、2体が別々に「ログが必要だ」と気づいたにもかかわらず、実行中にそれを共有できませんでした。1体は黙って諦め、もう1体は提案しないまま、チームは満場一致で誤答に合意し、5つの評価項目を落としました。AgentRadioを入れると、1体が必要なログ証拠を共有ワークログへ即座に流し、受動的に聞いていた他のエージェントがそのまま吸収して、16点満点を取りました。
チームに足りなかったのは、追加のエージェントでもレビュー工程でもありません。ある発見が、その価値が失われる前に適切な相手へ届くことだけでした。
コストと副作用
代償は明示されています。固定のチーム予算が必要なためトークン費用は膨らみ、1タスクあたりの平均API課金はOpus単体の2.96ドルに対しフル構成で19.45ドル。研究者自身が「税は現実だ」と認めています。
ただしこれは物量勝ちではありません。ほぼ同額の17.76ドルを使ってOpusの独立実行を6回回した対照実験では、解決率は37.9%にとどまりました。62.1%との差は、計算量ではなく構造から来ているという証拠です。
副作用も報告されています。エージェント間のチャーン、つまり通信はエージェントをより良い証拠へ導くこともあれば、正しい道から気を散らせることもある。常に速くなるわけではない、という点は押さえておくべきです。
💼 事業会社視点：これは自社にどう効くか
経営判断として使えるのは「責任のブレークポイント(responsibility breakpoints)」という判定軸です。研究者はこれを、有能なエンジニアが他人を巻き込む場面——作業が所有権の境界をまたぐ、独立した仮説が必要、別途の検証に値するリスクがある——と定義しています。人間の組織設計と同じ基準でAIの構成を決めろ、���いう話です。
受託開発・SI業では、引き継いだレガシーの調査、複数モジュールにまたがるリファクタ、依存関係の移行が該当します。ここは見積もり工数がブレる領域で、1タスク19.45ドルは人件費と比べれば議論の余地がありません。逆に、仕様が確定した1ファイル修正やボイラープレート生成に4体編成を当てるのは純粋な浪費です。「境界がはっきりし、局所的で、やり直せる作業」は1体で十分だと明記されています。
SaaS・EC事業者にとって効くのはインシデント調査とセキュリティ分析です。サービス横断の障害原因調査は、まさに1体が直列パスで辿ると証拠が伝播しない典型です。MinIOの例で本質だったのは「リクエスト単位のログを見る」という誰も計画に入れていなかった一手でした。自社の障害報告書を見直し、原因が「見るべき場所を最初に想定できていなかった」ケースが多いなら、複数体構成の投資回収は早いでしょう。
そして最上位の含意はモデル選定です。4.6のチームが4.8単体を上回った事実は、次期モデルを待つより自社の実行構造を設計し直す方が費用対効果が高い局面があることを示します。AIエージェント導入のKPIを「どのモデルを使うか」から「どこで情報を横に流すか」へ移す時期です。