WordPressの自動保存とリビジョンの違いは?DBが増え続ける仕組みとWP_POST_REVISIONS

このサイトはアフィリエイト広告(Amazonアソシエイト含む)を掲載しています。
WordPressの自動保存とリビジョンによる履歴の増え方を比較したイメージ

WordPressで投稿を編集していて画面の左下や上部に「保存中…」の表示がチラッと出るのを見て、なんとなく不安になったことはありませんか。

自動保存は編集中の内容を失わないための機能で、通常のリビジョンは保存・更新した内容を履歴として残す機能です。自動保存用の履歴は同じ投稿・同じユーザーについて最大1件までなので、編集しているだけで履歴が増え続けるわけではありません。一方、通常のリビジョンは標準では保存件数に上限がなく変更を保存するたびに増える可能性があります。

この記事ではWordPress公式ドキュメントの記載と実際のwp_postsテーブルの構造をもとに両者の違いと増え方の仕組み、そして必要に応じて制限する方法を整理します。

目次

結論だけ先に言うと

自動保存(Autosave)リビジョン(Revision)
生成タイミング編集中に一定間隔で自動的に生成。タイトルや本文など履歴の対象となる内容を変更して保存・更新した時に生成。
保存数の上限1投稿・1ユーザーにつき最大1件、条件によって下書き本体を更新。標準では無制限(WP_POST_REVISIONSで変更可)。
DBが肥大化する要因になるか同じ投稿・同じユーザーの履歴が時間とともに増え続けることはない。更新回数が多い投稿ほどなりやすい。
投稿一覧への表示されない。されない(編集画面のリビジョン欄からのみ確認可)。
DBの履歴件数を抑えるには通常は有効のまま使う。WP_POST_REVISIONSで保存件数を制限する。

自動保存用の履歴は同じ投稿・同じユーザーのものを上書きします。

通常のリビジョンは変更した内容を別の行として残すため、保存・更新を繰り返すほど件数が増えていきます。履歴の対象となる内容に変更がなければ通常は新しいリビジョンも作られません。

編集開始時の投稿ロック、編集中のローカル保存とサーバー保存、手動保存時のリビジョンの保存先を示す図

自動保存(Autosave)とは

自動保存は編集中の内容が失われないようにWordPressが裏側で定期的に保存してくれる機能です。ブラウザがクラッシュしたり、うっかりタブを閉じてしまったりしても次に編集画面を開いたときに「自動保存されたバージョンがあります」という案内が出てそこから復元できます。

ブロックエディター(Gutenberg)ではこの自動保存が二段構えになっています。

ローカル自動保存

編集内容をブラウザのストレージにだけ保存するものでサーバーのDBには書き込まれません。編集中の変更を定期的に保存します。

サーバー自動保存

編集中の内容をREST API経由でサーバーへ送り、データベースへ保存します。自動保存用の履歴を作る場合と、下書き本体を更新する場合があります。

DBの増減という意味で気にする必要があるのは後者のサーバー自動保存です。ローカル側はブラウザの中で完結しているので気にしなくて大丈夫です。

自分が作成した下書きや自動下書きを他のユーザーによる有効な投稿ロックがない状態で編集している場合、自動保存は下書き本体を更新します。この場合、別の自動保存リビジョンが作られるとは限りません。公開済み投稿などでは自動保存用の履歴に分けて保存されるため、編集中の内容がそのまま公開ページへ反映されることはありません。

自動保存用の履歴として保存される場合は「1投稿につき1ユーザーあたり最大1個まで」という上限があります。新しい自動保存が発生すると同じユーザーの古い自動保存はそのまま上書きされる仕組みです。複数人で同じ投稿を編集している場合は、ユーザーごとに1個ずつ自動保存が存在する形になります。

つまり「編集を続けている限り自動保存の行数が積み上がり続ける」ということは起きません。

リビジョン(Revision)とは

リビジョンは投稿のタイトルや本文などを変更して保存・更新したときに残る履歴です。過去の内容と比較したり、以前の状態へ戻したりするために使います。履歴の対象となる内容に変更がなければ通常は新しいリビジョンは作られません。

WordPressの標準設定では通常のリビジョンの保存件数に上限はありません。長い記事を何度も書き直すなど、本文の量と保存回数によってはデータベースの容量が増える要因になります。

過去の履歴をすべて残す必要がなければ、後述するWP_POST_REVISIONSで保存件数を制限できます。

DBの中では実際どう保存されている?

実際にwp_postsテーブルの中を覗いてみます。

通常のリビジョンと自動保存用に作られる履歴は、どちらもwp_postsテーブルに保存されます。専用のリビジョンテーブルがあるわけではなく、元の投稿を親とする別の行として扱われます。ここからは、この履歴として保存された行を確認します。

post_type

revision(自動保存・リビジョンともに共通)

post_status

inherit

post_parent

元の投稿のID

post_name

リビジョンは「{親投稿ID}-revision-v1」、自動保存は「{親投稿ID}-autosave-v1」という形式

自動保存とリビジョンを見分けているのはpost_typeではなくpost_nameの末尾(-revision-か-autosave-か)という点は少し意外でした。管理画面のUI上は別物に見えてもDB的には「同じpost_typeの中を名前で仕分けている」だけなんですね。

以下はphpMyAdminのSQL画面で実行する確認用の例です。123を調べたい投稿IDに、wp_postsを実際のテーブル名に置き換えてください。データの変更や削除は行いません。

SQL
SELECT
    ID,
    post_author,
    post_type,
    post_status,
    post_parent,
    post_name,
    post_date,
    post_modified
FROM wp_posts
WHERE post_parent = 123
  AND post_type = 'revision'
ORDER BY ID DESC;

下書きで試す場合は本文を変更してから手動保存し、通常のリビジョンが追加されるかを確認します。同じ内容を保存するだけでは増えない場合があります。自分の下書きでは自動保存が下書き本体を更新するため-autosave-v1の行がなくても異常ではありません。

公開済みのテスト用投稿では本文を変更して自動保存を待ち、更新ボタンを押す前に確認すると、自動保存用の履歴を調べられます。同じユーザーで編集を続けた場合は自動保存の件数だけでなく、行のIDやpost_modifiedの変化も見てください。


本番サイトとは別の環境で保存の動きを試したい場合はDockerでWordPressとphpMyAdminを用意できます。ローカル環境の構築手順は以下の記事にまとめています。

リビジョンの数を制限する(WP_POST_REVISIONS)

更新頻度の高いサイトでリビジョンを無制限に溜め続けたくない場合はwp-config.phpにWP_POST_REVISIONSを定義することで保存数を制限できます。

定義はrequire_once ABSPATH . 'wp-settings.php';より前へ記述します。すでに同じ定数がある場合は、追加するのではなく値を変更してください。

wp-config.php
// 各投稿につき最新5件までリビジョンを保持する
define('WP_POST_REVISIONS', 5);

指定できる値は次の通りです。

true

無制限に保存する。(デフォルト値)

1以上の整数

指定した件数を保持、超えた分は古いものから自動削除する。

false / 0

リビジョンを保存しない。

ここで注意しておきたいのが、falseや0にした場合でも自動保存そのものは残るという点です。「リビジョンを無効化した」つもりが「自動保存まで消えた」と勘違いしてしまうケースをたまに見かけますが、この二つは独立した設定という理解で問題ありません。

WP_POST_REVISIONSを設定しただけで、全投稿の古い履歴がすぐに削除されるわけではありません。たとえば 5 に設定すると、その投稿で新しいリビジョンが保存される際に、上限を超えた通常のリビジョンが整理されます。内容を変更せずに保存した場合などは、整理処理まで進まないことがあります。

falseや0は通常のリビジョンを新しく保存しない設定です。今までに作成された既存履歴をクリーンにしたい場合は手動で削除する必要があります。

自動保存の間隔自体を伸ばしたい場合はAUTOSAVE_INTERVALで秒数を指定します。

wp-config.php
// 自動保存の間隔を120秒に変更する
define('AUTOSAVE_INTERVAL', 120);

削除・制限しても大丈夫?

通常のリビジョンを削除するとその履歴を使って過去の内容へ戻せなくなります。自動保存も削除するとまだ手動保存していない編集内容を復元できなくなる可能性があります。

過去の履歴や未保存の編集内容を復元する必要がなければ不要な履歴を削除できます。このサイトではLiteSpeed Cacheプラグインのデータベース最適化機能を使っています。リビジョンのほか、削除済みの投稿に取り残された「孤立ポストメタ」や一時的なキャッシュである「期限切れのTransients」も整理できます。

LiteSpeed Cacheで投稿のリビジョン、孤立ポストメタ、自動下書き、期限切れのTransientsを赤い矢印で示した画面
筆者はこのへんの項目を整理しています。

WordPress 7.0からリビジョン画面が見やすくなった

2026年5月にリリースされたWordPress 7.0「Armstrong」ではリビジョンの比較画面が刷新され、編集画面に近い見た目でブロック単位の変更を確認できるようになりました。従来のHTMLベースの2カラム比較よりも実際に何が変わったのかが直感的に分かりやすくなっています。


WordPress 7.0全体の変更点は以前まとめているのでこちらもあわせてどうぞ。

迷いやすいポイント

自動保存を止める必要はありますか?

DBの履歴件数を減らしたいだけなら自動保存を止める必要はありません。自動保存用の履歴は同じ投稿・同じユーザーにつき最大1件で、古い内容を上書きします。まずは通常のリビジョンの保存件数を制限してください。

自動保存を止めるとブラウザを閉じたり通信が途切れたりした際に保存前の編集内容を復元できなくなるおそれがあります。特別な理由がなければ有効のまま使うことをおすすめします。

「New post」を開くたびに下書きが増えている気がするのですがこれもリビジョン?

それは通常のリビジョンとは異なるauto-draftという状態の自動下書きです。新規投稿画面で使う投稿本体で、自動保存用のリビジョンとも区別されます。

WordPressには7日を超えた古い自動下書きを削除する標準処理があります。通常はこの処理によって古いものが整理されます。

投稿を元に戻せるのは自動保存とリビジョンどっち?

保存された内容が残っていればどちらからも復元できます。自動保存の通知が出た場合は「自動保存を表示」から内容を確認し、復元するか判断します。

過去の変更履歴へ戻す場合は編集画面の設定サイドバーで「投稿」または「固定ページ」を開き、リビジョンの件数から比較画面へ進みます。戻したい履歴を選んで変更内容を確認し復元します。表示やボタン名は、WordPressのバージョンや使用するリビジョン画面によって異なります。

自分の下書きが直接更新されている場合など自動保存の通知や独立した自動保存履歴が表示されない場合もあります。

まとめ

  • 自動保存は編集中の保護、通常のリビジョンは過去の変更履歴を残すための機能だよ。
  • 自動保存用の履歴は1投稿・1ユーザーにつき最大1個。自分の下書きでは履歴を分けずに下書き本体を更新する場合もあるよ。
  • 通常のリビジョンは標準では件数の上限がないので変更を保存する回数が多い記事では容量増加の一因になるよ。
  • 増えすぎが気になるならwp-config.phpのWP_POST_REVISIONSで保存数を制限できるよ。0やfalseにしても自動保存は残る点は覚えておいてね。
  • 実際にphpMyAdminでwp_postsを覗いてみるとpost_parentやpost_nameの付き方から仕組みがすんなり理解できるよ。

WordPressの新機能や更新時の注意点、ローカル環境の構築などほかの運用記事はまとめページから探せます。

  • URLをコピーしました!
目次