AIO Toolkit for WordPress 開発日記 vol.2 — Plugin Check 0/0でも残っていた19件の欠陥と、WordPress.org提出までの記録

開発日記 vol.1 を書いたのが2026年5月22日でした。
あれから3ヶ月半、Frontierline AIO Toolkit は WordPress.org へ提出済みで、現在は審査結果を待っている状態です。

その間の進捗をこのブログにまったく書けていませんでした。
実際には、コードよりも「提出できる状態にする」ほうがはるかに重かったというのが正直なところです。
この記事では、そこで起きたことを日付と数字のまま残します。

自分でWordPressプラグインを公開してみたい方には、そのまま使えるチェックリストになるはずです。

まず、vol.1 から変わったことを2つ

記録の前に、vol.1 の内容から変更した点を先に書いておきます。

1. プラグイン名は「Frontierline AIO Toolkit」に確定しました。 vol.1 時点の仮称から変わっています。理由は後述しますが、ブランド名を頭に付けることが審査ガイドライン上ほぼ必須だったためです。
2. Pro版の買切¥9,800 / サブスク¥980/月という価格は撤回しました。 vol.1 に書いた計画を、自社の実測値で検算した結果、取り下げています。こちらも後述します。

提出までの実際の日程

日付	出来事
2026-05-22	開発日記 vol.1 公開。構想段階
2026-07-31	開発GO決定。リリース通知フォームに実際の登録が入り、需要があると判断
2026-08-03	Free版MVPの全ファイル実装完了。PHP構文チェック 9/9 通過
2026-08-07	実際のWordPress（7.0.3 / PHP 8.4）で全機能を検証。不具合5件を修正し再検証。Plugin Check 0/0
2026-08-28	スラッグとText Domainを統一。WordPress.org へ提出（自動スキャン通過）
2026-08-31	審査から1回目の返答を受領して修正。その後の再レビューで指摘外の実バグを合計19件検出・是正
2026-09-02	修正版（20,977バイト・12ファイル）を再提出。審査待ち

実装そのものは4日で終わっています。
8月7日から9月2日までのほぼ1ヶ月は、提出物の品質を上げるためだけに使いました。

コードを書く前に効いていたルール

申請フォームのページ本文に書かれているのに、実装が終わってから読むと手戻りになるルールが4つありました。

1. スラッグはプラグイン名から自動生成され、あとから変えられない

申請フォームには「プラグインのURLはメインファイルの Plugin Name の値をもとに生成されます」と明記されています。
承認後のリネームはできません。

問題は、長い訴求名をそのまま Plugin Name にすると、スラッグが長くなって Text Domain と一致しなくなることです。
この2つがずれると、WordPress.org の言語パックが永久に効きません。
私たちは8月28日、提出の直前にこれに気づいて統一しました。

2. 一般名は受理されにくい（ガイドライン17）

「AI Writer」「Image Optimization」のような一般的な名前は、スラッグが空いていても受理されにくいと明記されています。
自分の名前・ブランド・組織名・プロジェクト名といった固有の識別子を付けるよう求められています。

そのため「AIO Toolkit」ではなく Frontierline AIO Toolkit にしました。
同じ理由で、先行して公開している Frontierline Forms もブランド名を頭に付けています。

3. 既に十分にある分野は拒否されうる（ガイドライン18）

「機能がディレクトリ内で既に十分に表現されており、意味のある差別化を提供しないもの」は拒否対象と書かれています。
llms.txt を生成するプラグインは既に複数あります。

そこで readme の Description の冒頭に、他の同種プラグインと何が違うのかを置きました。
AIに読ませるには「読める内容」「取得の許可」「解析できる文脈」の3つが揃って初めて成立するので、その3つを1画面で完結させる、という書き方です。
同じ内容を申請フォームの Additional Information にも書いて先回りしました。

4. 無料版にPro機能を入れてロックするのは禁止（ガイドライン5・6）

「プラグイン自体に含まれる機能を人為的に制限してはならない。
ペイウォール、ライセンスによる機能ゲート、期間限定トライアル、利用回数の上限」が明確に禁止で、違反時はアカウントの無期限停止もあり得ると書かれています。

vol.1 で書いた「Free版とPro版」という構成は、Pro版のコードを無料版の配布物に同梱しないという前提でしか成立しません。
ここは設計に直接効きました。

Plugin Check 0/0 でも通らなかった

8月28日に提出したあと、8月31日に審査から1回目の返答が届きました。
指摘は2点です。

• <script> タグ内に出力するJSON-LDで、エスケープフラグ（JSON_HEX_TAG など4つ）が付いていない
• readme.txt に同じ語の繰り返しがある

どちらも Plugin Check がERROR 0 / WARNING 0 を返している状態で残っていたものです。
静的解析は「出力先がHTMLの <script> 内であること」までは判断しません。

そこから、自分たちで19件見つけた

指摘を直したあと、そのまま再提出せず、全ファイルをWordPress.orgの審査観点で敵対的に読み直しました。
自主監査で7件、別のモデルに同じレビューを投げて1回目で6件、2回目でさらに実害4件と些細なもの4件。
合計19件の欠陥が出ました。

すべて、Plugin Check 0/0・PHP lint通過の状態で残っていたものです。
代表的なものを挙げます。

会員限定の本文が、匿名アクセスに全文出る

get_posts() は既定で suppress_filters が true です。
この状態では posts_where / posts_join フィルタが無視されます。
会員制・ペイウォール・アクセス制御のプラグインは、まさにそのフィルタで公開記事を絞っています。

つまり、公開エンドポイント（llms-full.txt のような全文フィード）から素直に get_posts() を呼ぶと、「投稿ステータスは公開だが会員限定」の本文がログインしていない相手に全文出ます。
公開エンドポイントから呼ぶクエリには必ず 'suppress_filters' => false を付ける必要があります。

その修正が、次の穴を開けた

suppress_filters を false にした瞬間、そのクエリ結果は閲覧しているユーザーによって変わるようになります。
それを単一のキャッシュに保存すると、管理者が先に開いた内容が匿名ユーザーに配信されます。

しかも設定画面から「生成されたフィードを確認する」リンクを出していたので、管理者が先に踏む導線が正規の手順として存在していました。
必ず起きる事故です。
修正を入れたら、その修正が触った層の周りをもう一周する、という教訓になりました。

新規インストール直後の1回だけ、設定が保存されない

オプションの行がまだ無いとき、update_option() は内部で add_option() に委譲します。
このため update_option_{$option} フックは発火せず、add_option_{$option} のほうが発火します。
キャッシュ破棄のフックを前者にしか張っていないと、初回だけ古いキャッシュが残ります。

さらに厄介なことに、この委譲経路ではサニタイズのコールバックが2回走ります。
2回目は自分自身の出力を入力として受け取るため、1回目で削除している一時キーに依存した処理が動かず、値が落ちます。
症状は「新規インストール直後の初回保存だけ設定が効かない」で、再現条件が狭く、通常のテストでは見落とします。

無効化してもエンドポイントが生き残る

無効化フックは init の後に走ります。
その時点で自分の add_rewrite_rule() は既にリライトルールに入っているため、そのまま flush_rewrite_rules() を呼ぶと同じルールがDBに書き戻されます。
無効化したのに /llms.txt がフロントページを200で返す、という状態になります。

robots.txt に1行足しただけで、既存の制限が効かなくなる

これがいちばん見落としやすい型でした。
robots.txt の仕様（RFC 9309）では、クローラーは自分に最も一致するグループだけを読み、他のグループは無視します。

つまり User-agent: GPTBot / Allow: / というグループを追記すると、そのクローラーに対しては User-agent: * にあった Disallow: /wp-admin/ も、SEOプラグインが追加していた除外設定も効かなくなります。
「追記しただけで何も上書きしていない」というのは、テキストとしては正しくても挙動としては誤りです。
必要な除外は各グループに複製する必要があります。

readme に「外部送信なし」と書いてあるのに、外部通信が飛んでいた

get_the_excerpt() は内部で the_content フィルタを走らせます。
本文にYouTubeのURLが裸で書かれたページが1枚あるだけで、匿名の /llms.txt アクセスのたびに oEmbed の外部通信が発生していました。
readme の「外部サービスに接続しません」という記述と矛盾する状態です。

このとき生成される oEmbed キャッシュが、ループ中の記事ではなく別の記事のメタ情報に書き込まれる、という副作用も実機で確認しました。
抜粋が必要なだけなら、本文から自前で切り出すのが安全です。

マルチサイトで、子サイトの投稿が404になる

ネットワーク有効化でサイトを順に切り替えながら flush_rewrite_rules() を呼ぶと、親サイトのパーマリンク構造が全サブサイトに書き込まれます。
構造の違う子サイトでは投稿URLが404になります。
実機で再現しました。
ループ内ではルールを削除するだけにして、各サイトの次のリクエストで再生成させる形に直しています。

Free版の最終形

19件を直した結果、提出物は12ファイル・20,977バイトになりました。
無料で提供する機能は次のとおりです。

1. llms.txt の自動生成 — サイト概要・会社情報・主要ページを機械可読な形で /llms.txt に出力します
2. llms-full.txt の自動生成 — 公開済みの投稿と固定ページの本文を集約します。キャッシュとサイズ上限つきです
3. AIクローラー22種の一括許可 — GPTBot / OAI-SearchBot / ClaudeBot / PerplexityBot / Google-Extended / Applebot-Extended / CCBot / Amazonbot ほかを robots.txt で明示的に許可します
4. JSON-LDの自動付与 — 投稿にArticle、固定ページにWebPage、トップページにOrganizationとWebSite、著者にPerson、アイキャッチにImageObjectを出力します
5. SEOプラグインとの共存 — robots.txt への追記はフィルタ優先度100000で行うため、robots.txt を後から作り直すSEOプラグインと併用しても消えません。Yoast SEO / Rank Math / All in One SEO / SEOPress を検出した場合は、JSON-LDの重複を避けるためのチェックボックスの横に、その旨を設定画面に表示します

パスワード保護・非公開・下書きの記事は、生成されるフィードに一切含みません。
データはすべて自分のサーバー上で生成され、外部に送信しません。

llms.txt そのものの意味については llms.txt とは何か、なぜ今すぐ必要か と llms.txt は本当に効果があるのか に書いています。

Pro版の買切をやめた理由

vol.1 では「Pro版は買切¥9,800 / サブスク¥980/月」と書きました。
これを撤回します。
理由は、自社の実測値で検算したからです。

先に公開している Frontierline Forms は、2026年6月28日にWordPress.orgで公開して2ヶ月が経った時点で、有効インストール数が10件でした。
Contact Form 7 の拡張という、市場としてはかなり大きい分野でこの数字です。
WordPress.org 内の検索順位は、新規プラグインでは最下層から始まります。

ここから逆算すると、AIO Toolkit の設置数も、公開から2ヶ月で数十件から百数十件の範囲に収まる可能性が高い。
無料版から有料版への転換率を1%と置いても、販売件数は数件です。
しかも買切は、売れた月にしか計上されません。
継続的な月次収益の土台としては機能しない、という結論になりました。

作りが悪いという話ではなく、時間軸が合わないという話です。
WordPress.org は、審査に1〜10日かかり、公開後に検索順位が形成されるまで数ヶ月かかる資産型のチャネルです。
9月公開なら、効いてくるのは来年です。

なので、Pro版は「設置数が育ってから」に送りました。
そのかわり、AI検索最適化（AIO）の受託・月額運用を主柱に置き直しています。
同じ知識で、必要な母数が2桁違うためです。
プラグインは収益源ではなく、実装品質を検証できる公開物として回収する、という位置づけに変えました。

このあたりの考え方は、WordPress.org へのプラグイン提出を初めて経験したときの記録である Contact Form 7 拡張プラグインを WordPress.org に申請した話 とあわせて読むと、判断が変わっていく過程が見えると思います。

現在地と、次にやること

9月2日に修正版を再提出し、審査結果を待っています。
申請フォームに表示される待ち行列は、8月28日に281件、8月31日に345件、9月2日に357件と増えていました。
公称は1〜10日ですが、そのとおりに進まない前提で見ています。

次の 0.2.0 で入れる予定は、AIクローラーのアクセスログです。
robots.txt で「許可」を出しても、実際にGPTBotが来たのかどうかは誰も見ていません。
来訪の回数・日時・エージェント別を可視化するところまでを、直近7日分に限って無料版に入れる方針です。

vol.3 では、審査が通ったあとの実際（SVNコミット、公開直後の設置数の動き、通知メールの反応）を書きます。
今度は間を空けずに書きます。

まとめ

• 実装は4日で終わり、提出できる状態にするのに1ヶ月かかりました
• Plugin Check が ERROR 0 / WARNING 0 でも、実行時にしか出ない欠陥は残ります。私たちの場合は19件でした
• スラッグ・プラグイン名・Text Domain の一致、命名規則、機能の差別化、無料版でのロック禁止は、コードを書く前に決めておくべきルールでした
• 修正を入れたら、その修正が触った層の周りをもう一周する。19件のうち複数が「前の修正が生んだ副作用」でした

制作会社さま・広告代理店さまからの下請け・白ラベルでのご依頼は Partners のページ に料金とお取引条件をまとめています。
個別のご相談は お問い合わせフォーム までどうぞ。