投稿リビジョンとは何か
WordPress の「投稿リビジョン」は、
記事を更新するたびに自動保存される「過去バージョンの履歴」です。
1 回保存するごとに、
その時点の本文・タイトル・カスタムフィールドなどが、
別レコードとしてデータベースに溜まっていきます。
プログラミングで言えば、
1 つの投稿に対して「コミット履歴」がどんどん増えていくイメージです。
この履歴のおかげで「前の状態に戻す」ができる一方、放置すると別の問題も出てきます。
なぜリビジョン数を「制限」した方がいいのか
無制限だとデータベースがじわじわ太る
デフォルトでは、リビジョン数に上限がありません。
つまり、1 つの記事を 50 回更新すれば、50 個分のリビジョンが溜まります。
長く運営しているサイトや、よく更新する記事が多いサイトでは、
この「リビジョンの山」がデータベースの wp_posts テーブルをどんどん肥大化させます。
結果として、
投稿一覧のクエリが重くなる
バックアップやリストアに時間がかかる
サーバーのストレージを無駄に消費する
といった影響が出てきます。
「履歴は便利だけど、無限にはいらない」
というのが、リビジョン数を制限する発想です。
「戻せればいい数」はそんなに多くない
現実的に「戻したい」と思うのは、
直前の状態
数回前の状態
くらいまでであることがほとんどです。
1 記事あたり 100 個も 200 個も過去バージョンがあっても、
それを全部使いこなすことはまずありません。
プログラミングで言えば、
Git の履歴を永遠に残すのとは違い、
「この画面の Undo は 20 回までで十分」
と決めるような感覚です。
WordPress のリビジョンも、
「安全に戻れるだけの数」を残して、
それ以上は切り捨ててしまって問題ないケースがほとんどです。
リビジョン数を制限する基本的な考え方
「無効化」ではなく「上限を決める」が現実的
リビジョン機能を完全に無効化することもできますが、
これはあまりおすすめしません。
なぜなら、
書いている途中でブラウザが落ちた
誤って本文を消して保存してしまった
といったときに、「戻せる保険」がなくなるからです。
現実的には、
リビジョン機能は生かす
ただし、1 投稿あたりの最大リビジョン数に上限を設ける
という形がバランス良いです。
例えば「5〜10 件くらいまで残す」と決めておけば、
直近の変更には戻れるし、
無限に履歴が増え続けることも防げます。
サイトの性格に合わせて「適正値」を決める
リビジョン数の上限は、サイトの運用スタイルによって変わります。
更新頻度が低いコーポレートサイトなら、
1 投稿あたり 3〜5 件でも十分かもしれません。
頻繁に書き換える長文記事が多いブログなら、
10〜20 件くらい残しておいてもいいでしょう。
大事なのは、
「無制限のまま放置」ではなく、
「自分たちの運用に合う上限値を一度決める」ことです。
実装イメージ：wp-config.php で制限する
WP_POST_REVISIONS 定数で上限を指定する
リビジョン数の上限は、wp-config.php に定数を追加することで設定できます。
イメージはこんな感じです。
define( 'WP_POST_REVISIONS', 10 );
この例では、
「1 投稿あたり最大 10 件までリビジョンを保存する」
という意味になります。
11 回目以降の保存では、古いリビジョンから順に削除され、
常に最新 10 件だけが残るようになります。
完全に無効化する場合の書き方（あえてやるなら）
もしどうしてもリビジョンを使いたくない場合は、
define( 'WP_POST_REVISIONS', false );
とすることで、リビジョン機能自体をオフにできます。
ただし、これは
誤操作からの復旧が難しくなる
自動保存の恩恵が減る
といったデメリットもあるので、
「上限を 0 にする」というよりは、
「小さめの上限を設定する」方が安全です。
すでに溜まっているリビジョンはどうなるか
上限設定は「これから保存される分」に効く
WP_POST_REVISIONS を設定しても、
すでにデータベースに溜まっているリビジョンが自動で消えるわけではありません。
上限は「これから保存されるとき」に適用されます。
つまり、
今後の更新では、指定した数以上は増えない
過去のリビジョンを整理したいなら、別途クリーンアップが必要
ということです。
過去リビジョンの整理は「お掃除」のイメージ
本格的にやるなら、
データベースを直接操作する
リビジョン削除用のプラグインを使う
といった方法で、
既存のリビジョンを一括削除・圧縮することもできます。
ただし、これは
バックアップを取ってから行う
本番環境でいきなりやらない
といった注意が必要な“お掃除作業”です。
プログラミングで言えば、
「古いログをローテーションして削除する」
「不要な履歴テーブルを整理する」
のと同じで、慎重さが求められます。
初心者のうちは、
まずは「これ以上増やさない」ために上限を設定し、
過去分の整理は慣れてから、あるいは詳しい人と一緒にやる、くらいで十分です。
プログラミングの感覚で整理してみる
「履歴テーブルの設計」と同じ発想
アプリケーション設計でも、
変更履歴を残すテーブルを作ることがあります。
そのときに必ず議論になるのが、
どこまで履歴を残すか
どのタイミングで古い履歴を消すか
という話です。
WordPress のリビジョンも、
まさに「履歴テーブルの運用ルール」を決める話です。
無制限に残すのは簡単ですが、
長期運用を考えると、
「上限を決めて、古いものから削る」方が現実的です。
「安全に戻れる」と「軽く保てる」のバランス
リビジョン数を 0 にすれば、
データベースは軽くなりますが、
安全に戻る手段も失われます。
逆に、無制限にすれば、
どこまでも戻れますが、
データベースは重くなります。
この二つの間で、
「自分のサイトにとってちょうどいいバランス」を見つけるのが、
天才プログラマー的な設計です。
まとめ：リビジョン数は「意識して決める設定」
「投稿リビジョン数を制限する」というのは、
履歴をどこまで残すか
データベースをどこまで軽く保つか
誤操作からどこまで戻れるようにしておくか
を、自分たちの運用に合わせて“設計する”ということです。
wp-config.php に
define( 'WP_POST_REVISIONS', 10 );
と 1 行書き足すだけで、
今後のリビジョンの増え方は大きく変わります。
もし今、あなたのサイトが長く運用されていて、
「なんとなく重い」「バックアップが大きい」と感じているなら、
まずは「リビジョン数をいくつにするか」を一度決めてみる。
それだけでも、
WordPress を“ただ使う側”から、“設計して運用する側”に一歩近づけます。
