WordPress Migration v2 — Rebuild Brief

目標

「移行手順を説明するSkill」から、許可された環境で移行作業を進め、途中状態を保持し、 完了判定または安全なロールバックまで到達する実行型ツールへ変更する。

利用体験

利用者の最初の依頼は、次の情報だけでよい。

• 移行元
• 移行先
• ドメイン変更の有無
• 作業可能時間

不足情報はツール側が読み取り調査で埋める。取得できない認証や外部契約だけを、理由付きで依頼する。

v2の中核

1. Migration Project

1移行につき1つの状態ファイルを作る。

migration-project/
├─ manifest.json
├─ state.json
├─ evidence/
├─ backups/
├─ reports/
└─ logs/

state.json は DISCOVERED / PLANNED / BACKED_UP / COPIED / IMPORTED / REPLACED / VERIFIED / CUTOVER / COMPLETED / ROLLED_BACK / BLOCKED を保持する。

2. Provider Adapter

処理をホスティング固有情報から分離する。

• local-wpcli
• ssh-wpcli
• shared-hosting-manual

Xserver、さくら、ConoHa等は、上のアダプターへ接続情報と制約を渡すプロファイルとして扱う。

3. Executable Phases

• Discover: WordPress・PHP・DB・容量・プラグイン・外部依存を取得
• Plan: 移行型、転送方式、凍結、承認点、ロールバック条件を決定
• Backup: DBとファイルを取得し、サイズ・ハッシュ・復元テストを記録
• Transfer: 再開可能な方式でファイルとDBを移送し、件数・サイズを照合
• Transform: URL置換dry-run、承認後の実行、残存確認
• Verify: HTTP、canonical、robots、noindex、画像、フォーム、ログイン、主要導線を検証
• Cutover: 人間が行うDNS操作に必要な値を提示し、反映後を再検証
• Handover: 完了レポート、残課題、旧環境保持期限、復旧手順を出力

4. Approval Boundary

承認点は「支出・外部公開・外部送信・破壊的変更」に限定する。 読み取り調査、ローカル生成、dry-run、ハッシュ照合、レポート作成で逐一止めない。

完成判定シナリオ

最低でも次を実環境で完走する。

1. 同一ドメインのサーバー移行
2. サーバー＋ドメイン変更
3. WP-CLIなし共有サーバーからの移行
4. URL置換dry-run不一致で安全停止
5. 移行後検証FAILからロールバック

各シナリオで、作業者が手で組み立てたコマンドではなく、同じ実行エンジンが状態を更新すること。

今回捨てるもの

• 長い手順書を完成品と呼ぶこと
• 文字列検査だけで「移行テスト済み」と表現すること
• ホスティング別の説明ページを増やして進捗にすること
• 実行できない環境で承認だけを往復させること