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

WordPress の管理画面で「ツール → サイトヘルス」を開いたとき、見慣れない一文が出ていて手が止まった経験はないでしょうか。私の場合がまさにそれでした。

このブログ（Rapls Works）はエックスサーバーのスタンダードプランで動かしています。ある日サイトヘルスを開いたら、前日まで無かったはずのこの文章が増えていました。最初に頭をよぎったのは「何か壊したかもしれない」という不安です。プラグインを入れすぎたか、設定をいじったせいか、と心当たりを探しました。

結論を先に書いておくと、これはエラーではありません。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回のページ表示が終わった瞬間に、ためておいたキャッシュは全部捨てられます。次の人が同じページを開けば、また一からデータベースに問い合わせ直しです。

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

この「ためておく場所」には、いくつか種類があります。代表的なものを整理しておきます。

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

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

なぜ急に出てきたのか ― 焦らなくていい理由

「昨日まで無かったのに」と私が戸惑ったのには、理由があります。

この推奨項目は、WordPress 6.1（2022年11月）からサイトヘルスに追加されたものです。WordPress 6.0 以前を使っていた人にとっては見覚えがない表示で、アップデート後に突然現れて驚く、という流れになりがちです。私もまさにそのパターンで、「設定を触った記憶はないのに」としばらく原因を探してしまいました。

しかも、この警告はインストール直後のサイトには出ません。投稿数やデータが増えて、サイトがある程度の規模になってから表示されるようです。具体的な基準は公開されていませんが、数十記事を超えたあたりで見かけるという話をよく聞きます。育ってきた証、くらいに受け止めてよいものです。

対処すべきか、放置でいいか ― 私が考えた線引き

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

対処を考えたほうがいいのは、次のようなサイトです。月に数万PV以上ある、WooCommerce などで動的な処理が多い EC サイト、ログインユーザーの多い会員制サイト、プラグインを20個以上入れていてクエリ数が多い、サーバーの反応が体感で遅い、Query Monitor で見たらクエリが200回を超えていた――このあたりに当てはまるなら、対処する価値が出てきます。

逆に、個人ブログや小規模サイト、すでにページキャッシュ系プラグインを入れていて表示に不満がない、PageSpeed Insights のスコアにも困っていない、そもそもサーバーが Redis も Memcached も APCu も使えない、設定をいじるのが不安――こういう場合は、無理に手を出さなくて大丈夫です。放置は立派な選択です。

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

【方法①】プラグインで解決する ― 私が実際にやった方法

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

導入する前に知っておきたい、4つの落とし穴

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

ひとつ目は、キャッシュの不整合です。記事を更新したのに古い内容が表示される、設定を変えたのに反映されない、といった現象が起きることがあります。そういうときは、プラグインの管理画面からキャッシュをフラッシュ（クリア）すれば直ります。慌てて設定を戻す前に、まずキャッシュクリアを試してください。

ふたつ目は、プラグインの競合です。オブジェクトキャッシュ系のプラグインを複数同時に有効にしてはいけません。たとえば APCu Manager と W3 Total Cache のオブジェクトキャッシュを両方オンにすると、競合してサイトが不安定になることがあります。この手のプラグインは、必ず1つに絞ってください。

みっつ目は、これがいちばん怖いのですが、データリークです。特に EC サイトや会員制サイトで、設定を誤ると、あるユーザーの画面に別のユーザーの個人情報が表示されてしまう事故が起こり得ます。大規模なショップで実際に起きた例も報告されています。ログイン後の画面を扱うサイトでは、本番に入れる前にテスト環境で「他人のデータが見えないか」を必ず確認してください。

よっつ目は、逆に遅くなるケースです。一部のプラグインはオブジェクトキャッシュと相性が悪く、入れたら前より遅くなることがあります。だからこそ、導入は「入れて終わり」にせず、前後で必ず計測することが大事です。

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

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

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

長くなったので、選び方をひとつの流れにまとめておきます。

私の場合は、エックスサーバーで APCu が使えたので、APCu Manager を入れて2分で終わり、でした。劇的に速くなったわけではありませんが、サーバーへの問い合わせは確かに減りましたし、何よりサイトヘルスを開くたびの小さなストレスが消えました。

最後に、自分への戒めとして書いておきます。あの警告を初めて見たとき、私は「何か壊した」と決めつけて、設定をあちこち触りそうになりました。でも実際は、壊れてなどいなくて、ただ WordPress が「やると良いことがありますよ」と勧めていただけでした。サイトヘルスの表示は、赤も黄色も緑も、まず落ち着いて「これはエラーなのか、推奨なのか」を見分けるところから始める。慌てて手を動かす前に、表示の意味を一度調べる。これは、今後また知らない警告に出会ったときに、自分が真っ先に思い出したいことです。

WordPress キャッシュ関連の記事

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