宿のホームページが急に表示されない。予約ボタンを押しても進まない。WordPress管理画面に「重大なエラー」と表示された――。営業中に起きると、早く直したい気持ちから、更新、再起動、プラグイン停止を次々に試したくなります。
しかし、障害直後に重要なのは修正の速さだけではありません。宿泊希望者とのつながりを守り、症状を記録し、追加被害を防いでから原因調査へ渡すことです。
この記事では、ITに詳しくない宿主さんがCodexやClaude Codeを補助に使いながら、最初の30分で行う初動対応を時系列で説明します。
結論：最初の30分は「営業を守る・記録する・止める・連絡する」
障害対応の優先順は次のとおりです。
0〜5分 予約・問い合わせの代替経路を確保
5〜10分 症状と発生時刻を記録
10〜20分 追加変更を止め、影響範囲を確認
20〜30分 担当者へ必要情報を渡し、復旧方針を決める
この30分で必ず復旧させるという意味ではありません。焦って原因を増やさず、保守担当者が安全に調べられる状態を作ることが目標です。
0〜5分：予約・問い合わせの入口を守る
最初に確認するのはWordPress管理画面ではなく、お客様が宿へ連絡できるかです。
- 電話がつながるか
- OTAの宿ページと予約受付が動いているか
- 自社予約システムがWordPressとは別に開けるか
- 公式SNSで案内できるか
- 既存予約者へ連絡できるか
WordPressだけが停止し、OTAや外部予約システムが動いているなら、そこを一時的な予約経路として案内できます。逆に、予約システムや決済まで止まっている場合は、空室や料金を推測で案内せず、電話受付後に確認して折り返す運用へ切り替えます。
一時案内の例
現在、公式サイトの表示に不具合が発生しています。
ご予約・お問い合わせは、当面［電話番号／利用できる予約先］をご利用ください。
復旧状況はこの案内でお知らせします。
原因、復旧予定時刻、個人情報流出の有無は、確認前に断定しません。「サイバー攻撃」「データ消失」といった表現も、根拠がない段階では使いません。
5〜10分：画面と時刻を記録する
障害画面は、原因調査の手掛かりです。再読み込みや設定変更で見えなくなる前に記録します。
記録するもの
- 発見日時
- 問題が起きたURL
- パソコン・スマートフォンのどちらか
- Wi-Fi・携帯回線など確認した回線
- 画面に出た短いエラー文と番号
- ログイン中・ログアウト状態の違い
- 直前に行った更新や設定変更
- 最後に正常だった日時
- 予約、問い合わせ、管理画面の状態
スクリーンショットには、管理画面URL、利用者名、メールアドレス、予約番号、ブラウザのタブなどが写ることがあります。社外やAIへ渡す前に必要部分だけ切り出し、秘密情報と個人情報を伏せます。
別の端末でも一度だけ確認する
自分のブラウザだけの問題か、一般のお客様にも起きているかを分けます。
- シークレットウィンドウで開く
- スマートフォンの携帯回線で開く
- 問題のURLを直接開く
何度もフォーム送信や予約操作を繰り返すと、重複問い合わせや仮予約を作る可能性があります。機能テストは、方法を確認してから行います。
10〜20分：追加変更を止め、影響範囲を分ける
次の操作はいったん止めます。
- WordPress・テーマ・プラグインの追加更新
- プラグインの一括停止
- テーマの本番切り替え
- データベースの修復・置換・復元
- サーバーの再起動
- キャッシュ削除と設定変更の同時実行
- エラーを隠すためだけのコード追加
- 古いバックアップやログの削除
すでに始めた作業がある場合は、「何を」「いつ」「どの画面から」実行したかを記録します。途中で強制停止すると別の問題が起きる処理もあるため、状態を保守担当者へ伝えます。
影響範囲を四段階に分ける
| 段階 | 例 | 初動の考え方 |
|---|---|---|
| 一部表示 | 画像や装飾だけ崩れる | 記録し、予約導線を確認して調査 |
| 一部機能 | 予約・フォーム・メニューが動かない | 代替経路を案内して優先調査 |
| サイト全体 | 白画面、重大エラー、500等 | 追加変更を止め、担当者へ連絡 |
| 複数サービス | メール、予約、サーバーも停止 | 契約先の障害情報を含め緊急連絡 |
見た目の崩れはテーマ・プラグイン・キャッシュの切り分けへ進みます。サイト全体が停止している場合は、表示だけの問題と決めつけません。
20〜30分：誰へ何を渡すか決める
サーバーの借り方によって連絡先が異なります。
レンタルサーバー・マネージドWordPress
- サーバー会社の障害・メンテナンス情報を確認
- 管理画面の問い合わせ窓口へ連絡
- 契約者名義とサポート対象を確認
- 復元サービスの有無と対象時点を確認
VPS・クラウド
- WordPress保守担当者またはサーバー管理者へ連絡
- サーバー、Web、PHP、データベースの稼働状況を読み取り確認
- 再起動や復元の前に影響範囲と戻し方を決める
- 予約やメール等、同居サービスへの影響を確認
サーバー会社はWordPress内部の修正を支援しない場合があり、制作会社はサーバー契約へ入れない場合があります。平常時に担当範囲を記録しておくことが重要です。
WordPressのリカバリーモードとは
WordPressは、テーマやプラグイン等で致命的なPHPエラーを検出した場合、管理者メールへリカバリーモード用リンクを送ることがあります。特別な管理セッションで問題の部品を確認できる仕組みです。
メールが届いたら次を確認します。
- 送信先がWordPressに登録した管理者メールか
- URLのドメインが自分のサイトか
- 不審な添付ファイルがないか
- 画面に示されたテーマ・プラグイン名
リカバリーモードはすべての障害で働くわけではなく、恒久修正でもありません。メールが届かないからといって、管理者アドレスを慌てて変更したり、不審なリンクを検索結果から開いたりしないでください。レンタルサーバーや保守担当者へ相談します。
AIに任せるのは状況整理と安全な調査計画
AIが初動で支援できることは次のとおりです。
- 記録内容を時系列へ整理
- 影響を受けるURLと機能の一覧化
- 本番を変更しない確認項目の作成
- 更新履歴と発生時刻の照合
- エラー文から確認先の公式資料を探す
- サーバー会社・保守担当者向け問い合わせ文の作成
- 復旧後の確認チェックリスト作成
- 障害記録のひな型作成
一方、再起動、データベース復元、全プラグイン停止、権限変更、ファイル削除を、障害直後にAIへ一任しません。
コピペで使える初動プロンプト
最初の状況整理
宿のWordPressで障害が起きています。まだ修正しないでください。
発見日時: ［日時］
問題のURL: ［URL］
症状: ［短いエラー・表示状態］
直前の作業: ［更新や設定変更］
現在使える予約経路: ［電話・OTA等］
最初は読み取りと状況整理だけを行い、
営業への影響、確認済みの事実、原因候補、未確認事項、
次に人が確認する項目を分けてください。
更新、停止、再起動、復元、削除、設定変更は実行しないでください。
サポートへの問い合わせ文を作る
次のWordPress障害について、サーバー会社または保守担当者へ送る
問い合わせ文を作ってください。
［発生日時、URL、症状、直前の変更、確認端末、影響機能、実施済み確認］
原因を断定せず、緊急度と希望する確認内容を簡潔に示してください。
パスワード、秘密鍵、内部パス、顧客・予約情報は含めないでください。
復旧案を比較する
読み取り調査で次の事実が確認できました。
［確認できた事実］
まだ実行しないでください。
修正、部品の一時停止、以前の版へ戻す、バックアップ復元について、
影響範囲、失われる可能性があるデータ、所要時間、元へ戻す方法、
復旧後の確認を比較してください。
人の承認が必要な操作を明示してください。
復旧か復元かを急いで決めない
障害前の状態へ戻す方法には複数あります。
- 問題の設定だけ元へ戻す
- 更新したテーマ・プラグインを検証済み版へ戻す
- 原因の部品を一時停止する
- ファイルだけを戻す
- データベースを含めてバックアップから復元する
データベース全体を古い時点へ戻すと、バックアップ取得後の記事、問い合わせ、予約、設定が失われる可能性があります。まず何が壊れ、どこまで戻す必要があるかを確認します。バックアップの状態は復元リハーサルの記事も参考にしてください。
復旧後に確認すること
「トップページが開いた」だけで終了しません。
- パソコンとスマートフォンで主要ページが開く
- 予約ボタンと外部予約先が正しい
- 料金・プラン・空室案内が正しい
- 問い合わせフォームを安全に確認した
- 管理画面へ正規の管理者が入れる
- 画像、CSS、JavaScriptが欠けていない
- メール送信が正常か確認した
- 監視やバックアップが再開している
- 一時案内を復旧案内へ更新した
- 原因、対応、所要時間、再発防止を記録した
更新前後の画面比較にはPlaywrightによる自動比較を利用できます。
平常時に用意する「障害対応カード」
障害時に探し回らないよう、紙または安全な共有場所へ次をまとめます。
- 公開サイトと予約ページのURL
- 電話、OTA、SNSなど代替連絡手段
- レンタルサーバー会社と契約者
- WordPress保守・制作・予約システムの連絡先
- 誰が一時案内を出せるか
- 最後の検証済みバックアップの確認方法
- 障害記録の保存場所
- 再起動・復元・削除を承認できる人
パスワードや秘密鍵をカードへ直接書くのではなく、組織で決めた安全な管理場所への案内だけを記載します。
宿主さん向けチェックリスト
- [ ] 電話・OTA等の代替予約経路を確認した
- [ ] お客様向け一時案内を出した
- [ ] 発生時刻、URL、画面を記録した
- [ ] 別端末・別回線で一度確認した
- [ ] 追加の更新と場当たり的修正を止めた
- [ ] 影響を表示・予約・メール・管理画面に分けた
- [ ] サーバー会社または保守担当者へ連絡した
- [ ] AIには読み取り調査から依頼した
- [ ] 復元前に失われるデータを確認した
- [ ] 復旧後に予約・問い合わせを人が確認した
参考にした公式情報
まとめ
WordPress障害後の最初の30分は、闇雲に直す時間ではありません。お客様の予約・問い合わせ経路を守り、症状を記録し、追加変更を止め、適切な担当者へ情報を渡す時間です。
AIは時系列整理、影響範囲の分類、問い合わせ文、確認表の作成を支援できます。宿主さんは営業上の優先順位、外部案内、変更承認、料金・予約の最終確認を担当します。この役割分担を平常時に決めておけば、障害が起きても「何から始めるか」で迷いにくくなります。
