【実務・中級編】wp_cache_addとwp_cache_setの使い分け：Transient APIの内部挙動を読み解く – WordPress 内部コア・データベース構造とパフォーマンス最適化解析バイブル

WordPressを掌握する：`wp_cache_add` と `wp_cache_set` の深淵なる使い分け

WordPressのパフォーマンスを語る上で、`Transient API` は避けて通れない。しかし、多くのエンジニアは「とりあえず `set_transient` を使っておけばいい」という浅い理解で止まっている。

もし君が、高負荷な環境で「キャッシュの不整合」や「競合状態（Race Condition）」に悩まされているなら、それは `Transient API` の背後にある `Object Cache` の挙動を誤解している証拠だ。今回は、低レイヤーの視点からキャッシュ戦略を再構築する。

—

1. 内部構造：`wp_cache_set` と `wp_cache_add` の決定的な違い

WordPressの `Object Cache` は、メモリ内に存在する永続的（Redis/Memcached）または非永続的なストレージへの抽象レイヤーだ。

`wp_cache_set($key, $value, $group, $expire)`:

キーが存在しようがしまいが、強制的に上書きする。

`wp_cache_add($key, $value, $group, $expire)`:

キーが存在しない場合のみ値をセットする。既にキーが存在する場合は `false` を返す。

この「存在しない場合のみ」という特性が、高並列処理におけるアトミック（不可分）なロック機構として機能する。これを理解しているか否かが、プロダクションコードの堅牢性を決定づける。

—

2. なぜ Transient API は「危険」なのか

`set_transient` は内部で `wp_cache_set` を呼び出す。これは「後から来た処理が常に正」という前提に基づいている。

もし、複数のプロセスが同時に重いAPIレスポンスをキャッシュしようとしたらどうなるか？データベースや外部APIへのリクエストが重複して飛び、キャッシュサーバーへの書き込みが競合する。これは単なる無駄ではなく、DB負荷の増大とレスポンスタイムの不安定化を招く。

—

3. 実装の極意：競合を防ぐ「ロック・パターン」

高度なコンポーネント設計では、キャッシュ生成時に「誰かが既にキャッシュを作っていないか？」を厳密に管理する必要がある。以下は、私がプロダクション環境で採用している、スレッドセーフを意識したキャッシュ生成パターンだ。

競合を避けた堅牢なキャッシュ取得・生成パターン

/
function get_optimized_data(string $cache_key, callable $fallback_callback, int $ttl = 3600) {
$data = wp_cache_get($cache_key, ‘my_app_group’);

if (false !== $data) {
return $data;
}

// キャッシュが存在しない場合、生成の権利を得るためのロックを試みる
$lock_key = $cache_key . ‘_lock’;

// wp_cache_add はアトミック。複数のリクエストが同時に来ても、
// 成功するのは1つだけである。
if (wp_cache_add($lock_key, ‘locked’, ‘my_app_group’, 10)) {

// 生成処理（重いAPIコールなど）
$data = $fallback_callback();

// キャッシュを更新
wp_cache_set($cache_key, $data, ‘my_app_group’, $ttl);

// ロック解除
wp_cache_delete($lock_key, ‘my_app_group’);

return $data;
}

// ロックが取れなかった場合は、別のプロセスが生成中なので少し待機するか、
// 古いデータがあればそれを返すなどのフォールバックを行う
usleep(100000); // 0.1秒待機
return get_optimized_data($cache_key, $fallback_callback, $ttl);
}

なぜこのコードが美しいのか

1. アトミックな競合回避: `wp_cache_add` を利用して「生成中である」というステータスを共有メモリ上にロックしている。
2. Dogpile Effect（キャッシュ雪崩）の防止: 複数のリクエストが同時にAPIへ向かうのを防ぎ、システム全体のレイテンシを安定させる。
3. 疎結合: `$fallback_callback` を渡すことで、データ取得ロジックとキャッシュ制御ロジックが完全に分離されている。

—

4. パフォーマンス最適化の注意点

グループの活用: `wp_cache_get($key, $group)` のグループ引数を活用せよ。Redisの場合、これは名前空間として機能し、キャッシュのフラッシュやデバッグ時に圧倒的に管理しやすくなる。
シリアライズのコスト: WordPressはメモリに保存する際、自動的にシリアライズを行う。巨大なオブジェクトをキャッシュすると、取得のたびにデシリアライズコストが発生する。可能な限りプリミティブな型（配列や文字列）に変換してから保存する癖をつけよ。
Redisの `GET` コスト: 必要以上にキャッシュキーを細分化しすぎると、Redisのオーバーヘッドが無視できなくなる。キー設計は「論理的な単位」でまとめろ。

—

最後に：伝説的コントリビューターからのメッセージ

「動くコード」を書くのはジュニアエンジニアの仕事だ。しかし、「高負荷下でも静かに、かつ確実に動くコード」を書くのが、システムを設計する者の責務である。

WordPressは、その柔軟性ゆえに「甘い設計」を許容してしまう。だが、コアの深層部には `wp_cache_add` のような、堅牢なシステムを構築するための強力なツールが隠されている。

次回のコードレビューで、`set_transient` を盲目的に使っているコードを見つけたら、この記事を突きつけてやってほしい。真のエンジニアリングとは、APIの利便性ではなく、その裏側にある「データの整合性と実行効率」を支配することにあるのだから。