WordPress大規模統合の罠：`wp_posts` ID再採番と、失われた整合性を完全に保つためのデータベースアーキテクチャ
開発プロジェクトのテクニカルリードとして、私は数々のサイト統合案件を見てきた。その中で最も頻発し、そして最もエンジニアのキャリアを揺るがす致命傷となるのが、
「複数WordPress環境の統合時におけるID衝突と、リレーションの崩壊」だ。
素人がやりがちなのは、SQLダンプをとってプライマリーキー（`ID`）を力技でずらし、`wp_postmeta`や`wp_term_relationships`をExcelやその場のノリのスクリプトで書き換えるアプローチだ。本番環境でこれを実行した瞬間、カスタムフィールドの紐付けが吹き飛び、ビジュアルビルダーのJSONシリアライズデータが破損し、内部リンクは404の嵐と化す。
WordPressのデータベース構造、特にメタデータやタームの紐付けは、リレーショナルデータベースとしては非常にシンプルだが、それゆえに
「アプリケーション層（PHP）とデータベース層の暗黙の依存関係」を見落とすと容易に破綻する。
今回は、数百万レコードを抱える大規模サイトの統合において、ID再採番と外部キー整合性を1ビットの狂いもなく完全維持するための実践的なアーキテクチャと、プロダクション品質の移行スクリプトを解説する。
—
1. WordPressデータベーススキーマの急所を見抜け
まず、統合対象となるテーブル群の関係性を物理レベルで把握する必要がある。WordPressには厳格な外部キー制約（Foreign Key Constraints）が
標準では存在しない。マイグレーションの安全性を担保するのは、DBエンジンではなく
「お前のコードの正確性」だけだ。
- `wp_posts` (`ID` bigint)
- `wp_postmeta` (`post_id` bigint) -> `wp_posts.ID`
- `wp_term_relationships` (`object_id` bigint) -> `wp_posts.ID`
- `wp_posts` (`post_parent` bigint) -> 自身の `wp_posts.ID` (階層構造)
さらに厄介なのが、
シリアライズされたデータ（Serialized Data）や
JSONデータの中に投稿IDやパーマリンクがハードコードされているケースだ。特にAdvanced Custom Fields (ACF) や Gutenbergのブロックエディタ（`
