プラグインを2本作って、1本に畳んだ｜統合の判断と、失ったもの

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

2本になった経緯

1本目は Takahiro Revision Cleanup でした。溜まったリビジョンを管理画面から確認して削除するプラグインです。なぜ自分で作ったのかは 開発ストーリーに書きました。

2本目の Revision Autopilot は、そのあとに作りました。動機ははっきりしていて、自分のサイトの整理を夜間のスクリプトに任せたかったのです。管理画面のボタンは、人がそこに座っていないと押せません。そこで WP-CLI コマンドと、WordPress 6.9 で入った Abilities API 経由の ability として、同じ操作を出しました。

このとき私は「画面を持たないこと自体が設計だ」と考え、実際そう説明して公開しました。プラグインの説明文の2行目は、こう始まっていました——「このプラグインにはボタンがありません」。

分け方が間違っていた

しばらく運用して気づいたのは、単純なことでした。同じ人が、同じサイトで、日によって両方使うのです。

普段は夜間のスクリプトに任せておく。半年ぶりに大きく片付けるときだけ、管理画面を開いて数字を見てから消す。これは2人の別々の利用者ではなく、1人の利用者の2つの場面でした。

つまり私は、製品を「どう呼び出すか」という軸で切っていたのです。画面か、コマンドか。しかし利用者が選んでいるのは呼び出し方ではなく、その時どちらが都合がいいかでした。同じ仕事に対して、入口が2つあるだけです。入口ごとに箱を分ければ、どちらの箱にも機能が半分しか入っていない、という状態になります。

プロダクトを分ける軸は「解いている問題が違うかどうか」であって、「操作方法が違うかどうか」ではない。言葉にすれば当たり前ですが、作っている最中の私にはそう見えていませんでした。自分が実装した境界線が、そのまま製品の境界線に見えてしまっていたのだと思います。

決定的だったのは、審査の側から見た景色

きっかけは機能追加の要望でした。「Autopilot にも削除のボタンを置いて、消えていくのが目で見えるようにしたい」。自分でもそう思っていました。

ところが手を動かす前に気づきました。ボタンを足した瞬間、2本は機能的に同じものになる。そして Autopilot が WordPress.org の審査を通ったのは、「画面が無いこと自体が設計であり、それが既存プラグインとの違いだ」という説明が成立したからでした。

WordPress.org は、同一著者による実質的な重複プラグインを歓迎しません。ガイドラインに明示の条項は無く、「迷ったら聞け」とされている領域です。裏を返せば、黙って2本並べたまま片方に機能を足していくのは、いちばんまずいやり方でした。

だから選択肢は2つでした。ボタンを諦めるか、統合するか。統合を選びました。

どちらを残したか

残したのは Revision Autopilot です。名前の響きではなく、足し算の向きで決めました。

• Autopilot に画面を足すのは、既存のドメインオブジェクトの上に表示層を1枚乗せる作業でした
• Takahiro Revision Cleanup にCLI と ability を足すのは、画面の中に埋まっていた処理を引き剥がして、フォームも nonce も無い経路で安全に呼べる形に作り直す作業でした

前者のほうが小さく、かつ壊す範囲が狭い。それだけです。

実績で決めなかったのは、どちらにも守るべき実績が無かったからです。両方ともインストール数は10未満、レビューは0件。もし片方に数千サイトが入っていたら、間違いなくそちらを残していました。

統合後の設計の核は、3つの経路が同じオブジェクトの上に乗っていることです。画面・CLI・ability が別々の実装を持つと、同じ操作が呼び出し方によって違う結果を出すようになります。それは2本に分けていたときより悪い状態です。

失ったもの

統合はタダではありませんでした。

• Takahiro Revision Cleanup の3か月ぶんの存在。利用者、検索流入、プラグインページ。閉鎖したプラグインのページは「閉鎖済み」の表示になり、readme も読めなくなります
• 削除対象の全件プレビュー。旧プラグインは削除前のリビジョンをページ送りで全件表示できました。統合後の画面に出るのは直近10件までです。「消す前に、まず見せる」が最初に置いた原則だったので、ここは明確な後退です
• 名前。自分の名前を冠したプラグインを畳むのは、思っていたより抵抗がありました

既存の利用者への影響は、意図的に小さくしてあります。旧プラグインが発火していた tnrc_security_event アクションは統合後も発火し続けるので、監査ログを組んでいた人の連携は切れません。動作要件の WordPress は 5.9 で旧プラグインと同じにしました——移行のために WordPress を上げさせないためです。

後片付けの量を、正直に書いておく

統合作業の大半は、コードではありませんでした。すでに公開してしまった記述です。

厄介だったものを3つ挙げます。

• 構造化データ。Google が機械的に読む downloadUrl と installUrl が、死ぬURLを指していました
• レンダリング済みの画像。比較表の画像に、製品名と配布ページのURLが焼き込まれていました。生成元のHTMLを残していたので作り直せましたが、残していなければ手詰まりでした
• すでに投稿した SNS。編集できません。リンク先が自サイトのページなら生き続けますが、WordPress.org を直接指していたものは死にます

そして一番効いた判断は、製品ページのURLを変えなかったことです。旧プラグイン名のままのURLに、統合版の説明を載せています。見た目は不格好ですが、URLを変えれば稼働中のテーマコードのリダイレクト設定と、編集できない SNS 投稿のリンク先が、まとめて死にます。変えるのは「外へのリンク」と「製品名の主張」だけ、URLとスラッグは一切触らない——この線を引いたことで、事故の可能性の大半が消えました。

書き直しの途中で、事実の誤りが5つ出てきた

統合とは関係なく、製品ページの記述が実装とずれていました。書き換えのために全部読み直したことで、ついでに見つかったものです。

• バッチ上限を「1回あたり最大2,000件」と書いていた（実際は1,000件）
• 「PHP 7.4 以上」と書いていた（実際は 8.1 以上）
• 「一覧プレビュー 20件ずつページ送り」と書いていた（統合後の画面には無い）
• 「累計削除数を表示」と書いていた（無い）
• 「UI は英語です」と書いていた（日本語を同梱済み）

公開した文章は、放っておくと実装から静かに離れていきます。棚卸しの機会がなければ、誰も気づかないまま残り続ける。統合は痛い作業でしたが、これを見つけられたのは副産物として大きかったと思っています。

同じ判断をする人へ

もし今、似た形で複数のプロダクトを抱えているなら、1つだけ確かめてみてください。その分け方は、利用者が解きたい問題で切れていますか。それとも、あなたが実装した経路で切れていますか。

後者なら、遅いほど高くつきます。私の場合は3か月で18本の記述と1枚の画像でした。1年放置していたら、この記事は書けていなかったかもしれません。

よくある質問