キャッシュは「思考停止」の逃げ場所ではない。WordPressオブジェクトキャッシュをあえて「無効化」する設計論
WordPressのパフォーマンスチューニングにおいて、RedisやMemcachedを用いたObject Cache（`wp_cache_` 系関数）の導入は、もはやデファクトスタンダードだ。データベースへのクエリを減らし、メモリ上でデータをハンドリングする。これ自体は正しい。
しかし、「とりあえず全部キャッシュしておけ」という安易な設計は、システムを脆弱にする。
真のエンジニアは、キャッシュの背後にある「データの寿命（TTL）」と「整合性の崩壊リスク」を常に冷徹に見極めている。本稿では、あえてキャッシュを無効化、あるいはバイパスすべき境界線と、それを実現するための堅牢な設計パターンを伝授する。
—
1. なぜキャッシュが「毒」になるのか：負のケーススタディ
以下のケースでは、キャッシュを適用するよりも、直接DBを叩く（あるいはキャッシュをスキップする）方がシステムの健全性が保たれる。
- 「即時性」がUXの核となる場合:
在庫数、リアルタイムの入札価格、権限ベースのアクセス制御データ。これらがキャッシュによって数秒でも遅延すると、ビジネスロジック上の致命的なエラー（オーバーセルなど）を招く。
- 「書き込み頻度」が極めて高いデータ:
高トラフィックなサイトで、頻繁に更新されるメタデータ（例：PVカウンタ、最終ログイン時刻）。キャッシュの更新（Invalidation）と読み込みが競合し、CPUを浪費する「キャッシュ・スラッシング」が発生する。
- 非決定論的なデータ:
現在のユーザーのコンテキストによって結果が激しく変化する動的なデータ。キー設計が複雑化しすぎると、キャッシュミス率が上がり、逆にDBへの負荷を増大させる。
—
2. WordPressでキャッシュを「意図的にバイパス」する設計パターン
WordPressの `wp_cache_get` は非常に強力だが、制御不能なキャッシュほど恐ろしいものはない。ここでは、実務で使える「キャッシュ制御のパターン」を提示する。
A. 低レイヤーでのキャッシュバイパス（Direct DB Query）
特定の高頻度更新データに対しては、WordPressの抽象化層を通さず、直接的なクエリを発行して最新値を取得し、キャッシュ層をバイパスさせるのが最も確実だ。
/
- リアルタイム性が求められる在庫数の取得
- Object Cacheをスキップし、DBから最新状態を強制取得する
/
function get_realtime_inventory(int $product_id): int {
global $wpdb;
// キャッシュ層を経由せず、直接SQLを実行
// wp_cache_get() は呼ばない。これによりRedis等のキャッシュ状態に依存しない
$query = $wpdb->prepare(
“SELECT stock_count FROM {$wpdb->prefix}product_inventory WHERE product_id = %d”,
$product_id
);
$stock = $wpdb->get_var($query);
return (int) $stock;
}
B. `transient` の「不整合」を防ぐアトミックな更新
キャッシュを無効化できないが、データ整合性が重要な場合は、「キャッシュを更新する」のではなく「キャッシュを削除して、次のリクエストで再生成させる」のが鉄則だ。
/
- 堅牢なキャッシュ更新パターン
- 更新時にキャッシュを削除し、DBへの書き込みを優先する
/
function update_product_metadata(int $product_id, array $data): void {
// 1. まずDBを更新
// update_post_meta($product_id, ‘…’, …);
// 2. キャッシュを即座に破棄（Flush）
// 更新した値が他リクエストに見える前にキャッシュを消すのが肝
wp_cache_delete(“product_meta_{$product_id}”, ‘product_group’);
}
—
3. パフォーマンス最適化の「境界線」をどう引くか
「何をキャッシュすべきか」という問いに対して、私は以下の3つの軸で判断を下している。
1. Read/Write Ratio (R/W比): 100回読まれて1回更新されるならキャッシュの価値がある。逆に、1回読まれて1回更新されるなら、キャッシュはただのオーバーヘッドである。
2. 計算コスト: DBクエリの結果を加工するプロセスが、PHPの実行時間やメモリを圧迫しているか？ そうでなければキャッシュする意味は薄い。
3. 整合性の許容度: 1秒前のデータが表示されても、ユーザー体験に影響はないか？ なければキャッシュすべきだ。あれば、即座に無効化ロジックを組むべきだ。
—
結論：エンジニアの責務
WordPressの内部構造を知り尽くした者であれば、キャッシュを「魔法の杖」とは考えないはずだ。キャッシュはあくまで、「コストのかかる処理を一時的に退避させるためのバッファ」に過ぎない。
システムが複雑になればなるほど、「あえてキャッシュしない」という選択が、最もバグを生まず、結果としてパフォーマンスを最大化する。
次にあなたがコードを書くとき、そのクエリは「本当にキャッシュすべきか？」と自問自答してほしい。その一瞬の疑念こそが、堅牢なシステムを構築するための第一歩となる。
—
追伸：もし Redis のメモリ枯渇に悩んでいるなら、キャッシュ戦略を見直す前に、キャッシュの TTL（有効期限）を適切に設計し、不要なオブジェクトがメモリを占有していないか `redis-cli` で `INFO memory` を叩くことから始めてください。それがプロの診断手順です。