動的 `posts_per_page` が引き起こす暗黙のキャッシュ崩壊とその対策
コードレビューをしよう。以下のコードを見て、どこに致命的なパフォーマンスボトルネックが潜んでいるか即答できるだろうか？
// 良くあるアンチパターン
$per_page = isset( $_GET[‘per_page’] ) ? intval( $_GET[‘per_page’] ) : 10;
$args = array(
‘post_type’ => ‘post’,
‘posts_per_page’ => $per_page,
‘paged’ => get_query_var( ‘paged’ ? get_query_var( ‘paged’ ) : 1,
);
$query = new WP_Query( $args );
一見、ユーザーの要求に応じて表示件数を切り替える柔軟な実装に見える。しかし、この実装をトラフィックの多いプロダクション環境に投入すれば、瞬く間にデータベースのCPU使用率は跳ね上がり、オブジェクトキャッシュ（Redis/Memcached）のヒット率は底を突くだろう。
なぜか？ WordPressのコア、そしてクエリキャッシュの本質を理解していれば自明だ。
本稿では、ユーザーの選択に応じて `posts_per_page`（ページサイズ）が動的に変動する際、キャッシュキーをどう設計し、いかにして無駄なSQL発行とメモリ肥大化を防ぐか。その極限のアーキテクチャを解説する。
—
1. なぜ動的 `posts_per_page` はキャッシュ戦略を破壊するのか
WordPressのクエリキャッシュ（あるいはサードパーティのオブジェクトキャッシュ、さらにはHTTPリバースプロキシ）は、基本的に「リクエストされたURL」や「生成されたクエリハッシュ」をキーにしてデータを保持する。
ここで問題になるのが以下の2点だ。
1. キャッシュのフラグメンテーション（断片化）
ユーザーAが `per_page=10` でアクセスし、ユーザーBが `per_page=20` でアクセスした場合、たとえ同じカテゴリ、同じページ（`paged=1`）であっても、データベースが返すデータセットの境界（LIMIT句）が異なるため、別物のキャッシュエントリとして生成される。これが無制限に生成されると、キャッシュヒット率が著しく低下し、メモリが圧迫される。
2. ページングの整合性崩壊
`per_page=10` の時の 3ページ目（offset: 20）と、`per_page=20` の時の 3ページ目（offset: 40）は全く指し示すデータが異なる。これを適切にキャッシュキーに内包させなければ、ユーザーに古いデータや重複したデータが返却される致命的な不整合を生む。
したがって、動的なページサイズを受け入れるシステムでは、「許可された値のホワイトリスト化」と「キャッシュキーの正規化」が絶対命題となる。
—
2. 堅牢な設計パターン：バリデーションとキャッシュキーの正規化
実務の現場において、GETパラメータをそのまま `WP_Query` に渡すエンジニアは論外だ。SQLインジェクション対策は当然として、キャッシュ汚染（Cache Poisoning / Cache Pollution）を防ぐために、許容値を厳格に制限する必要がある。
以下に、プロダクションクオリティの設計パターンを示す。ここでは、Transient API もしくはオブジェクトキャッシュを用い、動的パラメータを安全にハンドリングするクラス構造を構築する。
/
class Dynamic_Query_Manager {
/
- 許可するページサイズのホワイトリスト
- 無制限なキャッシュフラグメンテーションを防ぐための防壁
/
private const ALLOWED_PER_PAGE = [ 10, 20, 50, 100 ];
private const DEFAULT_PER_PAGE = 10;
/
- 安全な posts_per_page を取得する
- @return int
/
public function get_sanitized_per_page(): int {
$input = filter_input( INPUT_GET, ‘per_page’, FILTER_VALIDATE_INT );
if ( $input && in_array( $input, self::ALLOWED_PER_PAGE, true ) ) {
return $input;
}
return self::DEFAULT_PER_PAGE;
}
/
- キャッシュのヒット率を担保するためのキャッシュキー生成
- @param int $paged 現在のページ番号
- @param int $per_page 1ページあたりの件数
- @return string
/
public function generate_cache_key( int $paged, int $per_page ): string {
// 現在のクエリ条件（例: カテゴIDやタグなど）もここにハッシュ化して含めるべき
$current_cat = get_query_var( ‘cat’, 0 );
return sprintf(
‘dyn_posts_cat_%d_page_%d_per_%d’,
$current_cat,
$paged,
$per_page
);
}
/
- キャッシュを考慮した最適化されたクエリの実行
- @return WP_Query
/
public function execute_optimized_query(): WP_Query {
$paged = max( 1, get_query_var( ‘paged’, 1 ) );
$per_page = $this->get_sanitized_per_page();
$cache_key = $this->generate_cache_key( $paged, $per_page );
// オブジェクトキャッシュから投稿IDの配列（スカラー値）をフェッチする
// WP_Query オブジェクト全体をキャッシュするのはシリアライズのコストが高いためNG
$cached_post_ids = wp_cache_get( $cache_key, ‘dynamic_queries’ );
if ( false === $cached_post_ids ) {
$args = [
‘post_type’ => ‘post’,
‘posts_per_page’ => $per_page,
‘paged’ => $paged,
‘post_status’ => ‘publish’,
‘fields’ => ‘ids’, // ★重要: IDのみを取得してメモリ消費を極限まで抑制
];
$query = new WP_Query( $args );
$cached_post_ids = $query->posts;
// キャッシュに保存（有効期限は1時間、コンテンツ更新時にパージする設計に連動させる）
wp_cache_set( $cache_key, $cached_post_ids, ‘dynamic_queries’, HOUR_IN_SECONDS );
}
// 取得したID群を元に、実際の WP_Query を再構築する（プライマリキャッシュ＝オブジェクトキャッシュを活用）
return $this->warm_up_query_from_ids( $cached_post_ids, $per_page, $paged );
}
/
- ID配列から WP_Query オブジェクトを復元する
- @param array $post_ids
- @param int $per_page
- @param int $paged
- @return WP_Query
/
private function warm_up_query_from_ids( array $post_ids, int $per_page, int $paged ): WP_Query {
// キャッシュされたIDが存在しない場合のフォールバック
if ( empty( $post_ids ) ) {
return new WP_Query( [ ‘post_type’ => ‘post’, ‘posts_per_page’ => 0 ] );
}
// WP_Query の内部で無駄なSQLを発行させないためのトリック
// すでに投稿メタやポストデータがキャッシュ（prime_post_caches）されている前提でクエリを構築
$query = new WP_Query( [
‘post__in’ => $post_ids,
‘orderby’ => ‘post__in’, // 順序を維持
‘posts_per_page’ => $per_page,
‘paged’ => $paged,
‘post_type’ => ‘post’,
] );
return $query;
}
}
—
3. この設計がプロダクション環境で最強である理由
上記のコードには、WordPress内部を知り尽くしたエンジニアならではの最適化が3つ組み込まれている。
A. ホワイトリストによる「キャッシュ・スラッシング」の防止
`ALLOWED_PER_PAGE = [10, 20, 50, 100]` と定義することで、ユーザーが `?per_page=11` や `?per_page=99999` といった悪意ある、あるいは無意味なパラメータを指定しても、強制的に `10` にフォールバックする。これにより、メモリを枯渇させるDDoS的なキャッシュ肥大化を完全に防ぐ。
B. `fields => ‘ids’` によるDB負荷の最小化とシリアライズコストの削減
`WP_Query` のインスタンスをそのままオブジェクトキャッシュに突っ込む愚を犯してはならない。`WP_Query` 内には膨大なプロパティやデータベースリソースへの参照が含まれており、シリアライズ／アンシリアライズのオーバーヘッドが無視できない。
必要なのは「どの投稿IDの順番か」という最小限のデータ（スカラー値の配列）のみである。これをキャッシュし、実体はWordPressのコアが持つ投稿キャッシュ（`_prime_post_caches`）に依存させることで、メモリ効率を劇的に改善する。
C. キャッシュパージ（無効化）の容易性
動的クエリのキャッシュは、投稿の更新（`save_post`）や削除時に一斉にクリアされる必要がある。
上記のように `dynamic_queries` というグループキー（キャッシュグループ）を切っておけば、Redis等の環境において `wp_cache_flush_group( ‘dynamic_queries’ )` を叩くだけで、動的ページサイズの全キャッシュをクリーンに保つことができる。
—
テクニカルリードからの総括
「動的な要件を満たすために、とりあえずクエリをそのまま回す」——これはジュニアから中級者へ移行するエンジニアが最も陥りやすい罠だ。
Webシステムにおいて「動的であること」と「キャッシュ可能であること」は決して二律背反ではない。変数の取りうる空間を限定（ホワイトリスト化）し、キャッシュの粒度をデータ構造の単位（ID配列）まで分解すること。この設計思想をマスターすれば、いかなるトラフィックのうねりをも受け止める堅牢なWordPressバックエンドを構築できる。
次のコードレビューでは、動的パラメータを扱うすべての `WP_Query` にこの視点が網羅されているか、厳しく目を光らせてほしい。