TrueFoundry AI GatewayのAuto Routingのご紹介

TrueFoundry AI Gatewayに新しい機能が追加されました。この自動ルーティング機能は、受信した各リクエストを読み取り、3つの複雑性レベルのいずれかに分類した上で、そのレベルに割り当てられた最適なモデルへと送信します。

この機能は、お客様のトラフィックによく見られるパターンを解決するために開発されました。通常、クエリの大半は単純なものであり、軽量なモデルで処理可能です。複雑なモデルへのルーティングが必要なクエリはごく一部に過ぎません。しかし実際には、複雑さに関係なく、すべてのクエリに対して一律のモデルが割り当てられているケースがほとんどです。その結果、企業はサイクルごとに不必要な高額請求に直面することになります。ルーティングルールをハードコーディングする方法では、各チームが独自のルーティングロジックを適用してしまい、標準化が図れないため、拡張性もありません。

その役割を担うのが、このゲートウェイです。

「トークン最大化」から「トークンエコノミクス」へ

過去2年間の大半において、チームはAIの導入状況を消費量で測定してきました。消費されたトークン数が、成果の代わりとなっていたのです。一部の企業では、最も多く利用した人を称える社内ランキングまで作成していました。AI導入の初期段階において、どれだけの作業をモデルにオフロードできるかを把握することが目的であったなら、これは理にかなっていたかもしれません。 

しかし、請求書が届き始めました。ある IDCによるクラウドおよびAIの意思決定者を対象とした調査によると、61%の組織が2025年度のクラウドAI予算を大幅に超過しました。UberのCTOは、チームの年間AI予算を4月中旬までに使い果たしたことを明らかにしています。推論ループは長くなり、コンテキストウィンドウは肥大化し、エージェントは誰の監視もないまま、1日に何千回も自律的にモデルを呼び出すようになりました。

そこで優先順位が変わりました。「トークン最大化」に代わって「トークンエコノミクス」が重視されるようになり、導入や実験のスピードを落とすことなくAI支出を抑制する戦略が求められています。つまり、リアルタイムのコスト可視化、チャージバックモデル、チームごとのコスト配分、利用上限設定への注目が高まっています。これらはすべて重要な機能ですが、支出を監視・制限するだけであり、最適化するものではありません。

請求額を左右する決定は、もっと早い段階で、もっと迅速に行われます。それは「どのモデルにこのリクエストを割り当てるか」という判断です。これこそが、自動ルーティングが機能する領域です。

自動ルーティングの仕組み

単一のモデル名で3つの階層を管理

自動ルーティングは 仮想モデル上で設定されます。これはアプリケーションが呼び出す単一の名前付きエントリーです。特定のモデルを割り当てることができる3つの複雑性階層が用意されています。

階層の割り当ては仮想モデル上で行われるため、より優れた、あるいは安価なモデルが登場した際には、アプリケーション側のコードを変更することなく、背後のモデルをいつでも入れ替えることができます。ルーティングポリシーは、所有者や変更履歴が管理され、一元的に編集可能な設定オブジェクトとなります。

複雑性階層はどのように選択されるのか？

各クエリが3つの階層のいずれかに分類される方法には、以下の2通りがあります。

1. ヒューリスティック分類（デフォルト）

ヒューリスティック分類器はプロンプトを読み取り、あらかじめ定義された一連のシグナルに基づいてスコアリングを行い、ティアを選択します。ゲートウェイプロセス内で実行されるため、レイテンシやコストは発生せず、完全に決定論的な動作をします。 

以下のパラメータに基づいてクエリの複雑さを判断します。

• コードユーザーまたはシステムテキストに含まれる、function、class、api、docker、sql、言語名などのプログラミングキーワード
• 明示的な推論リクエスト 「ステップバイステップで」「じっくり考えて」「メリットとデメリット」「推論の根拠を説明して」といった表現
• 専門用語 architecture、distributed、concurrency、throughputなど
• プロンプトの長さプロンプトが長いほど、処理負荷が高くなる傾向があるため
• マルチステップ構造「まず～、次に～」といった言い回しや、番号付きリストなど
• 一度に複数の質問1つのリクエスト内に疑問符が3つ以上含まれる場合

2. LLM分類

ここでは分類器モデルを選択します（仮想モデルではなく、カタログ内のチャットモデルである必要があります）。また、タイムアウト時間をミリ秒単位で設定します。さらに、その呼び出しが失敗した場合の動作も設定する必要があります。フォールバックオプションは2つあり、組み込みのシグナルによる判断に戻す「ヒューリスティック」と、指定したティアにすべて送信する「静的」から選択可能です。分類器の失敗によってリクエスト自体が失敗することはありません。

これには2つのトレードオフがあります。分類器はリクエストの前にモデル呼び出しとして実行されるため、レイテンシが発生します。また、これは課金対象のゲートウェイリクエストとなり、トリガーとなったリクエストと同じテナントおよびサブジェクトに帰属します。 

自動ルーティングの優れた機能

自動ルーティングは単純なルーティングルールを超え、精度を維持しながらモデルの利用コストを最適化するための追加機能を提供します。

• エスカレーションとフォールバック：Auto Routingは完全に順序付けられたチェーンを構築します。特定の階層に分類されたリクエストは、まずその階層のターゲットに対して、指定した順序で試行され、その後、より上位の階層へと順次処理が進められます。 
• 会話の固定：最初のターンは通常通り分類され、ターゲットが正常に応答すると、ゲートウェイはその階層を記録します。その後のターンは再度分類されます。より難易度が高いターンであれば会話は上位階層へ移動し、難易度が低い場合は、既存の上位階層が維持されます。
• 可観測性：ai_gateway_complexity_routing_decisions_totalは、決定された階層と実際に解決された階層の両方でラベル付けされ、すべての決定をカウントします。財務部門には階層の構成比を、エンジニアリング部門にはエスカレーション率を提示できるほか、特定のリクエストを追跡して、なぜその階層に割り当てられたのかを説明することも可能です。

ベンチマークの結果

私たちは、すべてのリクエストをClaude Opus 5に送信するベースラインと比較して、16の公開データセットと約4,700件の呼び出しを用いてAuto Routingをテストしました。これには無料のヒューリスティック分類器と、Haiku、Sonnet、Opusの階層構造を使用しています。評価は決定論的です。生成されたコードは各ベンチマークのユニットテストをサンドボックス内で実行し、数学や選択問題の回答は正解キーと照合されます。

いずれのケースにおいても、品質を損なうことなく大幅なコスト削減が実現しました。

詳細な手法、データセットごとの内訳、および本番環境のトラフィック分析については、エンジニアリングの深掘り記事をご覧ください： 品質を落とさずにLLMコストを3分の1に削減する方法。

はじめに

Auto Routingは仮想モデル上で動作します。 AI Gateway → Models → Virtual Modelに移動し、 Complexity をルーティングタイプとして選択し、分類戦略を選んで、利用したい各階層のターゲットを設定してください。その後、アプリケーションの接続先を仮想モデルの名前に変更し、プレイグラウンドでさまざまな複雑さのプロンプトを使用してテストを行ってください。