MENU
  1. ホーム
  2. WordPress
  3. WP Revisions Control 完全ガイド！【WordPressリビジョン管理】

WP Revisions Control 完全ガイド！【WordPressリビジョン管理】

広告
WP Revisions Control

サイト運用をしていると、編集履歴（リビジョン）がどんどん溜まって気になったことはありませんか？

以下のような疑問や不安を抱えている読者が多いはずです。

「リビジョンって放置しておくと何がまずいの？」
「誤って消した編集を元に戻せるのか不安……」
「プラグインを入れたら、今までの履歴は勝手に消えるの？」
「チームで編集しているとリビジョンが多すぎて管理できない」
「どのくらいの保存数に設定すれば安全なの？」
「大量のリビジョンを一括で削除しても大丈夫？」

本記事では、上の疑問一つひとつに初心者にもわかる言葉で答えながら、実際に「WP Revisions Control」を使って安全に導入・運用する手順を丁寧に解説します。

この記事を読み終える頃には、リビジョンの仕組みが理解でき、バックアップ→導入→設定→運用という一連の流れを自信を持って実行できるようになります。

この記事の構成

  1. リビジョンとは何か・放置のリスク
  2. WP Revisions Control でできること（利点と限界）
  3. インストールと初期設定（ステップバイステップ）
  4. 既存リビジョンの整理方法（安全な一括削除）
  5. 日常運用とチームでのルール作り
  6. 動作確認と互換性チェック、運用のベストプラクティス

まずは現在の状況の把握（リビジョン数の確認とバックアップの取得）から始めましょう。

安全対策が整っていれば、次のステップに進んでも問題は起きにくくなります。

目次

概要：リビジョンとは何か、なぜ制御が必要か

リビジョン（Revision）は、WordPress が投稿や固定ページを編集したときに自動で保存する「過去の編集履歴」です。

編集中に誤って内容を消してしまったときや、以前の状態に戻したいときに復元や差分確認ができるため、編集の安全装置として非常に便利です。📌

しかし、何もしないで放置すると、サイトの投稿数や更新頻度に応じてリビジョンが大量に溜まり、データベースが大きくなってしまうことがあります。

リビジョンは wp_posts テーブルに追加行を作るため、数が増えるほどデータベースのサイズとクエリ負荷が増え、パフォーマンス低下やバックアップ容量の増加といった問題を招く可能性があります。

これが「リビジョンを制御すべき理由」です。

リビジョン機能の仕組みと運用上の課題

仕組み

  • WordPress は通常、編集中に自動保存（autosave）を行い、また「保存／公開」操作のたびに新しいリビジョンを生成します。
  • 各リビジョンは投稿本文のスナップショット（＋編集者・タイムスタンプ）としてデータベースに保存されます。

運用で起きやすい課題

  • データベース肥大化：頻繁に更新する記事や大量の投稿があるサイトでは、リビジョンが短期間で膨れ上がりやすい。これによりバックアップ時間やストレージが増えます。
  • クエリ遅延：wp_posts に大量のリビジョン行があると、特にホスティングのリソースが限られる環境でクエリ速度に影響が出ることがあります。
  • 運用上の混乱：チームで編集している場合、不要な細かなリビジョンが多いと「どの版が正しいのか」を判別しづらくなることがあります。
  • 既存リビジョンの扱い：リビジョン制限を設定しても、導入前に既に保存されている過去のリビジョンは自動で削除されない点に注意が必要です（別途クリーンアップが必要）。

ポイント：リビジョンは「便利だが放置は危険」。必要な分は残しつつ、不要な蓄積を防ぐ運用ルールとツールが重要です。

プラグインで期待できる効果（利点の整理）

WP Revisions Control（代表的な例）のようなリビジョン制御プラグインを使うと、以下のような実益が期待できます。

スクロールできます
効果詳細
データベースの肥大化抑制投稿タイプごとに保持するリビジョン数を制限でき、不要な蓄積を抑えられる。
性能維持リビジョン行が減ることでクエリの負荷軽減・バックアップ処理の高速化が見込める。
柔軟な制御「投稿は最大5件、固定ページは最大2件」など、投稿タイプ単位で異なる制限が可能。
運用の簡素化管理画面（通常は「設定」→「投稿設定／執筆設定」等）で直感的に設定でき、コード編集が不要。
個別削除のサポートプラグインによっては投稿編集画面から該当投稿のリビジョンを即時削除（Purge）できる機能がある。既存履歴の一括削除は別ツールが必要な場合も。

運用例（すぐ使える）

  • 小規模ブログ：投稿は5件、固定ページは2件に制限。
  • 編集チームあり：重要なコラムのみリビジョンを多めにし、その他は制限する。
  • 既存大量リビジョンがある場合：制限の導入 + 一括削除ツールで一度クリーンアップしてから運用開始。

注意点

  • プラグインは「今後作られるリビジョンの数」を制御するのが基本で、導入前の古いリビジョンは残る。必要なら別途削除プラグインやデータベース操作で対応する。

まとめ（次にやること・チェックリスト）

まず確認すること

  1. 現状のリビジョン数（例：wp_posts の post_type = 'revision' が何件か確認）。
  2. どの投稿タイプを厳しく制限すべきか（固定ページ、投稿、カスタム投稿など）。

導入の流れ

  1. プラグインを導入・有効化 → 2. 設定画面（Settings → Writing 等）で投稿タイプ別に上限を指定 → 3. 必要なら既存リビジョンを一括削除してクリーンアップ → 4. 運用ルールをチームで共有。

最後に一言
リビジョンは“保険”です。すべてを無効化するのは危険ですが、適切に制御してこそ本当の意味で便利に使えます。まずは小さく試して、効果を確認してから全体ルールを決めるのがおすすめです。

導入前に知っておくこと（注意点）

WP Revisions Controlや類似の「リビジョン数を制限するプラグイン」は強力ですが、導入前に押さえておかないと運用で困る点がいくつかあります。

以下は初心者にもわかりやすく整理したチェックリストと注意点です。

導入前に必ずバックアップを取ることを最優先にしてください。💾

既存リビジョンへの影響について

要点：プラグインで設定する上限は「これから作られるリビジョン」に適用されます。導入前に既に保存されている過去のリビジョンは自動で消えません。
つまり、設定を変えても既に蓄積された履歴は残り続けるため、導入だけでデータベース容量が減るわけではありません。

実務での流れ（安全に進める手順）

  1. 現状把握：まず現状のリビジョン数を確認する。
    • 目安コマンド（管理者向け、WP-CLIが使える場合）
    wp post list --post_type='revision' --format=csv --fields=ID,post_parent,post_date | wc -l
    • またはデータベース管理ツールで post_type = 'revision' の件数を確認。
  2. バックアップを取得：データベースの完全バックアップを必ず取得する（ファイルも含めて）。
  3. 設定導入：WP Revisions Control を入れて「今後の」保持数を設定する。
  4. 既存リビジョンの整理（任意）：過去の大量リビジョンを削除したい場合は、別途一括削除ツール（専用プラグイン、WP-CLI、またはSQL）を使う。
    • 一括削除は取り返しがつかないので、バックアップ→ステージングでテスト→本番で実行の順が安全。
  5. 確認：削除後、公開ページや差し戻し機能が問題なく動くか確認する。

簡単な注意文：既存の履歴を消すと「過去の内容に戻せない」ことがあるため、重要な記事やコラムはバックアップを別保管するか、リビジョンを別途エクスポートしておくと安心です。

制限や短所（プラグインの弱点）

まとめ（主なデメリット）

  • 既往のリビジョンは残る：前述の通り、導入だけでは過去分は削除されない。
  • 自動保存（Autosave）との違い：オートセーブ（編集中の一時保存）は別の仕組みであり、必ずしもプラグインで完全に制御できない場合がある。
  • 編集フローに影響する可能性：編集履歴を多めに残しておく必要があるチームワーク（例：査読ワークフローや差戻しの多い編集環境）では、保持数を少なく設定すると業務に支障が出る場合がある。
  • 互換性の問題：一部のテーマや他プラグイン（履歴を参照するプラグイン、カスタム投稿を多用するプラグイン等）と相性が悪く、想定外の動作をすることがある。
  • マルチサイトでの管理：マルチサイト環境では、サイトごとの挙動やネットワーク管理者権限の扱いに注意が必要。ネットワーク全体で一気に設定変更すると影響範囲が大きい。
  • 大量削除の負荷：一括で大量のリビジョンを削除するとDBに負荷がかかる。SharedホスティングではタイムアウトやI/O制限に引っかかることがある。
  • 誤削除リスク：自動化やCLIでの削除は便利だが、誤コマンドで投稿本体を消してしまう事故が発生することがある。

具体的な注意点と対処法

  • 設定の目安を設ける：最初は保守的な数（例：投稿5件、固定ページ2件）にして様子を見る。運用で不便があれば調整する。
  • ステージングで事前検証：特に大規模サイトや編集チームがいるサイトは、本番前にステージング環境で設定変更 → 実際に復元や比較が可能か確認する。
  • 互換性チェック：主要なプラグイン（キャッシュ、バックアップ、エディタ拡張、編集ワークフロー系）とテストして、機能に問題がないかを確認。
  • 削除は段階的に：既存の大量リビジョンを減らす場合、少しずつ削除してサイト動作を監視する。場合によってはホスティング側に相談して夜間に実行する。
  • 権限管理：誰でも一括削除や設定変更できる状態にしない（管理者権限の管理）。重大操作は複数人の承認プロセスを作ると安心。
  • ログとモニタリング：削除や設定変更のログを残し、サイト速度やDBサイズの変化を数日〜数週間監視する。

実践チェックリスト（導入前にやること）

  • [ ] サイト全体とデータベースの完全バックアップを取得した。
  • [ ] 現在のリビジョン件数と、どの投稿タイプに多いかを確認した。
  • [ ] ステージング環境でプラグインを導入して動作検証を行った。
  • [ ] チーム全員に運用ルール（何件残すか、誰が削除できるか）を共有した。
  • [ ] 既存リビジョンを削除する場合は、少量ずつ実行して影響を監視する方法を決めた。

最後に（初心者向けの一言アドバイス）

WP Revisions Control は「これから増える分」を賢く制御するための道具です。

導入だけで問題が完全解決するわけではないので、バックアップ→現状把握→ステージングで検証→慎重に導入という順序を守ることが最も重要です。

安全第一で進めましょう！ ✅

インストール方法（手順別）

はじめに： インストール前に必ずサイトとデータベースのバックアップを取ってください。導入後に問題が起きたときに元に戻せるようにしておくことが最優先です。💾

下では「管理画面からの導入」と「配布ファイルを使った手動インストール（アップロード／FTP）」の両方を、初心者向けに丁寧に説明します。

最後に導入後にやるべき確認作業とよくあるトラブル対処法もまとめます。

管理画面経由でのインストール手順

概要： WordPress の管理画面（プラグイン検索）から直接インストールして有効化する最も簡単な方法です。

  1. WordPress に管理者でログインする。
  2. 左メニューの「プラグイン」→「新規追加」を開く。
  3. 右上の検索ボックスに「WP Revisions Control」または目的のプラグイン名を入力して検索する。
  4. 表示されたプラグインの中から該当項目を見つけ、「今すぐインストール」をクリックする。
  5. インストールが終わったら 「有効化」 をクリックする。
  6. 有効化後、左メニューの「設定」や「ツール」等にプラグインの設定ページが追加されている場合は開いて初期設定を行う。

チェックポイント（管理画面法）

  • 管理画面での検索結果に複数バージョンや類似名が出ることがあるため、作者名や説明を確認して正しいものを選ぶ。
  • サイトでファイルアップロード上限が低いホスティングでも、管理画面経由のインストールは通常問題ありません。
  • 有効化直後にエラーが出る場合は、プラグイン同士の競合や PHP バージョンの非対応が考えられるため、エラーメッセージを確認する。

配布ファイルを使った手動インストール方法

概要： プラグインの ZIP ファイルをダウンロードして管理画面経由でアップロードする方法と、FTP/SFTP で直接 wp-content/plugins/ に展開して有効化する方法の2通りを扱います。

A. 管理画面から ZIP をアップロードしてインストールする手順

  1. プラグイン ZIP を事前にダウンロードしておく（ローカル保存）。
  2. WordPress 管理画面の「プラグイン」→「新規追加」→「プラグインのアップロード」をクリック。
  3. 「ファイルを選択」から ZIP ファイルを指定し、「今すぐインストール」を押す。
  4. インストールが完了したら 「プラグインを有効化」 を押す。
  5. 必要に応じて設定画面で初期設定を行う。

注意点（ZIPアップロード）

  • サーバーの upload_max_filesize が小さいとアップロードできない場合がある（その場合はFTPでの手動配置を検討）。
  • ZIP 内のフォルダ構成が plugin-folder/plugin-files のような正しい形式であるか確認する。

B. FTP/SFTP を使って手動でインストールする手順

  1. ローカルでプラグイン ZIP を解凍し、解凍後のフォルダ（例：wp-revisions-control）を用意する。
  2. FTP/SFTP クライアント（FileZilla など）でサーバに接続する。
  3. サーバ側の WordPress インストールディレクトリ内の wp-content/plugins/ フォルダを開く。
  4. 解凍したプラグインフォルダを wp-content/plugins/ にアップロード（フォルダ丸ごと）。
  5. 管理画面の「プラグイン」ページを開き、アップロードしたプラグインの 「有効化」 をクリックする。
  6. 設定画面がある場合は初期設定を行う。

注意点（FTP）

  • アップロード中にタイムアウトや接続切断が発生するとファイルが壊れることがあるため、完了するまで確認する。
  • アップロード後にフォルダの所有者・パーミッションが原因でプラグインが認識されない場合がある（その際はホスティングのファイルマネージャやサポートに相談）。
  • FTP 操作に不慣れな場合は、管理画面の ZIP アップロードを優先するのが安全。

インストール方法の比較

スクロールできます
項目管理画面からZIPアップロードFTP/SFTP
初心者向け◎◎△
ファイルサイズ制限の影響少ない有り得るなし
サーバー権限が必要かほぼ不要ほぼ不要必要（FTPアクセス）
トラブル発生時の復旧のしやすさ◎◎△（誤操作のリスク）

インストール後にやるべきこと（確認と初期設定）

  1. プラグインを有効化したら、まず設定ページを開く。
  2. サイト全体や投稿タイプごとのデフォルト上限を設定する（例：投稿5、固定ページ2）。
  3. テスト投稿を作って編集を何度か行い、リビジョンが設定どおり保存されるか確認する。
    • 編集 → 保存 を複数回行い、編集画面の「リビジョン」セクションで件数を確認する。
  4. 既存のリビジョンが多い場合は（必要なら）一括削除の計画を立てる（バックアップ必須）。
  5. サイトの表示・編集・復元（リビジョンから戻す）を実際に試して問題ないかチェックする。✅

よくあるトラブルと対処法

  • プラグインがインストールできない／ZIP がアップロードできない
    → サーバの upload_max_filesize や PHP 設定の問題。FTPでのアップロードを試すか、ホスティングに相談。
  • プラグインを有効化したら画面が真っ白（白画面）になった
    → プラグインの互換性問題。FTP で該当プラグインフォルダの名前を変更して一時的に無効化し、エラーログを確認。
  • 設定が反映されない／既存リビジョンが残る
    → 設定は「今後作成されるリビジョン」に適用されるため、既存の履歴は別途削除が必要（削除前にバックアップ）。
  • FTP アップロード後にプラグインが管理画面に出ない
    → フォルダ構成や権限を確認。フォルダ名が重複していないか、正しい階層に置かれているかを見直す。
  • 一括削除で時間がかかる／タイムアウトする
    → 小分けで削除するか、WP-CLI を使える場合は CLI で実行、あるいはホスティングにバッチ実行を依頼する。

インストール時の安全ワンポイント

  • まずはステージング環境でインストール→動作確認すること。特に編集フローが複雑なサイトやマルチサイト環境では本番直導入は避ける。
  • 管理者権限のある人を限定し、重大な設定変更・一括削除の前には必ずバックアップ。
  • 設定変更後は 1週間ほど運用して影響を監視すると安全です（DBサイズ・ページ表示速度・編集時の挙動など）。

まとめ（短いチェックリスト）

  • [ ] バックアップを取った。
  • [ ] ステージングで試した（可能なら）。
  • [ ] 管理画面／または手動アップロードでプラグインを導入した。
  • [ ] プラグインを有効化して初期設定を行った。
  • [ ] テスト編集でリビジョンが期待どおり動作するか確認した。
  • [ ] 既存の大量リビジョンがある場合、削除手順を決めてから実施した。

導入で迷ったら、まずは管理画面経由で試して設定を確認→問題なければ本番へ反映する、という段階的な進め方が一番安全です。

基本設定の流れ（初期セットアップ）

WP Revisions Control を有効化したら、まず「どこで何を設定するか」を順を追って落ち着いて行いましょう。

ここでは画面の場所の見つけ方 → 全体設定 → 投稿タイプ毎の個別設定 → UI の使い方 → デフォルト値の考え方まで、初心者にもわかるように丁寧に説明します。🛠️

管理画面上の設定画面の場所と見つけ方

  1. プラグイン一覧を確認
    • 管理画面の「プラグイン」→「インストール済みプラグイン」を開き、WP Revisions Control の項目を探します。
    • その行に「設定」や「Settings」へのリンクが表示されている場合は、まずそこをクリックします。
  2. 設定メニューを辿る
    • プラグインによっては、「設定（Settings）」メニュー内、あるいは「ツール（Tools）」や「投稿（Posts）」のサブメニューに項目が追加されることがあります。
    • 管理メニューに新しい項目が見当たらない場合は、プラグイン名の「詳細表示」を開くと設定画面への誘導が書かれていることが多いです。
  3. 管理バーの検索を使う
    • 管理画面上部の検索ボックス（画面右上）に「revision」や「リビジョン」と入力すると該当ページが出ることがあります。
    • また、プラグインの説明文（プラグイン一覧での短い説明）に「設定画面は ○○ にあります」と書かれていることがあるので確認してください。

Tip: 見つからないときは、プラグインを一度無効化→再有効化すると設定リンクが表示される場合があります（ただし本番で行う際はバックアップ推奨）。

サイト全体の上限値を決める方法（全体設定）

  1. 設定画面を開く
    • 上で見つけた設定ページを開くと、まず「サイト全体に適用するデフォルトのリビジョン上限」を指定する項目があるはずです。
  2. 数値を入力または選択する
    • 多くのプラグインは プルダウンか数値入力欄で指定します。例：0（無制限）/ 2 / 5 / 10 など。
    • 「0」を選ぶと無制限になる実装があるので、意味は表示文言で必ず確認してください。
  3. 保存ボタンを押す
    • 設定変更後は必ず 「保存」 を押して反映させます。保存後、新しい投稿・編集から上限が適用されます（既存リビジョンは自動で削除されない点に注意）。
  4. 確認作業
    • テスト記事を作って編集を繰り返し、設定どおりにリビジョンが保存されているか確認します。

投稿・固定ページごとの個別制御のやり方

  1. 投稿タイプごとの設定項目を探す
    • 設定画面に「投稿（Posts）」「固定ページ（Pages）」「カスタム投稿タイプ」の個別設定欄が用意されていることが多いです。
    • そこから各投稿タイプに対して別の上限値を設定できます。
  2. 個別記事レベルでの上書き（可能な場合）
    • プラグインによっては、投稿編集画面に「この投稿のリビジョン上限」を設定する欄が追加されます。
    • 重要記事だけ上限を高くしたい場合は、編集画面で個別に設定してください。
  3. 大規模運用のコツ
    • カスタム投稿が多いサイトでは、投稿タイプ毎に運用ルールを作ると管理が楽になります（例：ニュースは3、コラムは10、製品情報は2）。
  4. 設定適用のタイミング
    • 個別設定は保存後の新しいリビジョンに適用されます。既存リビジョンの扱いは別途処理が必要です。

最大保存数を選ぶUI（プルダウン等）の使い方

  • UI の要素
    • プルダウン：事前定義された値から選ぶ（初心者向け）。
    • 数値入力欄：好きな数値を入力できる（柔軟だが間違いのリスクあり）。
    • トグル（チェックボックス）：機能オン/オフ（例：リビジョンを無効化する）に使われる。
  • 選び方のガイドライン
    • プルダウンには小刻みな値（1,2,3,5,10）が並ぶことが多いので、運用に合わせて選んでください。
    • 入力欄を使う場合は 誤って大きな数値を入れないよう注意（例：1000等はDB肥大化の原因）。
    • 「0」が意味する挙動（無制限／無効化のどちらか）は UI で明記されていることが多いので、説明文をよく読む。
  • 視覚的な確認
    • 設定変更後は、投稿編集画面の「リビジョン」欄で現在保存されている件数と上限が一致しているかをチェックしましょう。

デフォルト値と「リビジョン範囲」の設定概念

  • デフォルト値とは
    • プラグインがインストールされた直後に自動で適用される「初期の上限値」です。サイト全体に影響するので、導入時は保守的（控えめ）な数値を設定するのが安全です。
  • リビジョン範囲（概念説明）
    • 「リビジョン範囲」とは、いつまでの履歴を保持するか（期間）やどの程度の変更を個別に保存するか（粒度）を指す考え方です。
    • 具体例：
      • 範囲A（直近の小さな変更を細かく残す）：編集頻度が高いドラフトや作業中の記事向け。
      • 範囲B（重要バージョンのみ保存）：完成記事や公開済みコンテンツ向け。
  • プラグインでの実装パターン
    • 多くのリビジョン制御プラグインは「件数ベース」で保持する仕組み（例：最新○件のみ保持）。
    • 一部は「期間ベース（例：30日分を保持）」や「重要なリビジョンのみ保持」といった細かいルールを提供する場合があります。UIにどの方式かが明示されているか確認してください。
  • 初期値の決め方（実務的）
    • 個人ブログ：投稿は3〜5件、固定ページは1〜2件。
    • ビジネスサイト：重要なページは5〜10件、ニュースは2〜3件。
    • 大規模編集チーム：差し戻しが多い場合は多めに（10件以上）設定して様子を見て調整。

最後に：設定作業の実践フロー（短い手順リスト）

  1. 設定画面を見つける（プラグイン一覧→設定、または Settings/Tools）。
  2. サイト全体のデフォルト上限を入力・保存する。
  3. 投稿タイプ毎の上限を設定する（必要に応じて個別設定）。
  4. テスト記事で編集→保存→「リビジョン」欄を確認する。
  5. 1週間ほど運用して DB サイズ・編集ワークフローに問題がないか監視する。

補足（注意）：設定は「今後の保存分」に効くのが基本です。既に大量に溜まったリビジョンは別途クリーンアップが必要なので、導入時には現状の件数確認とバックアップを忘れずに行ってください。🔍

日常の使い方（運用）

サイトを運用するうえで「リビジョン制御」は日常業務に密接に関係します。

ここでは、管理画面／投稿編集画面での確認・削除操作と、バージョン（リビジョン）の比較・復元方法を初心者にもわかりやすく、手順・注意点つきで解説します。

管理画面や投稿編集画面での操作方法（保存数確認・削除）

基本方針：

  • まず見る場所を覚える（編集画面の「リビジョン」セクション、プラグイン設定ページ、プラグインが追加する個別メタボックスなど）。
  • 操作前にバックアップ。特に削除操作は不可逆なので、必ず最新のバックアップを取ってから行ってください。💾

投稿編集画面での確認手順（Gutenberg / ブロックエディタ）

  1. 投稿（または固定ページ）の編集画面を開く。
  2. 右サイドバーの「ドキュメント」や「投稿の状態」などのブロック群を確認すると、「リビジョン：○件」のような表示がある場合があります。ここから「表示」または「リビジョンを閲覧」リンクをクリックします。
  3. リビジョン画面で件数や最新の保存日時を確認できます。

投稿編集画面での確認手順（クラシックエディタ）

  1. エディタ画面の上部または右側に「リビジョン：○」のリンクが出ます。
  2. そのリンクをクリックしてリビジョン一覧・比較画面に入ります。

保存数を確認する別の場所

  • プラグインの 設定画面（WP Revisions Control の設定ページ）で、投稿タイプごとの「現在の上限」や個別設定の有無が表示されることがあります。
  • 大量のリビジョンを集計で見たい場合は、管理者向けの簡易レポートや DB クエリ（上級者向け）で post_type = 'revision' の件数を確認します。

リビジョンの削除（個別・一括）の操作方法と注意点

個別削除（投稿編集画面から）

  • プラグインが投稿編集画面に「この投稿のリビジョンを削除」ボタンを追加している場合は、該当ボタンをクリックして削除できます。操作は即時反映されることが多いので、誤操作に注意。
  • 操作の前に、削除対象のリビジョンが本当に不要かを確認してください（差分を見てから削除することを推奨）。

一括削除（大量の既存リビジョン）

  • 大量削除は DB に高負荷を与える可能性があります。夜間やアクセスの少ない時間帯に、小分けで実施するか、WP-CLI を使うほうが安全です。
  • 一括削除の例（WP-CLI を使える環境の参考例）：
  # すべてのリビジョンを一括取得して削除（実行前に必ずバックアップ）
  wp post delete $(wp post list --post_type='revision' --format=ids) --force

注意：CLI 操作は強力ですが取り返しがつかないため、操作前に必ずバックアップとステージングでの検証を行ってください。

トラブル対処（削除関連）

  • 削除後に特定の復元が必要になった場合、削除したリビジョンは原則復元できません（DB バックアップからのリストアが必要）。
  • 一括削除でタイムアウトが発生する場合は、ホスティングのサポートに相談するか、削除を分割して実施してください。

バージョンの比較と復元の仕方

目的別の道具立て

  • 差分を見て戻す（部分的に復元）：エディタの「リビジョン比較」機能を使う。
  • 完成版に丸ごと戻す：復元ボタンでそのリビジョンに戻す。
  • 大規模なロールバック：DB レベルやバックアップからのリストア（サイト全体）を検討。

リビジョン比較の基本操作（手順）

  1. 対象の投稿編集画面で「リビジョン：○件」をクリックしてリビジョン一覧を開く。
  2. 比較画面では 左右またはスライダーで2つのバージョンを選択できます（UIはエディタによって異なります）。
  3. 画面上で「その差分（何が変わったか）」がハイライト表示されるので、戻したい箇所・バージョンを確認します。
  4. 問題なければ「このバージョンを復元」ボタンを押すと、その時点の内容に記事が戻ります。
    • 復元は即時反映されるため、復元後も編集画面で内容を確認して保存してください。

復元時の注意点

  • 復元は「現在の編集状態」を上書きする可能性があるので、復元前に現在の状態を別名でコピー（下書き保存）するのが安全です。
  • 複数人で編集するサイトでは、誰がいつ復元したかをチーム内で記録しておくと混乱を防げます。

差分の読み方のコツ

  • 大きな変更（段落の追加・削除）は目立ちますが、微差（スペース・改行・HTMLタグ）でも差分として拾われます。重要な段落の意味が変わっていないかを優先して確認しましょう。🔎

日常運用のチェックリスト（クイック）

  • [ ] 投稿編集前にサイドバーで現在のリビジョン数を確認した。
  • [ ] 重要な記事を復元する前に、現状を下書きコピーした。
  • [ ] 大量削除はバックアップ取得＋夜間に小分けで実行した。
  • [ ] 復元や削除の操作ログ（誰がいつ実行したか）を管理者間で記録している。
  • [ ] リビジョン上限は運用ルールに合わせて定期的に見直している（例：四半期ごと）。

よくある質問（FAQ）＆解決ヒント

Q. 編集を誤って上書きしてしまった。すぐ戻せますか？
A. 投稿編集画面のリビジョン比較から最近のリビジョンを選び、「復元」を押せば元に戻せます。復元前に現在の内容を別名で保存しておくと安全です。

Q. 削除してしまったリビジョンを復元できますか？
A. 基本的にアイテム単位で削除したリビジョンは復元できません。復元したければ、データベースのバックアップから復元する必要があります。

Q. 誰がリビジョンを削除したかわからないときは？
A. プラグインや管理ログ（監査ログ）を導入していれば誰が何をしたかを辿れます。重要操作はログ化する運用をおすすめします。

まとめ（運用で失敗しないために）

  • 日常は確認→比較→判断→実行の流れを習慣化しましょう。
  • 削除や一括処理はリスクが高いので、必ずバックアップを取り、出来ればステージングで試行してから本番で実施してください。
  • 小さな運用ルール（例：重要記事はリビジョンを10件に設定、削除は管理者のみ実行）を決めておくと、トラブルが減ります。🔐

既存リビジョンの整理と代替手段

過去に蓄積されたリビジョンをまとめて減らしたいときや、プラグイン以外の方法でリビジョンの挙動を変えたいときの実務的な選択肢を整理します。

それぞれの方法のやり方・利点・リスクを明確にまとめました。作業前に必ずバックアップを取り、可能ならステージング環境で検証してください。💾⚠️

大量リビジョンを一括削除するツール／方法

概要：既に溜まったリビジョンをまとめて削除するには、（1）専用プラグイン、（2）WP-CLI、（3）直接SQL操作、のいずれかが現実的です。以下に具体手順と注意点を示します。

A. 専用プラグインを使う（初心者向けで安全）

  • 代表的な用途：既存リビジョンの一覧確認 → 不要分の一括削除 → 最適化（DBの最適化機能つきが多い）。
  • 利点：GUI 操作で安全・直感的。リトライや削除対象のプレビューがあることが多い。
  • 注意点：削除は不可逆。削除前に必ずバックアップを取る。大量削除で時間がかかる場合、ホスティング側でタイムアウトが起きることがある。

実行の流れ（例）

  1. プラグインをインストール・有効化。
  2. 「リビジョン削除」機能を開き、削除対象（古い日付／全て／投稿タイプ別など）を選択。
  3. バックアップを確認してから実行。
  4. 削除後に DB 最適化を行う（プラグインに機能があれば実施）。

B. WP-CLI を使う（中〜上級者向け、効率的）

  • 利点：コマンドラインで大量データを効率良く処理できる。タイムアウトやブラウザ依存が少ない。
  • 注意点：サーバに WP-CLI が入っていて SSH アクセス権が必要。コマンドは取り返しがつかないので慎重に。

よく使うコマンド例（実行前に必ず --dry-run 相当で確認）：

# すべてのリビジョンIDを取得して削除（危険！バックアップ必須）
wp post delete $(wp post list --post_type='revision' --format=ids) --force

安全対策：

  • 先に wp post list --post_type='revision' --format=ids | wc -w などで件数確認。
  • 小分けに削除（例：投稿日時でフィルタ、古い日付分だけ削除）する。
  • ステージングで試す。

C. 直接SQLで削除する（熟練者向け・慎重に）

  • 利点：細かい条件で削除できる（例：特定日以前のリビジョンのみ削除）。
  • 注意点：SQLミスはサイト破壊に直結。必ず DB のスナップショット（バックアップ）を保存し、ステージングで検証すること。

シンプルな削除例（例：2023-01-01 より前のリビジョンを削除）

DELETE FROM wp_posts
WHERE post_type = 'revision'
  AND post_date < '2023-01-01';

注意：本番で実行する前に SELECT COUNT(*) ... で対象件数を確認し、少しずつ削除することを推奨します。

プラグインを使わずにリビジョン自体を無効化する方法

概要：今後のリビジョン生成を止めたい場合、wp-config.php に定数を追加するか、functions.php のフィルターで制御します。※既存のリビジョンは消えません（別途削除が必要）。

A. wp-config.php に定義を追加する（サイト全体に適用）

  • 使い方（例）：wp-config.php の /* That's all, stop editing! Happy publishing. */ の直前に追加します。
// リビジョンを無効化（将来のリビジョンが作られなくなる）
define( 'WP_POST_REVISIONS', false );

// または、保持するリビジョン数を指定（例：各投稿につき最新3件のみ）
define( 'WP_POST_REVISIONS', 3 );

注意点：

  • false にすると新しいリビジョンが作成されなくなる実装が多いが、環境により挙動が異なる場合があるため、ステージングで検証してください。
  • 既存データは残るので、不要な過去リビジョンは別途削除が必要。

B. テーマの functions.php で投稿タイプ別に細かく制御する（柔軟）

  • 使い方（例）：投稿タイプごとに異なる保持数を返すフィルターを追加できます。
// functions.php に追加
add_filter( 'wp_revisions_to_keep', 'my_revisions_to_keep', 10, 2 );
function my_revisions_to_keep( $num, $post ) {
    // 固定ページは最大2件、その他の投稿は5件保持
    if ( 'page' === $post->post_type ) {
        return 2;
    }
    return 5;
}

利点：投稿タイプや条件（投稿メタなど）に応じた柔軟な制御が可能。
注意点：テーマファイルに直接書くとテーマを切り替えたときに設定が消えるため、子テーマやサイト固有のスニペット管理プラグインを使うのが安全です。

方法ごとの比較

スクロールできます
方法利点欠点初心者向け度
専用プラグインGUIで操作しやすい、安全機能あり大量削除でタイムアウトすることがある◎
WP-CLI高速・小分け実行しやすいSSH/WP-CLI 必須、コマンドミスのリスク△〜◎（中級者向け）
直接SQL高度な条件で削除可能ミスが致命的、バックアップ必須×（上級者のみ）
wp-config / functions.php で無効化コード1行で効果がある既存履歴は残る、テーマ依存の危険あり△（要テスト）

安全に実行するためのベストプラクティス（必読）

  1. 必ずバックアップ：DB とファイルの完全バックアップを事前に取る。
  2. ステージングで検証：本番で実行する前に同様の手順をステージングで試す。
  3. 小分けで実行：大量削除は一度にやらず、日付や件数で分割して実行。
  4. ログを残す：誰がいつ何を削除したかを記録しておく（管理者ログ、監査用プラグインなど）。
  5. 監視：削除後は DB サイズ、サイト表示速度、編集／復元機能を数日間監視する。
  6. 権限管理：削除操作は管理者に限定し、権限を厳格に管理する。

実務チェックリスト（作業前後）

  • [ ] 最新バックアップを取得した（DB・ファイル両方）。
  • [ ] ステージングで同手順を検証した。
  • [ ] 削除対象の件数・条件を事前に確認した（SELECT COUNT(*) ...）。
  • [ ] 削除は夜間・アクセス低下時間帯に小分けで実行した。
  • [ ] 削除後に復元テスト（重要記事）を行い、問題がないか確認した。
  • [ ] 操作ログを保存し、関係者に通知した。

最後に一言

リビジョンのクリーンアップは有効なメンテナンスですが、取り返しのつかない操作でもあります。

「何を」「どの範囲で」「どの方法で」消すのかを必ず明確にし、バックアップとステージング検証を最優先に進めてください。

動作確認・互換性チェック

WP Revisions Control を本番で使う前に、プラグイン自体や導入後の挙動がテーマ／他プラグイン／WordPress 本体のバージョンと問題なく動くかを必ず確認しましょう。

ここでは「何を」「どの順で」「どうチェックするか」を初心者向けに丁寧に説明します。✨

重要：まずは必ずステージング環境でテストしてください。本番直接導入はリスクが高いです。

1) まず確認すること（準備フェーズ）

  • プラグインのページで「最終更新日」「バージョン」「Tested up to（対応WPバージョン）」を確認する。 プラグインの設定は通常 「設定 > 執筆（Settings > Writing）」 に追加される実装です。
  • プラグインの最新バージョン情報と更新履歴をチェックする（頻繁に更新されているか、不具合報告が多くないか）。最近の更新情報やバージョン表示も確認してください。

2) ステージングでの基本チェック手順（推奨順）

  1. ステージング環境を用意する（本番と同じWPバージョン／同じテーマ／主要プラグインを入れた環境）。
  2. フルバックアップ（DB＋ファイル）を取る。
  3. プラグインをインストールして有効化する（管理画面から）。プラグインは通常「設定 > 執筆」に項目が追加されます。
  4. 基本機能テスト
    • 投稿（投稿タイプごと）に対してリビジョン上限を設定 → 編集を複数回行ってリビジョン数が上限通り保存されるか確認。
    • 編集画面での「リビジョン表示／復元」が正常に動作するか確認。
  5. サイト表示チェック
    • フロントページ、代表的な固定ページや投稿を確認（白画面やエラーが出ないか）。
    • 管理画面（投稿一覧、編集画面）でJSエラーや表示崩れがないかを確認。
  6. ログとエラーチェック
    • PHP エラーログ、サーバーログ、ブラウザのコンソールにエラーが出ていないか確認。
  7. パフォーマンステスト（任意）
    • DB サイズ、応答時間、バックアップ処理時間に目立った変化がないか簡易チェック。

3) テーマや他プラグインとの相性チェック手順（例：SWELLなど）

チェック項目（実務）：

  • カスタム投稿タイプの動作確認
    • カスタム投稿タイプを多用するサイトでは、該当投稿タイプごとにリビジョンが適切に制御されるかテストしてください。※一部報告ではカスタム投稿タイプで挙動に問題が出る事例があります（要ログ確認）。
  • エディタ種類（ブロック/Gutenberg と クラシック）の確認
    • 使用しているエディタでリビジョンの表示・比較・復元が問題なく行えるかを確認します。
    • ブロックエディタ固有のブロックデータが変化していないか慎重にチェック。
  • 代表的なプラグインとの組合せテスト
    • キャッシュ（キャッシュ系）、バックアップ、ページビルダー（テーマ付属の機能含む）、カスタム編集ワークフロー系プラグイン等と併用して問題が出ないか確認。
    • 特にバックアップ系やDB最適化系はリビジョン操作後の挙動に影響する場合があるので注意。
  • テーマ固有の挙動（例：SWELL や他の商用テーマ）
    • SWELL のような高度なテーマを使っている場合は、テーマが追加するカスタムフィールドやメタボックスがリビジョン対象に含まれているか確認します。テーマがリビジョン挙動に影響を与えるケースがあるため、テーマを有効化したまま確認することが重要です。
    • テーマ特有の編集画面（ページビルダーや独自パネル）でリビジョン機能が正しく働くか、復元後の表示崩れがないかまでチェックしてください。

実行例（簡単なテストシナリオ）：

  1. テーマ（SWELL等）を有効化した状態で新規投稿を作成。
  2. 文章＋カスタムフィールド／カスタムブロックを追加して複数回保存。
  3. リビジョン画面で比較し、復元→フロントで見た表示が崩れないか確認。
  4. ページビルダーで作ったページも同様にテストする（ビルダーデータの損失がないか注意）。

4) 対応WordPressバージョンと動作確認方法

  • 確認の基本：プラグインページに表示されている「Tested up to」や最終更新日・バージョンを必ず確認してください。プラグインは WordPress のメジャーアップデートで影響を受けることがあるためです。
  • 検証手順（推奨）：
    1. ステージング環境を本番と同じ WordPress コアのバージョンに合わせる（例：本番が 6.x 系ならステージングも 6.x）。
    2. プラグインの「テスト済み WordPress バージョン」欄と照合し、矛盾があれば注意する（プラグインが古く最後の更新が長い場合は要注意）。
    3. 小規模な機能テスト（投稿の作成・編集・復元・削除）を実施。
    4. プラグイン開発者のサポートフォーラムに同様のエラー報告がないか検索する（互換性問題や既知の不具合の手掛かりになります）。

5) 互換性で問題が見つかったときの対処フロー

  1. 原因切り分け
    • プラグインを一時無効化して問題が消えるか確認（有効化→無効化で変化を見る）。
    • テーマを一時的に WordPress デフォルトテーマ（例：Twenty Twenty-Three等）に切り替えて挙動を確認。
  2. ログを確認（PHP エラーログ、ブラウザコンソール、サーバーログ）。
  3. 開発者フォーラムを検索／報告（既知の問題か、パッチがあるか確認）。
  4. 代替案：もしプラグインが特定の構成で安定しない場合は、他のリビジョン制御プラグインや wp-config.php / functions.php による制御（ただし既存リビジョンは別途処理が必要）を検討する。
  5. 最終的に本番へ反映するか否かを判断（リスクが高ければ別手段で運用する）。

6) 確認チェックリスト（導入後すぐにやること）

  • [ ] ステージングで全テストを実施した。
  • [ ] 投稿タイプ（投稿、固定ページ、カスタム投稿）それぞれで編集→リビジョン保存→復元を確認した。
  • [ ] テーマ（SWELL等）を有効にした状態で表示崩れやデータ欠損がないか確認した。
  • [ ] JSエラー／PHPエラーのログを確認した（無ければOK）。
  • [ ] 主要プラグイン（キャッシュ、バックアップ、ページビルダー等）と併用して問題ないか確認した。
  • [ ] 問題発生時のロールバック方法（バックアップ復元手順）を明確にしておいた。

トラブルシューティング（よくある症状と短い対処）

  • リビジョン数が設定どおり反映されない → プラグイン設定画面（Settings > Writing）で設定が保存されているか／キャッシュが影響していないか確認。
  • 特定のカスタム投稿で動かない → その投稿タイプがリビジョンをサポートしているか、またはテーマ／プラグインが独自にリビジョン処理していないかを確認。既知の報告がある場合はフォーラムを参照。
  • 編集画面でエラーが出る／白画面になる → 該当プラグインを無効化して回避できるか確認。PHP エラーログで詳細を確認。

最後に（初心者向け一言アドバイス）

段階的に進めることが安全です。

まずはステージングで（1）基本機能、（2）テーマとの相性、（3）主要プラグインとの併用テストの順でチェックしてください。

プラグインのページに記載されている「最終更新日」「バージョン」「Tested up to」は必ず確認し、問題が見つかったらすぐに本番反映を止めることをおすすめします。

運用のベストプラクティス

要点： WP Revisions Control は「編集履歴を安全に残しつつ、不要な蓄積を防ぐ」ためのツールです。導入は手段であり、運用ルールと定期的な監視が効果を最大化します。以下は実務で使える短く強力なガイドです。

推奨設定（すぐ使える初期値）

以下は運用開始時の目安です。サイト規模や編集フローに合わせて調整してください。

スクロールできます
サイトタイプ投稿（記事）固定ページ重要なコラム・長期保存記事
個人ブログ / 趣味サイト3〜5件1〜2件5〜10件
中小ビジネスサイト5件2〜3件10件
編集チームあり（大規模）10件3〜5件20件以上（要相談）

ワンポイント： 最初は控えめに設定し、運用で不便を感じたら増やす方針が安全です。

運用ルール案（テンプレート）

短く明文化したルール例（チーム用）：

  • バックアップ：設定変更や大量削除の前に必ず DB とファイルのフルバックアップを取得する。
  • テスト環境：新しい設定はまずステージングで72時間以上試験運用する。
  • 削除権限：一括削除は管理者（または指定の運用担当者）のみが実行する。削除実行は2名以上の承認を推奨。
  • 記録：削除・復元・設定変更は操作ログ（日時／実行者／対象）を残す。
  • 見直し頻度：リビジョン設定は四半期ごとにレビューする。サイト成長や編集頻度に応じて調整する。

運用チェックリスト（日常／週次／四半期）

日常（編集者）

  • 編集開始前に現在のリビジョン数を確認。
  • 重要な変更前は下書きコピーを作成。

週次（管理者）

  • DB サイズと revision 件数の増減を確認。
  • 異常な急増があれば原因を調査（自動保存ループや外部インポートなど）。

四半期（運用評価）

  • 保持数の適切性を評価し、必要なら調整。
  • 既存の古いリビジョンを段階的にクリーンアップするか検討。

よくある失敗とその対策

  • 失敗：導入だけして既存リビジョンを放置
    → 対策：導入後の最初のメンテで一括削除計画（小分け実行）を実施する。
  • 失敗：保持数を低くしすぎて復元が困難に
    → 対策：重要記事は個別に上限を緩めるルールを作る。
  • 失敗：一括削除でサイトに負荷がかかる
    → 対策：削除はアクセス低下時に小分けで実行、またはホスティングに相談する。

監視すべき指標（運用効果を測る）

  • revision 件数の推移（週次）
  • データベースサイズ（総量・増加率）
  • バックアップ時間（差が出ていないか）
  • 編集／復元の成功率（問題発生件数）

即効で使える簡単なルール文

リビジョン運用ポリシー

  1. 設定変更・一括削除前は必ずバックアップを実行する。
  2. 重大な削除は管理者のみ、実行前に承認を得る。
  3. 重要ページは個別にリビジョン上限を緩和する。
  4. 設定は四半期ごとに見直す。

最後に：導入の優先度と次の一手

  • 優先度：高 — サイトが中〜大規模、または編集頻度が高い場合は早めに導入・ルール化を。
  • 次の一手（提案）：あなたのサイト規模（投稿数／編集頻度／チーム人数）を教えていただければ、具体的な初期設定値・運用スクリプト・承認フローのテンプレートをカスタムで作成します。どれがよいですか？ ✅

まとめ

結論：WP Revisions Control は「編集の安全性」と「データベースの健全性」を両立させる実用的なツールです。
正しく導入・運用すれば、復元ニーズに応えつつ不要な履歴の蓄積を抑えられます。

ただし、導入だけでは既存リビジョンは消えないため、導入前後の作業計画が重要です。

実務で押さえるべき要点

  • 必ずバックアップを取る（DB とファイル）。
  • ステージング環境で先に動作確認を行う。
  • 最初は控えめな上限値（例：投稿3〜5件、固定ページ1〜2件）からスタート。
  • 既存の大量リビジョンは小分けで安全に削除（プラグイン / WP-CLI / SQL を使い分け）。
  • チーム運用では「誰が削除できるか／承認フロー」を明確にする。
  • 導入後はDBサイズ・編集ワークフロー・復元テストを数週間監視する。

クイックチェックリスト（コピーして使える）

  • [ ] フルバックアップを取得した
  • [ ] ステージングで動作確認を行った
  • [ ] デフォルト上限を設定してテスト投稿で確認した
  • [ ] 既存リビジョンの削除計画を立てた（必要なら小分けで実施）
  • [ ] チーム運用ルールを文書化した
WordPress プラグイン

関連記事

目次