なぜ自分でリビジョン削除プラグインを作ったのか｜開発ストーリー

最終更新: 2026年9月22日 ｜ 執筆: Takahiro Nishii

発端：バックアップが妙に重くなった

記事数はそれほど増えていないのに、サイトのバックアップだけがどんどん遅くなる。ファイルは大して変わっていない。おかしいのはデータベースでした。管理画面からは何も見えないのに、DBだけが静かに膨らんでいたのです。

犯人は”見えない”リビジョンだった

wp_posts を覗いて驚きました。公開記事は数十本なのに、テーブルは数千行。その大半が post_type = revision。記事を更新するたびに自動保存される「過去版のコピー」でした。仕組みは リビジョンとは？と wp_postsが肥大化する原因にまとめています。

定番プラグインが消え、代替難民になった

「削除プラグインを入れよう」と思って気づきました。定番だった Better Delete Revision は、2022年に公式ディレクトリから消えていた（セキュリティ上の問題）。代わりを探しても、更新が止まっていたり、最新の WordPress で動くか不安なものばかり。安心して任せられる代替が、無い。この顛末は Better Delete Revisionの代替で詳しく書きました。

手動でやろうとして、詰めの甘さに気づく

手動という手もあります。でもどれも決め手に欠けました。

• phpMyAdmin で直接 DELETE — 一歩間違えば公開記事を巻き込む（その危険性）
• WP_POST_REVISIONS で制限 — “これから”にしか効かず、既存の山は残る（設定と限界）

結局、「安全に・既存を・確認しながら」消す手段が無かったのです。

「無いなら作る」──設計で最初に決めたこと

作ると決めて、最初に置いた原則は「消す前に、まず見せる」でした。総数・推定容量・累計削除数を可視化し、削除対象を一覧でプレビューできること。表示されるのはリビジョンだけで、公開記事は絶対に出てこない設計にしました。

作った機能：狙って消せて、取りこぼさない

そこから機能を積み上げました。

• タイプ別削除 — 投稿だけ・固定ページだけ・特定のカスタム投稿タイプだけと、範囲を狙える
• 孤立リビジョンの検出 — 親記事が消えても残る”孤児”データも掃除できる
• DBメンテ — 削除後に CHECK → OPTIMIZE でテーブルの断片化も整理（対象は wp_posts / wp_postmeta だけ）

「全消しは怖い」という人に寄り添えるように、という一点をずっと意識していました。

v1.3.0：大量削除を1クリックで

旧プラグインの最後の大きな更新 v1.3.0 の目玉は、大量削除の安定化でした。リビジョンが数万件あっても、押すボタンは1回でいい。あとは進捗バーを眺めているだけで、内部でバッチ処理が自動的に進みます。「大量削除でタイムアウト」という定番の悩みを解消しました。

一番こだわったのは、実はセキュリティ

リビジョン削除プラグインで見落とされがちなのがセキュリティです。Better Delete Revision が公式から消えたのも、そこが理由でした。だから今の基準で多層防御にしています。

• nonce ＋ フォームトークン
• 破壊操作のレート制限
• 1回の削除上限
• 触れるテーブルの許可リスト

削除は自前で DB を直接叩かず、WordPress 標準の wp_delete_post_revision() 経由。postmeta やターム関係まで WordPress 自身がきれいに片付けてくれる、ゴミを残さない削除です。他プラグインとの違いは 比較記事にまとめました。

その後：2本作って、1本に畳んだ

ここまでが Takahiro Revision Cleanup の話です。続きがあります。

公開したあと、私はもう1本作りました。Revision Autopilot といいます。リビジョン整理を夜間のスクリプトに任せたくて、WP-CLI と Abilities API から呼べる形にしたものです。そして3か月後、その2本を1本に統合しました。残したのは Revision Autopilot の方で、Takahiro Revision Cleanup は役目を終えます。

なぜ分けたのが間違いだったのか、どちらを残す判断をしたのか、統合で何を失ったのかは、2本作って1本に畳んだ話に分けて書きました。短く言えば、「何をするか」ではなく「どう呼び出すか」で製品を切ってしまったのが誤りでした。

統合で無くなったもの

上の「作った機能」に出てくるもののうち、次の3つは現在の Revision Autopilot にはありません。この記事を読んで入れた方が、無い機能を探すことのないように書いておきます。

• 累計削除数の表示 — 旧プラグインは「これまでに何件消したか」を数え続けていました。統合版が出すのは、総数・推定容量・投稿タイプ別の内訳です
• CHECK TABLE — 統合版にあるのは wp_posts と wp_postmeta への OPTIMIZE TABLE だけです
• 全件のページ送り一覧 — 統合後の画面に出るのは直近10件までです。「消す前に、まず見せる」という最初の原則からすると、ここはまだ足りていません

逆に増えたのは、WP-CLI と Abilities API から同じ操作を呼べること、削除を途中で中止できること、そして管理画面の日本語表示です。

同じ悩みの人へ

小さな違和感から始まって、公式ディレクトリ掲載まで来て、2本を1本に畳むところまで来ました。リビジョンで重くなった DB に悩む人に、遠回りせず届いてほしいと思っています。

• ✅ 消す前に総数・推定容量・投稿タイプ別の内訳を見せる
• ✅ 投稿タイプ別・孤立リビジョン対応
• ✅ 大量削除も進捗バーで安定。途中で中止できる
• ✅ 破壊的な操作は2回確認。JavaScript を切っていても働く
• ✅ 同じ操作を WP-CLI と Abilities API からも呼べる
• ✅ 今の基準のセキュリティ
• ✅ 無料・GPL・WordPress 5.9 以降

よくある質問