10月7日、InfoWorldが「Five keys to controlling AI token costs」と題した記事を公開した。この記事では、LLMのAPIコストを抑えるための5つの実践的な手法について詳しく紹介されている。
生成AIのAPI利用料が想定外に膨らむ「AIビルショック」は、エンジニアリング組織における新たなFinOps課題として定着しつつある。クラウドコストの最適化にようやく慣れてきたところへ、トークン単位で課金される不透明なLLMのコスト構造が加わった形だ。
記事の核心は「トークンを、CPUやメモリと同じ制約されたリソースとして扱え」という一言に集約される。以下、5つの手法を紹介する。
1. モデルルーティング——最も即効性が高い
記事が最初に挙げ、最も手厚く解説するのがモデルルーティングだ。
プロトタイピング段階では最強モデルを使うのが自然だが、本番環境では「そのユースケースに必要な最低限のモデル」に切り替えることが必須と記事は主張する。単純な分類やテキストパース、ユーザーの意図検出であれば、GPT-4o miniやClaude 3 Haikuで十分なケースは多い。
大規模なエンタープライズ構成では、RouteLLMやSemantic Routerといったフレームワークで動的ルーティングを実装できる。さらにKong、Cloudflare AI Gateway、PortkeyのようなAI APIゲートウェイを活用すれば、テナントやマイクロサービス単位でトークン予算を強制適用し、レートリミット時に安価なモデルへ自動フォールバックする「カスケードルーティング」も実現できる。
記事はこれを「認知タスクのロードバランサーを構築する」と表現している。
2. リランキングによるプロンプト節約——コスパ最強の一手
次に注目すべきはプロンプトの肥大化対策、特にリランキングだ。
モデルが100万〜200万トークンのコンテキストウィンドウを持つ今、「とりあえずPDF全体やコードベース全体を突っ込む」誘惑は強い。しかし入力トークンはすべて課金対象であり、コンテキストが長くなるほど「Lost in the Middle問題」——モデルがコンテキスト中間部のコンテンツの解像度を失う問題——も顕在化する。
対策は、ベクトルDBから上位50件を取得した後、Cohere RerankやBGEモデルのような小型クロスエンコーダーでスコアリングし、上位3〜4件だけをフロンティアモデルに渡すことだ。
クロスエンコーダーは約100ミリ秒のレイテンシを追加するが、プロンプトのトークン数を80%以上削減しながら、生成精度も向上させる。
記事は「LLMに読ませる量を減らすことは、最もレバレッジの高いアクションのひとつ」と断言している。
3. セマンティックキャッシング
「パスワードのリセット方法は？」と「ログインできなくなりました」は、文字列としては別物だが意味は同じだ。従来のキャッシュ（完全一致）ではヒット率はほぼゼロになる。
セマンティックキャッシングでは、受け取ったプロンプトを高速な埋め込みモデルに通し、過去の回答済みプロンプトとの類似度検索を行う。類似度が閾値（例：0.92）を超えれば、LLMを呼ばずにキャッシュ済みレスポンスを返す。これによりその問い合わせの推論コストはゼロになり、レスポンスタイムも数秒から数ミリ秒に短縮される。
実装にはGPTCacheや、既存のPostgreSQLにpgvectorを追加する方法が挙げられている。
ただし類似度閾値の調整は繊細で、低すぎると「セマンティックフラットニング」——汎用的な回答が返ってしまう問題——が発生する。RAGシステム、カスタマーサポートBot、社内ナレッジベースのような「同じ質問が何千通りもの言い方で来る」用途では強力だが、クリエイティブな生成AIアプリには向かない。
4. プロンプトキャッシング
プロバイダー側が提供する機能で、RAGパイプラインやDBから取得した大量のコンテキストデータをモデル側にキャッシュしておく仕組みだ。キャッシュされたトークンは通常の入力トークンに比べ50〜90%割引で処理される。
実装の注意点はプロバイダーによって異なる：
- OpenAI：自動適用だが、システムプロンプトの先頭にタイムスタンプやユーザーIDなどの動的変数を置くとキャッシュが無効化される。1,024トークンの最小閾値あり。
- Anthropic Claude / Google Gemini：明示的なAPI操作が必要。TTL（生存期間）の設定や、JSONペイロードへのキャッシュ制御ポイントの注入が求められる。書き込みプレミアムが発生するが、大容量のRAGデータを数時間にわたってメモリに保持できる。
5. レスポンスの制約
デフォルトのLLMは饒舌だ。「Certainly! Here is the JSON you requested...」から始まり「Please let me know if you need anything else!」で締める。
出力トークンは入力トークンの3〜5倍の単価で課金される。この「礼儀正しさ」がコストを食っている。
対策は以下の通りだ：
max_tokensをハードなサーキットブレーカーとして設定する（整形ツールとして使うとJSONが途中で切れる）stop_wordsでモデルに作業完了を明示的に伝える（SQLクエリの出力後にmarkdownの閉じタグを止め字として設定するなど）- Structured Outputs（厳格JSONモード）とゼロトレランスなシステムプロンプトを組み合わせる
ただし制限しすぎには注意が必要だ。LLMは内部的なワーキングメモリを持たず、「トークンを出力しながら思考する」。複雑なロジック問題に対してTrue/Falseの一言だけを強制すると、精度は急落する。目標は「無駄な出力を削る」ことであり、「Chain-of-Thoughtのような実際の計算作業には十分なスペースを与える」ことだ。
※編集部の考察：5つの手法のうち、すぐ試せる順に優先度をつけるなら、モデルルーティング→レスポンス制約→プロンプトキャッシングの順が現実的だ。セマンティックキャッシングとリランキングは導入コストがかかる分、RAG構成では最も劇的な効果をもたらす。
詳細はFive keys to controlling AI token costsを参照していただきたい。
