こんにちは！WordPressの内部構造の世界へようこそ。
普段何気なく使っているWordPressですが、データベースの裏側を覗いてみると、実は歴史的な背景やちょっとユニークな仕様が隠されているんです。
今回は、データベースの心臓部である `wp_posts` テーブル、その中でも「GUID（Global Unique Identifier）」というカラムにスポットを当ててみましょう。「名前は聞いたことあるけれど、実際は何をしているの？」という疑問を、エンジニアの先輩として優しく、そして深く解き明かしていきますね。
ここをクリアすれば、WordPressのデータ構造に対する理解がグッと深まり、トラブルシューティングのスキルも一気に跳ね上がりますよ。一緒にバッチリマスターしていきましょう！
—
1. `wp_posts` テーブルのGUIDカラム、その正体とは？
まずは、データベースの `wp_posts` テーブルを覗いてみてください。投稿、固定ページ、添付ファイル、カスタム投稿タイプなど、ありとあらゆるコンテンツがこのテーブルに保存されていますよね。
その中にある `guid` カラムには、通常以下のようなデータが入っています。
おや？これ、どこかで見たことありませんか？そう、多くの場合、このURLは「その投稿のパーマリンク（公開URL）」とそっくり、あるいは全く同じになっています。
ここで、他の言語（Ruby on RailsやLaravelなど）のORMや、一般的なデータベース設計を学んだことのある方なら、こう疑問に思うはずです。
> 「GUID（グローバル一意識別子）って、UUIDみたいにシステム全体で重複しない一意のIDを表すものじゃないの？ なんでURLが入っているの？」
その直感、大正解です。実はここに、WordPressの歴史と、少し複雑な「現在地」が隠されているんです。
—
2. 本来の目的と「現状」のねじれを知る
本来の目的：不変の識別子
WordPressの黎明期において、GUIDは「インターネット上でその投稿を指し示す、世界でたった一つの変わらないID（文字列）」として設計されました。データベースを移行したり、ドメインが変わったりしても、このGUIDさえあれば「これが元のデータだ」と識別できるようにしたかったのですね。
現状：URLと結びついた「ただの文字列」
しかし、現実はどうでしょう。多くのユーザーが「パーマリンク構造（例: `/2023/sample-post/`）」に変更したり、後からサイトのドメイン（例: `http` から `https` へ、あるいはドメイン移転）を変更したりします。
ここで重大な事実があります。
「WordPressは、一度生成された `guid` の値を、後から自動的に書き換えてはくれない」 ということです。
つまり、データベース内の `guid` は、作成された瞬間のURL（しかも大抵はクエリパラメータ形式 `?p=123`）のまま固定され、実際の公開URLとは乖離していくのがデフォルトなのです。
—
3. なぜ「変えてはいけない」のか？（マルチサイトと同期の罠）
「じゃあ、ドメインを変えたときに `guid` も一括で新しいURLに書き換えちゃえばいいんじゃない？」と思いますよね。ここで、マルチサイト環境やデータ同期の文脈において、非常に重要な注意点が出てきます。
もしあなたが、外部のRSSリーダーやAPI、あるいは他のWordPressサイトとデータを同期（シンク）するシステムを作っているとしましょう。
[外部システム] ─── (GUIDをキーにして差分をチェック) ───> [WordPress DB]
このとき、もしサイト側でURLが変わったからといって `guid` を勝手に書き換えてしまうと、外部システム側は「おっ、新しい記事が追加されたぞ！」と勘違いしてしまい、同じ記事が二重に登録される（重複データが生まれる）という大惨事が起きてしまいます。
そのため、WordPressコアの哲学としても、「一度発行された `guid` は、原則として二度と変更してはならない（Immutable）」と扱われているのです。
—
4. 実践：コードで見る GUID の扱い方
それでは、開発の現場で私たちがこのGUIDとどう向き合うべきか、実際のコードを見ていきましょう。
例えば、カスタムプラグインなどで記事データを新しくプログラムから挿入する場合、`wp_insert_post()` 関数を使いますよね。このとき、GUIDをどう指定すべきでしょうか？
正しい投稿追加のコード例
/
$post_data = array(
‘post_title’ => ‘内部構造を極めるための投稿’,
‘post_content’ => ‘GUIDの挙動を理解することはエンジニアとしての第一歩です。’,
‘post_status’ => ‘publish’,
‘post_type’ => ‘post’,
// ‘guid’ => ここにあえてカスタム値を指定しない！
);
// 投稿をデータベースに挿入
$post_id = wp_insert_post( $post_data );
if ( ! is_wp_error( $post_id ) ) {
// 成功した場合、WordPressは自動的に
// “http://yoursite.com/?p={post_id}” のようなデフォルトGUIDを生成して格納します
echo “投稿ID: {$post_id} が正常に作成されました。”;
}
🚨 陥りやすい文法・設計エラー
初心者の開発者によくあるミスがこちらです。
// 【やってはいけないアンチパターン】
$post_data = array(
‘post_title’ => ‘エラーになる例’,
‘post_content’ => ‘…’,
‘post_status’ => ‘publish’,
// 意気込んでGUIDに現在のパーマリンクを直接入れようとする
‘guid’ => ‘https://example.com/archives/1234’
);
wp_insert_post( $post_data );
これをやってしまうと何が起きるでしょうか？
後からパーマリンクの設定（スラッグや構造）を変更した際、データベースの `guid` と実際のURLが完全にちぐはぐになり、将来的なデータ移行やインポート・エクスポートツール（WXRファイルなど）を使った際に、重複インポートの原因になります。
原則として、`wp_insert_post()` を使うときは `guid` の指定はWordPressコアに丸投げする（自前で書き換えない）のが鉄則です。
—
5. データベース設計・保守におけるベストプラクティス
最後に、マルチサイト環境や大規模なWordPressサイトを運用・開発するエンジニアとして、知っておくべき心構えをまとめます。
1. GUIDを「URL」として信用しない
フロントエンドのリンク生成や、SEO用のURL取得に `post->guid` を使ってはいけません。必ず `get_permalink($post_id)` を使いましょう。これはWordPress開発の極めて重要な基本です。
2. ドメイン移行時のSQL置換に注意する
サイト移転時に `wp_posts` の `guid` を一括置換（Search & Replace）したくなる誘惑に駆られますが、前述の通り外部連携のキーとして使っているプラグイン等がある場合、整合性が崩れるリスクがあります。原則として、コアのGUIDはそのまま触らないのが無難です。
3. 一意性制約がない点に注意
名前に「Global Unique Identifier」とついていながら、実はデータベースレベル（MySQLのスキーマ）では `guid` カラムに `UNIQUE` キーやインデックスが張られていないバージョンが長く存在しました（※環境やバージョンによって異なりますが、完全なユニーク性が厳密に担保されているわけではありません）。ここも「名ばかりのユニークID」と言われる所以です。
—
いかがでしたでしょうか？
今回は少しマニアックな `wp_posts` の `guid` カラムについて深掘りしました。「歴史的経緯からURLが入っているけれど、実態としては変えてはいけない不変のキーとして扱われている」という背景が分かると、データベースを見る目がガラリと変わったのではないでしょうか。
こうした内部構造の機微を知っているだけで、トラブルに直面したときの原因究明のスピードが圧倒的に早くなります。ぜひ、実際のデータベースをphpMyAdminなどで覗いて、ご自身の目で確認してみてくださいね。
それでは、次のステップでも一緒にWordPressの奥深い世界を楽しみましょう！