【ITニュース解説】Why your agent bill explodes before the model even thinks — tiered routing and the cheap-check-first fix — Tiered Routing

最近、AI技術の発展、特に大規模言語モデル（LLM）を使ったシステムが注目を集めている。これらのシステムは「エージェント」と呼ばれ、まるで人間のように複雑な作業をこなすことができる。しかし、この便利なエージェントを企業で利用する際、予想外に高額な費用が発生し、多くの開発者を悩ませている。エージェントがまだ思考を始める前の準備段階や簡単な作業で、すでに高額な請求が発生しているのだ。

なぜこのようなコスト増大が起きるのだろうか。その理由は、エージェントが実行する作業の各ステップで、常に最も高性能で高価なLLM（フロンティアモデルと呼ばれるもの、例えばClaude Opusなど）を使っていることにある。フロンティアモデルは非常に賢いが、その分、使用料金も小型モデルの5倍から25倍と高額だ。1回あたりの利用では小さな差でも、何十ステップも続くエージェントの処理全体で見ると、とてつもない金額になる。

ある開発者は、たった一日のエージェントの作業で340ドルもの費用がかかった経験がある。そのエージェントは23ステップの処理を行い、そのうち19ステップがJSON形式の整形、日付の抽出、サポートチケットの分類といった比較的単純な作業だった。高性能なモデルは、このような単純な作業にも「最高級の料金」で使われていたのだ。これでは、自転車でできる仕事に高級車を使うようなものだ。

この問題の根本原因は、LLMエージェントの設計にある。多くのエージェントは、すべての処理ステップでデフォルトとして同じ高性能モデルを使うように設定されている。しかし、「要約する」ステップと「計画を立てる」ステップでは、必要とされるAIの推論能力が大きく異なる。計画立案には高度な思考能力が必要だが、結果の整形やデータ抽出には、そこまで高度なモデルは必要ない。モデルの選択は、エージェント全体に対して一度行うのではなく、各ステップの必要性に応じて行うべきだということに、多くの開発者が気づき始めた。これは、書類整理のために高給な上級建築家を雇うような非効率さだ。

この問題の解決策として、「階層型ルーティング」（Tiered Routing）または「モデルカスケード」と呼ばれるアプローチが注目されている。これは、非常にシンプルな考え方に基づいている。まず、安価で小規模なモデルを使って各ステップの処理を試みる。その処理結果が適切かどうかを「ゲート」と呼ばれるチェック機構で検証し、もし不適切だった場合、初めて高性能なフロンティアモデルに処理をエスカレート（引き継ぐ）するという仕組みだ。

この方法を「FrugalGPT」という研究が最初に提案し、最大98%のコスト削減を達成しながらも、GPT-4に匹敵するかそれ以上の精度を示した。多くのクエリは高価なモデルを必要とせず、高価なモデルは本当に必要なクエリだけを処理すれば良いという点が重要だった。

しかし、この階層型ルーティングが成功するためにはいくつかの条件がある。まず、最も重要なのは「ゲート」の品質だ。単に出力データの形式が正しいかを確認するだけでなく、その内容が意味的に正確であるかを判断できなければならない。もしゲートが「2024年Q3」と「2025年Q3」の違いを識別できないなら、それは単なる形式チェックであり、間違った答えを正しいものとして通してしまうことになる。次に、安価なモデルで失敗し、高価なモデルにエスカレートする「エスカレーション率」が十分に低い必要がある。安価なモデルでの試行にもコストがかかるため、もし安価なモデルが80%の確率で失敗するようでは、最初から高価なモデルを使うよりも費用がかさんでしまう。最後に、安価なモデルの処理速度が速くなければ、コストは削減できても、応答時間が大幅に伸びてしまい、実用性が損なわれる可能性がある。

最近の研究では、この階層型ルーティングの有効性が具体的な数値で示されている。「AgentRouter」というシステムは、非常に少ないオーバーヘッドで各ステップに最適なモデルを選び、フロンティアモデルのみを使う場合と比較して72%のコスト削減を実現しつつ、品質は97.3%とほとんど損なわれなかった。これは、エージェントの処理全体ではなく、「ステップごと」にルーティングを行うことが重要だということを裏付けている。なぜなら、一つのエージェントが実行する作業の中でも、各サブタスクの複雑さは大きく異なるからだ。

ここで一つ、見落とされがちなコスト増大の落とし穴がある。それは「プロンプトキャッシュ」だ。LLMサービスプロバイダーは、過去の会話履歴をキャッシュとして保存し、同じ入力トークンに対して割引を提供する場合がある。これにより、会話が進むにつれてコストが大幅に削減される。しかし、エージェントのセッション中に使用するモデルを切り替えてしまうと、このキャッシュが無効になる。なぜなら、各モデルには独自のキャッシュがあるからだ。新しいモデルは以前のモデルの履歴にアクセスできず、毎回最初から会話全体を読み込み直す必要があり、その結果、トークンコストが大幅に跳ね上がることがある。特に長文を扱う作業では、この一度のモデル切り替えが、せっかくのルーティングによるコスト削減効果を帳消しにしてしまう。この問題を避けるためには、セッション全体ではなく、個々のステップ内でモデルを切り替えるか、モデルを切り替える前にそれまでの会話履歴を要約し、要約された短い情報を新しいモデルに渡すのが良い方法だ。

実際にこの技術を導入している企業も増えている。OpenRouterやCisco、Fireworksといった企業が、この階層型ルーティングによってコストを大幅に削減し、応答速度を向上させていると報告している。成功しているチームは、一つの「最高のモデル」を万能薬として使うのではなく、各ステップに「適切なモデル」を選んで活用しているのだ。

では、あなたのシステムに階層型ルーティングを導入すべきはどのような場合だろうか。それは、エージェントの処理ステップの中に、複雑さのばらつきが大きい部分がある場合だ。例えば、高度な計画や思考が必要なステップと、単純なデータ抽出やフォーマット整形、分類のステップが混在しているようなケースである。もしすべてのステップが本当に高性能モデルの能力を必要とするなら、ルーティングはあまり効果がないだろう。また、処理するトークン量が多く、コスト削減が具体的な経済的メリットになる場合に導入を検討すべきだ。月50ドルの費用を40%削減しても大きな変化はないが、月5万ドルの費用を40%削減できればその効果は絶大だ。そして、ルーティングの判断は、エージェントの「クエリ全体」ではなく、「各ステップ」の具体的な指示や、それまでの会話の流れといった情報に基づいて行うことが重要である。

階層型ルーティングは、コスト削減と応答速度の向上という大きなメリットをもたらすが、いくつかのトレードオフも伴う。ルーティングの判断には誤りが生じる可能性があり、複雑なステップが安価なモデルに割り振られて失敗した場合、安価なモデルでの試行費用と、その後のエスカレーション費用、さらにはその間の遅延と、かえってコストがかさむことになる。また、ゲートが誤った回答を「正しい」と判断して通してしまうと、割引価格で間違った情報を提供するだけになり、コスト削減の恩恵は嘘になってしまう。さらに、ルーターやゲート、複数のモデル設定など、システム全体の構成が複雑になる。これらは個別に障害発生の原因となる可能性がある。

しかし、筆者は自身の請求額が68%削減されながらも品質がほとんど低下しないという経験から、このアプローチが非常に有効だと確信している。成功しているチームは、最も優れたモデルを常に使うのではなく、各ステップに「最適な」モデルを選ぶという明確な意思決定を受け入れているのだ。もしあなたのエージェントのコスト内訳をステップごとに分析し、それぞれのステップで本当にフロンティアモデルを使う必要があったのかを問われたら、どう答えるだろうか。最適なモデル選択は、いまや当たり前に考えるべき重要な設計判断なのである。