Chrome拡張機能をChrome Web Storeへ公開する手順：登録・ZIPアップロード・審査送信

公開日：2026/06/11

Chrome拡張機能個人開発公開・収益化 Chrome Web Store Chrome拡張機能 Developer Dashboard Distribution Manifest V3 Privacy practices ZIP 個人開発公開手順審査

前回の記事「Chrome Web Store公開前チェックリスト：ZIP・権限・画像・プライバシーを確認する」では、提出用ZIP、権限、掲載画像、プライバシー開示を確認しました。

公開前チェックが終わったら、Chrome Web Store Developer Dashboardへ拡張機能を登録します。

初回は開発者登録を行い、提出用ZIPをアップロードします。

その後、ストア掲載情報、プライバシー開示、配布設定、必要に応じた審査担当者向けテスト手順を入力し、審査へ送信します。

この記事では、初めて公開する人向けに、Chrome Web Storeへ登録する流れを順番に整理します。

Chrome Web Storeの画面や項目名は、今後変更される可能性があります。実際に作業するときは、Developer Dashboardの表示とGoogle公式資料も確認してください。

Chrome Web Store Developer DashboardへZIPをアップロードし審査後に公開する流れの図解

公開までの全体像

Chrome Web Storeへ公開する流れは、次の通りです。

Chrome Web Store Developer Dashboardへアクセスする
初回だけ開発者登録を行う
New item からZIPファイルをアップロードする
Store listingを入力する
Privacy practicesを入力する
Distributionを確認する
必要に応じてTest instructionsを追加する
審査へ送信する
承認後にストア掲載ページとインストール動作を確認する

公開前に、前回の記事のチェックリストを完了しておきます。

ZIPをアップロードした後で秘密情報や不要な権限に気付くと、修正と再確認が必要になります。

Developer Dashboardへアクセスする

Chrome Web Storeへ拡張機能を登録するときは、Chrome Web Store Developer Dashboardを使います。

次のページへアクセスします。

Chrome Web Store Developer Dashboard

Googleアカウントでログインします。

公開に使うGoogleアカウントは、長期的に管理できるものを選びます。

個人開発でも、次の点を確認します。

普段使う個人アカウントと分ける必要があるか
連絡先メールを継続して確認できるか
2段階認証などのセキュリティ設定を確認したか
将来、チームで管理する可能性があるか

拡張機能を公開した後も、審査結果、ポリシー変更、問い合わせなどの連絡を確認します。

初回は開発者登録を行う

初めてChrome Web Storeへ公開する場合は、開発者登録が必要です。

Developer Dashboardの案内に従い、登録を進めます。

登録時には、登録料の支払いが必要です。

金額や支払い画面は変更される可能性があるため、実際に表示される最新の案内を確認してください。

登録後は、連絡先メールの確認や、必要なアカウント設定を行います。

Google公式資料では、アカウント設定として、連絡先メールの確認、開発者メール、必要に応じた住所確認や2段階認証などが案内されています。

画面に表示される未完了項目がある場合は、ZIPをアップロードする前に対応します。

提出用ZIPを用意する

前回の記事で作った提出用ZIPを用意します。

ZIP直下に manifest.json があることを確認します。

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

次のような秘密情報や不要ファイルを含めません。

.env
APIキー
パスワード
秘密鍵
アクセストークン
node_modules/
開発用ログ
不要なテストファイル

アップロード直前に、提出用フォルダをChromeへ読み込み直し、主要機能が動くことを確認します。

New itemからZIPをアップロードする

Developer Dashboardへログインしたら、New item を選びます。

表示された画面で、提出用ZIPをアップロードします。

アップロード後、manifest.json の内容が読み取られ、アイテム編集画面へ進みます。

エラーが表示された場合は、次の点を確認します。

ZIP直下に manifest.json があるか
JSONの構文エラーがないか
manifest_version が正しいか
必要なファイルがZIP内にあるか
アイコンやJavaScriptのパスが正しいか
version の形式が正しいか

エラーを修正したら、提出用フォルダをChromeへ読み込み直し、動作確認してからZIPを作り直します。

入力する主なタブ

ZIPをアップロードすると、Developer Dashboardで公開情報を入力します。

主な項目は次の通りです。

タブまたは項目	入力する内容
Store listing	説明文、カテゴリ、言語、アイコン、スクリーンショット、サポート情報
Privacy practices	単一目的、権限理由、データ利用、プライバシーポリシーURL
Distribution	公開範囲、対象地域、必要な配布設定
Test instructions	ログインや特殊操作が必要な場合の確認手順

Dashboardのレイアウトや項目名は更新される可能性があります。

画面の案内に従い、未入力項目や警告が残っていないか確認します。

Chrome Web Store Developer Dashboardで入力する主な項目の図解

Store listingを入力する

Store listingでは、Chrome Web Storeに表示する情報を入力します。

利用者は、掲載ページを見てインストールするか判断します。

実際の機能と一致する説明を書きます。

主な項目は次の通りです。

項目	確認内容
拡張機能名	機能が分かり、誤解を招かないか
短い説明	主な用途を簡潔に書いたか
詳細説明	主要機能、使い方、対象利用者を説明したか
カテゴリ	用途に合った分類を選んだか
言語	想定利用者が読める言語を設定したか
アイコン	小さい表示でも識別できるか
スクリーンショット	実際の機能と画面が分かるか
サポート情報	問い合わせ方法を確認できるか

説明文に、実装していない機能を書いてはいけません。

たとえば、外部送信しないローカル保存型の拡張機能なら、その特徴を分かりやすく書けます。

スクリーンショットには、個人情報、APIキー、テスト用の秘密情報を写さないようにします。

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

Store listingでは、アイコンやスクリーンショットを登録します。

画像のサイズや形式は、Developer Dashboardに表示される要件とGoogle公式資料を確認します。

スクリーンショットは、利用者が機能を理解できる画面を選びます。

たとえば、コメント履歴を保存する拡張機能なら、次のような画面が候補です。

コメント履歴を保存している画面
履歴一覧を表示している画面
検索やCSV出力がある場合、その操作画面
設定画面

画像は、現在のバージョンと一致させます。

古いUIや、未実装機能を含む画像は使いません。

Privacy practicesを入力する

Privacy practicesでは、拡張機能の目的、権限、データ利用について開示します。

前々回の記事で作った権限表と、前回までに整理したデータ棚卸し表を使います。

主に次の点を確認します。

拡張機能の単一目的を説明できるか
要求する権限ごとに必要な理由を書けるか
どのユーザーデータを扱うか
ローカル保存だけか
外部サーバーへ送信するか
第三者へ提供するか
プライバシーポリシーURLがあるか

入力内容は、実際のコードと一致させます。

たとえば、IndexedDBへコメント履歴を保存し、外部送信しない場合は、その内容を説明します。

外部APIを使う場合は、送信するデータ、送信先、目的を整理します。

プライバシーポリシーURLは、ログイン不要で閲覧できるページを指定します。

単一目的を分かりやすくする

Chrome Web Storeでは、拡張機能の目的を分かりやすく説明できることが重要です。

複数の関係ない機能を詰め込むと、利用者にも審査担当者にも分かりにくくなります。

たとえば、YouTube Liveのコメントを保存する拡張機能なら、主な目的は次のように説明できます。

YouTube Liveのコメント履歴をブラウザ内へ保存し、
配信後に確認しやすくする。

この目的に必要な機能と権限だけを含めます。

将来追加するかもしれない機能を、先回りして説明しません。

権限理由を具体的に書く

Privacy practicesでは、権限の理由を説明できるようにします。

たとえば、次のように整理します。

権限またはアクセス先	理由
`storage`	popupのON/OFF設定をブラウザ内へ保存するため
`activeTab`	利用者が操作した現在ページだけを処理するため
`scripting`	利用者操作後に対象ページへスクリプトを挿入するため
`https://example.com/*`	対象サイトのページだけで機能を動かすため

「必要だから」とだけ書かず、どの機能で使うかを書きます。

不要な権限が見つかった場合は、説明を作るのではなく、manifest.json から削除します。

Distributionを確認する

Distributionでは、配布に関する設定を確認します。

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

主な確認項目は次の通りです。

一般公開するか
限定公開または非公開にするか
対象地域をどうするか
料金や提供条件をどうするか
テスト利用者だけで確認する段階が必要か

初回公開で不安がある場合は、すぐに広く公開せず、確認範囲を限定して動作を見る方法もあります。

設定項目は、Developer Dashboardの表示に従って確認します。

Test instructionsを追加する

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

その場合は、審査担当者向けのTest instructionsを用意します。

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

対象サイトへのログインが必要
テスト用アカウントが必要
特定ページを開く必要がある
初期設定が必要
外部サービスとの連携が必要
特定の操作順がある

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

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

テスト用アカウントが必要な場合は、専用のアカウントを用意します。

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

入力内容を保存して見直す

各項目を入力したら、保存します。

未入力項目、警告、エラーメッセージが残っていないか確認します。

審査へ送信する前に、次の内容を見直します。

Store listingの説明文と画像が現在の機能と一致している
Privacy practicesの開示が実際のコードと一致している
権限理由を具体的に説明できる
プライバシーポリシーURLを開ける
Distributionが意図した公開範囲になっている
Test instructionsが必要な場合、手順どおりに確認できる
ZIPが最終版になっている

提出後に慌てて修正しないように、送信前にもう一度確認します。

Submit for reviewで審査へ送信する

入力内容を確認したら、審査へ送信します。

Developer Dashboardの案内に従い、Submit for review を選びます。

画面に表示される確認事項を読み、問題がなければ送信します。

審査へ送信すると、Dashboardでステータスを確認できます。

審査結果や追加対応が必要な場合は、登録した連絡先メールも確認します。

審査期間は余裕を持って考える

審査にかかる時間は、拡張機能の内容や時期によって変わります。

固定の日数で完了すると考えない方が安全です。

Google公式資料では、2026年4月29日付で、Chrome Web Storeの審査時間が通常より長くなっているという案内が掲載されています。

公開日が決まっている場合は、余裕を持って提出します。

審査待ちの間に、説明文、サポートページ、問い合わせ対応の準備も確認します。

最新の状況は、Google公式のreview processページを確認してください。

承認後に確認する

承認されたら、公開済みのストア掲載ページを確認します。

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

拡張機能名が正しい
説明文が正しい
アイコンが表示されている
スクリーンショットが表示されている
プライバシーポリシーURLを開ける
サポート情報を確認できる
意図した公開範囲になっている

次に、公開ページから拡張機能をインストールし、動作を確認します。

開発用のパッケージ化されていない拡張機能ではなく、ストアから配布された状態で確認します。

公開後に記録する

公開後は、運用に必要な情報を記録します。

拡張機能名
Chrome Web Storeの公開URL
公開日
公開したバージョン
Developer Dashboardの管理アカウント
問い合わせ先
プライバシーポリシーURL
サポートページURL

アップデート時に、どのバージョンを公開したか分かる状態にします。

公開後の更新手順は、後続記事で扱います。

公開フローを整理する

初回公開は、次の5段階に分けると進めやすくなります。

Register：開発者登録とアカウント設定を行う
Upload：New item からZIPをアップロードする
Fill details：Store listing、Privacy practices、Distribution、Test instructionsを入力する
Submit：審査へ送信する
Publish：承認後に掲載ページとインストール動作を確認する

Chrome Web Storeへ登録してZIPをアップロードし審査後に公開する5段階の図解

よくある注意点

Dashboardの画面は更新される

Chrome Web Store Developer Dashboardの画面、項目名、入力順は変更される可能性があります。

この記事は全体の流れを理解するために使い、実際の作業時は画面の案内とGoogle公式資料を確認してください。

ZIPを修正したら再テストする

ZIP内のファイルを修正した場合は、提出用フォルダをChromeへ読み込み直します。

ZIPを作り直すだけで終わらず、主要機能を再テストします。

説明文と実装を一致させる

説明文、スクリーンショット、Privacy practices、プライバシーポリシーは、実際の動作と一致させます。

未実装の機能を書いたり、外部送信があるのに説明しなかったりしないようにします。

権限を追加する前に見直す

入力中に権限理由を書けない権限が見つかった場合は、その権限が本当に必要か確認します。

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

審査用アカウントを分ける

テスト用アカウントが必要な場合は、審査専用のアカウントを用意します。

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

次の記事で扱うこと

この記事では、Chrome Web Storeへ登録する操作順を整理しました。

審査では、権限が広すぎる、説明と動作が一致しない、データ利用の説明が不足しているなどの点に注意が必要です。

次の記事では、Chrome拡張機能の審査で注意したいポイントを整理します。

参考リンク

まとめ

この記事では、Chrome拡張機能をChrome Web Storeへ公開する流れを整理しました。

初回は、Developer Dashboardで開発者登録とアカウント設定を行います。

New item から提出用ZIPをアップロードし、Store listing、Privacy practices、Distributionを入力します。

ログインや特殊操作が必要な場合は、審査担当者向けのTest instructionsも用意します。

入力内容を見直したら、Submit for review で審査へ送信します。

審査時間は時期や内容によって変わるため、余裕を持って提出します。

承認後は、ストア掲載ページと、ストアからインストールした拡張機能の動作を確認します。

公開後のURL、公開日、バージョンも記録し、次のアップデートに備えます。