Q7　LLM の監視・運用

Q7. LLMの監視・運用

本番でLLMの挙動を監視するとき、トレースやトークン数、レイテンシ、エラー、ドリフトなどを実際にどう見ていますか？ 異常に早く気づくためにどんなダッシュボードやアラートを組んでいて、そこから改善につなげた経験があれば教えてください。

出典: @voidwarriorchan の投稿（2026-08-25）

この質問は何を聞いているのか

質問文には専門用語が並ぶ。本番（production）とは開発中の試作ではなく実際のユーザーがLLMを使う環境のことだ。トレース（trace）は「1回のリクエストが処理される一部始終」の記録で、その中の1つ1つの処理ステップをスパン（span）と呼ぶ。レイテンシ（latency）は応答が返るまでの待ち時間、ドリフト（drift）は本番で観測される中身が過去の基準からずれていく現象を指す。ダッシュボードは指標をまとめて表示する画面、アラートはしきい値超過を人へ通知する仕組みだ。

つまりこの質問は、LLMを使ったアプリを動かしっぱなしにするのではなく、「1件のリクエストの中で何が起きているか」「トークンとお金がどれだけ動いているか」「どれくらい待たされているか」「エラーは何が原因か」「入力やモデルの中身が知らぬ間に変わっていないか」の5つを数値として取り出し、しきい値を決めてアラートを組み、改善した経験があるかを尋ねている。ログを流し見するだけでは答えられず、指標設計・アラート運用・改善までの経験がないと具体的に話せない。候補者が「動かして終わり」でなく「動かし続ける」仕組みを構築した経験があるかを測る質問だ。

各社はこの木構造を少しずつ違う言葉で呼ぶが、指している概念は同じだ。対応関係を押さえておけば、面接で聞かれても混乱しない。

仕組みの解説① — レイテンシとトークンを測る

レイテンシの内訳 — TTFTとTPOT、prefillとdecode

「応答が遅い」を1つの数字で語ると原因を見誤る。LLMの処理は読み込み段階（prefill）――入力全体を一括で読み込んで理解する処理――と、書き出し段階（decode）――理解した内容をもとに1トークン（= モデルが文章を扱う最小単位）ずつ生成する処理――の2段階に分かれ、レイテンシもTTFT（Time To First Token、最初の1トークンが出るまでの時間）とTPOT（Time Per Output Token、2トークン目以降の1トークンあたりの生成時間）の2つに分けて測るのが標準的だ。OpenTelemetry（以下OTel。特定ベンダーに依存しない、測定用コードをアプリに仕込む＝「計装」の共通規格）の定義では、TTFTは「キュー待ち（サーバーで順番待ちしている時間）＋prefillの時間」、TPOTは「decode段階の性能」を表す。

出力トークン数がレイテンシを支配する点は見落とされやすい。OpenAIの公式ガイドは「出力トークンを50%減らせばレイテンシもおよそ50%減る」一方、「プロンプトを50%短くしても改善は1〜5%程度」と明記している。「遅い」対策はまず出力を短くする・不要な生成をやめることが効きやすく、プロンプト圧縮の優先度は低い。ストリーミング（トークンを都度クライアントへ送る方式）は体感の待ち時間を最も削る手段として公式が挙げ、「読み始められる時刻」をTTFTまで前倒しできる。

トークンとコストの内訳 — 二重に数えない

入力トークンは一枚岩ではない。プロンプトキャッシュ（prompt caching）――直前までの入力の計算結果を保存し使い回す仕組み――を使うと、1回のリクエストの入力トークンは「キャッシュ読み取り分（cache read）」「キャッシュ書き込み分（cache creation）」「キャッシュに関与しない分」の3種類に分かれる。Anthropicではこの3種類で課金倍率とレート制限（一定時間あたりに送れる量の上限）への算入有無が異なり、読み取り分は基準価格の0.1倍でほとんどのモデルでは入力トークンのレート制限（ITPM = 1分あたりの入力トークン上限）にも数えられない。書き込み分は保持5分なら1.25倍・1時間なら2倍でレート制限に数えられ、残りは基準価格でレート制限に数えられる（いずれも2026-08時点）。ストリーミング中のusageは差分でなく累積値なので、逐次足し算すると二重計上になる。

ここで初心者がつまずくのが、規約によって「入力トークンの合計」の指す範囲が違うことだ。OpenTelemetryのGenAI規約では入力トークン数はキャッシュ分も含めた総和として定義される。一方でAnthropicのAPIが返すinput_tokensは、キャッシュの区切り（cache breakpoint）より後ろのトークンだけを指し、キャッシュ読み取り・書き込み分は含まない。合計はcache_read_input_tokens + cache_creation_input_tokens + input_tokensを自分で足す必要がある。同じ「input_tokens」でも意味が逆なので、ダッシュボードでは集計の定義を揃えないと数字が合わなくなる。

仕組みの解説② — エラー・品質・ドリフトを見張る

エラーとレート制限 — 429は一つではない

429エラー（レート制限やアクセス過多を示すHTTPステータス）は原因によって対応がまったく変わる。一時的なレート制限ならレスポンスにretry-afterヘッダ（待つべき秒数）が付き、SDK（APIを呼ぶための公式ライブラリ）が指数バックオフ（待ち時間を倍々に伸ばす再試行方式）で自動的に再試行する。Anthropicの場合、支出上限（スペンドキャップ）による429にはretry-afterヘッダが付かず、上限解除まで何度リトライしても失敗し続ける。Anthropicはerror.details.error_code（例: enforced_spend_limit_reached）でこの2つを見分けており、OpenAIも429を5つの意味に分け、一時的なレート制限以外の4つにはcredit_balance_exhausted・organization_spend_limit_exceeded・project_spend_limit_exceeded・organization_usage_limit_exceededというコードが付く。急激なリクエスト増加はAnthropicではacceleration limitによる429、OpenAIでは503「Slow Down」として返り、対策はどちらも急にペースを増やさないこと（Anthropic: 徐々にランプアップ、OpenAI: 元のペースに戻し15分維持後に段階的に上げる）である。

もう1つの落とし穴は、ストリーミング応答ではHTTP 200を返した後にエラーイベント（event: error）が来ることがある点だ。HTTPステータスだけで集計すると、ストリーミング中の失敗を取りこぼしてエラー率を過小評価する。

品質とドリフト — LLM-as-a-Judgeと2種類の変化

LLM-as-a-Judge（別のLLMを「判定器」として使い、採点基準〈rubric〉に沿って出力の質をスコア化する評価手法）は、本番トレースに継続的に走らせるオンライン評価と、変更前にデータセットへ走らせるオフライン評価の両方で使われる。LangfuseのFAQは、優れた判定モデルは人間の評価者と80〜90%程度一致し、これは人間同士の評価者間一致率と同程度だと説明している。裏返せば判定器も人間と同じ程度にはぶれるので、少数の人手ラベルと突き合わせて較正（calibrate）することを同じFAQが勧めている。判定器自身も小さな機械学習システムとして、継続的な検証の対象になる。

ドリフトは2つの現象を指す。1つは入力データの分布変化――ユーザーの質問の傾向が過去と変わること――で、テキストでは基準期間（reference）と直近期間（current）を区別する2値分類モデル（ドメイン分類器）を訓練し、うまく区別できるほどドリフトが疑われる。もう1つはモデル提供側の変化――モデル自体がプロバイダによって更新・非推奨化・廃止されること――で、Anthropicはライフサイクルを Active（現行）→ Legacy（更新終了）→ Deprecated（非推奨、代替と廃止日を提示）→ Retired（提供終了、失敗する）の4段階で定義し、廃止の少なくとも60日前に通知する（2026-08時点）。

実務では何をするのか

マネージドAPIを使う場合

AnthropicはUsage & Cost Admin APIを提供しており、トークン使用量は時間バケット（集計の区切り幅。1m＝1分／1h＝1時間／1d＝1日）で、コストは日次（1d）のみで集計できる。データは通常リクエスト完了から5分以内に反映される（遅れることもある。2026-08時点）。1分に1回のポーリング（定期的に問い合わせて取得すること）が想定される。公式ユースケースは「キャッシュ効率の測定」「予算超過アラート」「レート制限の最適化」。Rate Limits APIで現在の制限値を読み取り、使用量と突き合わせて内部アラートを組むことも推奨される。anthropic-ratelimit-*ヘッダ（上限・残量・回復時刻）はリアルタイム監視に使える。OpenAIも同様に時間バケット・グルーピング指定可能なUsage/Costs APIとx-ratelimit-*ヘッダを持つ。

観測基盤・自前ホスティングを使う場合

モデルを自前のサーバーで動かす場合、OpenTelemetryのGenAI規約は「モデルサーバー側」の指標としてgen_ai.server.time_to_first_token（キュー待ち＋prefillの時間）とgen_ai.server.time_per_output_token（decode段階の性能）を定義しており、これに沿って計装すればprefillとdecodeの性能を分けて観測できる（まだ「Development」段階＝安定版ではない）。Langfuseはこの OpenTelemetry の上に作られており、Phoenix・Datadog も送られたgen_ai.*属性を受け取れる。LangSmith も run（= OTel の span 相当）で同じ概念を扱う。トークン数・モデル名が送られれば価格表からコストを自動計算するが、推論（思考）トークンを使うモデルはトークン数が無いとコストを推定できない。

これらの基盤は監視項目を①運用メトリクス（量・レイテンシのp50/p95/p99〈p95 = 全体の95%がそれより速く、残りの遅い5%がそれより遅い、という境界の値。平均には出ない一部の遅さを表す。p50は中央値、p99は上位1%〉・TTFT・エラー率・トークン・コスト）②トレース（個別リクエストの生データ）③品質スコアの3層で標準ダッシュボードとして用意している。アラートはLangfuse・LangSmithともに対象メトリクス・しきい値・集計ウィンドウを設定して発報する仕組みが用意されている（詳細は後述の表）。サンプリングには、開始時に一定割合だけ残す「head sampling」（速いが失敗トレースを取りこぼす恐れ）と、全スパンを保持してから属性で選別する「tail sampling」（正確だが重い）があり、分散システムではparentbased_traceidratioでトレース単位の一貫性を保つ。

改善につなげる仕組みとして、本番トレースをエラー・低評価スコアや数%サンプリングで注釈キュー（人が見るキュー）やデータセットへ流し込み、人手評価やLLM-as-a-Judgeの較正・比較実験を経てCI（自動テストの仕組み）でリグレッション（以前できていたことができなくなる退行）をブロックしてから再デプロイする、というループを各社が公式機能として用意する。本文はOpenTelemetryの既定では記録されず、記録時はマスキング（送信前に機微情報を伏せる処理）が必要になる。

回答を見極めるポイント

深掘り質問の例

• 429を受け取ったとき、retry-afterヘッダの有無で対応をどう変えますか？
• トークン数を内訳で見る理由は何ですか？
• LLM-as-a-Judgeの判定結果をどう検証していますか？

つまずきポイント

理解度チェック

まとめ

• トレース・スパン・セッションは各社で呼び方が違うだけで、指す概念は共通している
• レイテンシはTTFT（prefillの性能）とTPOT（decodeの性能）に分けて測り、出力トークン数がレイテンシを支配する
• トークンはキャッシュ読み取り・書き込み・非キャッシュ・推論の内訳で見ないと、コストとレート制限の消費量を読み違える
• 429エラーはretry-afterヘッダやエラーコードで分類してから対応を決める。ストリーミング中は200の後にもエラーが来る
• ドリフトは「入力データの分布変化」と「モデル提供側の変化」という別々の現象であり、どちらも監視の対象になる
• 監視は運用メトリクス・トレース・品質スコアの3層で設計し、アラートから注釈・データセット化・実験・再デプロイまで含めて「運用」と呼べる

次章のQ8「モデル選定の判断基準」では、ここで見た指標を使ってタスクごとにどのモデルを選ぶかを見る。

参考リンク

• Anthropic — Rate limits
• Anthropic — Errors
• Anthropic — Usage & Cost Admin API
• Anthropic — Prompt caching
• OpenAI — Rate limits
• OpenAI — Error codes
• OpenAI — Latency optimization
• Langfuse — Observability data model
• Langfuse — Alerts
• LangSmith — Observability concepts
• Datadog — Agent Observability terms
• Evidently — Data drift detection