
WordPressでPHP致命的エラーがobject-cache.phpに発生した時の直し方
WordPress で「Call to a member function get() on null」という PHP の致命的エラーが object-cache.php で発生する場合、原因はオブジェクトキャッシュプラグイン(SQLite Object Cache)の初期化失敗にある。PHP バージョンアップグレード後に必要な PHP 拡張機能(sqlite3、igbinary、apcu 等)が有効でないことが主な引き金だ。緊急復旧にはプラグインの無効化とキャッシュファイルの削除を、恒久対策には拡張機能の有効化とプラグインの再設定を行う。
このエラーが起きる根本的な原因

対象のエラーは WordPress の起動シーケンスのごく初期段階で発生する。wp-settings.php が wp_start_object_cache() を呼び出す際、SQLite Object Cache プラグインが WP_Object_Cache クラスのインスタンスを生成しようとする。ここで PHP の sqlite3 拡張がロードされていない、あるいはデータベースファイルへの書き込み権限がないなどの理由でコンストラクタが失敗すると、null が返る。その後の処理で null に対して get() メソッドを呼び出そうとして致命的エラーに至る。
スタックトレースを見ると wp_cache_get → wp_load_alloptions → get_option → wp_check_invalid_utf8 → esc_html とエスカレーションしている。これはオブジェクトキャッシュが機能しない状態で、WordPress が初期設定値(blog_charset 等)を取得しようとする過程で表面化した二次的なエラーだ。根はあくまでキャッシュ層の初期化失敗にある。
とくに PHP を手動またはホスティング側でアップグレードした直後に顕在化しやすい。新しい PHP バージョンでは過去に有効だった拡張機能がデフォルト無効になっていたり、パスが変わっていたりするため、プラグインの前提条件が崩れる。
サイトを即時に復旧させる手順

まずは管理画面にアクセスできない状態を脱する必要がある。エラーが object-cache.php の読み込み時に起きて WordPress 全体が停止するため、管理画面経由でのプラグイン停止は不可能だ。FTP またはサーバーのファイルマネージャーを使う。
上記の手順でキャッシュ関連ファイルが除去され、WordPress はデフォルトのキャッシュ機構にフォールバックして起動する。この状態では速度面での最適化は失われるが、少なくともサイトは表示され管理画面にも入れる。緊急避難として有効な手段だ。
恒久的にエラーを解決する方法

一時しのぎで復旧したあとは、SQLite Object Cache プラグインを正常に動作させるための根本対応を行う。PHP 8.4 で必要な拡張機能を確認し、サーバー設定を見直す。
PHP 拡張機能が有効か確認する
レンタルサーバーの管理パネルから PHP 設定を開き、sqlite3 拡張にチェックが入っているか確認する。多くのサーバーでは PHP バージョンごとに拡張のオンオフを切り替えられる。バージョンアップ時にデフォルト設定がリセットされ、sqlite3 が外れていることがよくある。
さらにパフォーマンスを引き出すために igbinary と apcu も有効にしておくと良い。igbinary はデータをバイナリ形式でシリアライズしてキャッシュ容量を節約し、apcu は PHP のユーザーキャッシュとしてメモリ上にデータを保持する。いずれも SQLite Object Cache プラグインが内部的に使用する。
プラグインを再インストールして設定する
先の手順でプラグインフォルダを削除した場合は、WordPress 管理画面から「プラグイン」→「新規追加」で SQLite Object Cache を検索し、再インストールする。有効化すると自動的に object-cache.php が wp-content 直下に再生成される。
有効化後、プラグインのステータス画面で「接続が確立されている」旨の表示が出れば正常だ。もしエラーが再発するようなら、wp-content ディレクトリのパーミッションが適切か(通常 755 または 775)も確認する。
自動読み込みオプションを整理する
質問の状況では自動読み込みオプション(autoloaded options)が 10MB に達していた。これは標準の数百 KB に比べるとかなり大きく、キャッシュ構築時にメモリを圧迫してエラーを誘発する一因になりうる。不要なオプションを整理することで、オブジェクトキャッシュの初期化負荷を下げられる。
長期運営サイトでは、過去にインストールして削除したプラグインの設定値が wp_options テーブルに残り、自動読み込みフラグがオンのまま放置されていることが多い。WP-CLI が使える環境なら wp option list --autoload=yes --format=table で一覧を取得し、不要なものを wp option delete で削除する。あるいは Advanced Database Cleaner のようなプラグインで掃除する方法もある。
再発を防ぐための設定ポイント

PHP バージョンアップ時には事前にステージング環境でプラグイン互換性をテストしておくのが理想だ。しかし実際には共有サーバーで本番一発のバージョンアップが行われるケースも多い。そうした環境では、少なくとも次の3点をルーティン化しておくと安全だ。
- PHP 拡張機能の有効リストをバージョンアップ前後で比較する
- object-cache.php の存在とプラグイン状態をアップグレード直後に確認する
- 自動読み込みオプションのサイズを定期的に監視し肥大化を防ぐ
sqlite3 拡張 無効 → オブジェクトキャッシュ初期化失敗 → サイト全体停止
sqlite3 拡張 有効 → キャッシュ正常稼働 → サイト表示速度も改善
このデモのとおり、PHP アップグレード直後は拡張機能の設定がリセットされてエラー状態に陥りやすい。事前に必要な拡張機能リストを控えておき、アップグレード後に同じ設定を復元する手順を習慣化することで再発を防げる。
よくある質問
管理画面にも入れず FTP も使えない場合はどうすればよいか
レンタルサーバーのファイルマネージャー(cPanel 等)から直接 wp-content にアクセスし、object-cache.php とプラグインフォルダを削除する。これで WordPress が起動できるようになる。どうしても操作できない場合はサーバー会社のサポートに依頼して該当ファイルの除去を代行してもらう。
SQLite Object Cache をやめて別のキャッシュプラグインに移行してもよいか
もちろん問題ない。Redis Object Cache や Memcached など、サーバーが対応している別の永続オブジェクトキャッシュを使う選択肢もある。ただし Redis や Memcached はサーバー側でデーモンを起動する必要があるため、共有サーバーでは使えないことも多い。その点 SQLite Object Cache はファイルベースで動くため導入障壁が低い。
object-cache.php だけ削除してプラグインは残しても大丈夫か
一時的な復旧としては有効だが、プラグインを再有効化すると object-cache.php が自動再生成され、拡張機能の問題が解決していなければ同じエラーが再発する。恒久対応としては必ず PHP 拡張機能を有効にしてから再インストールする必要がある。
自動読み込みオプションが 10MB を超えるのは異常なのか
かなり大きい部類に入る。通常のサイトでは数百 KB から高くても 2〜3MB 程度だ。10MB になるとキャッシュ初期化時のクエリ負荷が無視できず、メモリ制限の低い環境ではエラーの遠因になる。定期的な整理が推奨される。
SQLite Object Cache プラグインの代替手段はあるか
同プラグインはファイルベースの永続キャッシュとして優秀だが、もし拡張機能周りで繰り返し問題が起きるなら、WP Super Cache や W3 Total Cache のようなページキャッシュ系プラグインと、Transients のデータベース管理を組み合わせて代替する手もある。ただしオブジェクトキャッシュのパフォーマンスメリットは一部犠牲になる。
この記事のポイント
- PHP の致命的エラーは object-cache.php の初期化失敗が原因で起きている
- sqlite3 拡張機能が無効になっていることが最大の引き金
- 緊急復旧には object-cache.php とプラグインフォルダの削除が有効
- 恒久対策では PHP 拡張機能の再有効化とプラグイン再インストールを行う
- 自動読み込みオプションの肥大化もエラーを誘発するため定期的な整理が必要

・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている
