本記事について
当サイトを閲覧いただきありがとうございます。 本記事はシリーズ『生成AI時代のアーキテクチャ超入門』の「システムアーキテクチャ」カテゴリ第9弾として、監視と運用のシステムアーキテクチャレベルでの全体地図を解説する記事です。
監視のない本番運用は計器なしの飛行機操縦と変わらず、復旧時間はほぼ運次第になります。本記事はシステムアーキテクチャ段階で押さえる監視要件（Observability3本柱・4ゴールデンシグナル・監視基盤選定・段階別投入計画）に特化し、運用実装（OpenTelemetry・ログ設計・SLO運用・オンコール）は別カテゴリ「開発運用アーキテクチャ」に委ねます。
本記事のテーマについてさらに詳しく知りたい方は『AWSの基本・仕組み・重要用語が全部わかる教科書』も参考にしてみてください。
本記事の守備範囲
監視・運用はシステム全体を貫くテーマなので、本シリーズでは設計段階と運用段階で記事を分けて扱います。本記事は「システムアーキテクチャ段階で、監視要件をどう組み込むか」に特化します。
| 記事 | 扱う範囲 |
|---|---|
| 本記事（監視の全体設計） | Observabilityの3本柱 / 4ゴールデンシグナル / 監視基盤の選定 / 段階別投入計画 |
| 監視とオブザーバビリティ（別カテゴリ） | メトリクス / ログ / トレースの実装 / OpenTelemetry / ダッシュボード |
| ログ設計（別カテゴリ） | ログレベル / 構造化ログ / 保持期間 / PII |
| SLOとSLI（別カテゴリ） | SLO設定 / エラー予算 / バーンレートアラート |
| インシデント対応（別カテゴリ） | オンコール / Runbook / ポストモーテム |
本記事では「SLOを月次でどう運用するか」「PagerDutyのエスカレーション」「ポストモーテムの書き方」には踏み込みません。設計時の全体地図を描いて、詳細は別カテゴリに委ねます。
本記事の問いは「システムアーキテクチャで何を監視すると決めるか」運用実装は別カテゴリの守備範囲です。
そもそも監視設計とは何か
監視設計とは、ざっくり言えば「システムの健康状態を常時チェックする仕組みを整えること」です。
車のダッシュボードを想像してください。速度計（レスポンスタイム）・燃料計（リソース使用率）・エンジン警告灯（エラーアラート）があるから、運転中に異常に気づけます。もし計器が一切なければ、エンジンが焼き付くまで気づかないかもしれません。システムの監視も同じで、数値・ログ・トレースという3つの「計器」で常時チェックし、異常を早期発見する仕組みです。
なぜ監視設計が重要なのか
もし監視なしで本番運用したらどうなるか。それは計器なしの飛行機操縦と同じで、復旧時間はほぼ運次第になります。監視基盤が貧弱なシステムは、一度大きな障害を経験するとチームの士気が崩壊します。原因が分からないまま対応を続けることになり、「次またいつ起きるか分からない」という不安が開発の足を引っ張り続けます。
逆に監視が整ったチームは、障害を学習機会として消化でき、時間とともに堅牢性が積み上がっていきます。監視は当たり前品質であり、運用開始前に整備するのが鉄則です。
Observabilityの3本柱
Observability（可観測性）は、システム内部の状態を外部から推測できる度合いを表す概念です。単なる「監視」より広く、メトリクス・ログ・トレースという3つの情報源を組み合わせて、「なぜ遅いのか・どこで失敗したか」を根本的に解明できる状態を目指します。
| 柱 | 目的 | 具体例 |
|---|---|---|
| メトリクス | 数値の時系列推移 | CPU使用率・レイテンシ・エラー率 |
| ログ | 個別イベントの詳細記録 | アクセスログ・エラーログ・監査ログ |
| トレース | 1リクエストが辿った経路 | 分散トレーシング |
3本柱が揃って初めて、メトリクスで「APIが遅い」と気づき、ログで「どのリクエストが遅かったか」を特定し、トレースで「どのサービスが原因か」を見つけられる。1つでも欠けると「どこから直せばいいか分からない」状態に陥ります。
4つの黄金シグナル
GoogleのSRE（Site Reliability Engineering）チームが提唱する、まず見るべき4つの基本指標です。全てを監視しようとすると破綻するので、この4つを軸にするのが鉄板です。
| 指標 | 意味 | 代表例 |
|---|---|---|
| Latency（レイテンシ） | リクエスト処理時間 | API応答時間・p99 |
| Traffic（トラフィック） | リクエスト数・転送量 | RPS（Requests Per Second、秒間リクエスト数）・同時接続数 |
| Errors（エラー） | 失敗したリクエスト率 | 5xxエラー率・例外発生数 |
| Saturation（飽和度） | リソース逼迫度 | CPU/メモリ/ディスク使用率 |
LatencyはP50ではなくP95・P99 で見るのが鉄則です。平均値だと「大多数のユーザーにとっては速いが、1%のユーザーにとっては耐え難く遅い」という状況を見逃します。障害は大抵、末尾の遅い1%から始まるものです。
4つのシグナルから始めます。「全部監視」は不可能です。
監視基盤の選び方
監視基盤は「クラウド純正 vs SaaS vs OSS」の3系統から選びます。運用人員のスキル・コスト許容度・既存スタックで決まります。
| 製品 | 得意領域 | 向いているケース |
|---|---|---|
| CloudWatch / Azure Monitor / GCP Operations | クラウド純正・無償枠 | 単一クラウド・スタートアップ |
| Datadog | 統合型・UI優秀 | 予算があって一元化したい |
| New Relic | APM特化 | アプリ性能重視 |
| Grafana + Prometheus + Loki | OSS統合 | コスト重視・自前運用可能 |
| Splunk | ログ解析の老舗 | エンタープライズ・大規模 |
Datadogは機能の充実度が圧倒的ですが、月額コストが数十万〜数百万円になりやすいです。Grafana Stack（OSS）は安価でも運用人員が必要。CloudWatch は単一クラウド環境なら最もコスパが良い選択肢です。
設計時に置く信頼性目標
SLOの月次運用は別カテゴリの守備範囲ですが、設計段階では「どれくらい止まっても良いサービスか」の当たりを付けておきます。これで冗長化レベル・監視投資・オンコール体制の要不要が決まります。
| サービス種別 | 目標可用性の当たり | 月間許容停止時間 |
|---|---|---|
| 個人ブログ・実験サービス | 99%（意図しないと届かない） | 約7時間 |
| 一般的なB2C Web | 99.9% | 約43分 |
| B2B SaaS（業務時間必須） | 99.95% | 約22分 |
| 金融・決済・医療 | 99.99%以上 | 約4分 |
SLA（契約）を先に決めると設計が縛られるため、「まずSLO（目標）を当たりで置き、SLAは営業要件で後から詰める」のが実務の順序です。詳細なSLIの選定とバーンレート設計は別カテゴリに委ねます。
設計時に決めるのは「何分止まってよいサービスか」の当たりだけです。精緻化は別記事で行います。
監視導入の段階別ロードマップ
監視も「最初から全部」は無理で、フェーズに応じて整える順序があります。下記は事故った時に後悔が大きい順です。
| フェーズ | 最低限入れる | 目標時間 / 指標 | 年間監視コスト目安 |
|---|---|---|---|
| ① MVP | ヘルスチェック + エラー通知（Sentry等） | 1日1回のSlack通知でOK | 〜0円 |
| ② 初期運用 | + 4ゴールデンシグナル + 構造化ログ | P95 < 500ms・エラー率 < 1% | 数万円 |
| ③ スケール運用 | + 分散トレース（OTel）・SLO/エラーバジェット | SLO 99.9%・バーンレート監視 | 数十万円 |
| ④ 多サービス | + AIOps（AI for IT Operations、AIで運用を支援する領域）対応ツール・異常検知 | 誤検知率 5%以下・MTTR 30分以内 | 数百万円 |
| ⑤ オンコール体制 | PagerDuty/Opsgenie・Runbook・ポストモーテム | MTTA（認知時間）5分以内 | + 人件費 |
アラート閾値の定番数値：P99レイテンシが平常値の2倍を超えたらWARN、3倍でPAGE、エラー率 0.5%超でWARN、2%超でPAGE。ただし静的閾値は必ず形骸化するので、運用6ヶ月以内にSLOベースへ切り替えるのが定石です。
監視はフェーズに合わせて段階投入。MVPで Datadog 月額30万円は明らかな過剰投資です。
AI判断軸 ― 標準プロトコルでAIが読めるか
AI駆動開発が前提になると、監視基盤は「OpenTelemetry等の標準プロトコルで計装できるか」と「AIがログやメトリクスを解析できるか」の2軸で選定が決まります。独自SDKの計装はAIの学習データが少なく移行もしにくい一方、OpenTelemetryはCNCF標準でAI情報量が豊富です。
| AI時代に有利 | AI時代に不利 |
|---|---|
| OpenTelemetry（標準・ベンダー中立） | 各社独自の計装SDK |
| 構造化ログ（JSON、AIが解析しやすい） | 非構造化テキストログ |
| Runbook/Alert定義をコード化 | 手順書がWord・PDF・口頭 |
| AIOps対応のDatadog/New Relic | 閉じた独自UIのみの監視基盤 |
AIによるアノマリ検知・相関分析・復旧提案が標準機能になりつつあり、「どう検知するか」より「どう復旧させるか」（Auto Remediation）を設計段階から考える時代に入っています。
選定の優先順位をまとめると次の通りです。
- 4ゴールデンシグナルを最初に計装（全部監視は不可能）
- SLO/エラーバジェットを定義し、アラートはSLO違反ベースで鳴らす
- 計装はOpenTelemetry（ベンダーロックイン回避 + AI時代対応）
- オンコールとRunbookを仕組み化し、属人化を排除
構造化ログがAI解析の前提条件
AIにログ分析を任せる場合、JSON形式の構造化ログが必須です。timestamp・level・service・trace_id・messageのフィールドが一貫した形式で出力されていれば、AIはログからエラーパターンの抽出・影響範囲の特定・根本原因の推測を高精度で行えます。
逆に、非構造化テキストログ（printfデバッグの残骸のようなフリーフォーマット）は、AIにとって解析コストが高く、誤検知や見落としが頻発します。ログフォーマットの統一は、AI時代の監視基盤における最初の投資です。
RunbookのMarkdown化とAIエージェントによる自動復旧
障害対応手順（Runbook）をMarkdownやコードとして管理すると、将来的にAIエージェントが手順を読み取って自動復旧を実行する基盤になります。たとえば「ディスク使用率90%超→古いログの削除→サービス再起動→確認」という手順が構造化されていれば、PagerDutyやOpsGenie経由でAIエージェントが自動実行する構成が現実的になりつつあります。
Word/PDFの手順書は人間しか読めないため、AI活用の対象外になります。監視設計の段階で「AIが読める形式」を意識しておくことが、将来の運用コスト削減につながります。
やっては���けないこと
監視で事故るパターンは、製品選定よりも運用設計で決まります。ここを外すと、いくら良い製品を入れても機能しません。
| 禁じ手 | なぜダメか |
|---|---|
| 本番でDEBUGログを出し続ける | CloudWatch Logs / Datadog 請求が月100万円を超える事例多数。INFO以上に絞るのが基本 |
| CPU / メモリの静的閾値（80%超でアラート）を継続運用 | 負荷変動で誤検知が積み重なり、誰も見なくなる。SLO違反ベースへ切り替える |
| アラートを1つのSlackチャンネルに全部流す | 本物の障害通知が日常ノイズに埋もれる。重要度で通知先を分離する |
| Runbookを Word / PDF / 口頭伝承で管理 | 属人化・再現不能。Markdown + Git 管理が現代の標準 |
| ポストモーテムで犯人を特定する文化 | 情報が隠蔽され、次の障害が見えなくなる。Blameless が鉄則 |
| 監視基盤のコストを監視しない | Datadog の請求が5倍に膨らむ事例が頻発。監視の監視が必要 |
| トレースなしでマイクロサービス運用 | 「どのサービスが遅いか」が特定不能で、MTTRが数時間〜数日に |
| アラートを誰も見ていない状態で放置 | 鳴らない障害と同じ。月1回のアラート棚卸しで形骸化を削る |
| ログの保持期間を延々と長く設定 | S3保管料 + Athena検索料が積み上がる。階層ストレージ + 自動削除が必須 |
| P50（平均値）でレイテンシを判断する | 平均値は1%の遅いユーザーを隠す。障害の兆候はP95/P99に現れるため、末尾レイテンシを追わないと見逃す |
| 監視項目を増やせばシステムが安全になると考える | 監視項目が増えるほどアラート疲れで全てミュートされる。価値は量ではなくアクションに繋がるかで決まる |
2017年2月28日のAWS S3 us-east-1 大規模障害は、典型文字列のタイプミスで数百サービスが4時間停止した事件です。監視が整っていても「親クラウドの障害通知」を受け取る仕組みがないチームは、状況把握が遅れて対応が後手になりました。
アラートの価値は「鳴らした数ではなく、人が動いた数」で決まります。
「ミュートにしないと仕事にならない」アラートチャンネル（業界事例）
ある開発チームに新人が入った初日、先輩から「このSlackチャンネル、ミュートにしないと仕事にならないですよ」と真顔で言われた。という話が現場から伝わってきます。そのチャンネルはCPU閾値アラートが毎日数十件鳴り続けるノイズの塊で、チーム全員が実質的に見るのをやめていたそうです。
ところが数ヶ月後、本物の障害アラートも同じチャンネルに埋もれ、検知が数時間遅れたといいます。
似たような光景はいろいろなチームで目撃されています。「このチャンネルは誰も見ない」が暗黙の共有知識になっていて、新しく入ったメンバーだけが毎回驚く構造になっている。教訓は、「アラートは鳴らした数ではなく、人が動けた数で価値が決まる」ということです。
誰も見ないチャンネルは、存在しないのと同じ。ノイズは削り、SLO違反だけ鳴らす、という設計に振り切る勇気が、結果的にチームを救います。
「消すのが怖いアラート」は、もう形骸化しています。
決めるべきこと（設計段階）
- 監視基盤の方針（CloudWatch / Datadog / Grafana系）
- ログ集約の有無と保存期間（30日 / 90日 / 年単位）
- 分散トレースを計装するか（OpenTelemetry採用の有無）
- 信頼性目標（SLOの当たり値・許容停止時間）
- 監視コストの上限
アラート設計・SLO運用・オンコール・Runbook・ポストモーテムは別カテゴリ「開発・運用アーキテクチャ」の各記事で決定します。
この記事に関連する記事
まとめ
本記事はシステムアーキテクチャレベルでの監視と運用の全体地図について解説しました。如何だったでしょうか。
4ゴールデンシグナル → Observability3本柱 → SLOベースのアラート、という順序で整えるのが鉄板です。「全部監視」は不可能なので、フェーズに応じて段階投入し、ノイズアラートは消す勇気が大事です。
次回は「BCP」（事業継続計画・RPO/RTO・DR戦略）について解説します。
シリーズ目次に戻る → 『生成AI時代のアーキテクチャ超入門』の歩き方
本記事で扱った内容の詳細は Amazon CloudWatch も合わせて参考にしてください。
それでは次の記事も閲覧いただけると幸いです。
📚 シリーズ：生成AI時代のアーキテクチャ超入門（14/89）