モデルルーティングの複雑さとは

記事一覧に戻る

• 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. 複雑さはタスクの難易度だけでは測れない

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

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

第二に、仮にタスクの難易度を完璧に推定できたとしても、それは単なる一つの指標に過ぎません。本番環境では、ルーターはコスト、レイテンシ、モデルの専門性、信頼性を同時にバランスさせる必要があります。さらに企業向け展開では、コンプライアンス要件、データの所在地規制、プライバシー制約、承認済みモデルリストなど、追加の条件が重なります。本来ならあるモデルに振り分けるべきタスクも、ガバナンス上の理由で別のモデルへ回さなければならず、ルーターはこれを柔軟かつ適切に処理できなければなりません。

ルーターは単一の課題を解決するものではなく、コスト、品質、レイテンシ、コンプライアンス、信頼性という複数の要素を常に同時に調整し続けています。

3. レイテンシはモデル速度だけではない

「モデルサイズが大きいほど遅く、小さいほど速い」という単純な図式でレイテンシを考えがちですが、ユーザーが実際に体感する速度はそれだけでは決まりません。

ルーティング自体にもオーバーヘッドが発生します。さらに重要なのはインフラ要因です。モデルがどのハードウェア上で動作しているか、キャッシュが有効化されているか（ウォーム状態か）、エンドポイントの混雑状況などは、エンドツーエンドの応答時間を決定づける主要因となり得ます。理論上は高速なモデルでも、サービング環境が整っていなければ、ユーザー体験としては遅く感じられてしまいます。

また、ルーティングの粒度も影響します。タスクごとに一度だけルーティングする場合はオーバーヘッドは最小限ですが、実行中の各ステップで都度ルーティングを行うと、柔軟性は高まるものの、意思決定ポイントが増えるたびにレイテンシと運用複雑度が上昇します。

サービングシステムを無視したルーター設計は、現実の課題に対して間違った最適化を行ってしまっているのです。

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

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

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

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

The Bigger Picture

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

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

今後の投稿では、このアプローチの技術的な詳細について詳しく解説する予定です。その間、ご自身でエージェント型システムにルーティングを実装されている方は、どのようなトレードオフに直面しているかぜひ教えていただければ幸いです。

謝辞

本記事は、多くの同僚との議論から影響を受けました。彼らの鋭い質問やフィードバック、そして洞察が、私たちの考え方を洗練させるのに大きく貢献しました。