夜の10時、Slackに「サイトが表示されません」の通知。慌ててアクセスすると確かに繋がらない。保守会社に連絡しても「まずは調査から」。クライアントからは「いつ復旧しますか？」のメールが届く。
こんな状況、経験ありませんか？
障害が起きた瞬間、現場は一気に非常時モードになります。ただ、多くのケースで本当に詰まるのは、原因究明や高度な調査の前にある「復旧」です。
バックアップがあるのに戻せない。戻す手順がない。必要な権限に入れない。そもそも連絡がつかない。判断する人がいない。
こうなると、制作会社のディレクター/PMは技術の責任者ではないのに、状況整理・連絡・社内説明・意思決定の促進まで背負うことになります。
このとき厄介なのが、「誰が何を決めるのか」「何を復旧と呼ぶのか」「どこまで戻せれば一旦OKなのか」が曖昧だと、時間だけが溶けていく点です。
この記事では、障害時に止まる典型ポイントを「手順・権限・連絡」に分解し、提案前／引き継ぎ時／障害後に使えるチェックリストとしてまとめます。
なぜ「バックアップがあるのに復旧できない」が起きるのか
復旧で詰む3大原因：手順・権限・連絡
バックアップは「材料」であって、「戻せる状態」を保証しません。現場で起きる「復旧できない」は、だいたい次の3つに集約されます。
① 手順がない（または曖昧）
どこから・何を・どの順番で戻すのか。復元対象（DB/ファイル/設定）や復元先、検証方法、切り戻し判断が決まっていない状態です。「前任者なら分かる」「保守会社がやってくれるはず」になっていると、障害時に誰も復旧手順を確定できず、結果として復旧作業（切り戻し／復元）が着手できません。
よくあるのは、バックアップから戻したのに、キャッシュやDNSの影響でユーザーからは復旧していないように見えるケース。こうなると「復旧したのか、してないのか」の判断すら難しくなります。
② 権限がない（または権限が偏っている）
クラウド、サーバー、CMS、監視、WAF、CDN、DNS、SSL…復旧に必要な場所へ入れない状態です。MFA（多要素認証）が担当者のスマホに紐付いていて詰まるのも定番です。技術的にできるか以前に、入れなければ実行できません。
出張中・退職・端末変更などで、緊急時にMFAが通らないだけで復旧が止まります。「管理者のスマホが手元にない」だけで、何もできなくなるケースも珍しくありません。
③ 連絡がつながらない（または連絡が迷子）
誰に、どの手段で、どの順番で連絡するかが決まっていない状態です。夜間休日はどうするのか、一次報告に何を書くのかも曖昧。連絡が散ると、復旧より先に「状況整理」が仕事になります。
「今どこまで進んでいますか？」の確認が増えるほど、復旧そのものの手が止まります。
この3つの要因が揃うと、障害対応は「技術課題」ではなく「運用課題」になります。そして運用課題は、火が出てから整備できません。
「復旧」の定義を3段階に分ける
もう1つ見落とされがちなのが、「どの状態を『復旧』と呼ぶか」です。ここが曖昧だと、復旧作業が「終わらない」か、「終わったことにできない」状態になります。
おすすめは、復旧を3段階に分けて事前に合意することです。
① 暫定復旧（一次復旧）：まず主要導線を戻す
例：トップ表示、購入、ログイン、問い合わせなど。
完璧さより「止血」を優先し、表示は戻ったが一部機能が不安定でもOKとするラインを決めます。「重要ページだけ先に戻す」という合意があるだけで、一次報告と優先順位付けがブレなくなります。
② 完全復旧：通常運用に戻す
機能／性能／監視／バックアップまで含めて、平常時と同じ運用状態に戻す段階です。目安として、ユーザー影響が止まり、平常運用に戻った時点で復旧完了とします。表示は戻ったが監視が機能していない／バックアップが失敗したまま、といった状態は、次の事故の温床になります。
③ 恒久対応（再発防止）：原因分析、設定改善、運用の見直し
復旧完了後に、原因分析と再発防止（設定改善・運用見直し）を別タスクとして切り出します。原因分析・再発防止を復旧対応と同時並行にすると復旧のゴールがぶれやすいため、まずは復旧を収束させ、恒久対応は担当と期限を切って進める方が混乱が減ります。
この3段階が決まるだけで、「一次報告に何を書くか」「どこまでやったら一旦落ち着けるか」が明確になり、社内外の説明も楽になります。
制作会社が巻き込まれる典型パターン
判断者が決まっておらず初動が止まる
障害時は「誰がGOを出すか」が決まっていないと対応が止まります。とくに止まりやすいのは次の3つです。
- 復旧開始の判断（緊急対応を始めるか）
- 切り戻しの判断（直すか、戻すか）
- 公開/非公開の判断（告知・一時停止を含む）
制作会社は「作業担当」でも「決裁者」でもないことが多いのに、判断材料だけ集め続ける役になりがちです。「確認します」が増えるほど、現場の判断が遅れ、復旧までの時間が伸びていきます。
関係者間で情報が散り、状況整理に時間が溶ける
Slack、メール、電話、チャット、Backlog、スプレッドシート…情報が散ると、復旧より先に「状況整理」が仕事になります。
最低限、次の4点が1本に集約されていないと、初動が簡単に30分〜1時間遅れます。
- いま何が起きているか（症状）
- 何をしたか（対応履歴）
- 何が分かっている/分かっていないか（仮説）
- 次に誰が何をするか（アクション）
ここが揃うだけで、関係者は「同じ地図」を見て動けるようになります。揃っていない場合、同じ質問への回答、状況の転記、認識合わせの往復が発生し、復旧の実作業が止まります。
復旧後の報告が属人化し、信頼を落とす
復旧後の報告が属人化すると、「いつも同じ人が書く」「その人しか経緯を追えない」状態になります。結果として、制作会社側の特定メンバーに事実確認と文面調整が集中し、復旧後も対応が長引きます。さらに、報告の粒度や形式が人によってブレると、内容が雑に見えて信頼を落とします。
この対策として有効なのが、復旧報告のテンプレ化です。テンプレは、報告の粒度と順序を固定し、誰が書いても一定品質にするための“型”です。これがあるだけで、報告が特定の人に依存しにくくなり、抜け漏れや表現のブレも抑えられます。
最低限、次の項目をテンプレに入れておくと、報告の品質が安定します。
- いつ何が起きたか（時系列）
- 影響範囲（誰に何が起きたか）
- 一次対応で何をしたか（暫定対応）
- 次に何をするか（恒久対応の方針と期限感）
テンプレを用意しておくと、情報収集と文面作成の手戻りが減り、復旧後のやり取りも短くできます。
復旧の抜けを防ぐチェックリスト10項目
チェックリストの使い方
このチェックリストは「契約書のレビュー」ではなく、障害対応で止まりやすい“運用上の抜け”を事前に見える化するための棚卸しとして使います。10項目を「今の状態で、できるか／できないか」でチェックし、チェックが付かなかった項目を優先して埋めていきます。
使うタイミングは、次の3つです。
- 提案前：運用の前提をそろえ、見積もりや体制の認識ズレを減らす
（例：「夜間・休日は誰が対応しますか？」が後から論点になる状況を避けられます） - 運用引き継ぎ時：担当変更・外注切替・納品後の混乱を減らす
（例：納品後に「その前提は聞いていません」と認識がズレる場面が起きやすいタイミングです） - 障害後の見直し：実際に止まった箇所を整理し、次回に持ち越さないようにする
（障害発生直後は、何が足りなかったかが最も具体的に分かるため、更新のタイミングとして有効です）
【時間がない方向け】まず最短でやるなら、この3つから着手
- ② 一次連絡先（24/365・手段も含む）
- ⑦ 復旧に必要な権限・アカウント（MFA含む）
- ⑤ 切り戻し手順（判断基準と手順）
この3つを先にそろえるだけでも、初動停止のリスクを大きく下げられます。余裕があれば、残りの7項目も順に確認してください。
10項目のチェックリスト
① 緊急復旧（最悪の事態）の定義が合意されている
「緊急」を決めるのは、深夜に誰を起こすかではなく、復旧対応を“今すぐ開始する条件”を揃えるためです。
最低限、次をセットで明文化します。
- 緊急の条件（例：トップ表示不可／決済不可／ログイン不可／改ざん疑い／情報漏えい疑い など）
- 条件ごとの連絡先と順番（誰に最初に、次に誰へ）
- 最初の指示（「暫定復旧を優先」「切り戻し判断を先に」など）
これがないと、発生直後に「緊急かどうか」「誰に連絡するか」でやり取りが往復し、復旧作業の開始が遅れます。
② 一次連絡先が決まっている（24/365・手段も含む）
必要なのは「担当者名」ではなく、**24/365で確実につながる“連絡ルート”**です。最低限ここまで決めます。
- 窓口（連絡先）：個人名ではなく、一次窓口（当番・代表・受付）を用意する
- 連絡手段：電話／チャット／メールの優先順位（緊急時の主手段を固定）
- 不通時の代替：◯分反応がなければ次へ（代替先・代替手段）
- 連絡時に渡す情報：状況・影響・直近変更などのテンプレ項目
これがないと「誰に連絡したか／つながっているか」の確認で時間が消え、一次報告の遅れ＝不安の増幅につながります。
③ 判断者（復旧開始のGOサイン）が決まっている（代替含む）
止まるポイントは作業ではなく、“着手してよいか”の確認です。ここは役割で固定します。
- 復旧開始の判断者（緊急対応を開始してよい人）
- 切り戻しの判断者（直す／戻すの選択を決める人）
- 不在時の代替（副判断者、連絡不能時の扱い）
- 判断に必要な情報（影響・復旧見込み・切り戻し所要時間 など）
これが決まっていないと、現場は「進めていいか」を確認し続ける状態になり、復旧そのものが始まりません。
④ 復旧の目標時間がある（一次報告／暫定／完全の目安）
目標時間は“約束”ではなく、報告の節目（更新タイミング）を決めるための基準です。最低限この3つを置きます。
- 一次報告の目安：発生から◯分以内に「状況・影響・次の更新時刻」を出す
- 暫定復旧の目安：ユーザー影響を止めるまでの目安
- 完全復旧の目安：通常運転（監視・バックアップ含む）までの目安
これがないと報告が「調査中」で止まり、問い合わせが「いつまで？」一本になります。
目安があると、コミュニケーションが「いつまで？」から**「次の更新はいつ？」に切り替わり**、復旧作業に集中できます。
⑤ 切り戻し手順がある（変更時の戻し方・判断基準）
切り戻しは“できるか”ではなく、いつ戻すか／どう戻すかが決まっているかです。最低限を文章で残します。
- 切り戻す条件（判断基準）：例）停止が◯分超／決済不可／広範囲で再現／暫定復旧が見込めない
- 切り戻し手順：誰が、どこで、何を戻し、所要時間はどれくらいか
- 切り戻し後の確認：何がOKなら暫定復旧と判定するか
これがないと、障害時に「直す／戻す」の議論が先に立ち、方針決定だけで時間が溶けます。
⑥ 復元手順がある（取得ではなく「戻す」手順）
バックアップは「ある」だけでは意味がなく、戻す手順・戻す対象・戻した後の判定が揃って初めて使えます。
- 復元対象：DB／ファイル／設定のどこを戻すか
- 復元先：本番へ直接か、検証環境へ復元して確認してからか
- 選ぶバックアップ：どの時点を使うか（判断基準）
- 復元後の判定：何がOKなら暫定／完全復旧とするか
これがないと、発生時に「どれを戻す？」「どの時点？」が決められず、復旧作業が開始できません。
⑦ 復旧に必要な権限・アカウントが揃っている
権限は「アカウントがあるか」ではなく、障害対応の初動に必要な操作を“自分たちで実行できるか”で判断します。
たとえば次の作業が、担当者不在でも実行できる状態です。
- 監視アラート／ログの確認（原因の切り分けに必要）
- サーバー／クラウド側の基本操作（再起動、設定反映、リソース変更など）
- バックアップの復元実行と、復元後の確認（復旧判定まで含む）
よくある落とし穴は、管理者権限やMFAが特定の1人に集中していたり、緊急時に“どの画面に誰が入れるか”が整理されていないことです。
この状態だと、対処方針が決まっていても操作できず、復旧の開始が遅れます。
⑧ DNS／SSL／CDNの操作が担当不在でもできる状態である
DNS／SSL／CDNは“入口”の設定です。ここを触れないと、障害時に次のような暫定対応ができません。
- 別環境への切り替え（フェイルオーバー／退避先への向け替え）
- 一時的な迂回設定（特定パスの遮断、静的ページへの切替など）
- 証明書まわりの復旧（期限切れ・更新漏れ・誤設定の修正）
その結果、アプリやサーバー側は直せていても、ユーザーからは「まだ見えない／使えない」状態が続きます。
ここは「担当者がいなくても操作できる」状態にするために、管理画面URL、アカウント、権限、最低限の手順をセットで揃えます。
⑨ 原因調査に必要な最低限の情報が取れる（ログ／変更履歴など）
ここは“高度な調査”の話ではなく、復旧後に「説明できる状態」を作るための最低限です。最低限、次が追える状態にします。
- ログ：アクセス／アプリ／OS（最低でも場所と閲覧権限）
- 監視アラート：いつ何が鳴ったか（通知先も含む）
- 直近の変更履歴：何をいつ誰が変えたか（粒度は粗くてOK）
これが取れないと、復旧後に「原因不明」で終わり、次回も同じ形で燃えます。
また、説明が詰まると、制作会社側は関係者へ聞き取りを繰り返すことになり、復旧後の工数が膨らみます。
⑩ 一次報告・復旧報告のテンプレがある
テンプレの目的は“文章を楽にする”ではなく、報告品質を標準化して、情報収集と承認の往復を減らすことです。最低限、2種類を用意します。
- 一次報告テンプレ：症状／影響／暫定対応の方針／次の更新時刻
- 復旧報告テンプレ：時系列／原因（暫定で可）／対応内容／再発防止の方針と次アクション
テンプレがないと、報告内容が人によってばらつき、追加質問が増えます。結果として、制作会社側（担当者）は情報を集め直し、文面を作り直す往復が発生し、復旧後の対応が長引きます。
チェック結果の見方：危険度と優先順位
0〜3個：危険 復旧できないリスクが高い
この状態では、障害が起きても**「操作できない／連絡できない／戻せない」**のいずれかで初動が止まり、復旧作業に入れません。改善は次の順で進めます。
- 権限：必要な管理画面に入れないと、確認・切り分け・復元などの作業を開始できません
- 連絡：連絡ルートが確立していないと、判断者や作業者に到達できず、一次報告も出せません
- 手順：戻し方（切り戻し／復元）が決まっていないと、作業に入れても判断が揺れて時間が延びます
4〜6個：要注意 属人化で事故りやすい
平日日中は関係者が揃っていて対応できても、夜間・休日や担当者不在になると確認と判断が往復して初動が遅れます。つまずきやすいのは次の3点です。
- 判断者が曖昧：復旧開始や切り戻しの承認が出ず、作業方針が確定しません
- 切り戻しが未整備：直す／戻すの判断基準がなく、議論が先に立って時間が溶けます
- 入口側の操作権限が不足：暫定復旧の選択肢（切替・迂回）が取れず、ユーザー影響が止まりません
7〜8個：最低限OK ただし夜間休日で詰まりがち
ここまで整っていれば復旧に着手できます。次にやるべきは、決めた内容が古くならない仕組みです。
- 月1回の点検：連絡先／権限／証明書期限など「期限と人に依存する項目」を更新します
- 変更の都度、履歴を残す：いつ・何を・誰が変えたかを1行で残します（チケットやスプレッドシートで十分です）
- 報告テンプレを先に確定する：報告の抜け漏れを減らし、追加質問の往復を減らします
9〜10個：強い 運用設計ができている
運用設計ができていても、事故要因として最後に残りやすいのは次の2点です。
- 変更管理：変更内容が残っていないと、原因特定と切り戻し判断が遅れます
- 定期テスト：復元・切り戻しは「手順がある」だけでは不十分で、実際に動くことを確認する必要があります
年1回でもよいので、机上演習（手順の読み合わせ＋所要時間の見積もり）だけは実施し、手順と連絡ルートが機能する前提を維持します。
復旧に必要な責任分界を決めるポイント
責任分界で決めるべき5つの論点
① 誰が判断するか：復旧開始／切り戻しのGOサイン
判断者が決まっていないと、作業方針が確定せず復旧が始まりません。復旧開始と切り戻しは別の判断として定義し、連絡不能時の代替判断まで決めます。
② 誰が作業するか：実作業と代替要員
担当者が不在でも対応できるよう、代替要員（社内・保守会社・別ベンダー）を前提にします。「1人しか触れない」状態は、障害時に復旧が止まる構造です。
③ 誰が連絡するか：一次報告／エスカレーション
一次報告を誰が出し、どの基準で誰に上げるかを決めます。これがないと制作会社側が窓口を背負い、連絡と説明の往復が増えて復旧作業の時間が削られます。
④ 誰が権限を持つか：アカウント管理／緊急時アクセス
平時の権限管理と緊急時アクセス（MFA・管理者権限）を分けて定義します。緊急時に特定個人の端末が必要な状態は、復旧に着手できない原因になるため最優先で解消します。
⑤ 誰が説明責任を持つか：復旧報告／再発防止
復旧報告と再発防止の責任者を決めると、報告の粒度が揃い、次のアクションが確定します。制作会社が説明責任を単独で抱えないよう、情報の出所と承認者まで明確にします。
責任分界を曖昧にしない「決め方」
「どこまでやりますか？」と聞くと解釈が割れやすいので、成果物（何を、どこに、どの粒度で残すか）で線を引きます。
- 一次報告テンプレを誰が埋め、誰が承認して送るか
- 対応履歴をどこに残すか（チケット／スレッド／台帳）
- 切り戻し判断基準を誰が承認するか
切り戻しの判断基準を文章で残す
口頭だと案件ごとに判断が揺れるため、最低限ここまで文章化します。
- 切り戻す条件：例）停止が30分超／決済不可／広範囲で再現／暫定復旧が見込めない
- 切り戻し手順：誰が、どこで、何を戻し、所要時間はどれくらいか
- 切り戻し後の確認：何がOKなら暫定復旧（一次復旧）と判定するか
既存の保守会社がいる場合の整理の仕方
いきなり「障害対応できますか？」と聞くと、範囲が広すぎて回答が抽象的になります。先に質問を揃えて、判断・作業・連絡・権限・報告を具体化します。
- 判断：復旧開始／切り戻しのGOは誰が出しますか
- 連絡：夜間休日の連絡先はどこですか。反応がない場合の代替手段はありますか
- 権限：触れる範囲はどこですか（クラウド・サーバー・監視など）。緊急時アクセスの手順はありますか
- 切り戻し・復元：手順はありますか。誰が実行し、所要時間の目安はありますか
- 報告：一次報告は誰が、どのフォーマットで、どの頻度で行いますか
回答をもとに、制作会社側で「1枚の運用台帳」に落としておくと、次回の案件でも同じ論点で確認でき、初動が速くなります。
まとめ：今日からできること
まずは10項目で“穴”を洗い出す
復旧は、障害発生後に整備できるものではありません。まずは10項目を並べ、**「復旧に必要な前提が揃っているか」**を可視化してください。可視化できるだけで、提案・引き継ぎ・障害後の会話が「感覚」から「具体」に変わります。
穴が見つかったら、優先順位は「権限→連絡→手順」
改善の最短ルートは次の順です。
- 権限：必要な操作ができないと復旧が始まりません
- 連絡：判断者・作業者に到達できないと意思決定が進みません
- 手順：戻し方（切り戻し／復元）が決まって初めて再現性が出ます
この3つが揃えば、障害対応は「場当たり」ではなく「手順」で進みます。制作会社側が火消しに取られる時間を減らし、次の案件に集中できる状態を作れます。
10項目を関係者（クライアント／保守会社／制作会社）で並べ、穴を埋める順番と担当を決めてください。合意が取れているだけで、次の初動は確実に速くなります。
コーポレートサイトをクラウドでセキュアに
サーバー管理
クロジカガイドブック
- コーポレートサイト構築・運用の課題を解決
- クロジカサーバー管理の主な機能
- 導入事例
- 導入までの流れ
