推論モデルに乗り換えたらコストが急増した — プロンプト予算・セマンティックキャッシュ・ルーティングで最大85%削減する実践手法

7月29日、Jeff Millsが「Token-Budget-Aware LLM Reasoning: Cut Costs in 2026」と題した記事を公開した。推論モデルのトークンコストを削減するための実践的な手法として、トークン予算制御・セマンティックキャッシュ・モデルルーティング・メモリ永続化の4つのアプローチを、具体的な数値と実装例を交えて解説している。

推論モデル（Reasoning Model）に切り替えた途端、コストが跳ね上がった経験を持つエンジニアは少なくないだろう。その原因のほとんどは推論トークンにある。推論モデルが「答えを出す前に考える」プロセスはすべて出力トークンとして課金される。OpenAIの標準コンテキストモデルでは、出力トークンの単価は入力トークンの6倍だ。そして「2+3=?」という質問に対して、一部の推論モデルは900トークン以上を消費したケースが報告されている。

推論トークンを削る：プロンプトレベルの手法

Chain of Draft：ステップを5単語以内に絞る

Chain-of-Thought（CoT）プロンプティングは多段階問題の精度を上げるが、各ステップがそのまま出力トークンとして請求される。Chain of Draftはその対策で、各推論ステップを5単語以下に制限する手法だ。

結果が興味深い。Claude 3.5 Sonnetでスポーツ理解問題を解かせた場合、CoTでは190トークン・精度93.2%だったのが、Chain of Draftでは14トークン・精度97.3%に変わった。コインフリップ課題では、GPT-4oとClaude 3.5 Sonnetの両モデルで精度100%を維持しながらトークンを68〜86%削減した。

ただし算数（GSM8K）では代償があった：

GPT-4o：精度95.4%→91.1%、出力205→44トークン
Claude 3.5 Sonnet：精度95.8%→91.4%、出力190→40トークン

問題の種類によって効果が変わるというのが実用上の要点だ。モデルより先に「タスクの性質」を確認すべきといえる。

TALE：モデル自身に予算を見積もらせる

固定のトークン予算では限界がある。「2+3」に合わせた予算は多段階問題を詰まらせ、多段階問題に合わせた予算は簡単な問題でトークンを無駄にする。

TALE（Token-Budget-Aware LLM Estimation）はこの問題を2フェーズで解決する：

Estimate：ゼロショットプロンプトでモデル自身に必要トークン数を見積もらせる
Constrain：その見積もりを推論プロンプトへの明示的な予算として渡す

GPT-4o-miniの7データセットでの評価では、出力トークンを平均67%削減しながら精度低下は3%未満。GSM8Kでは精度が81.35%→84.46%に向上し、平均出力は318→77トークンに減少した。過剰な思考を減らすことが精度改善にも寄与した格好だ。

プロンプトの限界：予算が小さすぎると逆効果

プロンプトによる予算制御には根本的な限界がある。TALE評価のある事例では、258トークン必要な問題に対して50トークン予算を設定すると86トークンに抑えられたが、10トークン予算に絞ると157トークンに増えた。モデルが制約を守れないと、制約自体を無視してより長い推論に戻ってしまう。

各プロバイダーはAPIパラメータとして予算制御を整備しつつある：

Gemini：thinking budgetパラメータ（0で無効化、-1でモデルが自動調整）
Claude：Opus 4.7以降はbudget_tokensが廃止され、effortパラメータに移行。思考はモデル制御になった
OpenAI：推論モデルではCoTプロンプト自体を使わないよう開発者に推奨。内部で推論するため

より大きな削減：セマンティックキャッシュで「同じ推論」への課金をやめる

プロンプト予算は1レスポンスを小さくする。しかし同じ質問に何度も課金されることは止められない。ある分析では、LLMクエリの30%以上が意味的に類似した過去のクエリと重複していた。

セマンティックキャッシュの仕組みはシンプルだ：

LLMレスポンスをプロンプトのベクトル埋め込みと共に保存する
新しいプロンプトが来たらコサイン類似度で比較する
類似度が閾値を超えたらキャッシュを返す。超えなければモデルを呼ぶ

ある実装では、ヒット率は**61.6〜68.8%、ヒット時の精度は92.5〜97.3%**を記録した。単に安いだけでなく、答えの質も担保されている点が重要だ。

Redisはこのユースケース向けにRedis LangCacheを提供している。ベクトル埋め込み生成とベクトル検索を管理するマネージドサービスで、Redisの計測ではLLM推論コストを最大73%削減、キャッシュヒット時のレスポンスを15倍高速化したとしている。現在の提供状況についてはRedis LangCacheの公式ページで確認されたい。

ルーティングとメモリ：アーキテクチャ全体での予算管理

複雑さベースのルーティング

全クエリを最高性能・最高コストのモデルに流す必要はない。複雑さベースのルーティングは、クエリをその難易度に応じた最安モデルに振り分ける。

研究結果では：

事前推論ルーターで、MT BenchでのGPT-4性能の95%を維持しながらコストを最大85%削減
カスケードルーターで、最良モデルの推論コストの最大98%を節約しながら同等性能

RedisはこのパターンをRedisVLのSemanticRouterとして提供している。KNN分類でクエリを意味的にルーティングし、簡単なクエリを軽量モデルへ誘導する。

推論結果のメモリ永続化

マルチターンのエージェントでは、会話履歴をAPI呼び出しのたびに再送信するため、トークンコストがターン数に対して概ね二乗で増加する。さらにセッションをまたぐと、前回導き出した結論を再び推論し直す無駄が生じる。

Reflexionエージェントのように、推論結果をエピソードメモリバッファに保存して再利用する設計が有効だ。Redis Iris（Redis Cloudのマネージドサービス群）は、セッションメモリと長期ベクトル検索メモリの2層構造でこのパターンを実装している。

効果を可視化する：計測の仕組みを先に整える

どの手法も、計測なしには改善の判断ができない。プロンプト予算・キャッシュ・ルーティングのそれぞれが実際にどう効いているかを確認するためには、トークン消費の可視化が前提となる。前述の施策と合わせて、まず計測基盤を整備することが先決だ。

OpenTelemetryのGenAIセマンティック規約（開発中）は以下の属性を定義している：

gen_ai.usage.input_tokens
gen_ai.usage.output_tokens
gen_ai.usage.reasoning.output_tokens（推論トークン単独）

元記事によれば、GitHubはAPIプロキシ計装と、出力トークンをキャッシュ済みリードより高く重み付けした「Effective Tokens」メトリクスを用いることで、エージェントワークフローのトークン消費を最大62%削減したとされている。

プロンプト予算・セマンティックキャッシュ・複雑さルーティング・メモリ永続化は、それぞれ独立した施策ではなく、組み合わせることで効果が大きくなる。どの施策から始めるかを判断するためにも、計測の仕組みを先に整えることが実践上の出発点となる。

詳細はToken-Budget-Aware LLM Reasoning: Cut Costs in 2026を参照していただきたい。