AIでChrome拡張を作る手順｜企画からChrome Web Store公開まで
プロンプトを一つ渡せば拡張ができて公開まで進む、という作り方にはなりませんでした。Chrome拡張を8本公開するまでに固まった、困りごとの定義からMVP、AIへの分割依頼、権限の確認、ストア素材、審査までの進め方を順番に書きます。
AIを使うと、Chrome拡張の実装はかなり速くなります。ただ、プロンプトを一つ渡せば拡張ができて公開まで進む、という作り方にはなりませんでした。これまでに8本を公開してみて分かったのは、AIに任せられる部分と、人間が決めるしかない部分がはっきり分かれていることです。
この記事では、企画からChrome Web Storeの公開までを、実際にやっている順番で書きます。使っているのはChatGPTとClaude Codeです。ChatGPTには作りたいものの整理を、Claude Codeにはプロジェクトを読ませて実装を任せています。
全体の流れ
困りごとを決める
↓
MVPを絞る
↓
拡張の構成を決める
↓
AIに小さく実装させる
↓
Chromeで試す
↓
権限・通信・保存先を確認する
↓
ストア用の素材を作る
↓
申請・審査
↓
修正して公開9つのうち、AIがほとんどを引き受けるのは4番目だけです。残りは人間が決めるか、人間が確認します。
1. 何が面倒なのかを、一文にする
最初にやるのは、コードを書かせることではなく、困りごとを一文にすることです。
複数のWebページから選択した文章を集めて、最後にまとめてコピーしたい。
これはCopy & Prepという拡張の出発点になった一文です。逆に、こう書き出したときはうまくいきませんでした。
情報収集を便利にする高機能なChrome拡張を作りたい。
抽象的に頼むと、AIはタグ、クラウド同期、AI要約、アカウント、履歴管理といったものを足してきます。個々の提案が間違っているわけではありません。ただ、頼んでいない機能が増えるほど、自分で全体を追えなくなります。問題を小さく定義するのが、最初の仕事です。
2. やらないことを先に決める
一文が決まったら、AIに仕様を整理させます。このとき「必要なもの」より「やらないこと」のほうを先に固めます。
| 入れるもの | 入れないもの |
|---|---|
| 選んだ文章を追加する | ログイン |
| 複数件を保持する | クラウド同期 |
| 並べ替える | AI要約 |
| 改行を整える | 外部通信 |
| まとめてコピーする |
右の列を書いておくと、あとの会話でAIが同じ提案を持ってきたときに、その場で判断せずに済みます。実際にできあがったCopy & Prepも、この左の列のままです。整形は入れましたが、変換前と変換後を並べて見せてから適用する形にしました。文章を勝手に書き換える道具にはしたくなかったためです。この一文が指していた作業そのものは、複数のWebページから文章を集めてまとめてコピーする方法にまとめています。
3. 構成を決めてから頼む
AIに「Chrome拡張を作って」と頼む前に、どの部品が要るのかを自分で把握しておきます。細部まで理解している必要はなく、この程度で足ります。
manifest.json
↓
content script ←→ Webページ
↓
popup / side panel
↓
background / service worker
↓
chrome.storage.localどこに何を置くかを先に決めておくと、AIの実装が想定と違う場所に入ったときに気づけます。それぞれの部品が何をしているかは、Chrome拡張はどう動くのかに書きました。
4. 一度に全部を頼まない
実装は次のように分けて頼みます。
- 選択した文章を取得する
- storageへ保存する
- 一覧を表示する
- 並べ替える
- まとめてコピーする
AIエージェントのコンテキストウィンドウは大きくなりましたが、無限ではありません。プロジェクトが育つほど、読むファイル、仕様、過去の判断、依存関係が増えていきます。一度に広い範囲を任せると、個々の修正は動いても、全体としてまとまりを失うことがあります。
Chrome拡張がこの作り方に向いているのは、必要な作業範囲を小さく保ちやすいからです。ファイル数が少なく、機能の境界がはっきりしていて、多くの場合サーバーが要りません。AIにとっても、人間にとっても、全体を追いやすい大きさに収まります。
5. 早い段階でChromeに読み込む
chrome://extensions を開き、デベロッパーモードを有効にして、「パッケージ化されていない拡張機能を読み込む」でフォルダを指定します。
完成してから試すのではなく、少し作るたびに読み込んで、自分で使います。
少し作る → Chromeで試す → 違和感を見つける → AIに直させるコードを読んでいるだけでは分からないことが、ここで出てきます。ボタンの位置、確認が出る間合い、何度も繰り返したときの煩わしさ。どれも動作としては正しいので、テストでは落ちません。
6. 動くことと、公開してよいことは別
ここが、この記事でいちばん書いておきたい部分です。AIが動くコードを書いたからといって、その設計をそのまま採用する必要はありません。実装が一段落したら、次を自分で見ます。
permissionsに、使っていない権限が入っていないかhost_permissionsの範囲が、必要より広くなっていないか- 外部への通信が増えていないか
- 何を、どこに保存しているか
- ページから読み取っている情報の範囲
- 入力欄の値にどこまで触れているか
- 使っていないライブラリが残っていないか
権限は実装の都合で決まる設定項目ではなく、インストール画面で利用者にそのまま表示されるものです。何がどう表示されるかは、Chrome拡張の権限表示の読み方に書きました。作る側にとっては、そこに出る文言が自分の設計の説明そのものになります。
7. テストが通っても、使いやすいとは限らない
確認するのは、正常系、データが無いとき、大量にあるとき、ページを移動したとき、ブラウザを再起動したとき、設定を変えたとき、権限が足りないときあたりです。Playwrightのような道具も使えます。
ただ、自動テストが通ることと、普通に使えることは別です。最後は自分で触ります。
8. コード以外の仕事が始まる
ストアに出す段階で必要になるものは、コードではありません。
製品名、アイコン、スクリーンショット、短い説明、詳細な説明、プライバシーの申告、各権限を使う理由、Webサイト、サポートページ。
文章や素材づくりはAIがかなり手伝えます。ただし、申告の内容は実装と一致していなければなりません。ここを任せきりにすると、実装より少し広い説明や、少し親切すぎる説明ができあがります。申告は最後に自分でmanifest.jsonと突き合わせます。
説明文の書き方で審査に落ちることもあります。自分の場合は、キーワードを詰め込んだ説明文がキーワードスパムと判定されて却下されました。コードは変えずに、文章だけを直して通っています。
9. 申請する
ZIPを作って、Developer Dashboardから提出します。審査で見られているのは「AIで作ったかどうか」ではなく、この拡張が実際に何をするのかです。修正を求められることも普通にあります。
申請の画面には、コード以外の判断がいくつも混ざっています。自分は事業者情報の申告で選択を誤り、自宅の住所がストアに公開されていました。AIは、この画面の中までは見てくれません。
10. 公開したあとに見るもの
公開は終わりではありません。インストールされたか、実際に使われたか、不具合の報告はないか、説明で意図が伝わっているか。必要なら直して、また申請します。
AIによって、作るコストは下がりました。その結果、残った仕事のほうが重くなっています。何を作るのか。公開してよいのか。使われているのか。
AIがChrome拡張を作ってくれるわけではありません。小さな問題を人間が定義して、AIと一緒に短いサイクルで道具に変えていく。いまのところ、その進め方がいちばん続いています。