WP_Queryを制する者はWordPressを制す：`pre_get_posts` によるクエリ最適化の極致
WordPressにおいて、`WP_Query` は強力な抽象化レイヤーです。しかし、多くのエンジニアがこの抽象化に甘え、無意識のうちに「重いクエリ」をデータベースに投げつけています。
特にメインクエリの改変において、テンプレートファイルで `new WP_Query` を乱用するのは悪手です。リクエストのライフサイクルを理解するプロフェッショナルであれば、`pre_get_posts` フックこそが、クエリの実行前に最適化を施す唯一の聖域であることを知っているはずです。
なぜ `pre_get_posts` なのか？
理由は単純です。「クエリがデータベースへ発行される前に介入できるから」です。
メインクエリが実行された後で `get_posts()` や `new WP_Query` を叩くと、それは既に2度目のDB接続（あるいはキャッシュ探索）を発生させており、リソースの無駄遣いです。
`pre_get_posts` を使えば、メインクエリそのものの条件を書き換えるため、追加のオーバーヘッドはゼロ。これが、パフォーマンスを追求するエンジニアが選ぶべき唯一の解法です。
—
実践：プロダクションレベルの「堅牢な」クエリ改変パターン
単に `set()` するだけでは不十分です。メインクエリ以外（管理画面やREST API経由のアクセス）を誤って破壊しないための「ガード節」が不可欠です。
以下は、特定のカスタム投稿タイプにおいて、特定の条件を満たす記事のみを取得しつつ、不必要なメタデータ読み込みを抑制する設計例です。
/
- メインクエリを制御するためのセキュアな設計パターン
/
add_action(‘pre_get_posts’, function (WP_Query $query) {
// 1. ガード節：管理画面とメインクエリ以外は即座に弾く
if (is_admin() || !$query->is_main_query()) {
return;
}
// 2. 特定のテンプレートのみに適用する条件分岐
if (is_post_type_archive(‘product’)) {
// 3. クエリパラメータの最適化
// 不要なJOINを避けるため、必要なデータだけを絞り込む
$query->set(‘posts_per_page’, 12);
$query->set(‘post_status’, ‘publish’);
// パフォーマンス向上：不要なメタデータキャッシュの読み込みを停止
$query->set(‘update_post_meta_cache’, false);
$query->set(‘update_post_term_cache’, false);
// 4. カスタムフィールドによるフィルタリング
// ここで meta_query を使う場合、インデックスが貼られているかを確認すること
$query->set(‘meta_query’, [
[
‘key’ => ‘_is_featured’,
‘value’ => ‘1’,
‘compare’ => ‘=’
]
]);
}
});
パフォーマンスを極めるための3つの鉄則
1. `update_post_meta_cache` の制御
デフォルトのWP_Queryは、取得した投稿全てのメタデータを一度にキャッシュしようとします。投稿数が多い場合、この `update_post_meta_cache` は致命的な遅延（巨大な `IN` クエリの発生）を招きます。リスト表示でメタデータを必要としない場合は、迷わず `false` に設定してください。
2. データベースのインデックスを意識せよ
`meta_query` や `tax_query` を使う際、そのキーがデータベースのどこにあるかを想像してください。`wp_postmeta` テーブルの `meta_key` はインデックス化されていますが、値（`meta_value`）はロングテキスト型であり、ここでの検索はフルテーブルスキャンを誘発しがちです。
もし検索頻度が高いメタデータであれば、`meta_query` ではなく、カスタムテーブルへの切り出しや、`WP_Query` の `fields => ‘ids’` を使ったキャッシュ戦略を検討すべきです。
3. `is_main_query()` の重要性
このチェックを忘れると、サイドバーのウィジェットやメニュー生成で走る「予期せぬサブクエリ」まで改変してしまいます。これはシステム全体の予期せぬバグの温床です。`pre_get_posts` 内では、常にこのチェックが「入り口」であることを徹底してください。
—
技術者への提言：計測なき最適化は単なる推測
このコードを実装する際、必ず `Query Monitor` プラグインを使用して、実際に発行されている SQL クエリを確認してください。
- JOIN は減っているか？
- クエリの実行時間は短縮されたか？
- 不要な `SELECT ` を発行していないか？
WordPressの内部構造を理解し、クエリを「制御」する。これこそが、単なる実装者と、システムを掌中に収めるリードエンジニアとの境界線です。
あなたのコードが、次に読むエンジニアにとっても「美しい」と感じられる設計であることを願っています。それでは、良いハッキングを。