こんにちは。WordPressの深淵へようこそ。
WordPressを学び始めると、データベースの `wp_posts` テーブルの中に、必ずと言っていいほど目にする謎のカラムがありますよね。そう、`guid` です。
「これって記事のURLだよね？」そう思って、サイト移転のたびに `UPDATE wp_posts SET guid = REPLACE(…)` なんてSQLを叩いていませんか？
もしそうなら、今日でその習慣とはお別れしましょう。GUIDはURLではありません。そして、触ってはいけない聖域なのです。
なぜそう言い切れるのか、コアの内部構造から紐解いていきましょう。
—
1. GUIDの正体：URLではなく「グローバルな識別子」
まず、`guid` という名前は「Globally Unique Identifier」の略です。
WordPressにおいて、このカラムの本来の役割は「その投稿に対して世界で唯一無二のID（一意識別子）を付与すること」にあります。
なぜURLのように見えるのか？
WordPressの黎明期、投稿を識別するための文字列として「その時のパーマリンク」をそのまま使っていた名残が、今の `http://example.com/?p=123` のような形式です。しかし、現代のWordPressにおいて、この値は「URL」としては全く機能していません。
重要な事実
- GUIDは固定です： 投稿が作成された瞬間に一度だけ生成され、その後は（原則として）変更すべきではありません。
- URLは動的です： パーマリンク設定を変えればURLは変わりますよね。でも、GUIDが変わってしまうと、外部のRSSフィードやAPIなどの連携システムが「別の記事だ」と誤認してしまいます。
—
2. データベース設計上の「罠」
もしあなたが `guid` をURLとして書き換えてしまうと、以下のような悪夢が待っています。
1. RSSフィードの破壊： フィードリーダーはGUIDをキーにして「既読・未読」を管理しています。ここを書き換えると、読者のフィードリーダーに過去記事が「新着」として大量に再送されるという大惨事が起きます。
2. キャッシュの無効化： 一部のプラグインや外部キャッシュシステムはGUIDをキーにしています。書き換えはパフォーマンスの低下を招きます。
陥りやすい「文法（設計）エラー」
「サイトをHTTPS化したから、全記事のGUIDもhttps://に書き換えなきゃ！」と考えてSQLを投げるのは、WordPressの設計思想における最大の禁じ手です。GUIDは、たとえHTTPのままでも、その投稿のアイデンティティとしてそのまま放置しておくのが正解なのです。
—
3. WordPressの内部でGUIDを「触らせない」ための防衛線
開発者として、この「触ってはいけないGUID」を誤って操作しないために、WordPressには強力なフックが用意されています。
コード例：GUIDの改竄を物理的にブロックする
もしチーム開発で、誤ってGUIDを更新するような処理を書いてしまう人がいたら、以下のコードを `functions.php` に仕込んでおきましょう。
/
- wp_postsのguidカラムが更新されるのを防ぐガードレール
/
add_filter(‘wp_insert_post_data’, function ($data, $postarr) {
// 既存の投稿かつ、GUIDが意図せず書き換えられそうになった場合
if (!empty($postarr[‘ID’]) && isset($data[‘guid’])) {
// データベースから現在のGUIDを取得
$original_guid = get_the_guid($postarr[‘ID’]);
// 元のGUIDと異なる場合は、強制的に元に戻す
if ($data[‘guid’] !== $original_guid) {
$data[‘guid’] = $original_guid;
}
}
return $data;
}, 10, 2);
このコードは、まさに「門番」です。`wp_insert_post_data` フックは、データベースに書き込まれる直前のデータを制御できる、コアコントリビューター御用達の重要なポイントですね。
—
4. まとめの知見：プロフェッショナルの視点
今日、皆さんに持ち帰っていただきたいのは以下の3点です。
- GUIDは「識別子」であり「URL」ではない： 書き換える必要は一切ありません。
- RSSと連携システムの命綱： GUIDを書き換えると、外部システムとの整合性が崩れます。
- 「触らない勇気」もエンジニアリング： WordPressのコアが意図的に残している古い仕様を「バグ」と決めつけず、その背後にある理由を理解することこそが、真のフルスタックへの近道です。
WordPressという巨大なシステムを掌握するには、DBの物理構造を理解し、「何を変えてはいけないのか」という境界線を引くことが最も重要です。
ここをクリアしたあなたは、もう初心者ではありません。次はぜひ、`wp_postmeta` のインデックス戦略や、Object Cacheの効率化についても深掘りしてみてください。WordPressの世界は、知れば知るほど面白くなりますよ！
また何か疑問があれば、いつでも聞いてくださいね。応援しています。