月次保守 実行手順（Phase 0〜9）

SKILL.md の正本手順。定期保守（型M1）を想定し、緊急（M2）・長期停滞（M3）の差分を各Phaseに注記する。

目次

Phase 0 作業前の合意 / Phase 1 環境の確定 / Phase 2 状態の記録 / Phase 3 バックアップ / Phase 4 更新候補 / Phase 5 更新 / Phase 6 束ごとの確認 / Phase 7 全体確認 / Phase 8 記録 / Phase 9 後片付け

---

Phase 0. 作業前の合意（作業日の前）

更新は「いつ」「誰が」「何を確認するか」を決めてから始める。ここを飛ばすと、 壊れたときに連絡先が分からず復旧が遅れる。

• 作業時間帯を決める。ECと会員制サイトは営業時間中に更新しない。
• 壊れたときの連絡先と、判断できる人を確認する。
• ステージング環境の有無を確認する。無い場合、無いという事実を伝えてから進む。
• 更新後に確認してもらう項目（フォーム送信、ログイン、決済）と、誰が確認するかを決める。
• 作業内容が「更新」だけか、「PHPバージョン変更」等を含むか確認する。 含む場合は別日程へ分ける。

M3（長期停滞）の場合: ここでステージング必須を伝える。無いまま進めない。 M2（緊急）の場合: 時間帯の制約は緩めてよいが、連絡先の確認は省略しない。

Phase 1. 環境の確定

• WP-CLIが使えるか（wp --version）。無ければ管理画面経路（SKILL.md Step 7）。
• PHPバージョンとWordPressバージョンを控える。
• マルチサイトかどうか。マルチサイトなら --network の考慮が要る。
• キャッシュ系・セキュリティ系プラグインの有無。更新後の確認結果を汚す。

Phase 2. 状態の記録（省略禁止）

SKILL.md Step 2 を実行し、~/wp-maint/<日付>/ へ保存する。

• plugins-before.csv が空でないこと
• themes-before.csv core-version.txt blog_public.txt
• 更新前のトップページのHTTPステータスとバイト数

保存できていない状態で Phase 5 へ進まない。

Phase 3. バックアップと復元可能性

• wp db export が空でなく、末尾まで書けている
• 更新対象のコードアーカイブまたはホスティング側スナップショットを復元できる
• wordpress.org 以外配布のプラグインを cp -a で退避した
• 戻し方を書き出した（references/ROLLBACK.md のどの手順を使うか）
• バックアップの置き場所が公開ディレクトリ配下でないこと
• 保管期限を決めた（DBダンプは個人情報を含む。作業後に残し続けない）

Phase 4. 更新候補の提示

• wp plugin update --all --dry-run / wp theme update --all --dry-run / wp core check-update
• メジャー更新を識別した
• 中核プラグイン（EC・フォーム・会員・ビルダー・キャッシュ・セキュリティ）を識別した
• 戻す手段が無い対象が含まれていないか確認した
• この一覧を利用者へ提示し、束の分け方に同意を得た

M2（緊急）の場合: 対象を該当プラグインだけに絞る。ついでに他も上げない。

Phase 5. 束に分けて更新

順序: コア → 中核以外 → 中核（1つずつ）→ テーマ。

• 各束の実行直前に、変わる内容を提示した
• 束ごとに Phase 6 を挟んだ（まとめて全部やってから確認しない）
• 失敗した束があれば、そこで止めて ROLLBACK.md へ

M3（長期停滞）の場合: 一気に最新まで上げない。中間バージョンを刻む。 特にコアは複数メジャーを飛ばさず、段階的に上げる。

Phase 6. 各束の直後の確認

• トップページが200を返す
• wp core verify-checksums
• 新しいPHPエラーが出ていない（wp-content/debug.log とサーバーのエラーログ）
• 管理画面にログインできる

ここで異常があれば、次の束へ進まずに戻す。

Phase 7. 全体の確認（200を返したまま壊れる箇所）

自動では判定できない。確認できない項目は未確認と記録する。

• 問い合わせフォームの送信 → 受信箱まで届いたか
• 管理画面へのログイン（別ブラウザ / シークレットウィンドウでも）
• ページビルダーの編集画面が開くか
• 決済・カート（ECの場合、テスト注文）
• 会員ログイン（会員制の場合）
• wp option get blog_public が 1 のまま
• 下層ページ 2〜3枚
• 予約投稿・定期処理（wp cron event list が Phase 2 の内容と比べて欠けていない）
• キャッシュをクリアしてから再確認（wp cache flush）

Phase 8. 記録と報告

• diff で「何のバージョンが何から何へ変わったか」を出した
• 確認した項目と結果を書いた
• 未確認の項目を未確認と書いた
• 戻す手順と、バックアップの場所・保管期限を書いた
• 保留した更新があれば、保留した理由を書いた

報告に書いてはいけないもの: DB名、DBユーザー名、パスワード、管理画面のURL（変更している場合）、 バックアップファイルの完全パス。報告はメールやチャットで共有される。

Phase 9. 後片付け

• 一時的に有効化したデバッグ設定（WP_DEBUG 等）を戻した
• 切り分けのために停止したプラグインを、Phase 2 で記録した一覧どおりに戻した
• 作業用ディレクトリの扱いを決めた（保管するなら場所と期限、しないなら削除）
• 戻したプラグインがある場合、その自動更新を停止した（再発防止）
• 次回の保守日と、今回保留した更新の扱いを決めた

---

この手順が守っていること

1. 戻せない状態で更新しない（Phase 2・3）
2. 原因が特定できない形で更新しない（Phase 5の束分け）
3. 確認していないことを確認したと言わない（Phase 7・8）

この3つを外すと、作業量は同じでも保守の価値がなくなる。