本記事について
当サイトを閲覧いただきありがとうございます。 本記事はシリーズ『生成AI時代のアーキテクチャ超入門』の「開発運用アーキテクチャ」カテゴリ第9弾として、監視とオブザーバビリティについて解説する記事です。
「動いてる？」に答えるのが監視、「なぜ壊れた？」に答えるのがオブザーバビリティです。本記事では監視3本柱（Metrics／Logs／Traces）、4ゴールデンシグナル（Latency／Traffic/Errors／Saturation）、OpenTelemetry、AIOps、運用実装まで解説します（システムアーキテクチャ段階の監視要件は別記事「システムアーキテクチャ」へ）。
このカテゴリの他の記事
なぜ必要か
障害に気づかないと被害が拡大する
ユーザーからのクレームで初めて障害に気づく組織は未だに多いです。監視がないと気づいた時には大事故になります。
マイクロサービスでは原因追跡が困難
100個のサービスが連携するシステムで、どこが原因で遅いのかを特定するには、分散トレーシング等のオブザーバビリティ基盤が必須です。
SLO・SLAの数値化
「99.9%稼働」を約束するなら、実測値を計測する仕組みが必要です。測れないものは守れないのが原則です。
三本柱（Three Pillars）
オブザーバビリティの基本となる3つのデータ種別です。どれか1つでは不十分で、3つを組み合わせて初めて全体像が見えます。「3本柱」はもはや古典で、現代は Events・Profiles も加えた多角的アプローチが主流です。
flowchart TB
APP([アプリ実行])
APP --> METRIC[Metrics<br/>数値時系列<br/>CPU/エラー率/レイテンシ]
APP --> LOG[Logs<br/>イベント記録<br/>アクセス/エラー詳細]
APP --> TRACE[Traces<br/>リクエスト経路<br/>分散追跡]
METRIC --> Q1[何が起きてるか?]
LOG --> Q2[何が記録されたか?]
TRACE --> Q3[どう動いたか?]
Q1 --> ANSWER([全体像<br/>= Observability])
Q2 --> ANSWER
Q3 --> ANSWER
classDef app fill:#fef3c7,stroke:#d97706;
classDef m fill:#dbeafe,stroke:#2563eb;
classDef l fill:#fae8ff,stroke:#a21caf;
classDef t fill:#dcfce7,stroke:#16a34a;
classDef goal fill:#fef3c7,stroke:#d97706,stroke-width:2px;
class APP app;
class METRIC,Q1 m;
class LOG,Q2 l;
class TRACE,Q3 t;
class ANSWER goal;| 種別 | 内容 | 代表 |
|---|---|---|
| Metrics（メトリクス） | 数値の時系列データ | Prometheus・Datadog |
| Logs（ログ） | 文字列のイベント記録 | Loki・Elasticsearch |
| Traces（トレース） | リクエストの経路 | Jaeger・Tempo |
メトリクスは「何が起きているか」、ログは「何が記録されたか」、トレースは「どう動いたか」を示します。
メトリクス
数値化した時系列データで、CPU 使用率・リクエスト数・エラー率・レイテンシなどを記録します。ストレージ効率が良く、集計・アラートに向くのが特徴で、監視の基本となるデータです。
| 典型メトリクス | 内容 |
|---|---|
| システム系 | CPU・メモリ・ディスクI/O・ネットワーク |
| アプリ系 | リクエスト数・エラー率・レイテンシ |
| ビジネス系 | 注文数・登録数・売上 |
| USE | Utilization・Saturation・Errors |
| RED | Rate・Errors・Duration |
USE／RED は有名なメトリクス設計フレームワークで、「何を測るか」の指針として使われます。
ログ
時刻付きのテキストイベントで、アプリが出力する詳細情報を記録します。構造化ログ（JSON形式）が現代の標準で、メトリクス・トレースと紐付けられます。ログについては次の記事で詳しく扱います。
| ログの種類 | 用途 |
|---|---|
| アプリログ | 業務処理の記録 |
| アクセスログ | HTTP リクエスト |
| 監査ログ | 権限操作・重要変更 |
| システムログ | OS・ミドルウェアのイベント |
ログは大量に発生するため保管コストが問題になりやすく、保持期間・圧縮・サンプリング戦略が運用論点です。
トレース
1つのリクエストが複数サービスを経由する過程を追跡するデータです。マイクロサービスでは「注文APIが在庫APIと決済APIを呼ぶ」といった連鎖があり、どこで遅いか・どこで失敗したかを視覚化できます。
トレースは Span（個々の処理）が Trace ID で繋がれ、全体の流れを DAG（Directed Acyclic Graph＝有向非巡回グラフ）として表現します。代表的な技術は OpenTelemetry（業界標準）で、Jaeger・Tempo・Datadog APM（Application Performance Monitoring＝アプリ性能監視）等に送信されます。
Trace: order-abc123
├─ Span: POST /order (100ms)
│ ├─ Span: check stock (30ms)
│ └─ Span: charge card (50ms)
│ └─ Span: Stripe API (45ms)主要ツール（クラウドネイティブOSS）
OSS ベースのオブザーバビリティは、Prometheus・Grafana・Loki・Tempo・OpenTelemetry の組み合わせが事実上の標準です。CNCF（Cloud Native Computing Foundation）の傘下で発展しており、将来性も高いです。
| ツール | 役割 |
|---|---|
| Prometheus | メトリクス収集・保管・アラート |
| Grafana | 可視化ダッシュボード |
| Loki | ログ集約（Grafana Labs 製） |
| Tempo | 分散トレース（Grafana Labs 製） |
| OpenTelemetry | 計測データ収集の標準 |
| Alertmanager | アラート通知 |
LGTMスタック（Loki・Grafana・Tempo・Mimir）として統合ブランディングされ、近年急速に普及しています。
主要ツール（SaaS）
自社で基盤を構築したくない場合、SaaS のオブザーバビリティを使うのが手早い選択です。料金は高いですが、運用負担ほぼゼロで高機能な監視基盤が手に入ります。
| サービス | 特徴 |
|---|---|
| Datadog | 機能最強・料金高い |
| New Relic | 老舗・全機能統合 |
| Splunk | ログ分析の王様 |
| Dynatrace | AI 駆動の自動解析 |
| Honeycomb | 高カーディナリティに強い |
| Grafana Cloud | LGTM スタックのマネージド |
Datadog が機能最強ですが、月額数十万〜数百万円になることも多く、小規模は Grafana Cloud・New Relic 無料枠の方が現実的です。
OpenTelemetry（計測の標準）
メトリクス・ログ・トレースを統一的に収集する業界標準です。2019年に OpenTracing と OpenCensus が合流して誕生し、CNCF Incubating から Graduated へと進んだ現代の共通規格です。
OpenTelemetry を使えば、計測コードはベンダーニュートラルで書けます。Datadog から Grafana に乗り換える時も、アプリ側のコードを書き換える必要がありません。送信先の設定を Collector 側で差し替えるだけで済むため、ベンダーロックイン回避が机上の議論ではなく実装レベルで効いてきます。
さらに、計装 API が統一されることで複数ツールの併用が容易になります。例えば本番メトリクスは Datadog、長期ログアーカイブは S3 + Loki、開発環境トレースは Jaeger のように、同じ計測コードから用途別に振り分けられます。独自 SDK を使うと各ツールごとに計装をやり直すコストが発生するため、規模が大きくなるほどこの差は無視できません。
| 特徴 | 内容 |
|---|---|
| ベンダー中立 | どのバックエンドにも送信可能 |
| 言語サポート | 主要言語ほぼ全て |
| 自動計測 | 主要フレームワーク対応 |
| 計測の統一 | メトリクス・ログ・トレース統合 |
新規構築するなら OpenTelemetry が第一候補です。ベンダーロックインを避けられます。
ダッシュボードとアラート
監視データを集めるだけでは意味がなく、可視化とアラートで初めて運用に活かせます。Grafana や各 SaaS のダッシュボードで状態を俯瞰し、閾値を超えたら Slack や PagerDuty で通知する運用が標準です。
| ダッシュボード種別 | 内容 |
|---|---|
| サービスヘルス | API 別の状態・エラー率 |
| インフラ | CPU・メモリ・ネットワーク |
| ビジネス | 売上・ユーザー数・コンバージョン |
| SLO | SLI 実測 vs 目標 |
アラートは少なすぎると気づかない、多すぎると麻痺するという二律背反があり、重要度別のルーティング（警告は Slack、重大は PagerDuty）が重要です。
アラート設計
良いアラートの条件は、(1)必ず対応が必要、(2)対応可能、(3)すぐに動くべき、の3つを満たすことです。これを外したアラートはアラート疲れを生み、本当の重大事案を見逃す原因になります。
| 良いアラート | 悪いアラート |
|---|---|
| SLO 違反 | CPU 80% 超過（自動回復する） |
| エラー率急上昇 | 1回だけのエラー |
| ユーザー影響明確 | 「なんか遅い」 |
| 対応手順あり | 誰が何すれば良いか不明 |
アラートは「症状」ではなくユーザー影響で発報すべきです。CPU 高騰自体はユーザーに影響しません。
「機械が苦しいか」と「人間が苦しんでいるか」は別物、というのは監視設計の定番の教訓です。CPU 使用率80%でアラートを仕込んで安心していた現場で、当日誰のダッシュボードも赤くなっていないのに Twitter では「ログインできない」の報告が流れていた、という事例はよく聞かれます。原因は DB 接続プールの枯渇で CPU はむしろ暇、アプリだけが全員待たされている状態、という典型パターンです。
SLOベースアラートの実装例
「SLO違反ベース」のアラートは、エラーバジェットの消費速度（burn rate）で発報するのが現代的です。単なる閾値超過ではなく「このペースだと予算を使い切る」を検知する仕組みで、Google SRE Workbook が標準として推奨しています。
| 重大度 | 条件 | 発報先 |
|---|---|---|
| Critical（即対応） | 1時間で予算の2%消費（burn rate > 14.4×） | PagerDuty |
| High（数時間以内） | 6時間で予算の5%消費（burn rate > 6×） | PagerDuty |
| Warning（営業時間内） | 3日で予算の10%消費（burn rate > 1×） | Slack |
# Prometheus の例（可用性SLO 99.9%, 月間予算 43.2分）
alert: ErrorBudgetBurnRateCritical
expr: (1 - availability_slo:ratio_rate5m) > (14.4 * 0.001)
and (1 - availability_slo:ratio_rate1h) > (14.4 * 0.001)
for: 2m「CPU 80%超えたら発報」は時代遅れ。burn rateで発報するのが現代の標準です。
判断基準①：システム規模と複雑さ
オブザーバビリティの重装度はシステムの複雑度で決まります。モノリシックな単一サーバーなら軽量監視で十分、マイクロサービスならフルセットが必要です。
| システム規模 | 推奨 |
|---|---|
| 単一サーバー・モノリス | CloudWatch／Datadog 軽量プラン |
| 数サービス | Prometheus + Grafana |
| マイクロサービス（10〜50） | LGTM + OpenTelemetry |
| 大規模(100+) | Datadog／Dynatrace エンタープライズ |
判断基準②：運用チームのスキル
OSS スタックは運用が重く、専門チームが必要です。SaaS なら運用負担は減りますが、コストが跳ね上がります。
| チーム体制 | 推奨 |
|---|---|
| SRE 専属なし | SaaS（Datadog／New Relic） |
| SRE 数名 | Grafana Cloud |
| SRE 充実・コスト削減志向 | 自社 LGTM + OpenTelemetry |
ケース別の選び方
個人開発・小規模SaaS
クラウド標準（CloudWatch／Cloud Monitoring）+ UptimeRobot。月数千円から回せます。独自ダッシュボードが欲しくなったら Grafana Cloud 無料枠を追加します。
スタートアップ・SRE 0〜1名
Datadog or New Relic の無料枠 + OpenTelemetry SDK。運用負荷を最小化したいなら SaaS 一択です。OTel で計測すれば、将来バックエンド切替も可能です。規模が大きくなると課金が跳ねるため、100ホスト超で見直します。
中堅SaaS・マイクロサービス化
Grafana Cloud（LGTM）+ OpenTelemetry。LGTM スタックの学習コストはありますが、Datadog より大幅に安く済みます。SRE 2〜3名で運用可能です。
大企業・独自運用できるチーム
自社 Prometheus + Grafana + Loki + Tempo + OpenTelemetry。ベンダーロックインを避け、機密データを外に出さない構成です。運用には5名以上の専任 SRE が必要になります。
よくある勘違い
ログを全部取れば大丈夫
ログ地獄になります。サンプリング・構造化・重要度別の設計が必要で、ログ量は金になります。
CPU高騰を監視すれば十分
CPU 高騰はユーザーに影響しないこともあります。ユーザー影響ベース（SLO）が正しいアプローチです。
アラートは全員にメールで送る
誰も見なくなります。対応者に適切なチャネルで届けるべきで、オンコール設計が重要です。
OpenTelemetryは新しいから様子見
既に業界標準です。今から入れるなら OTel 一択で、ベンダー独自 SDK は陳腐化しつつあります。
監視コスト・アラート運用の数値Gate
※ 2026年4月時点の業界相場値です。テクノロジー・人材市場の変化で陳腐化するため、定期的にアップデートが必要です。
監視は「入れれば安心」ではなく、費用とシグナル品質を数値で追うのが運用の肝です。
| 指標 | 推奨値 | 超えたらどうするか |
|---|---|---|
| 監視基盤の月額コスト | インフラ費の5〜10% | サンプリング・保持期間短縮 |
| 本番DEBUGログ出力 | 禁止 | INFO 以上に絞る |
| アラート発報数／週 | 10件以下 | ノイズ削減・SLO ベースへ |
| アラート対応率 | 90%以上 | 鳴っても誰も見ないなら削除 |
| MTTA（Mean Time To Acknowledge） | 5分以内 | オンコール体制の見直し |
| MTTR（Mean Time To Resolve） | 30分以内 | Runbook 整備 |
| Lighthouse Observability スコア | 90点以上 | メトリクス設計を見直す |
| 構造化ログ率 | 100% | JSON 以外は受け付けない |
| OpenTelemetry 採用率 | 新規は100% | ベンダー独自 SDK を避ける |
アラート発報10件超／週は「ノイズ化の兆候」Datadog月額30万円超はスタートアップでは過剰投資の目安。本番でDEBUGログを出し続けるとCloudWatch Logs月100万円超という事故が定番です。
監視コストはインフラ費の10%が上限。超えたらサンプリング・保持期間で削ります。
監視設計の鬼門・禁じ手
監視で事故る典型パターン。どれも設定しただけで運用できていない構造を持ちます。
| 禁じ手 | なぜダメか |
|---|---|
| CPU／メモリの静的閾値（80%超過等）でアラート | 負荷変動で誤検知が積み重なり、鳴っても誰も見ない状態に |
| 本番でDEBUGレベルログを出し続ける | CloudWatch Logs／Datadog 請求が月100万円超 |
| アラートを1つのSlackチャンネルに全部流す | 本物の障害通知が日常ノイズに埋もれる |
| 平均値（Average）だけで性能を追う | 1%の遅いユーザーが見えない。P95／P99で追う |
| RunbookをWord／PDF／口頭で管理 | 属人化・再現不能、AI に実行させられない |
| ポストモーテムで犯人探し | 情報隠蔽の温床。Blamelessが鉄則 |
| 監視基盤のコストを監視しない | Datadog 請求5倍事故が頻発、監視の監視が必要 |
| トレースなしでマイクロサービス運用 | どのサービスが遅いか特定不能、MTTR が数時間に |
| 独自SDKで計装 | ベンダーロックイン、将来の乗り換えで全書き換え |
| アラート棚卸しを実施しない | 月1回の棚卸しで形骸化アラートを削除 |
| 監視系と本番を同じネットワークで運用 | 2021年10月の Facebook 6時間障害と同じ構造（BGP設定ミスで監視ツールまで見えず） |
2021年10月の Facebook／Instagram 6時間障害（BGP 設定ミスで社外からサーバーが見えなくなり、社内の監視ツール・入退室システムまで同じネットワークに依存していたため復旧遅延、推定6,000万ドル超の損失）は、監視の監視がない構造的問題を示した事例です。
監視は「人間の痛み」で鳴らす。CPU 80% ではなく SLO 違反で発報します。
AI時代の視点
AI 駆動開発（バイブコーディング）と AI 活用が前提になると、オブザーバビリティはAIが異常を自動検知・診断する領域に進化しています。Datadog Watchdog・Dynatrace Davis 等の AI 駆動監視は、従来の閾値ベースを超えて異常を自動発見します。
| AI時代に有利 | AI時代に不利 |
|---|---|
| 高カーディナリティ対応(Honeycomb) | 固定メトリクスだけ |
| OpenTelemetry 標準 | 独自SDK |
| AIが読める構造化ログ | 非構造の文字列ログ |
| SRE Agent・LLM(Large Language Model＝大規模言語モデル)連携 | 手動での原因追跡 |
AI に障害を調査させるためには、トレース・構造化ログが必須です。生の文字列ログだけでは AI も解析できません。「AIが読める形で計測データを出す」のが新しい基準です。
オブザーバビリティの将来はAIエージェントが運用する。データ構造が命です。
筆者メモ — 「ダッシュボード全面緑」の裏で燃えていた事例
監視していたはずなのに気づけなかった、という事例が運用現場の定番の語り草になっています。
ある SaaS で、CPU・メモリ・ネットワークのダッシュボードは全て緑のまま、Twitterには「ログインできない」の報告が数百件流れていた、というヒヤリハットがあります。原因は DB 接続プール枯渇で、CPU はむしろ暇、アプリだけが全員待たされている状態でした。「インフラメトリクスを見て安心していた」のが罠で、SLO（ユーザー影響）を測っていなかったのが根本原因です。
もう一つ、2021年10月の Facebook／Instagram 6時間障害は、BGP設定ミスで社外からサーバーが見えなくなっただけでなく、社内の監視ツールや入退室システムまで同じネットワークに依存していたため、エンジニアがデータセンターに入れず復旧が遅延した、という「監視の監視がない」事例として語り草になっています。広告収入の損失だけで推定6,000万ドル超でした。
どちらも「何を測るか」と「監視系の独立性」の設計漏れが致命傷で、ユーザー影響で鳴らす・監視は対象と切り離すの両方が必須であることを突きつけます。
決めるべきこと — あなたのプロジェクトでの答えは？
以下の項目について、あなたのプロジェクトの答えを1〜2文で言語化してみてください。曖昧なまま着手すると、必ず後から「なぜそう決めたんだっけ」が問われます。
- 計測SDK（OpenTelemetry推奨／ベンダー独自）
- バックエンド（OSS LGTM／Datadog／New Relic）
- メトリクス設計（USE・RED・SLI）
- ログ戦略（収集範囲・保持期間）
- 分散トレース（全リクエスト／サンプリング）
- アラート設計（SLOベース・チャネル分け）
- ダッシュボード（サービスヘルス・ビジネス）
最終的な判断の仕方
監視とオブザーバビリティの核心は動いてる？に答えるのが監視、なぜ壊れた？に答えるのがオブザーバビリティという役割の違いを理解することです。モノリシックなら従来の監視で足りますが、マイクロサービス化が進んだ瞬間、Metrics／Logs／Traces の三本柱と OpenTelemetry による統一計測が必須になります。アラート設計は CPU 高騰のような「症状」ではなく SLO 違反のような「ユーザー影響」ベースに寄せ、アラート疲れを防ぐのが運用持続性の鍵になります。
もう一つの決定的な軸はAIエージェントが運用するためのデータ構造です。OpenTelemetry・構造化ログ・高カーディナリティ対応が揃った基盤は AI が障害を自動診断でき、Datadog Watchdog や SRE Agent といった新しい運用モデルに乗れます。独自 SDK・非構造文字列ログ・固定メトリクスのみは AI 時代に陳腐化します。
選定の優先順位
- OpenTelemetryで計測を統一 — ベンダー中立、将来のバックエンド切替に備える
- SaaS vs OSSは運用体制で決める — SRE 専属なしは Datadog、数名なら Grafana Cloud、充実なら自社 LGTM
- アラートはユーザー影響ベース — SLO 違反を発報、CPU 高騰単体は鳴らさない
- AIが読める構造化データ — JSON／Traces／高カーディナリティ、AI 診断に備える
「三本柱をOpenTelemetryで統一」AI が読める形で計測を揃え、ユーザー影響で鳴らします。
まとめ
本記事は監視とオブザーバビリティについて、三本柱・OpenTelemetry・主要ツール・SLOバーンレートアラート・AI診断に備える構造化データまで含めて解説しました。如何だったでしょうか。
OpenTelemetryで計測を統一し、運用体制でSaaS vs OSSを決め、アラートはユーザー影響ベースで、AIが読める構造化データを整える。これが2026年の監視とオブザーバビリティの現実解です。
次回はログ設計（構造化ログ・PII保護・保持期間）について解説します。
シリーズ目次に戻る → 『生成AI時代のアーキテクチャ超入門』の歩き方
それでは次の記事も閲覧いただけると幸いです。
📚 シリーズ：生成AI時代のアーキテクチャ超入門（62/89）