こんにちは！ WordPressの内部構造やパフォーマンス最適化の世界へようこそ。
今回は、実務でも非常によく遭遇する「ユーザーの選択に応じて `posts_per_page`（1ページあたりの表示件数）を動的に変更する際のキャッシュ戦略」について、コアの動きとデータベースの裏側を交えながら深く掘り下げて解説していきますね。
「他の言語からWordPressに入ったけれど、クエリの動的制御とキャッシュの組み合わせでハマってしまった……」そんな悩みを抱える中級者の方に向けて、本質からしっかり解き明かしていきます。ここをクリアすれば、あなたもWordPressのパフォーマンスチューニングを自在に操れるようになりますよ！
—
なぜ `posts_per_page` の動的変更はキャッシュ戦略が命なのか？
WordPressでサイトを作っていると、「ユーザーに表示件数（例：10件、20件、50件）を選ばせたい」という要件に出会うことがありますよね。
一見、`WP_Query` の引数に渡す `posts_per_page` を動的に変えるだけで簡単に実装できるように思えます。しかし、ここにキャッシュ（Object CacheやTransients API）を絡めた途端、致命的な設計ミスを犯してしまう開発者が後を絶ちません。
データベースとキャッシュのすれ違い
WordPressの内部では、`WP_Query` が実行されると、SQLが組み立てられてデータベースに投げられます。
例えば、以下のようなコードを書いてみたとしましょう。
// ユーザーが選択した件数を取得（デフォルトは10）
$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 );
これをそのまま全ページ共通の静的なキャッシュキーで保存してしまったらどうなるでしょうか？
- ユーザーAが「10件表示」でアクセス ⇒ 10件分のデータがキャッシュされる。
- ユーザーBが「50件表示」でアクセス ⇒ ユーザーAが作った「10件分のキャッシュ」が返されてしまい、レイアウトが崩れたり件数が足りなくなったりする！
そう、「クエリの条件（この場合は `posts_per_page` や `paged`）」がキャッシュキーに正しく反映されていないことが原因で起こるバグです。
—
健全なキャッシュキー設計の黄金律
動的なパラメータを持つクエリの結果をキャッシュする場合、キャッシュキーは「一意性（ユニークさ）」を担保しなければなりません。
図解的に表現すると、キャッシュの保存場所（バケツ）の構造は以下のようになっている必要があります。
[ キャッシュストア (Redis / Memcached / Transients) ]
├── my_custom_query_per10_page1 => [投稿ID 1~10のシリアライズデータ]
├── my_custom_query_per10_page2 => [投稿ID 11~20のシリアライズデータ]
├── my_custom_query_per50_page1 => [投稿ID 1~50のシリアライズデータ]
└── my_custom_query_per50_page2 => [投稿ID 51~100のシリアライズデータ]
つまり、「変動するパラメータ（表示件数、ページ番号、ソート順など）をすべて網羅したハッシュ（または文字列）をキャッシュキーの一部にする」これが鉄則です。
—
実装コード：動的 `posts_per_page` とトランジェントキャッシュの融合
それでは、実際に安全で高速なキャッシュ戦略を実装したコードを見てみましょう。
ここでは WordPress の Transients API を使った例をベースに解説します。
/
- 動的な posts_per_page を考慮した最適化クエリ＆キャッシュ関数
/
function get_optimized_dynamic_posts() {
// 1. 入力値のサニタイズとバリデーション（セキュリティの基本！）
$allowed_per_page = array( 10, 20, 50 );
$per_page = isset( $_GET[‘per_page’] ) ? intval( $_GET[‘per_page’] ) : 10;
// 許可されていない値が来たらデフォルトにフォールバック（意図しない大量取得を防ぐ）
if ( ! in_array( $per_page, $allowed_per_page, true ) ) {
$per_page = 10;
}
$paged = max( 1, get_query_var( ‘paged’ ) );
// 2. キャッシュキーの動的生成（これが今回の最重要ポイント！）
// パラメータの組み合わせごとに一意のキーを生成します
$cache_key = ‘opt_posts_per_’ . $per_page . ‘_page_’ . $paged;
// 3. キャッシュからデータを取得を試みる
$cached_data = get_transient( $cache_key );
if ( false !== $cached_data ) {
// キャッシュヒット！データベースへのクエリ発行を完全に回避します
return $cached_data;
}
// 4. キャッシュミスの場合は実際に WP_Query を実行
$args = array(
‘post_type’ => ‘post’,
‘posts_per_page’ => $per_page,
‘paged’ => $paged,
‘post_status’ => ‘publish’,
// パフォーマンス向上のため不要なメタデータの読み込みを抑制
‘no_found_rows’ => false, // ページネーションに総数が必要なため false
);
$query = new WP_Query( $args );
// 必要なデータ構造に整理して保持（WP_Queryオブジェクト丸ごとのキャッシュはメモリを圧迫するため避ける）
$data_to_cache = array(
‘posts’ => $query->posts,
‘max_pages’ => $query->max_num_pages,
‘found_posts’ => $query->found_posts,
);
// 5. キャッシュを保存（有効期限は適宜調整。例：12時間）
set_transient( $cache_key, $data_to_cache, 12 HOUR_IN_SECONDS );
return $data_to_cache;
}
コードの解説とシニアエンジニアからのワンポイント
1. バリデーションの重要性
`$_GET[‘per_page’]` をそのまま `posts_per_page` に渡すと、悪意あるユーザーに `?per_page=999999` のようなリクエストを送られ、データベースサーバーのメモリを枯渇させる（DoS攻撃の温床になる）リスクがあります。必ずホワイトリスト方式（`$allowed_per_page`）でガードしましょう。
2. `WP_Query` オブジェクトを丸ごとキャッシュしない
オブジェクト自体にはクロージャや巨大なデータが含まれることがあるため、必要な配列データ（投稿オブジェクトの配列やページ数など）だけを抽出してキャッシュするのが、メモリ効率の観点からベストプラクティスです。
—
陥りやすい文法・設計エラーと対策
初心者の頃、あるいは他のフレームワークから移行した際によやりがちなミスを挙げておきます。
❌ やってはいけない例：キャッシュキーの固定
// NG: ユーザーが何件指定しようが、キャッシュキーが常に一定
$cache_key = ‘my_posts_cache’;
$posts = get_transient( $cache_key );
if ( ! $posts ) {
$query = new WP_Query( array( ‘posts_per_page’ => $per_page ) );
set_transient( $cache_key, $query->posts, HOUR_IN_SECONDS );
}
結果： 最初に「10件」でアクセスした人の結果がキャッシュされ、後から「50件」見た人も10件しか表示されないバグが発生します。
❌ やってはいけない例：SQLインジェクションや型崩れ
`intval()` を通さずにクエリ引数に直接入れることで、予期せぬクエリの歪みや脆弱性を生む原因になります。外部からの入力値は必ず整数にキャスト（`intval()`）するか、サニタイズを徹底してください。
—
まとめ：ここをクリアすればWordPressの基本はバッチリ！
今回は、動的な `posts_per_page` を扱う際のキャッシュキー設計について、実務的なコードを交えて解説しました。
- 動的パラメータは必ずキャッシュキーの一部に組み込むこと。
- 入力値のバリデーションを必ず行い、セキュリティとサーバーリソースを保護すること。
- 必要なデータだけを軽量にキャッシュすること。
この3つを押さえておけば、大規模なトラフィックに耐える堅牢で高速なWordPressサイトを構築することができます。
データベースの内部挙動とキャッシュのライフサイクルを意識できるようになると、WordPress開発は圧倒的に楽しく、そして深いものになります。ぜひ、あなたのプロジェクトでもこの設計を取り入れてみてくださいね。応援しています！