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

本記事について

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

「動いてる？」に答えるのが監視、「なぜ壊れた？」に答えるのがオブザーバビリティです。本記事では監視3本柱（Metrics／Logs／Traces）、OpenTelemetry、ツール選定、SLOバーンレートアラート、AIOpsまで解説します。

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

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

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

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

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

なぜ必要か

第一に、障害に気づかないと被害が拡大するからです。ユーザーからのクレームで初めて障害に気づく組織は未だに多く、監視がないと気づいた時には大事故になります。第二に、マイクロサービスでは原因追跡が困難だからです。100個のサービスが連携するシステムでどこが遅いのかを特定するには、分散トレーシング等の基盤が必須です。第三に、SLO・SLAの数値化のためです。「99.9%稼働」を約束するなら実測値を計測する仕組みが必要で、測れないものは守れないのが原則です。

三本柱（Metrics・Logs・Traces）

オブザーバビリティの基本となる3つのデータ種別です。どれか1つでは不十分で、3つを組み合わせて初めて全体像が見えます。

メトリクスは数値化した時系列データで、システム系（CPU・メモリ）・アプリ系（リクエスト数・エラー率・レイテンシ）・ビジネス系（注文数・売上）を記録します。ストレージ効率が良く集計・アラートに向き、「何を測るか」の指針としてUSE（Utilization・Saturation・Errors）とRED（Rate・Errors・Duration）という設計フレームワークが定番です。

ログは時刻付きのテキストイベントで、構造化ログ（JSON形式）が現代の標準です。大量に発生するため保持期間・サンプリングが運用論点になります（詳細は次回のログ設計）。

トレースは1つのリクエストが複数サービスを経由する過程を追跡するデータです。どこで遅いか・どこで失敗したかを視覚化でき、マイクロサービスでは必須です。

Trace: order-abc123
 ├─ Span: POST /order (100ms)
 │   ├─ Span: check stock (30ms)
 │   └─ Span: charge card (50ms)
 │       └─ Span: Stripe API (45ms)

主要ツール — OSSとSaaS

OSSベースでは、Prometheus（メトリクス収集・アラート）+ Grafana（可視化）+ Loki（ログ）+ Tempo（トレース）の組み合わせが事実上の標準です。LGTMスタック（Loki・Grafana・Tempo・Mimir）として統合ブランディングされ、近年急速に普及しています。

SaaSではDatadogが機能最強ですが、月額数十万〜数百万円になることも多く、小規模にはGrafana Cloud（LGTMのマネージド）やNew Relic無料枠の方が現実的です。その他、ログ分析の王様Splunk、AI駆動解析のDynatrace、高カーディナリティに強いHoneycombがあります。SaaSは料金が高い代わりに運用負担ほぼゼロで高機能な基盤が手に入ります。

OpenTelemetry（計測の標準）

メトリクス・ログ・トレースを統一的に収集する業界標準です。2019年にOpenTracingとOpenCensusが合流して誕生し、CNCF Graduatedまで進んだ現代の共通規格です。

OpenTelemetryを使えば計測コードはベンダーニュートラルで書けます。DatadogからGrafanaに乗り換える時も、アプリ側のコードを書き換える必要がなく、送信先の設定をCollector側で差し替えるだけ。ベンダーロックイン回避が机上の議論ではなく実装レベルで効いてきます。さらに、本番メトリクスはDatadog、長期ログアーカイブはS3 + Loki、開発環境トレースはJaegerのように、同じ計測コードから用途別に振り分けることもできます。新規構築なら第一候補です。

アラート設計 — ユーザー影響で鳴らす

監視データを集めるだけでは意味がなく、ダッシュボード（サービスヘルス・インフラ・ビジネス・SLO）とアラートで初めて運用に活かせます。アラートは少なすぎると気づかない、多すぎると麻痺するという二律背反があり、重要度別のルーティング（警告はSlack、重大はPagerDuty）が重要です。

良いアラートの条件は、(1)必ず対応が必要、(2)対応可能、(3)すぐに動くべき、の3つを満たすことです。アラートは「症状」ではなくユーザー影響で発報すべきで、CPU高騰自体はユーザーに影響しません。「機械が苦しいか」と「人間が苦しんでいるか」は別物──CPU使用率80%のアラートで安心していたら、ダッシュボードは全面緑なのにTwitterでは「ログインできない」の報告が流れていた（原因はDB接続プール枯渇でCPUはむしろ暇）、という典型パターンがあります。

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

3つのシナリオで考える

個人開発・小規模SaaSの場合

クラウド標準のCloudWatchやCloud MonitoringにUptimeRobotを足すだけで、月数千円から回せてしまいます。独自のダッシュボードが欲しくなったらGrafana Cloudの無料枠を追加しましょう。SRE専属がいない段階では、OpenTelemetry SDKで計測だけ標準化しておいて、バックエンドはSaaSに任せるのが運用負荷最小の構成だと思います。

個人・スタートアップ ― 1か月で出せる構成が正解 ― 生成AI時代のアーキテクチャ超入門senkohome.com/arch-intro-case-startup/

中小SaaS企業の場合

Grafana Cloud（LGTM）とOpenTelemetryの組み合わせが本命です。LGTMスタックの学習コストはそれなりにありますが、Datadogより大幅に安く済みますし、SRE 2〜3名で運用できてしまいます。DatadogやNew Relicを使う場合は、100ホストを超えたあたりで課金が跳ね上がりますので、その時点で見直すのが良いでしょう。

中小SaaS ― マネージドに寄せて少人数で回す ― 生成AI時代のアーキテクチャ超入門senkohome.com/arch-intro-case-saas/

大企業の場合

独自運用できるチームがあるなら、自社でPrometheusとGrafana、Loki、Tempo、OpenTelemetryを組む構成になります。ベンダーロックインを避けられて、機密データを外に出さずに済むのが利点ですが、運用には5名以上の専任SREが必要です。100を超える大規模マイクロサービスでSaaSに寄せるなら、DatadogやDynatraceのエンタープライズプランという選択になります。

大企業基幹系 ― 新しい技術より組織で成立する設計 ― 生成AI時代のアーキテクチャ超入門senkohome.com/arch-intro-case-enterprise/

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

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

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

アラート発報10件超/週は「ノイズ化の兆候」、本番でDEBUGログを出し続けるとCloudWatch Logs月100万円超という事故が定番です。監視コストはインフラ費の10%が上限で、超えたらサンプリング・保持期間で削ります。

AI判断軸 ― AIによる根本原因分析に備える

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

Datadogの「Watchdog RCA」やNew Relicの「AI Insights」は、複数のシグナル（ログ・メトリクス・トレース）を横断的に解析し、障害の根本原因を推定する機能を提供しています。これが機能する前提条件は、3本柱が trace_id で相関付けされていることです。OpenTelemetryで統一的に計装しておけば、ログ→トレース→メトリクスの相関がツール側で自動的に構築され、AIによるRCAの精度が最大化されます。

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

2026年時点で、AI機能の成熟度はツールによって差があります。Datadogは異常検知・RCA・ランブック推奨までAIでカバーし、HoneycombはBubbleUp（高カーディナリティ分析）でAIの介入余地を広げ、Grafana CloudはLLMベースのログクエリ生成を実装しています。ツール選定時に「AIによる診断支援がどこまで可能か」も評価軸に入れる時代です。

やってはいけないこと

監視で事故る典型を、特に危険な6つに絞ります。どれも設定しただけで運用できていない構造を持ちます。

なお独自SDKでの計装もベンダーロックインの温床です。将来の乗り換えで全書き換えになるため、新規はOpenTelemetry一択です。

筆者メモ — 「ダッシュボード全面緑」の裏で燃えていた事例

ある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 も合わせて参考にしてください。

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