障害対応や緊急対応が遅れる原因は、技術力不足よりも「必要な情報が散在していて初動が止まる」ことが多いです。Slack、メール、スプレッドシート、口頭伝承に情報が分散していると、復旧作業の前に「探す」「確認する」「連絡を待つ」時間が発生します。
制作会社のディレクター/PMは、インフラ専任が薄い体制の中で、顧客・開発・保守会社・各種ベンダーの間に立つ調整役になりがちです。その結果、障害時は復旧作業より先に、ログイン情報・連絡先・切り分けの材料を集める作業に追われます。
この記事では、初動10分で動ける状態を作るために、最低限そろえるべき情報を整理します。ゴールは立派な資料を作ることではなく、緊急時に「どこを見れば、次の行動が決まるか」が明確になっている状態にすることです。
障害対応が遅れるのは「技術」ではなく“探しもの”から始まる
制作会社の現場でよく起きるのが、次のような状態です。
- Slackに断片的な情報が流れている（例：「DNSは◯◯が見ていたはず」）
- メールに契約情報が埋もれている（例：どのベンダーで契約しているか分からない）
- スプレッドシートはあるが更新されていない（例：担当者退職、最終更新が半年前）
- 「◯◯さんが知っているはず」で口頭伝承になっている（属人化）
障害が発生した直後、最初に必要になるのは復旧作業そのものではなく、「入る」「連絡する」「切り分ける」ための確認です。具体的には次の3つです。
- どこにログインするか（どの管理画面を見るか）
- 誰に連絡するか（意思決定者／作業者／外部窓口）
- どこで問題が起きている可能性が高いか（切り分けの順番）
“初動が止まる”典型シーン（ミニケース）
たとえば、サイトが急に表示できなくなった場合、確認したいのは概ね次の順番です。
- DNSが変わっていないか（切替／期限／設定ミス）
- CDN/WAFが遮断していないか（ルール変更／誤検知）
- Origin（サーバ／コンテナ／クラウド）が停止していないか
- アプリやDBでエラーが出ていないか
- 監視に何が出ているか、いつからか
ただし現場では、確認の順番が分かっていても、管理画面や窓口が特定できずに初動が止まることが多いです。
- DNSの管理画面URLが分からない（どのサービスか／誰の名義か）
- CDN/WAFがどれか分からない（Cloudflareなのか、ALBなのか、別サービスなのか）
- 監視の通知が誰に届いているか分からない（どのSlackチャンネル／誰のメール）
- 顧客側の意思決定者に連絡できない（夜間に電話してよいか／誰が承認するか）
つまり「復旧が遅い」の正体は、技術対応そのものよりも、次の3つで止まっているケースが多いということです。
- ログインできない（管理画面URLが不明／名義が不明／MFAの所在が不明）
- 連絡できない（顧客の意思決定者・承認者が不明／保守会社の窓口が追えない）
- 構成が分からない（どこから切り分けるべきかが決まっていない）
制作会社では、インフラ専任が薄い／いないことも多く、障害時の調整がディレクターやPMに集中しがちです。復旧のために手を動かす前に、まず情報を集め、関係者を揃え、判断材料を用意するところから始まってしまう。これが初動遅延の実態です。
初動10分で動くために整理すべき“必要情報”3つ
初動10分で動ける状態とは、「完璧なドキュメントがある」ことではありません。最低限、次の3つが揃っていて、すぐに辿れる状態です。
- 入れる（権限）：必要な管理画面にログインできる
- 連絡できる（連絡先）：判断できる人／作業できる人に連絡できる
- 切れる（構成）：原因候補の範囲を絞り、次に見るべき箇所が決まる
ここでいう「10分」は復旧完了ではありません。10分で次の行動が決まる状態です。たとえば、次ができれば十分です。
- どの管理画面を見るべきかが分かり、ログインできる
- 誰に連絡すべきかが分かり、連絡できる
- 影響範囲の仮説が立ち、切り分けの順番が決まる
1. 権限（入れないと始まらない：管理画面・アカウント・MFA）
最優先は「入れる」ことです。ログインできないと、確認も問い合わせも進みません。
最低限そろえるもの
- 管理画面URL一覧（DNS／CDN／クラウド／監視／サーバ など）
- 名義・アカウントの所在（誰が持つ／どこに保管）
- MFAの所在（誰の端末／どの手段）
- パスワードは直書きしない（保管場所のリンクにする）
直書きしない理由
- 更新されず、緊急時に使えない
- 共有が難しくなり、特定の人に依存する
- セキュリティ上のリスクになる
現実的な落とし所
ここに書くのは「秘密情報」ではなく「辿り方」です。
- 管理画面URL
- 保管場所（1Password／Bitwarden／社内Vault／Backlogの添付やWiki など）
- 管理者（誰が管理しているか）
- MFAの所在（認証アプリ／物理キー／SMSなど、誰が持つか）
MFAが不明だと、IDとパスワードが分かっていてもログインできません。だからこそ、MFAは必ず「所在」を記録します。
2. 連絡先（決められないと進まない：顧客・保守会社・ベンダー）
障害対応は技術対応だけで完結しません。判断・承認・外部調整が必ず発生します。
最低限そろえるもの
- 顧客側：意思決定者／承認者／窓口（夜間・休日ルール含む）
- 外部：保守会社／クラウド／DNS業者／証明書／CDN/WAF
- 一次連絡テンプレ（何が起きた／影響／暫定対応／次アクション）
連絡先で重要なのは「役割」
名前があっても、役割が曖昧だと判断が止まります。
- この人に連絡すれば判断できる（停止／切り戻しの判断）
- この人に連絡すれば承認できる（作業の許可）
- この窓口に連絡すれば作業できる（実行部隊）
夜間・休日ルール（最小限）
- 夜間は電話OKか
- まず誰に連絡するか（一次窓口）
- 何分返信がなければ誰にエスカレーションするか
一次連絡テンプレ（要素が揃っていることが重要）
- 事象：何が起きているか（例：サイトが503）
- 影響：誰が困っているか（例：全ユーザー）
- 発生：いつからか（例：10:12頃）
- 現状：分かっていること（例：監視でCPU高騰、DB接続エラー）
- 暫定：やったこと（例：再起動、切り戻し検討中）
- 次：判断が必要なこと（例：一時停止して復旧するか）
3. 構成（どこで落ちているかを切る：依存関係・監視・影響範囲）
構成が曖昧だと、切り分けが当て推量になり、時間が失われます。
最低限そろえるもの
- 依存関係を1行で（DNS→CDN/WAF→Origin→DB→外部API）
- 例：example.com → Cloudflare → ALB → ECS → RDS → 外部決済API
- 監視の入口（何をどこで見て、通知はどこへ）
- バックアップ／切り戻しの導線（どこに、何世代、復元リンク）
構成図を作り込む必要はありません。1行で依存関係が分かれば、初動の順番が決まり、関係者への説明も早くなります。
監視も設定内容を全部書く必要はなく、最低限は次の3点です。
- 異常か正常かを判断できるダッシュボードURL
- 通知先（Slack／メール／電話）
- アラート履歴を確認できる場所
初動10分の“必要情報チェック”テンプレ
ここからは、前章の3カテゴリ（権限／連絡先／構成）を、そのまま埋められるチェック形式に落とします。
目的は一覧を綺麗に作ることではなく、不足している情報を見える化し、緊急時に辿れる状態にすることです。
最初から全項目を完璧に埋める必要はありません。まずは空欄を出し、「誰に何を確認すれば埋まるか」を決められる状態にします。空欄が見えれば、顧客や保守会社に確認すべき内容が明確になります。
A. 権限チェック（管理画面URL／名義／MFA）
以下の項目を、「どこにログインするか」と「どう辿るか」が分かるように整理します。
パスワードそのものは記載せず、保管場所へのリンクを置く運用にします。
- DNS管理：管理画面URL／名義／アカウント保管場所／MFAの所在
- CDN/WAF：管理画面URL／名義／権限者／MFAの所在
- クラウド：管理画面URL／名義／権限者／MFAの所在
- 監視：管理画面URL／通知先／閲覧権限
- サーバ：管理画面URL（または接続情報の保管場所）／作業権限
記入例（目安）
- 名義：顧客法人名／制作会社法人名（個人名義は要注意）
- 保管場所：1PasswordのVault名／BacklogのWikiページ／Notionの固定ページ／社内Vaultなど
- MFAの所在：PM端末／顧客情シス端末／物理キーの保管場所（保管者）など
B. 連絡先チェック（意思決定者／外部窓口／夜間休日）
障害対応では「作業できる人」だけでなく、「判断できる人／承認できる人」が必要です。
連絡先は氏名だけでなく、役割と連絡ルールまで整理します。
- 顧客：意思決定者／承認者／窓口（連絡手段・対応時間・夜間休日ルール）
- 保守会社：一次窓口／緊急窓口（契約有無・対応範囲）
- 各ベンダー：DNS／証明書／CDN／クラウド（問い合わせ方法・ログイン要否）
一次連絡テンプレ（コピペ用）
- 事象（何が起きた）：
- 影響範囲（誰に影響が出ている）：
- 発生時刻（いつから）：
- 現状（分かっていること）：
- 暫定対応（実施済みのこと）：
- 次に判断が必要なこと（承認・方針決定が必要な点）：
補足：問い合わせ方法まで書く理由
「問い合わせフォームしかない」「電話がある」「チャットがある」だけでも初動が変わります。
また、問い合わせ自体にログインが必要なベンダーもあるため、連絡先は権限情報（A）とセットで管理します。
C. 構成チェック（DNS→CDN→サーバ→DB→外部API）
構成は作り込んだ図よりも、初動で切り分けの順番を決められる情報が重要です。
まずは依存関係を1行で書ける状態にします。
- 依存関係（1行）：
- 例：example.com → Cloudflare → ALB → ECS → RDS → 外部決済API
- 監視の入口（どこを見る）：
- 通知先（誰に届く／どこに届く）：
- 影響範囲の見立て（例：全ユーザー／ログインのみ／購入のみ／管理画面のみ）：
補足：影響範囲は粗くて構いません
最初の説明で必要なのは精密な分析ではなく、一次報告としての見立てです。
「全ユーザー」「主要機能に影響」「管理画面のみ」程度でよいので、すぐ書ける形にします。
D. 監視・バックアップ・切り戻し導線チェック
緊急時に必要なのは、設定の詳細よりも「どこを見て」「どこへ戻せるか」です。
以下はリンク中心で整理します。
- バックアップ：対象／頻度／保持世代／復元手順リンク
- 切り戻し：戻す先（前設定／前リリース）／実行手順リンク
- 緊急時の判断基準：切り戻しを検討する条件（例：復旧見込みが立たない、影響が大きい）
判断基準の例（置けるなら強い）
- 30分以上、復旧見込みが立たない場合は切り戻しを検討する
- 決済／会員など主要機能に影響が出ている場合は、まず復旧を優先する（機能制限も選択肢に含める）
- 顧客承認が必要な場合は、承認者を連絡先に紐づける（Bと接続する）
E. 変更履歴（最小限）：原因特定と切り戻しのため
「いつからおかしいか」が分からないと、原因特定も切り戻し判断も遅れます。
詳細ログを完璧に残す必要はありません。最小限の履歴だけ残します。
- 変更日／変更者／対象
- 変更内容（1行）
- 根拠（チケットURL／依頼URL）
- 戻し先（前設定／前バージョン）
- 影響（あれば）
この履歴があるだけで、「直近の変更に当たりを付ける」「戻し先を迷わない」といった初動が早くなります。
初動10分を維持する：必要情報チェックの更新ルール
チェックは作った直後が最も整っています。更新されないと、緊急時に使えません。
そのため、ルールは「少なく、確実に」を優先します。
1. 変更作業の完了条件に「必要情報チェック更新」を入れる
最も危険なのは、「変更したのにチェックが古い」状態です。
変更作業のDone条件に入れるだけで、更新が作業の一部になります。
- DNSを変えた → DNS欄を更新する
- CDN/WAFのルールを変えた → 管理画面URL・変更履歴・影響範囲を更新する
- 監視通知先を変えた → 通知先と閲覧手順を更新する
2. 月1で“最終更新日だけ”見る
全部見直す運用は継続しません。月1で確認するのは次の2点だけで十分です。
- 最終更新日が古い箇所がないか
- 空欄が減っているか（埋めるべき情報が放置されていないか）
必要があれば、優先順位は「権限・連絡先」から先に更新します。
3. 障害後に1つだけ追記する
再発防止を大きくしすぎると、結局続きません。
障害後は「今回詰まった箇所」を1つだけ改善します。
- 連絡先が分からなかった → 連絡先欄を埋める
- MFAが不明だった → MFAの所在を追記する
- 切り戻し導線がなかった → 戻し先リンクを追記する
小さく直し続けることで、チェックが実務に馴染んでいきます。
よくある失敗と回避
詳細を書きすぎて更新できない → リンクハブにする
チェックは「覚え書き」ではなく「入口」です。
詳細手順や構成図までここに書くと、更新コストが上がり、古くなります。
チェックにはリンクを置き、詳細は別ドキュメント（手順書／構成図／チケット）に逃がします。
作った人しか分からない → オーナー／更新責任者を決める
属人化の原因は「誰が更新するか不明」なことです。
制作会社の体制ではPMがオーナーになりやすいので、最初から割り切って決めた方が運用が安定します。
- オーナー：更新の責任者（必ず1名）
- 代替：不在時に更新する人（兼務でも可）
緊急時に見つからない → 保管場所を固定＋権限設計
緊急時に「どこにあるか」を探している時点で初動が遅れます。
保管場所は1つに固定し、URLを共有し、閲覧権限は必要な範囲で広めに設定します。
- 例：BacklogのWiki固定／Notionの固定ページ／Google Driveの固定フォルダ など
パスワードを直書きして破綻 → 保管場所リンクに統一
パスワードの直書きは「更新されない」「共有しづらい」「管理上のリスクが増える」につながりがちです。
最初から「保管場所リンク」に統一すると、更新負荷が下がり、運用が続きます。
まとめ：探しものを無くせば、初動は10分で動き出す
障害対応が遅れる原因は、技術の前に「探しもの」で初動が止まることです。
初動10分で動けるようにするために、まずは次の順番で整理してください。
- 権限：必要な管理画面に入れる状態を作る
- 連絡先：判断できる人・作業できる窓口に連絡できる状態を作る
- 構成：切り分けの入口と、切り戻しの入口を用意する
全部を完璧に揃える必要はありません。まずは「辿れる導線」を先に整えることが最短で効きます。
コーポレートサイトをクラウドでセキュアに
サーバー管理
クロジカガイドブック
- コーポレートサイト構築・運用の課題を解決
- クロジカサーバー管理の主な機能
- 導入事例
- 導入までの流れ
