こんにちは。WordPressの深淵へようこそ。
WordPressのパフォーマンスチューニングにおいて、「とりあえずRedisやMemcachedを導入してオブジェクトキャッシュを有効化すれば爆速になる」という言説を耳にすることがあるかもしれません。しかし、それは半分正解で、半分はシステムを破壊する爆弾になり得ます。
今日は、WordPressの「心臓部」とも言えるオブジェクトキャッシュとTransient APIの真実、そして「あえてキャッシュしない」という高度な判断基準について、エンジニアとしての視座から解説します。
—
1. オブジェクトキャッシュの「本質」を知る
WordPressのオブジェクトキャッシュは、メモリ上にデータを一時保存する仕組みです。通常、DBへのクエリはコストが高い（遅い）ため、一度取得したデータをメモリに置いておき、二回目以降のアクセスを瞬時に返すのが目的ですね。
しかし、キャッシュは「最新性」と「速度」のトレードオフです。
データのライフサイクルをイメージする
1. Request Start: PHPが起動する。
2. Cache Hit?: Redisにデータがあるか確認。あればDBを叩かずに即座に値を返す。
3. Cache Miss: DBにSQLを投げる。結果をRedisに保存（`wp_cache_set`）してから返す。
この「メモリに置く」という行為は、実は魔法ではありません。メモリの確保、シリアライズ（データ変換）、通信コストが発生します。
—
2. なぜ「キャッシュしてはいけない」ケースがあるのか？
多くの開発者が陥る罠は、「すべてのデータをキャッシュ対象にしてしまうこと」です。以下の判断基準を満たす場合、キャッシュは無効化、あるいは即時反映させる設計が必要です。
キャッシュを避けるべき「3つの聖域」
1. リアルタイム性が生命線のデータ:
株価、在庫数、今日の限定クーポンなど。数秒のラグが致命的なビジネス機会損失になるもの。
2. ユーザー個別のパーソナライズデータ:
ログインユーザーの「お気に入り一覧」や「閲覧履歴」。これらをキャッシュすると、ユーザーAの画面にユーザーBの情報が表示されるという、セキュリティ事故（キャッシュ汚染）を引き起こします。
3. 書き込み頻度が極めて高いデータ:
アクセスログやカウンタなど。書き込みのたびにキャッシュの削除（パージ）と再生成を繰り返すと、DBを叩くよりもキャッシュサーバーの負荷が高まる「キャッシュスラッシング」が発生します。
—
3. コードで見る「キャッシュの境界線」
ここからは、実際に現場で使えるコードパターンを見ていきましょう。
実践：キャッシュすべきではないデータの扱い
例えば、「現在の在庫数」を表示する関数を作成する場合、キャッシュを使ってはいけません。
/
- 在庫数を取得する関数
- キャッシュを通さず、常にDBから直接取得する
/
function get_realtime_stock_count($product_id) {
global $wpdb;
// キャッシュを無視してDBへ直行する
// 直接クエリを投げることで、常に最新の在庫を保証する
$stock = $wpdb->get_var(
$wpdb->prepare(“SELECT stock_count FROM {$wpdb->prefix}products WHERE id = %d”, $product_id)
);
return (int)$stock;
}
逆に、キャッシュすべきデータのパターン
一方で、頻繁には変わらない「カテゴリーリスト」などは、積極的にキャッシュすべきです。
function get_cached_category_list() {
$cache_key = ‘my_custom_category_list’;
$list = wp_cache_get($cache_key);
if (false === $list) {
// キャッシュがない場合のみ取得
$list = get_categories();
// 3600秒（1時間）キャッシュする
wp_cache_set($cache_key, $list, ”, 3600);
}
return $list;
}
—
4. 陥りやすい罠とデバッグのコツ
「キャッシュ汚染」を防ぐキー設計
最も多いエラーは、全ユーザー共通のキーを使ってユーザー固有のデータを保存してしまうことです。
- 悪い例: `wp_cache_set(‘user_profile’, $data);`
- 良い例: `wp_cache_set(‘user_profile_’ . get_current_user_id(), $data);`
このように、キーにユーザーIDやコンテキストを含めることが、WordPressエンジニアのたしなみです。
キャッシュのクリア（インバリデーション）は慎重に
データが更新されたときに、古いキャッシュを消すのを忘れていませんか？ `save_post` などのフックを使い、対象データが更新された瞬間に `wp_cache_delete()` でキャッシュを破棄する設計が必要です。
—
最後に：エンジニアとして成長するために
WordPressのパフォーマンスを極めるということは、「どこでデータが生まれ、どこで消費され、いつ死ぬのか」というデータの流れ（ライフサイクル）を支配することです。
- データが変わらないならキャッシュする。
- データが常に動くならDBを信じる。
- ユーザー固有ならコンテキストをキーに混ぜる。
この境界線が見えてくると、あなたの作るサイトは重たいCMSから、高効率なデータ駆動型アプリケーションへと進化します。
まずは、自分の書いているコードが「どこにデータを保存しているか」「いつそのデータは最新ではなくなるか」を紙に書き出してみてください。それが、WordPressを掌握する第一歩です。
ここをクリアすれば、あなたはもうWordPressの基礎を完全にマスターしたと言えます。自信を持って、次の実装に進んでくださいね！応援しています。