初めてWordPress公式ディレクトリにプラグインを登録するまで ― 「Egosaru Suggest」が承認されるまでの８日間と、つまずいたこと

　投稿画面の中でサジェストを調べられるプラグイン「Egosaru Suggest（エゴサる・サジェスト）」が、2026年10月26日にWordPress.orgの公式プラグインディレクトリに承認されました。いまは管理画面の「プラグイン → 新規追加」で「Egosaru Suggest」と検索すれば、そのまま入れられます。

　公式ページ：https://wordpress.org/plugins/egosaru-suggest/

　プラグインの中身と使い方は、申請したときの記事に書きました。今回は、その続きです。申請から公開までにやったこと、つまずいたことを、そのまま書きます。

　私にとって、WordPress.orgへのプラグイン申請は初めてでした。コードを書くこと自体よりも、審査の作法と、「この名前のサービスは本当にあなたのものか」を証明するところで、思った以上に手間取りました。これから申請する方の参考になればと思います。

1.申請から公開までの８日間

　全体の流れは次のとおりです。提出から承認まで８日、承認から公開ページが出るまでは、その日の夜のうちに終わりました。

1.申請から公開までの８日間

　10月18日の夜に提出し、自動チェック（Plugin Check）にはその場で合格しました。そこから人の目の審査を待ちます。このときの画面には、審査待ちが500件以上あると出ていました。

　最初の審査メールが届いたのは、10月21日の深夜１時30分です。提出から２日と５時間でした。思っていたより早かったのですが、中身は「承認」ではなく「保留」でした。

2.審査メールのやり取り一覧

　私のメールソフトの受信一覧です。審査のやり取りは、すべて１つのスレッドにつながっています。10月21日の深夜に最初の審査、同じ日の夕方に修正版の受付確認、10月24日の未明に差し戻し、その日の夜に私の返信、そして10月26日の未明に承認です。承認の後ろに並ぶ３通は、SVNにコミットするたびに届く通知で、22時台に３回コミットしたことが分かります。私のメールアドレスは伏せています。

3.最初の審査メール

　最初の審査メールの前半です。件名は「Review in Progress」で、「いくつか問題が見つかったので、直す機会を作るために保留にしました」と書かれています。その下の「The review process」には、審査の進め方が順番に並んでいます。メールを最後まで読むこと、指摘をすべて直してテストすること、そしてこのメールのスレッドに返信すること。この先に、指摘の中身が長く続きます。宛先のメールアドレスは伏せています。

4.審査で受けた指摘と対応

　審査メールは長文の英語で、冒頭に「このメッセージは人とアルゴリズムとAIを組み合わせて作っています。AIの出力には✨の印を付けています」と書かれていました。審査する側もAIを使う時代なのだと、少し驚きました。

4.審査で受けた指摘と対応

　指摘は、大きく分けて次の４つでした。

　１．設定値の無害化（サニタイズ）がない。 設定画面で保存する５つの項目に、入力値を整える処理（sanitize_callback）が付いていませんでした。APIキーは文字列として整え、取得元は許可した値だけを通し、キャッシュ日数は１〜30日に丸めるように直しました。

　２．PHP 7.4で動かない関数を使っている。 readmeでは「PHP 7.4以上」と書いているのに、PHP 8から入った str_contains() を使っていました。PHP 7.4の環境では、管理画面を開いた時点で致命的エラーになります。自分の環境がPHP 8なので、まったく気づいていませんでした。

　３．不要な翻訳読み込みを呼んでいる。 公式ディレクトリのプラグインは、WordPress本体が翻訳ファイルを自動で読み込みます。自分で load_plugin_textdomain() を呼ぶ必要はない、という指摘でした。

　４．名前に「Egosaru」を使うなら、所有者であることを示してほしい。 他社の商標や有名サービスの名前を勝手に使ったプラグインを防ぐための確認です。エゴサるは私が運営しているサービスなので、改名ではなく、所有者であることを証明する方向にしました。

　コードの指摘３つは、その日のうちに直しました。修正したzipを「Add your plugin」のページから同じスラッグ（egosaru-suggest）で再アップロードし、コメント欄に直した内容を短く書きました。このコメントは、受付確認のメールとして審査のスレッドにつながります（一覧の10月21日18時19分の１通です）。審査メールには、新しいメールを送るのではなく、届いた審査メールに返信することとも書かれています。新しいメールで送ると、担当者の順番待ちに戻れません。

　審査メールには、返信の書き方についての注意もありました。「返信は短く、次の審査に必要なことだけを書くこと」「変更点を全部説明しなくてよい」「AIが作ったような冗長な文は避けること」。指摘の一部しか直さずに返信を繰り返すと、ボランティアの時間を奪うとして却下されることがある、とも書かれていました。指摘は全部直してから返す、が基本です。

5.所有権の証明でつまずいた

　いちばん苦労したのは、コードではなく４つ目の「名前」でした。

5.所有権の証明でつまずいた

　所有権の証明には、いくつか方法があります。サービスのドメイン（エゴサるなら gstudio1.com）のDNSに、決められた文字列のTXTレコードを追加するのが、いちばん確実です。今回の文字列は wordpressorg-egosaru-verification でした（egosaru の部分はWordPress.orgのユーザー名です）。

　ここで私は、順番を間違えました。再アップロードのコメントで「DNSのTXTレコードを追加しました」と書いたのですが、実際にはまだ外から見える状態になっていませんでした。さらに、運営会社の説明も、サイトの表記とうまく結びついていませんでした。

6.再アップロード時のコメント

　再アップロードすると届く受付確認のメールです。「Comment:」のあとが、私が書いたコメントです。「Egosaruは自社のサービス（gstudio1.com、ライトセンドが運営）で、DNSのTXTレコードを追加済み」と書いています。この時点では、まだレコードが外から見えていませんでした。

　10月24日に届いた返事は、こうです。「DNSを確認したが、レコードが見つからない。サイトには会社へのリンクがあるだけで、その会社がエゴサるを運営していることは確認できない。DNSの確認、サイト上の公式な表記、正しいアカウントへの移管のどれかで関係を示すか、公式プラグインに見えない名前に変えてほしい」。

7.所有権で差し戻されたメール

　差し戻しのメールです。「the current DNS check does not find the required record」（いまDNSを確認しても、必要なレコードが見つからない）とはっきり書かれています。名前を変えるなら、新しいパーマリンク（スラッグ）を返信で明示するように、とも書かれています。

　改名も考えました。ただ、スラッグ（URLの一部になる名前）は承認後に変えられません。改名するなら、コード全体の置き換えと再アップロードが必要で、審査もさらに長引きます。エゴサるは自分のサービスなので、名前は守ることにしました。

　今度は、DNSにTXTレコードを追加したあと、Googleの公開DNS（8.8.8.8）で実際に見えることを確かめてから返信しました。返信の本文は、次の３文だけです。

8.DNSを確認してから送った返信

　10月24日の20時58分に送った返信です。「TXTレコードがgstudio1.comのルートで公開された（8.8.8.8で見える）」「私がgstudio1.comとエゴサるを管理している」「前回のアップロード以降、プラグインは変えていない」。届いた差し戻しのメールに、そのまま返信しています。差出人のメールアドレスは伏せています。

　会社の関係を長々と説明することは、やめました。審査で聞かれているのは「このアカウントがgstudio1.comを管理しているか」だけで、DNSのレコードはその答えとして十分だからです。説明を足すほど、新しい質問を呼んでしまいます。

　そして10月26日の深夜０時35分、承認のメールが届きました。返信してから、１日と４時間ほどです。メールの冒頭に「CONGRATULATIONS」の文字を見たときは、正直ほっとしました。

9.承認のメール

　審査のスレッドに届いた承認のメールです。「YOUR PLUGIN HOSTING REQUEST HAS BEEN APPROVED」（ホスティングの申請が承認されました）とあり、SVNのURLや公開ページのURL、次にやることが並んでいます。「問題がない限り、このメールには返信しないでください」とも書かれています。

10.SVNの使い方を案内する承認メール

　承認のメールは、もう１通、別の件名で届きます。こちらは、SVNの使い方の案内が中心です。「コードはSVNで自分でアップロードすること（代わりにはやれない）」「ユーザー名は大文字・小文字を区別する」「SVNのパスワードはプロフィールで設定する」「メールアドレスはユーザー名として使えない」。このあとの作業で、私がつまずいた点が、ほとんどここに書いてありました。

11.SVNで公開するまでの手順

　承認されて終わり、ではありません。承認メールに書かれているのは、「あなた専用のSVNリポジトリを用意しました。コードは自分でアップロードしてください」ということです。ファイルを入れるまで、公開ページは表示されません。

11.SVNで公開するまでの手順

　GitHubに慣れていると戸惑うのですが、WordPress.orgのプラグインは、いまでもSubversion（SVN）で管理されています。ここでも、いくつかつまずきました。

　１．SVNのパスワードは、ログインのパスワードとは別物。 WordPress.orgのプロフィールの「Account & Security」で、SVN専用のパスワードを発行します。ユーザー名は大文字・小文字を区別し、メールアドレスでは認証できません。

　２．パスワードが写った画面を共有してしまった。 発行した画面のスクリーンショットを、作業を手伝ってもらっていたAI（Claude Code）にそのまま貼ってしまいました。すぐに指摘されて、パスワードを再発行しました。発行直後の画面は、人にもAIにも見せないほうがよいです。

12.SVN用パスワードの発行画面

　実際に共有してしまった画面です。パスワードは灰色で伏せています（このパスワードは、すでに無効にしています）。「Copy」の左に、パスワードがそのまま表示されます。

　３．フォルダを二重にしない。 trunk/ の中に、プラグインのファイルを直接置きます。trunk/egosaru-suggest/ のように、もう１階層作ってしまうと正しく認識されません。Windowsでは、コマンドラインのSVNクライアント（SlikSvn）を入れて作業しました。

　４．タグを切って、readmeの「Stable tag」と合わせる。 trunk をコピーして tags/1.1.0 を作り、readme.txtの Stable tag も 1.1.0 にしてからコミットします。利用者に配られるのは、この Stable tag で指定したタグの中身です。

13.SVNで初めてコミットしたターミナル

　最初の行は、赤い文字のエラーです。私のパソコンには svn コマンドが入っておらず、「認識されません」と言われました。そこで winget でSlikSvnを入れてから、コミットしました。trunk と tags\1.1.0 に同じファイルが追加され、最後に「リビジョン 3766474 をコミットしました。」と出れば成功です。パスワードの入力行は伏せています。

　コミットが通ると、ブラウザでSVNのURLを開いて、中身を確かめられます。trunk/ の直下に、プラグインのファイルが並んでいれば正解です。

14.SVNのtrunkにファイルが入った画面

　egosaru-suggest.php と readme.txt が、フォルダを挟まずに trunk/ の直下にあります。しばらくして、公開ページも表示されました。

公開した直後に、不具合が見つかった

　コミットすると、WordPress.orgから変更内容（差分）の入った通知メールが届きます。その差分を見直していて、ブロックエディタのパネルで件数を表示する一行に、関数の読み込み漏れがあることに気づきました。結果を表示する瞬間にエラーになりうる不具合です。

15.1.1.0をコミットした通知メール

　最初のコミット（リビジョン3766474）の通知です。追加したファイルの一覧のあとに、「Diff」として中身の差分がそのまま続きます。自分が出したコードを、もう一度別の形で読み直す機会になりました。

　修正は１行でしたが、承認されたばかりのバージョンに不具合が残っていたのは、少し悔しかったです。審査は、セキュリティやガイドラインの確認であって、動作のテストまではしてくれません。その日のうちに1.1.1として直し、もう一度コミットしました。

16.1.1.1で直した通知メール

　1.1.1のコミット（リビジョン3766483）の通知です。差分の - const { __ } = wp.i18n; が + const { __, sprintf } = wp.i18n; に変わっているのが、今回の修正です。あわせて、readmeの Stable tag を1.1.1に上げ、FAQの「10 attempts」を実際のコードに合わせて「12 attempts」に直しています。

　公開ページには「Version 1.1.1 will be released to sites in about 6 hours」と出ます。WordPress.orgでは、更新が利用者に配られるまで６時間ほど待つ仕組みになっています。