マルチエージェントの引き継ぎ方式を155トークンのルーターに選ばせる──Routed Graph Handoff

複数のAIエージェントを連携させて動かすマルチエージェントシステムでは、エージェント同士がやり取りするメッセージ自体がトークン予算を大きく圧迫する。arXivで2026年8月26日に公開された論文（arXiv:2608.25277）は、この問題を「構造化された引き継ぎ形式」と「自然言語」のどちらを使うかを、タスクごとにルーターへ選ばせる方式で緩和しようとしている。著者はAmazon AGI（Sunnyvale, USA）のPratyay Banerjee氏とAnkit Chadha氏の2名。

3行まとめ

1. Amazon AGIの2名が提案する「Routed Graph Handoff」は、155トークン・オーバーヘッド0.15%の軽量LLMルーターが、委任1回ごとに型付き依存グラフ(8ノード種・7エッジ関係)と自然言語のどちらで引き継ぐかを判断する方式。
2. BrowseComp(150試行)・τ-retail(150組試行)・BFCL v3(600試行)・AppWorld(152組試行)の計1,052試行で評価し、τ-retailで圧縮率3.2倍時に+12.7ポイント(p<0.01)、BrowseCompで圧縮率2.2倍時に+8.7ポイント(p<0.05)、BFCL・AppWorldでは自然言語単独と同等の成績だった。
3. ルーターを外して常にグラフで委任するとAppWorldで-14.6ポイント悪化するが、ルーターがタスクごとにグラフ100%/自然言語0%〜グラフ11%/自然言語89%まで配分を変えることでこの悪化をほぼゼロに抑えている。オラクル分析ではまだ8.6ポイント分の伸びしろが残るとしている。

何と何を比較しているか

論文が出発点にしている観察はシンプルだ。

Multi-agent LLM systems coordinate through natural-language messages that consume 40--60% of their token budget. Replacing these with structured graphs reduces cost but fails on tasks requiring adaptive reasoning.

（マルチエージェントLLMシステムは、トークン予算の40〜60%を消費する自然言語メッセージを通じて連携する。これを構造化グラフに置き換えるとコストは下がるが、適応的な推論を要するタスクでは失敗する）

つまり「安いが融通が利かない構造化グラフ」と「高いが柔軟な自然言語」という2つの選択肢が両極にあり、どちらか一方に固定すると片方の弱点を引き受けることになる。論文の提案はこの二択そのものを固定せず、タスクの委任1回ごとに、どちらの形式を使うかを軽量なルーターに判断させるという設計だ。

グラフのスキーマ:8ノード種・7エッジ関係、τ-benchの47軌跡から反復設計

Native Graph Handoff（NGH）と呼ばれるグラフ形式は、各委任を「8種類のノード」（goal・constraint・entity・action・precondition・postcondition・tool_call・tool_arg）と「7種類のエッジ関係」（requires・targets・blocks・enables・depends_on・contradicts・follows）を持つ型付きDAG(有向非巡回グラフ)として表現する。このスキーマはτ-benchの47件の軌跡を使って反復的に設計されたと論文は説明している。最初はgoal・entity・action・constraintの4種類のコアノードから始め、エラー分析で見つかった2つの失敗パターン──(1)サブエージェントが前提条件チェックを飛ばす、(2)複数ステップのAPI呼び出し順序を間違える──に対応する形で、それぞれprecondition/postconditionノードとtool_call/tool_arg+depends_onエッジを追加したという。グラフを出力するオーケストレータにはClaude Sonnet 4.5を使い、AWS Bedrockの制約付きデコーディング（tool_use入力スキーマとして渡す）で、出力が必ずDAG構造に適合したJSONになるよう強制している。ファインチューニングや補助エンコーダは不要で、推論時のみのゼロショット手法だと述べられている。

論文はグラフ形式単体では不十分であることも強調している。受け手のエージェントには、ノードの種類・エッジの意味（例:depends_on＝先に完了させる必要がある）・トポロジカル順序での辿り方を明示する「グラフ対応の実行者プロンプト」が別途必要で、これを欠いた標準プロンプトのまま同じJSONを渡しても効果がゼロになり、τ-retailではこのプロンプトを外すとNGHが自然言語単独を下回る（このプロンプトを戻すと+12.7ポイントまで回復する）と報告されている。

ルーター:155トークン・0.15%コストの単一分類プロンプト

ルーターは委任のたびに1回の分類呼び出し（約155トークン、$0.0005）で、グラフか自然言語かを決める。プロンプトはベンチマーク固有の例を一切含まない抽象的な判断基準1つだけで構成され、「決定論的な回答が順序立ったサブタスクに依存するタスク（集計・複数ステップの検索・逐次的なAPI呼び出し）にはGRAPHを、反復・条件分岐・自由記述の解釈・適応的推論が必要なタスクにはNLを選べ」という指示になっている。論文が挙げる3つの設計上の工夫は次の通り。

• 保守的なデフォルト：依存チェーンのパターンが検出されない限りNLを選ぶ(NL側の機会損失をゼロにする)
• 決定論的：temperature=0、3回の独立実行で同一の判定結果になることを確認
• ドメイン非依存：BrowseComp(Web検索)・τ-bench(カスタマーサービス)・BFCL(関数呼び出し)・AppWorld(複数アプリのコーディング)の全てに同じプロンプトが使われる

実際のルーティング比率は、BrowseComp/τ-retail/BFCLで100%グラフ、AppWorldで11%グラフ・89%NL、τ-airlineで2%グラフだったと報告されている。同じ分類器がAppWorld単体でも11%/89%に分かれる(固定のベンチマーク単位ルールでは不可能な挙動)ことが、判断がタスク単位で行われている証拠だと論文は位置づけている。

ベンチマークと結果の数字

評価対象は4つの多様なマルチエージェントタスクで、BrowseComp(150試行、長期にわたるWeb検索)・BFCL v3(600試行、複雑なAPI呼び出し系列のBerkeley Function Calling Leaderboard)・τ-bench retail(150組試行＝50タスク×3シード、ツール呼び出しを伴うカスタマーサービス)・AppWorld(152組試行、条件分岐を伴う複数アプリのツール利用)で、合計1,052試行になる。オーケストレータはAWS Bedrock経由のClaude Sonnet 4.5で統一されている。

Routedは4ベンチマークすべてでNLと同等以上になっている。効率面では、圧縮率は加重平均で2.1倍（BrowseComp 2.2倍・τ-retail 3.2倍・BFCL 2.0倍・AppWorld 1.04倍）で、ルーター呼び出し(155トークン)とグラフ対応実行者プロンプト(約80トークン)を含めた委任1回あたりの総トークンで比較しても、グラフ経路はNLより少ない(τ-retailで461対730トークン、1.6倍)と報告されている。

論文はオーケストレータをClaude Sonnet 4.5からGPT-5 miniに差し替えた追試も行っており、BrowseComp 65→68%・BFCL 82→85%・AppWorld 50→52%と、いずれもRoutedがNL単独を上回る方向で結果が再現されたとしている。また、別の検証(Appendix F)ではClaude×Nova Proの組み合わせで不正なJSON出力が0%、圧縮率3.1〜3.6倍が維持されたとも報告されている。

残された伸びしろ

論文はオラクル分析（理想的な選択をした場合の上限を試算する分析）によって、現在のルーターにはまだ8.6ポイント分の追加の伸びしろがあると報告しており、実行時に適応的にルーティングする方向を今後の課題として挙げている。ライセンスはCC BY-NC-ND 4.0（非営利・改変禁止）。

査読状況とベンチマークのバージョンについて

arXiv掲載ページのComments欄には「Accepted in EMNLP 2026」と明記されている。EMNLP（Empirical Methods in Natural Language Processing）はNLP分野の主要会議の一つで、単なるプレプリント公開ではなく、査読を経て採択された論文だということがこの記載から分かる。提出履歴はv1のみ（2026年8月26日01:24:34 UTC、32KB）で、本記事執筆時点（curlで再確認済み）で改訂版は出ていない。またSemantic Scholarの書誌データベースでは、このarXiv IDに対応する論文の被引用数（citationCount）が0件だった。提出から日が浅い論文のため、外部からの引用による第三者評価はまだ存在しないことになる。

評価に使われた4ベンチマークのうち、BFCL（Berkeley Function Calling Leaderboard）については、Gorilla LLMチームの公式サイトで現行バージョンを確認できる。同サイトによれば、BFCLはv1（AST評価指標の導入）→v2（企業・OSS由来の関数の追加）→v3（マルチターンのやり取りの導入）→v4（holisticなエージェント評価への拡張、直近更新2026-04-12）という順で拡張されてきた。論文が使っているのは「BFCL v3」で、これはv3時点の「マルチターンのやり取り」を評価対象にしたバージョンであり、現在公式サイトで公開されている最新のv4（エージェント評価まで含む版）とは範囲が異なる点に注意したい。

ルーターの学習コスト・グラフの実装コードまでは確認していない

本記事はarXivのHTML全文（Abstract・Method・Experiments・Ablationの各セクション）をcurlで取得して書いている。ただしAppendix（A〜J）にある「NGHグラフの成功例・失敗例」「誤整合のアノテーション手法」「グラフ対応実行者プロンプトの全文」「クロスベンダー移植性」「トークン・レイテンシの詳細集計」は、本文中で言及されている数値以上には読み込んでいない。ルーター・グラフ生成に使われたプロンプトの全文、実際のグラフJSON出力例、評価に使ったコード自体は本記事の範囲では確認できていない。自分でマルチエージェントシステムにこの仕組みを実装して再現する検証も行っていない。「オーバーヘッド0.15%」「$0.0005」といったコスト数値は論文の自己報告であり、モデルAPIの料金体系や実行環境によって実際のコストは変動しうる。

関連記事: AIエージェントとは / MCPとは / Claude・GPT・Gemini API料金の読み方

感想・指摘はコメント欄へ。