WordPressのTransientsを永続オブジェクトキャッシュ（Redis等）に保存する設定と確認方法

Transients API（set_transient() / get_transient()）は、永続オブジェクトキャッシュが有効なサイトでは自動的に Redis や Memcached に保存先が切り替わります。つまり「Transients をオブジェクトキャッシュのバックエンドで動かす」ために Transients 側の設定は不要で、必要なのは object-cache.php ドロップインを正しく導入することです。この記事では、保存先が切り替わる仕組み、Redis を使った設定手順、切り替わったかどうかの確認方法、移行時につまずきやすい点を順に説明します。

Transients の保存先が決まる仕組み

set_transient() は内部で wp_using_ext_object_cache() を確認しています。この関数が true を返すとき、つまり wp-content/object-cache.php というドロップインが読み込まれて外部のキャッシュが使われているとき、値は wp_cache_set() を通じて transient グループに書き込まれます。マルチサイト全体で共有する set_site_transient() は site-transient グループです。

ドロップインが無い場合は、データベースの wp_options テーブルに _transient_{名前} と _transient_timeout_{名前} の2行として保存されます。有効期限を指定しなかった Transient は自動読み込み（autoload）の対象になるため、数が増えるとページ表示のたびに読み込まれるオプションが膨らみます。永続オブジェクトキャッシュへ移すと、この wp_options の肥大化を避けられるのが大きな利点です。

注意したいのは、コアに最初から入っている WP_Object_Cache はリクエストの間だけメモリに値を持つ「非永続」のキャッシュだという点です。何もしなければ Transients はデータベースに残ります。外部キャッシュに載せるには、Redis などのサーバーと、それにつなぐドロップインの両方が必要です。

前提条件と事前準備

作業の前に次の点を確認してください。

• サーバーで Redis（または Memcached）が動いていて、PHP から接続できること。Redis の場合は PHP 拡張の phpredis が入っているか、ドロップイン側が対応する接続ライブラリを用意していること
• 共用サーバーでは、管理画面やサーバーパネルでオブジェクトキャッシュを提供している場合があります。その場合は事業者の手順に従うほうが安全です
• データベースと wp-content のバックアップを取り、まずステージング環境で試すこと

同じ Redis を複数のサイトで共有する場合は、キーが衝突しないようにサイトごとの接頭辞（プレフィックス）かデータベース番号を分けます。これを忘れると、別サイトの Transient を読んでしまうという分かりにくい不具合になります。

Redis Object Cache プラグインで有効化する手順

ここでは WordPress.org で配布されている Redis Object Cache プラグインを例にします。管理画面の項目名はバージョンによって変わることがあるため、目的ベースで説明します（2026年10月現在の構成をもとにしています）。

まず wp-config.php の「編集はここまで」のコメントより上に接続設定を書きます。値は自分の環境に合わせて変えてください。

// wp-config.php（例）
define( 'WP_REDIS_HOST', '127.0.0.1' );
define( 'WP_REDIS_PORT', 6379 );
define( 'WP_REDIS_DATABASE', 0 );
define( 'WP_REDIS_PREFIX', 'example_com:' );
// 認証を設定している場合のみ。実際の値はリポジトリに含めない
// define( 'WP_REDIS_PASSWORD', 'your-redis-password' );

次にプラグインを有効化し、設定画面からオブジェクトキャッシュを有効にします。この操作で wp-content/object-cache.php が配置されます。WP-CLI が使える環境ではコマンドでも同じことができます。

wp plugin install redis-cache --activate
wp redis enable
wp redis status

wp redis status で接続状態が「Connected」になっていれば、ドロップインが Redis に接続できています。ここで接続に失敗する場合は、ホスト名・ポート・認証設定・PHP 拡張の有無を順に確認します。

Transients が外部キャッシュに載ったか確認する

設定画面の表示だけでなく、Transient が実際にどこへ書かれているかを確認しておくと安心です。

# true なら外部オブジェクトキャッシュが使われている
wp eval 'var_dump( wp_using_ext_object_cache() );'

# テスト用の Transient を5分の期限で書き込む
wp transient set myprefix_test hello 300
wp transient get myprefix_test

# データベースには書かれていないことを確認（エラーになれば想定どおり）
wp option get _transient_myprefix_test

wp transient get で値が返り、wp option get では見つからなければ、Transient は外部キャッシュに保存されています。Redis 側でキーを見たい場合は redis-cli --scan --pattern '*myprefix_test*' のように探せますが、キー名の組み立て方はドロップインによって異なります。また redis-cli monitor は負荷が高いので本番では短時間にとどめてください。

WordPress 6.1 以降のサイトヘルスには永続オブジェクトキャッシュの利用を勧める項目があり、有効化後はこの指摘が消えるかどうかも目安になります。

外部キャッシュ前提でつまずきやすい点

期限前に値が消えることがある

Redis はメモリ上限に達すると、設定された退避ポリシーに従ってキーを削除します。Transient は「指定した期限までは残っている保証のないキャッシュ」です。get_transient() が false を返したら作り直す、という書き方を守っていれば問題になりません。逆に、設定値や注文情報のような消えては困るデータを Transient に入れるのは避け、オプションや投稿メタに保存します。

function myprefix_get_popular_post_ids() {
    $key = 'myprefix_popular_ids_v1';
    $ids = get_transient( $key );

    if ( false === $ids ) {
        $query = new WP_Query( array(
            'posts_per_page'      => 5,
            'orderby'             => 'comment_count',
            'ignore_sticky_posts' => true,
            'no_found_rows'       => true,
            'fields'              => 'ids',
        ) );
        $ids = $query->posts;
        set_transient( $key, $ids, 15 * MINUTE_IN_SECONDS );
    }

    return $ids;
}

// 投稿が保存されたら作り直させる
add_action( 'save_post', function () {
    delete_transient( 'myprefix_popular_ids_v1' );
} );

値そのものに false を保存すると「キャッシュが無い」と区別できなくなるため、空の結果は空配列などで保存します。

期限なしの Transient の扱いが変わる

データベース保存では期限なしの Transient は自動読み込みされ、削除されるまで残ります。外部キャッシュでは期限なしのキーはメモリが足りる間だけ残り、退避の対象にもなります。期限は用途に合わせて明示しておくほうが、どちらの保存先でも挙動が読みやすくなります。

移行前の古い Transient が wp_options に残る

外部キャッシュを有効にしても、それまで wp_options に書かれていた Transient は自動では消えません。参照されなくなった行が残るだけなので、有効化の前に wp transient delete --all で整理しておくと後で迷いません。有効化後にこのコマンドを実行すると、WP-CLI はデータベース側だけを対象にする旨を表示します。外部キャッシュ側の Transient を消したいときは wp cache flush を使いますが、Transient 以外のキャッシュもまとめて消える点に注意してください。

Redis が止まったときの復旧手段を用意する

Redis が停止したり接続情報が変わったりすると、ドロップインの実装によっては管理画面に入れなくなることがあります。そのときは FTP やファイルマネージャーで wp-content/object-cache.php を別名に変えれば、データベース保存に戻って表示が回復します。復旧手順を運用メモに残しておくと、深夜の障害でも慌てずに済みます。

キャッシュプラグインとの重複

ページキャッシュ系のプラグインにもオブジェクトキャッシュ機能を持つものがあります。object-cache.php は1つしか置けないため、複数のプラグインで同時に有効にしようとすると上書きや競合が起きます。どのプラグインがドロップインを管理しているかを決めて、ほかは無効にしておきます。

Transients と wp_cache 関数の使い分け

外部キャッシュが常にある環境なら、wp_cache_set() / wp_cache_get() を独自グループで直接使う方法もあります。ただし外部キャッシュが無い環境では wp_cache_* はリクエスト内でしか保持されません。配布するプラグインや、環境が変わる可能性があるテーマでは、どちらの環境でも期限つきで残る Transients を使うほうが扱いやすいです。自社サーバーで Redis が前提と決まっているなら、グループを分けられる wp_cache_* で管理する選択肢も検討できます。

まとめ

• Transients は object-cache.php ドロップインがあると自動的に外部キャッシュへ保存される。Transients 側の設定は不要
• Redis Object Cache プラグインなら wp-config.php に接続設定を書き、有効化後に wp redis status で接続を確認する
• wp_using_ext_object_cache() と wp option get _transient_... で、実際の保存先を確かめる
• 外部キャッシュでは期限前に値が消えうる。false が返ったら作り直すコードにし、消えて困るデータは入れない
• 有効化前に古い Transient を整理し、Redis 障害時は object-cache.php を別名にして復旧できるようにしておく

• WordPressのRedis接続エラーの原因と対処法
• WordPressのTransientキャッシュを削除する方法