AGENT VENTURESTUDIO / 01
← CLAUDE-PENGIN-TOOLS
DOCUMENT · 6.7 KB

skills/wordpress-migration/EXAMPLE.md

Workspace snapshot · 09/04 13:33

実行例 / Example session

これは説明用の想定例です。実サイトの作業ログではありません。 実際の出力は環境によって変わります。この例が示したいのは、Skillが起動したときに どの順序で何を確認するかです。

例1: サーバーもドメインも変わる移行（型C）

あなた:

顧客のWordPressを old.example.com から new.example.jp へ、サーバーも変えて移行したい。

Claude（Skill起動後）:

まず移行の型を確定します。ドメインとサーバーの両方が変わるので 型C です。 URL置換が必要で、DNS切替とセットになるため、当日だけでは終わりません。

先に読み取りだけの調査をします。ここでは何も変更しません。

wp core version                    → 6.5.2
wp option get siteurl              → https://old.example.com
wp option get home                 → https://old.example.com
wp option get blog_public          → 1
wp option get permalink_structure  → /%postname%/
wp db prefix                       → wp_
wp db size --human-readable        → 412 MB
du -sh wp-content/uploads          → 6.8 GB
wp config list | grep -i WP_HOME   → （なし）

判断が3つ出ました。

  1. uploads が 6.8GB。 ワンクリック移行プラグインは実行時間・アップロード上限に当たります。 厄介なのは失敗ではなく「途中まで成功して完了扱いになる」ことなので、rsync + wp-cli で進めます。
  2. DBに 412MB。 phpMyAdmin 経由のインポートは避けます。
  3. WP_SITEURL / WP_HOME 定数は未定義。置換がDBに効きます（定義済みだと「置換したのに変わらない」原因になります）。

確認させてください。

  • 移行先のPHPバージョンは現行と揃えられますか（移行とPHP更新は同時にやりません。障害の切り分けができなくなります）
  • コンテンツ凍結できる時間帯はいつですか（ECや会員サイトなら必須です）
  • 旧ドメイン・旧IPに依存している仕組みはありますか（フォームの送信元SPF、決済のIP制限、外部cron、Webhook）
  • DNSの権威はどこですか。レコードを変更できるのは誰ですか

いただけたら、次の順で日程表にします。TTL引き下げは切替の48〜72時間前、SSLの事前発行も切替前で、 どちらも当日では間に合いません。

例2: URL置換の直前（型C・置換フェーズ）

Claude:

置換に入る前に、バックアップの実体を確認します。

wp db export ~/backup/pre-replace-202608211430.sql
ls -l  ~/backup/pre-replace-202608211430.sql   → 431,220,544 bytes
tail -c 200 ~/backup/pre-replace-202608211430.sql   → Dump completed

431MBで末尾まで書けています。復元は wp db import ~/backup/pre-replace-202608211430.sql です。 これが唯一のロールバック手段なので、控えておいてください。

次に dry-run を6形式ぶん流します。この時点でDBは一切変更されません。

wp search-replace "https://old.example.com" "https://new.example.jp" \
  --all-tables-with-prefix --precise --report-changed-only --skip-columns=guid --dry-run
→ 1,284 replacements to be made（wp_posts: 902, wp_postmeta: 311, wp_options: 71）

（http:// → 214件 / //old.example.com → 38件 / JSONエスケープ形 3パス → 計 617件）

JSONエスケープ形で617件出ています。ページビルダーがJSONを入れ子で保存しているためで、 ここを飛ばすとレイアウトが後から白紙になる箇所です。

合計 2,153件を置換します。実行すると元に戻せるのは上のダンプからのみです。 このまま実行してよいですか。 承認をもらってから --dry-run を外して同じ順序で流します。

（--precise は全行をPHP側で処理してシリアライズを壊さないため、 --all-tables-with-prefix はプラグインが作った wp_ テーブルを取りこぼさないため、 --skip-columns=guid は guid を書き換えるとRSSが全記事を再配信するためです）

なお、スキーム無しの old.example.com 単体の置換は既定では行いません。 info@old.example.com のようなメールアドレスや本文中の言及まで巻き込むためです。必要ならご相談ください。

例3: 同じドメインのままサーバーだけ引っ越す（型A）

あなた:

ドメインはそのままで、サーバーだけ引っ越します。URL置換もやっておいた方がいいですか？

Claude:

やりません。 型Aなので置換は不要で、やれば事故の確率だけが上がります。

この移行で本当に気をつけるのは別のところです。

  • DNS切替の前に、hosts で自端末だけ新サーバーへ向けて本番URLのまま動作確認する
  • TTL経過中は旧サーバーにも到達し得るので、旧サーバー側で投稿・受注が増えないようにする
  • 旧サーバーは切替後も最低でもTTL経過＋7日残す（巻き戻し先が消えると復旧できません）
  • wp-config.php は移行先の値で作り直す（コピーせず、DB接続情報と $table_prefix を合わせる）

置換が必要になるのは、ドメインが変わる場合（型B・C）、ステージング本番化（型D）、 HTTPS化（型E）だけです。

例4: ステージングを本番にする（型D）

Claude:

型Dで最も損失が大きく、最も気づかれにくい事故は検索避けの残存です。切替後に必ず見ます。

wp option get blog_public        → 0   ← 検索避けが有効。公開なら 1 に戻す
curl -sI https://new.example.jp | grep -i x-robots-tag

X-Robots-Tag はブラウザの画面に出ないので、ヘッダーで確認します。 物理の robots.txt に Disallow: / が残っていないか、SEOプラグイン側の noindex 設定が 別にないかも見ます。ステージング用のBasic認証も外し忘れが多い箇所です。

このSkillがやらないこと

  • DNSレコードの変更、サーバー契約、決済は行いません。利用者本人が実施します。
  • バックアップが取れていない状態では移行を始めません。
  • 破壊的コマンドは、内容と影響範囲を提示して同意を得るまで実行しません。
  • 判断できない状態を「たぶん大丈夫」で通しません。懸念として明示して返します。

MIT License. Provided as-is, without warranty. Part of PENGIN Tools.