2026 年 4 月のある日。WordPress の管理画面で「ツール → サイトヘルス」を開いたら、前日まで無かった一文が増えていて、手が止まりました。「永続オブジェクトキャッシュを使用してください」。最初に頭をよぎったのは、何か壊したかもしれない、という不安です。あなたも同じ画面で身構えたなら、先に答えだけ受け取ってください。これはエラーではなく、WordPress が「やっておくと良いですよ」と勧めてくる推奨です。個人ブログや小規模サイトなら、放置してもサイトは普通に動きます。私もしばらく放置していましたが、表示にも投稿にも支障はありませんでした。そして、私のエックスサーバー環境では、APCu Manager というプラグインを入れて2分で警告は消えました。
検証環境：WordPress 6.9.4 / PHP 8.3.21 / Cocoon 2.9.1.1 / エックスサーバー スタンダードプラン（2026年4月）。エックスサーバー以外は私の実機検証ではなく、各社の公式情報と公開報告にもとづく整理です。最終的にはご自身のサイトヘルスの表示を確認してください。
これは、何をためる仕組みなのか
WordPress は動的な CMS です。誰かがページを開くたび、PHP がデータベースへ「この投稿の本文は」「サイトのタイトルは」と何度も問い合わせ、その場で HTML を組み立てて返します。1ページの表示でも、数十回から数百回の問い合わせが走ることがある。私のブログでも気になって Query Monitor で測ったら、トップページを開いただけで約120回でした。思っていたより多い、というのが第一印象です。アクセスが重なれば、その回数ぶんデータベースに負荷がかかります。
WordPress には負荷をやわらげる仕組みが最初から入っていて、一度取ってきたデータを PHP のメモリに置き、同じページの処理中に再利用します。ただ大きな前提があって、標準のオブジェクトキャッシュは非永続です。1回のページ表示が終わった瞬間に、ためたキャッシュは全部捨てられます。次の人が同じページを開けば、また一から問い合わせ直し。永続オブジェクトキャッシュは、この「ページが終わっても捨てない」を実現して、複数のアクセスをまたいでキャッシュを使い回す仕組みです。ためる場所(バックエンド)には種類があり、本格運用なら Redis や Memcached、共有レンタルサーバーでは PHP の共有メモリを使う APCu が扱いやすい。エックスサーバーはこの APCu が使えます。自分の環境で何が使えるかは、サイトヘルスが「次のオブジェクトキャッシュサービスをサポートしているようです」と教えてくれるので、まずその一文を探してください。
なぜ急に出たのか、焦らなくていい理由
昨日まで無かったのに、と戸惑ったのには理由があります。この推奨は WordPress 6.1(2022年11月)からサイトヘルスに追加されたもので、6.0 以前から使っていると、アップデート後に突然現れて驚きます。しかもインストール直後には出ません。投稿やデータが増えてサイトがある程度の規模になってから表示されるようで、数十記事を超えたあたりで見かける、という話をよく聞きます。育ってきた証くらいに受け取ってよいものです。大事なのは、これがサイトヘルスの分類でいう「推奨」であって、エラーや障害ではないこと。この表示があっても、サイトの表示・動作・検索結果への直接の悪影響はありません。
対処すべきか、放置でいいか
正体が分かると、次に迷うのが「で、自分は対処すべきか」です。ここはサイトの性格によります。月に数万 PV 以上ある、WooCommerce のような動的処理の多い EC、ログインユーザーの多い会員制、プラグインが多くクエリが200回を超える、体感で遅い。こうしたサイトは対処を考える価値があります。逆に、個人ブログや小規模サイトで、表示速度に不満がなく、PageSpeed Insights のスコアにも困っていないなら、放置は立派な選択です。
期待しすぎないために、私の実測も正直に書きます。エックスサーバーで APCu Manager を入れる前と後で、PageSpeed Insights のスコアには目立った変化はありませんでした。入れたら一気に速くなる、を期待すると肩透かしを食らいます。一方で、Query Monitor で見るとメモリ使用量とデータベースへの問い合わせには改善がありました。体感がガラッと変わるより、サーバーへの負荷を静かに減らす、という性格のものです。
エックスサーバーでは、何をしたか
方法1：APCu Manager（私が選んだ手）
サイトヘルスに「APCu」と出ていたら、これが使えます。プラグインの新規追加で「APCu Manager」を入れて有効化し、左メニューの Settings を開いて、一番上の「Object cache」にチェックを入れて保存する。ほかの項目は触りません。これだけで、サイトヘルスを開き直すと警告が消えていました。検索して入れて設定して、ぜんぶで2分ほど。トラブルもありませんでした。注意は、APCu が単一サーバー向けのキャッシュだという点です。複数サーバーで負荷分散する環境では共有されないので向きませんが、共有レンタルサーバーで個人サイトを動かすなら、APCu で十分です。多機能な W3 Total Cache や、中間的な Powered Cache でも APCu を選べますが、目的がオブジェクトキャッシュだけなら APCu Manager がいちばん素直でした。
方法2：functions.php で警告だけ消す
キャッシュを入れるほどではないけれど、警告が残るのが気になる。そういうときは、子テーマの functions.php に1行足すと、提案そのものを止められます。
| 1 | add_filter( 'site_status_should_suggest_persistent_object_cache', '__return_false' ); |
正直に言えば対症療法で、速くなるわけではありません。画面から警告を消すだけです。それでも、1行で済んでプラグインも要らず、副作用のリスクもないので、サーバーがキャッシュに対応していない、速度に不満はないが表示だけ片付けたい、というケースには現実的です。私は APCu が使えたので使いませんでしたが、非対応サーバーの友人にはこれを勧めています。
方法3：SSH で Redis を自前で入れる（中〜上級）
SSH が使える環境なら、Redis をサーバーに直接入れて本格運用する道もあります。効果はいちばん大きいですが、コマンドライン操作が必要です。私はエックスサーバーで APCu で足りているので常用していません。流れは、WordPress に Redis Object Cache プラグインを入れておき(この時点では Not Connected で正常)、SSH で入って redis-server を起動し、プラグインの Status が Connected になれば完了、というものです。レンタルサーバーは systemctl が使えないことが多いので、再起動後の自動起動は Cron で面倒を見ます。
| 1 2 | # 5分ごとに生存確認して、落ちていたら起動し直す */5 * * * * pgrep redis-server || redis-server --daemonize yes --port 6379 |
この SSH と Cron の扱いでは、別件でエックスサーバーの cron がうまく動かず、最終的に WP-CLI で解決した話を別記事に書いています。サーバー操作に不安があれば、あわせてどうぞ。
サーバー別に、何を選ぶか
日本でよく使われるサーバーごとに整理します。繰り返しになりますが、エックスサーバー以外は公式情報と公開報告にもとづく整理です。
| サーバー | 使えるバックエンド | おすすめの対処 |
|---|---|---|
| エックスサーバー | APCu | APCu Manager / Powered Cache（実体験で確認済み） |
| ConoHa WING | APCu | APCu Manager |
| さくらのレンタルサーバー | APCu（プランによる） | APCu Manager |
| ロリポップ | 非対応 | functions.php で非表示 / LiteSpeed Cache（ハイスピード以上） |
| mixhost | 実質非対応 | functions.php で非表示 / Docket Cache |
| Cloudways / Kinsta | Redis | Redis Object Cache |
| KUSANAGI | Redis / Memcached | Redis Object Cache（bcache 競合に注意） |
ロリポップは公式に「永続オブジェクトキャッシュは使用できない」と明記し、代替を案内しています。mixhost は Memcached も Redis も無効化されているため、LiteSpeed Cache を入れてもバックエンドが動かず、非表示が現実的です。KUSANAGI は独自の bcache を持つので、プラグインを足すと競合する可能性があり、安易な導入は勧められていません。Redis も Memcached も APCu も使えない環境には、PHP の OPcache を使う Docket Cache という最後の手もあります。
導入前に知っておく落とし穴
キャッシュは「ためて使い回す」仕組みである以上、固有のリスクがあります。更新したのに古い内容が出る不整合は、設定を戻す前に、まずプラグイン管理画面からキャッシュをフラッシュする。オブジェクトキャッシュ系のプラグインは複数同時に有効化せず、必ず1つに絞る。そしてEC や会員制では、本番前にテスト環境で「ログインユーザーごとに表示が混ざらないか」を必ず確認してください。他人のデータが見える事故例も報告されています。ここだけは手を抜かないこと。相性の悪いプラグインで逆に遅くなることもあるので、導入は入れて終わりにせず、PageSpeed Insights と Query Monitor の数値を前後で記録し、バックアップを取ってから作業します。この往復をやっておくと、問題が起きてもどこを戻せばいいかがすぐ分かります。
結局、自分はどうすればいいか
選び方を一つの流れにします。まず表示速度に不満がなければ放置で問題ありません(気になるなら functions.php で非表示)。不満があるなら、サーバーが Redis / Memcached に対応していれば Redis Object Cache。していなければ、APCu が使えるかをサイトヘルスで確認し、使えれば APCu Manager か Powered Cache。それも使えなければ Docket Cache か、functions.php での非表示、という順です。あの警告を初めて見たとき、私は何か壊したと決めつけて設定をあちこち触りそうになりました。でも実際は壊れてなどおらず、WordPress が「やると良いことがありますよ」と勧めていただけでした。次に知らない警告に出会ったときも、まずサイトヘルスの色(良好・推奨・重大)を見分けるところから始めれば、たぶんもう怖くありません。
参考にした公式情報
- WordPress 公式：最適化（永続オブジェクトキャッシュ）（確認日 2026年4月）
- WordPress Developer：WP_Object_Cache クラスリファレンス（確認日 2026年4月）
関連記事
- 夜中だけ予約メールが届かない｜WP-Cron は「アクセスで動く」と知らずに半日溶かした話。エックスサーバーでの SSH・Cron 操作の実体験です。
コメント