制作会社の現場では「監視しています」という表現が頻繁に使われます。しかし、障害や性能劣化が起きた瞬間に問われるのは「監視しているかどうか」ではなく、監視が運用として機能する設計になっているかです。
ここでいう「機能する」とは、単にメトリクスを見ている状態ではありません。少なくとも、以下の要素が定義され、関係者が参照できる状態です。
- 何を監視するか（対象・範囲）
- どの条件で異常とみなすか（しきい値・判定）
- 誰が通知を受けるか（一次受け・当番）
- いつ対応するか（対応時間・例外）
- 最初に何を確認するか（初動手順）
- どこへ連絡するか（エスカレーション：連絡順・判断基準）
- 何を残すか（記録・証跡）
- どう改善するか（振り返り）
通知先／対応時間／初動／連絡順が未定義のままだと、障害時に「通知は来たが誰も動けない」「動いたが判断できない」「連絡先が分からない」が連鎖し、調整負荷が制作会社側に集中しやすくなります。
本記事は、クライアント（※必要に応じて既存保守会社・開発会社・前任ベンダーなど関係者を含む）へ確認に走る前に、制作会社側で前提・範囲・運用条件を棚卸しするための20項目をまとめたものです。提案フェーズ・運用フェーズのどちらでも、「監視が機能している状態」かどうかを点検できます。
なぜ監視の棚卸しが必要か
「監視している」の認識違いが、期待値ズレ／初動遅延／属人化につながる
「監視しています」という言葉が指す内容は、関係者ごとに異なります。
- クライアント：「外形も死活も性能もアプリも見ている」
- 制作会社：「死活（落ちたら通知）だけ」「通知設定はあるが運用は未整備」
- 既存保守会社：「監視は既存がやっているはず」だが、実態は範囲が限定的
この認識差が残ったまま進むと、障害発生時に次のような摩擦が起きやすくなります。
- 「監視しているなら、なぜユーザーからの連絡が先なのか」
- 「通知は来ていたが、一次受けが不在で見ていなかった」
- 「営業時間外の扱いを決めていなかった」
- 「復旧の定義が一致せず、連絡が遅いと言われた」
技術的な復旧の難しさ以前に、期待値ズレによる信頼毀損が先に発生しやすい点が、監視で問題になりやすいところです。
制作会社はインフラ専任が薄く、調整負荷が集中しやすい
制作会社では、インフラ専任がいない／薄い状態で、PM・ディレクター・営業が「調整役」になりがちです。監視の運用設計が曖昧だと、障害時に次のような「詰まり」が起きます。
- 誰に連絡するかが分からず、連絡が遅れる
- 監視ツールやクラウドの権限が揃っておらず、確認に時間がかかる
- 初動の確認順がなく、切り分けが止まる
- 結果として、調整役に負荷が集中する
だからこそ、ツールの話をする前に、まず棚卸しで設計の穴を可視化することが重要です。
監視は「項目」ではなく、運用設計（通知・初動・判断）の整備である
監視は「CPUを見てます」「死活監視があります」という項目の有無だけでは成立しません。監視が運用として機能するのは、検知→通知→初動→判断→エスカレーション→記録→改善がつながっているときです。
たとえば、通知が来ても一次受けが不在なら「気づけない」。気づいても初動が未整備なら「動けない」。動いても判断基準やエスカレーションが曖昧なら「止まる」。記録と振り返りがなければ「同じことを繰り返す」ことになります。監視は「点」ではなく「線」です。
棚卸し不足で発生しやすい典型的なズレ
通知設計の過不足により、重要アラートの見落としが起きる
通知が多すぎると埋もれ、少なすぎると検知できません。重大度の段階がないと、夜間に不要な通知で疲弊し、結果として重要通知の見落としにつながりやすくなります。
初動手順が未整備で、検知後の対応が遅れる
「まず何を見ればいいか」が決まっていないと、外形・死活・直近の変更・ログ確認がばらばらになり、切り分けが遅れます。
当番・運用時間・エスカレーションが曖昧になり、調整負荷が集中する
誰が一次受けするか、対応時間はどこまでか、誰に繋ぐかが曖昧だと、結局PM／ディレクターが交通整理をする構図になりがちです。
記録・振り返りがなく、改善が継続しない
対応内容を記録しないと、改善が回らず同種の通知・事故が繰り返されます。
次の章の20項目は、こうしたズレを潰すための棚卸し観点です。
クライアントに確認する前に整理すべき20項目
この20項目で整理できること
- 監視が「機能している状態」かどうかを判断できる
- 不足があれば、未整備箇所（通知／初動／当番／証跡など）を特定できる
- 整理した内容を、社内共有・引き継ぎ・クライアント説明に転用できる
ポイントは「クライアントに確認する前に」です。確認そのものが悪いのではなく、「何を確認すべきか」が曖昧なまま関係者に聞き始めると、情報収集が長期化し、属人化しやすいためです。先に観点を揃えてから確認に走るだけで、確認の抜け漏れが減り、質問が具体化します。
棚卸しの進め方
- 答えられない項目＝未整備として扱う
- 完璧を目指すより、最低ラインを先に固める（後述のStep1が最優先）
- 決まった内容は議事録・運用メモに残し、更新できる形にする
補足として、確認先は「クライアント」だけとは限りません。既存保守会社・開発会社・前任ベンダーなど、情報が分散しているケースは多くあります。棚卸しは「誰に聞くか」ではなく、まず「何を確認するか」を確定させる作業です。
1. 目的と対象範囲（Q1〜Q4）
Q1. 監視の目的（早期検知／兆候検知／セキュリティ兆候など）
監視の目的が曖昧だと、必要な項目も通知の設計もぶれます。
例：止まると困る（死活）／遅くなると困る（応答・性能）／エラー率が困る（アプリ）／兆候検知がしたい（容量や遅延の傾向）
Q2. 監視範囲（外形・サーバー・DB・ミドルウェア・アプリ・ジョブ・証明書 等）
どこまでを監視対象に含めるかを決め、関係者で認識を揃えます。特に「アプリ監視」「ジョブ監視」は抜けやすいので要確認です。
Q3. 対象環境（本番のみ／検証含む）
本番だけなのか、検証も含めるのかを整理します。検証を含める場合は、通知疲れを防ぐ設計（通知先や抑止）も合わせて検討が必要です。
Q4. 「異常」の定義（停止・遅延・エラー率・逼迫 など）
「異常」の定義がないと「通知は来たが対応判断ができない」状態になります。
例：応答時間が何秒を超えたら異常か／エラー率が何％で異常か／容量は何％で要注意か
2. 監視項目（Q5〜Q10）
Q5. 外形監視（頻度・判定条件・監視地点）
URL監視は最小限の監視として有効ですが、頻度・地点・判定条件次第で価値が変わります。
例：1分間隔か5分間隔か／複数地点が必要か／200でもエラー画面を返すケースを拾えるか
Q6. 死活監視（単位：VM／コンテナ／LBなど）
何を単位として「落ちた」と判断するかを整理します。インフラ構成によっては、VMが生きていてもLB配下が死んでいる状態が起きます。
Q7. リソース（CPU／メモリ／ディスク／IO／ネットワーク）
見るだけでなく、しきい値や段階とセットで考えます。特にディスク逼迫は兆候検知として代表的で、気づけると事故を減らせます。
Q8. アプリ（500率、ログエラー、APM等）
サーバーが生きていてもアプリが止まるケースは少なくありません。
例：500が増える／特定APIだけ遅い／ログに特定エラーが増える
Q9. バッチ／ジョブ（失敗・遅延・未実行の検知）
「失敗」だけでなく「走っていない」「遅れている」を拾えるかを確認します。売上や業務に直結する処理ほど、外形より先にジョブ監視が有効な場合があります。
Q10. 期限（SSL証明書・ドメイン等）
期限系は影響が大きい一方で、設計が後回しになりがちです。何日前に誰へ通知し、誰が更新するかまで決めます。
3. しきい値とアラート設計（Q11〜Q14）
Q11. しきい値の決め方（固定／平常値比／時間帯別）
固定値で良いか、平常値からの乖離を見るか、時間帯で分けるかを整理します。「正解」より、まず「根拠の置き方」を決めることが重要です。
Q12. 段階（Warning／Critical）と、それぞれの条件
段階がないと、通知が「全部同じ重さ」になり、運用が疲弊します。まずはWarningで兆候を拾い、Criticalで即時対応、のように整理します。
Q13. 誤検知 vs 検知遅れ、どちらを優先するか（方針決定／判断基準の明確化）
サービス特性で最適が変わります。
例：ピーク時は検知遅れを避けたい／開発中は誤検知を抑えたい
Q14. メンテ時の抑止（サイレンス）の手順（誰が／どうやる）
メンテで鳴り続ける→慣れて無視→本番の重大アラートも見落とす、という流れは典型的な事故パターンです。「誰が」「どの手順で」「いつ解除するか」まで運用として定義します。
4. 通知・初動・当番（Q15〜Q18）
Q15. 通知先（メール／Slack／Teams／電話）と一次受け
「通知が飛ぶ」ではなく「誰が受ける」が主語です。一次受けが曖昧だと、監視の効果が出にくくなります。
Q16. 運用時間（監視の対応時間（何時〜何時、誰が一次受けするか））と例外条件
24／365か、営業時間か、ベストエフォートか。重要なのは「言い切る」ことではなく、線引きを明文化することです。
例：時間外は重大障害のみ連絡／一次受けはするが復旧は翌営業日
Q17. 初動手順（最初の5分で確認する項目）
初動は完璧な手順書でなくて構いません。まずは5分の固定化が有効です。
例：外形→死活→直近変更（デプロイ／設定変更）→ログ→影響範囲
Q18. エスカレーション（連絡順・連絡手段・判断基準）
誰に、どの順で、どう繋ぐかを整理します。連絡順が曖昧だと、障害時に「関係者探し」が始まり、初動が遅れます。
5. 証跡・改善（Q19〜Q20）
Q19. 履歴と対応記録を残す場所（チケット／運用台帳等）
チャットだけに残すと、後から振り返れません。「最低限どこに残すか」だけでも決めると、改善が回り始めます。
Q20. 振り返り方法（月次レポ、再発防止の決め方）
監視は運用で育てるものです。
例：月次でアラート件数・重大度・誤検知・再発を確認し、しきい値と通知設計を調整する
未設計があった場合の整備手順
20項目を埋めると、必ず「答えられない」「曖昧」が出ます。ここからが本番です。未整備を一気に全部埋めようとすると止まりやすいので、最短で「機能する監視」に寄せる順番で進めます。
Step1｜決める（検知して動ける状態を作る）
ここが未整備だと、監視ツールがあっても機能しません。まず最低ラインを作ります。
- 一次受け（通知先）：誰が受けるか（担当／当番／窓口）
- 運用時間（いつ誰が見るか）：対応時間・例外条件
- 初動（最初の確認手順）：最初の5分の確認順
- エスカレーション（誰に繋ぐか・判断基準）：連絡順と判断ライン
ポイントは「完璧」ではなく「止まらない」ことです。Step1が揃うだけで、障害時の交通整理に費やす時間が減ります。
Step2｜整える（見落とし・疲弊を防ぐ）
次に「監視はあるのに役に立たない」状態を防ぎます。通知の質を上げる工程です。
- しきい値の根拠（固定値／平常値比／時間帯別）
- 段階（Warning／Critical）
- メンテナンス時の抑止（サイレンス）手順
Step2は、アラート疲れによる見落としを防ぐ意味でも重要です。特にメンテ時の抑止は、Step2の中では優先度が高い項目です。
Step3｜仕組みにする（改善を回す）
最後に、同じ課題を繰り返さない仕組みを作ります。ここまで来ると監視が運用として改善される状態になります。
- 履歴・対応記録の置き場
- 振り返りの頻度と観点（アラート削減／再発防止）
詰まりやすいポイント
運用時間を決めきれない（期待値が怖い）
「24／365か否か」ではなく、まずは一次受け可能な時間帯、時間外の扱い、緊急時の例外に分けて線を引くと決めやすくなります。
初動手順の粒度が分からない（どこを見るべきか）
まずは「最初の5分」だけ固定化します。完璧なRunbookは後から育てれば良い、という割り切りが重要です。
しきい値の基準が作れない（根拠不足）
いきなり正解を決めず、Warning→Criticalの段階を作り、1〜2週間の観測で調整する前提にすると進みます。
まとめ
棚卸しで押さえるべき結論
この棚卸しで得たい成果は、「監視しています」を運用として説明できる状態にすることです。項目の数ではなく、検知後に止まらず動ける条件が揃っているかを確認してください。
- 監視は「項目」ではなく、運用設計（通知→初動→判断）
- 未設計があれば、Step1→2→3の順で埋める
- 特にStep1（通知先／運用時間／初動／エスカレーション）が最優先
次にやること
ここから先は、棚卸し結果を“未整備のタスク”に変換するだけです。答えられない項目は未整備として扱い、前提に合わせて埋めていきましょう。
- まずは20項目を埋める（答えられない＝未整備を可視化する）
- 未整備が出たら、Step1から最短で整備する
- 詰まったら、前提に合わせて落とし込む支援を使う
コーポレートサイトをクラウドでセキュアに
サーバー管理
クロジカガイドブック
- コーポレートサイト構築・運用の課題を解決
- クロジカサーバー管理の主な機能
- 導入事例
- 導入までの流れ
