TL;DR
- AI コーディング前提の Observability は、計測対象レイヤー（コード生成 / レビュー / マージ / 障害） と スタック（OTel / eBPF / LangSmith / 内製 KPI） の 2 軸で設計する（経験則）。
- 既存の SRE Observability は障害層に強いが、コード生成 / レビュー層 が空白。AI 時代はここを LangSmith や 内製 KPI で補完するのが現実解[公式値]。
- 本記事は 063 AI変更後のCFR再定義ガイド と 064 AIコーディング運用インシデントRunbookハブ を完結させる 計測層 ハブとして機能する。
はじめに
AI コーディング運用で「気付きが遅れた事象」を遡ると、ほとんどが 観測の隙間 に起因します（経験則）。コード生成時のプロンプト履歴、レビュー時のレビュアー判断、マージ後の挙動、障害時のスパン、これらを 1 ストリームに並べないと、AI の意思決定がブラックボックス化します。
本記事は、Tech Lead / Platform Lead / EM 向けに、4 つの計測対象レイヤー と 4 種類のスタック を組み合わせた可観測性設計を提示します。詳細な指標選定は DORAとSPACEの選び方、CFR 再定義は AI変更後のCFR再定義ガイド、Runbook 集約は AIコーディング運用インシデントRunbookハブ を併読してください。
1. なぜ「AI コーディング向け Observability」を別個に設計するのか
既存 SRE Observability の強みと弱み
OpenTelemetry / Prometheus / Datadog 等の既存 Observability は、production 障害層 の計測には十分です（OpenTelemetry 公式 [公式値]）。span / metrics / log の 3 シグナルで、サービス間レイテンシや error rate を追跡できます。
しかし、AI コーディング運用では以下の層が空白です（経験則）:
- コード生成層: プロンプト履歴、AI モデル呼び出し、トークン消費
- レビュー層: レビュー時間、AI vs human レビュー、手戻り率
- マージ層: AI-augmented vs human-only PR の品質差
この空白を埋めるのが LangSmith / 内製 KPI ダッシュボードです。
AI 時代に必要な追加シグナル
| シグナル | 目的 | 推奨スタック |
|---|---|---|
| Prompt history | AI 出力の再現性確保 | LangSmith / 内製ログ |
| Token consumption | コスト按分 / 利用統計 | LangSmith / OTel custom metrics |
| Review duration | レビューゲートの健全性 | GitHub Actions logs / 内製 KPI |
| AI-augmented label | CFR 連動 | PR label + commit metadata |
| Tool call traces | エージェント実行の追跡 | OTel + LangSmith |
2. 計測対象レイヤー（4 段階）
2.1 コード生成層
AI が呼び出されたタイミングで、プロンプト・モデル・トークン消費・出力サイズを記録します。LangSmith / Helicone / 内製ログのいずれかで実装が現実解（経験則）。
2.2 レビュー層
PR レビュー時間、レビュアー判定（approve / request changes）、AI 自動レビューの結果、人間レビューの結果を記録。GitHub Actions のログ + 内製 KPI ダッシュボードで実装可能。レビュー運用設計は AI時代のレビュー運用設計 を参照。
2.3 マージ層
PR ラベル（ai-augmented / human-only）+ commit metadata（Co-Authored-By:）を機械抽出し、CFR と接続します。詳細は AI変更後のCFR再定義ガイド。
2.4 障害層
production span + structured log + error taxonomy。既存 Observability スタックがそのまま使えます。詳細は AIエージェントの可観測性と障害解析 と LLM/AI開発の Observability を eBPF × OTel で最小実装する。
3. スタック比較表（2026-05 公式値）
| スタック | 主用途 | 公式値 |
|---|---|---|
| OpenTelemetry | span / metrics / log の業界標準 | OTel 公式 [公式値] |
| eBPF | カーネルレベルのインフラ観測（USE method） | eBPF 公式 [公式値] |
| LangSmith | LLM 呼び出しトレース / プロンプト管理 / 評価 | LangSmith 公式 [公式値] |
| 内製 KPI ダッシュボード | DORA / SPACE / DevEx の自社カスタマイズ | dora.dev 公式値ベース |
スタック選定の決定木
Q1: production 障害層を強化するか？
Yes → OpenTelemetry + eBPF（[ai-observability-ebpf](/articles/ai-observability-ebpf)）
No → Q2
Q2: LLM 呼び出しの再現性・評価が必要か？
Yes → LangSmith（プロンプト管理 + トレース）
No → Q3
Q3: DORA / SPACE / DevEx 指標を自社運用するか？
Yes → 内製 KPI ダッシュボード（[DORAとSPACEの選び方](/articles/dora-vs-space-metrics)）
No → 既存スタック維持
4. 064 Runbook hub・063 CFR と接続する KPI 設計
本記事の Observability スタックは、064 Runbook hub と 063 CFR と 3 層で接続します。
KPI の 3 層
- Leading Indicator（先行指標）: prompt token / review duration / AI-augmented label 比率
- CFR 系: ΔCFR_ai / Failed Deployment Recovery Time（063 で定義）
- Lagging Indicator（遅行指標）: 顧客クレーム数 / SLO 違反継続時間（064 Incident で扱う）
接続例
[コード生成層] prompt token 急増
→ [レビュー層] review duration 延伸
→ [マージ層] ΔCFR_ai 上昇（063）
→ [障害層] Incident 発生（064）
→ Runbook 起動・改善ループ（063 + 064）
このループを 観測 → 学習 → レビュー反映 で回すと、運用改善が定量化されます。
5. 導入ロードマップ（Phase 1: ログ → Phase 2: trace → Phase 3: agent telemetry）
Phase 1: 構造化ログ（Day 1-30）
- AI 呼び出しごとに
agent_id / model / token / outcomeを構造化ログで残す - 既存の application log infrastructure に乗せれば追加コストはほぼゼロ
Phase 2: 分散トレース（Day 31-60）
- OTel span を 3 階層（User Request → Agent Loop → Tool Call）で取る
- 既存 SRE スタックがあれば LangSmith / OTel SDK を追加するだけ
Phase 3: agent telemetry + KPI ダッシュボード（Day 61-90）
- LangSmith でプロンプト管理 + トレース可視化
- 内製 KPI ダッシュボード（DORA / SPACE / DevEx + ΔCFR_ai）を立ち上げ
- 064 Runbook hub と連動した起動条件（閾値）を設定
6. 実装の落とし穴（Pitfalls）
経験則ベースの落とし穴 5 点。
- PII / 認証情報がプロンプト履歴に混入: LangSmith / 内製ログで mask 必須
- トークン消費の按分が agent_id で取れない: 最初の設計で metadata 必須化
- eBPF の運用コストが高い: 本番 cluster で常時稼働は避け、必要時に有効化
- LangSmith は SaaS 依存: コンプライアンス要件が厳しい場合は 内製 LLM tracing で代替
- 既存 SRE スタックとのサイロ化: span / log の相関 ID を共通化（trace_id を一貫させる）
FAQ
Q1. OpenTelemetry と LangSmith は競合しますか？
競合しません（経験則）。OTel は 業界標準の span / metrics / log フレームワーク[公式値]、LangSmith は LLM 呼び出しに特化したトレース + プロンプト管理 + 評価[公式値] です。実運用では両方併用が現実解で、LangSmith の trace を OTel の trace_id でブリッジするパターンが多いです。
Q2. 内製 KPI ダッシュボードと SaaS（Datadog / Grafana Cloud 等）はどちらが良いですか？
組織規模と要件次第（経験則）。100 名未満 なら SaaS の方が初期コスト低、100-500 名 で内製の費用対効果が高くなり、500 名超 なら内製 + SaaS の hybrid が現実解。詳細な指標選定は DORAとSPACEの選び方。
Q3. eBPF はいつ導入すべきですか？
カーネルレベルの遅延・I/O ボトルネックを疑うときが検討タイミングです（経験則）。詳細は LLM/AI開発の Observability を eBPF × OTel で最小実装する。AI コーディング運用では agent loop が数秒-数分の単位で動くため、eBPF まで掘ることは初期は不要なケースが多いです。
Q4. 既存 Observability スタックを AI 用に拡張する手順は？
3 ステップで済みます（経験則）: (1) AI 呼び出しに agent_id / model / token / outcome を構造化ログで追加、(2) OTel span を 3 階層で取る、(3) LangSmith / 内製ダッシュボードを後段に接続。詳細は本記事「§5 導入ロードマップ」参照。
Q5. CFR / Runbook hub とこの Observability の関係は？
3 層で接続します。Observability = 計測、CFR = 評価指標、Runbook = 対応の役割分担で、Observability で異常検知 → CFR で集計 → Runbook で対応、というループを回します。詳細は AI変更後のCFR再定義ガイド と AIコーディング運用インシデントRunbookハブ を併読してください。
References
- OpenTelemetry 公式 — span / metrics / log の業界標準
- eBPF 公式 — カーネルレベル観測
- LangSmith 公式 docs — LLM トレース / プロンプト管理
- DORA Metrics 公式ガイド — 5 指標モデル
- Google SRE Workbook - Monitoring Distributed Systems — Observability の原典
- OpenAI Codex App Server 公式 — streamed agent events
