Chrome拡張を公開前に落とさない確認リスト
Chrome拡張は、手元で動くところまでは意外と早い。けれど公開前になると、manifest.json の権限、ストア説明文、プライバシー項目、審査で見られる禁止事項が一気に出てくる。ここを曖昧にしたまま進めると、機能は完成しているのに公開直前で直し込みが増える。
この記事では、Chrome拡張を初めて公開する前に見る確認リストをまとめる。主役は本の紹介ではなく、公開前に落とし穴を減らすための実務チェックだ。Manifest V3で小さな個人ツールを作る前提で、設計、権限、動作確認、ストア提出前の見直しまでを順番に整理する。
まず拡張の役割を1文に絞る
公開前に最初に見るのはコード量ではなく、拡張の役割が1文で言えるかどうかだ。たとえば「開いているページのタイトルとURLを1クリックで整形コピーする」なら、必要な権限はかなり絞れる。逆に「ブラウザ作業を便利にする」だと、どのページに触るのか、保存するのか、外部通信するのかが曖昧になり、審査前の説明もぼやける。
最初に書くメモは、この4行で十分だ。
- 何をする拡張か
- どのページやタブに触るか
- どのデータを保存するか
- 外部へ送信する情報があるか
最初に入れるものと後回しにするもの
初日に入れるのは、拡張の中核機能、最小権限、手動テストの3つだけでよい。見た目の作り込み、ショートカット、設定画面、同期、課金、分析タグは後回しにする。公開前チェックで一番効くのは、機能を増やすことではなく「なぜその権限が必要なのか」を説明できる状態にすることだ。
判断に迷う時は、古いブログ記事より先に公式入口へ戻る。Manifest V3ではバックグラウンド処理や権限の考え方が変わっているため、昔のManifest V2前提の手順を混ぜると、手元では動いても公開準備で詰まりやすい。
今回の確認入口は次のように絞る。
- Chrome Extensions documentation: 拡張機能の権限と公開前確認を確認する
- Chrome Web Store Program Policies: 公開時の禁止事項を確認する
最初の日に見る順番は、だいたい次のように分けると扱いやすい。
| 分類 | 初日にやること | 後回しでよいこと |
|---|---|---|
| manifest | name、description、permissions、host_permissionsを最小化する |
便利そうな権限を先に広く入れる |
| 画面 | popupかcontent scriptかを決める | 設定画面や多機能メニューを作り込む |
| 確認 | ローカル読み込みで主要操作を手動テストする | 最初から自動テストやCIを組む |
| 公開準備 | ストア説明文と権限理由を下書きする | アイコン差分や宣伝文を先に詰める |
よくある失敗は「動く」と「公開できる」を混ぜること
Chrome拡張で起きやすい失敗は、ローカルで動いた状態を公開準備完了だと思ってしまうことだ。開発者モードで読み込めた、popupが開いた、content scriptが動いた。ここまでは動作確認であって、まだストア提出の確認ではない。
公開前には、少なくとも次の境目を分けて見る。
- ローカルで読み込める
- 主要なページで動く
- 余計な権限を要求していない
- ストア説明文と実際の動きが一致している
- プライバシー項目に矛盾がない
ここを混ぜると、審査直前に「なぜこの権限が必要なのか」「どのデータを扱うのか」を説明できなくなる。コードを直すより、説明と実装のズレを直すほうが時間を取られることがある。
公開前に小さく試す3ステップ
私なら、公開前に次の順番で確認する。
manifest.jsonの権限を1つずつ説明する- Chromeの拡張機能ページで再読み込みし、主要操作を3回試す
- ストア説明文、スクリーンショット、実際の挙動を照合する
この3つだけでも、公開直前の事故はかなり減る。特に権限は、後から増やすより先に減らすほうが楽だ。activeTabで足りるのか、特定ドメインのhost_permissionsが必要なのか、全サイト権限が本当に必要なのかを早めに分ける。
提出直前に見るべきなのは、コードの完成度だけではない。ユーザーに見せる説明と、拡張が実際に行う処理が一致しているかだ。ここが揃っていると、ストア提出の文章も短く書ける。
判断基準は「審査で説明できるか」に置く
Chrome拡張の公開前チェックでは、数字より説明可能性を優先する。ファイル数、行数、機能数が多くても、権限理由やデータ取り扱いを説明できなければ公開前の不安は残る。
見るべき基準は次の3つだ。
- 権限: 要求している権限を機能単位で説明できるか
- データ: 保存、送信、取得する情報を1行で説明できるか
- 表示: ストア説明文とスクリーンショットが実際の機能を盛っていないか
たとえばURLをコピーするだけの拡張なら、閲覧履歴全体へ触れるような説明は不要だ。ページ本文を読む拡張なら、どのタイミングで何を読み、どこへ送るのかを明確にする。ここを先に言語化すると、実装の削りどころも見える。
小さく実測する例
実測は大げさでなくていい。提出前の1日だけでも、ローカル読み込み、主要操作、権限確認、説明文確認を1セットで記録する。
私なら、確認メモを次のように残す。
extension: 拡張名
core_action: 1クリックで実行する主機能
permissions: activeTab, storage など
host_permissions: 必要なドメインだけ
manual_test: popup / content script / options の確認結果
store_text_gap: 説明文と実際の動きのズレ
stop_reason: 公開前に止める理由があれば1行
このメモがあると、提出直前に迷った時の戻り道になる。特にstore_text_gapは重要だ。ストア説明文に「自動で整理します」と書いているのに、実際はユーザーが毎回ボタンを押す必要があるなら、その差分は公開前に直す。
提出直前に見直す小さな基準
提出直前は、機能追加を止めて差分確認に切り替える。最後に便利機能を足すと、権限や説明文も一緒に変わる。Chrome Web Storeへ出す前は、増やすより削る時間にしたほうがいい。
まず、使っていない権限を消す。次に、スクリーンショットで見せている機能が現在のビルドに残っているかを見る。最後に、プライバシー項目と実装を照合する。保存していないデータを保存しているように書くのも、保存しているのに書かないのも危ない。
止める条件も短くしておく。たとえば「説明できない権限が1つでもあれば提出しない」「外部送信があるなら送信先と目的を書けるまで止める」「ストア説明文と実装がズレたら画像より本文を先に直す」。このくらい短いほうが、公開直前でも迷わず止まれる。
実践チェックリスト
今日見る項目は、このくらいに絞る。
- 拡張の役割を1文で言える
permissionsとhost_permissionsを1つずつ説明できる- ローカル読み込み後、主要操作を3回試した
- ストア説明文と実際の挙動が一致している
- スクリーンショットが現在の画面とズレていない
- 保存、取得、送信するデータを説明できる
- 使っていない権限や機能を削った
- 審査前に止める条件を1行で書いた
このチェックで1つでも曖昧なら、機能を増やす前に範囲を狭くする。最初から多機能を目指すより、1つの用途で説明しきれる拡張にしたほうが公開前の不安は減る。
特に外部送信、アカウント連携、ページ本文の取得、クリップボード操作のようにユーザーの情報へ触れる機能は、便利さより停止条件を優先する。自分が眠い時でも同じ判断で止まれるくらい、条件を短く書いておく。
この短い停止条件があるだけで、あとから道具を足す時の判断が楽になる。新しいツールを入れるたびに迷うのではなく、最初に決めた境界へ戻って確認できるからだ。
よくある質問
最初から全部そろえるべきですか？
最初は1つの用途で十分だ。popup、content script、options、同期、分析を一気に入れるより、主機能を1つに絞って権限理由を説明できる状態にする。
権限は少なければ少ないほどよいですか？
少なければよいというより、機能に対して説明できる範囲にする。必要な権限まで削ると動かなくなるので、機能、権限、説明文が一致しているかを見る。
本まで読む必要がありますか？
記事だけで今日の判断はできる。背景、細かい手順、失敗例をまとめて追いたい場合だけ本を見ればいい。
まとめ
- 最初から全部を整えようとしない
- 拡張の役割を1文に絞る
- 権限とデータの扱いを説明できる状態にする
- ローカル動作とストア提出の確認を分ける
- 説明文、スクリーンショット、実装を照合する
- 提出直前は機能追加より削る時間にする
今回の元になったテーマは、Kindle本『副業会社員のChrome拡張開発入門』にもまとめている。この記事では最初の判断軸に絞った。背景、細かい手順、失敗例を順番に追いたい人には本の方が向いている。今日のチェックだけで足りる人はこの記事だけで十分だ。
※リンクには広告属性を付けています。価格、レビュー数、ランキングなどの変動情報は本文では扱いません。