WordPressの投稿リビジョンが増えすぎた時の整理方法｜削除前の注意点

WordPressの投稿リビジョンが増えすぎて、データベースを軽くするために全部削除してよいのか迷っていませんか。リビジョンは記事の過去版を保存し、編集ミスや共同作業の上書きから戻すための機能です。件数が多いだけで直ちに障害とは限らないため、現在の投稿や復元に必要な版まで消さない順番が重要です。

結論は、先に件数と容量を測り、復元できるバックアップを確保し、対象を「投稿リビジョン」に限定して少量ずつ整理することです。削除後は保存数を制限し、定期点検へ切り替えます。感覚だけでデータベース全体を一括最適化してはいけません。

よこやま良平

20年以上ITエンジニアとしてWordPressの制作・保守・復旧に携わっている、よこやま良平です。データベース整理では、削除量より「何を残し、どこまで戻せるか」を先に決めます。初心者でも確認できる順に解説します。

この記事は通常の投稿・固定ページに保存されるWordPress標準リビジョンを対象にしています。ECの注文、予約、会員情報、フォーム送信履歴、独自プラグインの履歴は別データです。作業前に本番サイトの構成と利用中プラグインを確認し、業務データをリビジョンと思い込まないでください。

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

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

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

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

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

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

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

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

WordPressの投稿リビジョンとは何か

WordPressの投稿リビジョンは、投稿や固定ページを更新した時の過去内容をデータベースへ残し、編集画面から比較・復元できる仕組みです。不要データではなく、公開記事を誤って書き換えた時に戻すための保険なので、削除の必要性と復元価値を分けて考えます。

公開中の本文とは別の過去版として保存される

現在公開されている投稿は通常のpostやpageとして保存され、過去版はrevisionという種類で親投稿へ関連付けられます。リビジョンを正しく削除しても、現在の公開本文そのものを消す操作ではありません。ただし、条件のないSQLや誤ったプラグイン設定なら現在投稿まで対象にできるため、方法の安全性が重要です。

編集画面のリビジョン比較では、追加・削除された文章を見比べ、必要な版を復元できます。共同編集、長文記事、LP、規約ページなど、変更の影響が大きいコンテンツほど価値があります。単純に古い順からすべて消せばよいわけではありません。

自動保存と通常リビジョンは目的が少し違う

自動保存は、ブラウザを閉じた、通信が切れた、保存前に画面を移動したといった事故から編集中の内容を救う仕組みです。通常リビジョンは、更新として保存された過去版を比較して戻すために使います。どちらも編集保護ですが、作られるタイミングと保持のされ方が同じではありません。

AUTOSAVE_INTERVALを長くすれば保存回数を減らせますが、その分だけ障害時に失う編集量が増えます。リビジョン増加対策として最初に自動保存を止めるのは不適切です。まず通常リビジョンの件数と容量を確認し、必要なら保持上限を設けます。

リビジョンが役立つサイトでは残す価値が高い

更新担当が複数いる、承認前後を比較したい、法令・価格・仕様の変更履歴が重要、編集事故の影響が大きいサイトでは、一定数を残す価値があります。反対に、機械的な更新が頻繁で、外部にも確実な履歴とバックアップがある場合は、保持数を少なめに設計できます。

プラグイン無料プレゼント　リビジョン機能有効化

WordPressの投稿リビジョンが増えすぎたか確認する方法

WordPressの投稿リビジョンは、件数だけで削除せず、データベース容量・管理画面の症状・運用上の復元需要を合わせて判断します。更新回数の多い長文ページでは、一投稿だけに過去版が集中する場合もあります。

最初に症状と発生時刻を記録する

確認したい症状は、投稿編集画面だけが遅いのか、管理画面全体が遅いのか、公開ページも遅いのかです。リビジョンが多くても、原因が外部API、キャッシュ、PHPメモリ、データベースロック、バックアップ処理なら、削除しても本質的には改善しません。

遅くなる時間帯、対象投稿、保存時にかかった秒数、エラー文、PHP・MySQLの負荷を記録します。一つの長大な投稿だけで起きるなら、その投稿のリビジョン数やブロック量を重点確認します。サイト全体なら別要因を含めた切り分けが必要です。

管理画面とWP-CLIで件数を把握する

個別投稿は編集画面のリビジョン欄から過去版の存在を確認できます。ただしサイト全体の総数は分かりにくいため、サーバーへ安全に接続できる場合はWP-CLIでrevisionの件数を取得します。以下は削除せず一覧数だけを数える確認コマンドです。

wp post list --post_type='revision' --format=count

WP-CLIが使えない場合は、バックアップ機能を持つ信頼できる最適化プラグインのスキャン画面で件数を確認します。確認だけの段階で「すべて最適化」を押さず、投稿リビジョン、期限切れ一時データ、ゴミ箱、コメント、データベーステーブルを別項目として見られるものを選んでください。

データベース容量はテーブル全体と増加傾向を見る

標準リビジョンは主に投稿テーブルへ保存されますが、サイトによっては関連メタデータも増えます。phpMyAdminやサーバーのデータベース画面で、投稿テーブルだけでなくデータベース全体の容量、直近の増加量、空き容量を記録します。テーブル接頭辞はwp_とは限りません。

一度の測定だけでは通常範囲か判断しづらいため、1週間または1か月後に同じ項目を比較できる記録を残します。毎日大量に増えるなら保存上限や更新処理の見直しが必要です。長期間ほぼ変わらず容量にも余裕があるなら、急いで削除する理由は弱くなります。

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

WordPressの投稿リビジョンを削除する前の注意点

WordPressの投稿リビジョンを削除する前は、データベースだけのバックアップ、復元テスト、対象範囲、作業時間、除外対象を確定します。バックアップファイルを作っただけでは不十分で、どのサイトのどの日時へ戻せるか説明できて初めて作業を始められます。

ファイルとデータベースを同じ時点で保存する

リビジョンはデータベース内の情報ですが、復元後のWordPress本体・テーマ・プラグインと整合しなければ、確認が難しくなる場合があります。少なくとも作業直前のデータベースを保存し、可能ならファイルも同じ時点で取得します。保存先は作業対象サーバー以外にも複製してください。

WordPressバックアップの完全解説｜UpdraftPlus / BackWPup / all-in-one-wp-migrationを図解

バックアップの完了だけでなく復元経路を確認する

バックアッププラグインの「成功」表示だけを信じず、ファイルサイズ、保存日時、データベースを含むか、暗号化・パスワード、保管先へのアクセスを確認します。ステージング環境や別データベースへ復元できれば理想です。本番でしか試せない場合は、サーバー会社の復元手段と連絡先を控えます。

自動バックアップが削除作業の直前に実行されるとは限りません。前夜のバックアップしかなければ、その後に編集した記事や注文などを失います。作業直前に手動取得し、開始時刻を記録してください。

削除対象と残す範囲を文章にする

「不要データを削除する」では範囲が曖昧です。「標準の投稿・固定ページに属するrevisionだけ」「公開中の現在投稿は対象外」「注文・予約・フォーム履歴・独自投稿タイプは対象外」のように書きます。プラグインが示す項目名と実際の対象が一致するか、公式説明も確認します。

アクセスと編集の少ない時間に小さく実行する

リビジョン削除はデータベースへのDELETE処理です。件数が多いとロック、CPU負荷、バックアップ肥大、タイムアウトが起きることがあります。投稿更新、注文、フォーム送信が少ない時間を選び、メンテナンス告知や担当者への共有を済ませます。最初は一部または少量で結果を確認します。

WordPressの投稿リビジョンを安全に整理する方法

WordPressの投稿リビジョンを安全に整理する方法は、管理画面の信頼できる最適化プラグイン、WP-CLI、専門家によるデータベース操作の順で選びます。初心者は対象が画面上で分かれ、バックアップと結果確認ができる方法を優先してください。

最適化プラグインはリビジョン項目だけを選ぶ

データベース最適化プラグインを使う場合は、投稿リビジョンだけを選びます。「データベース全体を最適化」「すべての不要データ」「孤立メタを削除」などを同時に実行すると、問題が起きた時に原因を特定できません。実行前プレビュー、除外、ログ、バックアップの有無を確認します。

利用中プラグインと同じ開発元でも、更新停止や互換性問題があれば使いません。最近の更新日、対応WordPress、サポート状況、低評価の内容を確認します。作業が終わったら、不要な最適化プラグインを常駐させるかも見直してください。

WP-CLIは一覧確認後に分割して削除する

SSHとWP-CLIを扱える場合は、先に件数とID一覧を確認し、削除ログを保存してから実行します。大量IDを一度にシェルへ渡すと引数上限やタイムアウトが起きるため、一定件数ずつ処理します。以下は考え方の例で、必ず対象サイトのルートとバックアップを確認してから使います。

wp post list --post_type='revision' --format=ids | xargs -n 100 wp post delete --force

実行直後に現在投稿が開けるか、代表的な投稿のタイトル・本文・画像・カテゴリー・URLが変わっていないか確認します。削除件数と実行時刻を記録し、次のまとまりへ進みます。途中でエラーが出たら同じコマンドを無条件に繰り返さず、残件とデータベース状態を再確認します。

SQLの直接削除は条件ミスと関連データに注意する

phpMyAdminでSQLを直接実行する方法は高速ですが、接頭辞・WHERE条件・関連メタデータを誤ると被害が大きくなります。画面に表示された例をそのまま貼らず、まずSELECTで対象件数とサンプルを確認します。DELETEへ変える前に、別担当者の確認を入れるのが安全です。

外部キーがない構成でも、プラグインがリビジョンへ独自メタを保存している場合があります。投稿テーブルだけ削除すると孤立データが残ることがあるため、WordPressのAPIを通すプラグインやWP-CLIの方が扱いやすい場面があります。大規模サイトではデータベース担当者へ依頼してください。

削除後は記事・管理画面・バックアップを確認する

削除件数が想定内か、リビジョン比較欄が意図した範囲まで減ったか、投稿の更新・公開・プレビューができるかを確認します。公開ページだけでなく、管理画面の投稿一覧、検索、メディア、REST API、定期バックアップも確認してください。

WordPressデータベースアップデートに失敗した時の原因と解決方法【完全ガイド】

WordPressの投稿リビジョン削除で起きやすい失敗

WordPressの投稿リビジョン削除で起きやすい失敗は、削除そのものより、目的と対象を決めずに複数の最適化をまとめて実行することです。容量を減らせても、復元点や原因調査の材料を失えば、障害時の損失が大きくなります。

現在投稿まで消える条件で実行してしまう

SQLでpost_type条件を入れ忘れる、対象データベースを取り違える、プラグインの全投稿削除を選ぶと、現在の投稿・固定ページまで失う危険があります。実行前にSELECT相当のプレビューで件数とタイトルを確認し、対象がrevisionだけか確認してください。

最適化を同時実行して原因が分からなくなる

リビジョン、ゴミ箱、一時データ、コメント、テーブル最適化、画像整理を一度に行うと、不具合が出た時にどの処理が原因か分かりません。作業単位を分け、各段階で投稿更新と公開表示を確認します。「ワンクリックですべて高速化」は検証可能性を下げます。

リビジョン削除だけで速度改善を断定する

管理画面の遅さは、外部通信、重いプラグイン、PHPメモリ、オブジェクトキャッシュ、データベースクエリ、Cron、サーバー負荷でも起きます。削除前後で同じ操作の時間を測り、変化がなければ別原因を調べます。改善したように感じるだけでは再発防止になりません。

バックアップも同じサーバー内だけに置く

削除対象と同じサーバーだけにバックアップを置くと、容量不足、アカウント停止、ディスク障害、誤削除の影響を同時に受けます。外部ストレージへ複製し、定期的に復元テストを行います。自動化しても通知を見なければ失敗に気づけません。

WordPressのバックアップを自動化する最強の方法｜UpdraftPlus・BackWPup・All-in-One WP Migrationの使い分けガイド

WordPressの投稿リビジョンを増やしすぎない設定

WordPressの投稿リビジョンを整理した後は、WP_POST_REVISIONSで投稿ごとの保持数を決め、定期的に件数とバックアップを確認します。完全無効化より、実際に戻したい期間と更新頻度から5〜20件程度など合理的な上限を決める方が安全です。

wp-config.phpで保持数を設定する

wp-config.phpの「編集が必要なのはここまで」という行より前に、WP_POST_REVISIONSを整数で定義すると、投稿ごとに保持するリビジョン数を制限できます。たとえば10なら、通常は各投稿に一定数の過去版を残す設計になります。環境によって既存分が即時削除されるわけではありません。

define( 'WP_POST_REVISIONS', 10 );

falseを指定すれば通常リビジョンを無効化できますが、編集事故から戻せなくなるため安易に選びません。すでに同じ定数が定義されている場合は二重に追加せず、現在値を確認します。編集前後のファイルを保存し、PHP構文エラーがないことも確認してください。

保持数は更新頻度と重要度で決める

毎日更新するニュース記事、複数人で修正するLP、価格や規約の重要ページでは、少なすぎる上限が不利です。一方、完成後ほとんど変更しない固定ページでは少数でも運用できます。全投稿へ一律適用する前に、よく更新する代表記事で復元可能な期間を試算します。

自動保存間隔を長くしすぎない

AUTOSAVE_INTERVALは秒数で調整できますが、長くするほどブラウザ障害時に失う内容が増えます。データベース負荷の根拠がなく、リビジョン件数を減らす目的だけで変更しないでください。共同編集や長文執筆では、標準間隔を維持した方が安全な場合が多くあります。

月次点検で増加量と復元テストを確認する

毎月または四半期ごとに、リビジョン総数、データベース容量、バックアップ所要時間、復元テスト結果を記録します。急増した月は、大量更新、インポート、ページビルダー、同期プラグイン、API処理など原因となった変更を調べます。数値を追えば、必要な時だけ整理できます。

WordPressの投稿リビジョン整理に関するよくある質問

WordPressの投稿リビジョンを整理する時によくある疑問を、削除対象、速度、バックアップ、保持数の観点からまとめます。

WordPressの投稿リビジョンを安全に整理する手順まとめ

WordPressの投稿リビジョンは、編集ミスや上書きから記事を戻すための保険です。件数が多いだけで直ちに削除せず、投稿編集画面の症状、リビジョン総数、データベース容量、バックアップへの影響、復元に必要な期間を確認してください。

整理する時は、作業直前のデータベースとファイルを外部にも保存し、対象を標準のrevisionだけに限定します。初心者はプレビューできる信頼性の高いプラグインを使い、SSHを扱える場合はWP-CLIで件数確認後に分割削除します。SQLの直接操作は条件ミスと関連データの扱いが難しいため、専門知識が必要です。

よこやま良平が実務で重視するのは、削除後の運用まで決めることです。WP_POST_REVISIONSで必要な保持数を設定し、自動保存という事故対策は残します。月次または四半期に件数・容量・バックアップ・復元を確認すれば、一括削除を繰り返さず安全に管理できます。

WordPressのデータベース整理を自分で進められない時は

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

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

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

いまなら期間限定で