エージェントシステムにルーターを組み込むことは、簡単に成果を得られる方法（Easy Win）のように思えます。シンプルなリクエストは安価なモデルに送り、高価なモデルはより困難なタスクのために残しておく。あるいは、得意分野に応じてルーティングする。コードは Claude に、マルチモーダルは Gemini に、といった具合です。分類器やヒューリスティックなルールで決定を下せば、コストは下がり、パフォーマンスは維持されます。これで完了です。
しかし、現実はそう甘くありません。多くのルーティングシステムは、モデルの選択を単なる分類問題として捉えています。私たちがエージェントシステムでルーティングを構築してきた経験から言うと、一見モデル選択の問題に見えるものは、すぐにシステム最適化の問題へと変化します。この取り組みを予想以上に難しくしている3つの次元があります。
1. コストは単なるモデルの価格設定ではない
私たちは当初、GPT-4.1 の方が Claude Sonnet 4.6 よりも安価になると考えていました。しかし、結果は違いました。
AppWorld Test Challenge の 417 個のタスクにおいて、同じ CodeAct エージェントを使用した場合、Sonnet の総コストは 79 ドル（1タスクあたり 0.19 ドル）であったのに対し、GPT-4.1 は 155 ドル（1タスクあたり 0.37 ドル）と、ほぼ2倍に達しました。カタログスペック上の価格だけを見れば、これはまったく辻褄が合いません。GPT-4.1 は入力および出力トークンの価格がどちらも安く、さらに Sonnet が同じタスクを完了するのに必要な推論ステップ数は GPT-4.1 の約3倍でした。提示されている価格表だけを見れば、GPT-4.1 が簡単に勝つはずだったのです。
原因は何でしょうか？キャッシュです。これは、ほとんどのルーティングに関する議論で完全に無視されている要素です。
エージェントのワークロードは、複数のステップ間で大量のコンテキストを再利用する傾向があります。キャッシュヒット率が高くなると、実質的な入力コストは大幅に低下します。Sonnet のキャッシュ読み取り価格の安さは、このパターンにおいてより大きな恩恵をもたらし、基本価格の高さや推論ステップの長さを相殺するのに十分でした。
結論として、実際のコストはモデル、ワークロード、そして提供インフラの相互作用によって決まります。価格表だけを見て判断するルーターは、誤った指標に基づいて最適化を行っていることになります。
2. 複雑さは単なるタスクの難易度ではない
一般的なルーティング戦略は、タスクの難易度を見積もり、より難しいタスクをより強力なモデルに送るというものです。この考え方は直感的ですが、2つの問題があります。
第一に、タスクの難易度はルーティングの時点では見えないことが多いという点です。「この契約書を要約して」というリクエストは一見シンプルに見えますが、完了するまでにリトリーバル（検索）、コンプライアンスチェック、ツール呼び出し、および複数回の推敲が発生する可能性があります。一方で、高度に技術的なプロンプトであっても、より小規模で専門化されたモデルによって効率的に処理できる場合もあります。タスクが実際にどれほど難しいかは、実行が開始されるまで分からないのが一般的です。
第二に、難易度を完璧に見積もれたとしても、それは数あるシグナルの1つに過ぎないという点です。本番環境において、ルーターはコスト、レイテンシ、モデルの得意分野、および信頼性のバランスを同時に取る必要があります。さらに、エンタープライズ環境でのデプロイには、コンプライアンス要件、データ常駐ルール、プライバシー制限、承認済みモデルのリストなど、より多くの制約が課されます。理論上はあるモデルに割り当てるべきタスクであっても、ガバナンス要件によって別のモデルに送らなければならない場合があり、ルーターはこうした状況をスマートに処理しなければなりません。
ルーターが解決しているのは、単一の問題ではありません。コスト、品質、レイテンシ、コンプライアンス、および信頼性のバランスを常に同時に天秤にかけているのです。
3. レイテンシは単なるモデルの速度ではない
モデルのサイズだけでレイテンシを理解しがちです。つまり、大きいモデルは遅く、小さいモデルは速いという認識です。しかし、ユーザーが実際に体感するエクスペリエンスは、それよりもはるかに複雑です。
ルーティング自体がオーバーヘッドをもたらします。モデルがどのハードウェアで動作しているか、キャッシュがウォームアップされているか、エンドポイントがどれほど混雑しているかといったインフラストラクチャの要因が、エンドツーエンドの応答時間を左右することがよくあります。理論上は高速なモデルであっても、サービング条件が適切でなければ、最終的な体感速度は遅くなる可能性があります。
さらに、ルーティングの粒度の問題もあります。タスクごとに1回だけルーティングする場合、オーバーヘッドは最小限に抑えられます。しかし、実行プロセスの中でより柔軟に調整するためにステップごとにルーティングを行うと、意思決定ポイントが増えるたびにレイテンシと運用上の複雑さが生じることになります。
サービングシステムを無視したルーターは、誤った現実に合わせて最適化を行っていることになります。
では、私たちはどのように対処したのか？
これらの教訓が、私たちのルーター構築アプローチを形作りました。重要な転換は、ルーティングを分類問題として捉えるのをやめ、最適化問題として捉えるようにしたことです。「このタスクに最適なモデルはどれか？」と問いかける代わりに、私たちのアルゴリズムはコスト、品質、レイテンシの間で同時に最適化を行います。しかも、それ自体がボトルネックにならないほど軽量です。
以下の図は、AppWorld Test Challenge において CodeAct エージェントを使用した際の結果を示しています。青い四角のそれぞれが、私たちのルーターの異なる設定を表しており、コストと正確性のトレードオフのフロンティア（境界線）を描いています。重要なのは特定の1点ではなく、コスト、レイテンシ、正確性のどれを重視するかに応じて、ルーターが選択可能な動作点のセットを提供できる点です。「設定1」（レイテンシ最適化を目標とする）は、84% の正確性を達成し、コストは 93 ドル、所要時間は 83 秒でした。これは、Opus のみを実行した場合と比較して、コストを 21% 削減、レイテンシを 9% 短縮しつつ、正確性の低下をわずか 4% に抑えています。「設定2」では、さらにコストを抑えることができます。
なお、標準的な難易度ベースのルーター（青緑色のひし形）は、同等の正確性レンジに位置しているものの、コストが高くなっています。これは、最適化ベースのアプローチのようにトレードオフの空間全体を探索できていないためです。また、最適化プロセス自体が非常に軽量（1タスクあたり約 6 ミリ秒、メモリ使用量 2 KB）であるため、ルーターが前述したようなボトルネックになることはありません。
より広い視野で見る
この取り組みから得られた示唆は、ルーティングの本質はモデルの選択ではなく、システムの最適化であるということです。モデルは重要な変数の1つですが、キャッシュの挙動、インフラストラクチャの状態、コンプライアンスの制約、ワークロードのパターンなど、多くの要因の中の1つに過ぎません。
ルーティングがうまく機能しているとき、その理由は特定のタスクに対して「最適な」モデルを見つけたからではなく、システム全体にとって最適な動作点を見つけたからであることがほとんどです。これは分類よりも難しい課題ですが、取り組む価値は十分にあります。
今後の記事で、私たちの手法に関する技術的な詳細をさらに共有していく予定です。それまでの間、もしご自身のエージェントシステムでルーティングを構築されているなら、どのようなトレードオフに直面しているか、ぜひお聞かせください。
謝辞
この記事は、多くの同僚との対話からインスピレーションを得たものです。彼らの思慮深い質問、フィードバック、および洞察は、私たちの考えを洗練させる上で大きな助けとなりました。