Chrome拡張機能の審査で注意したいポイント：権限・プライバシー・説明文の落とし穴
前回の記事「Chrome拡張機能をChrome Web Storeへ公開する手順：登録・ZIPアップロード・審査送信」では、Developer DashboardへZIPをアップロードし、ストア掲載情報やPrivacy practicesを入力して審査へ送る流れを整理しました。
Chrome Web Storeへ送信した拡張機能は、Googleの審査を通ります。
審査では、拡張機能がChrome Web Store Developer Program Policiesに沿っているか、ユーザーに誤解を与えないか、必要以上のデータや権限を扱っていないかが確認されます。
この記事では、初めて公開する人向けに、審査で注意したいポイントを整理します。
特に、広すぎる権限、Privacy practicesの説明不足、ストア説明文と実際の動作の不一致、難読化されたコードは、提出前に見直しておきたい項目です。
Chrome Web Storeの審査基準やDeveloper Dashboardの項目は変更される可能性があります。実際に提出する前には、必ずGoogle公式情報とDashboard上の最新表示も確認してください。
審査で見られること
Chrome Web Storeの審査は、単にZIPがアップロードできるかを確認するだけではありません。
ユーザーが安心してインストールできる拡張機能か、ストア上の説明と実際の動作が一致しているか、要求している権限に妥当な理由があるかを確認します。
主に見られる観点は、次の通りです。
| 観点 | 確認したいこと |
|---|---|
| 権限 | 機能に必要な最小限の permissions と host_permissions になっているか |
| プライバシー | 収集するデータ、保存場所、送信先、利用目的を正しく開示しているか |
| 掲載情報 | タイトル、説明文、スクリーンショット、アイコンが実際の機能と一致しているか |
| コード | 難読化や隠れた動作がなく、提出されたコードから機能が確認できるか |
| ユーザー保護 | 不正なデータ収集、詐欺的な動作、誤解を招く表現がないか |
個人開発の小さな拡張機能でも、これらの観点は同じです。
「自分用に作った小さなツールだから大丈夫」と考えるよりも、「知らない人がインストールしても、何をする拡張機能か分かる状態になっているか」を基準に見直すと安全です。
審査時間は固定ではない
Chrome Web Storeの審査時間は、固定ではありません。
Google公式資料では、多くの拡張機能は数日で審査が完了することがある一方、数週間かかる場合もあると説明されています。
さらに、2026年4月時点の公式注意として、提出数の増加により審査時間が延びていることが案内されています。
そのため、ブログやSNSで見た過去の体験談だけをもとに「何日で必ず通る」と考えない方が安全です。
審査時間が延びやすい要因として、公式資料では次のようなものが挙げられています。
| 要因 | なぜ時間がかかりやすいか |
|---|---|
| 広いホスト権限 | *://*/* や <all_urls> のように多くのサイトへアクセスできるため |
| 強い権限 | tabs、downloads、cookies、webRequest など、扱い方によって影響が大きいため |
| コード量が多い | 安全性や動作を確認する範囲が広くなるため |
| 読みにくいコード | レビュー担当者が機能を確認しづらくなるため |
| 過去の警告や却下 | 修正内容や再発防止をより慎重に確認する必要があるため |
審査が長いからといって、必ず問題があるとは限りません。
ただし、提出前に権限、説明文、Privacy practices、テスト手順を整えておくことで、不要な差し戻しを減らしやすくなります。
落ちやすいポイント
審査で問題になりやすいのは、機能そのものよりも「説明不足」や「必要以上に広い要求」です。
実装者から見ると自然な設計でも、ストア審査や利用者から見ると不透明に見えることがあります。
権限が広すぎる
Chrome拡張機能では、できるだけ狭い権限を要求します。
たとえば、特定の業務サイトだけで動けばよい拡張機能なのに、<all_urls> を要求していると、ユーザーの閲覧全体にアクセスできるように見えます。
Chrome Web Storeのポリシーでは、同じ機能を実現できるなら、データや機能へのアクセスが少ない権限を選ぶことが求められています。
提出前には、次のように見直します。
host_permissionsは対象サイトに絞る- まだ実装していない将来機能のために権限を先取りしない
activeTabで足りる場面では常時アクセス権限を要求しないtabsやdownloadsなどの強い権限には明確な利用理由を用意する- 権限説明文で、ユーザーに伝わる言葉に置き換える
将来使うかもしれない権限は、審査では不利になりやすいです。
必要になったタイミングでバージョンアップし、理由を説明して追加する方が分かりやすくなります。
Privacy practicesと実際の動作が合っていない
Privacy practicesでは、拡張機能が扱うユーザーデータや利用目的を開示します。
問題になりやすいのは、「データを扱っているのに未申告」「外部送信しているのに説明していない」「プライバシーポリシーとDashboardの入力内容が食い違っている」といったケースです。
特に、次のデータは慎重に扱います。
- ページURL
- ページ本文
- 入力フォームの内容
- メールアドレスやユーザーID
- Cookieや認証に関わる情報
- 閲覧履歴に近いログ
ローカル保存だけの拡張機能でも、「何を保存するか」「外部送信しないか」「削除できるか」は説明しておくと安心です。
外部APIへ送信する場合は、送信先、送信するデータ、送信目的を本文、プライバシーポリシー、Dashboardの入力内容で揃えます。
説明文と実際の機能が一致していない
ストア掲載文は、審査でもユーザーでも重要です。
説明文に書いた機能が実装されていなかったり、実際には別の動作をしていたりすると、誤解を招く掲載情報になります。
たとえば、次のような書き方は避けます。
| 避けたい表現 | 見直し方 |
|---|---|
| 実装していない機能を「できます」と書く | 現在の機能だけを書く |
| 効果を過度に断定する | 利用者が確認できる事実に寄せる |
| 対応サイトを広く見せる | 動作確認済みサイトを明記する |
| スクリーンショットが古い | 現在の画面に差し替える |
| キーワードを詰め込む | 自然な説明文にする |
拡張機能の主目的は、狭く、分かりやすく書きます。
「何でもできます」よりも、「このページでこの作業を楽にします」と書いた方が、審査にも利用者にも伝わりやすくなります。
コードが読みにくい
Chrome Web Storeのポリシーでは、コードの難読化や機能の隠蔽は認められていません。
空白やコメントの削除、変数名短縮、ファイル結合などの一般的な圧縮は許容される場合がありますが、機能を分からなくする目的の難読化は避ける必要があります。
提出前には、次の点を確認します。
- ビルド後のコードに不要な難読化設定が入っていない
- 外部から実行コードを読み込む設計になっていない
- 未使用のライブラリやサンプルコードを含めていない
- 秘密情報、APIキー、テスト用トークンを含めていない
- 主要な機能が提出物のコードから確認できる
Manifest V3では、拡張機能の機能が提出されたコードから確認できることが重要です。
ビルドツールを使う場合でも、審査担当者が「何をしているか」を追える構成にしておきます。
テスト手順が足りない
ログインが必要な拡張機能、特定サイトでしか動かない拡張機能、操作手順が分かりにくい拡張機能では、Test instructionsが重要になります。
審査担当者が機能を再現できないと、確認に時間がかかったり、機能不備として扱われたりする可能性があります。
次のような情報を用意します。
- どのページで確認するか
- どのボタンを押すか
- どの状態になれば正常か
- ログインが必要な場合の確認方法
- テスト用データが必要な場合の準備手順
ユーザー向けの説明文とは別に、審査担当者が迷わず動作確認できる手順を用意するのがポイントです。
修正時の考え方
審査結果は、Developer Dashboard上のステータスや通知で確認します。
公式資料では、ステータスとして Published、Pending、Rejected、Taken Down などが案内されています。
却下や公開停止になった場合は、まず通知内容を読み、原因を分けて考えます。
修正時の基本は、次の順番です。
- 通知文と該当ポリシーを読む
- 問題がコード、権限、説明文、Privacy practicesのどこにあるか分ける
- 原因になった実装や表現を修正する
- 関連する掲載情報やプライバシーポリシーも合わせて直す
- ローカルで動作確認する
- 変更内容が分かるようにバージョンを更新して再提出する
大事なのは、表面的な言い換えだけで済ませないことです。
たとえば、権限が広すぎると言われた場合、説明文だけを足すのではなく、実際に権限を狭められないかを先に検討します。
Privacy practicesの不足を指摘された場合は、Dashboardの入力だけでなく、本文、プライバシーポリシー、ストア説明文も矛盾しないように見直します。
提出前チェック
審査へ送る前に、次の項目を確認します。
| チェック項目 | 確認内容 |
|---|---|
| 権限 | 機能に必要な最小限の権限だけを要求している |
| ホスト権限 | 対象サイトをできるだけ限定している |
| 説明文 | 実装済みの機能だけを正確に書いている |
| スクリーンショット | 現在のUIと一致している |
| Privacy practices | 保存、送信、利用目的を正しく入力している |
| プライバシーポリシー | Dashboardの入力内容と矛盾していない |
| コード | 難読化、秘密情報、不要ファイルを含めていない |
| テスト手順 | 審査担当者が動作確認できる手順を書いている |
| 公式情報 | 最新のProgram Policiesと審査関連資料を確認している |
特に個人開発では、提出直前に「動くからOK」と判断しがちです。
しかし、公開する拡張機能では、動作確認に加えて、ユーザーへの説明、権限の妥当性、データの扱いをそろえる必要があります。
参考リンク
- Chrome Web Store review process
- Chrome Web Store Program Policies
- Use of Permissions
- Code Readability Requirements
- Misleading or Unexpected Behavior
- Check on your review status
- Privacy practices
まとめ
Chrome Web Storeの審査で注意したいポイントは、難しい裏技ではありません。
基本は、必要な権限だけを使い、データの扱いを正直に説明し、ストア掲載文と実際の動作を一致させることです。
広いホスト権限、強い権限、読みにくいコード、説明不足のPrivacy practicesは、審査に時間がかかったり差し戻しにつながったりしやすいポイントです。
提出前に、拡張機能本体、ストア掲載情報、プライバシーポリシー、テスト手順を同じ内容でそろえておきます。
次回は、公開後に必要になるアップデート方法を整理します。
Your Message