WordPressのリビジョン完全ガイド！復元・削除・最適化、プラグインなど徹底解説！

2025年9月21日

「記事を編集していたら大事な段落を消してしまった……戻せますか？」
「リビジョンがどんどん増えてデータベースが重くなっている気がする。どうすればいい？」
「リビジョンの表示が出ない／復元ボタンが見当たらないんだけど原因は？」
「プラグインで一括削除しても安全？初心者でもできる方法はある？」

もしあなたが上のどれかに当てはまるなら、本記事はまさに役立ちます。

この記事では、初心者でも迷わず使えるように、「復元」「削除」「最適化」「運用ルール」「おすすめプラグイン」を一つずつ丁寧に解説します。

読むと得られること：

誤編集を安全に復元する手順（Gutenberg／クラシック別）
不要なリビジョンを安全に削除してDBを軽くする方法（プラグイン／WP-CLI／SQL）
運用で失敗しないための設定とチェックリスト（推奨値つき）
実務で使えるトラブル対処フローと初心者向けの安全なワークフロー

まずは落ち着いて、復元の基本操作と「やる前に必ずすること」から読み進めましょう。🔍

変更履歴の基礎知識

変更履歴とは何か（投稿の保存履歴の概要）

変更履歴（リビジョン）は、投稿や固定ページの「過去の編集状態」を自動で保存しておく仕組みです。

編集ミスを元に戻したり、差分を確認してどの編集で何が変わったか把握したりするのに役立ちます。

ポイント

誰がいつ何を編集したかを遡れる：本文だけでなく、タイトルや抜粋、ブロックの構造など編集に関する情報が履歴として残ります。
UIで比較・復元できる：管理画面の編集画面から過去の版と現在版を比較し、必要な版を復元できます。
自動で作成されるので、基本的にはユーザーが意識しなくても履歴が溜まっていきます。

初心者向け例

「誤って重要な段落を消してしまった」 → リビジョンから該当時点を選んで復元できます。
「どの編集で構成を変えたか知りたい」 → 差分（差し替えられたテキストの部分）が見られます。 ✅

保存されるタイミングと対象データ（公開・更新・自動保存など）

変更履歴が作られる代表的なタイミングと、どんなデータが保存されるかを整理します。

主な保存タイミング

「下書きを保存」 を押したとき
「更新（Update）」／「公開（Publish）」 を押したとき
自動保存（Autosave） が走ったとき（※自動保存の扱いは次節で解説）
ブロック単位での編集が大きく変わった場合（ブロックエディターでは内部的に細かく扱われる）

保存される主な項目

本文（post_content）：本文やブロック構造そのもの
タイトル（post_title）、抜粋（post_excerpt）
公開状態（公開／下書き）やステータスの変更（一部のメタ情報）
（テーマ/プラグインで保存される場合）カスタムフィールドやブロック属性

簡潔な表（タイミング × 性質）

スクロールできます

保存タイミング	代表的な性質	管理画面での見え方
下書き保存・更新・公開を押したとき	永続的にリビジョンとして残る可能性が高い	「リビジョン一覧」に表示される
自動保存（短間隔）	一時的・頻繁に作成される（自動保存専用扱い）	通常は専用表示か一部UIのみ表示
プラグイン等の外部バックアップ	サイト外の完全コピー（ファイル・DB）	管理画面外（バックアップツールで確認）

補足（運用）

サイトの規模によってはリビジョンが大量に溜まり、データベース容量や表示速度に影響することがあります。運用方針に合わせて保存数を制限することが多いです。

自動保存との違いと補足（スナップショットやバックアップとの比較）

リビジョン（変更履歴）、自動保存（Autosave）、サイトバックアップ は目的や扱いが異なります。混同しないことが重要です。

主な違い

目的
- リビジョン：編集の履歴を記録して、任意の過去版に戻せるようにすること。
- 自動保存：編集中の作業を失わないための短期的な保険（ブラウザクラッシュや接続切断対策）。
- バックアップ：サイト全体（ファイル＋DB）の復旧を目的とした外部保存（障害対策）。
保存の永続性
- リビジョン：通常は永続的（ただし上限設定で古いものが削除されることあり）。
- 自動保存：短期間で上書きされることが多く、常に1つあるいは少数の「編集中の一時保存」が保持される実装。
- バックアップ：明示的に保存され、長期保管される（スケジュールや手動で保管）。
復元の粒度
- リビジョン：記事単位で差分比較・復元が可能（編集単位で細かく戻せる）。
- 自動保存：編集中の状態を戻すのに便利だが、履歴の一覧性や差分比較は限定的。
- バックアップ：サイト全体をある時点に戻す（記事単位での細かい差分よりも大域的な復旧向き）。

比較表

スクロールできます

項目	リビジョン	自動保存	サイトバックアップ
目的	編集履歴の保持と復元	編集中の一時保護	障害からの全体復旧
継続性	長期（ポリシー次第）	短期・上書きされやすい	長期保存可
復元方法	管理画面で差分比較・復元	編集画面の一時復元	バックアップツールで復元
対象	記事・ページ単位	編集中の投稿	サイト全体（ファイル＋DB）

実践的な注意点

✨ リビジョンは「編集の履歴」。重要な変更があるときは、リビジョンで差分をチェックしてから復元すると安全です。
💾 自動保存は“作業中の保険”。長期保存を期待せず、こまめに下書きを確定すると安心です。
🔁 バックアップとは役割が全く違うので、リビジョンだけに頼らず定期的なサイト全体バックアップを運用してください。

設定例（実務メモ）
wp-config.php でリビジョンや自動保存の動作を調整できます（例）：

// リビジョンの保持数を制限（例：5世代を保持）
define( 'WP_POST_REVISIONS', 5 );

// 自動保存の間隔（秒）を変更（例：300秒＝5分）
define( 'AUTOSAVE_INTERVAL', 300 );

⚠️ wp-config.php の編集はサイトに直接影響するため、編集前にバックアップを取り、テキストエディタで慎重に作業してください。

まとめ（簡潔チェックリスト）

変更履歴は「編集の履歴」を保存する機能：差分確認と復元が可能。
保存タイミングは下書き保存・更新・公開・自動保存など。保存対象は本文・タイトル・ブロック構造など。
自動保存と混同しない：自動保存は一時保護、バックアップはサイト全体復旧用。
運用のコツ：必要に応じて保持数や自動保存間隔を調整し、定期バックアップを併用すること。

変更履歴の保存場所と種類

データベースに格納される仕組み

ポイント：WordPress のリビジョンはサイトのデータベース内に「投稿」として保存されます。

具体的には、wp_posts（プレフィックスは環境によって異なる）テーブルの中で post_type = 'revision' として格納され、元の投稿とは post_parent（親投稿ID）で関連付けられます。

この仕組みにより、各リビジョンは「投稿の別レコード」として扱われ、編集者や編集日時などの管理情報も持てます。

補足

編集日時は post_modified / post_modified_gmt に記録されます。
作成者情報（誰が編集したか）は post_author に入ることが多いです。
一部の情報（例：編集に関する追加のメタデータ）は wp_postmeta に格納される場合があります。
プラグインによっては、リビジョンを別テーブルや外部ストレージに保存する（スナップショット方式）こともあります。

実際に確認する簡単なSQL例

-- 投稿ID = 123 のリビジョン一覧を新しい順に取得
SELECT ID, post_author, post_modified, post_title
FROM wp_posts
WHERE post_type = 'revision' AND post_parent = 123
ORDER BY post_modified DESC;

リビジョンに含まれる情報（本文、メタ、ブロック情報など）

リビジョンに保存される主な要素は次の通りです：

スクロールできます

項目	説明
本文（post_content）	記事本文やブロックデータ。ブロックエディターの場合はブロック構造（HTMLコメント＋ブロックマークアップ）ごと保存される。
タイトル（post_title）	投稿タイトルの当時の状態
抜粋（post_excerpt）	抜粋や要約（使用しているテーマ/プラグイン次第で重要）
ステータス・公開状態	公開/下書きなどの状態変化情報の一部
編集者情報（post_author）	編集を行ったユーザーID
カスタムフィールド（場合による）	必要に応じて `wp_postmeta` に関連データが保存されることがある

ブロックエディター（Gutenberg）の扱い

Gutenberg ではブロック構造そのものが post_content に保存されます。そのため、ブロック属性や内部の構造もリビジョンで復元可能です。

注意点

添付ファイル（メディアファイル本体）はリビジョンに含まれません。リビジョンは「投稿の状態」を保存する仕組みであり、サーバ上のファイル自体は別管理です。
一部のプラグインがカスタムデータ（例：複雑なブロック属性や外部キャッシュ）を別テーブルに保存することがあり、その場合はリビジョンだけでは完全な復元にならないことがあります。重要データはバックアップで補完することが大切です。

カスタム投稿やページでの扱い

基本原則：カスタム投稿タイプでも「revisions」サポートが有効なら同じ仕組みで保存されます。

カスタム投稿タイプを登録する際に supports で revisions を含めると、その投稿タイプの編集履歴が wp_posts の post_type = 'revision' として保存されます。

  // 例：カスタム投稿タイプ 'book' でリビジョンを有効にする
  register_post_type( 'book', array(
    'label' => 'ブック',
    'supports' => array( 'title', 'editor', 'revisions' ),
    // ... 他の設定
  ) );

既存のカスタム投稿タイプに後からリビジョン機能を追加する場合は add_post_type_support() を使えます。逆に無効化するには remove_post_type_support() を利用します。

  // 有効化
  add_post_type_support( 'book', 'revisions' );

  // 無効化
  remove_post_type_support( 'book', 'revisions' );

表示されない／保存されないケース

カスタム投稿がリビジョンをサポートしていないと、編集画面にリビジョンが出ず、履歴も残りません。
テーマやプラグインが remove_post_type_support() を使っている場合も同様です。
一部の軽量化プラグインやカスタム実装は「リビジョンを抑制」していることがあるため、運用前に確認が必要です。

参照用の関数（WordPress側）

プログラムからリビジョンを取得するには wp_get_post_revisions( $post_id ) を使います。

  $revisions = wp_get_post_revisions( 123 ); // 投稿ID 123 のリビジョン一覧が配列で返る

投稿タイプがリビジョンをサポートしているかを確認するには post_type_supports( 'book', 'revisions' ) が便利です。

要点まとめ（初心者向けチェック）

リビジョンはデータベース内（主に wp_posts）に保存され、元投稿とは post_parent で紐付く。
本文やタイトル、抜粋、ブロック構造などがリビジョンとして復元可能。ただしメディア本体や一部プラグインデータは含まれない。
カスタム投稿でも revisions をサポートしていれば同じ仕組みで保存される。サポートを追加／削除するコード例は上記の通り。

変更履歴の確認・アクセス方法

管理画面（編集画面）での確認手順

編集画面からリビジョンへアクセスする基本的な手順を、Gutenberg（ブロックエディター）とクラシックエディターで分けてわかりやすく説明します。

Gutenberg（ブロックエディター）の場合

投稿・固定ページの編集画面を開く。
右上サイドバーの「ドキュメント（Document）」パネルを表示する（開いていない場合は右上の歯車アイコンをクリック）。
「Revisions（リビジョン）: ○件」という表示を探す。件数のリンクをクリックするとリビジョンの比較画面に移動します。
比較画面で差分を確認し、必要ならその版を復元します。

クラシックエディターの場合

投稿・固定ページの編集画面を開く。
右側の「公開（Publish）」ボックス内（または投稿メタボックス）に「リビジョン：○件」と表示されていることが多い。これをクリックするとリビジョン画面に移ります。
リビジョン一覧から確認・復元を行います。

補足（管理画面を素早く開く）

管理画面の「投稿一覧」→ 対象投稿を編集から上記の手順を行います。
編集権限がないユーザーはリビジョンを見られないことがあります（権限の確認が必要）。

比較ビューの使い方（差分の見方）

リビジョン比較画面では、古い版と新しい版の差分を視覚的に確認できます。主な操作と見方は次の通りです。

左右のスライダー／ナビゲーション
- 画面の左右で古い版（左）と新しい版（右）を切り替えられます。中央のスライダーや「前へ／次へ」ボタンで時系列を移動します。
差分の強調表示
- 追加された部分 と 削除された部分 が視覚的に区別されます（色や装飾でわかりやすく表示される）。文章のどこが変わったかを一目で把握できます。
全体プレビューとブロック単位の表示（Gutenberg）
- ブロックエディターではブロック単位の差分を確認できるため、どのブロックが変わったかがわかりやすいです。
復元ボタンの使い方
- 比較して「この版を復元（Restore This Revision）」というボタンを押すと、その時点の状態が編集画面に戻ります（全体復元）。
- 一部だけ戻したい場合は、復元後に不要な箇所を手で編集するか、差分をコピーして現在の編集に貼り付けると安全です。✂️📋

ワンポイント：復元は基本的に「その版の状態をまるごと上書き」するので、復元前に現在の内容をコピーしてバックアップしておくと安心です。

編集画面でリビジョンが見当たらないときに確認する項目

編集画面に「リビジョン」が表示されない場合、原因は複数考えられます。次のチェックリストで順に確認してください。

チェックリスト（順に確認）

そもそもリビジョンが作成されているか
- まだ一度も保存・更新していない投稿はリビジョンが存在しません。まずは「下書き保存」してから確認します。
投稿タイプ（カスタム投稿）のリビジョンサポート
- カスタム投稿タイプでリビジョンをサポートしていない場合、履歴が残りません。post_type_supports() や register_post_type の supports を確認します。
- 必要なら add_post_type_support( 'your_post_type', 'revisions' ); を利用して有効化します。
wp-config.php の設定
- WP_POST_REVISIONS が false または 0 に設定されているとリビジョンが無効化されます。wp-config.php を確認してください。

   // リビジョン無効化の例（これがあると作成されない）
   define( 'WP_POST_REVISIONS', false );

プラグインやテーマによる抑制
- 一部のキャッシュ／最適化プラグインやテーマがリビジョンを抑制している場合があります。プラグインを一時停止、またはテーマを標準（Twenty Twentyなど）に切り替えて確認してみましょう。
ユーザー権限の確認
- 編集権限の低いユーザーではリビジョン情報が見えないことがあります。管理者でログインして確認してください。
データベースで直接確認する
- 実際にリビジョンが存在するかはデータベースで確認できます（安全な環境で実行してください）。

   SELECT ID, post_author, post_modified, post_title
   FROM wp_posts
   WHERE post_type = 'revision' AND post_parent = 123
   ORDER BY post_modified DESC;

上記で結果が返らない場合、該当投稿にリビジョンが存在していないことが確定します。

管理画面のキャッシュ／クライアント側の問題
- ブラウザのキャッシュやJavaScriptのエラーで表示されない場合があります。ブラウザを再読み込み、キャッシュクリア、別ブラウザでの確認を試してください。
ログやエラーの確認
- サーバーやWPのエラーログに関連エラーが出ていないか確認します。特にカスタムコードやフィルタを導入している場合はそちらが原因になっていることがあります。

まとめ（即実行できるチェックと操作）

まずは編集画面の「Revisions」リンクを探す（Gutenbergはドキュメントパネル、クラシックは公開ボックス）。🔍
差分画面では左右スライダーで時系列を移動し、差分を確認してから復元を実行する。復元は全体上書きなので必要なら事前に現在内容を退避。💾
表示されないときは：保存履歴の有無 → 投稿タイプのサポート設定 → wp-config.php → プラグイン／テーマ干渉 → DBで直接確認、の順で調査する。🧭

実践：変更履歴を使って復元する流れ

以下では、Gutenberg（ブロックエディター）／クラシックエディターそれぞれの操作を初心者向けに段階的に説明します。

実際に復元する前に現在の内容をコピーしておくなどの安全対策も忘れずに。

リビジョン画面の開き方（ステップ1〜3）

Gutenberg（ブロックエディター）

投稿・固定ページの編集画面を開く。
右上の歯車アイコンをクリックして ドキュメント（Document） パネルを開く。
「Revisions：○件」と表示されている箇所をクリックすると、リビジョン比較画面に移動する。
- 件数が見えない場合は「公開」パネルや画面上部のオプションを確認する。

クラシックエディター

投稿・固定ページの編集画面を開く。
右側の「公開（Publish）」ボックス内にある「リビジョン：○件」のリンクをクリックする。
リビジョン一覧または比較画面に遷移する（テーマ／プラグインで表示位置が異なることがある）。

一言アドバイス

まずは編集画面で「リビジョン」の表示場所を確認して、どのくらい履歴が溜まっているかを把握しましょう。🔍

元に戻したい版を選んで復旧する手順

以下は差分を確認してから復元する安全な手順です。作業は落ち着いて。

差分を確認する（比較ビュー）
- 左右（またはタイムライン）で古い版と新しい版を切り替え、追加・削除された箇所を確認します。
- ブロックエディターではブロック単位で何が変わったか見やすいです。
- ヒント：重要な箇所はコピーして別ファイルに退避しておくと安心です。📋
復元（Restore）を実行
- 比較画面にある「このリビジョンを復元」や「復元」ボタンを押すと、その版の内容が編集画面に戻ります。
- 復元はその時点の状態を上書きする操作です（＝現在の内容は上書きされます）。
- 復元後は必ず編集画面で内容を確認し、必要に応じて修正してから保存／公開してください。✅
下書きとして保存 or 公開
- 復元直後は下書き状態でよい場合が多いので、内容確認後に「更新（Update）／公開（Publish）」を実行します。
復元が正常に行われたか確認
- サイト上で表示を確認し、レイアウトやメディアの挙動に問題がないかチェックします。
- 問題があれば、必要箇所を手動で修正するか再度別のリビジョンを選んで復元します。

操作フロー（簡易表）

スクロールできます

手順	操作
1	編集画面 → リビジョンを開く
2	差分を確認（コピー退避）
3	「このリビジョンを復元」実行
4	編集画面で確認 → 下書き保存または公開

復元をやり直す／取り消す方法

復元を実行した後で「やっぱり元に戻したい」と思った場合の対処法を整理します。

A. 別のリビジョンを選んで再度復元する（もっとも確実）

リビジョンは履歴として残るため、復元操作自体も新たなリビジョンとして保存されることが多いです。
つまり、再度リビジョン画面を開き、元に戻したい別の版（復元前の版など）を選んで復元すれば差し戻し可能です。🔁

B. エディター内の「取り消し（Undo）」を使う

ブロックエディターやエディターのテキスト操作では Ctrl+Z / ⌘+Z（取り消し） が使える場合があります。
ただし、復元後にページを保存してしまうとUndoで戻せないことがあるため注意してください。⛔

C. 現在の（復元後の）内容を手動で再編集して修正する

復元後に不要な部分のみを手直ししてから保存する方法です。部分的に元に戻したいときは最も簡単。✂️✍️

D. バックアップから全体復旧する（最終手段）

リビジョンでは解決できない重大な問題が発生した場合、サイト全体のバックアップから復元することを検討します。
重要：バックアップ復旧はサイト全体に影響が出るため、実行前に現在のデータをダンプして保管しておくこと。

比較表：取り消し方法の使い分け

スクロールできます

状況	推奨アクション	備考
単純なミスをすぐ気づいた	エディターのUndo（Ctrl+Z）	保存前なら有効
元に戻したい以前の別版がある	別のリビジョンを再度復元	最も安全・確実
部分的に差分だけ戻したい	手動で編集（コピー→貼り付け）	細かい調整向き
サイト全体がおかしい／DB破損	バックアップから復元	最終手段。事前に現状バックアップを推奨

安全対策と実践的なTIP（復元前に必ずやること）

現在の内容をコピーして保存（テキストファイルやローカルドキュメントに）しておく。📁
復元はまず下書きで試す：いきなり公開せず、表示確認後に公開する。🔎
権限のある管理者ユーザーで操作する：権限不足だと正しく操作できないことがあります。🔐
重大作業前はサイト全体のバックアップを取得（特にDBのダンプ）。💾
復元後も必ず動作確認：画像・ショートコード・外部プラグイン連携などを確認する。🧪

まとめ（ワンポイント）

リビジョン復元は強力だが上書きリスクがあるため、必ず「現在の内容の退避 → 差分確認 → 下書きで試す」の順で作業すること。
復元の取り消しは別のリビジョンを再復元するのがもっとも安全。編集のUndoは保存のタイミングで効かなくなるので注意してください。

編集ツール別の操作（エディターごとの違い）

編集画面によってリビジョンの見え方・操作性が変わるため、使っているエディターに応じたポイントを押さえておきましょう。

ここでは Gutenberg（ブロックエディター） と クラシックエディター に分けて、実際の操作上の違いや便利なワザを初心者向けに丁寧に解説します。

ブロックエディター（Gutenberg）での操作ポイント

概要
Gutenberg（ブロックエディター）は「ブロック単位」でコンテンツを扱うため、どのブロックが変更されたかがわかりやすい差分表示になります。リビジョン画面もブロックの構造を反映してくれるので、視覚的に復元判断がしやすいのが特徴です。

具体的な操作手順（素早く確認する流れ）

編集画面を開く → 右上の歯車（設定）を開く → Document（ドキュメント）パネルにある「Revisions: ○件」をクリック。
リビジョン比較画面に入り、タイムラインやスライダーで時点を移動。
ブロックごとの差分を確認し、必要なら「このリビジョンを復元」を実行。

Gutenberg特有の利点

ブロック単位で差分がわかるので、どの段落・見出し・カラムが変わったか一目で把握できる。
ブロックの属性（例：カスタムクラスや内部設定）も post_content に含まれるため、見た目・構造ともに復元しやすい。
エディターの Undo/Redo と併用すると短時間の取り消しが手早く行える。

よく使うワザ／注意点

部分復元のワザ：Gutenberg のリビジョン画面は「その版をまるごと復元」するUIですが、差分を見て復元したいブロックの内容だけをコピー→現在のエディターへ貼り付けすると、部分的な戻しが可能です。📝
自動保存との関係：編集中の自動保存（autosave）がリビジョン一覧に混ざるケースがあるため、日時をよく確認してから復元しましょう。
大きなブロック構造の変更に注意：複雑なブロック（ネストされたカラムや高機能ブロック）は復元後に微調整が必要なことがあります。復元後は必ずプレビューで表示確認を。🔍

短い比較表（Gutenberg）

スクロールできます

項目	ポイント
差分の見え方	ブロック単位でわかりやすい
部分復元	コピー＆貼り付けで部分的に戻せる
画像・メディア	メディア本体は別管理。復元後にリンク切れ確認を
操作の安全性	復元は上書きなので下書きで試すのが安全

クラシックエディターでの操作ポイント

概要
クラシックエディター（TinyMCE 等）は一昔前の「テキストベース」エディターです。差分は基本的に本文全体のテキスト差分として表示されることが多く、ブロック単位での視覚的把握はできません。しかしその分インターフェースがシンプルで、テキスト主体の編集では扱いやすい場合があります。

具体的な操作手順（素早く確認する流れ）

投稿編集画面を開く → 右の「公開（Publish）」ボックス内の「リビジョン：○件」をクリック。
リビジョン比較画面で古い版と新しい版の差分を確認する。
「このリビジョンを復元」を押して編集画面に戻す（必要なら下書きで確認）。

クラシックならではのポイント

テキスト差分が直感的にわかるため、文章中心の記事で差分だけ見たい場合に扱いやすい。
HTML（テキスト）モードで編集していると、リビジョンで保存されるのはそのときのHTML全体になるため、意図しないタグの差異に注意。
TinyMCEのUndoは段階的に戻せますが、投稿を保存してしまうとUndoでは戻せないため要注意。

よく使うワザ／注意点

差分のコピーで部分戻し：クラシックでも、リビジョン画面から必要なテキストをコピーして現在のエディターに貼ることで部分的に戻せます。✂️
ショートコードやHTMLの扱い：ショートコードや手書きHTMLが含まれる投稿では、復元後に表示崩れが起こることがあるため、必ずプレビューで表示チェックしてください。
ビジュアルモードとテキストモードのズレ：ビジュアル（WYSIWYG）とテキスト（HTML）で同じ見た目でも内部表現が異なることがあるため、復元後は両モードで確認するのが安全です。🔁

短い比較表（クラシック）

スクロールできます

項目	ポイント
差分の見え方	テキスト全体の差分が中心
部分復元	コピー＆貼り付けで対応（手作業）
HTML扱い	タグ差異に注意（テキストモードで確認）
操作の安全性	復元は上書き。保存前にバックアップ推奨

共通の実践アドバイス（どちらのエディターでも使える）

復元はまず下書きで試す：公開前に表示確認できるので安心です。✅
重要な編集前はコピー保存：長い記事は編集前にローカルへテキストを控えておくと安全。💾
差分の日時を必ず確認：autosave と正式リビジョンを間違えると意図しない版を復元することがあります。🕒
画像や外部データは別途確認：リビジョンは投稿内の参照情報を戻すが、メディア本体は別管理。復元後に画像が存在するかをチェック。🖼️

まとめ（すぐ実践できるチェックリスト）

自分が使っているエディターを確認する（Gutenberg / Classic）。
リビジョンを開く → 差分を確認 → 必要ならコピー退避 → 下書きで復元を試す。
復元後はプレビューで最終確認し、表示やショートコード・画像の挙動をチェックする。

表示されない・動作がおかしいときのトラブル対策

リビジョンが編集画面に表示されない、比較・復元が期待通りに動かない──そんなときに順を追って原因を切り分け、安全に復旧する方法を初心者向けにまとめます。

まずは「影響範囲を最小にする」ことを心がけ、作業前に必ずバックアップを取ってください。💾

リビジョン機能が無効化されているケースの確認

現象例：編集画面に「Revisions」が表示されない／リビジョンがデータベースに存在しない。

確認手順

下書き保存を試す — 一度「下書き保存」または「更新」を実行して、リビジョンが作成されるか確認。
wp-config.php の設定を確認
- WP_POST_REVISIONS が false もしくは 0 に設定されているとリビジョンは無効化されます。
- 有効にするには（例：5世代保持）：
// wp-config.php に追加（編集はバックアップ後に） define( 'WP_POST_REVISIONS', 5 );
- 無効化されている例（要注意）：
define( 'WP_POST_REVISIONS', false ); // これだと作成されない
DB を直接確認（安全な環境で）
- 投稿ID = 123 のリビジョンがあるか確認するSQL例：
SELECT ID, post_date, post_author FROM wp_posts WHERE post_type = 'revision' AND post_parent = 123 ORDER BY post_date DESC;
- 結果が空ならリビジョンが作成されていません。

対処

WP_POST_REVISIONS を削除するか正しい値（true または数値）にして、再度編集→保存を行って確認。
変更の前に必ず wp-config.php のバックアップを取り、FTP/ホスティングのファイルマネージャで編集してください。

プラグインやテーマによる干渉をチェックする手順

現象例：ある環境だけリビジョンが表示されない、特定の投稿タイプだけ見えない、管理画面が崩れるなど。

チェック手順（安全な順）

ブラウザ側の簡易チェック
- キャッシュクリア、別ブラウザ、シークレットモードで確認。
- 開発者ツール（F12）でコンソールに JavaScript エラーが出ていないか確認。🕵️‍♀️
プラグインを疑う（段階的に無効化）
- すべてのプラグインを一時的に無効化 → リビジョンが出るか確認。
- 出ればプラグインが原因なので、一つずつ有効化して再現を特定する。
- 特に「最適化」「DBクリーナー」「キャッシュ」「エディター拡張系」プラグインが怪しいことが多いです。🧰
テーマの影響を確認
- 一時的にデフォルトテーマ（例：Twenty Twenty）に切り替えて確認。テーマが原因なら functions.php やカスタムコードに remove_post_type_support() 等があるかチェック。
ログを確認
- サーバーの PHP エラーログや WordPress のデバッグログを確認（後述の WP_DEBUG を参照）。
ステージングで再現テスト
- 可能ならステージング環境で同じテーマ／プラグイン構成を再現して試験的に切り分ける（本番を触らず安全に確認可能）。

対処例

問題のプラグインを無効化したまま、代替プラグインに切り替える。
テーマ内のカスタムコードを見直し、影響する記述があればコメントアウトして動作確認。
問題のあるプラグインの作者に報告する（開発者向けに再現手順を添えると対応が早い）。

remove_post_type_supportやwp-configの記述を確認する

現象例：特定の投稿タイプでリビジョンが保存されない、編集画面に履歴リンクが出ない。

確認ポイント

投稿タイプがリビジョンをサポートしているか
- テーマやプラグインが remove_post_type_support() を使っていると、リビジョンサポートが外されます。
- 確認（PHPコード内をチェック）：remove_post_type_support( 'post', 'revisions' );
プログラム的にリビジョンを有効にする方法
- 後から有効化するには：
// functions.php などに追加（編集はバックアップを） add_action( 'init', function() { add_post_type_support( 'your_post_type', 'revisions' ); } );
- 既定の投稿タイプ（’post’ / ‘page’）は通常有効ですが、カスタム投稿は登録時の supports に依存します。
wp-config.php の関連定義
- WP_POST_REVISIONS の確認（上記参照）。
- 自動保存間隔や他のフラグも影響することがあるため、wp-config.php 内の編集系定義を確認：
define( 'WP_POST_REVISIONS', 5 ); define( 'AUTOSAVE_INTERVAL', 300 );
- もし AUTOSAVE_INTERVAL が極端に長く設定されていると、期待する自動保存（とそれに紐づくリビジョン）が作られにくくなることがあります。
コード例：サポート有無をチェックする関数

   if ( post_type_supports( 'book', 'revisions' ) ) {
     // revisions をサポートしている
   } else {
     // サポートしていない
   }

安全に修正する手順

テーマ／プラグインの functions.php やカスタムプラグインの中で remove_post_type_support() を検索。
見つかったら一時的にコメントアウトして（または子テーマで上書きして）リビジョン表示を確認。
必要なら add_post_type_support() を追加してサポートを復活させる。
変更後は迅速に動作確認し、問題がなければ変更を反映。問題があれば元に戻す。

追加の診断コマンドと安全確認（上級向け・実行前にバックアップ推奨）

WP-CLI でリビジョンを確認（投稿IDがわかっている場合）：

  wp post list --post_type=revision --post_parent=123 --format=table

デバッグログを有効にする（wp-config.php）：

  define( 'WP_DEBUG', true );
  define( 'WP_DEBUG_LOG', true ); // wp-content/debug.log に出力
  define( 'WP_DEBUG_DISPLAY', false ); // 表示しない（本番では推奨）

データベースの整合性チェック：リビジョンの post_parent が正しく設定されているか確認。post_parent が誤っていると関連付けされず表示されない可能性があります。

トラブルシュートの簡易チェックリスト（コピーして使える）

スクロールできます

手順	操作	期待結果
1	編集画面で下書き保存	リビジョン件数が増える／表示される
2	wp-config.php の `WP_POST_REVISIONS` を確認	`false` なら有効化して再確認
3	ブラウザのキャッシュ・別ブラウザで確認	表示が復活するか確認
4	全プラグイン無効化 → 逐次有効化	問題のあるプラグインを特定
5	テーマをデフォルトに切替	テーマ由来の問題か判定
6	functions.php に `remove_post_type_support` がないか検索	あればコメントアウトして再試行
7	DBで `wp_posts` の `post_type='revision'` を確認	リビジョンがDBに存在するか確認
8	WP_DEBUG を有効にしてログ確認	エラーメッセージを手がかりに修正

最後に（注意点）

本番環境を直接いじる前に、必ずバックアップ（ファイル＋DB）を取ってください。
初心者は「プラグイン無効化→再現確認」をまず試すのが安全で効果的です。
もし上記の手順で解決しない場合は、実際のログやエラーの出力を元にさらに切り分けする必要があります。ログや再現手順があれば、より具体的な原因特定と修正案を提示できます。

管理：保存数の制限と無効化（設定による制御）

リビジョンの保存数や自動保存の挙動は、サイトの規模や運用方針に合わせて調整するのが重要です。

ここでは「コードで設定する方法」「プラグインで手軽に制御する方法」「自動保存間隔の変更」の3つを、初心者でもわかるように具体例付きで丁寧に解説します。

どの方法でも編集前に必ずバックアップ（ファイル＋DB）を取ることを忘れないでください。💾

wp-config.phpで制御する方法（コードで保存数を設定／無効化する）

概要
wp-config.php に定数を追加することで、WordPress のリビジョン動作をサーバー側で直接制御できます。軽量・確実に動く反面、ファイル編集が必要なので慎重に行ってください。

代表的な設定例

// リビジョンを 5 世代だけ残す（数値で上限を設定）
define( 'WP_POST_REVISIONS', 5 );

// リビジョンを完全に無効化する（注意：復元機能が使えなくなる）
define( 'WP_POST_REVISIONS', false );

// 自動保存の間隔を 5 分（300秒）に設定（デフォルトは 60秒）
define( 'AUTOSAVE_INTERVAL', 300 );

使い分けの目安

小〜中規模サイト：WP_POST_REVISIONS=5 のように上限を設けると、履歴は残りつつDB肥大を抑えられます。✅
巨大メディアサイトやDBコストを強く抑えたい場合：false で無効化する手もありますが、編集ミスの復元ができなくなるリスクがあります。⚠️

特定投稿タイプだけ制御したい場合（functions.php）

// 投稿タイプごとに保持数を変える例（functions.php）
add_filter( 'wp_revisions_to_keep', function( $num, $post ) {
    if ( 'post' === $post->post_type ) {
        return 5; // 投稿は5世代
    }
    if ( 'page' === $post->post_type ) {
        return 0; // 固定ページはリビジョンを残さない
    }
    return $num; // その他はデフォルト
}, 10, 2 );

注意点（安全対策）

wp-config.php を編集する前にFTP・ホスティングのファイルマネージャでバックアップを保存。
サイトがキャッシュされている場合は、変更後にキャッシュクリアして動作確認。🔁

プラグインを使って上限を設ける方法（代表的な管理プラグインの使い方）

概要
コード編集に抵抗がある場合、プラグインでGUIから簡単に設定できます。インストール→設定画面で数値を指定するだけ、という手軽さが魅力です。以下はよく使われる機能と使い方の例（一般的な手順として説明します）。

よくあるプラグインの機能

リビジョンの保持数をサイト全体または投稿タイプごとに設定
既存の不要なリビジョンを一括削除（クリーンアップ）
自動保存の無効化や間隔変更のUIサポート

導入手順（典型的）

管理画面 → プラグイン → 新規追加でプラグイン名を検索してインストール・有効化。
有効化後、設定画面（プラグイン固有のメニューまたは「設定」以下）に移動。
「保持するリビジョン数」や「投稿タイプ別設定」などを入力して保存。
必要なら「既存リビジョンの一括削除」機能でDBをクリーンアップ。🧹

注意点

プラグインにも品質差があるため、導入後はサイトの動作（管理画面・公開側）を確認してください。
一括削除機能を使う前に必ずDBバックアップを取ること（削除は元に戻せない）。❗

補足（操作上のTIP）

プラグインで設定しても、wp-config.php で強制的に上書きされている場合は優先度の関係でプラグイン設定が効かないことがあります。設定が反映されないときは wp-config.php を確認しましょう。

自動保存の間隔を変更する方法（コード／プラグイン）

概要
自動保存（autosave）は編集中の作業を守る重要な仕組みですが、頻繁すぎると短期的なリビジョンが多発してしまいます。間隔を延ばす／短くすることで、リビジョン生成の頻度を調整できます。

コードで変更する（wp-config.php）

// 自動保存の間隔を 5 分（300秒）に設定
define( 'AUTOSAVE_INTERVAL', 300 );

プラグインで変更する

プラグインによっては自動保存間隔をGUIで設定できます。導入手順は前節のプラグイン導入と同様です。
プラグインによる設定は、テーマや他のプラグインの影響で意図どおり反映されない場合があるため、設定後の挙動確認を必ず行ってください。🔍

間隔の設定目安

短い（30〜60秒）：頻繁に保存したい場合（複数人で同時編集する環境など）
中間（300秒＝5分）：一般的なブログ運用でのバランス設定 ✅
長め（600秒以上）：リビジョンが大量に増えるのを強く抑えたいとき。ただし作業中の消失リスクが上がる

補足：自動保存とリビジョンの関係

自動保存は「編集中の保険」であり、通常は短時間で上書きされますが、設定やプラグインによっては自動保存がリビジョンとして残る場合もあるため、間隔調整とリビジョン上限の両方を設定するのが実務的に安全です。🔧

比較表：方法ごとの長所・短所

スクロールできます

方法	長所	短所
wp-config.php（定数）	サーバー側で確実に反映。軽量でプラグイン不要。	ファイル編集が必要。誤編集でサイトに影響。
functions.php（フィルタ）	投稿タイプごとの柔軟な制御が可能。	コード編集が必要。テーマ更新で上書きされる可能性あり。
プラグイン	GUIで設定しやすい。非技術者向け。	プラグイン品質に依存。余分なプラグイン負荷。
自動保存間隔調整	無駄な保存を減らせる。	間隔を長くし過ぎると作業データ喪失リスクあり。

動作確認と運用フロー（初心者向けチェックリスト）

バックアップを取得する（ファイル＋DB）。💾
変更を加える場所を決める（wp-config.php / functions.php / プラグイン）。
一時的にテスト投稿で動作確認（本番記事を触らない）。🧪
反映を確認：リビジョンが指定数だけ残るか、自動保存間隔が変わるかを確認。
不要リビジョンのクリーンアップ（必要なら一括削除、DB最適化）。🧹
運用ルールを決めてドキュメント化（例：月1でDBクリーン、主要記事は無制限など）。🗂️

最後に（推奨）

初めて設定するなら「保持数を少数に設定（例：5）」＋「自動保存は5分程度」にするのが安全でバランスの良い出発点です。✅
本番で直接編集するのが不安な場合は、まずステージング環境で試すことを強くおすすめします。

削除と最適化（ストレージ/表示速度対策）

リビジョン（編集履歴）が大量に蓄積すると、データベース容量が増えてサイト表示やバックアップに影響することがあります。

ここでは 個別削除 → プラグインでの一括削除 → データベース最適化 → プラグイン無しでのクリーンアップ（SQL／WP-CLI） まで、初心者でも実行しやすい手順をわかりやすくまとめます。

作業前に必ず「ファイル＋DBのバックアップ」を取ってください。💾

単一リビジョンの削除方法（個別操作）

目的：特定の投稿で誤ったリビジョンだけ消したい／差分だけを扱いたいときに使います。

Gutenberg（ブロックエディター）からの手順

対象の投稿を編集画面で開く。
右上の「ドキュメント」パネル → Revisions: ○件 をクリックして比較画面へ。
削除したいリビジョンが表示されている場合は、その版を表示して内容を手動で編集（差分をコピー）し、現在版から不要箇所を消すのが安全。
- ※標準UIに「1つのリビジョンだけをDBから完全削除する」ボタンはないため、個別削除は管理画面からは限界がある（代わりにプラグインやDB操作を使います）。

クラシックエディターからの手順

基本は同じ。リビジョン比較で不要部分をコピーして現在の投稿に反映→現在の投稿を更新して旧リビジョンに上書きする、というフローが実用的。

ポイント

管理画面の「復元」操作は過去版を“上書きで戻す”操作であり、DB内の古いリビジョンを個別に削除するとは別物です。
個別にDBから削除したい場合はプラグインまたは直接DB操作（後述）が必要になります。⚠️

一括で不要な履歴を消す方法（プラグインを使った一括削除）

目的：全投稿・特定投稿タイプ・一定期間より古いリビジョンをまとめて消したいときに便利。GUIで扱えるため初心者向き。

代表的な操作例（一般的な手順）

管理画面 → プラグイン → 新規追加 → 「WP-Optimize」「WP-Sweep」「Advanced Database Cleaner」等を検索してインストール・有効化。
プラグインの設定画面へ移動し「Revisions（リビジョン）」や「Database cleanup」など該当メニューを探す。
一括削除対象（全リビジョン / 投稿タイプ別 / 日付指定など）を選択し、バックアップを取得した後に実行。
削除完了後、プラグインの「最適化（OPTIMIZE）」機能でテーブルの最適化を行うことが多い。

操作上の注意

必ずDBバックアップをとる（削除は元に戻せません）。
プラグインによっては大量リビジョン削除で処理がタイムアウトすることがあるため、数回に分けて実行したり、ホスティングのCLIやステージングで行うと安全です。
サイトのアクセスが多い時間帯は避け、メンテナンス時間に実施するのが望ましいです。🕑

データベースの最適化手順と注意点（WP-Optimize等の活用例）

目的：リビジョン削除後にテーブルを最適化して空き領域を回収し、DBサイズを縮小する。

手順（プラグインで簡単に）

削除作業後、WP-Optimize や同様のプラグインの「データベース最適化」セクションへ。
OPTIMIZE TABLE 相当の操作（テーブルの最適化）を実行。プラグインによっては実行前に推奨事項やチェックボックスを提示します。
実行後、wp_posts や wp_postmeta のサイズが小さくなったかを確認。

プラグインなしでのクリーンアップ（SQLやWP-CLIの例）

目的：プラグインを入れたくない環境や、自動化スクリプトで運用したい場合に使います。コマンド／SQLは取り返しがつかないため、必ずバックアップ後に実行してください。

A. 特定投稿のリビジョンを一覧表示（WP-CLI）

# 投稿ID = 123 のリビジョンID一覧（確認用）
wp post list --post_type=revision --post_parent=123 --format=ids

B. 特定投稿のリビジョンを一括削除（WP-CLI）

# 投稿ID = 123 のリビジョンを削除（慎重に）
wp post delete $(wp post list --post_type=revision --post_parent=123 --format=ids) --force

–force を付けるとゴミ箱を経由せずに完全削除します。まずは wp post list ... でIDを確認してから実行してください。

C. すべてのリビジョンを一括削除（WP-CLI／危険）

# 全リビジョンIDを取得して削除（非常に危険。必ずバックアップ）
wp post delete $(wp post list --post_type=revision --format=ids) --force

実行前に wp post list --post_type=revision --format=ids | wc -w などで件数を確認することを推奨します。

D. SQLで削除（例：特定投稿／特定期間）

投稿ID のリビジョンだけ削除：

DELETE FROM wp_posts
WHERE post_type = 'revision' AND post_parent = 123;

90日より古いリビジョンを削除：

DELETE FROM wp_posts
WHERE post_type = 'revision' AND post_date < DATE_SUB(NOW(), INTERVAL 90 DAY);

関連する postmeta も同時に削除（postmeta のゴミ残しを防ぐ）：

DELETE pm
FROM wp_postmeta pm
JOIN wp_posts p ON pm.post_id = p.ID
WHERE p.post_type = 'revision' AND p.post_date < DATE_SUB(NOW(), INTERVAL 90 DAY);

その後にテーブル最適化：

OPTIMIZE TABLE wp_postmeta;
OPTIMIZE TABLE wp_posts;

重要な注意

上のSQLは 即座に実行され取り消せません。まずは SELECT 文で対象件数と内容を十分確認してください：

SELECT ID, post_date, post_parent
FROM wp_posts
WHERE post_type = 'revision' AND post_date < DATE_SUB(NOW(), INTERVAL 90 DAY)
LIMIT 50;

大量削除はDB負荷が高いため、分割して実行するか、オフピーク時間に行ってください。

方法ごとの比較

スクロールできます

方法	初心者向け度	復元可否（削除後）	備考
管理画面（手動コピー）	高	高（上書きしなければ）	個別で安全だがDB削除はできない
プラグイン（WP-Optimize 等）	非常に高	いいえ（削除後は不可）	GUIでわかりやすい。バックアップ必須
WP-CLI	中〜高（コマンド慣れ必要）	いいえ（削除後は不可）	スクリプト化や大量削除に最適
直接SQL	低（上級者向け）	いいえ（削除後は不可）	最も強力だが危険度高い

安全な実行フロー（初心者におすすめの手順）

必ずバックアップを取得（ファイルとDBの両方）。💾
ステージング環境があればそこで手順を検証。🧪
小規模なら プラグイン（WP-Optimize 等）で一括削除 → 最適化 を実行。
大量 or 自動化したいなら WP-CLI を使い、まずは wp post list --post_type=revision --format=ids で対象を確認。
SQLで操作する場合は 必ずSELECTで対象を確認 → 小分けでDELETE → OPTIMIZE TABLE を実行。
終了後、サイト表示（代表的な公開記事）、検索、管理画面を確認して問題がないか確かめる。🔍

まとめ（ワンポイント）

バックアップが最重要：削除操作は元に戻せません。
初心者はプラグインでの一括削除→最適化 が最も安全で手軽。
自動化や大量削除はWP-CLIやSQLで可能だが慎重に。実行前に対象確認・ステージングテスト・時間帯調整を行ってください。
削除後は OPTIMIZE TABLE（またはプラグインの最適化機能）で空き領域を回収するのを忘れずに。

管理を補助する代表的なプラグインと使いどころ

リビジョンの「制御」と「削除／最適化」は目的が違うため、目的別にプラグインを使い分けるのが効率的です。

以下では代表的なプラグイン群を「リビジョン制御系」と「最適化・掃除系」に分けて、特徴・使いどころ・導入手順（簡単）・注意点を初心者向けにまとめます。

表も使って一目で比較できるようにしています。

✅ 基本ルール：プラグインで操作する前に必ず ファイル＋DBのバックアップ を取りましょう。

リビジョン制御系プラグイン（上限設定・無効化・編集ワークフロー）

これらは「リビジョンを何件保持するか」「そもそもリビジョンを作るか」を手軽に管理するためのプラグインです。

コード編集なしで運用ルールを変更したいときに便利。

スクロールできます

プラグイン例	主な機能	使いどころ
WP Revisions Control / Simple Revision Control	投稿タイプごとに保持するリビジョン数を設定	少数世代（例：5件）だけ残したいサイト向け
Disable Post Revisions	リビジョンの自動生成を無効化	DB肥大を極力抑えたいケース（ただし復元機能が減る）
Revisionary / Editorial workflow系	編集の承認フローや下書き管理を強化	複数人の編集フローがあるメディア向け

最適化・掃除系プラグイン（データベース軽量化）

リビジョンを削除したり、DBの不要データを掃除してテーブルを最適化する目的で使います。

削除は元に戻せないので、操作は慎重に。

スクロールできます

プラグイン例	主な機能	使いどころ
WP-Optimize	リビジョン削除・テーブル最適化・キャッシュ機能など一括で実行	手軽にDBを軽くしたい＆UIで管理したいとき
WP-Sweep	各種「ゴミデータ」を細かく掃除（リビジョン、トランジェント等）	詳細に削除対象を選びたい場合
Advanced Database Cleaner	スケジュール/詳細設定で定期クリーンが可能	定期メンテナンスの自動化をしたいサイト

導入の流れ（代表例：WP-Optimize）

プラグインをインストールして有効化。
「WP-Optimize」メニューへ移動 → Database タブを開く。
「Revisions」などのチェックボックスを選び、バックアップ取得後に「Run optimization」を実行。
実行後、同プラグインで OPTIMIZE TABLE 相当の操作を行う（多くはワンクリック）。

実行時の注意

大量データを一度に削除するとタイムアウトやDB負荷が発生することがあります。分割実行やオフピークでの実施を推奨。
一括削除は不可逆なので、必ずバックアップ（DBダンプ）をとる。
プラグイン内の「自動クリーン」やスケジュール機能は便利ですが、設定が厳しすぎると必要な履歴まで消えることがあるので注意。

ちょっとした使い方のヒント（初心者向け実務TIPS）

まずはテスト環境で試す：本番でいきなり一括削除を実行するのは危険。ステージングで手順を検証しましょう。🧪
削除対象は段階的に：最初は古いリビジョン（例：90日以上）だけを削除して様子を見ます。📆
スケジュール設定：定期的にDB掃除をしたい場合は Advanced Database Cleaner のスケジューラを使うと便利。🔁
ログを残す：プラグインやホスティングで実行ログを残せる設定があるならオンにしておくとトラブル時の追跡が容易。🧾

導入後にやるべき確認事項（チェックリスト）

[ ] 削除や設定変更の前に DBバックアップ を取得したか？
[ ] テスト投稿で期待どおりリビジョン数が制御されているか確認したか？
[ ] 一括削除後に公開ページの表示や画像・ショートコードの動作を確認したか？
[ ] wp-config.php の定数がプラグインの設定を阻害していないか確認したか？
[ ] プラグインの定期実行スケジュールはサイト稼働時間外に設定しているか？

まとめ（何をどのように選べばよいか）

簡単に「何件残すか」を決めたい → リビジョン制御系（WP Revisions Control 等）。
溜まった不要データを安全に掃除したい → WP-Optimize、WP-Sweep 等の最適化系。
複数人の編集ワークフローが必要 → Revisionary など編集フロー対応プラグイン。
コード編集が苦手 → プラグインで完結する方法が向くが、反映されない場合は wp-config.php を確認すること。

変更履歴の利点とリスク（運用方針の判断材料）

利点：誤編集の復旧や差分の把握、編集履歴の監査性

変更履歴（リビジョン）を残すメリットを具体的に、初心者にもわかりやすく整理します。

誤編集からの復旧が簡単
誤って文章を消した／公開してしまったとき、過去の版に戻せば即時復元できます。手動でのコピペ復元よりずっと安全で時間短縮になります。🔄
差分を見て変更点を正確に把握できる
どの箇所が追加・削除されたかが視覚的にわかるため、編集履歴の追跡が容易です。複数回リライトしたときに「どの編集で成果が出たか」分析するのに便利です。👀
共同編集の監査性（誰が何をしたかの記録）
複数人で編集するサイトでは、誰がいつ変更したかがわかることが信頼性とトラブル対応に直結します。社内メディアや編集チーム運用では必須レベルの機能です。🧑‍💻➡️🧑‍💻
実務での使い方例
- 重要記事は主要版（公開前）をキープ→誤編集時はその版に戻す。
- リライト前に最新版を保存しておき、複数案の差分を比較してベスト版を採用する。

リスク：データベース肥大化による表示速度低下、IDの増加、管理画面の扱いづらさ

リビジョンを無制限に放置すると起きやすい問題点と、それがもたらす影響をわかりやすく示します。

データベースサイズの増加 → バックアップ/復元やバックエンド処理が重くなる
リビジョンは投稿ごとにレコードを追加するため、数千～数万件のリビジョンが溜まると DBの容量が増え、バックアップ時間・転送量・復元時間が伸びる場合があります。📦⬆️
ページ表示や管理画面のパフォーマンス低下
大量のリビジョンがあると、投稿編集画面のロードや一覧表示の一部処理で遅延が出るケースがあります。特に共有ホスティング環境では影響が顕著です。🐢
ID（行数）の増大による運用上の混乱
post テーブル内のレコード数が増えると、DBクエリのスキャンコストや索引の効率に影響を与える場合があります。結果としてメンテナンスや分析クエリが遅くなることがあります。
管理画面の煩雑さ（リビジョンの取り扱いが面倒）
リビジョンが多すぎると、差分の探索や復元判断が大変になり、誤って古い版を復元するリスクが上がります。UIが扱いにくく感じる場面が増えます。⚠️

比較表：利点 vs リスク（要点だけ見たいとき）

スクロールできます

観点	利点（残す理由）	リスク（残しすぎた場合）
復元性	簡単に元に戻せる	大量だと管理が面倒
変更追跡	差分で編集の意図がわかる	探すのが大変になる
共同編集	誰が編集したかわかる	不要履歴が競合を生む
パフォーマンス	—	DB容量・バックアップ時間増加
運用コスト	—	定期的なクリーンが必要になる

運用方針の決め方（初心者向けの判断基準）

小さな個人ブログ / スタートアップ

推奨：保存数を少なめ（例：3〜5件）に設定し、定期バックアップを運用。
理由：復元性を確保しつつ、DBの肥大化を防げる。

チーム運営のメディア / 編集ワークフローあり

推奨：比較的多め（例：10〜20件）を許容。加えて定期的なDB最適化・バックアップを自動化。
理由：複数人が関わるため履歴が重要。だが無制限は避ける。

大規模高トラフィックサイト / メディア

推奨：リビジョンを制限し、外部バックアップで完全復元を担保。必要に応じて履歴はストレージ別（アーカイブ）で管理。
理由：DBコストとパフォーマンスが重要なため、運用ポリシーを明確化する。

実務でのおすすめルール（すぐ適用できる）

初期設定案（安全な出発点）：WP_POST_REVISIONS = 5、AUTOSAVE_INTERVAL = 300（5分）。✅
バックアップ頻度：重要記事があるなら毎日DBバックアップ、通常は週1〜が目安。💾
クリーン周期：古いリビジョン（例：90日以上）を月1回で削除して最適化。🧹
ステージングでテスト：設定変更や一括削除はまずステージングで試す。🧪

最後に：判断フロー（1分で決められるチェック）

サイトは個人かチームか？ → チームなら履歴を多めに。
DBのサイズやバックアップ時間が問題か？ → 問題なら保存数を減らす or 定期クリーン。
自動保存の頻度は適切か？ → こまめすぎるなら間隔を延ばす。
重大作業の前にバックアップは取っているか？ → 取っていなければまずバックアップ！

ひとこと：リビジョンは「安全帯」として非常に有用ですが、無制限に放置せず運用ポリシー（保持数・自動保存間隔・定期クリーン）を決めることが快適なサイト運営のコツです。

設定のすすめ（現場での推奨設定）

編集履歴（リビジョン）は「安全性」と「パフォーマンス」のトレードオフです。

ここでは 現場で実務的に使いやすく、安全に運用できる設定例とルール を提示します。

まずは小さく始めて、サイト規模に合わせて調整するのが基本です。

推奨される保存数（小規模〜大規模サイト別の目安）

以下は運用開始時にすぐ適用できる「目安」です。状況に応じて上下してください。

スクロールできます

サイト規模	推奨保存数（WP_POST_REVISIONS）	備考
個人ブログ／趣味サイト（投稿数少）	3〜5	DB負荷を抑えつつ復元は可能に。
中〜小規模ビジネス／副業ブログ	5〜10	多少の履歴を残せるバランス設定。
編集チームありのメディア	10〜20	複数案の比較や承認フローを考慮。
大規模／高トラフィックサイト	3〜10（または外部アーカイブ）	DB肥大を避けるため保持を制限し、重要版は別ストレージで管理。

ワンポイント

「無制限（デフォルト）」は初心者向けではありません。まずは上限を設け、運用で問題がなければ調整しましょう。
投稿タイプごとに値を分ける（例：投稿は5、固定ページは0）と柔軟です（後述のコード例参照）。

自動保存・リビジョン管理の運用ルール（バックアップ方針との併用）

運用ルール（必須）

編集前の一時ルール：大幅リライトを行う前は「現在版を下書きとして複製」しておく（重要記事の安全帯）。
バックアップ併用：リビジョンは編集単位の救済策。サイト全体の障害対策はバックアップで行う。
- 重要記事がある場合：DBは日次、フルバックアップは週次が目安。
- 小規模サイト：DB週次＋フルイメージ月次でも可。
ステージング運用：大幅なテンプレート変更やプラグイン導入はステージングで検証。
変更履歴の命名／メモ：編集者が「何をしたか」の短いメモ（編集ログ）を残す習慣をつけると履歴探索が容易になる。

自動保存（Autosave）設定目安

同時編集が稀なサイト：AUTOSAVE_INTERVAL = 300（5分） が現実的で不要リビジョンを減らせます。
複数人で頻繁に編集するチーム：AUTOSAVE_INTERVAL = 60〜120（1〜2分） を検討。
（wp-config.php に定義する例は下に記載）

バックアップ方針

重要度高：DB 日次・フル（ファイル＋DB）週次・復元テスト四半期ごと。
中程度：DB 週次・フル月次。
低頻度：DB 月次・フル月次 or 四半期。
※バックアップは外部ストレージ（別リージョン／クラウド）へ保管すること。

定期的なクリーンアップの運用スケジュール例

運用負担を抑えつつDB肥大を防ぐための実践スケジュール例です。各組織の運用力に合わせて自動化（プラグイン／WP-CLI）してください。

A：個人・小規模サイト（手動または簡易自動化）

毎月：古いリビジョン（例：90日以上）を一括削除（プラグインで実施）。🧹
毎月：DB最適化（プラグインのOptimize実行）。
毎月：バックアップ確認（保存先と復元手順のチェック）。

B：中〜大規模サイト（自動化推奨）

週次：インクリメンタルDBバックアップ（自動）。💾
月次：リビジョンのポリシーに従ったクリーン（例：最新 N 件以外を削減、古い履歴を削除）。
月次：DB最適化（自動／管理者承認）。
四半期：フルバックアップの復元テスト（動作確認）。🧪

C：編集チーム／大規模メディア（厳密運用）

日次：重要記事の内容スナップショット（外部ストレージ）を自動保存。
週次：自動クリーンは「90日より古いもののみ」等の緩やかな条件で実行。
月次：DB最適化＋パフォーマンスチェック（レスポンスタイム測定）。
四半期：リビジョン保持ポリシーの見直しと復元テスト。

実務でそのまま使えるコード例と運用コマンド（安全注意付き）

wp-config.php に追記する例

// 保持世代を 5 にする（サイト全体）
define( 'WP_POST_REVISIONS', 5 );

// 自動保存間隔を 5 分（300秒）にする
define( 'AUTOSAVE_INTERVAL', 300 );

投稿タイプ別に保持数を制御（functions.php）

add_filter( 'wp_revisions_to_keep', function( $num, $post ) {
    if ( 'post' === $post->post_type ) {
        return 5;
    }
    if ( 'page' === $post->post_type ) {
        return 0; // 固定ページは残さない
    }
    return $num;
}, 10, 2 );

定期クリーンの簡単な WP-CLI（cron に登録する例）

注意：実行前に必ずバックアップを。まずは --dry-run 相当で対象を確認してください（下は実デリート例：危険）。

# 例：90日より古いリビジョンを削除（wordpress のテーブルプレフィックスが wp_ の場合）
wp db query "DELETE FROM wp_posts WHERE post_type = 'revision' AND post_date < DATE_SUB(NOW(), INTERVAL 90 DAY);"

cron 登録例（サーバの crontab）：

# 毎月1日 03:00 に上のクエリを実行（事前にスクリプト化してから呼ぶこと）
0 3 1 * * /usr/bin/wp --path=/path/to/wp db query "DELETE FROM wp_posts WHERE post_type = 'revision' AND post_date < DATE_SUB(NOW(), INTERVAL 90 DAY);"

チェックリスト：設定適用後に必ずやること

[ ] wp-config.php / functions.php を編集する前にファイルとDBのバックアップを取得した。
[ ] テスト投稿で変更が反映されることを確認した。
[ ] 自動クリーンやcronはまずステージングで検証した。
[ ] クリーン実行後、代表的な公開記事を表示確認した（画像・ショートコード等）。
[ ] 定期バックアップの復元手順を責任者が把握している。

まとめ（初心者向けの“最短”推奨セットアップ）

まずは安全な出発点：WP_POST_REVISIONS = 5、AUTOSAVE_INTERVAL = 300。
バックアップを忘れずに：重要サイトはDB日次＋フル週次。
クリーンは自動化しつつ段階的に：まずは「90日より古いリビジョン」を月次で削除して様子をみる。
ステージング → 本番の順で適用：操作は必ずテストしてから本番で実行。

安全かつ効率的にリビジョンを運用するために

以下は「いま設定すべきこと」「トラブルが起きたときの優先的な対処」「導入・変更時に必ず行う手順」を初心者向けに実務的かつ短くまとまたものです。

まずは小さく始め、問題がなければ徐々に運用を強化してください。

最低限チェックすべき設定項目

編集前に必ず確認する“必須設定”

リビジョン保持数（WP_POST_REVISIONS）
- 推奨例：個人ブログは 3〜5、編集チームは 10〜20。
- wp-config.php またはプラグインで設定。
自動保存間隔（AUTOSAVE_INTERVAL）
- 推奨例：単独編集なら 300（5分）、複数人なら 60〜120 秒。
- 編集頻度に応じて調整して、不要な自動リビジョンの発生を抑える。
投稿タイプのリビジョンサポート
- カスタム投稿（book 等）が履歴を持つか post_type_supports() で確認。必要に応じて add_post_type_support() を設定。
バックアップ方針（CF. リスト）
- 重要サイト：DB 日次＋フル週次 を推奨。バックアップは外部に保管。
クリーンアップポリシー
- 古いリビジョン（例：90日超）を定期削除、または保持数で制御する運用を決める。
権限管理
- 編集者の権限を整理し、誰が復元・削除できるか明確にする。

確認用（短いコード例）

// wp-config.php に追記（例）
define('WP_POST_REVISIONS', 5);
define('AUTOSAVE_INTERVAL', 300);

トラブル発生時の優先対応フロー

現場で速やかに動けるよう、優先度の高い順で手順化しました。

まずバックアップを取得（最優先） 💾
- 問題が起きている時点でのDBダンプとファイルコピーを必ず取る。何もしないまま復旧操作をするのは危険。
影響範囲を切り分ける（再現性の確認） 🔍
- どの投稿・ユーザー・投稿タイプで起きているか特定。ステージングで再現できるか試す。
簡易チェック（すぐできる項目） ✔️
- wp-config.php の WP_POST_REVISIONS 設定確認。
- ブラウザのキャッシュやコンソールのJSエラー確認。
- 管理者権限でログインしているかチェック。
プラグイン・テーマの切り分け 🔧
- 全プラグインを一時無効化して症状が消えるか確認。
- デフォルトテーマ（例：Twenty）に切り替えて再チェック。
- 再現する場合はプラグイン or テーマのどちらが原因か逐次切り分け。
DBレベルでの確認 🧾
- wp_posts に post_type = 'revision' が存在するか確認。post_parent の関連をチェック。
- WP-CLI や SELECT 文で対象を安全に確認（DELETE は慎重に）。
復元／回避策の実行 🔁
- 管理画面で復元可能なら下書きで復元 → 表示確認 → 公開。
- DBが破損している等で復元不可なら、最新の安全なバックアップから復旧。
原因究明と恒久対策 🛠️
- 原因プラグインのバグ報告 or 設定修正。wp-config.php の値を運用方針に合わせて固定化。
- 定期クリーンや監視の自動化を検討。

導入・変更時のチェックリスト

導入前（準備）

[ ] ファイルとDBのフルバックアップを取得した。
[ ] ステージング環境で同じ設定を適用してテスト済み。
[ ] 変更内容（誰が何をするか）を関係者に共有済み。

変更時（実行）

[ ] wp-config.php / functions.php はエディタで直接編集せず、FTP/ホスティングのファイル管理でバックアップを残した。
[ ] 変更を加えたらテスト投稿で保存→リビジョン生成→復元まで一通り確認した。
[ ] 一括削除やDB最適化は深夜などのオフピーク時間に実行した。

変更後（確認）

[ ] 公開ページの表示（代表記事3〜5件）を確認した（画像・ショートコード・ウィジェット含む）。
[ ] 管理画面の編集画面表示速度とレスポンスをチェックした。
[ ] 定期クリーンやバックアップジョブが正しくスケジュールされていることを確認した。
[ ] 運用マニュアル（誰がいつ何をするか）を1ページにまとめ関係者に配布した。

定期運用（継続確認）

[ ] 月次でDBサイズとバックアップ時間を監視。
[ ] 四半期ごとにバックアップ復元テストを実施。
[ ] 重大アップデート（WP本体・主要プラグイン・テーマ）前にステージングで再確認。

最後に（実務ワンポイント）

まずは「小さな設定」から始める：WP_POST_REVISIONS = 5 と AUTOSAVE_INTERVAL = 300 を目安に。
常にバックアップを最優先：問題が出たらまずバックアップを取る。これが最も早く安全な対処です。
自動化で運用負荷を下げる：定期クリーンやバックアップは自動化（cron／プラグイン）してヒューマンエラーを減らす。

まとめ（この記事の要点 ─ これだけ押さえればOK）

リビジョンは便利だが放置は危険。 誤編集の復旧や編集履歴の把握には有益だが、無制限だとDB肥大や表示遅延を招く。
まずやること（必須）：作業前にバックアップ（ファイル＋DB）を取る、復元は下書きで試す。💾
すぐ使える設定例：WP_POST_REVISIONS = 5、AUTOSAVE_INTERVAL = 300（編集頻度に応じて調整）。
削除・最適化は段階的に：まずは「90日以上」など古いリビジョンから削る→プラグイン（WP-Optimize等）でOPTIMIZE → 表示確認。
トラブル時の優先順位：1.バックアップ取得 → 2.再現範囲の特定 → 3.プラグイン／テーマの切り分け → 4.DBの確認 → 5.復元またはバックアップからの復旧。
運用のコツ：保持数・自動保存間隔・定期クリーンのルールを決め、ステージングで検証してから本番に反映する。