WordPressの障害が復旧すると、「サイトが戻ってよかった」で作業を終えたくなります。しかし、何が起き、なぜ発見が遅れ、どの対応が役立ったかを残さないと、次の更新で同じ不具合を繰り返す可能性があります。
必要なのは、誰かの失敗を責める反省文ではありません。事実を時系列に並べ、仕組みや手順の弱い部分を見つけ、担当者と期限のある改善へ変える障害振り返りです。
この記事では、CodexやClaude Codeに記録の整理を手伝わせながら、小さな宿でも無理なく再発防止報告書を作る方法を説明します。
結論：報告書は「出来事」ではなく「次の行動」まで書く
最低限、次の六つを残します。
- 何が起きたか
- 宿泊希望者・既存予約・業務へどんな影響があったか
- 発見から復旧まで何をしたか
- 直接原因と、被害を広げた要因は何か
- うまくいった対応と、迷った対応は何か
- 誰が、いつまでに、何を改善するか
「次回は気をつける」で終えると、忙しくなったときに元へ戻ります。改善策には担当者、期限、完了条件を付けます。
どの障害を振り返るか
すべての小さな表示ずれに長い報告書は必要ありません。次のいずれかがあれば、短くても記録を残す価値があります。
- 公式サイトが一定時間開かなかった
- 予約、問い合わせ、決済の一部が使えなかった
- 誤った料金・休館・看板猫情報が表示された
- データの消失または重複があった
- バックアップからの復元や版の巻き戻しを行った
- サーバー会社・制作会社の緊急対応が必要だった
- 監視ではなく、お客様の連絡で初めて気づいた
- 同じ種類の不具合を繰り返した
- 個人情報やアカウントへの影響が疑われた
個人情報漏えいや不正アクセスが疑われる場合は、通常の振り返りだけで済ませず、契約先、専門家、必要な関係機関へ相談します。確認前に「漏えいなし」と断定しません。
振り返りはいつ行うか
サイトが開いただけの段階では、まだ復旧確認中です。予約、問い合わせ、メール、料金、スマートフォン表示を確認し、一時対応が落ち着いてから振り返ります。
目安として次の二段階に分けます。
当日：事実を保存する
- 発生・発見・連絡・復旧の時刻
- 画面、短いエラー、監視結果
- 実行した変更と担当者
- お客様向け案内
- 使ったバックアップや版
- 未確認事項
数日以内：原因と改善を話し合う
- 直接原因
- 発見や復旧が遅れた要因
- 役立った仕組み
- 再発防止策
- 担当者、期限、完了条件
時間が経つほど「たぶんこうだった」という記憶が混ざります。時刻と事実だけは早めに残します。
事実・推測・判断を分ける
AIは、情報が不足していても文章を自然につなげられます。そのため、報告書では内容を明確に分けます。
| 区分 | 例 |
|---|---|
| 事実 | 更新操作後、特定URLが500で応答した |
| 推測 | 更新したプラグインが関係した可能性がある |
| 判断 | 追加更新を止め、以前の版へ戻す方針を選んだ |
| 未確認 | 問い合わせメールへの影響は確認できていない |
「エラーログにプラグイン名があった」ことと、「そのプラグインが根本原因だった」ことも別です。根拠となる検証結果がない場合は、原因候補または未確認と書きます。
宿の障害で記録したい影響
技術者向けの報告書はサーバー停止時間だけに偏りがちですが、宿では営業への影響が重要です。
お客様への影響
- 公式サイトを閲覧できなかった時間
- 予約ボタンを利用できなかった時間
- 誤った料金・空室・休館情報を見た可能性
- 問い合わせが送れなかった可能性
- 既存予約者への案内遅延
宿の業務への影響
- 電話やOTAで代替受付した件数
- 重複予約や折り返し確認の有無
- スタッフが対応に使った時間
- 制作会社・保守会社への緊急依頼
- 復元により失われた可能性がある更新
件数が分からない場合は、推測で数字を作らず「確認できず」と記録します。
「原因」は一つとは限らない
障害には、直接止めた原因のほかに、発見や復旧を難しくした要因があります。
直接原因
- テーマ更新で独自CSSとの互換性が崩れた
- プラグイン更新で致命的エラーが起きた
- 保存容量が不足した
- 設定変更で予約先URLが誤った
寄与要因
- 複数項目を同時に更新した
- 更新前の画面を保存していなかった
- 検証環境がなかった
- バックアップの復元手順を試していなかった
- 監視対象に予約ページが入っていなかった
- サーバー会社と制作会社の担当範囲が不明だった
- 変更記録がなく、直前の作業を特定できなかった
個人の注意力だけを原因にすると、同じ状況で別の人も失敗します。「なぜ、その操作が安全に見えたのか」「仕組みが止められなかったのはなぜか」を考えます。
AIに任せられる振り返り作業
CodexやClaude Codeは次の整理を支援できます。
- メモやログ時刻から時系列表を作る
- 事実・推測・未確認を分類する
- 更新前後の版やファイル差分をまとめる
- 営業影響を項目別に整理する
- 寄与要因を「人」ではなく「仕組み」として言い換える
- 改善案を予防・検知・復旧に分類する
- 担当者と期限が欠けた改善項目を指摘する
- 宿内用と外部説明用の文書を分ける
- 運用手順やAI指示書への追記案を作る
ただし、AIが知らない事実を補わせません。会話記録やログにない時刻、原因、影響件数は「未確認」のままにします。
改善策を三種類に分ける
1. 予防する
- 更新を一項目ずつ行う
- 検証環境で先に試す
- 変更前バックアップと画面を残す
- 親テーマを直接編集しない
- AIの実行権限を限定する
2. 早く発見する
- トップだけでなく予約・問い合わせURLも監視する
- パソコンとスマートフォンの画面差分を確認する
- 更新後のHTTP、description、画像を自動確認する
- 管理者メールの受信状態を点検する
3. 早く戻す
- 代替予約経路を準備する
- 保守担当者と連絡先を明確にする
- バックアップの整合性と復元を試す
- 以前の版へ戻す手順を記録する
- お客様向け一時案内をテンプレート化する
一つの障害から改善案を大量に出すと実行されません。営業への効果と作業量を比較し、まず一〜三件に絞ります。
良い改善項目の書き方
| 曖昧な改善 | 実行できる改善 |
|---|---|
| 更新に注意する | 更新前チェックリストを作り、次回更新から使用する |
| バックアップを確認する | 隔離環境で復元試験を行い、結果を記録する |
| 監視を強化する | 予約ページのHTTP確認を追加し、異常時の連絡先を設定する |
| AIを安全に使う | 更新・削除・再起動を承認制にして指示書へ追記する |
各項目へ次を付けます。
- 担当者
- 期限
- 完了条件
- 確認する人
- 関連する手順書
完了条件は「検討した」ではなく、「手順を作成して一度試した」など確認可能な形にします。
コピペで使えるAIへの依頼文
時系列を作る
次のWordPress障害メモから、復旧後の時系列表を作ってください。
［日時付きメモ、実施した変更、画面記録］
発生、発見、連絡、一時対応、原因調査、復旧、確認に分けてください。
記録にない日時や出来事を補わず、不明は「未確認」としてください。
個人情報、認証情報、内部パスは報告書へ含めないでください。
原因と寄与要因を整理する
次の確認済み事実から、直接原因、寄与要因、未確認事項を整理してください。
［検証結果、更新履歴、エラーの要約］
個人を責める表現を避け、手順、権限、監視、情報、環境の観点で整理してください。
証拠がない原因は断定しないでください。
改善項目へ変える
次の障害振り返りから、再発防止策を作ってください。
［振り返りの要約］
予防、早期発見、早期復旧に分類し、各項目へ
優先度、担当者欄、期限欄、完了条件、確認方法を付けてください。
まず実行する項目を3件以内に絞り、その理由を示してください。
まだサイトやサーバーは変更しないでください。
AI運用ルールへ反映する
この障害から得た安全ルールを、AGENTS.mdまたはCLAUDE.mdへ追記する案にしてください。
既存ルールと重複しないか確認し、通常作業、事前承認、禁止事項、
確認項目のどこへ入れるか示してください。
接続情報、内部パス、実コマンド、顧客情報は含めないでください。
まだファイルは変更せず、差分案だけを提示してください。
報告書のひな型
# 障害の名称
## 概要
- 発生日:
- 復旧確認:
- 影響した機能:
- 営業への影響:
## 時系列
- 時刻 / 確認した事実 / 実施した対応 / 担当
## 原因
- 確認できた直接原因:
- 寄与要因:
- 未確認事項:
## 対応
- うまくいったこと:
- 改善が必要なこと:
## 再発防止
- 改善項目 / 優先度 / 担当 / 期限 / 完了条件
## 関連資料
- 手順書、画面記録、公式資料への安全な参照
顧客名、予約内容、メールアドレス、IPアドレス、パスワード、秘密鍵、管理画面URLなどは、共有範囲に応じて除外または別管理します。公開記事として障害事例を紹介する場合は、さらに内部構成や攻撃へ利用できる情報を外します。
改善策を運用へ戻す
報告書を書くだけでは再発を防げません。改善内容を実際に使う場所へ戻します。
- 月次点検チェックリスト
- WordPress更新手順
- バックアップと復元手順
- 障害対応カード
- サーバー会社・保守会社の連絡先
- Codex用
AGENTS.md - Claude Code用
CLAUDE.md - Playwright等の自動確認
AIとの相談内容を運用ルールへ残す方法はAIとの議論を運用マニュアルに残す方法でも説明しています。
改善が完了したか確認する
一か月後に「期限を過ぎていないか」を見るだけでは不十分です。
- チェックリストを実際の更新で使ったか
- バックアップを別環境へ戻せたか
- 監視が意図した異常を検知できるか
- 代替予約案内をスタッフが出せるか
- 担当者不在でも連絡先が分かるか
- AIが禁止操作を承認なしに提案・実行しないか
可能なら安全な検証環境で小さな訓練を行います。本番サイトを意図的に停止して試してはいけません。
宿主さん向けチェックリスト
- [ ] 復旧確認後、日時付きの事実を保存した
- [ ] お客様と宿の業務への影響を整理した
- [ ] 事実・推測・判断・未確認を分けた
- [ ] 直接原因と寄与要因を分けた
- [ ] 個人を責めず、仕組みと手順を見直した
- [ ] 予防・早期発見・早期復旧の改善案を出した
- [ ] 最初に行う改善を三件以内に絞った
- [ ] 担当者、期限、完了条件を付けた
- [ ] AI運用ルールと手順書へ反映した
- [ ] 後日、改善が実際に使われたか確認した
障害直後の行動はWordPress障害発生後の最初の30分、原因調査はテーマ・プラグイン・キャッシュの切り分け、復元準備はAIと行う復元リハーサルを参照してください。
参考にした情報
まとめ
障害振り返りの目的は、失敗した人を見つけることではありません。確認できた事実と影響を残し、同じ条件でも安全に作業できる仕組みへ変えることです。
AIは時系列の整形、事実と推測の分類、改善案、報告書作成を速くできます。宿主さんは営業への影響、優先順位、担当者、期限、完了条件を決めます。復旧後に一つでも運用を改善できれば、障害対応を単なる損失ではなく、次の安心につながる知識へ変えられます。
