Chrome 拡張をストア公開までに見たもの（FyreFighter の例）

結論

Chrome 拡張 FyreFighter をストア公開する際、実装より先に整えたのは権限の説明とプライバシー文言です。拡張機能は見慣れない権限を求めるだけで警戒されやすく、ストア審査でも「なぜその権限が必要か」を短く答えられる状態が通過率に効きます。

1. manifest

使わない host permission は付けません。権限を一つ増やすごとに審査の質問も増えるため、必要最小限に絞りました。審査で聞かれたときに、どの権限がどの機能に対応するかを一覧で説明できるようにしています。manifest を読めば機能と権限の対応が追える状態を目指しました。

2. プライバシー

拡張と kimura512.dev は別プロダクトですが、問い合わせ先は info@kimura512.dev に統一しています。利用者がどこに連絡すればよいか迷わないことが、信頼の土台になります。LLM に送信するデータがある場合は、何を送り何を送らないかを、ストア説明とプライバシー文の両方に平易な言葉で書きました。

3. ストア文面

スクリーンショットは実際の UI だけを使い、加工や誇張はしません。できないことを「できる」と書くと、レビューや低評価につながります。英語の説明も日本語と同じ意味に揃え、片方だけ別の内容にならないよう読み比べています。

4. 更新

段階的公開とバージョンタグを使い、問題が出たときに前のバージョンへ戻しやすくしています。月1更新は約束せず、セキュリティに関わる修正のときだけ出すと明記しました。更新頻度を先に決めすぎると、無理なリリースが増えて品質が落ちやすくなります。

5. サイトとの関係

Works から拡張の本番 URL へリンクしています。kimura512.dev 側の広告はブログ記事に限定し、拡張内には AdSense を入れません。拡張の中で広告を出すと、ストアの印象とサイト側の運用が混ざり、説明が難しくなります。

6. レビュー返信

権限を怖がるレビューには、データが売られない旨を短く返信します。感情的な表現には直接反論せず、事実と対応方法だけを簡潔に書きます。返信は短く丁寧にし、他の利用者にも読みやすい形にしています。

7. パッケージング

zip 提出前に manifest の version を上げ、変更点をストアの「新機能」欄に1行書きます。審査待ち中に権限を増やすと差し戻しが増えるため、権限追加はまとめて行います。提出物と説明文の内容が一致しているか、提出前に読み比べます。

8. kimura512.dev との関係

拡張のランディングは専用サブドメイン、運営者情報は About に集約しています。ストアのサポート URL とサイトの Contact が矛盾しないよう、メールアドレスを一本化しました。Web サイト審査と拡張審査は別ですが、運営者の同一性は About で示しています。

初回申請では、スクリーンショットと説明文の文言がずれているだけで差し戻しになることもありました。画面に写っているボタンと、ストア説明の動詞を揃えてから再提出したら通りました。審査で聞かれた内容は、だいたい「この権限で何をするか」「ユーザーデータをどこに送るか」の二点に集まりました。manifest とストア説明に同じことを書いておけば、返答は短く済みます。実装を変えたら、説明文とスクリーンショットも同じタイミングで更新するルールにしています。

バージョンを上げるたびに、権限の増減を changelog に一行書きます。自分が半年前に何を考えていたか忘れがちなので、ストア審査用のメモとしても使っています。

公開後に権限を足す更新は、既存ユーザーへの説明が必要になるので、初回申請時点で必要最小限に抑える方が楽でした。ストアの「単一用途」説明とも矛盾しないよう、機能追加のたびに一文ずつ更新しています。審査用の文章は別ファイルにコピーせず、ストアに載せた文言を正とします。

まとめ

権限・データの流れ・問い合わせ先を揃えてから申請しました。この三点が説明できれば、審査でも利用者への説明でも大きく迷いません。

補足

Q. 審査は何日？

1〜3営業日が多い印象ですが、常に同じ日数で終わるとは限りません。権限追加時は再審査になるため、余裕を持ったスケジュールで計画します。

Q. サイト必須？

説明可能な URL があると、審査側が機能を確かめやすくなります。サポート先と運営者情報が辿れる導線があることが重要です。