LLM 機能を本番で動かすなら、観測（Observability）は「あれば便利」ではなく最初に仕込む配線です。LLM は同じ入力でも出力が揺れ、料金は呼ぶたびに発生し、失敗は静かに混ざります。何が起き・いくらかかり・どこで失敗したかを後から追えるよう、ログ・トレース・メトリクスの3点をはじめから埋め込みます。本稿は2026年時点の標準である OpenTelemetry の GenAI 規約に沿って、初学者でも組めるよう具体的に整理します。
FIG.1 1つのリクエストを、ログ・トレース・メトリクスの3つの視点で同時に記録する
01なぜ LLM は特に観測が要るのか
普通の Web API なら「200 が返ったか」「何ミリ秒か」を見れば概ね足ります。LLM 機能はそれだけでは不十分です。理由は次の3つで、いずれも従来の監視では拾えません。
- 出力が毎回ゆらぐ：同じ質問でも答えが変わる。再現には「そのとき渡したプロンプト・モデル・パラメータ」の記録が要る。
- 呼ぶたびに課金される：料金は入力・出力のトークン数に比例する。どの機能・どのユーザーが費用を生んでいるかは、トークンを記録しないと分からない。
- 失敗が静かに混ざる：HTTP は 200 でも、中身が幻覚（事実でない断定）だったり、根拠を引けていなかったりする。「成功扱いの失敗」を見つけるには中身の観測が要る。
02取るべき3種：ログ・トレース・メトリクス
観測の基本は「3本柱（three pillars）」と呼ばれる、ログ・トレース・メトリクスです。役割が違うので、どれか1つでは足りません。
ログ（Logs）
個々の出来事の記録。入力（要約/匿名化）・出力・エラー・どの分岐を通ったか。「あの1件で何が起きたか」を後から読む。
トレース（Traces）
1リクエストの処理経路。プロンプト構築 → 検索 → 生成 → 後処理を1本の流れとして可視化し、遅い/落ちた箇所を特定する。
メトリクス（Metrics）
数値の集計。レイテンシ・トークン数/コスト・失敗率・拒否率を時系列で見て、傾向や異常を検知する。
典型的な分担はこうです。メトリクスでダッシュボードを眺めて「失敗率が上がった」と気づき、トレースで「検索段で落ちている」と当たりを付け、ログでその1件の入力・出力を読んで原因を確かめる。粗→細へ降りていく流れです。
03トレースの構造：スパンが入れ子になる
トレースはスパン（span）という区間の入れ子で表します。1リクエスト全体が親スパン、その中の各処理が子スパンです。エージェント型（道具を呼ぶ AI）では、2026年時点の OpenTelemetry GenAI 規約で次のような木構造が標準になっています。
