開発解説
LLM API運用で何をログに残す?token・遅延・品質を同じrequestで追う

目次
結論
request IDを軸にtoken・latency・error・quality判定を結びます。一方、prompt本文や機密データを無条件にログへ保存する設計は避け、内容と運用メタデータを分離します。
判断の順番は 必須条件→費用/性能の得失→運用条件 です。価格、plan、求人、hardware仕様など時間で変わる事実には 2026-09-13 の観測日を付け、未測定の速度・品質・時間・電力を公式仕様から推測して数値化しません。
判断表:PIIを除いたAI request observability schema
{
"request_id": "...",
"provider": "...", "model": "...", "model_version": "...",
"route": "primary|fallback", "feature": "...",
"usage": {"input": null, "output": null, "cache": null, "billable_unit": "provider_raw"},
"latency_ms": {"end_to_end": null, "provider": null, "ttft": null},
"result": {"http_status": null, "tool_calls": null, "schema_valid": null},
"quality": {"eval_set": null, "score": null, "user_feedback": null},
"privacy": {"prompt_stored": false, "redaction_policy": "..."}
}
costとqualityを別dashboardにしないのが要点です。同じrequest_idへusage、latency、schema/ツール成否、後付けevalを結びます。prompt本文は既定で保存せず、必要ならredaction/consentを別設計します。
判断の前提
LLM APIはproviderを替えてもHTTP requestが同じになるわけではありません。message構造、ツール schema、structured output、rate limit、error semanticsを契約として扱います。
運用ではprovider公式のtoken/limitだけでなく、自分のrequest IDとlatency/error/quality評価を結びます。ただしprompt本文や個人情報を無条件にtelemetryへ載せません。
migration/fallbackは「返答が出たら成功」ではなく、schema validation・ツール実行・policy・評価セットまで同等に通ることをrelease条件にします。
このテーマで実際に見るポイント
request
request_id/provider/model/versionを必須keyにする。
usage
input/output/cache tokenなどproviderのbillable unitをrawで保持。
latency
end-to-endとprovider call/TTFTを分ける。
quality
offline evalまたはuser feedbackをrequest_idへ後付けできる形にする。
選ばない・進めない条件
schema/ツール/policy/rollbackが代表evalを通らないprovider/modelへ切り替えない。
これは「慎重に」という抽象論ではなく、比較表の必須条件を満たさない候補をランキングから外すための公開条件です。
一次情報
- OpenTelemetry — GenAI semantic conventions
- OpenAI API — Compare models
- Anthropic — Rate limits
- Google AI — Gemini API rate limits
- Google AI — Function calling
まとめ
request IDを軸にtoken・latency・error・quality判定を結びます。一方、prompt本文や機密データを無条件にログへ保存する設計は避け、内容と運用メタデータを分離します。
変化が速い領域ほど固定ランキングより、同じinputで更新できるPIIを除いたAI request observability schemaを正本にします。更新時は変化した項目だけを最新の情報源/実際の観測結果で差し替え、同じ判断基準で結論を再計算します。
まとめ
- request IDを軸にtoken・latency・error・quality判定を結びます。一方、prompt本文や機密データを無条件にログへ保存する設計は避け、内容と運用メタデータを分離します。 変化が速い領域ほど固定ランキングより、同じinputで更新できる**PIIを除いたAI request observability schema**を正本にします。更新時は変化した項目だけを最新の情報源/実際の観測結果で差し替え、同じ判断基準で結論を再計算します。