サイトヘルスの「永続オブジェクトキャッシュを使用してください」に、エックスサーバーで向き合った記録

2026 年 4 月のある日。WordPress の管理画面で「ツール → サイトヘルス」を開いたら、前日まで無かったはずの一文が増えていて、手が止まりました。「永続オブジェクトキャッシュを使用してください」。最初に頭をよぎったのは、何か壊したかもしれない、という不安です。プラグインを入れすぎたか、設定をいじったせいか、と心当たりを探しました。

先に答えを書いておくと、これはエラーではありません。WordPress が「やっておくと良いですよ」と勧めてくる、推奨レベルの提案です。個人ブログや小規模サイトなら、放置してもサイトは普通に動きます。実際、私はしばらく放置していましたが、表示にも投稿にも何の支障もありませんでした。ただ、正体を理解したうえで「自分のサイトでは対処すべきか、放置すべきか」を判断できるようになっておくと、サイトヘルスを開くたびに胸がざわつくこともなくなります。この記事は、その警告に私がエックスサーバーでどう向き合い、何を選び、結果どうだったかの記録です。サーバーによって取れる手段が変わるので、自分以外の環境についても調べた範囲を添えています。

実際に表示された警告。前日まで無かったので、最初は「何かやらかした」と身構えました。

検証環境：WordPress 6.9.4 / PHP 8.3.21 / Cocoon 2.9.1.1 / エックスサーバー スタンダードプラン（2026年4月時点）。確認日：2026年4月。なお、エックスサーバー以外のサーバーは私自身が実機検証したわけではなく、各社の公式情報と公開されている報告をもとに整理しています。その点は正直にお断りしておきます。

「永続オブジェクトキャッシュ」とは、何をためておく仕組みなのか

この警告を理解するには、WordPress が普段どうやってページを表示しているかを知っておくと早いです。WordPress は動的な CMS です。誰かがページを開くたびに、PHP がデータベース（MySQL や MariaDB）へ「この投稿の本文は？」「サイトのタイトルは？」「このウィジェットの中身は？」と何度も問い合わせ、その場で HTML を組み立てて返しています。たった1ページを表示するだけでも、数十回から数百回のデータベースへの問い合わせが走ることがあります。プラグインが増えるほど、その回数は膨らみます。私のブログでも、どれくらい問い合わせが起きているのか気になって、Query Monitor というプラグインで計測してみました。トップページを開いただけで、データベースへの問い合わせが約120回。正直、思っていたより多いというのが第一印象でした。アクセスが重なれば、その回数ぶんデータベースに負荷がかかり、表示が遅くなっていきます。

Query Monitor で見たトップページのクエリ数。1ページの表示で約120回の問い合わせが起きていました。プラグインを増やすほど、ここは膨らみます。

WordPress にも、この負荷をやわらげる仕組みは最初から入っています。WP_Object_Cache というクラスがそれで、一度データベースから取ってきたデータを PHP のメモリに置いておき、同じページの処理中に同じデータが必要になったら、データベースではなくメモリから返してくれます。ただ、ここに大きな前提があります。標準のオブジェクトキャッシュは「非永続」です。1回のページ表示が終わった瞬間に、ためておいたキャッシュは全部捨てられます。次の人が同じページを開けば、また一からデータベースに問い合わせ直しです。

非永続と永続の違いを1枚にした図。ページが終わると捨てるか、またいで使い回すか、の差です。

永続オブジェクトキャッシュは、この「ページが終わっても捨てない」を実現する仕組みです。複数のアクセスをまたいでキャッシュを使い回せるので、毎回データベースに同じことを聞きにいく無駄が減ります。WordPress の公式ドキュメントでも、永続オブジェクトキャッシュはサーバーからデータベースへの往復を減らし、読み込み時間を改善する手段として説明されています（参考：WordPress 公式ドキュメント「最適化」、確認日 2026年4月）。この「ためておく場所」には、いくつか種類があります。代表的なものを整理しておきます。

自分のサーバーで何が使えるかは、サイトヘルスが教えてくれます。私の環境では「お使いのホスティングサービスでは、次のオブジェクトキャッシュサービスをサポートしているようです: APCu」と表示されていました。この一文が、どの手段を選べばいいかの出発点になります。

サイトヘルスが「APCu が使えますよ」と教えてくれている画面（エックスサーバー環境）。ここを見れば、自分が取れる手段が分かります。まずこの一文を探してください。

なぜ急に出てきたのか、焦らなくていい理由を説明します

「昨日まで無かったのに」と私が戸惑ったのには、理由があります。この推奨項目は、WordPress 6.1（2022年11月）からサイトヘルスに追加されたものです。WordPress 6.0 以前を使っていた人にとっては見覚えがない表示で、アップデート後に突然現れて驚く、という流れになりがちです。私もまさにそのパターンで、設定を触った記憶はないのに、としばらく原因を探してしまいました。しかも、この警告はインストール直後のサイトには出ません。投稿数やデータが増えて、サイトがある程度の規模になってから表示されるようです。具体的な基準は公開されていませんが、数十記事を超えたあたりで見かけるという話をよく聞きます。育ってきた証、くらいに受け止めてよいものです。大事なのは、これがサイトヘルスの分類でいう「推奨」であって、エラーや障害ではない、という点です。下の図のとおり、サイトヘルスの表示には段階があります。

対処すべきか放置でいいかは、サイトの性格で決まります

正体が分かったところで、次に迷うのが「で、自分は対処すべきなの？」です。ここは正直、サイトの性格によります。私が調べたり試したりしながら引いた線引きを、表にまとめました。

放置は立派な選択です。ここで、私自身の実測も正直に共有しておきます。期待しすぎないでほしいからです。

対処すべきか放置でいいかの簡易フロー。迷ったら、まず表示速度に不満があるかどうかで分けると考えやすいです。

【方法①】私が実際にやったのは、プラグインでの解決でした

私が選んだのは、いちばん手軽なプラグインでの対処でした。エックスサーバーは APCu が使えるので、それを前提にした「APCu Manager」というプラグインです。サイトヘルスに「APCu」と出ていたら、この方法が使えます。導入は拍子抜けするほど簡単でした。実際の手順はこうです。

1. 管理画面の「プラグイン」→「新規追加」を開く
2. 検索欄に「APCu Manager」と入力して検索する
3. 「今すぐインストール」をクリックし、終わったら「有効化」する
4. 左メニューに出てくる「Settings」を開く
5. 設定画面の一番上「Object cache」にチェックを入れる
6. ほかの項目はチェックを外したままで構わない
7. 最下部の「変更を保存」をクリックする

APCu Manager の設定。「Object cache」にチェックを入れて保存するだけでした。ほかの項目は触っていません。

これだけです。サイトヘルスを開き直すと、あれだけ気になっていた警告が消えていました。エックスサーバーでの作業時間は、検索して入れて設定して、ぜんぶで2分ほど。トラブルらしいトラブルもありませんでした。

導入の前と後。警告が消えたサイトヘルスです。

APCu Manager 以外にも選択肢はあります。私は使い分けていませんが、調べた範囲で性格の違いを書いておきます。多機能なものが好きなら「W3 Total Cache」があります。オブジェクトキャッシュだけでなく、ページキャッシュやブラウザキャッシュ、CDN 連携まで一つで管理できる定番です。ただし設定項目がとても多いので、オブジェクトキャッシュ目的だけなら、Object Cache を Enable にして方式（APCu が使えるなら APCu）を選ぶ以外は、デフォルトのままで触らないのが無難です。

W3 Total Cache の Object Cache 設定。多機能なぶん、目的の項目以外は触らないほうが安全です。

「APCu Manager は専用すぎるし、W3 Total Cache は多すぎる」という中間が欲しいなら、Powered Cache という選択肢もあります。設定画面に APCu の項目がはっきりあり、操作も直感的です。日本ではまだマイナーですが、キャッシュ機能をこれ一つに寄せたい人には合うはずです。

Powered Cache の設定。Object Cache で「APCu」を選べます。

VPS やクラウドなど Redis が使える環境なら、「Redis Object Cache」が王道です。プラグインを入れて「Enable Object Cache」を押し、Status が「Connected」になれば成功です。ただし前提として、サーバー側で Redis が動いている必要があります。共有レンタルサーバーでは Redis が使えないことが多いので、事前にホスティング会社へ確認してください。Status が「Not Connected」のままなら、Redis が起動していないか接続設定の問題です。

Redis Object Cache が「Connected」になった状態。ここまで来れば警告は消えます。

Redis も Memcached も APCu も使えない、という八方塞がりの環境には、PHP の OPcache を使って永続キャッシュを実現する Docket Cache という手があります。WordPress 公式でも、Redis や Memcached が使えない人向けの代替として触れられています。入れて有効化するだけで動くので、最後の手段として覚えておくと安心です。ロリポップのハイスピードプランなどで使われている LiteSpeed Web サーバーなら、LiteSpeed Cache にオブジェクトキャッシュ機能が含まれています。ただし注意があって、これは裏側で Memcached か Redis を使う仕組みなので、サーバー側でそれらが有効になっていないと、プラグインを「有効化」してもキャッシュが実際には効かないことがあります。設定画面で「Memcached 拡張機能が無効」などと出ていないか、確認が要ります。

【方法②】警告だけ消す方法は、効果はないが副作用もありません

「キャッシュを入れるほどではないけど、サイトヘルスに警告が残っているのがどうも気になる」。その気持ちはよく分かります。そういうときは、子テーマの functions.php に1行足すだけで、提案そのものを止められます。

このフィルターは、WordPress が永続オブジェクトキャッシュの提案を出すかどうかを決めている部分です。false を返すことで、提案自体を表示しなくします。正直に言えば、これは対症療法です。速くなるわけではありません。あくまで「画面から警告を消すだけ」です。それでも、1行で済んでプラグインも要らず、副作用のリスクもないので、「サーバーがキャッシュに対応していない」「速度に不満はないが表示だけ片付けたい」というケースには、これがいちばん現実的だと思います。私自身はエックスサーバーで APCu が使えたので使いませんでしたが、対応していないサーバーの友人には、この方法を勧めています。

【方法③】SSH で Redis を自前で入れる道もあります（中〜上級者向け）

SSH が使える環境なら、Redis をサーバーに直接入れて、本格的に運用する道もあります。効果はいちばん大きいですが、コマンドライン操作が必要なので、自信のある人向けです。私はエックスサーバーで APCu で足りているため常用はしていませんが、検証として触った範囲で流れを残しておきます。大まかには4ステップです。まず WordPress 側に Redis Object Cache プラグインを入れておきます（この時点では Status は Not Connected のままで正常です）。次に SSH でサーバーに入り、Redis を起動します。

レンタルサーバーでは管理者権限がなく systemctl が使えないことがほとんどなので、サーバー再起動後の自動起動は Cron で面倒を見ます。

Redis が無事に動けば、プラグイン側の Status が「Connected」に変わり、サイトヘルスの警告も消えます。このあたりの SSH 接続や Cron の扱いは、別の記事で実際にハマった経験を書いています。エックスサーバーで Cron がうまく動かず、最終的に WP-CLI で解決した話なので、サーバー操作に不安がある方はあわせてどうぞ。

なお、エックスサーバーではプラグインを使わず、APCu 用のドロップインファイル（wp-content/object-cache.php）を直接置く方法もあります。GitHub にある APCu 用の object-cache.php を配置し、wp-config.php にキーソルトを1行足す形です。プラグインを増やしたくない人には向きますが、手動管理になるので、初心者の方には素直に APCu Manager をおすすめします。

サーバー別に、何を選べばいいかをまとめました

ここまでの内容を、日本でよく使われるサーバーごとに整理しておきます。繰り返しになりますが、エックスサーバー以外は私が実機検証したものではなく、各社の公式情報と公開されている報告にもとづく整理です。最終的にはご自身のサイトヘルスの表示を確認してください。

サーバー別のバックエンド対応マップ。APCu 系か、Redis 系か、非対応か、の3グループで見ると分かりやすいです。

エックスサーバーは APCu が標準で有効なので、私のように APCu Manager で2分で片付きます。スタンダードプラン以上なら問題なく動きました。ロリポップは公式に「永続オブジェクトキャッシュは使用できない」と明記されていて、代替としてアクセラレータや LiteSpeed Cache が案内されています。mixhost は Memcached も Redis も無効化されているため、LiteSpeed Cache を入れてもバックエンドが動かず、functions.php での非表示が現実的です。KUSANAGI は独自の bcache を持っているので、オブジェクトキャッシュのプラグインを足すと競合する可能性があり、安易な導入は勧められていません。

導入する前に、4つの落とし穴を知っておいてください

手軽とはいえ、キャッシュは「ためて使い回す」仕組みである以上、固有のリスクがあります。私が導入時に気をつけた点と、調べて知った事故例を、表にまとめました。

私が導入したときも、いきなり本番で有効にするのではなく、まず PageSpeed Insights のスコアと Query Monitor の数値を記録し、バックアップを取ってから作業しました。導入後に同じ条件で計測し直して、おかしくなっていないかを確認する。この往復をやっておくと、もし問題が起きても「どこを戻せばいいか」がすぐ分かります。

対処後のサイトヘルス。気になっていた項目が消えて、見るたびのもやもやがなくなりました。

Query Monitor で見た導入前後。体感は変わらなくても、問い合わせ回数やメモリ使用量は静かに減っていました。

結局、自分はどうすればいいのか

長くなったので、選び方をひとつの流れにまとめておきます。まず表示速度に不満がなければ放置で問題ありません（気になるなら functions.php で非表示）。不満があるなら、サーバーが Redis / Memcached に対応しているかを見て、対応していれば Redis Object Cache。していなければ APCu が使えるかをサイトヘルスで確認し、使えれば APCu Manager か Powered Cache。それも使えなければ Docket Cache か、functions.php での非表示、という順です。

対処法フローチャート。3つの質問に答えていくだけで、自分の取るべき手が決まります。

私の場合は、エックスサーバーで APCu が使えたので、APCu Manager を入れて2分で終わり、でした。劇的に速くなったわけではありませんが、サーバーへの問い合わせは確かに減りましたし、何よりサイトヘルスを開くたびの小さなストレスが消えました。あの警告を初めて見たとき、私は「何か壊した」と決めつけて、設定をあちこち触りそうになりました。でも実際は、壊れてなどいなくて、ただ WordPress が「やると良いことがありますよ」と勧めていただけでした。

そこで、最後にあなたに問いを残しておきます。いま、あなたのサイトヘルスには何が表示されていますか。そしてそれは、本当に「エラー」でしょうか。それとも、慌てて手を動かす前に一度意味を調べれば済む「推奨」でしょうか。赤も黄色も緑も、まずその一点を見分けるところから始めれば、次に知らない警告に出会っても、たぶんもう怖くないはずです。

WordPress キャッシュ関連の記事

• WP-Cron が動かない…エックスサーバーの cron で時間どおりのメール送信を取り戻した話 ── エックスサーバーでの SSH・Cron 操作の実体験。