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

最終更新: 2026年7月14日 ｜ 執筆: 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 自身がきれいに片付けてくれる、ゴミを残さない削除です。他プラグインとの違いは 比較記事にまとめました。

同じ悩みの人へ

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

• ✅ 消す前にプレビュー
• ✅ 投稿タイプ別・孤立リビジョン対応
• ✅ 大量削除も進捗バーで安定（v1.3.0）
• ✅ 今の基準のセキュリティ
• ✅ 無料・GPL・WordPress 7 対応

よくある質問