WordPressのautoloaded optionsが肥大化してサイトが遅い時の削除と高速化
WordPressのサイトヘルスで「autoloaded options」が94MBに肥大化し、ページ表示が数秒かかる・503エラーが出る場合は、削除済みプラグインの残した設定データが主な原因だ。古いプラグインのプレフィックスを持つ行を安全に削除すれば、多くのケースで速度が改善する。
autoloaded optionsがサイトを遅くする理由
autoloaded optionsとは、WordPressがページを表示するたびに必ずデータベースから読み込む「自動読み込み設定」の塊だ。通常は数百KBから数MB程度に収まるが、プラグインを削除してもその設定が残り続けると、数十MB単位で膨れ上がる。
サイトヘルスで「サイトには4784個の自動読み込みオプション（サイズ94MB）があります」と表示される場合、すべてのページ表示のたびに94MBものデータがメモリ上に展開される。Query Monitorでメモリ使用量が214MBに達するのはそのためで、サーバーのメモリ上限に近づくと503エラーが発生する。
このデモは肥大化した状態と削除後の状態の違いを示したイメージだ。まずは不要なデータを特定し、安全に削除する手順を確認する。
古いプラグインの残骸を特定する方法
問題の原因を特定するには、Advanced DB Cleanerの「オプション」タブで、同じプレフィックスを持つ行が大量にないかを確認する。たとえば「hashimage_cache_8e49faf63a472e474187cf79ab140ed9」のような行が数千件あれば、それは削除済みプラグインが作り残したキャッシュだ。
プレフィックスとは、オプション名の先頭部分「hashimage_cache_」のような共通文字列のことだ。この部分が同じ行は、かつて使っていた1つのプラグインが一括で作ったものと考えてよい。プラグイン本体が削除されていれば、このデータは使われない「残骸」になる。
念のため、サーバーのwp-contentフォルダ内を「hashimage_cache」または「hashimage」で検索し、現在アクティブなプラグインやテーマがこのプレフィックスを使っていないかを確認しておく。使っていなければ削除して安全だ。
autoloaded optionsを安全に削除する手順
削除作業に入る前に、必ずデータベースの完全バックアップを取得する。万が一、依存しているプログラムがあった場合に復元できるからだ。バックアップはレンタルサーバーの管理画面やUpdraftPlusなどのバックアッププラグインで取得できる。
このステップ図は削除作業の全体像を示している。各ステップの詳細を以下で説明する。
バックアップを必ず取る
削除する行は「おそらく不要」ではあっても、確実に不要とは言い切れない。バックアップなしで数千件の行を削除するのは危険だ。phpMyAdminからSQLファイルをエクスポートするか、バックアッププラグインでデータベース全体を保存しておく。これなら、もし問題が起きてもすぐに元へ戻せる。
削除対象のプレフィックスが本当に未使用か確認する
FTPソフトやサーバーのファイルマネージャーでwp-contentフォルダを開き、プラグインフォルダとテーマフォルダを横断して「hashimage」や対象のプレフィックスを含むファイルがないか検索する。検索して何もヒットしなければ、そのプレフィックスを使うプログラムは存在しないため、該当行を削除しても安全だ。
Advanced DB Cleanerで行を削除する
Advanced DB Cleanerの「オプション」タブを開き、検索ボックスにプレフィックス（例「hashimage_cache_」）を入力する。すると該当行だけが絞り込まれる。全選択して削除を実行する。数千件ある場合は、一度に全件削除せず、500件や1000件ずつ分けて削除するとタイムアウトを防げる。とくにサーバーが遅い場合は、より少ない件数で分けて実行する。
削除後はサイトヘルスを再度確認し、autoloaded optionsのサイズがどれだけ減ったかを確かめる。94MBから数MBに減っていれば、それが主因だったことがわかる。
503エラーが続く場合の対処
autoloaded optionsを削除しても503エラーが続く場合は、サーバーエラーログを確認する。503エラーはサーバーがリクエストを処理しきれない時に発生するため、エラーログに具体的な原因が記録されている。ログを確認せずに推測で対処しても時間の無駄になりやすい。
サーバーの契約プランによっては、メモリ上限やプロセス数が小さいために、WordPress本体の動作だけで503エラーになることもある。エラーログに「memory exhausted」や「timeout」の記録がある場合は、PHPメモリ上限の引き上げやサーバープランの見直しが必要になる場合がある。
サイトをさらに高速化するための追加対策
autoloaded optionsの削除が済んだら、残っている大きな行も見直す。Advanced DB Cleanerでオプションをサイズ順に並べ替え、不要な行が残っていないか確認する。しばしば、削除したはずの別プラグインが数MB単位の行を残していることがある。
期限切れのトランジェント（一時保存データ）も削除しておく。これもオプションテーブルに溜まり、放置すると肥大化の原因になる。キャッシュプラグインや専用のクリーンアップ機能があれば、それを使って一括削除できる。
基本的な高速化としては、画像の最適化（アップロード前に圧縮する）、キャッシュプラグインの導入、不要なプラグインの無効化、PHPバージョンの更新などが有効だ。これらはautoloaded optionsの肥大化とは別の話だが、組み合わせることで体感速度が大きく変わる。
よくある質問
autoloaded optionsを削除しても本当に安全か
削除する行のプレフィックスが現在のプラグインやテーマで使われていないことを確認すれば、基本的に安全だ。ただし必ずバックアップを取ってから作業するのが鉄則。削除後に不具合が出ても、バックアップから復元すればよい。
削除するとサイトが壊れないか心配だ
削除済みプラグインの残した設定データは、サイトの見た目やコンテンツには影響しない。削除対象が現在使っていないプラグインの行だと確認できていれば、サイトが壊れるリスクはごく低い。心配な場合は、本番環境ではなくステージング環境で先に試す方法もある。
phpMyAdminで直接削除してもよいか
SQLに慣れているならphpMyAdminで削除しても問題ない。たとえば「DELETE FROM wp_options WHERE option_name LIKE ‘hashimage_cache_%’;」のようなSQL文で該当行を一括削除できる。作業前に必ずテーブルのエクスポートを行い、削除後はサイトヘルスで効果を確認する。SQL文は環境によってテーブル名のプレフィックス（wp_など）が異なるため、実際のテーブル名を確認してから実行する。
autoloaded optionsがまた肥大化した場合はどうするか
同じ問題が再発する場合は、新しいプラグインをインストールするたびにautoloaded optionsのサイズをチェックする習慣をつける。また、プラグインを削除する時は、可能ならプラグイン側の「アンインストール時にデータを削除する」オプションを有効にしてから削除すると、残骸が残りにくい。
この記事のポイント
- autoloaded optionsの肥大化はサイト表示を遅くし、503エラーの原因になる
- 削除済みプラグインの残した行が肥大化の主因であることが多い
- プレフィックスを特定し、未使用を確認してから削除する
- 削除前には必ずデータベースの完全バックアップを取る
- 削除後はサイトヘルスでautoloaded optionsのサイズを再確認する
・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている
WordPressのパフォーマンス低下は「アクセス減少時」に起こる？共有サーバーの落とし穴と対策
WordPressサイトのパフォーマンス対策といえば、多くの場合はアクセス急増（スパイク）への備えを連想する。キャンペーンの開始や新製品の発表時にサーバーがダウンしないよう、リソースの増強やキャッシュの強化を行うのが一般的だ。
しかし、実は「アクセスが減少していく時期」にこそ、サイトの健全性を損なう大きなリスクが潜んでいる。キャンペーンが終わり、トラフィックが平時に戻る過程で、共有サーバー環境では予期せぬパフォーマンスの劣化が発生することがあるのだ。
なぜアクセスが減っているのに、サイトの動作が重くなるのか。その裏側には、多くのホスティングサービスが採用している「リソースの割り当てロジック」と、WordPress特有のバックグラウンド処理の仕組みが深く関わっている。
共有サーバーの不都合な真実：アクセスが減ると「後回し」にされる理由
多くの安価なレンタルサーバー（共有サーバー）では、1台の物理的なサーバー内に数百から数千のウェブサイトを収容している。ここで問題となるのが「オーバーセリング（過剰販売）」という手法だ。
オーバーセリングとは、物理的なサーバーの総リソース（CPUやメモリ）よりも多くの容量を、顧客に割り当てて販売することを指す。これは銀行の仕組みに似ている。すべての預金者が一度に現金を全額引き出そうとしない限り、銀行は預かっている以上の資金を運用できる。サーバーも同様に、すべてのサイトが同時にフル稼働しないことを前提に運用されている。
リソースの動的割り当てという名の「選別」
共有サーバー環境では、限られたリソースを効率よく分配するために「動的リソース割り当て」が行われる。これは、アクセスが多い「活発なサイト」に優先的にリソースを振り向け、アクセスが少ない「静かなサイト」への割り当てを削る仕組みだ。
つまり、あなたのサイトのアクセスが減少すると、サーバー側は「このサイトには今はリソースを割く必要がない」と判断する。その結果、余ったリソースは他の高トラフィックなサイトへと奪われてしまう。パフォーマンスがインフラの質ではなく、トラフィック量に依存してしまうという逆転現象が起きるのだ。
スロットリングによる制限の正体
リソースの制限は「スロットリング（Throttling）」と呼ばれる手法で実行される。これには主に3つの形態がある。
- CPU制限：計算処理能力に上限を設ける
- RAM（メモリ）割り当て：一度に扱えるデータ量を制限する
- I/O制限：ディスクへの読み書き速度を抑える
アクセスが多いときはリソースを消費し尽くすことで制限に触れるが、アクセスが少ないときは「最初からパイが小さく設定される」ため、わずかなバックグラウンド処理でも制限に引っかかるようになる。
スロットリングが招く「サイレント障害」：WP-Cronの遅延とデータベースの肥大化
フロントエンドの表示速度が落ちる以上に深刻なのが、WordPressのバックグラウンド処理への影響だ。WordPressには「WP-Cron（ダブルピー・クロン）」という、予約投稿やプラグインの更新チェック、データベースの最適化などを自動で行う仕組みが備わっている。
WP-Cronは、誰かがサイトにアクセスしたタイミングで実行される。アクセスが減少すると、そもそも実行される機会が減る。さらにリソースを制限された環境では、ようやく実行のチャンスが巡ってきても、CPUやメモリの不足によって処理が途中で失敗したり、実行が大幅に遅れたりする事態を招く。
蓄積される技術的負債
バックグラウンド処理の失敗は、目に見えないところでサイトの健康状態を悪化させる。例えば、以下のような問題が蓄積していく。
- データベース最適化の失敗：不要なデータ（リビジョンや一時データ）が削除されず、クエリの実行速度が徐々に低下する
- キャッシュのクリーンアップ遅延：古いキャッシュが残り続け、ディスク容量を圧迫する
- セキュリティスキャンの未完了：脆弱性の発見が遅れ、リスクが高まる
これらの問題は、アクセスが回復したときに自動的に解消されるわけではない。むしろ、肥大化したデータベースが足かせとなり、次のアクセス増の際にサーバーが耐えきれなくなる原因を作る。
共有環境と独立環境の視覚的イメージ
共有サーバーでのリソース奪い合いと、独立した環境の違いを視覚的に理解するためのデモを作成した。左側は他サイトの影響を受ける共有環境、右側は常に一定のリソースが確保された環境をイメージしている。
(アクセス減少時)
(アクセス減少時)
このデモは、共有環境では自分のサイト（青）が他サイト（赤）に圧迫されるのに対し、コンテナ型では常に一定の枠が保証される概念を示している。
独自の分析：トラフィックの「凪」がサイトの健康寿命を削るメカニズム
ここで独自の分析を加えたい。アクセス減少時のパフォーマンス低下は、単なる一時的な速度低下ではなく、サイトの「健康寿命」を削る慢性疾患のようなものだ。筆者はこれを「メンテナンス・デット（保守の負債）」の蓄積と呼んでいる。
自動車に例えるなら、レース（アクセス急増）のときだけオイル交換をし、街乗り（アクセス減少）のときは整備を一切受けられない状態に近い。整備不良のまま放置された車は、次に高速道路に乗った瞬間に故障する。WordPressサイトも同様で、平時のメンテナンスが滞ることで、サイトの構造自体が脆弱になっていくのだ。
SEOへの悪影響という負のループ
さらに深刻なのは、Googleの「CWV（Core Web Vitals / コアウェブバイタル）」への影響だ。アクセスが少ない時期にスロットリングによってページ読み込みが遅くなると、検索エンジンはそのサイトの評価を下げる可能性がある。
「アクセスが減る」→「リソースを削られる」→「表示が遅くなる」→「SEO評価が落ちる」→「さらにアクセスが減る」という負のスパイラルに陥る危険性がある。このループは、一度入り込むと抜け出すのが非常に困難だ。
コンテナ技術が実現する「トラフィックに左右されない」安定性
こうした共有サーバーの構造的な問題を解決するのが、Linuxコンテナ技術を活用したホスティングだ。Kinstaなどのモダンなホスティングサービスが採用しているこの方式では、各ウェブサイトが完全に独立した「コンテナ」内で動作する。
コンテナ型の最大の特徴は、他のサイトとリソースを共有しない点にある。あなたのサイトに割り当てられたCPUやメモリは、たとえアクセスがゼロになっても、他のサイトに転用されることはない。常にあなたのサイト専用の待機リソースとして確保され続ける。
キャッシュ機能もトラフィックに依存しない
また、多層構造のキャッシュシステムも安定性に寄与する。エッジキャッシュやサーバーレベルのキャッシュは、トラフィックの増減に関わらず一貫して動作する。Cloudflareなどのグローバルネットワークを利用したエッジキャッシュなら、オリジンサーバーにリクエストが届く前に応答できるため、アクセス減少時でも高速なレスポンスを維持できる。
静的アセット（画像やCSS）を配信するCDN（Content Delivery Network）も同様だ。これらはサーバーの負荷状況とは無関係に、世界中の拠点から最適な速度で配信される。
運用コストを最適化する：なぜ安定期こそ高品質なホスティングが必要なのか
「アクセスが少ない時期は、安いサーバーにダウングレードしてコストを抑えたい」と考えるのは自然な心理だ。しかし、WordPressサイトの複雑さはトラフィック量に比例して減るわけではない。
プラグインの動作、セキュリティスキャン、管理画面でのコンテンツ編集、ステージング環境でのテスト。これらすべての作業には、安定したインフラが必要だ。特にサイトを管理するエンジニアやディレクターにとって、管理画面のレスポンスがトラフィック減少時に悪化することは、作業効率を著しく低下させる要因となる。
長期的なビジネス成長を支えるインフラ選び
予測可能なインフラは、ビジネスの計画を容易にする。メンテナンス作業がスケジュール通りに完了し、WP-Cronが確実に実行され、管理画面が常にサクサク動く。この「当たり前」の環境を維持することが、長期的なサイト運営における最大のコスト削減につながる。
トラフィックの波に合わせてサーバーを右往左往させる管理コストや、劣化したパフォーマンスの調査に費やす時間を考えれば、最初からリソースが保証された環境を選ぶメリットは大きい。ホスティングは単なる「場所貸し」ではなく、サイトの健康を守る「維持装置」として捉えるべきだ。
この記事のポイント
- 共有サーバーでは「オーバーセリング」により、アクセスが少ないサイトのリソースが他へ転用されるリスクがある
- リソース制限（スロットリング）は、WP-Cronなどのバックグラウンド処理を停止させ、技術的負債を蓄積させる
- データベースの最適化不足やSEO評価の低下は、アクセス減少期に進行する「サイレント障害」である
- コンテナ型ホスティングなら、トラフィックの増減に関わらず専用リソースが確保され、安定した運用が可能になる
- 管理画面のレスポンスやメンテナンスの確実性を維持するためには、安定期こそ高品質なインフラが重要だ
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験