BLOGS

WordPressのバージョンアップやプラグインの更新。

やらなければいけないと分かっていても、本番環境でいきなり実行するのは怖いですよね。

「とりあえずローカルで検証しよう」と思い立ったとき、多くの記事ではこう書いてあります。

All-in-One WP Migrationでエクスポートして、Localにインポートするだけ！

でも現実はそう甘くありません。

長年運用してきたサイト、記事数が数千件を超えるメディア、アップロードファイルが積み重なったECサイト。DBが5GBを超えていたら、全量エクスポートは現実的ではありません。

この記事では、「膨大なコンテンツは移さない」という割り切りをしたうえで、管理画面の再現・テーマ・プラグインの動作確認・バージョンアップテストに必要な最小限のデータだけをローカルへ持ってくる手順をご紹介します。

この記事の対象読者

• WordPressの開発・保守を担当しているエンジニア・制作者
• バージョンアップやプラグイン更新をローカルで検証したいが、DBが大きすぎて詰まっている方
• LocalやMAMPを使ったことはあるが、大規模サイトへの応用に悩んでいる方

なぜ全量移行が現実的でないのか

WordPressのDBは、長期運用によって主に以下の理由で肥大化します。

• wp_postsに記事・リビジョン・添付ファイル情報が大量に蓄積される
• wp_postmetaはそれに紐づくメタデータなので、さらにレコード数が多い
• カスタム投稿タイプで記事とは別にデータを大量に持っている場合もある

全量エクスポートを試みると、phpMyAdminがタイムアウトし、移行ファイルが壊れることもあります。

仮に成功したとしても、Localへのインポートに何十分もかかり、ローカル環境が重くなります。

目的を思い出してください。バージョンアップのテストがしたいのであって、全記事を再現したいわけではありません。

必要なのは「管理画面が本番と同じ状態で動く環境」です。そこに絞ってデータを選別しましょう。

全体の流れ

Step 0: 本番ファイルをFTPで取得
Step 1: 管理画面を本番と同じにする（wp_options / wp_users / wp_usermeta）
Step 2: カテゴリ・タグを再現する（wp_terms 系 3テーブル）
Step 3: 記事・メニュー・ACFなどを必要最小限だけ移す（wp_posts / wp_postmeta）

Step 0：本番ファイルをFTPで取得する

まず本番サーバーからWordPressのファイル一式をFTPでダウンロードします。

注意：wp-config.php は不要です。

Localは独自のwp-config.phpを生成するため、本番のものを上書きしてはいけません。

wp-content/uploads/ は容量が大きければスキップして構いません。画像が表示されなくなりますが、バージョンアップのテスト目的なら支障ありません。

ダウンロードしたファイルは、Localでサイトを作成したあとに上書きコピーしてください。

Step 1：管理画面を本番と同じにする

次に、phpMyAdminから以下の3テーブルをエクスポートし、ローカルのDBにインポートします。

これだけで、本番と同じプラグイン構成・テーマが有効な状態の管理画面が再現できます。

インポート後のURL書き換え

インポートが終わったら、wp_options内のURLをローカル用に書き換えます。

LocalのAdminer（またはphpMyAdmin）のSQLタブで以下を実行してください。

UPDATE wp_options SET option_value = 'http://your-site.local' WHERE option_name = 'siteurl';
UPDATE wp_options SET option_value = 'http://your-site.local' WHERE option_name = 'home';

your-site.localの部分はLocalで設定したドメインに合わせてください。

Step 2：カテゴリ・タグを再現する

フロントの表示確認をするなら、カテゴリ・タグの構造も必要です。以下の3テーブルをセットで移します。

この3つはセットで意味をなすため、必ずまとめてエクスポート・インポートしてください。

Step 3：記事・メニュー・ACFを必要最小限だけ移す

ここが肝心の「選別」のステップです。wp_postsをそのまま全量エクスポートするのではなく、まず内訳を確認しましょう。

まず内訳を確認する

SELECT post_type, COUNT(*) as cnt FROM wp_posts GROUP BY post_type ORDER BY cnt DESC;

このSQLを本番phpMyAdminのSQLタブで実行すると、post_typeごとのレコード数が分かります。

attachment（添付ファイル）やrevision（リビジョン）が大量にある場合は移行対象から除外してください。

wp_posts のエクスポート（2回に分ける）

1回目：軽いデータを全件取得（メニュー・ACF・固定ページなど）

SELECT * FROM wp_posts WHERE post_type NOT IN ('attachment', 'revision', 'post_list')

post_listの部分は、自サイトで件数の多いカスタム投稿タイプ名に置き換えてください。

2回目：件数の多い投稿タイプは最新50件だけ取得

SELECT * FROM wp_posts
WHERE post_type = 'post_list' AND post_status = 'publish'
ORDER BY post_date DESC
LIMIT 50

SQLタブで実行後、結果画面の「エクスポート」ボタンからSQLファイルをダウンロードしてください。

wp_postmeta のエクスポート（2回に分ける）

wp_postmetaはwp_postsのIDに紐づくため、同じ条件で絞り込みます。

1回目：軽いデータの分

SELECT * FROM wp_postmeta
WHERE post_id IN (
  SELECT ID FROM wp_posts
  WHERE post_type NOT IN ('attachment', 'revision', 'post_list')
)

2回目：件数の多い投稿タイプの分

MySQL 5.7ではLIMITとサブクエリを組み合わせられないため、JOINで代用します。

SELECT m.* FROM wp_postmeta m
INNER JOIN wp_posts p ON m.post_id = p.ID
WHERE p.post_type = 'post_list'
  AND p.post_status = 'publish'
ORDER BY p.post_date DESC
LIMIT 2500

ローカルへのインポート

Local付属のAdminerを使ってインポートします。

1. 既存データをクリアする

TRUNCATE TABLE wp_posts;
TRUNCATE TABLE wp_postmeta;

2. 1回目のSQLファイルをそのままインポート

3. 2回目のSQLファイルは編集してからインポート

phpMyAdminがSQLを生成するとき、CREATE TABLE文と末尾のALTER TABLE文が含まれていることがあります。

2回目以降のファイルはこれらを削除し、INSERT文だけ残してからインポートしてください。

そのまま実行すると「テーブルが既に存在する」エラーになります。

注意点まとめ

phpMyAdminへのアクセスにはIPアドレス登録が必要

多くのレンタルサーバーでは、phpMyAdminにアクセスできるIPアドレスを管理画面で登録する必要があります。

IPv4だけでなくIPv6も忘れずに登録してください。接続できない場合はIPv6を疑ってみてください。

PHPバージョンの扱いに注意

Localのデフォルトのバージョンが本番より新しい場合、本番では出なかったPHPエラーが発生することがあります。型チェックの厳格化などが原因になりやすいです。

バージョンアップテストの手順としては、

1. まずLocalのPHPを本番と同じバージョンに設定し、現状のベースラインを確認する
2. 問題がないことを確認してから、PHPバージョンを上げてテストする

この順番で進めると、「バージョンアップによる変化」と「環境差異によるエラー」を切り分けやすくなります。

まとめ

「全部移さないと不安」という気持ちはよく分かります。

でも目的がバージョンアップの動作確認なら、全記事は不要です。

このフローで構築したローカル環境は、本番と同じプラグイン・テーマ・設定を持ちながら、インポートの時間もローカルの動作も軽快に保てます。

ローカル環境構築で詰まる時間を減らして、本来の開発・検証に集中してください。

そもそも、この手間はWordPressの宿命かもしれない

今回紹介したフローは、決して難しくはありません。

でも冷静に振り返ると、バージョンを一つ上げるだけのために、これだけの手順が必要だったとも言えます。

FTPでのファイル取得、テーブルの選別、SQLの分割エクスポート、URLの書き換え、PHPバージョンの切り分け……。

これが年に数回、サイトが増えるたびに繰り返されます。

WordPressはその柔軟性ゆえに、運用を続けるほどに複雑さが増していく構造を持っています。

Jamstackアーキテクチャに移行すると、この構造そのものが変わります。

フロントエンドとバックエンドが分離されているため、バージョンアップの影響範囲が限定的で、ローカル環境の再現もシンプルになります。プラグインの依存関係に振り回されることもありません。

「今のWordPressサイトの運用に、じわじわとコストを感じている」という方は、一度Jamstackへの移行を検討してみてください。

TamaTはNext.js・AstroをはじめとするJamstackの構築を得意としており、既存WordPressサイトからの移行実績も持っています。

まずは現状の課題をお聞かせください。

→ お問い合わせはこちら