キャッシュの「削除」と「更新」の極意：WordPressのオブジェクトキャッシュを完全に掌握する
WordPressにおいて、データベースへのクエリはパフォーマンスの最大ボトルネックだ。特に `WP_Query` や `get_post_meta` を多用する動的サイトでは、オブジェクトキャッシュ（Redis/Memcached）を導入しないことは、エンジニアとして「自らボトルネックを設計している」に等しい。
しかし、多くの開発者は「キャッシュの無効化（パージ）」のタイミングで躓く。キャッシュが古いままだとユーザー体験を損ない、頻繁にクリアしすぎればキャッシュヒット率が低下し、DBへの負荷が跳ね上がる。
今回は、「整合性を担保しつつ、パフォーマンスを最大化するキャッシュ戦略」を、実務レベルのコードで伝授する。
—
1. キャッシュ無効化の基本原則：Read-Through と Write-Through
キャッシュを制御する際、最も陥りやすい罠は「手動による複雑なロジックの埋め込み」だ。保守性を高めるためには、WordPressのフックシステムを最大限に活用し、データのライフサイクルにキャッシュのライフサイクルを同期させる必要がある。
基本的な原則はシンプルだ。
- Read: キャッシュがあれば返す。なければDBから取得し、キャッシュにセットする。
- Invalidate: データが更新された瞬間にキャッシュを「削除」する。
ここで重要：更新時にキャッシュを「更新」しようとしないこと。
「更新」は複雑な排他制御が必要になり、競合による不整合を生む。常に「削除」し、次回のアクセスで再生成させるのが最も堅牢なパターンだ。
—
2. 現場で使える「堅牢なキャッシュ設計」パターン
特定の投稿に関連するメタデータや、複雑な集計クエリの結果をキャッシュする場合、以下の設計がベストプラクティスだ。
実装例：`transient` を活用したクリーンな設計
/
- 複雑な集計結果を取得する関数
/
function get_complex_aggregated_data(int $post_id) {
$cache_key = “agg_data_{$post_id}”;
$data = get_transient($cache_key);
if (false === $data) {
// 重いクエリやAPI通信を実行
$data = perform_heavy_calculation($post_id);
// 12時間の有効期限を設定（キャッシュ汚染を防ぐ）
set_transient($cache_key, $data, 12 HOUR_IN_SECONDS);
}
return $data;
}
/
- 投稿更新時にキャッシュをパージするフック
- save_post_{post_type} を使い、特定の投稿タイプに限定する
/
add_action(‘save_post_post’, function($post_id) {
// 予期せぬ実行（リビジョンや自動保存）を排除
if (defined(‘DOING_AUTOSAVE’) && DOING_AUTOSAVE) return;
// キャッシュを削除するだけ。再生成は次の参照時まで待つ
delete_transient(“agg_data_{$post_id}”);
}, 10, 1);
なぜこのコードが「美しい」のか？
1. 関心の分離: キャッシュの管理ロジックと、データの生成ロジックが綺麗に分かれている。
2. 安全装置: `DOING_AUTOSAVE` チェックを怠らないこと。これがないと、編集画面を開いているだけで無数のキャッシュ削除処理が走り、DBとRedisに無駄な負荷をかける。
3. 即時性: `save_post` フックを使用することで、管理画面での「更新」ボタン押下と同時にキャッシュが破棄されるため、ユーザーは確実に最新情報を得られる。
—
3. パフォーマンスを殺す「アンチパターン」の回避
実務で見かける「やってはいけないこと」を指摘しておく。
- キャッシュキーの衝突: キー名に `post_id` や `user_id` を含めず、汎用的な文字列にしているケース。これでは複数の投稿でキャッシュが混ざり、致命的なデータ漏洩や表示崩れを招く。必ず一意なIDを付与すること。
- キャッシュの「更新」をループ内で行う: 高負荷時にキャッシュの更新処理がDBロックを引き起こし、サイト全体をダウンさせる。更新ではなく、常に `delete_transient` を選択せよ。
- 無期限のキャッシュ: `set_transient` に期限を設けないのは自殺行為だ。Redisのメモリが枯渇し、LRU（Least Recently Used）アルゴリズムによって重要なキャッシュが勝手に追い出される。
—
4. プロの視点：スケーラビリティを高めるには
もし、アクセスが極めて多いサイトを運用しているのであれば、`transient` API だけでなく、`wp_cache_set` / `wp_cache_get` を使った オブジェクトキャッシュ（非永続） との併用を検討すべきだ。
- Transient API: DBに保存される。RedisがあればRedisに自動的に乗る。永続性がある。
- WP Object Cache: メモリに保存される。リクエスト内での使い回しに最適。
テクニカルリードからのアドバイス：
「まず、静的な計算結果は `wp_cache_set` でリクエスト内キャッシュを行い、その上で永続化が必要なものだけを `transient` で Redis に送る」という二段構えのキャッシュ戦略を構築せよ。
キャッシュは「魔法」ではない。データの流れを把握し、いつデータが「汚染」されるかを予測するロジックをコードに落とし込む。それが、WordPressを掌握するということだ。
君たちが書くコードが、明日のサイトのパフォーマンスを左右する。今日から、「ただ動くコード」ではなく「キャッシュのライフサイクルまで管理された美しいコード」を目指してほしい。