LLMコストモニタリング:請求が跳ね上がる前に把握する(2026)

LLMコストモニタリング:請求が跳ね上がる前に把握する(2026)

LLMコストモニタリングがあるかどうかで、412ドルの不意打ち請求書になるか、予算の80%時点でSlackに通知が届くかが分かれます。Claude Sonnet 5は今月、入力トークン100万あたり3.00ドルで課金されますが、暴走したエージェントのループが1件あるだけで、午後のうちにその額を燃やし尽くしかねません。ほとんどのチームはトラッキングを1日で組み込みます。本当に省かれがちなのは、アラートのほうです。

要点:

• LLMコストモニタリングは、すべてのリクエストにトークン数とドル換算の見積もりを付与し、モデル別・チーム別に集約する仕組みです。
• 追うべき指標は5つあります。リクエストあたりのトークン数、機能/チーム/モデルあたりのコスト、キャッシュヒット率、会話あたりのコスト、急騰率です。
• LiteLLMの予算管理、Langfuseのトレース、Datadog LLM Observabilityのいずれを使っても、1日かからずコストの可視化が立ち上がります。
• ダッシュボードに表示されるのは見積もりです。キャッシュ入力価格とバッチ割引があるため、実際の請求額はそれを下回るケースが大半です。

LLMコストモニタリングが実際に追跡するものとは?

LLMコストモニタリングとは、すべてのLLMリクエストにトークン数とドル換算の見積もりを付与し、それを見積もりをモデル・機能・チーム別に集約することで、請求書が届く前にアラートを上げられるようにする運用です。見積もりは公開されているトークン単価からリクエストごとに計算され、呼び出しに付与したタグで集計され、事前に設定した予算と照合されます。

その計算の土台はベンダー非依存です。どのプロバイダーの利用状況レスポンスもトークンをフィールド単位で内訳しており、Datadogのコストドキュメントはその関係を明示的に記載しています。OpenTelemetry GenAIセマンティック規約は同じフィールド群をベンダー横断で標準化しているため、これを土台に作ったダッシュボードは特定プロバイダーに固定されません。

大部分の説明がつく関係性は3つです。総トークン数 = 入力 + 出力。入力 = 非キャッシュ + cache_read + cache_write。そしてreasoningトークンは出力の中に含まれ、出力単価で課金されます。ここを押さえればリクエストごとの見積もりは実額に近づきます。無視すると、ダッシュボードは毎月のように請求書からずれていきます。コストモニタリングはAIオブザーバビリティという柱の1本にすぎません。トレースと評価が残りの2本で、この3本は同じフィールド語彙を共有しています。

ダッシュボードが見せるのは見積もりです。キャッシュされない唯一のコスト指標は、請求書そのものです。

LLMの100万トークンはいくら?

モデルと方向で決まります。100万トークンあたり、DeepSeek-V4の入力なら0.14ドル、GPT-5.6 Terraの出力なら15.00ドルで、同じ単位で100倍の開きがあります。以下は2026年7月14日の価格調査から4モデルを抜き出し、公式ページで確認したものです。

出典:OpenAIの価格ページとAnthropicの価格ページ。注釈が1つあります。Claude Sonnet 5は2026年8月31日まで導入価格(入力2.00ドル / 出力10.00ドル)で提供され、その後は上記の数字に戻ります。

実際に重要な5つの指標

LLMコスト管理を担う指標は5つありますが、実際にアラートを設定しているチームは大半が2つだけです。まず最初の2行から始めてください。リクエストあたりのトークン数はプロンプトの肥大化が出た当日に捉え、チームあたりのコストは経理部門がいずれ必ず聞いてくる数字です。残りの3つは、この2つが回ってからの解像度向上に使います。

粒度について1つ注意があります。Datadogはコストドキュメントのとおり、リクエスト単位のコストをナノドル(ドルの10億分の1)で保存します。100万トークン0.14ドルでは、DeepSeek-V4のリクエスト1件が1セントの1000分の1を下回り得るため、丸める前に集約してください。そうしないと小規模モデルのトラフィックがレポートから消えます。

他を何も追わないとしても、1行目と2行目だけは追ってください。リクエストあたりのトークン数は最速の予兆です。チームあたりのコストは、経理部門と向き合っても耐える唯一の数字です。

LLMコストモニタリングを構築する3つの方法

このクエリで上位表示されるページの中に、実行可能なコードを1行でも載せているものはゼロです。そこで、動く構成を3つ示します。いずれも1日かからず本番投入でき、組み合わせも可能です。私たちは最初の2つを同時に動かしています。

私たちの本番環境で実際に動かしているのは次の構成です。すべてのクライアントエージェントがそれぞれの仮想キーでLiteLLMプロキシに接続し、キーごとに月次予算を設定、プロキシの背後でLangfuseが全リクエストをトレースします。 この2つを同時にデプロイしたとき、役割分担こそが狙いでした。プロキシが上限を強制し、トレースがその消費の中身を説明します。 クライアントキーごとに、2本目のヒューズとして1分あたり10万トークンのtpm_limitも設定しています。LiteLLMのドキュメントによれば、上限に達するとプロキシはリクエストを拒否します。私たちが頼りにしているのはこの文書化された挙動であり、自社で測定したベンチマークではありません。 また、2026年3月のサプライチェーンインシデントで問題のあったLiteLLM 1.82.7と1.82.8は完全に避け、イメージタグをlatestに流さず固定しています。

LiteLLMプロキシ:仮想キー + 予算

TechsyはLiteLLMプロキシの構成を本番で運用しており、クライアントごとに仮想キーを1本、キーごとに月次予算を設定しています。以下のリクエストはLiteLLMのvirtual_keysドキュメントに記載された形式そのものです。同ドキュメントによれば、このキーの累計支出が月内で50ドルを超えた時点で、プロキシは事後の警告ログではなく予算超過エラーで以降のリクエストを拒否します。

curl -X POST http://localhost:4000/key/generate \
  -H "Authorization: Bearer $LITELLM_MASTER_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "key_alias": "client-acme-search",
    "max_budget": 50.0,
    "budget_duration": "monthly",
    "tpm_limit": 100000,
    "models": ["anthropic/claude-sonnet-4-5"]
  }'

公開価格で計算してみます。Claude Sonnet 5の100万トークンあたり3.00ドル / 15.00ドルなら、50ドルで買えるのは入力トークン約1670万、または出力トークン約330万です。私たちの軽めのクライアントエージェント1本の、おおよそ1週間分のトラフィックに相当します。まさに狙いどおりの影響半径です。tpm_limitは2本目のヒューズで、暴走ループは月次予算に達するずっと前に、1分あたり10万トークンの上限で止まります。ユーザー単位の紐付けもusersエンドポイントで同じように実現できます。プロキシがその価値を発揮する場面と、単なる中継点で終わる場面は、LLMゲートウェイツール比較で詳しく扱っています。

Langfuse:@observeによるコストトレース

Googleのサジェストが「langfuse monitoring」とこのクエリを並べて表示するのは偶然ではありません。Langfuseはオープンソースのトレース基盤として事実上の標準です。Python SDKがプロバイダークライアントをラップし、Langfuseのトレースドキュメントのとおり、すべての呼び出しがトークン数と計算済みコストを持つトレースになります。

# pip install langfuse openai
from langfuse import observe
from langfuse.openai import openai  # drop-in wrapper, auto-traces

@observe()
def answer(question: str):
    return openai.chat.completions.create(
        model="gpt-4o-mini",
        messages=[{"role": "user", "content": question}],
    )

answer("what is llm cost monitoring")
# the trace now carries usage.total_tokens and total_cost,
# priced from Langfuse's model price cards

こちら側でトークン計算をしなくても、コストはトレースに乗ってきます。トレースをセッションIDまたはユーザーIDでグループ化すれば機能単位の集計ができ、データを社外に出せない場合はセルフホストも選べます。

Datadog LLM Observability:すでに使っているなら

チームがすでにDatadogエージェントを展開しているなら、そのLLMコストドキュメントはこのページで最も深い単一の参考文献です。ナノドル単位のリクエストコスト、チーム別・機能別の内訳を作るカスタムcost_tags、そしてコスト欠損の実際のトラブルシューティングまで載っています。正直な限界もあります。Datadog専用だということです。指標はプラットフォームの外に出ず、価格が合わなくなったときのオープンソースの逃げ道もありません。選ぶなら集約のために選ぶのであって、柔軟性のために選ぶツールではありません。

予算・アラート・チャージバックをどう組み込むか?

3層で組みます。上限でリクエストを拒否する予算キャップ、キャップの手前で割合閾値をきっかけに発火するWebhookアラート、そしてショーバックとチャージバックを議論ではなくクエリに変えるチーム単位の仮想キーです。LiteLLMはこの3つをすべて標準で備えています。このパターンは、キー単位で予算を管理できるゲートウェイならどれにでも応用できます。

集計するだけの予算はレポートです。上限でリクエストを拒否する予算こそが統制です。

急騰の前に鳴るアラート

アラートは上限の100%ではなく80%に設定します。LiteLLMにはSlackアラートが組み込まれています。general_settingsにalerting: ["slack"]とalerting_threshold: 80を設定し、環境変数SLACK_WEBHOOK_URLをチャンネルに向けると、キーが閾値を超えた時点で次のようなメッセージが届きます。

{
  "text": "LLM budget alert: client-acme-search spent $40.18 of its $50.00 monthly cap (80.4%). Top model: anthropic/claude-sonnet-4-5."
}

80%の時点なら、人間が動ける猶予がまだ数日あります。モデルをダウングレードする、プロンプトを引き締める、承認者の名前を付けて上限を引き上げる、のいずれかが選べます。100%で鳴るアラートは、死後の検死です。

ショーバックからチャージバックへ

ショーバックは各チームが自分たちの支出を確認できる状態、チャージバックはその支出がチームの予算から差し引かれる状態です。どちらも必要な材料は同じで、チームごとに仮想キーを発行し、作成時にタグを付けるだけです。月次レポートは、あとは支出テーブルのgroup-byで済みます。

これはフォーマットの例であり、クライアントのデータではありません。evals-batchの行は、この仕組みが意図どおりに動いている姿です。バッチ処理は上限まで走って止まり、請求書にこっそり混入することはありませんでした。強制の挙動はLiteLLMのvirtual_keysドキュメントに、予算期間のリセット方法を含めて記載されています。

ダッシュボードと請求額が一致しない理由

ダッシュボードが定価で課金するのに対し、請求書はモニタリングから見えない割引を適用するためです。キャッシュ入力は基本価格の0.1倍〜0.25倍で着地し、バッチは半額になり、reasoningトークンは出力カウントの中で出力単価で課金されます。2つの数字がずれるとき、低いのはたいてい請求書のほうで、その差はほぼ常に4つの変動要因のいずれかです。

オープンソースのpydantic/genai-pricesカタログを見れば、これらの倍率がモデルごとに異なる理由が分かります。キャッシュ係数もバッチ係数も各プロバイダーが独自に決めるため、ハードコードした単価テーブル1枚は、プロバイダーが価格表を改定した日からずれます。Datadogのコストドキュメントは、もう半分の問題、つまりトークンフィールド欠損でリクエストがCOST UNAVAILABLEを返す部分的コスト欠損を記載しています。ダッシュボードが請求書より低いときはそこを確認し、高いときは割引テーブルを確認してください。最大の倍率の裏にある仕組みはLLMプロンプトキャッシングで、キャッシュヒット率の高さは、追跡見積もりが実際の請求額を上回る最も一般的な理由です。

キャッシュヒットとバッチ割引を織り込まないコスト見積もりは、予測ではなく上限値です。

LLMコスト管理に実際使えるツールはどれか?

本番構成の大半は6つのツールで足ります。オープンソースとゲートウェイ側にLangfuse、LiteLLM、Helicone、Portkey、商用側にDatadogとBraintrustです。正直な棲み分けは、強制か観測かです。プロキシは予算に達したリクエストを拒否でき、トレースツールは事後に支出を測定します。成熟したスタックは、最終的に両方を1つずつ備えることが多いです。

この領域のベンダー発信コンテンツには1つ注意があります。Braintrust自身による2026年のコスト追跡ツール比較は、自社を1位に置き、上の表にあるオープンソースの選択肢をすべて省略しています。ベンダーのまとめ記事はランキングではなく、データのために読んでください。

ゼロから始めるチームなら、手前にLiteLLM、背後にLangfuseを置く構成を勧めます。プロキシが予算を強制し、トレースがその中身を説明し、この組み合わせはホスティングの有料プランに移行するまで費用がかかりません。2つのトレース標準で迷っているなら、Langfuse vs Langsmithの比較でその選択を深掘りしています。分野の全体像はAIオブザーバビリティプラットフォーム比較で網羅しています。

モニタリングからコスト削減へ

モニタリングはお金の行き先を示します。次のステップは、そこにいくら回すかを決めることです。効果の大きい順に3つのレバーがあります。繰り返しの入力をキャッシュする、簡単なリクエストを安価なモデルに振り分ける、品質が保てる範囲でモデルをダウンサイズする、の3つです。LLM APIコスト削減ガイドで各レバーを扱っており、上記の計算すべてのインプットになるのがLLM API価格比較です。

私たちのスタンスは明確です。クライアントのLLM支出が想定外だったとき、先にモニタリングし、削減は後から行います。逆は絶対にやりません。測定前にキャッシュを始めたチームは、たいてい間違ったプロンプトをキャッシュします。モニタリングはお金の行き先を教え、キャッシュとルーティングはその額を決めます。すでに請求書が痛いなら、無料相談で数字を一緒に見ます。

著者について

Mert BaturはTechsy.ioの共同創業者です。同社チームはB2Bクライアント向けにAIエージェント、自動化システム、音声/SDRパイプラインを提供しています。Techsyチームが本番で実際に使っているLLMツールスタックについて執筆しています。LinkedInでつながってください。

よくある質問

LLMの100万トークンはいくら?

定価では、モデルと方向に応じて100万あたり0.14ドルから15ドルまで幅があります。DeepSeek-V4の入力は100万あたり0.14ドル、GPT-5.6 Terraの出力は15ドルです。出力トークンは主要プロバイダーすべてで入力単価の3〜6倍です。最初のセクションの表に4モデルを掲載しており、LLM API価格比較では17モデルすべての価格を、2026年7月にOpenAIとAnthropicのページで確認したうえで掲載しています。

LLMコスト最適化とは?

品質を落とさずリクエストあたりのコストを下げる実践です。繰り返しの入力にはプロンプトキャッシング、簡単なタスクは安価なモデルへのルーティング、非同期処理にはBatch API、そして機能ごとのモデル適正化です。前提となるのがLLMコストモニタリングで、帰属が分からないものは最適化できません。キャッシュヒット率と機能あたりのコストは、最大のレバーを先に指し示す2つの指標です。

LLMはなぜこれほど高いのか?

推論は計算資源に制約されます。生成されるトークンは1つ残らず、GPU上でモデルのフォワードパスを1回実行します。reasoningモデルは回答の前に追加トークンを思考に使い、出力単価で課金されます。長いシステムプロンプトはそのコストをリクエストすべてに掛け算します。請求額は呼び出しの両側の冗長度とともに膨らむため、リクエストあたりのトークン数こそ最初に見る価値のある指標です。

アメリカでLLMを使うといくらかかる?

API価格は米ドル建てで、世界共通です。OpenAI、Anthropic、Googleは、リクエストがオハイオ州から来ても大阪から来ても、100万トークンあたりの定価は同じです。地域差が出るのはセルフホスティングで、GPU時間はクラウドリージョンによって変わり、マークアップを乗せるホスティングプラットフォームでも差が出ます。API利用については、所在地が変わるのはレイテンシであり、価格ではありません。

チームごとのLLMコストはどう追跡する?

LiteLLMのようなプロキシでチームごとに仮想キーを1本発行し、作成時にキーへチーム名をタグ付けし、そのタグで支出を集約します。これで全リクエストは発行された瞬間から帰属情報を持ち、ログ解析は不要です。上の予算セクションにあるショーバックテーブル、つまりチーム、月次予算、当月支出、ステータスが最終成果物です。

LLMコスト追跡はLangfuseとDatadogのどちらを選ぶべき?

オープンソース、セルフホスト、自社管理のデータが欲しいならLangfuseです。運用コストは無料で、リクエストごとのコストはすぐにトレースできます。Datadogを選ぶのは、チームがすでにインフラ用途で使っている場合だけにしてください。LLMコスト機能はプラットフォームの外に出ないためです。ゼロから始めるほとんどのチームには、LangfuseとLiteLLMプロキシの組み合わせが、単独のどちらよりも優れています。

LLMコストの見積もりは実際の請求額と一致する?

一致しません。そしてたいてい請求額のほうが低くなります。ダッシュボードは定価で課金しますが、キャッシュ入力は0.1倍〜0.25倍、バッチジョブは0.5倍で着地するため、キャッシュの多いワークロードでは実際の請求額が追跡見積もりを大きく下回ります。トークンフィールドの欠損は誤差を逆方向に押します。上のドリフト表に各倍率と確認先をまとめています。

LLM支出の急騰アラートはどう設定する?

各チームの月次予算の80%で閾値アラートを設定し、WebhookでSlackに届けます。加えて、高速で燃えるループ用に前日比+50%の異常検知アラートを置きます。LiteLLMはalerting_threshold設定でこの閾値パターンを標準で提供しています。80%のアラートなら対応に数日の猶予があります。100%のアラートは、キャップが仕事を果たしたことを確認するだけです。

無料で使えるLLMコストトラッカーはある?

信頼できるものが3つあります。セルフホストのLangfuseは無料でオープンソース、Langfuseの価格ページのとおりクラウドにも無料ホビー枠があります。LiteLLMのキー予算はオープンソースプロキシ上で無料で使えます。Heliconeの無料枠はレート制限付きでプロキシレベルのコストログをカバーします。無料枠でカバーできるのはモニタリングまでです。大規模な強制とアラートは、有料プランの領域です。

結論

今日、構成の道筋を1つ選んでください。6週間後に欲しくなるアラートは、今なら午後の時間で組み込めます。短くまとめると、次のとおりです。

• まずリクエストあたりのトークン数とチームあたりのコストを追う。残りの3指標は、この2つが機能してから足す。
• リクエストを拒否する予算は統制。集計するだけの予算はレポート。
• アラートは80%で、Slackに、請求書が誰かを驚かせる前に設定する。
• ダッシュボードは見積もり。キャッシュ入力とバッチ価格があるため、請求額はたいていそれを下回る。

数字を誰かと一緒に見たい場合は、無料相談をご利用ください。