すべてのAIプラットフォームチームは、いずれ同じ瞬間にぶつかります。財務がスプレッドシートを送ってくるのに、エンジニアはトークンがどこへ行ったのかわからず、データサイエンス担当の誰かが金曜の午後に仮説を確かめるためにGPT-4oで40万トークンのコンテキストウィンドウをただ試したところだった、という場面です。
LLMのコストはじわじわ増えません。全力疾走で増えます。
Andreessen Horowitzによると、AIインフラへの支出――主にLLM API呼び出し――は、多くの初期段階のAI企業において売上の20〜40%を消費しています。エンタープライズでは、チーム間でLLMの利用が制御されていないと、予測可能なクラウドコストのラインが、毎回の請求サイクル末にサプライズに変わり得ます。
本能的には締め付けたくなります。APIキーを一元化し、承認を必須にし、手作業の予算策定ステップを追加する。ですが、その直感は間違っています。エンジニアがLLMにアクセスしにくくなると、彼らは制御を迂回します――個人用APIキー、シャドーアカウント、あるいはそもそも実験をスキップするなどです。コストの可視性と引き換えにスピードを手に入れようとして、結局両方を失います。
正しいアプローチは、インフラ層でのプログラムによる支出（スピンド）抑制です。通常の利用中はエンジニアに見えないようにしつつ、境界では確実に強固であること。以下に、その作り方を示します。
なぜインフラなしではLLMコストの制御が非常に難しいのか
解決策に入る前に、まず、なぜこの問題が、従来のクラウドコスト管理に比べてLLMでは特別に難しいのかを理解しておく価値があります。
計算資源やストレージなら、先にリソースを用意できるためコストは予測可能です。LLMでは、コストは推論（inference）時に生成されます。そして、エンジニア自身が意識していない要因に左右されがちです。プロンプトの長さ、コンテキストウィンドウのサイズ、応答の冗長さ、失敗時のリトライのロジック、さらに$0.002/1Kトークンモデルか$0.015/1Kトークンモデルかといったモデル選択です。
失敗したときにリトライするエージェントのループ1つで、想定コストが5〜10倍に膨れ上がることがあります。「より良い品質」を理由にGPT-4o MiniからGPT-4oへ切り替えた、意図は善意の開発者でも、ビジネスロジックの1行も変えずに、呼び出しあたりのコストを25倍に増やしてしまえます。
本番のAIシステムで繰り返し現れる、3つの具体的な失敗パターンがあります。
チームごとの可視性がない。共有キーを使ってLLM APIを利用している企業のほとんどでは、「どのチーム、どのプロダクト、どの機能が、どの支出を生んだのか」がまったく分かりません。請求が来たときの内訳が「OpenAI: $47,000」だけで、詳細がない、という状態です。
強制の境界がない。可視性があったとしても、チームが予算をサイクル途中で超えてしまいそうでも、手作業でAPIアクセスを取り消す以外に止める仕組みがないのが通常です。これは下流のすべてを壊します。
実験を阻むガバナンス。手作業の承認ワークフロー、チケットキュー付きの中央集権的なキー管理、あるいは本番と開発環境に同じように適用されるフラットなレート制限は、最も価値のある作業をしているチームの動きを鈍らせる摩擦を作り出します。
実際に機能するアーキテクチャ：予算コントロール付きAIゲートウェイ
解決策はAIゲートウェイです。これはプロキシ層で、エンジニアとすべてのLLMプロバイダの間に入り、すべてのAPI呼び出しを中継し、意味のあるレイテンシを追加することなくリアルタイムで支出ポリシーを強制します。
LLMアクセスにおけるIAM層だと考えてください。エンジニアはOpenAIを直接呼びません。彼らは自社のゲートウェイを呼びます。ゲートウェイが適切なプロバイダへルーティングし、チームのクォータを強制し、利用をログに記録し、予算上限に近づいている場合はフォールバックモデルへルーティングします。
このゲートウェイ方式が機能する理由は、ポリシーとアクセスを切り離すからです。エンジニアは、すべてのモデルプロバイダで動作する統一された資格情報を取得できます。プラットフォームチームがルールを設定します。誰かが調整する必要はありません。
このアーキテクチャがうまくやるべきことは次のとおりです。
チームごとのクォータ管理— トークン上限、リクエスト上限、支出上限。特定のチーム、プロジェクト、さらには個々のユーザーに適用でき、それぞれ独立に設定可能です。
リアルタイム監視— 利用が、請求時の集計だけでなく、呼び出しレベルで可視化されること。火曜に200万トークンを消費したのがどのチームかを知る必要があります。インボイスが届くまで待つべきではありません。
ハードなブロックではなく、緩やかな劣化（グレースフル・デグレデーション）です。チームが上限に近づいたときに取るべき正しい挙動は、（例えばGPT-4oではなく）より安いモデルへルーティングすることであり、403を投げてサービスを壊すことではありません。
環境を意識したポリシー— 開発環境は実験を可能にするために十分に寛大な上限であるべきです。本番環境は、より厳格な監視とともに、より締めた予算である必要があります。これらは、同じインフラ上に別々のポリシーとして定義します。
TrueFoundry は LLM の支出（スピンド）強制をどう扱うか
TrueFoundry's AI Gateway は、まさにこのユースケースのために構築されています。単一のAPIエンドポイントを通じて250以上のLLMプロバイダに接続し、アプリケーションコードに触れずにプラットフォームチームが設定できるガバナンス層を公開します。
以下に、支出強制が実際にはどう動くかを説明します。
ステップ1：APIキー管理を一元化する
プロバイダのAPIキーを個別のチームに配るのではなく、一度だけ TrueFoundry に設定し、仮想の資格情報――実利用状況のトラッキングが紐づいたスコープ付きトークン――を発行します。これにより、実キーをプロキシします。
エンジニアはベースURLと認証ヘッダーを1回だけ更新します。その他はすべてそのままです。アプリケーションの観点では、引き続きOpenAI APIを呼び出しています。プラットフォームの観点では、すべての呼び出しが紐づけ可能で、計測でき、強制可能になります。
Before：プロバイダへの直接アクセス
client = OpenAI(api_key="sk-...")
After： TrueFoundry AI Gateway 経由でルーティング
client = OpenAI(
api_key="tf-team-data-science-prod",
base_url="https://your-org.truefoundry.com/api/llm"
)
他にコード変更は不要です。
ステップ2：チームごとに予算ポリシーを定義する
TrueFoundry は、複数のレベルで予算ポリシーを設定できます――チーム単位、プロジェクト単位、環境単位、個別ユーザー単位です。それぞれのポリシーは、以下の制限を強制できます。
トークン使用量（入力＋出力トークンの合算、または別々）
リクエスト数（API呼び出しの回数：1時間、1日、または1か月あたり）
見積り支出（ドルの金額。プロバイダの料金から計算）
たとえば、月額$2,000の予算を持つデータサイエンスチームで、さらに実験用に月額$500の別枠がある場合の典型的な設定は、プラットフォーム上では次のようになります――本番ワークロード用と開発用の2つのポリシーで、それぞれ上限とアラートの閾値が異なります。
チームが予算の80%に到達すると、TrueFoundry は問題が起きる「前」に、あなたが指定した相手（チームリード、プラットフォームチーム、財務など）へアラートを送信します。請求が来てからではありません。
ステップ3：インテリジェントなフォールバック・ルーティングを設定する
本番を壊してしまうハードリミットは、リミットがないよりも悪い。より賢い方法は、モデルのフォールバック・ルーティングです。チームが予算上限に近づいているとき、ゲートウェイは同じAPI契約を維持しながら、その後の呼び出しを自動的により安いモデルへルーティングします。
TrueFoundry はフォールバック・ルーティングの設定をサポートしており、プライマリモデルと、切り替えをトリガーする条件付きの1つ以上のフォールバック先を定義できます。予算のしきい値到達、レイテンシの急増、プロバイダのエラー率が高すぎる、またはそれらの任意の組み合わせです。
通常はClaude Sonnet 4を使っているチームでも、月間トークン予算の75%を消費した時点でClaude Haiku 4への自動フォールバックを設定できます。アプリケーションは動き続けます。コストは加速しません。通知が届きます。実行時にエンジニアが何かを変更する必要はありません。
ステップ4：リアルタイムの可観測性を使って、ムダを見つける
可視性のない強制は、逆方向に飛行盲目になることです。TrueFoundryのゲートウェイは、すべてのLLM呼び出しについてプロンプト、レスポンス、トークン数、レイテンシ、使用モデル、チームの帰属情報、コストといった完全なトレースをキャプチャし、リアルタイムのダッシュボードでそのデータを利用可能にします。
実際には、複数チームでのAI導入においてほぼ必ず見られる3つのパターンが浮き彫りになります。
高コストなプロンプトパターン。特定のワークフローが、毎回のリクエストで12,000トークンのシステムプロンプトを送信している。対策（プロンプト圧縮またはキャッシュ）は半日ではなく午後で済み、当該チームの支出を60%削減できることがあります。
不要なモデル選択。分類タスクが、GPT-4o Miniやファインチューニングしたより小さなモデルで同等の性能を出せるのに、GPT-4oに対して実行されている。品質低下なしで分類の呼び出しの80%でモデルを切り替えることは、よくある最初の最適化です。
リトライループがコストを膨らませる。指数バックオフなしで失敗した呼び出しをリトライするエラーハンドリングがあり、その結果、プロバイダの不安定さがある間は呼び出し量が実質的に3〜5倍になります。ゲートウェイのレベルでは、高いエラー率の呼び出しが先行してから急増することで見えます。
これらは、請求明細レベルではどれも見えません。すべてが、呼び出しごとのトレースダッシュボードで即座に確認できます。
その根拠を作る数字
直接LLMプロバイダへのアクセスから、統制されたゲートウェイ層へ移行したチームは、同様の結果を一貫して報告しています。TrueFoundry の顧客は、ゲートウェイの可観測性に基づく、クォータ管理、フォールバックルーティング、プロンプト最適化を導入した後に、LLMインフラの支出を40〜60%削減できたと報告しています。
なぜそうなるのか、その仕組みは次の通りです。直接のプロバイダアクセスには、プロンプト効率、モデル選定、キャッシュのための強制力がありません。誰かが1回あたりのコストを監視していると、チームは自然に最適化します。監視されていなければ、しません。
この管理を手作業のプロセスで行う運用上のオーバーヘッド—重要なアクセスのためのチケットキュー、スプレッドシートによる予算追跡、事後の請求分析—は、通常、週あたりプラットフォームエンジニアリングの工数として4〜8時間を消費します。ゲートウェイ層での自動強制により、それはほぼゼロになります。
やりたくないこと
LLMのコスト制御には、人気のある2つのアプローチがあり、どちらも逆効果です。
帰属情報のない共有APIキーは、ほとんどのチームにとってデフォルトの状態です。セットアップは簡単で、可視性や制御はゼロです。コストが急増しても、原因を特定する方法がありません。
手作業の承認ワークフローは、可視性の問題を解決しますが、より悪い問題を生みます。新しいAPIキーやクォータ増分が必要なエンジニアはチケットを起票し、待ち、フォローアップして、1日以上を失います。LLMがコアな開発ツールである環境では、この摩擦は、ほとんどのAIプロダクト価値が生まれる「実験のスピード」を直接的に低下させます。
適切なトレードオフは、自動強制であり、開発には寛容なデフォルト、本番にはより厳格なポリシー、そして全員に対するリアルタイムの可視性を用意することです。エンジニアは素早く動けます。プラットフォームチームは制御を維持できます。財務は予測可能な数字を得られます。
はじめる
複数チームにまたがってLLMワークロードを運用しており、現在はプロバイダに直接ルーティングしている場合、TrueFoundryでの移行手順はシンプルです。既存のクライアント設定でベースURLとAPIキーを更新し、プラットフォーム上でチームの予算を設定し、高い支出になっているモデルについてフォールバックルーティングを構成します。
TrueFoundryのAIゲートウェイは、単一のvCPUで3〜4msの追加レイテンシにより、毎秒350件以上のリクエストを処理します。これは、アプリケーションのパフォーマンスや開発者体験に影響を与えるような閾値を大きく下回っています。これは、AIゲートウェイの2025 Gartner Market Guideに掲載されています。
エンジニアは統制の層に気づかないでしょう。財務は請求書に気づきます。
TrueFoundryのAIゲートウェイを詳しく見る →
