AIでWordPressプラグインを作ればすぐ公開できる？ 実際にWordPress.orgへ申請して分かった7つの壁
「既存のプラグインでは、欲しい機能にあと一歩届かない」
WordPressを使っていると、そんな場面があります。複数のプラグインを組み合わせると管理が複雑になり、海外製のプラグインでは日本語の記事制作に合わないこともあります。一方、独自開発を外注するほど大規模な要望ではない場合、以前なら不便を受け入れるしかありませんでした。
生成AIの進歩によって、その状況は変わりつつあります。要望を整理し、コードを作り、エラーを調べるところまでAIが支援してくれるようになりました。小さな業務改善や、特定分野に特化した機能をプラグインとして形にするハードルは確実に下がっています。
そこでサイバーフォレスト株式会社では、AIを開発支援に使いながら、ギターのコード譜をWordPressのブロックエディターで作成できるプラグインを開発しました。
目標は、自分たちのサイトだけで動けばよいプログラムを作ることではありません。第三者がWordPressの管理画面から安心してインストールできるよう、WordPress.orgの公式プラグインディレクトリで公開することでした。
実際に取り組んでみると、「コードが動く」と「公式ディレクトリで配布できる」の間には、想像以上に多くの作業がありました。
誰のどんな問題を解決するか決める
WordPressの作法に沿って実装する
セキュリティと互換性を検査する
配布用ZIPと説明資料を整える
WordPress.orgの審査を受ける
指摘に対応する
承認後、Subversion（SVN）で公開する
この記事では、実際に公開したプラグインを題材に、企画から公式公開までの流れと、途中で直面した7つの壁を紹介します。
コードを一行ずつ解説する記事ではありません。これからAIを使ってプラグインを作りたい方が、「何を準備し、どこを自分で判断し、何を検証しなければならないか」を見通せるようにすることが目的です。
今回実際に作ったプラグイン
今回開発したのは、CyberForest Guitar Chord Sheetです。
WordPressのブロックエディター（Gutenberg）で、歌詞の上にコード名を入力し、ギターの運指をダイアグラムとして表示するためのプラグインです。
公開ページはこちらです。
解決したかったこと
ギター演奏者向けの記事では、歌詞とコード名だけでなく、「そのコードをギターでどう押さえるか」も一緒に示せると便利です。しかし、画像を一枚ずつ作成・配置すると、コードの追加や修正に手間がかかります。画面幅によって画像が見づらくなることもあります。
そこで、WordPressの記事編集画面からコード譜を入力し、コード名に対応するダイアグラムを表示できる専用ブロックを企画しました。
初期の無料版では、機能を広げすぎず、次の価値に絞りました。
Gutenbergから専用ブロックを追加できる
歌詞とコード名を編集できる
主要なコードの運指を表示できる
編集画面と公開画面の両方で確認できる
外部サービスへ接続せず、WordPress内で完結する
利用状況の追跡や個人情報の収集を行わない
公開までの結果
最初の申請は2026年8月1日に行いました。その後、プラグイン名とスラッグが一般的すぎるという指摘を受け、名称をブランド固有の CyberForest Guitar Chord Sheet に変更。修正版を提出し、2026年8月10日に承認されました。
承認後はWordPress.orgから割り当てられたSVNリポジトリへ公開用ファイルを登録し、2026年8月12日にバージョン`0.1.1`を公開しました。
公開時には、WordPress.orgが生成した配布ZIPと審査提出版の内容が一致すること、公開ページ、バナー、アイコン、スクリーンショットが表示されることまで確認しています。
これは「AIにコードを書いてもらったら完成した」という話ではありません。企画、仕様、実装、検査、申請、審査対応、配布管理をつなぎ、初めて一つの公開プラグインになりました。
AIを使った開発から公開までの全体像
今回の取り組みを大きく分けると、次の8段階になりました。
1. 課題と対象利用者を決める
最初に決めるのはコードではありません。「誰が、どの作業で困っているか」「既存の方法ではなぜ足りないか」を整理します。
今回は、WordPressでギター関連記事を作る人が、歌詞、コード名、運指図を一つの編集体験で扱えることを目標にしました。
2. 無料版の範囲を決める
思いついた機能をすべて入れると、完成が遠のき、検査範囲も広がります。最初は、プラグイン単体で役立つ最小限の無料版に絞りました。
将来のPro版候補は、無料版にロックした状態で詰め込むのではなく、別製品として設計しています。
3. Gutenbergブロックとして実装する
WordPressのブロックとして登録し、編集、保存、再編集、公開画面での表示が成立するように実装します。ブラウザー上で見た目が動くだけでなく、投稿に保存した内容を再び正しく読み込めることが重要です。
AIには、設計案、コード作成、問題の切り分け、テスト観点の洗い出しなどを支援させました。ただし、採用する仕様と最終判断は人が行います。
4. 品質と安全性を検査する
開発版では、WordPress上の動作確認に加え、公式Plugin Check、WordPress Coding Standards、PHP構文、入力値の処理、出力時のエスケープ、ライセンス、ZIP構成などを確認しました。
「自分の環境で動いた」だけでは、第三者へ配布できるとは判断しませんでした。
5. 公開資料を準備する
プラグイン本体だけでなく、`readme.txt`、説明、FAQ、変更履歴、バナー、アイコン、スクリーンショットを準備します。
WordPress.orgの一覧で利用者が最初に見るのは、コードではなく名前、説明、画像です。公開資料も製品の一部として扱いました。
6. WordPress.orgへ申請する
WordPress.orgアカウントを確認し、完成したZIPと概要を申請フォームから提出しました。提出時の自動スキャンには合格しましたが、それで公開が確定するわけではありません。人による審査を待ちます。
7. 審査指摘へ対応する
今回、一般的すぎる名称とスラッグについて修正を求められました。新名称へ統一した修正版ZIPを作り、既存の申請にアップロードし、元のメールスレッドで変更内容を返信しました。
8. 承認後にSVNで公開する
承認されると、専用のSVNリポジトリが用意されます。完成したプラグインを`trunk/`、公開バージョンを`tags/0.1.1/`、掲載画像を`assets/`へ登録しました。
公開後には、ページが表示されるだけでなく、生成されたZIPを取得し、意図したファイルだけが含まれていることも確認しました。
「AIならすぐ公開できる」と思っていた
生成AIは、プラグイン開発の速度を大きく上げてくれます。
「こういう機能が欲しい」と伝えれば、ファイル構成や実装案を出してくれます。エラーを渡せば原因候補を挙げ、修正コードも提案してくれます。知らないAPIやWordPress固有の仕組みを調べる入口としても有効です。
そのため、最初は「小さなプラグインなら、コードを生成してZIPにすれば公開できるのではないか」と感じるかもしれません。
ところが、AIが得意なのは主に、与えられた条件に対する案を素早く作ることです。公開に必要な条件がプロンプトから抜けていれば、その条件を満たさないコードが完成する可能性があります。
たとえば、画面に文字を表示するだけなら簡単でも、配布を考えると次の問いに答えなければなりません。
入力値は安全に処理されているか
権限のない利用者が操作できないか
表示時に適切なエスケープをしているか
古いPHP環境でも構文エラーにならないか
他のテーマやプラグインと名前が衝突しないか
翻訳可能な作りになっているか
外部サービスやデータ収集について説明できているか
ソースコードと画像のライセンスを説明できるか
開発用ファイルや秘密情報がZIPに紛れ込んでいないか
AIは、もっともらしい答えを生成しても、そのコードが実際のWordPress環境で動くことや、最新のガイドラインに適合することを保証しません。
今回の開発でも、AIは強力な共同作業者でした。しかし、完成条件を定義し、検査結果を読み、公開してよいかを判断する役割は人に残りました。
AIによって短くなったのは「コードを書く時間」です。企画、品質保証、説明責任、審査対応、公開後の保守までが消えたわけではありません。
実際に直面した7つの壁
壁1：アイデアを仕様に落とす
「ギターコード譜を表示したい」という要望だけでは、実装は決まりません。
歌詞とコードの入力方法、運指データの持ち方、画面幅が狭いときの表示、プラグインを無効化したときの挙動などを決める必要があります。将来追加したい機能と、初回公開に本当に必要な機能も分けなければなりません。
AIへ依頼する前に、利用者、課題、基本操作、保存内容、対象環境、受入条件を文章にしました。仕様が曖昧なまま生成を繰り返すと、その場しのぎの変更が積み重なり、後から全体を理解できなくなります。
壁2：Gutenberg上で正しく動かす
ブロックは、公開画面だけ整えば完成ではありません。
ブロック一覧への登録、挿入、選択、設定変更、保存、再読込、複製、削除を確認します。編集画面と公開画面で表示が大きく食い違わないことも重要です。
さらに、ブロック属性として何を保存するか、表示をJavaScriptだけに依存させるか、PHPで描画するかによって、互換性やプラグイン無効化時の挙動が変わります。画面の見栄えとデータ設計を同時に考える必要がありました。
壁3：セキュリティとコード品質を確認する
AIが生成したコードに、セキュリティ上の問題がないとは限りません。
入力値のサニタイズ、出力時のエスケープ、管理操作の権限確認、必要に応じたnonce検証など、データの入口と出口を確認します。今回の無料版では、外部通信、利用状況の追跡、独自の個人データ保存を行わない設計にし、その事実をコードと公開資料の両方で確認しました。
ライセンスも重要です。プラグイン本体だけでなく、画像、フォント、ライブラリなど、配布ZIPに含まれるものを説明できなければなりません。
壁4：Plugin Checkを通す
公式のPlugin Checkは、WordPress.orgで問題になりやすい項目を確認するうえで重要な道具です。
今回の申請候補は、WordPress 7.0.2／PHP 8.3環境でPlugin Checkのエラー0を確認しました。加えて、WordPress Coding Standards 3.4.1でエラー0・警告0、PHP 7.4で全PHPファイルの構文エラー0を確認しています。
ただし、検査ツールが合格しても、実際の操作や表示が正しいとは限りません。自動検査と手動確認は別物として扱いました。
壁5：公開用ZIPと掲載画像を準備する
開発フォルダーをそのままZIPにすればよいわけではありません。
ZIPの最上位ディレクトリ、ファイル名、バージョン、`readme.txt`、ライセンス、不要な開発ファイルの除外を確認します。APIキー、認証情報、テストデータなどが混入していないことも必須です。
WordPress.org掲載用には、バナー、アイコン、スクリーンショットも準備しました。画像寸法やファイル名には規則があり、プラグイン本体とは別にSVNの`assets/`へ置きます。
壁6：名称・スラッグの審査指摘に対応する
今回、初回申請時の名称は Guitar Diagram Block、希望スラッグは`guitar-diagram-block`でした。
しかし、一般的すぎるため、作者またはブランドを含む固有の名称へ変更するよう案内を受けました。そこで、名称を CyberForest Guitar Chord Sheet、希望スラッグを`cyberforest-guitar-chord-sheet`へ変更し、バージョン`0.1.1`の修正版ZIPを提出しました。
ここで重要だったのは、別の新規申請を作るのではなく、既存申請へ修正版をアップロードし、同じメールスレッドで簡潔に返信したことです。
名称は見た目の問題だけではありません。プラグインヘッダー、Text Domain、`readme.txt`、フォルダー名、翻訳、公開URLなどへ影響します。申請前に既存製品、商標、WordPress.org内での重複を調べておくべきでした。
壁7：承認後にSVNで正式公開する
審査承認はゴールではありません。承認後、WordPress.orgから提供されたSVNリポジトリへファイルを登録して、初めて一般利用者がインストールできる状態になります。
WordPress.orgのSVNには主に次の3つがあります。
`trunk/`: 次に公開する本体
`tags/<バージョン>/`: 公開バージョンの固定コピー
`assets/`: バナー、アイコン、スクリーンショット
今回の初回公開では、`trunk/`、`tags/0.1.1/`、`assets/`を登録しました。
SVNは日常の開発場所ではなく、完成したリリースを配布する場所として扱っています。開発中のコード、Pro版、テスト資料、ZIP、Git管理ファイルを誤って含めないよう、コミット前に差分を確認しました。
AIだけでは完結しなかった作業
今回の経験で特に重要だったのは、AIに任せられる作業と、人が責任を持つ作業を分けることでした。
AIが役立った作業
要望から仕様案を作る
ファイル構成や実装方針を比較する
PHP、JavaScript、CSSの下書きを作る
エラーの原因候補を整理する
テスト観点を洗い出す
`readme.txt`や説明文の原案を作る
チェックリストや手順書を整える
修正による影響範囲を調べる
これらは、白紙から考える時間を大きく短縮してくれました。
人が確認・判断した作業
本当に解決すべき利用者の課題
無料版に含める機能とPro版へ分ける機能
実際のWordPress環境での操作と表示
検査結果を公開可能と判断してよいか
名称、ブランド、商標、スラッグ
コード、画像、依存物のライセンス
申請規約への同意
審査チームへの返信
SVNへの公開コミット
公開後のサポートと更新
とりわけ、WordPress.orgへの申請と公開は外部へ影響する操作です。アカウント所有者が内容を確認し、規約へ同意したうえで進めました。
AIの回答より、検証結果を優先する
AIが「問題ありません」と答えても、それは検査結果ではありません。
実際のWordPressで操作し、Plugin Checkや構文検査を実行し、ZIPの中身を確認し、公開後のダウンロードファイルまで調べる。この積み重ねによって、初めて第三者へ配布できる確度が上がります。
AIを使うほど、人が何を確認したかを記録することが重要になります。生成されたコードの出所ではなく、最終的な製品について説明できる状態を作る必要があるからです。
初めて申請する人が公開前に確認すべきこと
これからWordPress.orgへ初めて申請する場合、少なくとも次の項目を確認することをおすすめします。
企画と名称
誰のどんな問題を解決するか説明できる
既存プラグインとの差を説明できる
プラグイン単体で役立つ
名称が一般的すぎず、作者やブランドを識別できる
WordPress.org内の類似名と商標を確認した
希望スラッグを長期的に使える
動作と互換性
インストールと有効化が成功する
主要機能を実際に操作した
保存後の再読込でも内容が維持される
無効化・削除時の挙動を確認した
対応するWordPressとPHPのバージョンを確認した
エラー表示やデバッグログを確認した
セキュリティとプライバシー
入力値を用途に応じてサニタイズしている
出力箇所に応じてエスケープしている
管理操作の権限を確認している
必要な操作でnonceを検証している
外部通信、トラッキング、保存データを把握している
個人情報や認証情報がコードとZIPに含まれていない
配布物
プラグインヘッダーの情報が正しい
本体バージョンと`readme.txt`のStable tagが一致している
Text Domainとスラッグの整合を確認した
`readme.txt`をバリデーターで確認した
ライセンスと第三者素材の条件を確認した
ZIPの最上位に正しいプラグインフォルダーがある
テスト、開発依存、設定ファイル、一時ファイルを除外した
Plugin Checkを実行した
申請と公開後の運用
WordPress.orgの登録メールを継続的に確認できる
`plugins@wordpress.org`からのメールを受信できる
審査指摘に対応する担当者を決めた
サポートフォーラムの確認方法を決めた
脆弱性や互換性問題が発生した場合の更新方法を決めた
SVNとGitの役割を分けて理解している
この一覧は、2026年8月時点の実体験を基にした概要です。WordPress.orgのガイドラインや申請画面は変更される可能性があります。実際に提出する日には、必ず公式のDetailed Plugin Guidelines、Plugin Developer FAQ、Plugin Checkの最新情報を確認してください。
公開して分かったこと
1. 「動くもの」と「配布できる製品」は違う
手元で機能が動いた段階は、開発工程の途中です。
第三者へ配布するには、対象環境、セキュリティ、ライセンス、説明、更新方法、問い合わせ対応まで考える必要があります。公開作業を経験すると、コード以外の部分が製品の信頼を支えていることが分かります。
2. 申請前の名称検討は軽視できない
今回の具体的な学びは、一般的な機能名だけでは審査で変更を求められる可能性があることです。
申請後に名称を変えると、ヘッダー、フォルダー、Text Domain、説明、画像、ZIPなど、広い範囲を再確認することになります。ブランドを含む固有の名称を早い段階で検討する方が効率的です。
3. 自動検査は重要だが、万能ではない
Plugin Check、コーディング規約、PHP構文などの自動検査は、見落としを減らしてくれます。一方、編集画面の操作感、スマートフォン表示、説明の分かりやすさは、人が実際に確認する必要があります。
合格という一つの表示だけでなく、何を検査し、何が検査対象外なのかを理解することが重要です。
4. 公開後から保守が始まる
WordPress本体、PHP、ブラウザー、テーマは更新されます。公開時に正常でも、将来の環境で同じように動くとは限りません。
サポートフォーラム、互換性、脆弱性、利用者からの要望を確認し、必要に応じて更新を提供する責任があります。公開本数を増やすほど、保守対象も増えていきます。
5. AI時代ほど、実体験の記録に価値がある
コードの例はAIがすぐに生成できます。しかし、どんな検査を行い、どんな指摘を受け、なぜ修正し、公開後に何を確認したかという記録は、実際に取り組まなければ得られません。
AIを使うこと自体よりも、AIをどの工程で使い、どの工程を人が検証したかを説明できることが、これからの開発ノウハウとして重要になると考えています。
詳細な手順とテンプレートについて
この記事では、AIを使ったWordPressプラグイン開発からWordPress.org公開までの全体像と、実際に直面した7つの壁を紹介しました。
要点をまとめると、次のとおりです。
AIによって実装は速くできる
その前に、課題と仕様を明確にする必要がある
自動生成されたコードにも人による検証が必要
Plugin Checkだけでなく、実機操作、セキュリティ、ライセンス、ZIP構成を確認する
名称とスラッグは申請前に慎重に決める
審査承認後も、SVN公開と公開後確認が残っている
公開した時点から保守が始まる
初めて取り組む場合、難しいのは情報がないことより、必要な情報が複数の公式ページや開発工程に分かれていることです。
そこで今後、今回の実務で使用した形式を整理し、次のようなテンプレートと詳細手順をまとめる予定です。
プラグイン企画書
要件定義と受入条件
無料版と有料版の機能整理表
開発・検査用チェックリスト
`readme.txt`の雛形と記入例
Plugin Check、構文、セキュリティの確認表
WordPress.org申請フォームの入力例
審査指摘を受けた場合の対応例
SVN初回公開とバージョン更新の手順
公開後の確認・保守チェックリスト
単に情報の続きを有料にするのではなく、実際の作業時間と見落としを減らせる資料として提供する方針です。
何を作るか決められない
AIでコードは作れたが、安全性を確認できない
Plugin Checkの指摘を直せない
WordPress.orgへの申請方法が分からない
審査メールへどう対応すればよいか分からない
SVNでの公開・更新が難しい
無料版から有料版へどうつなげるか悩んでいる
公式参考情報
WordPress Plugin Developer Handbook
https://developer.wordpress.org/plugins/Detailed Plugin Guidelines
https://developer.wordpress.org/plugins/wordpress-org/detailed-plugin-guidelines/Plugin Check
https://wordpress.org/plugins/plugin-check/Readme Validator
https://wordpress.org/plugins/developers/readme-validator/Using Subversion
https://developer.wordpress.org/plugins/wordpress-org/how-to-use-subversion/
※本記事は2026年8月時点の実体験と公式情報を基にしています。申請前には、必ず最新の公式ガイドラインをご確認ください。
#WordPress #WordPressプラグイン #プラグイン開発 #生成AI #AI開発 #個人開発 #Gutenberg #バイブコーディング #Web開発 #プログラミング
