年末年始に向けたWordPressサイト大掃除とデータベース最適化手順｜肥大化・リビジョン安全削除と高速化

WordPressサイトを長期間運用していると、「以前よりも管理画面の動作が重くなった」「ページの表示開始（TTFB）が遅い」「バックアップファイルの容量が急増している」といった課題に直面することが少なくありません。

その最大の原因の一つが、 データベース（MySQL / MariaDB）の肥大化と不要データの蓄積 です。

記事を投稿・更新するたびに自動生成される膨大な「リビジョン」や「自動下書き」、期限が切れても残留し続ける「トランジェント（一時キャッシュ）」、そして過去にインストールして削除したプラグインが残していった「残骸テーブル」や「wp_optionsのautoloadデータ」などが、目に見えないところでデータベースを圧迫し続けています。

特に年末年始や夏季休暇などの長期休暇前は、アクセスが比較的落ち着くサイトが多く、 サイトの健康診断とデータベースの大掃除（クリーンアップ＆最適化）を実施する絶好のタイミング です。

本記事では、事前の安全な完全バックアップ取得から、プラグイン（WP-Optimize等）を活用した初心者向けの一括掃除手順、phpMyAdminやSQLを用いた中・上級者向けの「wp_options autoload肥大化特定・削減手順」、そしてデータベースの再肥大化を恒久的に防ぐ wp-config.php のチューニングまで、体系的かつ安全な手順を徹底解説します。

---

年末年始にWordPressのデータベース大掃除を行うべき理由

なぜ、日常の運用中ではなく「年末年始などの長期休暇前」にデータベースの大掃除を行うべきなのでしょうか。放置された不要データがサイトに与える悪影響と、データベースが肥大化するメカニズムを整理しておきましょう。

放置された不要データがサイト表示速度やバックアップ容量に与える悪影響

WordPressは、アクセスが発生するたびにデータベースへ複数のSQLクエリを発行し、投稿本文、メタデータ、カテゴリー情報、サイト設定値などをリアルタイムに取得してHTMLを組み立てます。

データベース内に不要なレコードが蓄積してテーブルサイズが肥大化すると、以下のような深刻な悪影響が連鎖的に発生します。

1. クエリ実行速度の低下とTTFB（最初の1バイト到着時間）の悪化 テーブルのレコード数が増大すると、データベースの検索インデックスが肥大化し、目的のレコードを特定するためのスキャン時間が増加します。これにより、サーバーが最初のHTMLレスポンスを返すまでの時間（TTFB）が遅延し、Googleの検索評価指標である Core Web Vitals（LCPやINP）のスコア低下 に直結します。
2. バックアップ・リストア処理の長時間化とサーバー容量圧迫 データベースサイズが数百メガバイト〜数ギガバイトに膨らむと、日々の自動バックアップの生成や外部クラウドへの転送に膨大な時間がかかります。最悪の場合、PHPの実行時間制限（max_execution_time）を超過してバックアップ処理が途中でタイムアウト失敗する原因となります。また、トラブル発生時の復旧（リストア）にも多大な時間を要し、ダウンタイムが長期化します。
3. サーバーリソース消費の増大とデータベースクラッシュのリスク 不要なデータが常時メモリ（InnoDBバッファプール）を圧迫するため、アクセス集中時にサーバーのメモリ不足（OOM）やデータベース接続エラーが発生しやすくなります。

年末年始のアクセス閑散期は、訪問者への影響を最小限に抑えながら、まとまったメンテナンス時間を確保して安全にデータベースを健全化できる貴重な機会です。

データベース肥大化の主な原因（リビジョン・自動保存・期限切れキャッシュ・残骸テーブル）

長年運用されたWordPressデータベースを調査すると、容量の70%以上を「本来サイトの公開に必要のないゴミデータ」が占めているケースが珍しくありません。主な原因は以下の4点です。

• 投稿リビジョン（過去の変更履歴） : 記事を「下書き保存」または「更新」するたびに、過去の本文全文が1レコードとして丸ごと保存されます。100記事のブログで各記事を平均20回保存していれば、それだけで2,000レコード以上の余剰データが蓄積されます。
• 自動保存・自動下書き（Auto Draft） : 記事執筆中にWordPressが数十秒おきに自動生成する一時データです。ブラウザを途中で閉じたり下書きを破棄した場合、不要な孤立データとして残ることがあります。
• 期限切れトランジェント（Transient） : 外部API呼び出しの結果やプラグインの一時キャッシュを保持する仕組みですが、プラグインの不具合やcron実行の失敗によって有効期限切れ後も削除されずに残留し続けることがあります。
• 削除済みプラグインの残骸データ : プラグインをWordPress管理画面から「無効化」→「削除」しても、作成されたカスタムテーブルや wp_options 内の設定レコードはデータベース内にそのまま残る仕様になっています。

以下の表に、大掃除の対象となる主要データと、その危険度・削減効果をまとめました。

データベース大掃除対象データの危険度・削減効果一覧表

対象データ	肥大化の原因	削除時のリスク	推奨頻度・削減効果
投稿リビジョン	記事の編集・保存ごとに無限生成	なし（古い編集履歴が消えるのみ）	高（数千〜数万レコード削減）
自動保存・下書き	編集中の自動バックアップ残骸	なし	中（不要な一時データの解消）
期限切れトランジェント	一時キャッシュの蓄積・プラグインのバグ	極めて低い（必要時自動再生成）	高（管理画面・DBの応答速度改善）
wp_options autoload	削除済みプラグインの設定残骸	注意（現行プラグインのデータは保持必須）	極めて高（TTFB・ページ描画の劇的改善）

---

【作業前必須】データベースの完全バックアップ作成

データベースのクリーンアップや最適化作業は、 一度実行すると元に戻せない「不可逆な操作」 です。

万が一、削除対象の判別を誤って必要なプラグイン設定を消去してしまったり、テーブル最適化中にサーバー障害が発生してデータベースが破損した場合に備え、 作業前の完全バックアップ作成は絶対に省略してはならない最重要ステップ です。

バックアップの手順や障害時の復旧ノウハウについては、あらかじめ以下の解説記事を確認し、手元に復元手段を確保した上で作業に着手してください。

👉 【最短10分復旧】WordPressバックアップ＆復元完全手順｜主要サーバー別自動復元・プラグイン・手動リストア

万が一の破損に備えるphpMyAdminエクスポート手順とプラグインバックアップ

バックアップには「プラグインによる自動バックアップ」と「phpMyAdminによる手動エクスポート」の2通りがあります。

1. 初心者向け：プラグイン（UpdraftPlus等）による即時バックアップ

管理画面から手軽にバックアップを取得したい場合は、「UpdraftPlus」などのバックアッププラグインを利用します。

1. 管理画面の「設定」＞「UpdraftPlus バックアップ」を開く。
2. 「今すぐバックアップ」ボタンをクリック。
3. 「データベースをバックアップに含める」にチェックが入っていることを確認し、バックアップを実行。
4. 生成されたデータベースバックアップファイル（.gz形式）をPCローカル環境へダウンロード保存する。

2. 最も確実：phpMyAdminからの手動エクスポート手順

プラグインが動作しない緊急時でも確実に復旧できるよう、サーバーのデータベース管理ツール「phpMyAdmin」から直接 .sql ファイルをエクスポートしておく方法が最も安全です。

主要レンタルサーバーごとのphpMyAdminアクセス場所とエクスポートの流れは以下の通りです。

主要レンタルサーバー別 phpMyAdminアクセス＆エクスポート手順

レンタルサーバー	管理画面メニューからのアクセス手順	推奨エクスポート設定
エックスサーバー	サーバーパネル ＞ データベース ＞ 「phpMyAdmin」 をクリック（MySQLユーザ名・パスワードでログイン）	エクスポート方法:「簡易」、フォーマット:「SQL」、圧縮:「gzip」
ConoHa WING	コントロールパネル ＞ サイト管理 ＞ データベース ＞ 対象DBの 「phpMyAdmin」 リンクをクリック	エクスポート方法:「簡易」、フォーマット:「SQL」
さくらインターネット	サーバコントロールパネル ＞ Webサイト/ドメイン ＞ データベース ＞ 「phpMyAdminを開く」	エクスポート方法:「詳細」＞ 生成オプションでDROP TABLE追加を推奨
ロリポップ！	ユーザー専用ページ ＞ サーバーの管理・設定 ＞ データベース ＞ 「phpMyAdminを開く」 ボタンをクリック	エクスポート方法:「簡易」、フォーマット:「SQL」

エクスポートした .sql または .sql.gz ファイルが正常にPCへダウンロードされたことを確認できたら、次のクリーンアップ作業へ進みます。

万が一、作業中に設定ファイルの記述ミス等でサイトが表示されなくなった場合は、以下のトラブルシューティングガイドを参考に復旧を行ってください。

👉 【最短5分】WordPress「データベース接続確立エラー」の直し方｜wp-config設定・サーバー別復旧ガイド

---

初心者向け：プラグイン（WP-Optimize等）を使った安全なデータ大掃除

SQL文の知識がない初心者や、管理画面からクリック操作だけで安全にデータベースを整理したい場合は、専用のクリーンアッププラグインを活用するのが最も安全で確実です。

代表的な最適化プラグインである 「WP-Optimize」 を使用した大掃除手順を4つのステップで解説します。

1. 投稿リビジョン・自動下書き・ゴミ箱データの安全な一括クリーンアップ

まずは、データベース肥大化の最大の原因である投稿関連の不要データを一掃します。

1. WordPress管理画面の「プラグイン」＞「新規追加」から「WP-Optimize」をインストールし、有効化します。
2. 左メニューの 「WP-Optimize」＞「データベース」 を開きます。
3. 「最適化」タブに表示される項目のうち、以下のチェックボックスをオンにします： – 投稿リビジョンのクリーンアップ : 過去の編集履歴を一括消去します。現在公開されている記事本文には一切影響しません。 – 自動下書き投稿のクリーンアップ : 執筆途中で破棄された一時下書きを消去します。 – ゴミ箱の投稿のクリーンアップ : ゴミ箱に入ったまま放置されている記事・固定ページを完全消去します。
4. 右側の 「選択したすべての最適化を実行する」 ボタンをクリックします。

数秒〜数十秒で処理が完了し、削除されたレコード件数と削減された容量が表示されます。これだけで数千件単位の不要レコードが削除されます。

2. スパムコメント・ゴミ箱コメントの完全消去

ブログにコメント欄を設けている場合、スパムフィルター（Akismet等）によって隔離されたスパムコメントやゴミ箱コメントが数千〜数万件単位で蓄積していることがあります。

• スパムコメントのクリーンアップ にチェックを入れます。
• ゴミ箱のコメントのクリーンアップ にチェックを入れます。
• 「選択したすべての最適化を実行する」をクリックして完全消去します。

スパムコメントテーブル（wp_comments および wp_commentmeta）が軽くなることで、コメント検索や管理画面の表示が目に見えて軽快になります。

3. 期限切れトランジェント（transient）データのクリーンアップ

トランジェント（Transient）とは、WordPressの「Transient API」を利用して一時的にデータベースに保存されるキャッシュデータのことです。

通常は有効期限（Expiration）が切れると自動的に破棄される設計ですが、サーバーのcron設定やプラグインの実装不備によって、期限切れのまま何年も wp_options テーブルに残留し続けるケースが多発します。

WP-Optimizeの項目一覧から 「期限切れの一時オプション（transient）を削除」 を選択して実行します。

> トランジェント削除の安全性 > トランジェントデータは「一時キャッシュ」であるため、すべて削除してもサイトのレイアウトや設定が壊れることはありません。必要なデータは次回アクセス時にWordPressやプラグインが自動的に再生成します。

4. データベーステーブルの最適化（断片化の解消）実行手順

不要なレコードを大量に削除した直後は、実はハードディスクやSSDの「空き容量」が即座に解放されるわけではありません。

データベース内には、レコードを削除した跡地に 「断片化（オーバーヘッド・虫食い状態）」 と呼ばれる空洞領域が残ります。この断片化を解消し、データを連続して配置し直す作業が 「テーブルの最適化（OPTIMIZE TABLE）」 です。

1. WP-Optimizeの画面で 「データベーステーブルの最適化」 にチェックを入れます。
2. 最適化を実行すると、内部的にMySQLの OPTIMIZE TABLE コマンドが全テーブルに対して順次発行されます。
3. 「テーブル情報」タブを開き、各テーブルの「オーバーヘッド」が 0 KB になっていることを確認します。

これにより、物理的なファイルサイズが縮小され、データベースの入出力（I/O）効率が大幅に向上します。

---

中・上級者向け：phpMyAdminで肥大化の元凶（wp_options）を特定・削減するSQL手順

プラグインによる一般的なクリーンアップを行ってもサイトの表示速度が改善しない場合、 wp_options テーブルの autoload 肥大化 が原因になっている可能性が極めて高いです。

このセクションでは、phpMyAdminを使用して肥大化の元凶をピンポイントで特定し、安全に削減する技術的アプローチを解説します。

なぜ wp_options の autoload がサイト遅延のボトルネックになるのか

WordPressのデータベースにおいて、最も重要な中枢テーブルが wp_options です。サイト名、サイトURL、有効化されているプラグイン一覧、各種テーマ設定など、サイト全体の動作を司る設定値が格納されています。

このテーブルには autoload（自動読み込み）というフラグ列（yes または no）が存在します。

• autoload = 'yes' のレコード : フロントエンド・管理画面を問わず、すべてのページが読み込まれるたびに、1回のSQLクエリでメモリ上に一括ロード されます。
• 理想的なautoloadサイズ : 合計で 300KB〜500KB以下 が健全な目安です。
• 肥大化したautoloadサイズ : 過去に多くのプラグインを試したサイトでは、autoloadサイズが 1MB〜3MB以上 に達していることが珍しくありません。

もしautoloadサイズが1MBを超えていると、ページが開かれるたびに巨大なデータがPHPのメモリ上に展開され、CPU処理とメモリ帯域を浪費し、 TTFB（初回サーバー応答時間）が数百ミリ秒単位で悪化 します。

さらに厄介なのは、 「プラグインを削除しても、プラグインが残した設定値（autoload = ‘yes’）は自動的には消えない」 という点です。過去に削除したプラグインの残骸が、何年間も全ページ読み込みの重石となり続けているのです。

autoloadされているデータサイズが大きいレコードを特定するSQL文

まずは、phpMyAdminにログインし、どのオプションレコードがautoloadの容量を圧迫しているかを特定します。

手順1：phpMyAdminでSQLタブを開く

phpMyAdminにログインし、左メニューからWordPressのデータベースを選択後、上部メニューの 「SQL」タブ をクリックします。

手順2：autoloadサイズ上位20件を抽出するSQLクエリを実行する

以下のSQLクエリを貼り付けて「実行」をクリックします。

SELECT option_name, length(option_value) AS option_size
FROM wp_options
WHERE autoload = 'yes'
ORDER BY option_size DESC
LIMIT 20;

※プレフィックス（接頭辞）が wp_ 以外に変更されている環境（例: wp_abc123_）の場合は、適宜 FROM wp_options をご自身のテーブル名に合わせて変更してください。

クエリ結果の分析例

実行すると、データサイズ（バイト数）が大きい順にレコード名が一覧表示されます。

• option_size が 100,000（約100KB）以上 あるレコードは、明確な肥大化要因です。
• オプション名（option_name）のプレフィックスから、どのプラグインが生成したデータであるかを判別できます（例: transient_、elementor_、woocommerce_、yoast_、過去に使用していた問い合わせフォームプラグインなど）。

参考：autoloadの合計サイズを確認するクエリ

現在のサイト全体でautoloadされているデータの合計サイズ（KB単位）を知るには、以下のクエリを実行します。

SELECT SUM(length(option_value)) / 1024 AS autoload_size_kb
FROM wp_options
WHERE autoload = 'yes';

この値が 800KBを超えている場合は即時改善が必要 であり、1,500KBを超えている場合は深刻なパフォーマンス低下を引き起こしています。

削除済みプラグインの残骸オプションを安全に見極めて削除するルール

特定した巨大レコードを整理する際は、以下の厳格な安全基準を守って作業を進めてください。

ルール1：WordPress本体のコアオプションは絶対に触らない

以下のオプション名はWordPressが動作するための必須データです。これらを削除または無効化するとサイトがクラッシュします。

• siteurl, home, active_plugins, stylesheet, template, cron, rewrite_rules 等

ルール2：現在利用中のプラグインのデータは削除しない

現在有効化しているプラグインのデータを消してしまうと、設定が初期化されたりエラーが発生します。

ルール3：安全策として「DELETE（削除）」ではなく「autoload = ‘no’」に変更する

アンインストール済みのプラグインの残骸であっても、万が一の誤認に備えて、 いきなりレコードを削除（DELETE）するのではなく、まず autoload フラグを no に変更する のがプロの現場における鉄則です。

-- 特定のオプションのautoloadを無効化する安全なSQL
UPDATE wp_options
SET autoload = 'no'
WHERE option_name = '不要と特定したオプション名';

autoload = 'no' に変更すれば、全ページでの常時自動読み込みから除外されるため、サイトの表示速度は即座に改善します。万が一プラグインの動作に影響があった場合でも、SET autoload = 'yes' で瞬時に元に戻せます。

数日間サイトの稼働を確認し、完全に不要であると確信が持てた段階で、該当レコードを削除（DELETE FROM wp_options WHERE option_name = '...'）してください。

---

データベースの再肥大化を恒久的に防ぐ wp-config.php の最適化設定

一度データベースを大掃除して身軽にしても、設定をそのまま放置していれば、数ヶ月〜1年後には再びリビジョンや自動下書きが蓄積して元の木阿弥になります。

WordPressの最重要設定ファイルである wp-config.php をチューニングすることで、 データベースの再肥大化をシステム的に恒久防止 しましょう。

設定ファイルの編集手順や安全なバックアップ方法については、以下の完全マニュアルも参考にしてください。

👉 WordPressのwp-config.php設定完全マニュアル｜セキュリティ強化とトラブルシューティング

リビジョンの保存件数を制限する設定（WP_POST_REVISIONS）

WordPressはデフォルト状態では、 投稿リビジョンを「無制限」に保存 します。記事の推敲を重ねるブロガーやWeb担当者の場合、1記事で50〜100件以上のリビジョンが生成され、データベースを圧迫します。

過去のリビジョンは直近の数件があれば実務上十分です。保存件数を制限するために、wp-config.php に以下を定義します。

// リビジョンの最大保存件数を5件に制限
define('WP_POST_REVISIONS', 5);

この設定を行うと、各記事で最新の5件のリビジョンのみが保持され、6件目以降が保存されると最も古いリビジョンが自動的に押し出されて削除されます。データベースを常にコンパクトに維持できる最も効果的な設定です。

自動保存の間隔を延長して無駄な通信・保存を減らす設定（AUTOSAVE_INTERVAL）

WordPressエディターは、記事の編集中にデフォルトで 「60秒（1分）ごと」 に自動保存を実行します。

この自動保存頻度が高すぎると、執筆中にブラウザとサーバー間で頻繁にAjax通信が発生し、編集画面の動作がもたつくだけでなく、自動下書きレコードが乱立する要因になります。

自動保存の間隔を 「160秒（約2分40秒）」 程度に延長することで、サーバー負荷と無駄なデータの生成を抑制します。

// 自動保存の間隔を160秒に延長（デフォルトは60秒）
define('AUTOSAVE_INTERVAL', 160);

ゴミ箱の自動完全消去日数を短縮する設定（EMPTY_TRASH_DAYS）

記事や固定ページ、コメントをゴミ箱に移動させた場合、WordPressはデフォルトで 「30日間」 データベース内に保持し続けます。

不要だからゴミ箱に入れたデータが1ヶ月間もデータベースに残留するのは非効率です。自動完全消去のサイクルを 「7日」 に短縮することで、不要データが速やかにデータベースから消去されるようにします。

// ゴミ箱に入ったデータを7日後に自動完全削除（デフォルトは30日）
define('EMPTY_TRASH_DAYS', 7);

肥大化再発防止用 wp-config.php 追記コードまとめ

FTPソフトやサーバーのファイルマネージャーで wp-config.php を開き、以下のコードブロックをまとめて追記します。

/* データベース肥大化防止の最適化設定 */
// リビジョンの最大保存件数を5件に制限
define('WP_POST_REVISIONS', 5);

// 自動保存の間隔を160秒に延長（デフォルトは60秒）
define('AUTOSAVE_INTERVAL', 160);

// ゴミ箱に入ったデータを7日後に自動完全削除
define('EMPTY_TRASH_DAYS', 7);

> 記述場所の注意点 > wp-config.php に設定を追加する際は、必ずファイル末尾付近にある /* That's all, stop editing! Happy publishing. */（または「編集が必要なのはここまでです」）というコメント行よりも 「上」 に記述してください。それ以降に記述しても定数が正しく読み込まれません。

---

未使用画像・プラグイン・孤立メタデータの安全な整理

データベースの大掃除に合わせて、サーバーのストレージ領域を圧迫している「Webサーバー側の不要ファイル」も大掃除しておきましょう。

未使用メディアファイルの整理における注意点と安全な手順

WordPressを長く運営していると、過去にアップロードしたものの記事内では一度も使われなくなった画像や、差し替え前の古い画像が wp-content/uploads/ 配下に大量に蓄積していきます。

未使用画像を検出・削除するには「Media Cleaner」などのプラグインが便利ですが、利用時には重大な注意点があります。

1. アイキャッチ画像やテーマ設定ロゴの誤検知に注意 : プラグインによっては、記事本文中に埋め込まれていないアイキャッチ画像、テーマカスタマイザーで設定したサイトロゴ、ファビコン、OGP設定画像などを「未使用」と誤判定してしまうことがあります。
2. 必ずゴミ箱機能（Trash）を利用する : Media Cleanerを使用する際は、即時完全削除するのではなく、一度「プラグイン専用のゴミ箱」に退避させる設定でスキャンを実行してください。
3. 削除前にサイトの主要ページを目視確認 : ゴミ箱に退避させた状態でサイトのトップページや代表的な記事を開き、画像リンク切れが発生していないか確認した上で完全消去を行いましょう。

停止中の不要プラグイン・テーマの完全削除

管理画面で「無効化（停止中）」にしたまま残してあるプラグインや、使用していない過去のデフォルトテーマ（Twenty Twenty-One等）は、単にサーバー容量を占有するだけでなく、 深刻なセキュリティ脆弱性の侵入口 になります。

攻撃者は、停止中であってもサーバー上にPHPファイルが存在していれば、脆弱性のあるコードへ直接リクエストを送り込んで侵入を試みます。

• 不要プラグイン : 「無効化」にとどめず、管理画面から 「削除」 をクリックしてファイル一式をサーバーから完全に消去します。
• 不要テーマ : 現在有効化しているテーマ（親テーマ＋子テーマ）と、トラブル時のフォールバック用として最新のWordPress公式デフォルトテーマ1つだけを残し、それ以外の過去テーマはすべて削除してください。

---

まとめ｜年末年始のWordPressサイトメンテナンス総点検

年末年始のWordPressサイト大掃除とデータベース最適化手順について、必須のポイントを振り返りましょう。

年末年始データベース大掃除の実行ステップ総まとめ

1. 作業前の完全バックアップ : プラグインおよびphpMyAdminからデータベース（SQL）をPCローカルへダウンロード退避する。
2. 初心者向け一括クリーンアップ : WP-Optimizeを活用し、リビジョン・自動下書き・スパムコメント・期限切れトランジェントを削除し、テーブル最適化を実行する。
3. 中・上級者向け深部クリーンアップ : phpMyAdminでSQLを実行し、wp_options 内で autoload = 'yes' になっている巨大レコードを特定。削除済みプラグインの残骸を autoload = 'no' に変更または安全に削除する。
4. 恒久的な再肥大化防止策 : wp-config.php にリビジョン制限（5件）、自動保存間隔延長（160秒）、ゴミ箱消去日数短縮（7日）を設定する。
5. 不要アセットの断捨離 : 未使用画像や停止中プラグイン・未使用テーマを完全削除し、サーバー容量とセキュリティ耐性を高める。

データベースを適切に軽量化・最適化することで、サイトの表示速度が劇的に向上し、Core Web Vitalsの評価向上やユーザー離脱率の改善につながります。

万全のメンテナンスを完了させ、安心して穏やかな休暇をお迎えください。