はじめに
最近、Fiviaというプロダクトを個人開発しました。
一言でいうと「アートボードに画像を集めて、MCP経由でAIに渡すツール」です。
構想はシンプルで、こういう流れです。
- Chrome拡張機能でWeb上の画像をアートボードに保存する
- MCP経由でAIがそのアートボードを読み込む
- ビジュアルのコンテキストをそのままAIに渡して作業できる
この記事は、その拡張機能をChrome Web Storeに公開するまでの話です。
GW1週間で、Webサイト・拡張機能・MCPを全部作った
拡張機能の話をする前に、Fivia全体の開発背景を少し話しておきます。
FiviaのWebサイト・Chrome拡張機能・MCPサーバーを作ったのは、今年のゴールデンウィークです。
休みを全部ぶつけて、約1週間で3つを同時に作り上げました。
使ったのは Codex と Claude Code。2つとも上限いっぱいまで使い切るくらい、ガンガン回しました。
開発フローはシンプルで、まずドキュメントを書いて要件を固め、それをそのままAIに渡して実装させるというものです。拡張機能は、自分でコードを書かず、全部AIに作ってもらいました。
「AIなしだったらどうだったか？」と聞かれたら、ゴールデンウィーク丸々使っても、たぶん完成しなかったと思います。それくらい、今回の開発速度はAIありきで成立していました。
Chrome拡張機能の技術スタック
技術的な話を少しだけ。
| 項目 | 内容 |
|---|---|
| 対応バージョン | Chrome Manifest V3 |
| 言語 | TypeScript |
| UI | React 19 |
| ビルド | esbuild |
| 認証 | Google OAuth（PKCE） |
| バックエンド | Supabase |
機能は大きく3つです。
- 右クリックメニュー：Web上の画像を右クリック → アートボードを選ぶ → 保存完了
- ポップアップ：拡張機能アイコンをクリックするとログイン状態の確認やアートボード一覧へのアクセスができる
- アートボード作成：拡張機能から直接新しいアートボードを作れる
Manifest V3 の制約上、Service Worker（background.ts）内では Supabase SDK が使えません。
そのため、SupabaseへのアクセスはすべてWeb App API経由のfetchに統一しました。認証は、chrome.identity.launchWebAuthFlow でPKCEフローを実装し、セッションは chrome.storage.local に保存しています。
Chrome拡張機能を公開するために必要なもの
Chrome Web Storeに出すためには、コード以外にも以下が必要になります。
- Chrome Web Store Developer アカウント（登録料 $5）
- 拡張機能のアイコン（16・32・48・128px）
- スクリーンショット（最低1枚）
- 説明文（英語・日本語など）
- プライバシーポリシー（公開URLが必要）
- 単一用途の説明（拡張機能が何の目的に特化しているか）
- 権限が必要な理由（使用する権限ごとに用途を明示）
審査に何度も落とされた
開発よりも、公開の方が手こずりました。何度もリジェクトされ、修正して出してまた落とされる、というサイクルを繰り返しました。
審査自体のスピードは速く、出してから1〜2日で結果が返ってきます。ただ、ゴールデンウィーク明けから公開まで10日程度かかりました。最終的に審査を通過したのは 2026年5月11日、バージョン 0.0.2 です。
一番の原因：環境変数のミス
リジェクトの主な原因は、環境変数の設定ミスでした。
SupabaseのURLとAnon Keyは、開発環境と本番環境で別々に持っています。問題は、ZIPファイルにまとめる段階で開発用のキーを設定したままにしていたことでした。
# こうなるべきところが
SUPABASE_ANON_KEY=本番用のkey
# これになっていた
SUPABASE_ANON_KEY=開発用のkey
当然、本番環境ではAPIが動きません。審査で「動作しません」と返されてリジェクトされ、原因を見つけるのに時間がかかりました。
原因がわかりづらかったのは、ZIPファイルの中身を外から確認できないからです。どのキーがビルドに入っているのかをパッと確認する手段がなく、問題の特定に時間がかかりました。
仕様書にもその旨は記載していたので、AIが書いたコードを信頼していました。ここはAI開発の盲点で、実行環境の状態は自分で確認するしかない部分です。
ビルドスクリプトで本番用キーに切り替わるよう明示的に管理するようにして、ようやく解消しました。
その他の指摘ポイント
- 権限の説明が不足している（なぜその権限が必要かを明示する必要がある）
- プライバシーポリシーとデータ利用の説明が合っていない
特に データの取り扱い説明 は丁寧に書く必要があります。Fiviaの場合、以下を明記しました。
送信するデータ：
- 画像URL
- 画像が掲載されていたページURL（取得できる場合）
- ページタイトルまたはalt（取得できる場合）
- 認証用JWT
収集しないデータ：
- 閲覧履歴全体
- ユーザーが保存操作をしていないページの内容
- 画像ファイル本体（URLのみ保存）
まとめ
現在はアルファ版として一般公開中で、ちょいちょい使ってくれている人かもしれません。「Googleの中の人が使ってくれてるくらいのレベルかも」という感覚ですが、公開できたこと自体に手応えを感じています。
同じように拡張機能を公開しようとしている人に向けて、特に伝えたいことを最後に書いておきます。
Chrome Web Store Developer アカウントには登録料がかかります（$5）。
「よし、公開するぞ！」とアカウントを作ろうとした段階で初めてお金が必要なことに気づく、というパターンは多いと思います。大きな金額ではないですが、事前に把握しておきましょう。
AIを使えば、個人開発者でも短期間で拡張機能を作れる時代になりました。ただ、「動くコードがある」と「Web Storeに公開できる」の間には、意外と細かい壁があります。この記事がその壁を乗り越える参考になれば嬉しいです。
Fiviaは fivia.dev からアルファ版を試せます。
最後まで読んでくださってありがとうございます！
普段はデザインやフロントエンドを中心にQiitaで記事を投稿しているので、ぜひQiitaのフォローとX(Twitter)のフォローをお願いします。