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