Chrome Web Store公開前チェックリスト:ZIP・権限・画像・プライバシーを確認する

公開日: 

前回の記事「Chrome拡張機能のプライバシーポリシーの作り方:ローカル保存と外部送信を整理する」では、拡張機能が扱うデータを棚卸しし、プライバシーポリシーへ書く項目を紹介しました。

Chrome拡張機能が動くようになったら、Chrome Web Storeへの公開準備を始めます。

ただし、動作するフォルダをそのままZIP化して提出すればよいわけではありません。

不要なファイルが含まれていないか、権限が広すぎないか、ストア掲載用の画像を用意したか、プライバシー開示と実際の動作が一致しているかを確認します。

公開直前にまとめて確認すると、修正漏れを減らせます。

この記事では、Chrome Web Storeへ提出する前に確認したい項目を、初心者向けのチェックリストとして整理します。

Developer Dashboardでの具体的な登録操作は次の記事、審査で注意したい論点の深掘りはその次の記事で扱います。

Chrome Web Store公開前に拡張機能本体と掲載情報とプライバシーを確認する図解
Chrome Web Store公開前に拡張機能本体と掲載情報とプライバシーを確認する図解

公開前チェックが必要な理由

開発中は、機能を追加し、動作を確認することに意識が向きます。

一方、Chrome Web Storeへ提出するときは、拡張機能本体だけでなく、ストア掲載情報やデータ利用の説明も必要です。

たとえば、次のような見落としがあります。

  • ZIPの中に .env や開発用ファイルが残っている
  • manifest.json の version を更新していない
  • 使っていない権限が残っている
  • スクリーンショットが古い画面のままになっている
  • プライバシーポリシーと外部送信の実装が一致していない
  • ログインが必要なのに、審査担当者向けの確認手順がない

公開前チェックでは、次の5つに分けて確認します。

  1. 拡張機能本体
  2. 動作確認
  3. 権限とプライバシー
  4. ストア掲載情報
  5. 配布設定と審査準備

ZIPファイルを作る前に整理する

Chrome Web Storeへアップロードする拡張機能は、ZIPファイルにまとめます。

ZIPファイルのルートには、manifest.json が必要です。

次のような構造にします。

my-extension.zip
├─ manifest.json
├─ popup.html
├─ popup.js
├─ background.js
├─ content.js
└─ icons/
   ├─ icon16.png
   ├─ icon48.png
   └─ icon128.png

ZIPを開いた直後に、manifest.json が見える状態です。

次のように、余分な親フォルダを入れないようにします。

my-extension.zip
└─ my-extension/
   └─ manifest.json

アップロード用ZIPは、開発用フォルダと分けて作ると確認しやすくなります。

ZIPへ秘密情報を含めない

アップロード用ZIPへ、秘密情報を含めてはいけません。

特に、次のファイルや値を確認します。

.env
APIキー
パスワード
秘密鍵
アクセストークン
開発用の接続先
個人用メモ

JavaScriptやJSONへ直接書いた値も確認します。

const API_KEY = "ここへ秘密情報を書かない";

Chrome拡張機能のファイルは、利用者の環境へ配布されます。

拡張機能内へ埋め込んだ秘密情報を、利用者から完全に隠すことはできません。

外部APIを使う場合は、認証方式やサーバー側の設計を見直します。

また、提出に不要な開発用ファイルも除外します。

node_modules/
tests/
screenshots/
開発用ログ
バックアップファイル
READMEの作業メモ

必要なファイルだけを別フォルダへコピーし、そのフォルダをZIP化すると安全です。

Chrome Web Store提出用ZIPへ必要なファイルだけを含める図解
Chrome Web Store提出用ZIPへ必要なファイルだけを含める図解

manifest.jsonを確認する

ZIP化する前に、manifest.json を見直します。

最初に確認する項目は次の通りです。

項目確認内容
manifest_versionManifest V3の 3 になっているか
nameストア掲載名と分かりやすく対応しているか
description現在の機能を簡潔に説明しているか
version公開するバージョン番号になっているか
icons必要な画像ファイルが存在するか
actionpopupやアイコン設定が正しいか
permissions必要な権限だけになっているか
host_permissionsアクセス先が必要最小限か
content_scripts.matches自動実行する対象ページが広すぎないか

たとえば、次のような構成です。

{
  "manifest_version": 3,
  "name": "Sample Extension",
  "version": "1.0.0",
  "description": "作業を補助するサンプル拡張機能です。",
  "permissions": [
    "storage"
  ],
  "action": {
    "default_popup": "popup.html"
  },
  "icons": {
    "16": "icons/icon16.png",
    "48": "icons/icon48.png",
    "128": "icons/icon128.png"
  }
}

公開後に更新する場合は、version を上げます。

同じバージョン番号のまま新しいZIPを提出しないようにします。

パッケージ化前にChromeで読み込む

アップロード用フォルダを作ったら、そのフォルダをChromeへ読み込みます。

開発中の元フォルダではなく、提出に使うファイルだけを集めたフォルダを読み込むことが重要です。

手順は次の通りです。

  1. Chromeで chrome://extensions を開く
  2. 右上のデベロッパーモードをオンにする
  3. 「パッケージ化されていない拡張機能を読み込む」を押す
  4. アップロード用フォルダを選ぶ
  5. エラーが表示されないことを確認する
  6. 主要機能を操作する

開発用フォルダでは動いていたのに、アップロード用フォルダでは動かない場合があります。

必要なファイルをコピーし忘れていないか、パスが正しいかを確認します。

主要機能を動作確認する

公開前には、利用者が行う操作を順番に試します。

たとえば、次の項目を確認します。

  • 拡張機能アイコンが表示されるか
  • popupが開くか
  • ボタンや入力欄が動くか
  • content scriptが対象ページだけで動くか
  • background service workerの処理が動くか
  • 設定を保存して、popupを開き直しても復元できるか
  • ブラウザを再起動しても必要なデータが残るか
  • 履歴一覧が表示されるか
  • 削除機能がある場合、実際に削除できるか
  • CSV出力などのダウンロード機能が動くか

対象サイトへ依存する拡張機能は、複数のページで確認します。

ログイン前、ログイン後、対象データがない画面、データが多い画面など、条件を変えて試します。

エラーケースを確認する

正常に動く場合だけでなく、失敗した場合も確認します。

たとえば、次のような状態です。

エラーケース確認する内容
入力欄が空保存せず、分かりやすいメッセージを出すか
対象要素が見つからないページ全体を壊さずに処理を終えるか
外部APIが失敗利用者へ失敗を伝えるか
ネットワークが使えない再試行や案内が必要か
権限が許可されない対象機能だけを無効にできるか
保存処理が失敗Consoleと画面で確認できるか

公開後は、利用者の環境で同じエラーが起きる可能性があります。

エラーを握りつぶさず、利用者が次の操作を判断できる状態にします。

権限をもう一度見直す

前々回の記事では、Chrome拡張機能の権限設計を整理しました。

公開前には、manifest.json の権限をもう一度確認します。

項目確認内容
permissions実装済み機能で使う権限だけか
host_permissions対象ドメインやパスへ限定できないか
content_scripts.matches関係のないページで自動実行しないか
optional_permissions利用時だけ要求できる権限はないか
activeTab常時アクセスの代わりに使えないか

将来使うかもしれない権限を、先回りして追加しません。

<all_urls> や tabs を使う場合は、本当に必要か、より狭い権限で実現できないかを確認します。

権限ごとに、どの機能で使うかを説明できるようにします。

プライバシー開示を確認する

前回の記事では、プライバシーポリシーへ書く項目を整理しました。

公開前には、次の内容が一致しているか確認します。

  1. 拡張機能の実際の動作
  2. manifest.json の権限
  3. プライバシーポリシー
  4. Developer DashboardのPrivacy practices

確認するデータの例は次の通りです。

  • 設定値
  • コメント履歴
  • 閲覧ページのURL
  • 入力フォームの内容
  • 外部APIへ送信するデータ
  • 分析ツールへ送信するデータ
  • エラー収集サービスへ送信するデータ

ローカル保存だけの場合も、保存内容、保存場所、削除方法を説明します。

外部送信がある場合は、送信データ、送信先、利用目的を説明します。

ストア掲載情報を準備する

Chrome Web Storeのストア掲載ページでは、利用者が拡張機能の内容を判断します。

説明文と画像は、実際の機能と一致させます。

準備する項目は次の通りです。

項目確認内容
拡張機能名機能が分かり、誤解を招かないか
短い説明主な用途を簡潔に説明しているか
詳細説明主要機能、使い方、保存データを説明しているか
アイコン小さい表示でも識別できるか
スクリーンショット実際の画面と機能が分かるか
カテゴリ拡張機能の用途に合っているか
言語想定利用者が読めるか
サポート情報問い合わせ方法が分かるか
プライバシーポリシーURLログイン不要で閲覧できるか

スクリーンショットは、機能が分かる画面を選びます。

古いバージョンの画面や、実装していない機能を含む画像は使いません。

説明文も、必要以上に大きな効果をうたわないようにします。

アイコンとスクリーンショットを確認する

アイコンとスクリーンショットは、公開前に実ファイルを開いて確認します。

アイコンでは、次の点を見ます。

  • 画像がぼやけていないか
  • 小さいサイズでも識別できるか
  • 背景と区別できるか
  • 権利のある素材を使っているか
  • 他社サービスの公式アプリと誤解されないか

スクリーンショットでは、次の点を見ます。

  • 現在のUIと一致しているか
  • 個人情報や秘密情報が写っていないか
  • テスト用のメールアドレスやAPIキーが写っていないか
  • 利用者が機能を理解できるか
  • 画像内の文字が読めるか

対象サイトの画面を使う場合は、表示内容と権利関係にも注意します。

配布設定を確認する

Developer Dashboardでは、配布に関する設定も確認します。

たとえば、公開範囲、対象地域、価格設定などです。

公開前に、次の点を整理します。

  • 一般公開するか
  • 限定公開または非公開にするか
  • 対象地域をどうするか
  • 無料で公開するか
  • テスト利用者だけに配布する段階が必要か

最初から一般公開せず、少人数で確認してから広げる方法もあります。

拡張機能の目的と開発段階に合わせて選びます。

審査担当者向けの確認手順を用意する

拡張機能によっては、インストールしただけでは主要機能を確認できません。

たとえば、次のような場合です。

  • 特定サイトへのログインが必要
  • 対象ページを開く必要がある
  • テスト用アカウントが必要
  • 特定の操作順がある
  • 外部サービスとの連携設定が必要
  • 地域や権限によって表示が変わる

この場合は、審査担当者が機能を確認できる手順を用意します。

手順は、短く具体的に書きます。

1. 拡張機能をインストールする
2. https://example.com/login を開く
3. テスト用アカウントでログインする
4. ダッシュボード画面を開く
5. 拡張機能アイコンを押す
6. 「履歴を保存」を押す
7. 保存済み履歴が表示されることを確認する

必要な場合だけ、テスト用アカウントを準備します。

本番用の管理者アカウントや、個人用アカウントを共有しません。

公開前の最終確認シート

提出直前に、次のチェックリストを使います。

拡張機能本体

  • [ ] ZIP直下に manifest.json がある
  • [ ] 不要な親フォルダを含めていない
  • [ ] .env、APIキー、パスワード、秘密鍵を含めていない
  • [ ] node_modules、開発用ログ、不要なテストファイルを含めていない
  • [ ] manifest_version が 3 になっている
  • [ ] name、description、version が正しい
  • [ ] アイコンのパスと実ファイルが一致している

動作確認

  • [ ] アップロード用フォルダをChromeへ読み込める
  • [ ] 拡張機能管理画面にエラーが出ていない
  • [ ] popup、content script、background service workerが必要に応じて動く
  • [ ] 設定保存と復元が動く
  • [ ] 履歴保存と削除が必要に応じて動く
  • [ ] ブラウザ再起動後の状態を確認した
  • [ ] エラーケースで利用者向けメッセージが出る

権限とプライバシー

  • [ ] 未使用の権限が残っていない
  • [ ] host_permissions と content_scripts.matches を必要な範囲へ絞った
  • [ ] <all_urls> や tabs の必要性を説明できる
  • [ ] 保存するデータを一覧にした
  • [ ] 外部送信の有無、送信先、目的を確認した
  • [ ] データ削除方法を確認した
  • [ ] プライバシーポリシーを公開した
  • [ ] Privacy practicesの開示と実装が一致している

ストア掲載情報

  • [ ] 拡張機能名と説明文が実際の機能と一致している
  • [ ] アイコンを確認した
  • [ ] スクリーンショットを確認した
  • [ ] 画像に秘密情報や個人情報が写っていない
  • [ ] カテゴリと言語を確認した
  • [ ] サポート情報を用意した
  • [ ] プライバシーポリシーURLを確認した

配布と審査

  • [ ] 公開範囲を確認した
  • [ ] 対象地域を確認した
  • [ ] 料金や提供条件を確認した
  • [ ] 審査担当者向けのテスト手順が必要か確認した
  • [ ] 必要な場合、専用のテスト用アカウントを準備した

Build、Test、Review、Submitの順で確認する

公開前チェックは、次の4段階に分けると進めやすくなります。

  1. Build:提出用フォルダとZIPを作る
  2. Test:提出用フォルダをChromeへ読み込み、動作確認する
  3. Review:権限、データ利用、掲載情報、配布設定を見直す
  4. Submit:Developer Dashboardへアップロードする

開発用フォルダをそのまま提出せず、提出物を作った後にもう一度テストします。

Chrome拡張機能をBuildしてTestとReviewを行いSubmitする流れの図解
Chrome拡張機能をBuildしてTestとReviewを行いSubmitする流れの図解

公開後の更新にも同じチェックを使う

公開前チェックリストは、最初の公開だけでなく、アップデート時にも使えます。

機能を追加すると、権限、データ利用、スクリーンショット、説明文が変わる場合があります。

たとえば、次の変更では見直しが必要です。

  • 新しい権限を追加した
  • 対象サイトを増やした
  • 外部APIを追加した
  • 保存するデータを増やした
  • UIを変更した
  • 有料機能を追加した
  • 広告や分析ツールを追加した

更新時も、ZIP作成、動作確認、権限確認、掲載情報更新を行います。

公開後の具体的なアップデート手順は、後続記事で扱います。

参考リンク

まとめ

この記事では、Chrome Web Storeへ提出する前のチェック項目を整理しました。

最初に、提出用フォルダとZIPを作ります。

ZIP直下に manifest.json があること、.env、APIキー、パスワード、不要な開発用ファイルが含まれていないことを確認します。

次に、提出用フォルダをChromeへ読み込み、主要機能とエラーケースを確認します。

権限は必要最小限にし、プライバシーポリシー、Privacy practices、実際の動作を一致させます。

ストア掲載用の説明文、アイコン、スクリーンショット、カテゴリ、言語、サポート情報も準備します。

最後に、公開範囲や対象地域を確認し、必要であれば審査担当者向けのテスト手順を用意します。

次の記事では、Developer DashboardへZIPファイルをアップロードし、Chrome Web Storeへ登録する具体的な流れを扱います。




Your Message

メールアドレスが公開されることはありません。 ※ が付いている欄は必須項目です

日本語が含まれない投稿は無視されますのでご注意ください。(スパム対策)

このサイトはスパムを低減するために Akismet を使っています。コメントデータの処理方法の詳細はこちらをご覧ください。

スポンサードリンク

記事が気に入ったらシェアお願いします

PAGE TOP ↑