こんにちは！他の言語やフレームワークからWordPressの世界へ飛び込んできた開発者の皆さん、日々のコーディングお疲れ様です。
今回は、WordPressエンジニアとして避けて通れない、しかしマスターすれば一目置かれる「データベースの深層」についてお話しします。テーマは「複数サイト統合時における、`wp_posts`のID再採番と外部キー整合性の完全維持」です。
「うわ、なんだか難しそうな言葉が並んでいるな…」と思いましたか？大丈夫です。一歩ずつ、データベースの構造とデータ移行の裏側を紐解いていけば、決して怖くありません。ここをクリアすれば、WordPressのデータ構造の本質がバッチリ見えてきますよ。一緒にマスターしていきましょう！
—
なぜWordPressのデータ移行は一筋縄ではいかないのか？
複数のWordPressサイトを1つに統合するプロジェクトを任されたとしましょう。例えば、Aサイトの記事とBサイトの記事を、新しい統合サイトCにまとめたい場合です。
ここで問題になるのが、「プライマリキー（主キー）の衝突」です。
WordPressのデータベースを覗いたことがある方はご存知のとおり、投稿データを管理する `wp_posts` テーブルには、記事ごとに一意のID（`ID`カラム）が振られています。
[Aサイトの wp_posts] [Bサイトの wp_posts]
+—-+————-+ +—-+————-+
| ID | post_title | | ID | post_title |
+—-+————-+ +—-+————-+
| 1 | 挨拶 | | 1 | はじめに |
| 2 | 自己紹介 | | 2 | プロフィール|
+—-+————-+ +—-+————-+
AサイトにもBサイトにも、IDが `1` や `2` の記事が存在していますよね。これをそのまま単純にSQLで合算（`INSERT`）しようとすると、当然「Primary Key重複エラー」が発生して弾かれてしまいます。
だからこそ、Bサイト側のIDをずらす（＝再採番する）必要があるのです。「じゃあ、BサイトのIDに一律で `1000` を足してずらせばいいや！」……本当にそれだけで大丈夫でしょうか？
実は、WordPressのデータ構造はそんなに単純ではありません。ここが、他の汎用フレームワークのDB設計とは大きく異なる、WordPressならではの罠なんです。
—
WordPressデータベースの「人間関係」を理解しよう
WordPressのデータは、`wp_posts` という一つのテーブルだけで完結していません。他のテーブルと見えない糸（外部キーのような関係性）で結ばれています。
主な関係性を図解的に見てみましょう。
[ wp_posts ] (親)
┌────────────┬─────────────┐
│ ID (10) │ post_title │
└─────┬──────┴─────────────┘
│
├─────────────────────────┐ (1対多の紐付け)
▼ ▼
[ wp_postmeta ] [ wp_term_relationships ]
┌────────────┬───────────┐ ┌────────────┬───────────┐
│ meta_id │ 1 │ │ object_id │ 10 │
│ post_id │ 10 (※) │ │ term_tax_id│ 3 │
│ meta_key │ _price │ └────────────┴───────────┘
└────────────┴───────────┘
※ `wp_postmeta` の `post_id` は、`wp_posts` の `ID` を指し示しています。（標準のMySQL設定では物理的な外部キー制約は張られていませんが、論理的な外部キーとして完全に機能しています）
もしあなたが、Bサイトの `wp_posts` のIDを `10` から `1050` に変更したとします。
その時、子である `wp_postmeta` や `wp_term_relationships` の側はどうなるでしょうか？
親のIDだけが変わってしまい、子側が古い `10` を指したままになると、メタデータ（カスタムフィールドの値）やカテゴリ・タグとの紐付けがすべてプツリと切れてしまいます。これが、データ移行でサイトが崩壊する原因の正体です。
—
整合性を完全に維持した移行ロジックの設計
では、どうすればこの「親子関係のズレ」を防ぎながら安全にIDを再採番できるのでしょうか？
大まかなアルゴリズムは以下の通りです。
1. オフセット値（ずらす数）の決定：移行先の `wp_posts` の最大IDを確認し、衝突しない十分な数（例: `+10000` など）を決める。
2. `wp_posts` のIDを更新：新しいIDへ書き換える。
3. 関連テーブル（子）の外部キーを一括置換：`wp_postmeta`, `wp_term_relationships` などの `post_id` (または `object_id`) を、同じオフセット値分だけスライドさせる。
4. コンテンツ内の内部リンク・シリアライズデータの修復：（※これが一番厄介ですが今回は割愛、まずはIDとメタの整合性に集中しましょう！）
実践：安全なID置換を行うPHP/SQLスクリプトの概念
実際の現場では、WP-CLIやカスタムPHPスクリプトを書いて安全にトランザクション処理を行います。以下に、その核心部分のコード例を示します。
/
global $wpdb;
// トランザクション開始（途中でエラーが起きたらすべてロールバックするため）
$wpdb->query( ‘START TRANSACTION’ );
try {
// 1. 移行する古い投稿のIDリストを取得
$old_post_ids = [ 15, 22, 48 ]; // 例として特定のID群
$offset = 10000; // 衝突回避のためのオフセット値
foreach ( $old_post_ids as $old_id ) {
$new_id = $old_id + $offset;
// 2. wp_posts の ID を一時的な値、または直接新しいIDへ更新
// ※PRIMARY KEYを変更する場合、段階的なアプローチが必要です
$wpdb->update(
$wpdb->posts,
[ ‘ID’ => $new_id ],
[ ‘ID’ => $old_id ],
[ ‘%d’ ],
[ ‘%d’ ]
);
// 3. wp_postmeta の post_id を追従させる
$wpdb->query( $wpdb->prepare(
“UPDATE {$wpdb->postmeta} SET post_id = %d WHERE post_id = %d”,
$new_id,
$old_id
) );
// 4. wp_term_relationships の object_id も同様に追従させる
$wpdb->query( $wpdb->prepare(
“UPDATE {$wpdb->term_relationships} SET object_id = %d WHERE object_id = %d”,
$new_id,
$old_id
) );
}
// すべて成功したらコミット
$wpdb->query( ‘COMMIT’ );
echo “データの移行とIDの再採番が正常に完了しました！”;
} catch ( Exception $e ) {
// エラー時は変更をすべてなかったことにする（データの破損を防ぐ防壁）
$wpdb->query( ‘ROLLBACK’ );
echo “エラーが発生したため、処理をロールバックしました: ” . $e->getMessage();
}
—
開発現場でよくある「うっかり文法エラー」と落とし穴
他の言語からWordPressに入った開発者が、やりがちなミスをいくつかピックアップしておきます。ここで先回りして防いでおきましょう！
落とし穴その1：プライマリキーの直接 `UPDATE` でエラーが出る
MySQLの仕様上、AUTO_INCREMENT（自動連番）かつ PRIMARY KEY に指定されているカラムを直接 `UPDATE` しようとすると、一意制約（Unique Constraint）に引っかかって怒られることがあります。
対策：一時的に別の一意な大きな数に逃がすか、あるいは新テーブルへ一度データをコピーしてIDを振り直す「ETL（Extract, Transform, Load）」アプローチをとるのが安全です。
落とし穴その2：トランザクションを忘れる
「とりあえずループでUPDATE文を回せばいいや」と書いてしまい、途中のクエリ（例えばメタデータの更新）でコケた場合、親のIDだけが変わって子は宙ぶらりん（孤児レコード）という、データベースにとって最も最悪な状態が完成します。
対策：必ず `START TRANSACTION` と `COMMIT` / `ROLLBACK` をセットで使い、原子性（Atomicity）を担保しましょう。
落とし穴その3：シリアライズ（Serialized）データの存在を忘れる
今回のコード例では `wp_postmeta` の紐付けIDを直しましたが、メタデータの中身（`meta_value`）自体に、投稿IDや画像IDがシリアライズされた配列として保存されているケースがあります（例：Page Builder系のプラグインや高度なカスタムフィールド）。
IDをずらしただけだと、このシリアライズデータの中にあるIDが古いままになり、レイアウトが崩れたりデータが読み込めなくなったりします。文字列置換の際はシリアライズの構造を壊さない専用の関数やロジックが必要になる点に注意してください。
—
まとめ
今回は、WordPressのデータベースの物理構造の裏側を覗きながら、ID再採番と外部キー整合性の維持について解説しました。
- WordPressのデータは、`wp_posts`（親）とメタやリレーション（子）の「人間関係」で成り立っている。
- IDをずらす時は、必ず関連するテーブル側の外部キー（`post_id`や`object_id`）もセットでスライドさせなければならない。
- DB操作はトランザクションを使って安全性を担保する。
一見複雑に見えるWordPressのデータベースも、内部の構造とリレーションのルールさえつかんでしまえば、怖くありません。むしろ、非常にシンプルで合理的デザインで作られていることに気づくはずです。
ここをクリアできれば、あなたも立派なWordPressアーキテクトへの第一歩を踏み出しています。ぜひ実際の開発や検証環境で試してみてくださいね。応援しています！