キャッシュは銀の弾丸ではない：WordPressオブジェクトキャッシュの「不都合な真実」と最適化戦略
WordPressのパフォーマンスチューニングにおいて、RedisやMemcachedを `wp-content/object-cache.php` 経由で導入することは、現代のエンジニアリングにおける「定石」だ。しかし、この定石を無批判に適用することは、時にシステムを肥大化させ、メモリという貴重な資源を浪費し、最悪の場合はデータの不整合（Race Condition）を招く。
本稿では、オブジェクトキャッシュを「あえて無効化する」という選択肢を、システムアーキテクチャの観点から深掘りする。
—
1. オブジェクトキャッシュの「見えないコスト」
WordPressの `WP_Object_Cache` クラスは、メモリ上の揮発性データストアだ。これをRedis等の永続化キャッシュに置き換えると、全ての `get_option` や `get_post` がネットワーク越しの通信を伴うようになる。
誤解されているボトルネック
- シリアライズ/デシリアライズのオーバーヘッド: 複雑なオブジェクトをキャッシュする際、PHPの `serialize()` と `unserialize()` がCPUを消費する。大規模な配列を頻繁に読み書きする環境では、キャッシュヒット率が高いにもかかわらず、CPUロードが跳ね上がる現象が起きる。
- キャッシュのコールドスタートとメモリ断片化: キャッシュサーバー（Redis）のメモリが溢れた際、LRU（Least Recently Used）アルゴリズムが働く。この「追い出し（Eviction）」の発生は、最悪の場合、データベースへのクエリが集中する「キャッシュ雪崩（Cache Stampede）」を引き起こす。
—
2. キャッシュを無効化すべき「境界線」
シニアエンジニアは、何をキャッシュすべきかではなく、「何をキャッシュすべきでないか」を設計する。以下の基準に該当するデータは、キャッシュ層から排除すべきである。
① 高頻度な書き込みが発生するデータ
秒単位で更新されるユーザーの最終ログイン日時や、リアルタイムのカウンターなどはキャッシュすべきではない。これらのデータは `wp_options` に直接書き込まれ、さらにキャッシュが無効化されることで、データベースとキャッシュサーバーの両方に負荷をかける「二重の書き込み負荷」を生む。
② 機密性の高い動的セッションデータ
セキュリティの観点から、権限チェックのメタデータや一時的なセキュリティトークンをキャッシュするのはリスクがある。キャッシュサーバーが物理的にセキュアでない場合、そこが攻撃のベクター（情報漏洩の入り口）となる。
③ インスタンスごとの一過性データ
`WP_Query` の結果のうち、ページネーションを含んだ特定のクエリは、キャッシュの粒度を細かくしすぎると「キャッシュのヒット率」が低下し、管理コストだけが増大する。
—
3. 実装レベルでの制御：`wp_cache_delete` の先へ
特定の処理でオブジェクトキャッシュを無視したい場合、単にキャッシュをオフにするのではなく、`wp_cache_set` のフラグや、内部グローバル変数を利用した制御を行うべきだ。
以下のコードは、特定の高負荷処理において、オブジェクトキャッシュの共有メモリを利用せず、リクエスト内完結の静的変数（Static Variable）のみを利用する設計パターンである。
/
- データベースから直接取得し、外部オブジェクトキャッシュをバイパスする
- @param int $post_id
- @return WP_Post|null
/
function get_post_bypass_object_cache( $post_id ) {
global $wpdb;
// 外部のRedis/Memcachedを参照させないためのフラグ制御
// WordPressのコア内部では直接制御できないため、wpdbを直接叩くのが最も低レイヤで確実
$query = $wpdb->prepare( “SELECT FROM {$wpdb->posts} WHERE ID = %d LIMIT 1”, $post_id );
// キャッシュを汚染しない（キャッシュサーバーに書き込まない）
return $wpdb->get_row( $query );
}
—
4. 究極のパフォーマンス：キャッシュ無効化の判断基準（まとめ）
アーキテクトが判断を下すためのチェックリストを提示する。
1. データ寿命はどの程度か？: 更新頻度が1分未満なら、キャッシュせずデータベースのバッファ（InnoDB Buffer Pool）に任せるべきだ。
2. キャッシュサイズは最適か？: 1つのキーに数MBの配列を保存していないか？（Redisの `bigkey` はパフォーマンスを劇的に劣化させる）。
3. DBへのクエリ負荷は本当に高いか？: 適切なインデックスが貼られていれば、インメモリキャッシュよりもMySQLのインデックス検索の方が高速な場合がある。
結論：システムは「引き算」で作る
優れたエンジニアは、技術を導入するのではなく、技術を取り除くことで最適解を導き出す。オブジェクトキャッシュは強力な武器だが、それを盲目的に信じるのは初学者の過ちだ。
「キャッシュしないこと」によるパフォーマンス低下と、「キャッシュすること」による複雑性・オーバーヘッドのコスト。 このトレードオフを冷徹に計算できる者だけが、WordPressという巨大なランタイムを完全に掌握できる。
今のシステムにおいて、本当にそのデータはキャッシュが必要なのか？ 今一度、コードの深層を見つめ直してほしい。