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 規約で次のような木構造が標準になっています。
FIG.2 親 invoke_agent の下に chat スパン、その下に execute_tool スパンがぶら下がる
すべての子スパンが同じトレース IDを共有するため、バラバラに見えるログを1リクエストとして束ねて追えます。これが「相関 ID」の正体です。LLM の呼び出しスパンには、規約で名前が決まった属性を載せます。代表的なものは次の通りです。
| 属性（OpenTelemetry GenAI 規約） | 中身 |
|---|---|
| gen_ai.request.model | 呼んだモデル名（例：使用中の生成モデルの識別子） |
| gen_ai.usage.input_tokens | 入力トークン数（プロンプト側） |
| gen_ai.usage.output_tokens | 出力トークン数（生成側） |
| gen_ai.response.finish_reasons | 生成が止まった理由（完了・長さ上限・安全停止など） |
属性名を自前で決めず規約に合わせておくと、後でダッシュボードや解析ツールがそのまま読めます。なお GenAI 規約は2026年初頭時点で多くが実験的（experimental）扱いのため、属性名は将来変わりうる前提で、計装ライブラリ任せにして自前で埋め込みすぎないのが無難です。
04メトリクスは「金額・速度・品質」で見る
メトリクスは数えるほど増えますが、最初に固定で見る指標を絞ると運用が回ります。LLM では次の組み合わせが定番です。
- レイテンシ：応答までの時間。平均だけでなく p95（遅い側95パーセンタイル）も見る。「最初の1トークンまで」と「全部出るまで」を分けて測ると体感に近い。
- トークン数とコスト：入力・出力トークンを記録し、料金へ換算。機能別・ユーザー別に集計できるよう、トレースにタグを付ける。
- 失敗率：API エラーだけでなく、空応答・タイムアウト・JSON 崩れなど「使えなかった」も数える。
- 拒否率：安全フィルタ等で生成が止まった割合。急増は入力傾向の変化やプロンプト劣化のサイン。
測れないものは改善できない。観測はコスト・速度・品質すべての改善の前提です。
05実装の勘所：相関・再現・按分・保護
具体的に何を仕込むか。順番に組み込めば、最低限の観測がそろいます。
相関 ID を最初に発行する
リクエストの入口で1つの ID（トレース ID）を作り、検索・生成・後処理のすべてのログに付与する。「ユーザー操作 → 内部処理」を1本で追えるようになる。
再現に要るものを記録する
プロンプトのテンプレート版数・モデル名・主要パラメータ（温度など）を残す。出力がおかしいとき「そのときの構成」を復元できる。
コストを按分できるタグを付ける
トークン記録に機能名・ユーザー/テナント ID を添える。後で「どこに費用が偏っているか」を集計できる。
個人情報はログに残さない
入力・出力をそのまま保存しない。要約・匿名化・マスキングを通す。後述の通り、規約も既定では本文を残さない設計。
06ツール選び：まず「入る速さ」を優先
自前で全部書くこともできますが、2026年時点では専用ツールが充実しています。要件に合わせて取捨選択すれば十分で、最初は「導入が速いもの」から始めるのが定石です。料金・無料枠は頻繁に変わるため、採用前に必ず各社の公式ページで最新条件を確認してください。
- Langfuse：オープンソース（MIT ライセンス）で自前ホスト可。トレース・プロンプト管理・評価を備え、無料枠も用意されたクラウド版もある。データを自分で持ちたいときの定番。
- Arize Phoenix：オープンソース。OpenTelemetry 上の OpenInference 標準でトレースを取る。LlamaIndex 等との相性がよい。
- Helicone：API の前段に挟むプロキシ型で導入が最速。複数プロバイダのコストを横断で可視化できる。
- LangSmith：LangChain / LangGraph との統合が最も深い。同系フレームワークを使うなら有力。
- Datadog LLM Observability：既に Datadog を使う組織向け。前述の GenAI 規約に対応済み。
共通言語は OpenTelemetry です。アプリ側を OTel で計装しておけば、上記の OTLP 対応バックエンドに送り先を差し替えられます。特定ツールへ深く依存しすぎないための保険になります。
Privacy & Data Protection
「全部ログに残す」が一番危ない
観測のために本文を丸ごと保存すると、プロンプトや出力に含まれる個人情報・機密が観測基盤側に漏れ出します。OpenTelemetry の GenAI 規約も、既定では本文（プロンプト内容・道具の引数）を記録せず、モデル名・トークン数・所要時間といったメタデータだけを残す設計です。本文の取得は明示的に有効化したときだけ。下図の関所で、残すものと落とすものを必ず分けます。
FIG.3 関所でマスキングし、メタデータだけを観測基盤へ。本文の保存は要件と規約に整合させてから
保存方針はプライバシー規約・社内規程に必ず整合させること。そして観測は守りの仕組みなので、観測を削る変更は本番リスクです。コスト削減やリファクタの際にログ・トレースを安易に減らさない（減らすなら影響と代替を明示してから）。
07よくあるつまずきと処方箋
- ログがバラバラで追えない：相関 ID 未付与 → 入口で1つ発行し全処理に伝播させる。
- 出力の不具合を再現できない：プロンプト版数・モデル・パラメータを残していない → 生成時の構成をスパン属性に記録する。
- コストの原因が分からない：トークンを総量でしか取っていない → 機能別・ユーザー別タグで按分集計する。
- 個人情報が観測基盤に流れていた：本文を素通しで保存 → 既定で本文を残さず、必要時だけマスキング越しに有効化。
- HTTP は成功なのに苦情が来る：中身（幻覚・根拠欠落）を観測していない → 出力の検証結果や根拠の有無も指標化する。
08まとめ：最初の本番化で必ず仕込む
観測は後付けが効きづらい配線です。リリースしてから「あのとき何が起きたか」を知りたくなっても、記録していなければ追えません。だからこそ最初の本番化の段階で、ログ・トレース・メトリクスの3点をまとめて埋め込みます。共通言語は OpenTelemetry、守るべきは個人情報、見る指標は金額・速度・品質。小さく始めても、相関 ID と再現情報と按分タグの3つさえ最初に入れておけば、改善の土台になります。
