WordPressのautoloadデータが増えすぎた時の確認方法｜管理画面を軽くする手順

WordPressのサイトヘルスに「自動読み込みオプションはパフォーマンスに影響する可能性があります」と出たら、autoloadデータの合計容量を確認するタイミングです。ただし、警告を見てすぐにwp_optionsの行を削除するのは危険です。

結論から言うと、まず読み取り専用の確認で「どのoptionが、どれくらいの容量を占めているか」を記録し、所有するプラグインやテーマを特定してください。バックアップと戻し方を用意してから、一件ずつ改善するのが安全な順番です。

よこやま良平

20年以上ITエンジニアとしてWordPressの制作・保守・復旧に携わっている、よこやま良平です。autoloadの整理では、容量だけで削除せず、作成元と現在の利用状況を確認することを重視しています。

autoloadの警告は、直ちにサイトが壊れるという意味ではありません。表示速度へ影響する可能性を知らせ、不要な自動読み込みがないか点検するための合図です。

この記事では、サイトヘルスの確認からSQLによる容量調査、作成元の判断、安全な減らし方、再計測までを初心者向けに解説します。テーブル接頭辞やバックアップの注意点も含め、戻せる手順で進めましょう。

【無料プレゼント】
WordPress緊急チェック50

「自分のサイトは今、安全なのか？」
自信を持って答えられますか？

こんなお悩みはありませんか？

• ある朝、サイトを開いたら真っ白画面になっていた
• 管理画面にログインできなくなって手が止まった
• 身に覚えのない記事やページが勝手に増えていた
• プラグインを更新したらサイト全体が崩れてしまった
• 以前バックアップを取ったか自分でも覚えていない

累計1,000件以上のWordPressトラブル対応の経験から、「壊れる前に備える」ためのチェックリストを1冊にまとめました。
ログイン・本体・バックアップ・サーバー・運用の5分野を、50項目で「危険度・確認方法・対処法」まで解説しています。

セキュリティプラグイン・WordPressの教科書も含めた3大特典を、
今なら無料で受け取れます。

今すぐ無料ダウンロードする →

※登録後すぐにメールで特典をお届けします

WordPressのautoloadデータが増えると何が起きるか

WordPressのautoloadデータが増えすぎると、必要のない設定まで多くのリクエストで読み込まれ、PHPメモリやデータベース処理へ余分な負担がかかります。最初に、通常のoptionとの違いを理解しましょう。

autoloadは頻繁に使う設定をまとめて読み込む仕組み

WordPressはサイトURL、テーマ、プラグイン設定などをwp_optionsテーブルへ保存します。そのうちautoload対象の値は、ページごとに個別照会する代わりに、まとめて読み込んでキャッシュします。

小さく頻繁に使う設定なら、一度の問い合わせで取得できるため効率的です。問題は、使われていない設定や巨大な配列までautoloadになり、毎回の読み込み対象へ残り続ける場合です。

公開ページだけでなく、管理画面、REST API、cronなどでもWordPressの初期化処理が動きます。autoload全体が重いと、一つの画面だけではなく、さまざまな処理の土台へ負荷が加わります。

WordPressの管理画面が急に重い原因とは？初心者でもできる切り分け手順

800,000バイト以上は点検を促す基準

WordPress 6.6以降のサイトヘルスは、autoload対象の合計が既定で800,000バイト以上になると、パフォーマンスへ影響する可能性を警告します。表示上は約800KB前後に見えますが、コード上の既定値は800,000バイトです。

この基準を少し超えたからといって、すぐ障害になるわけではありません。サーバー性能、object cache、各optionの利用頻度、同時アクセス、プラグイン処理などで体感差は変わります。

反対に、警告が出ていなくても一つの巨大optionが頻繁に更新され、キャッシュを失効させている場合は負荷になります。警告の有無だけで正常・異常を断定せず、速度症状と容量の内訳を一緒に見てください。

件数より合計容量と上位のoptionを見る

autoloadの件数が多くても、一件ずつが小さければ影響は限定的です。一方、数件の大きなoptionだけで合計容量の大半を占めるケースもあります。

そのため「256件あるから256件を減らす」という考え方は適切ではありません。合計バイト数を記録し、容量順で上位20件ほどを確認して、改善効果が大きい候補から所有元を調べます。

WordPressのautoloadデータ量を安全に確認する方法

WordPressのautoloadデータ量は、サイトヘルスで全体像を記録し、データベースではSELECT文だけを使って内訳を調べるのが安全です。この段階ではUPDATEやDELETEを実行しません。

サイトヘルスの件数と容量を記録する

管理画面の「ツール」から「サイトヘルス」を開き、ステータス画面のパフォーマンス項目を確認します。autoloadの件数、合計容量、表示された警告文をスクリーンショットかメモで残してください。

確認日時、WordPressバージョン、直近で追加・削除・更新したプラグインも一緒に記録します。数日後に増えた場合、どの操作が増加のきっかけだったか追いやすくなります。

管理画面が重い場合は、ダッシュボード、投稿一覧、編集画面、プラグイン一覧を同じ順番で開き、おおよその待ち時間も残します。autoloadを減らした後、同じ条件で比べるための基準になります。

phpMyAdminでautoloadの合計量を確認する

phpMyAdminを使う場合は、対象サイトのデータベースを選び、SQLタブで読み取り専用のSELECT文を実行します。次の例はテーブル接頭辞がwp_の場合です。

実際の接頭辞がabc_なら、wp_optionsではなくabc_optionsへ置き換えます。似た名前の別サイトやステージング用テーブルを選ばないよう、wp-config.phpのtable_prefixと照合してください。

SELECT
  COUNT(*) AS autoload_count,
  SUM(LENGTH(option_value)) AS autoload_bytes,
  ROUND(SUM(LENGTH(option_value)) / 1024, 1) AS autoload_kb
FROM wp_options
WHERE autoload IN ('yes', 'on', 'auto-on', 'auto');

LENGTHは文字数ではなく、保存されている値のバイト数を返します。サイトヘルスと完全一致しない場合は、object cache、実行時の更新、プラグインによるフィルター、調査時刻の違いを確認してください。

WordPress 6.5以前の情報ではautoload=’yes’だけを条件にしたSQLが多く見つかります。6.6以降はon・auto-on・autoも対象になり得るため、yesだけでは合計を過小評価する場合があります。

WordPressデータベース修復を初心者でもできる完全ガイド｜エラー別対処手順まとめ

容量の大きいoptionを上位20件まで抽出する

合計量を確認したら、同じ条件でoption_name、バイト数、autoload値を容量順に並べます。option_valueの中身を最初から全文表示すると、機密情報や巨大データが画面へ出るため、まず名前とサイズだけを見ます。

SELECT
  option_name,
  LENGTH(option_value) AS bytes,
  autoload
FROM wp_options
WHERE autoload IN ('yes', 'on', 'auto-on', 'auto')
ORDER BY bytes DESC
LIMIT 20;

結果はCSVへ保存するか、option_nameとbytesだけを記録します。URL、トークン、メールアドレス、API設定などが値に含まれる可能性があるため、option_valueをそのまま第三者へ送らないでください。

同じ接頭辞のoptionが複数並ぶなら、一つのプラグインが設定、キャッシュ、ログを分けて保存している可能性があります。合計すると大きい場合もあるため、個別サイズと接頭辞ごとのまとまりを両方見ます。

WordPressのautoloadデータで削除候補を見分ける基準

WordPressのautoloadデータは、option_nameが大きいだけでは削除候補になりません。現在使われている機能か、作成元が管理しているか、消した後に安全に再生成されるかまで確認して判断します。

option_nameから作成元を推定する

option_nameには、プラグイン名、略称、テーマ名、機能名に近い接頭辞が使われることがあります。まずプラグイン一覧、テーマ、mu-plugins、独自コードの名称と照合してください。

ただし、名前が似ているだけで断定してはいけません。公式ドキュメントやサポート情報でoption名を検索し、該当プラグインを停止したステージング環境で値の参照状況や再生成を確認します。

有効なプラグインのライセンス、ルール、ウィジェット、フォーム、権限などは大きくても必要な設定かもしれません。容量を減らす目的で消すと、機能停止や初期設定への巻き戻りが起こります。

削除済みプラグインの残骸かを確認する

過去に削除したアクセス解析、バックアップ、移行、キャッシュ、セキュリティ系プラグインのoptionが残ることがあります。アンインストール時に設定保持を選んだ場合や、フォルダだけを手動削除した場合に起こりやすい状態です。

残骸に見えても、別の拡張機能が同じデータを利用している可能性があります。プラグイン名、最終利用時期、現在の代替機能、公式の削除手順、再導入の予定を確認してから候補へ入れます。

一時データやキャッシュらしい名前でも、削除後すぐ巨大な値が再作成されるなら、根本原因は生成元の設定です。保存期間、ログ件数、統計データ、バックアップ一覧などをプラグイン側で減らす方が再発を防げます。

serializedデータを途中だけ編集しない

option_valueには、PHPの配列やオブジェクトをserialized形式で保存した値があります。この形式には文字列長などの情報が含まれるため、phpMyAdminで一部分だけ削ると整合性が崩れます。

見た目がJSONや通常の文章に近くても、管理画面、プラグインAPI、WP-CLIなど正規の更新経路を優先してください。値を直接編集する場合は、形式を理解した担当者がステージングで検証する必要があります。

WordPress不具合の原因と解決方法｜よくある7つのトラブル完全ガイド【パターン別】

WordPressのautoloadデータを安全に減らす手順

WordPressのautoloadデータを減らす時は、バックアップ、所有元の停止、ステージング検証、個別変更、再計測の順で進めます。複数候補を一括で変更すると、どれが効果や不具合の原因か分からなくなります。

手順1：ファイルとデータベースを両方バックアップする

autoloadはデータベース内の設定ですが、復元時にプラグインやテーマのバージョンが違うと正しく戻らない場合があります。データベースだけでなく、wp-content、wp-config.php、利用中のプラグインとテーマも保存してください。

バックアップの作成日時、保存先、ファイル容量を確認し、復元手順も開いておきます。サーバー内だけでなく外部へコピーし、作業中のデータベースへ戻せる形式か確かめます。

WordPressバックアップ・UpdraftPlusプラグインの使い方【図解付き】

手順2：生成元の設定や公式アンインストールを優先する

容量の大きいoptionを作ったプラグインが判明したら、ログ保存期間、統計保持、キャッシュ、バックアップ履歴などを管理画面から調整します。データを作り続ける設定が残れば、行だけ消しても再び増えます。

もう使わないプラグインなら、公式の「設定も削除する」機能やアンインストール手順を確認します。単にフォルダを削除するより、開発元が用意した処理の方が関連optionを整合性のある状態で整理できます。

現役プラグインの必要な設定がautoloadになっている場合、勝手にoffへ変えないでください。毎回使う値を非autoloadにすると、ページごとに個別クエリが増え、かえって遅くなる可能性があります。

手順3：ステージングで一件ずつ変更して動作確認する

本番と同じWordPress、テーマ、プラグイン、PHPバージョンのステージングを用意します。個人情報や注文情報を含むサイトでは、複製先のアクセス制限とメール送信停止も確認してください。

一つの候補だけを公式手順で削除または非autoload化し、公開ページ、ログイン、投稿編集、保存、フォーム、決済、会員機能、定期処理を確認します。エラーログとブラウザのコンソールも変更前後で比べます。

問題がなければ、autoload合計量と上位一覧を再取得します。期待した容量だけ減ったか、別名で再生成されていないか、同じ機能で追加クエリが急増していないかを確認してください。

WordPressのautoloadデータ削減後に効果を検証する方法

WordPressのautoloadデータを減らした後は、警告が消えたかだけでなく、同じ画面の応答、PHPエラー、主要機能、再増加を確認してください。数字が減っても機能が壊れたら改善とは言えません。

同じ条件でサイトヘルスと管理画面を測り直す

変更前と同じ利用者、ブラウザ、時間帯、画面順で確認します。ダッシュボードだけ速くなったか、投稿保存やメディア画面も改善したかを分けて記録してください。

autoload合計が800,000バイト未満になっても、体感が変わらない場合があります。その時は外部API、wp-cron、重いクエリ、CPU、ディスクI/Oなど別の原因へ切り分けを進めます。

永続object cacheを使っている環境では、変更後も古いalloptionsキャッシュが残る場合があります。ホスティング会社やキャッシュ製品の正式な手順で対象キャッシュを更新し、全キャッシュの無計画な削除は避けます。

一週間から一か月後に再増加を確認する

改善直後だけ小さくても、日次集計、バックアップ、アクセス統計、期限切れデータの失敗などで再び増えることがあります。一週間後と一か月後に、合計量と上位optionを同じSQLで記録してください。

増加速度が分かれば、保存期間の短縮、不要ログの停止、プラグイン更新、開発元への問い合わせなど、再発防止へつなげられます。値そのものより「何の操作で増えたか」が重要です。

WordPressのトラブルを防ぐための定期メンテナンスFAQとチェックリスト【完全保存版】

WordPressのautoloadデータでよくある質問

WordPressのautoloadデータについて、削除や容量の判断で迷いやすい点をまとめます。最終的な判断は、optionの所有元とサイト固有の機能を確認して行ってください。

WordPressのautoloadデータを安全に見直す要点

WordPressのautoloadデータが増えすぎた時は、サイトヘルスの警告だけで削除を決めず、合計容量と上位optionをSELECT文で確認します。件数よりも、何が容量を占め、現在どの機能で使われているかを見てください。

よこやま良平が実務で重視するのは、変更前の証拠と戻せる状態を残すことです。バックアップ後、生成元の設定や公式アンインストールを優先し、ステージングで一件ずつ検証します。

WordPressトラブルが自分で直せない時は

WordPress保守・不正アクセス対策・マルウェア駆除・WordPressクイックレスキュー365

ワードプレスのWordPressエラートラブル解決をしたいなら
クイックレスキューが解決します。

これらでお悩みなら最短30分ですぐに解決します！

いまなら期間限定で