こんにちは！WordPressの内部構造やデータベースの深部までを語り出すと、ついつい熱くなってしまう先輩フルスタックエンジニアです。
他のプログラミング言語や一般的なWebアプリケーションからWordPressに入った開発者の多くが、最初に直面する大きな壁――それが「複数のWordPressインスタンスの統合（データマージ）」ですよね。
「古いブログのデータを新しいサイトにごっそり移したい」「複数の子サイトをメインサイトにまとめたい」そんな時、単純にデータベースをエクスポートしてインポートするだけでは、データが完全に壊れてしまいます。なぜなら、WordPressのデータベースには、リレーショナルデータベース特有の「隠された罠」が潜んでいるからです。
ここをしっかりとクリアできれば、あなたももうWordPressのデータベース構造を恐れる必要はありません。今日は、ID衝突と外部キー（メタ）の整合性を完全に守りながら安全にデータをマージする極意を、優しく紐解いていきましょう！
—
1. なぜWordPressのデータ統合は難しいのか？
まず、WordPressのデータベーススキーマの基本を思い出してください。記事本体を管理する `wp_posts` テーブルと、その記事に紐づくカスタムフィールドやメタデータを管理する `wp_postmeta` テーブルがありますよね。
これらは、次のような関係（リレーション）で結ばれています。
[ wp_posts テーブル ] [ wp_postmeta テーブル ]
+—-+—————-+ +————+———+———–+————+
ニ ID | post_title | <---(1対多)---> | meta_id | post_id | meta_key | meta_value |
+—-+—————-+ +————+———+———–+————+
1 | Hello World | 101 | 1 | _edit_lock | 16000… |
2 | 2つ目の記事 | 102 | 2 | _wp_page | template |
+—-+—————-+ +————+———+———–+————+
ここで問題になるのが、「IDの自動採番（AUTO_INCREMENT）」です。
移行元のサイト（Site A）と、移行先のサイト（Site B）で、それぞれ独立して記事が作られてきたため、両方のデータベースに `ID = 1` や `ID = 2` の記事が偶然にも存在しています。
この状態でSite Aの `wp_posts` をSite Bにそのままインポートするとどうなるでしょうか？
既存のIDと衝突（コンフリクト）を起こすか、上書きされてしまい、`wp_postmeta` に記録されていた `post_id` との紐づけが完全に崩壊してしまいます。結果として、カスタムフィールドが消えたり、全く関係ない記事のメタデータが結びついてしまったりする大惨事になるのです。
—
2. IDオフセット（ずらし）という基本戦略
この衝突を防ぐための最も手堅いアプローチが、「IDオフセット（ID Shift）」です。
これは非常にシンプルで、移行元データのすべてのIDに「移行先サイトの最大ID」を足して、番号がかぶらないようにあらかじめスライドさせてからインポートするという手法です。
例えば、
- 移行先（Site B）の現在の最大投稿IDが `500` だとします。
- 移行元（Site A）の投稿IDに `1000` という「オフセット値」をすべて足し算します。
- これにより、移行元データの `ID: 1` は `ID: 1001` になり、IDの衝突が完全に回避されます。
ただし、ここで忘れてはいけないのが、`wp_postmeta` や `wp_term_relationships` などの関連テーブルにある「親を指すID（外部キー的役割を持つカラム）」も、同じオフセット値で一斉に書き換える必要があるという点です。
—
3. 実践！安全なデータマージを行うためのSQLスクリプト
それでは、実際にデータベース上でどのようにデータを調整すべきか、安全なマイグレーション手順をコードで見ていきましょう。
以下のSQLは、移行元データのIDを安全にシフトさせるための処理の流れです。
— 事前準備：移行元データを「別名の作業用テーブル」としてコピーしておきます
CREATE TABLE wp_posts_migration LIKE wp_posts;
INSERT INTO wp_posts_migration SELECT FROM wp_posts_source;
CREATE TABLE wp_postmeta_migration LIKE wp_postmeta;
INSERT INTO wp_postmeta_migration SELECT FROM wp_postmeta_source;
— 1. オフセット値を変数として定義します（例：10000を足すと仮定）
SET @offset = 10000;
— 2. wp_posts_migration の ID を一斉にシフトさせます
— 既存のIDに @offset を足し算します
UPDATE wp_posts_migration
SET ID = ID + @offset;
— 3. 【最重要】wp_postmeta_migration の紐づけ先（post_id）も同じオフセットでシフトさせます！
— ここを忘れると、メタデータが路頭に迷うことになります。
UPDATE wp_postmeta_migration
SET post_id = post_id + @offset;
— 4. これで整合性が保たれたので、本番の wp_posts と wp_postmeta にデータを合流させます
INSERT INTO wp_posts SELECT FROM wp_posts_migration;
INSERT INTO wp_postmeta SELECT FROM wp_postmeta_migration;
— 5. お掃除（作業用テーブルの削除）
DROP TABLE wp_posts_migration;
DROP TABLE wp_postmeta_migration;
コードの解説と注意点
- 作業用テーブルの活用: 本番データを直接いじるのは御法度です。必ず別テーブル（`_migration` など）に複製してから安全に計算を行いましょう。
- 対になるキーの同時更新: `wp_posts` の `ID` を変えたら、`wp_postmeta` の `post_id` も全く同じ数値を足す必要があります。これがズレると、WordPressが裏側でデータを読み込めなくなります。
—
4. 陥りやすい文法エラーと落とし穴
データベースを移行する際、初学者がよくやってしまう失敗パターンがいくつかあります。あらかじめ知っておけば怖くありませんよ。
落とし穴 1: リビジョンや添付ファイル（attachment）のIDを巻き込んでしまう
`wp_posts` には、公開記事だけでなく「リビジョン（下書きの履歴）」や「画像などの添付ファイル」も含まれています。これらも含めて適当にオフセットをかけると、親記事とリビジョンの紐づけ（`post_parent`）が狂うことがあります。
移行する際は、`post_type = ‘post’` や `post_type = ‘page’` のように対象を明確に絞るのがプロの技です。
落とし穴 2: シリアライズされたデータ（Serialized Data）の存在
WordPressのデータベースの深層では、`wp_options` や `wp_postmeta` の中に、配列データがそのまま文字列として保存されている（シリアライズされている）ケースがあります。
もし、記事の本文中やカスタムフィールドの値の中に、「他の投稿IDへのリンク（例: `?p=123`）」や、ウィジェットの設定などが含まれている場合、単にIDをずらしただけではリンク切れを起こしてしまいます。
複雑なサイト統合では、単純なSQLだけでなく、PHP側で `maybe_unserialize()` を使ってデータを安全に書き換えるスクリプトを書く必要があることも覚えておいてくださいね。
—
まとめ：ここをクリアすればWordPressマスターへの道が開けます！
今回は、WordPressのデータベース構造の裏側を覗きながら、ID衝突と外部キーの整合性を守るためのデータ移行術を解説しました。
1. ID衝突の本質: テーブル同士がリレーション（関係性）で結ばれているため、片方だけIDを変えるとリンクが壊れる。
2. 解決策の基本: オフセット（ずらし値）を計算し、`wp_posts` の `ID` と `wp_postmeta` の `post_id` を同時に同じ値だけ操作する。
3. 安全第一: 必ず作業用テーブルを作り、本番環境へ影響を与えない状態でテストを重ねる。
一見すると難しそうに見えるデータベースの移行作業も、構造の本質さえ理解してしまえば怖くありません。このポイントをしっかりとクリアできたあなたなら、もう中級者から一歩抜け出した確かな実力を持っていますよ！
分からないところがあれば、いつでも気軽に質問してくださいね。応援しています！