監視とオブザーバビリティ ― 三本柱+OpenTelemetry+SLOアラート ― 生成AI時代のアーキテクチャ超入門

本記事について

当サイトを閲覧いただきありがとうございます。 本記事はシリーズ『生成AI時代のアーキテクチャ超入門』の「開発運用アーキテクチャ」カテゴリ第9弾として、監視とオブザーバビリティについて解説する記事です。

「動いてる？」に答えるのが監視、「なぜ壊れた？」に答えるのがオブザーバビリティです。本記事では監視3本柱（Metrics／Logs／Traces）、4ゴールデンシグナル（Latency／Traffic/Errors／Saturation）、OpenTelemetry、AIOps、運用実装まで解説します（システムアーキテクチャ段階の監視要件は別記事「システムアーキテクチャ」へ）。

本記事のテーマについてさらに詳しく知りたい方は『AWSの基本・仕組み・重要用語が全部わかる教科書』も参考にしてみてください。

そもそも監視とオブザーバビリティとは何か

車の運転を想像してください。速度計・燃料計・エンジン警告灯──ダッシュボードの計器がなければ、スピードも残りガソリンもエンジンの異常もわかりません。「エンジンが焼き付いてから気づく」のでは手遅れです。

監視（Monitoring）はシステムのダッシュボードです。CPU使用率・エラー率・応答時間などの数値を常時計測し、異常があればアラートを鳴らす仕組みです。一方、オブザーバビリティ（Observability）はさらに一歩進んで、「なぜ壊れたのか」を事後に調査できる能力を指します。

もし監視がなければ、ユーザーからのクレームで初めて障害に気づくことになります。もしオブザーバビリティがなければ、障害に気づいても原因がわからず、復旧に何時間もかかります。

なぜ必要か

障害に気づかないと被害が拡大する

ユーザーからのクレームで初めて障害に気づく組織は未だに多いです。監視がないと気づいた時には大事故になります。

マイクロサービスでは原因追跡が困難

100個のサービスが連携するシステムで、どこが原因で遅いのかを特定するには、分散トレーシング等のオブザーバビリティ基盤が必須です。

SLO・SLAの数値化

「99.9%稼働」を約束するなら、実測値を計測する仕組みが必要です。測れないものは守れないのが原則です。

三本柱（Three Pillars）

オブザーバビリティの基本となる3つのデータ種別です。どれか1つでは不十分で、3つを組み合わせて初めて全体像が見えます。「3本柱」はもはや古典で、現代は Events・Profiles も加えた多角的アプローチが主流です。

メトリクスは「何が起きているか」、ログは「何が記録されたか」、トレースは「どう動いたか」を示します。

メトリクス

数値化した時系列データで、CPU 使用率・リクエスト数・エラー率・レイテンシなどを記録します。ストレージ効率が良く、集計・アラートに向くのが特徴で、監視の基本となるデータです。

USE／RED は有名なメトリクス設計フレームワークで、「何を測るか」の指針として使われます。

ログ

時刻付きのテキストイベントで、アプリが出力する詳細情報を記録します。構造化ログ（JSON形式）が現代の標準で、メトリクス・トレースと紐付けられます。ログについては次の記事で詳しく扱います。

ログは大量に発生するため保管コストが問題になりやすく、保持期間・圧縮・サンプリング戦略が運用論点です。

トレース

1つのリクエストが複数サービスを経由する過程を追跡するデータです。マイクロサービスでは「注文APIが在庫APIと決済APIを呼ぶ」といった連鎖があり、どこで遅いか・どこで失敗したかを視覚化できます。

トレースは Span（個々の処理）が Trace ID で繋がれ、全体の流れを DAGとして表現します。代表的な技術は OpenTelemetry（業界標準）で、Jaeger・Tempo・Datadog APM等に送信されます。

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の傘下で発展しており、将来性も高いです。

LGTMスタック（Loki・Grafana・Tempo・Mimir）として統合ブランディングされ、近年急速に普及しています。

主要ツール（SaaS）

自社で基盤を構築したくない場合、SaaS のオブザーバビリティを使うのが手早い選択です。料金は高いですが、運用負担ほぼゼロで高機能な監視基盤が手に入ります。

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 で通知する運用が標準です。

アラートは少なすぎると気づかない、多すぎると麻痺するという二律背反があり、重要度別のルーティング（警告は Slack、重大は PagerDuty）が重要です。

アラート設計

良いアラートの条件は、(1)必ず対応が必要、(2)対応可能、(3)すぐに動くべき、の3つを満たすことです。これを外したアラートはアラート疲れを生み、本当の重大事案を見逃す原因になります。

アラートは「症状」ではなくユーザー影響で発報すべきです。CPU 高騰自体はユーザーに影響しません。

「機械が苦しいか」と「人間が苦しんでいるか」は別物、というのは監視設計の定番の教訓です。CPU 使用率80%でアラートを仕込んで安心していた現場で、当日誰のダッシュボードも赤くなっていないのに Twitter では「ログインできない」の報告が流れていた、という事例はよく聞かれます。原因は DB 接続プールの枯渇で CPU はむしろ暇、アプリだけが全員待たされている状態、という典型パターンです。

SLOベースアラートの実装例

「SLO違反ベース」のアラートは、エラーバジェットの消費速度（burn rate）で発報するのが現代的です。単なる閾値超過ではなく「このペースだと予算を使い切る」を検知する仕組みで、Google SRE Workbook が標準として推奨しています。

# 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で発報するのが現代の標準です。

判断基準①：システム規模と複雑さ

オブザーバビリティの重装度はシステムの複雑度で決まります。モノリシックな単一サーバーなら軽量監視で十分、マイクロサービスならフルセットが必要です。

判断基準②：運用チームのスキル

OSS スタックは運用が重く、専門チームが必要です。SaaS なら運用負担は減りますが、コストがかさみます。

ケース別の選び方

個人開発・小規模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 が必要になります。

監視コスト・アラート運用の数値Gate

※ 2026年4月時点の業界相場値です。テクノロジー・人材市場の変化で陳腐化するため、定期的にアップデートが必要です。

監視は「入れれば安心」ではなく、費用とシグナル品質を数値で追うのが運用の肝です。

アラート発報10件超／週は「ノイズ化の兆候」Datadog月額30万円超はスタートアップでは過剰投資の目安。本番でDEBUGログを出し続けるとCloudWatch Logs月100万円超という事故が定番です。

監視コストはインフラ費の10%が上限。超えたらサンプリング・保持期間で削ります。

やってはいけないこと

監視で事故る典型パターン。どれも設定しただけで運用できていない構造を持ちます。

2021年10月の Facebook／Instagram 6時間障害（BGP 設定ミスで社外からサーバーが見えなくなり、社内の監視ツール・入退室システムまで同じネットワークに依存していたため復旧遅延、推定6,000万ドル超の損失）は、監視の監視がない構造的問題を示した事例です。

監視は「人間の痛み」で鳴らす。CPU 80% ではなく SLO 違反で発報します。

AI判断軸

1. OpenTelemetryで計測を統一 — ベンダー中立、将来のバックエンド切替に備える
2. SaaS vs OSSは運用体制で決める — SRE 専属なしは Datadog、数名なら Grafana Cloud、充実なら自社 LGTM
3. アラートはユーザー影響ベース — SLO 違反を発報、CPU 高騰単体は鳴らさない
4. AIが読める構造化データ — JSON／Traces／高カーディナリティ、AI 診断に備える

AIによる障害の根本原因分析（RCA）が現実的になった

Datadogの「Watchdog RCA」やNew Relicの「AI Insights」は、複数のシグナル（ログ・メトリクス・トレース）を横断的に解析し、障害の根本原因を推定する機能を提供しています。これが機能する前提条件は、3本柱（ログ・メトリクス・トレース）がtrace_idで相関付けされていることです。

OpenTelemetryで統一的に計装しておけば、ログ→トレース→メトリクスの相関がツール側で自動的に構築され、AIによるRCAの精度が最大化されます。

Observabilityバックエンドの選定とAI機能の差

2026年時点で、AI機能の成熟度はObservabilityツールによって差があります。Datadogは異常検知・RCA・ランブック推奨までAIでカバーし、HoneycombはBubbleUp（高カーディナリティ分析）でAIの介入余地を広げ、Grafana CloudはLLMベースのログクエリ生成を実装しています。ツール選定時に「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ベース・チャネル分け）
• ダッシュボード（サービスヘルス・ビジネス）

この記事に関連する記事

まとめ

本記事は監視とオブザーバビリティについて、三本柱・OpenTelemetry・主要ツール・SLOバーンレートアラート・AI診断に備える構造化データまで含めて解説しました。如何だったでしょうか。

OpenTelemetryで計測を統一し、運用体制でSaaS vs OSSを決め、アラートはユーザー影響ベースで、AIが読める構造化データを整える。これが2026年の監視とオブザーバビリティの現実解です。

次回はログ設計（構造化ログ・PII保護・保持期間）について解説します。

シリーズ目次に戻る → 『生成AI時代のアーキテクチャ超入門』の歩き方

本記事で扱った内容の詳細は OpenTelemetry も合わせて参考にしてください。

それでは次の記事も閲覧いただけると幸いです。