モデルルーティングの複雑さについて

Back to Articles

• 1. コストはモデル価格だけではない
• 2. 複雑さはタスクの難易度だけではない
• 3. レイテンシはモデル速度だけではない
• では、私たちはどう対応したのか？
• 全体像
• 謝辞

エージェントにルーティング機能を組み込むのは、一見すると簡単な勝ち筋に見える。単純なリクエストを安価なモデルに送り、高価なモデルは難しいタスクのために温存する。あるいは専門性で振り分ける——コードなら Claude、マルチモーダルなら Gemini、といった具合だ。分類器やヒューリスティックが判断を下せば、コストは下がりパフォーマンスも維持される。これで完了だ。

しかし、現実はそう単純ではない。多くのルーティングシステムは、モデル選択を「分類問題」として扱っている。エージェントシステムの構築を通じてルーティングを実装してきた経験からすると、一見するとモデル選択の問題に見えるものが、すぐにシステム最適化の課題へと変貌することがわかった。私たちが直面した難しさは、主に 3 つの次元に起因する。

1. コストはモデル価格だけではない

GPT-4.1 は Claude Sonnet 4.6 より安価になると予想していたが、結果は逆だった。

CodeAct エージェントを用いて AppWorld Test Challenge の 417 タスクを実行したところ、Sonnet の総コストは 79 ドル（タスクあたり 0.19 ドル）に対し、GPT-4.1 は 155 ドル（同 0.37 ドル）となった。ほぼ倍額だ。紙面上では説明がつかない。GPT-4.1 のトークン価格は入力・出力ともに Sonnet より低く設定されており、Sonnet は同じタスクを完了するために推論ステップを約 3 倍も必要としている。定価だけで見れば、GPT-4.1 が勝つはずだ。

その理由はキャッシュにあります。多くのルーティング議論ではこの点が完全に無視されています。

エージェントのワークロードでは、ステップ間でコンテキストの大きな断片が再利用される傾向があります。キャッシュヒット率が高い場合、実質的な入力コストは劇的に低下します。Sonnet はキャッシュ読み取り料金が安いため、このパターンから不均衡な恩恵を受けました。その結果、高い基本料金や長いトジェクト（処理軌道）という不利さをすべて上回ってしまいました。

結論として、実際のコストはモデル、ワークロード、そしてサービングインフラの相互作用によって決まります。単に価格表だけを見てルーティングするシステムでは、間違った数値に対して最適化していることになります。

2. 複雑さはタスクの難易度だけではない

一般的なルーティング戦略として、「タスクがどれほど難しいかを推定し、難しいものは高性能なモデルへ送る」というものがあります。直感的には正しく見えますが、実は二つの点で破綻します。

第一に、ルーティング時点では難易度が目に見えないことが多いのです。「この契約書を要約して」といったリクエストは一見単純ですが、実際にはデータ取得、コンプライアンスチェック、ツール利用、そして複数の反復による改良が必要になるケースがあります。一方、高度に専門的なプロンプトであっても、小さな専用モデルによって効率的に処理できる場合があります。タスクが実際にどれほど難しいかは、実行が始まってみないとわからないのです。

では、私たちはどう対応したのか？

これらの教訓が、私たちがルーターを構築する際の指針となりました。最大の転換点は、ルーティングを分類問題として扱うのをやめ、最適化問題として捉え直したことです。「このタスクにどのモデルが最も適しているか」と問うのではなく、アルゴリズムはコスト、品質、レイテンシを同時に最適化します。その際にも、ルーター自体がボトルネックにならないよう、軽量な設計を維持しています。

下の図は、CodeAct エージェントを用いた AppWorld テストチャレンジでの結果を示しています。青い四角形それぞれが、ルーターの異なる設定を表しており、コストと精度のトレードオフ曲線（フロンティア）を描いています。重要なのは特定の一点ではなく、コスト、レイテンシ、精度のいずれを優先するかによって、ユーザーが選択できる運用ポイントの範囲を提供している点です。

例えば、レイテンシ最適化された設定 1 では、84% の精度で 93 ドル、83 秒という結果になります。これは Opus モデル単体で実行した場合と比較して、コストが 21%、レイテンシが 9% 削減され、精度はわずか 4% しか低下しないことを意味します。一方、設定 2 ではさらにコストを下げることが可能です。

標準的な難易度ベースのルーター（水色のダイヤモンド）も同程度の精度範囲に到達しますが、そのコストは高くなります。これは、最適化アプローチが持つようなトレードオフ空間全体を十分に探索できていないためです。また、最適化処理自体が軽量であること（タスクあたり約 6 ミリ秒、メモリ使用量 2 キロバイト）も幸いし、ルーターが前述したボトルネックになることはありません。

The Bigger Picture

今回の取り組みから得た教訓は、ルーティングの本質は「どのモデルを選ぶか」ではなく、「システム全体を最適化すること」にあるという点です。モデルは重要な変数の一つではありますが、キャッシュの挙動やインフラの状態、コンプライアンス上の制約、そしてワークロードのパターンなど、数多くの要素の中の一つに過ぎません。

ルーティングがうまく機能している場合、それは特定のタスクに対して「最良」なモデルを見つけたからではありません。むしろ、システム全体にとって最適な運用ポイントを見つけ出したからです。これは分類問題よりも難易度が高い課題ですが、取り組む価値のある課題です。

今後、当社のアプローチの技術的な詳細については別の記事で詳しく解説する予定です。その間、ご自身のアジェンシー型システムにルーティングを組み込んでいる方は、どのようなトレードオフに直面しているか、ぜひお聞かせください。

謝辞

本記事は、多くの同僚との議論から影響を受けました。彼らの深い問いかけやフィードバック、そして洞察が、当社の思考を磨き上げるのに大きく貢献しました。