本番環境でLLM機能に問題が起きたとき、最初に必要なのは「そのリクエストで実際に何が起きたか」です。アプリケーション側のログだけでは、リクエストを送ったこととレスポンスを受け取ったことしか分かりません。リトライ、フォールバック、レイテンシの内訳は、リクエストパスの途中にあるゲートウェイだけが見ています。
リクエストIDが結合キーになる
nRouterはすべての呼び出しに1つのリクエストIDを発行し、レスポンスヘッダーで返却します。同じヘッダーには、そのリクエストのコストと、実際に応答したモデルも含まれます。アプリケーション側でこのIDを自前の相関IDと一緒に記録しておけば、後からそのIDでリクエストログを開き、ルーティング、フォールバックの試行、プロバイダとの往復、決済までのタイムラインを確認できます。
ログ行に必要なもの
有用なログ行は、モデル、プロバイダ、ステータス、レイテンシ、トークン数、コストを1行にまとめたものです。nRouterのリクエストログは、リクエストID、モデル、プロバイダ、ステータス、キー、チーム、時間で検索とフィルタができます。成功したリクエストだけでなく、レート制限、キャッシュヒット、ガードレールによるブロックも同じストリームに理由付きで記録されます。ブロックされたリクエストが理由と一緒に残っているかどうかで、調査時間は大きく変わります。
レイテンシは2つの数値
ストリーミングでは、合計時間だけでは体験を表せません。最初のトークンまでの時間(TTFT)と合計時間を分けて記録することで、「表示が始まるまでが遅い」のか「生成全体が遅い」のかを区別できます。nRouterはこの2つを分けて追跡し、モデル、キー、チーム、組織ごとにパーセンタイル(p50、p95、p99、最大値)を報告します。
コストは一度だけ計算する
コストはゲートウェイで一度だけ計算し、その同じ値をリクエストログ、クレジット台帳、CSVエクスポート、分析に使うのが原則です。価格付けできないレスポンスは「未価格」とフラグされ、ゼロとして記録されることはありません。ゼロと書くことは主張であり、誤ったゼロは下流のすべてのレポートを壊します。
メタデータのみ、という境界
ログに保存するのはメタデータのみで、プロンプトとレスポンスの本文は保存されません。この境界があるからこそ、同じ記録を障害対応、支出の照合、ポリシー変更の監査に使えます。監査証跡はリクエストログより長く保持されます。
まとめ
1つのID、事実をまとめた1行、最初のトークンで分けたレイテンシ、一度だけ計算されるコスト、そして本文ではなくメタデータ。詳細は nRouterのオブザーバビリティページ にまとまっています。自前のスタックで「先週火曜日のあのリクエスト」を見せられるか、比べてみる価値があります。