本記事について
当サイトを閲覧いただきありがとうございます。 本記事はシリーズ『生成AI時代のアーキテクチャ超入門』の「システムアーキテクチャ」カテゴリ第9弾として、監視と運用のシステムアーキテクチャレベルでの全体地図を解説する記事です。
監視のない本番運用は計器なしの飛行機操縦と変わらず、復旧時間はほぼ運次第になります。本記事はシステムアーキテクチャ段階で押さえる監視要件（Observability3本柱・4ゴールデンシグナル・監視基盤選定・段階別投入計画）に特化し、運用実装（OpenTelemetry・ログ設計・SLO運用・オンコール）は別カテゴリ「開発運用アーキテクチャ」に委ねます。
このカテゴリの他の記事
本記事の守備範囲
監視・運用はシステム全体を貫くテーマなので、本シリーズでは設計段階と運用段階で記事を分けて扱います。本記事は「システムアーキテクチャ段階で、監視要件をどう組み込むか」に特化します。
| 記事 | 扱う範囲 |
|---|---|
| 本記事（監視の全体設計） | Observabilityの3本柱 / 4ゴールデンシグナル / 監視基盤の選定 / 段階別投入計画 |
| 監視とオブザーバビリティ（別カテゴリ） | メトリクス / ログ / トレースの実装 / OpenTelemetry / ダッシュボード |
| ログ設計（別カテゴリ） | ログレベル / 構造化ログ / 保持期間 / PII |
| SLOとSLI（別カテゴリ） | SLO設定 / エラー予算 / バーンレートアラート |
| インシデント対応（別カテゴリ） | オンコール / Runbook / ポストモーテム |
本記事では「SLOを月次でどう運用するか」「PagerDutyのエスカレーション」「ポストモーテムの書き方」には踏み込みません。設計時の全体地図を描いて、詳細は別カテゴリに委ねます。
本記事の問いは「システムアーキテクチャで何を監視すると決めるか」運用実装は別カテゴリの守備範囲です。
計器なしで飛ぶ飛行機
監視はシステムが正常に動いているかを数値・ログ・トレースで常時チェックする仕組みで、運用はその上で障害対応・予防保守・性能改善・コスト最適化を日常業務として回す営みです。両者は不可分のペアで、「監視で気づいて運用で直す」がワンセットです。運用開始前に監視基盤を整えるのは、機能開発と同じかそれ以上に重要な投資になります。
監視基盤が貧弱なシステムは、一度大きな障害を経験するとチームの士気が崩壊します。原因が分からないまま対応を続けることになり、「次またいつ起きるか分からない」という不安が開発の足を引っ張り続けます。逆に監視が整ったチームは、障害を学習機会として消化でき、時間とともに堅牢性が積み上がっていきます。
監視は当たり前品質。運用開始前に整備するのが鉄則です。
Observabilityの3本柱
Observability（可観測性）は、システム内部の状態を外部から推測できる度合いを表す概念です。単なる「監視」より広く、メトリクス・ログ・トレースという3つの情報源を組み合わせて、「なぜ遅いのか・どこで失敗したか」を根本的に解明できる状態を目指します。
flowchart LR
M[Metrics<br/>数値の時系列<br/>CPU/レイテンシ/エラー率]
L[Logs<br/>個別イベント<br/>アクセス/エラー/監査]
T[Traces<br/>1リクエストの経路<br/>分散トレーシング]
Q1{気づく}
Q2{特定する}
Q3{原因究明}
M --> Q1
L --> Q2
T --> Q3
Q1 --> Q2 --> Q3 --> FIX[修正対応]
classDef metric fill:#dbeafe,stroke:#2563eb;
classDef log fill:#fef3c7,stroke:#d97706;
classDef trace fill:#fae8ff,stroke:#a21caf;
classDef step fill:#f0f9ff,stroke:#0369a1;
classDef fix fill:#dcfce7,stroke:#16a34a;
class M metric;
class L log;
class T trace;
class Q1,Q2,Q3 step;
class FIX fix;| 柱 | 目的 | 具体例 |
|---|---|---|
| メトリクス | 数値の時系列推移 | 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万円は明らかな過剰投資です。
監視・アラート設計の鬼門
監視で事故るパターンは、製品選定よりも運用設計で決まります。ここを外すと、いくら良い製品を入れても機能しません。
| 禁じ手 | なぜダメか |
|---|---|
| 本番でDEBUGログを出し続ける | CloudWatch Logs / Datadog 請求が月100万円を超える事例多数。INFO以上に絞るのが基本 |
| CPU / メモリの静的閾値（80%超でアラート）を継続運用 | 負荷変動で誤検知が積み重なり、誰も見なくなる。SLO違反ベースへ切り替える |
| アラートを1つのSlackチャンネルに全部流す | 本物の障害通知が日常ノイズに埋もれる。重要度で通知先を分離する |
| Runbookを Word / PDF / 口頭伝承で管理 | 属人化・再現不能。Markdown + Git 管理が現代の標準 |
| ポストモーテムで犯人を特定する文化 | 情報が隠蔽され、次の障害が見えなくなる。Blameless が鉄則 |
| 監視基盤のコストを監視しない | Datadog の請求が5倍に膨らむ事例が頻発。監視の監視が必要 |
| トレースなしでマイクロサービス運用 | 「どのサービスが遅いか」が特定不能で、MTTRが数時間〜数日に |
| アラートを誰も見ていない状態で放置 | 鳴らない障害と同じ。月1回のアラート棚卸しで形骸化を削る |
| ログの保持期間を延々と長く設定 | S3保管料 + Athena検索料が積み上がる。階層ストレージ + 自動削除が必須 |
2017年2月28日のAWS S3 us-east-1 大規模障害は、典型文字列のタイプミスで数百サービスが4時間停止した事件です。監視が整っていても「親クラウドの障害通知」を受け取る仕組みがないチームは、状況把握が遅れて対応が後手になりました。
アラートの価値は「鳴らした数ではなく、人が動いた数」で決まります。
AI時代の視点
AI駆動開発が前提になると、監視基盤の選定は「OpenTelemetryなどの標準プロトコルで計装できるか」と「AIがログやメトリクスを解析できるか」の2軸で決まります。
独自SDK・ベンダーロックインされた計装は、AIの学習データが少なく移行もしにくい一方、OpenTelemetryはCNCF標準でAIの情報量が豊富です。さらにAIがログを要約し、インシデント対応のRunbookをAI生成・AI実行する未来が現実味を帯びています。
| AI時代に有利 | AI時代に不利 |
|---|---|
| OpenTelemetry（標準・ベンダー中立） | 各社独自の計装SDK |
| 構造化ログ（JSON、AIが解析しやすい） | 非構造化テキストログ |
| Runbook/Alert定義をコード化 | 手順書がWord・PDF・口頭 |
| AIOps対応のDatadog/New Relic | 閉じた独自UIのみの監視基盤 |
AIによるアノマリ検知・相関分析・復旧提案が標準機能になりつつあります。「どう検知するか」より「どう復旧させるか」（Auto Remediation）を設計段階から考える時代に入っています。
AI時代は「標準プロトコル + 構造化データ」AIが読めない監視は価値半減です。
よくある勘違い
- とにかく多く監視すれば安全 → 本当はこう：監視項目が増えれば増えるほどアラート疲れで全部ミュートされます。監視は量ではなくアクションに繋がるかで評価する
- 平均値を見れば性能が分かる → 本当はこう：平均は1%の遅いユーザーを隠します。P95/P99で見ないと障害の兆候が消える。LatencyはP50ではなくP99で追う
- ログは多いほど後で役に立つ → 本当はこう：DEBUGログ垂れ流しはコストが跳ねる地雷。INFO以上に絞り、DEBUGは調査時だけ一時的に有効化
- 障害時は犯人を探して再発防止 → 本当はこう：個人を責めると情報が隠蔽され、次の障害は見えなくなります。Blameless（非難なき）が鉄則
「ミュートにしないと仕事にならない」アラートチャンネル（業界事例）
ある開発チームに新人が入った初日、先輩から「このSlackチャンネル、ミュートにしないと仕事にならないですよ」と真顔で言われた。という話が現場から伝わってきます。そのチャンネルはCPU閾値アラートが毎日数十件鳴り続けるノイズの塊で、チーム全員が実質的に見るのをやめていたそうです。
ところが数ヶ月後、本物の障害アラートも同じチャンネルに埋もれ、検知が数時間遅れたといいます。
似たような光景はいろいろなチームで目撃されています。「このチャンネルは誰も見ない」が暗黙の共有知識になっていて、新しく入ったメンバーだけが毎回驚く構造になっている。教訓は、「アラートは鳴らした数ではなく、人が動けた数で価値が決まる」ということです。
誰も見ないチャンネルは、存在しないのと同じ。ノイズは削り、SLO違反だけ鳴らす、という設計に振り切る勇気が、結果的にチームを救います。
「消すのが怖いアラート」は、もう形骸化しています。
決めるべきこと（設計段階）
- 監視基盤の方針（CloudWatch / Datadog / Grafana系）
- ログ集約の有無と保存期間（30日 / 90日 / 年単位）
- 分散トレースを計装するか（OpenTelemetry採用の有無）
- 信頼性目標（SLOの当たり値・許容停止時間）
- 監視コストの上限
アラート設計・SLO運用・オンコール・Runbook・ポストモーテムは別カテゴリ「開発・運用アーキテクチャ」の各記事で決定します。
よくある失敗
- 本番でDEBUGログを出し続け、月100万円超の請求 ― INFO以上に絞るだけで大幅削減
- CPU閾値アラートが毎日鳴って誰も見ない ― SLOベースに変えるまで形骸化。本物の障害通知も確実に埋もれる
- ログは取っているが検索できず障害時に役立たない ― 構造化ログ＋集約基盤が必須
- ポストモーテムで犯人探し → 次の障害が隠蔽される。Blameless文化の徹底が必要
- 監視基盤の料金を監視しておらず予算オーバー ― Datadogで請求5倍に膨らむ事例が頻発
最終的な判断の仕方
監視と運用は「機能要件ではなく当たり前品質」として扱うのが選定の核になります。ユーザーから苦情が来て初めて障害に気づく状態は運用の放棄で、運用開始前に監視基盤・アラート設計・オンコール体制を整えるのが前提条件です。
「全部監視する」は不可能なので、Googleの4ゴールデンシグナル（Latency/Traffic/Errors/Saturation）を起点に、段階的にObservabilityの3本柱（メトリクス/ログ/トレース）を揃えるのが現実解です。
設計判断で最も重要なのは「SLOベースのアラート」と「コスト設計」の2点です。静的閾値アラートはノイズ化して必ず形骸化するので、SLO違反（ユーザー影響）を基準に鳴らす設計に倒します。
監視基盤自体のコスト（特にDatadogや本番DEBUGログ）は請求書が跳ねやすく、「監視のコストを監視する」のが実務の現実です。AI駆動開発では、OpenTelemetry + 構造化ログでAIが読める状態にしておくのが必須条件になります。
選定の優先順位をまとめると次の通りです。
- 4ゴールデンシグナルを最初に計装（全部監視は不可能）
- SLO/エラーバジェットを定義し、アラートはSLO違反ベースで鳴らす
- 計装はOpenTelemetry（ベンダーロックイン回避 + AI時代対応）
- オンコールとRunbookを仕組み化し、属人化を排除
「鳴っても誰も見ないアラートは消す」が鉄則。監視の価値は量ではなく、アクションにつながるか否かです。
まとめ
本記事はシステムアーキテクチャレベルでの監視と運用の全体地図について解説しました。如何だったでしょうか。
4ゴールデンシグナル → Observability3本柱 → SLOベースのアラート、という順序で整えるのが鉄板です。「全部監視」は不可能なので、フェーズに応じて段階投入し、ノイズアラートは消す勇気が大事です。
次回は「BCP」（事業継続計画・RPO/RTO・DR戦略）について解説します。
シリーズ目次に戻る → 『生成AI時代のアーキテクチャ超入門』の歩き方
それでは次の記事も閲覧いただけると幸いです。
📚 シリーズ：生成AI時代のアーキテクチャ超入門（14/89）