オブザーバビリティ入門 — ログ・メトリクス・トレースをどう組み合わせるか

「CPU使用率のグラフはある。エラー率のアラートも飛ぶ。それでも、障害のたびに原因究明で3時間溶ける」——多くのチームの監視は、この状態にあります。

監視(Monitoring)が「既知の異常を検知する」活動だとすれば、オブザーバビリティ(可観測性)は「未知の質問に答えられる」性質です。障害は毎回違う顔で来ます。「このユーザーのこのリクエストは、どこで、なぜ遅かったのか?」——事前に予想していなかった質問に、システムが出力するデータだけで答えられるか。この記事では、その土台になる3本柱の役割分担と、明日から始められる実装順序を整理します。

3本柱の役割分担 — どれも「万能」ではない

ログ・メトリクス・トレースは、それぞれ得意分野もコスト構造も違います。

柱	何を記録するか	得意なこと	弱点
メトリクス	数値の集約(件数・割合・分位点)	傾向の把握、アラート、ダッシュボード。安くて速い	「どのリクエストが」は分からない
ログ	個々のイベントの詳細	原因究明の最終証拠。何でも書ける	量が多く高コスト、集約に向かない
トレース	1リクエストの部品間の流れと所要時間	「どこで遅いか」の特定、依存関係の可視化	計装の手間、通常はサンプリングが前提

実務の調査は「メトリクスで異常に気づく → トレースで場所を絞る → ログで原因を特定する」という流れになります。3本柱は選ぶものではなく、この動線のためにつなぐものです。

何から測るか — ゴールデンシグナルとSLO

「何でも測る」は失敗します。出発点はGoogleのSRE本が示した4つのゴールデンシグナルです[1]。

1. レイテンシ — 応答にかかる時間(成功と失敗を分けて。平均ではなくp50/p95/p99の分位点で)
2. トラフィック — 需要の量(リクエスト/秒)
3. エラー — 失敗の率
4. 飽和 — リソースの逼迫度(どれだけ限界に近いか)

そのうえで、ユーザー体験に直結する指標をSLI(サービスレベル指標)として選び、目標値(SLO)を決めます。アラートとダッシュボードはSLOから逆算して作る——これが「グラフは山ほどあるのに、見るべきものがない」を防ぐ唯一の方法です。

実装の順序 — 構造化ログとtrace_idから始める

理想像から入ると挫折します。費用対効果の高い順に並べます。

ステップ1: ログを構造化する

printfの自由文ログをJSONに変えるだけで、ログは「読むもの」から「クエリするもの」に変わります。

{
  "ts": "2026-07-18T10:23:45+09:00",
  "level": "error",
  "msg": "payment failed",
  "trace_id": "a1b2c3d4",
  "user_id": "u_1029",
  "order_id": "o_5511",
  "duration_ms": 1840,
  "error_code": "GATEWAY_TIMEOUT"
}

ポイントは2つ。1リクエストの文脈(trace_id・主要なID)を全ログに入れること、そしてキー名をサービス間で揃えることです。この規約だけで「あの注文で何が起きたか」が1クエリになります。

ステップ2: trace_idで相関させる

分散トレーシング基盤の導入前でも、リクエストの入口でIDを発行し、内部の呼び出し先へ伝播させ、全ログに刻む——これだけで3本柱の連結の8割が手に入ります。モジュラモノリスで書いたとおり、マイクロサービス分割は観測コストを跳ね上げます。分割を検討する前に、この相関の仕組みを持っているかを自問してください。

ステップ3: OpenTelemetryで計装を標準化する

計装(コードに計測を仕込むこと)をベンダー固有のSDKで行うと、監視ツールの乗り換えが事実上不可能になります。現在の標準はOpenTelemetryです[2]。トレース・メトリクス・ログを共通のAPIで計装し、どのバックエンドにも送れる——CNCF配下でベンダー中立に開発されており、主要な監視サービスがこぞって対応しています。新規プロジェクトで独自計装を書く理由は、もうほとんどありません。

主要なWebフレームワーク・HTTPクライアント・DBドライバには自動計装が用意されているので、手始めは自動計装+手動スパンを重要処理にだけ追加が現実的です。

アラート設計 — 「疲れさせたら負け」

オブザーバビリティ最大の失敗は、技術ではなく運用に現れます。アラート疲れです。鳴りすぎるアラートは無視され、無視されたアラートは存在しないのと同じです。

• 症状ベースでアラートする[1]。「CPUが80%」(原因)ではなく「エラー率がSLOを脅かしている」(症状)で鳴らす。ユーザーが困っていないなら、夜中に人を起こさない
• すべてのアラートは行動可能に。受け取った人が何をすべきか不明なアラートは、通知ではなくノイズ
• 定期的に棚卸しする。1ヶ月間一度も行動につながらなかったアラートは、閾値を見直すか消す

LLM時代の補足 — AIシステムにも同じ規律を

LLMアプリやエージェントの運用でも、この規律はそのまま必要です。プロンプトのバージョン・トークン消費・ツール呼び出しの成否をトレースに載せる、生成の失敗を構造化ログで残す——ループエンジニアリングで「記録(Record)」がループの構成要素だと書きましたが、その実体はまさにオブザーバビリティです。非決定的なコンポーネントが増えるほど、観測の価値は上がります。

まとめ

• 監視は「既知の異常の検知」、オブザーバビリティは「未知の質問に答えられる性質」
• 3本柱は選択肢ではなく動線: メトリクスで気づき、トレースで絞り、ログで特定する
• 測る対象はゴールデンシグナルとSLOから逆算する。「何でも測る」は何も見ないのと同じ
• 実装は「構造化ログ → trace_id伝播 → OpenTelemetry」の順。この順なら明日から始められる
• アラートは症状ベース・行動可能・定期棚卸し。疲れさせたら監視は死ぬ

オブザーバビリティは監視ツールの購入では手に入りません。「未来の自分が障害調査で何を知りたいか」を想像してデータを設計する、地味な習慣の積み重ねです。その習慣は、システムが複雑になるほど——そしてAIのような非決定的な部品が増えるほど——効いてきます。