GUIDの呪縛：WordPressデータベース構造における「不変性」の幻想とマルチサイト移行の真実
WordPressのデータベーススキーマを設計した先人たちは、`wp_posts`テーブルに`guid`というカラムを配置した。一見すると「Globally Unique Identifier」の名を冠したこのカラムは、多くの開発者に「投稿のパーマリンクを保持する場所」と誤解されている。
しかし、カーネルレベルの洞察を持つ者ならば即座に理解できるはずだ。GUIDはパーマリンクではない。これは「識別子」の皮を被った「レガシーな参照ポインタ」に過ぎない。
本稿では、マルチサイト環境におけるデータ移行、そしてその裏側に潜む「GUID乖離」のリスクについて、内部構造の観点から深掘りする。
—
1. GUIDの本質的定義とメモリ・ストレージの解釈
`wp_posts.guid`は、RFC 4122で定義されるようなバイナリのUUIDではない。WordPressのコードベースにおけるGUIDは、単なる`varchar(255)`の文字列であり、デフォルトではサイトのホームURLに投稿IDを結合した文字列が格納される。
なぜこれが危険なのか？
WordPressのコアロジックにおいて、`get_permalink()`や`get_the_guid()`は、以下の挙動を示す。
- `get_permalink()`: `wp_rewrite`オブジェクトを介し、現在のパーマリンク設定に基づいて動的に再構築される。
- `get_the_guid()`: 単にデータベースの`guid`カラムをフェッチする。
この「動的な生成」と「静的な保存」の二重構造こそが、マルチサイト移行時の地雷となる。移行時にドメインを書き換えた際、`wp_options`の`siteurl`は更新されるが、`wp_posts.guid`は追従しない。結果として、RSSフィードや外部ツールがこの値を参照した際、旧ドメインを指し続ける「ゾンビ参照」が発生するのだ。
—
2. マルチサイト移行における「整合性崩壊」のメカニズム
マルチサイト環境（特に`DOMAIN_CURRENT_SITE`が変更されるような移行）では、以下のデータ整合性リスクが顕在化する。
1. RSS/Atomフィードの無効化: RSSリーダーは`guid`を投稿のユニークキーとして使用する。移行先でGUIDが旧ドメインのままだと、フィードリーダーは「過去の投稿がすべて更新された」あるいは「重複した投稿である」と誤認する。
2. REST APIのシリアライズ: `WP_REST_Posts_Controller`は、デフォルトで`guid`をレスポンスに含める。API経由でデータを吸い上げ、別のプラットフォームへ移行する際、不整合なドメイン情報がメタデータとして混入する。
—
3. 極限の運用：GUIDを制御下に置くための設計思想
GUIDは、原則として「一度生成されたら二度と変更してはならない不変な値」として扱うべきである。しかし、物理的に整合性が取れていないのであれば、それは「技術的負債」だ。
解決策：wp_insert_post_dataフックによる正規化
データ移行の際、あるいは新規投稿時にGUIDを適切に管理するための実装例を示す。コアのロジックに深く介入し、GUIDを「URL」から「識別子」へと昇華させる。
/
- GUIDの挙動をオーバーライドし、URLへの依存を排除する
- 移行時にGUIDを書き換えるのではなく、最初から「真の識別子」として運用する
/
add_filter(‘wp_insert_post_data’, function ($data, $postarr) {
// 新規投稿時、またはGUIDが空の場合のみ処理
if (empty($postarr[‘ID’]) && empty($data[‘guid’])) {
// 現在のドメインを排除した一意なハッシュをGUIDとして生成
// これにより、将来的なドメイン移行でもGUIDは不変となる
$data[‘guid’] = sprintf(‘wp-uuid-%s’, wp_generate_password(16, false));
}
return $data;
}, 10, 2);
/
- REST APIレスポンスからGUIDを秘匿する（セキュリティ最適化）
- 不必要なメタデータは転送コストを増大させるだけである
/
add_filter(‘rest_prepare_post’, function ($response) {
$data = $response->get_data();
unset($data[‘guid’]);
$response->set_data($data);
return $response;
}, 10, 1);
—
4. チーフアーキテクトからの提言：データ移行のベストプラクティス
物理的なデータベースの移行においては、SQLレベルでの置換（`sed`や`wp-cli search-replace`）を安易に行うべきではない。
- シリアライズデータの破壊: `wp_postmeta`等にはシリアライズされたデータが含まれる。単純な文字列置換を行うと、文字列長が変化し、PHPの`unserialize()`が失敗する。必ず`wp-cli`などの、シリアライズ構造を解析できるツールを使用すること。
- GUIDの再生成ポリシー: 本来、WordPressのGUIDは「変更不可」が原則だが、移行時に旧ドメインが完全に死滅する場合、`UPDATE wp_posts SET guid = REPLACE(guid, ‘old.com’, ‘new.com’)`を実行せざるを得ないこともある。この際、バイナリレベルでの一貫性が保たれているかを確認するため、トランザクション分離レベルを`REPEATABLE READ`に設定し、整合性を担保せよ。
結論
GUIDはWordPressの設計において最も「曖昧な」存在だ。これを正しく掌握するとは、GUIDを「URLの代用品」と見なすのをやめ、システム間での一意性を保証するための「不変ID」として再定義することに他ならない。
内部構造の裏側まで深く視認し、データの流れを制御せよ。それこそが、WordPressを単なるCMSとしてではなく、堅牢なアプリケーション基盤として運用するための唯一の道である。