オブザーバビリティ

システムの内部状態を、外部からの観測（ログ・メトリクス・トレース）だけでどれだけ把握できるかを示す性質。 「未知の未知（Unknown Unknowns）」の障害まで追跡できる設計能力 で、AI 駆動開発で量産されるコードの本番運用を支える基盤。

O11y は observability の「o」と「y」の間に 11 文字あることに由来する省略表記。

概要

従来の モニタリング は「事前に決めた指標を監視」する受動的アプローチ。これに対しオブザーバビリティは、 「想定外の異常が起きたときに、ログ・メトリクス・トレースから原因を特定できる」 能動的アプローチです。

観点	モニタリング	オブザーバビリティ
対象	既知の障害パターン	未知の障害も含む
目的	「いつ壊れたか」を検出	「なぜ壊れたか」を解明
必要条件	事前にダッシュボード設計	データの粒度・関連性が確保されている
質問形式	「CPU 80% 超過？」（Yes/No）	「なぜ顧客 X の注文が遅延した？」（自由形式）

3 本柱（Three Pillars）

オブザーバビリティの古典的な構成要素。

柱	内容	代表ツール
Logs（ログ）	時系列のイベント記録。文脈情報を含む	Loki / Elasticsearch / Datadog Logs
Metrics（メトリクス）	集計された数値時系列（CPU・レイテンシ等）	Prometheus / Datadog Metrics
Traces（トレース）	リクエストがサービスを跨ぐ流れ	Jaeger / Tempo / Datadog APM

3 本柱の役割分担

What happened?  → Metrics    （何が起きたか — 集計）
When?           → Logs       （いつ起きたか — タイムスタンプ）
Where?          → Traces     （どこで起きたか — 経路）
Why?            → 全部組み合わせて分析

5 本柱への進化（2025 年）

近年は 3 本柱に加えて Profiling と Events を含む 5 本柱 が標準化されつつあります。

追加柱	内容	効用
Profiling（継続的プロファイリング）	CPU / メモリの使用箇所を時系列で記録	性能ボトルネックを本番から自動特定
Events（ビジネスイベント）	デプロイ・機能フラグ切替・キャンペーン開始など	「なぜこの瞬間から異常？」の原因絞り込み

イベントソーシングと組み合わせると、 ビジネスイベントとシステムイベントが統合された 強力な観測基盤になります。

OpenTelemetry — 業界標準

OpenTelemetry（OTel） は CNCF が標準化する、オブザーバビリティデータの仕様 + SDK + 収集エージェント。 2025 年現在のデファクトスタンダード 。

提供物	内容
仕様	OTLP（OpenTelemetry Protocol）でログ・メトリクス・トレースを統一表現
SDK	各言語（Go / Java / Python / Node.js / .NET 等）のライブラリ
Collector	データ収集・変換・転送のミドルウェア
ベンダー非依存	Datadog / New Relic / Grafana など主要バックエンドが対応

OTel を使えば 計装は 1 度、バックエンドは後から差し替え が可能。ベンダーロックイン回避の最強の手段。

代表的なツール構成

商用 SaaS

ツール	強み
Datadog	All-in-One、UI が秀逸、価格は高め
New Relic	APM の歴史、フリーミアムあり
Honeycomb	ハイカーディナリティ（高次元データ）に強い
Sentry	エラー追跡が中心、開発者体験◎
Axiom	ログ・イベント中心、コスト効率良い

OSS スタック（Grafana Stack）

Loki        ← ログ
Prometheus  ← メトリクス
Tempo       ← トレース
Pyroscope   ← プロファイル
        ↓
    Grafana （統合 UI）

セルフホスト可能で、 コスト管理しやすい 構成。一人 SaaS でも採用しやすい。

AI 駆動開発との関係

AI が生成するコードの本番運用には、 オブザーバビリティが不可欠 。理由は 3 つ。

1. AI 生成コードの「想定外」を検知

AI は「動くコード」を出すが、 本番特有の負荷・データ偏り・並行性 を完璧には予測できません。オブザーバビリティがあれば、想定外の挙動を 本番投入後に発見・修正 できます。

2. AI に異常分析を任せる素材になる

素材	AI に任せられる作業
ログ	「このエラーログから根本原因を特定」
トレース	「遅延が発生したスパンを特定」
メトリクス異常	「異常時刻に何が変わったかを Events と突合」
プロファイル	「CPU を食っている関数を特定し、最適化提案」

ログが構造化されていれば（JSON など）、 AI が即座に分析できる素材 になります。

3. 自動復旧（Self-Healing）の判定材料

AI 駆動開発の発展形として、 異常検知 → AI が原因仮説を立てる → 自動修正 PR を作成 という自動復旧パイプラインが現実化しています。これにはオブザーバビリティの 3 本柱が前提。

CLAUDE.md に書いておくべきこと

## オブザーバビリティ要件

- ログは構造化（JSON）で出力すること
- 全リクエストに traceId / requestId を付与
- 重要な業務イベント（注文確定・決済・キャンセル）は必ずログに記録
- 例外発生時は Sentry に送信
- メトリクスは Prometheus 形式で公開
- 個人情報・パスワード・カード番号はログに出さない

これを明示すると、AI が生成するコードに 最初からオブザーバビリティが組み込まれます 。後付けより圧倒的に安い。

アンチパターン

失敗	是正
構造化されていない `console.log` の羅列	必ず JSON ログ + 構造化フィールド（user_id, trace_id 等）
traceId が伝播していない	OpenTelemetry SDK で自動伝播、手動でも propagation を必須化
ログに個人情報が混入	redaction（マスキング）を共通ミドルウェアで強制
ログ・メトリクス・トレースがバラバラのツール	OpenTelemetry で統合、または Grafana Stack で一元化
アラートが鳴りすぎてオオカミ少年化	SLO ベースのアラート設計、alert fatigue を避ける
高カーディナリティをそのまま捨てる	Honeycomb / Axiom など対応バックエンドを採用

開発手法ガイド：モノレポ編 — 一人 SaaS スタックでの監視ツール選定
開発手法ガイド：イベントソーシング編 — Events 柱との統合
開発手法ガイド：CES アプローチ編 — Saga ゾンビ検知の運用基盤

概要