こんにちは。WordPressという巨大なエコシステムに足を踏み入れたばかりの皆さん、ようこそ。
多くの開発者がWordPressを「ただのブログツール」だと誤解していますが、その心臓部は驚くほど柔軟で、同時に非常に繊細なデータベース構造を持っています。今日は、その中でも「階層構造を持つ投稿タイプ」を扱う際に、多くの人が陥る「死の罠」と、それを回避するプロのキャッシュ戦略についてお話ししましょう。
ここをマスターすれば、WordPressのパフォーマンスに対する解像度が一段と上がりますよ。
—
1. そもそも `post_parent` とは何者なのか？
WordPressの `wp_posts` テーブルには、`post_parent` というカラムが存在します。これは「誰が親か」を記録する、いわば「家系図のポインタ」です。
- 親投稿: `post_parent` は `0`
- 子投稿: `post_parent` に親の `ID` が入る
この構造のおかげで、固定ページやカスタム投稿タイプで「階層構造（ツリー構造）」を簡単に作れますよね。でも、ここからが問題です。
「再帰的クエリ」という悪魔のささやき
「ある投稿のすべての子孫（子、孫、ひ孫…）を取得したい」と思ったとき、多くの初心者は以下のようなコードを書きがちです。
// 悪い例：ループの中でクエリを発行する「N+1問題」
function get_all_children($parent_id) {
$children = get_posts([‘post_parent’ => $parent_id, ‘post_type’ => ‘my_type’]);
foreach ($children as $child) {
// 再帰的に呼び出すたびにSQLが飛ぶ！
$child->descendants = get_all_children($child->ID);
}
return $children;
}
これ、データが増えると一瞬でサイトが重くなります。なぜなら、再帰の深さ分だけSQLが実行されるからです。データベースへのクエリは、WordPressにおいて最もコストが高い処理の一つ。これをループの中で連発するのは、サーバーにとって自殺行為に等しいのです。
—
2. データベース負荷を軽減する「キャッシュ戦略」
プロの現場では、再帰的な計算をデータベースに直接させず、「一度取得した階層データをメモリに閉じ込める」手法をとります。
解決策：Transients API を使った構造化キャッシュ
毎回データベースをなめるのではなく、一度計算したツリー構造を `wp_options` テーブル（あるいは Redis などのオブジェクトキャッシュ）に保存しましょう。
function get_cached_tree($parent_id) {
$cache_key = ‘my_tree_’ . $parent_id;
$tree = get_transient($cache_key);
if (false === $tree) {
// キャッシュがない場合のみ、一度だけ全データを取得
// 全データを取得してからPHP側でツリーを構築する方が、SQLを連発するより圧倒的に高速です
$all_posts = get_posts([‘post_type’ => ‘my_type’, ‘posts_per_page’ => -1]);
$tree = build_tree_structure($all_posts, $parent_id);
// 12時間キャッシュしておく
set_transient($cache_key, $tree, 12 HOUR_IN_SECONDS);
}
return $tree;
}
なぜこれが「正解」なのか？
1. クエリの集約: `posts_per_page => -1` で全データを一度に取得し、メモリ上で親子関係を解決します。
2. I/Oの削減: データベースへのアクセスを「1回」に抑えています。
3. 有効期限管理: `set_transient` で期限を設けることで、データの整合性とパフォーマンスのバランスをとっています。
—
3. 陥りやすい文法エラーと注意点
初心者がよくやるミスに、「キャッシュの削除（パージ）忘れ」があります。
投稿が更新されたときにキャッシュを削除しないと、古い情報のまま表示され続けてしまいます。これを防ぐには、WordPressのフック（アクション）を正しく使う必要があります。
// 投稿が保存されたらキャッシュをクリアする
add_action(‘save_post_my_type’, function($post_id) {
// 関連するすべてのキャッシュキーを削除する戦略をとる
delete_transient(‘my_tree_0’);
// …など
});
ここでのポイントは、「更新時にキャッシュを捨てる」という設計思想です。WordPressのフックシステムを知り尽くせば、データ整合性は完璧に制御できます。
—
最後に：エンジニアとして成長するために
WordPressのデータベース構造は、決して「レガシーで遅い」わけではありません。「どのようにデータを取得し、どのようにキャッシュを階層化するか」という、エンジニアの設計力次第で、世界最高峰のパフォーマンスを引き出すことが可能です。
`wp_posts` の親子関係を理解し、クエリの回数を最小化する。この思考プロセスを身につければ、WordPressエンジニアとして一段上のステージに立てたと言えるでしょう。
「ここをクリアすれば、WordPressの基本はバッチリマスター」です。ぜひ、ご自身のプロジェクトで試してみてください。何か詰まったら、いつでもまた聞きに来てくださいね。応援しています！