こんにちは。WordPressの深淵へようこそ。
コードベースを眺めていると、誰もが一度は「この `guid` って何のためにあるんだ？」という疑問にぶつかりますよね。
データベースの `wp_posts` テーブルを覗くと、必ず鎮座しているこのカラム。URLのように見えるけれど、書き換えてもサイトが壊れるわけではない。でも、いざマルチサイト移行やドメイン変更をすると悪夢が始まる……。
今日は、WordPressの「心臓部」に潜むこのガイド（GUID）の正体と、プロとして絶対に守るべき扱い方について、その核心を紐解いていきましょう。
—
1. GUIDの正体：URLではなく「グローバルな識別子」
まず、最も重要な前提からお伝えします。
GUID（Globally Unique Identifier）は、URLではありません。
多くの初心者が陥る罠は、`guid` カラムを「記事のパーマリンク」だと誤解することです。もしあなたが「`wp_posts` の `guid` を書き換えれば、サイト全体のリンクが変わるはずだ」と考えているなら、それは大きな勘違いです。
- 本来の役割: 記事が作成された瞬間に割り当てられる、世界で唯一無二の「名前」です。
- なぜURL形式なのか: RSSフィードなどで「投稿を一意に特定するための識別子」としてURL形式が採用されたという歴史的経緯があるだけです。
結論: `guid` は記事が生成された時に一度決まったら、原則として二度と変更してはいけない「固定された名札」だと考えてください。
—
2. なぜマルチサイト移行で「GUID」が牙を剥くのか
マルチサイト環境やサーバー移行時、多くのエンジニアが「データベース内の全URLを `wp-cli` で置換しよう」と考えます。
悪魔のコマンド（やってはいけない例）
wp search-replace ‘old-site.com’ ‘new-site.com’
このコマンドを盲目的に実行すると、`wp_posts.guid` まで書き換わってしまいます。何が起こるか？
1. RSSフィードの破壊: GUIDが変わると、RSSリーダーは「これは新しい記事だ！」と誤認し、購読者に古い記事が大量に再通知されるという大事故が発生します。
2. 投稿のユニーク性喪失: 外部システムやAPI連携において、GUIDをキーにしている場合、連携が完全に断絶します。
ここをクリアすれば、WordPressの基本はバッチリマスターできますよ。
「GUIDは、移行作業において『触れてはいけない聖域』である」と覚えておいてください。
—
3. 実践：正しいデータ移行の作法
では、ドメインが変わった時はどうすべきか。WordPressには、`guid` を維持しつつ、リンク先だけを動的に解決する仕組みが備わっています。
正しいアプローチ：`get_permalink()` の仕組みを知る
WordPressは投稿のURLを生成する際、データベースの `guid` を参照しているわけではありません。パーマリンク設定に基づいて、`post_id` から動的にURLを生成しています。
もし、どうしてもデータベース内のURLを置換する必要がある場合は、`guid` カラムを除外して置換を行うのがプロの鉄則です。
正しい置換方法（guidカラムを除外する）
wp search-replace ‘old-site.com’ ‘new-site.com’ –skip-columns=guid
—
4. コードで見る「GUID」の罠
開発中に「現在の記事のURLが欲しい」と思ったとき、決して `guid` を直接参照してはいけません。
ダメな例：
// データベースのguidを直接取ってくる。これは危険！
$post_url = get_post($post_id)->guid;
良い例：
// WordPressのロジックを通してパーマリンクを取得する。これが正解。
$post_url = get_permalink($post_id);
`get_permalink()` は、現在の環境設定、マルチサイトのパス、パーマリンク構造をすべて計算した上で、正しいURLを返してくれます。内部コアは、データベースの `guid` に頼らず、`ID` から動的に解決しているのです。
—
まとめ：WordPressエンジニアとしての一歩先へ
今日の話をまとめるとこうなります。
- GUIDは「名札」: 一度決めたら二度と変えない。
- GUIDは「URL」ではない: URLを管理しているのはパーマリンク設定と `post_id`。
- 移行時は除外する: `search-replace` する際は、必ず `–skip-columns=guid` を添える。
WordPressという巨大なシステムは、一見不合理に見える構造にも「過去の互換性」と「将来の拡張性」という深い理由があります。GUIDの扱いをマスターすることは、WordPressの内部構造を理解するための第一歩です。
この「触れてはいけない場所」を理解したあなたなら、どんな大規模なサイト移転でも、データ整合性を壊すことなく成功させることができるはずです。
次回の記事では、`wp_postmeta` の EAV（Entity-Attribute-Value）構造のパフォーマンス劣化と、それを回避するためのカスタムテーブル設計について深掘りします。それでは、またコードの海でお会いしましょう。