9月10日、Towards Data Scienceが「Optimizing LLM Inference Costs in Multi-Agent Systems with Adaptive Model Routing」と題した記事を公開した。この記事では、マルチエージェントシステムにおいてLLM推論コストを最大94%削減できる「適応型モデルルーティング」アーキテクチャについて詳しく紹介されている。
背景：マルチエージェント普及とともに顕在化したコスト問題
LLMを複数組み合わせて複雑なタスクを自律的に処理する「マルチエージェントシステム」は、ここ数年で急速に実用化が進んだ。Planner・Researcher・Analyst・Critic・Reporterといった役割を持つエージェントが連携し、調査・分析・報告を一気通貫でこなす構成は、企業の情報収集や意思決定支援の現場で広く採用されつつある。
しかしその普及と裏腹に、LLMの推論コストは企業にとって無視できない負担になっている。GPT-4oやClaude 3.5 Sonnetといった高性能モデルは1Mトークンあたり数ドルから十数ドルの費用が発生し、エージェントが並列・連鎖的に動作するシステムでは1クエリあたりのコストが容易に1ドルを超える。スタートアップから大企業まで、「どのタスクにどのモデルを使うか」の最適化は切実な課題だ。
問題の本質：全タスクを最強モデルで処理するのは無駄である
マルチエージェントシステムの単純な設計では、すべてのエージェントに最上位モデルを使いがちだ。しかし、単純なWebサーチも複雑な契約リスク分析も同じモデルで処理するのは、コスト面で非合理的である。
クエリの種類が予測可能であれば、エージェントの役割に応じてモデルを静的に割り当てれば済む。だが、組織の複数部門をまたぐような汎用アシスタントでは、データソースやコンテキストが実行時にしか確定しない。静的な割り当ては破綻する。
核心アイデア：「分類は実行より安い」
この記事が提案するAdaptive Agent Model Routerの設計思想は2点に集約される。
計画をフロントに集中させず、各エージェントへ分散させる。巨大なGlobal Plannerを1つ置くと、上流がデータを集める前に下流タスクを推測しなければならない「コンテキスト盲目」問題が生じる。代わりに、各エージェントが自分のターンに軽量なPlanner Agentを動的に呼び出し、そのエージェント固有のサブタスクをJust-In-Time（必要なタイミングで必要な分だけ）生成する。
タスクの複雑度を判定する分類は、タスク実行よりはるかに安い。高速・低コストの分類モデルでタスクの難易度を判定し、その結果に基づいて本番モデルを選択すれば十分な精度が得られる。
ルーティングの仕組み
ルーターは各サブタスクを3つの軸でスコアリングする：
| 軸 | Low(0) | Medium(1) | High(2) |
|---|---|---|---|
| Complexity | 事実検索、フォーマット | 要約、比較 | 多段推論、統合 |
| Reasoning | 直接参照 | パターン認識 | 論理推論、ギャップ分析 |
| Context Size | 2k tokens未満 | 2k〜6k tokens | 6k tokens超 |
3軸の合計スコア（0〜6）でモデルティアを決定する：
- 0〜2点 → Fast tier（軽量・高速モデル）
- 3〜4点 → Balanced tier（中間モデル）
- 5〜6点 → Powerful tier（最上位モデル）
特筆すべきはContext Sizeの扱いだ。マルチエージェントパイプラインではコンテキストが累積する。Researcherは小さなプロンプトで始まるが、Analystはその出力を引き継ぎ、CriticはResearcherとAnalyst双方の出力を受け取る。Reporterが動く頃には7,000〜8,000トークンに達することもあり、これだけでスコアがPowerful tierに引き上げられる。
コンテキストサイズはLLMに推測させるのではなく、tiktoken（OpenAIが提供するトークナイザーライブラリ）で決定論的に計算する設計が採用されている：
def calculate_exact_context_size(prompt: str, accumulated_context: list[str]) -> int:
encoder = tiktoken.get_encoding("o200k_base")
full_payload = prompt + "\n".join(accumulated_context)
token_count = len(encoder.encode(full_payload))
if token_count < 2_000: return "small"
if token_count < 6_000: return "medium"
return "large"
LLMはComplexityとReasoningの定性評価だけを担い、コンテキストサイズは実測値で決める。この分業が精度と速度を両立させている。
実験結果：コスト削減は「クエリの難易度に正比例」する
3種類のクエリで検証した結果が興味深い：
| クエリ | 適応型コスト | 全Powerful時のコスト | 削減率 |
|---|---|---|---|
| ☁️ クラウドコンピューティングの利点とリスク | $0.05 | ~$0.96 | ~94% |
| ⚡ 再エネvs化石燃料の経済インパクト | $0.63 | ~$0.84 | ~25% |
| 🔬 ML再現性危機のフレームワーク設計 | $1.41 | ~$1.62 | ~13% |
クラウドコンピューティングのような汎用クエリではほぼすべてのステップがFast/Balancedに収まり、94%削減を達成した。一方、ML再現性危機のような本質的に難しいクエリでは、CriticエージェントのすべてのサブタスクがHigh Complexity・High Reasoningと評価され、Powerful tierに集中した。削減率は13%にとどまるが、これは「コストを妥協してでも安く抑える」のではなく「本当に高度な処理が必要だと正直に評価した」結果だ。
同一エージェント内で連続するステップでも、コストに最大14倍の差が生じるケースも示されている。AnalystのあるステップはBalanced（$0.0091）、次のステップはPowerful（$0.1335）という結果だ。エージェントの「役割ラベル」ではなく、個別タスクのセマンティックな重みで判断している点が従来の静的割り当てとの最大の違いである。
アーキテクチャ構成
実装はFastAPI（バックエンド）とReact/Vite（フロントエンド）で構成される。エージェント間の結果受け渡しにはSSE（Server-Sent Events）ストリーミングエンドポイントを採用しており、ルーティング決定がリアルタイムに流れ、エージェントカードとコスト累計がステップごとに更新される。
モデルのラベルと料金は環境変数で設定する設計になっており、特定のLLMプロバイダーに依存しない点も実用上の強みだ。OpenAIのモデルをベースに構築したシステムであっても、AnthropicやGoogleのモデルに差し替えることが容易で、将来的なプロバイダー乗り換えや複数プロバイダーの混在運用にも対応しやすい。
ルーター自体の呼び出しコストについても言及がある。分類ステップに高速・低コストモデルを使うことで、ルーティング判定そのもののオーバーヘッドを最小限に抑える設計になっており、「分類コストが節約分を食い潰す」という本末転倒を避けている。
詳細はOptimizing LLM Inference Costs in Multi-Agent Systems with Adaptive Model Routingを参照していただきたい。
