こんにちは。WordPressの深淵へようこそ。
今日は、多くの開発者が「なんとなく」触れているけれど、いざという時に地獄を見ることになる「データベースのID衝突」というテーマでお話しします。
複数のサイトを統合する際、「そのままSQLをダンプしてインポートすればいいや」と考えていませんか？ それがまさに、データの整合性を崩壊させる第一歩です。今日は、WordPressのデータベース構造を物理レイヤーから掌握し、安全に移行を完了させるための「極意」を授けます。
—
1. なぜIDが衝突するのか？（物理構造の理解）
WordPressのデータベースにおける `wp_posts` テーブルは、すべてのコンテンツの「ハブ」です。投稿、固定ページ、メディア、さらにはカスタム投稿タイプまで、すべてがここを起点に管理されています。
ここで重要なのは、`ID` カラムが `BIGINT(20) UNSIGNED AUTO_INCREMENT` であるという点です。
- 何が起きるのか: Aサイトの「ID:100」の記事と、Bサイトの「ID:100」の記事が存在する場合、単純にインポートすると後から入れたデータが既存のデータを上書きするか、外部キー（`wp_postmeta` や `wp_term_relationships`）との紐付けが完全に狂います。
- 整合性の崩壊: `post_id` 100 に紐付いていたメタデータが、意図しない新しい記事（あるいは古い記事）と結びついてしまう。これが、移行後に「画像が表示されない」「カスタムフィールドの値が消えた」という怪現象の正体です。
—
2. 移行の黄金律：「擬似外部キー」をどう維持するか
WordPressには、RDBMSレベルでの厳密な外部キー制約（Foreign Key Constraint）がありません。その代わり、アプリケーション層で ID を介してリレーションを維持しています。
移行を成功させるための戦略は、「ソース側の ID を一度オフセットして退避させ、移行先で再割り当てする」ことです。
推奨される移行手順のイメージ
1. エクスポート: 各レコードの `post_id` を保持しつつ、関連する `meta_key` や `term_id` もセットでエクスポートする。
2. インポート（スクリプト処理）:
- 直接 SQL を流し込むのではなく、`wp_insert_post()` を活用する。
- これを使えば、WordPress が自動的に新しいユニークIDを発行し、同時に `postmeta` も整合性を保ったまま再構築してくれます。
—
3. 実践：ID衝突を回避する移行ロジック
WP-CLI を使ったスクリプトが最も安全です。`wp_insert_post` を使えば、古いIDとの紐付けを保持したまま、新しい環境に馴染ませることができます。
/
- 外部の投稿データを安全にインポートするロジック例
/
function migrate_post_safely($external_post_data) {
// 1. 新しい投稿を作成し、新しいIDを取得
$new_id = wp_insert_post([
‘post_title’ => $external_post_data[‘title’],
‘post_content’ => $external_post_data[‘content’],
‘post_status’ => ‘publish’,
‘post_type’ => ‘post’
]);
if ($new_id && !is_wp_error($new_id)) {
// 2. メタデータの移行：ここでIDの整合性を保つ
// wp_insert_post が発行した $new_id を使うのがポイント！
foreach ($external_post_data[‘meta’] as $key => $value) {
update_post_meta($new_id, $key, $value);
}
return “成功: 新ID {$new_id} でインポート完了”;
}
return “失敗: エラーが発生しました”;
}
陥りやすい罠（ここを注意！）
- `wp_postmeta` を直接 SQL でいじらない: よくある間違いが `INSERT INTO wp_postmeta …` を直接叩くことですが、これは `meta_id` の重複やシーケンスのズレを招きます。必ず WordPress の抽象化レイヤー（`update_post_meta` など）を通してください。
- メディアファイルのパス: `post_content` 内にある画像パスが古いドメインのままになっていませんか？ `WP_Rewrite` や `Search Replace DB` ツールを使って、インポート後に文字列置換を行うのを忘れないようにしましょう。
—
4. 最後に：なぜ「ツール」ではなく「理解」なのか
WordPressは単なるブログツールではなく、巨大なリレーショナルデータ構造を持つCMSです。
移行時にIDが衝突するのは、あなたが悪いのではなく、「WordPressがIDをリレーションの鍵として使っているから」です。この構造を理解していれば、SQLを直接編集するリスクを避け、WP-CLI や `wp_insert_post` といった「コアが用意した正しい手段」で安全に橋を架けることができます。
ここをクリアできれば、あなたはもう WordPress のデータベース構造を恐れる必要はありません。大規模なサイト移行も、複雑なデータ統合も、すべてあなたの支配下に置くことができるはずです。
何か分からないことがあれば、いつでも聞いてくださいね。エンジニアとして、あなたの成長を心から応援しています。