Chrome拡張機能の公開後アップデート方法：version更新・再審査・ロールアウトの流れ

公開日：2026/06/14

Chrome拡張機能個人開発公開・収益化 Chrome Web Store Chrome拡張機能 Developer Dashboard Manifest V3 permissions Privacy practices version ロールアウト個人開発再審査

前回の記事「Chrome拡張機能の審査で注意したいポイント：権限・プライバシー・説明文の落とし穴」では、Chrome Web Storeへ提出する前に確認したい審査上の注意点を整理しました。

Chrome拡張機能は、公開できたら終わりではありません。公開後も、Chrome本体や対象サイトの仕様変更、不具合修正、ユーザーからの要望、ストア掲載情報の見直しに合わせて更新していく必要があります。

この記事では、すでにChrome Web Storeで公開した拡張機能を更新するときの基本的な流れを整理します。特に、manifest.json の version を上げること、新しいZIPを作り直すこと、Developer Dashboardから再審査に出すこと、既存ユーザーへ反映されるタイミング、追加権限がある場合の注意点を扱います。

Chrome Web Storeの画面や審査ルールは変更されることがあります。実際に更新を出す前には、必ずChrome for Developersの公式ドキュメントとDeveloper Dashboard上の最新表示を確認してください。

公開後にアップデートが必要になるケース

Chrome拡張機能の更新理由は、大きく分けると次のようになります。

更新理由	具体例
不具合修正	popupが開かない、content scriptが対象ページで動かない、保存処理が失敗する
対象サイトの変更対応	YouTube、ECサイト、社内システムなどのHTML構造が変わった
Chrome仕様への対応	Manifest V3、API、権限、セキュリティ要件の変化に合わせる
機能追加	フィルタ、エクスポート、設定項目、通知などを追加する
ストア情報の更新	説明文、スクリーンショット、カテゴリ、プライバシー情報を直す
権限やデータ扱いの見直し	permissions、host_permissions、Privacy practices、プライバシーポリシーを更新する

個人開発や小規模事業向けの拡張機能では、特に「対象サイトの変更対応」と「説明不足の修正」が多くなりがちです。公開時点で動いていても、外部サイトに依存する拡張機能は、相手側のHTMLや仕様が変わると急に動かなくなることがあります。

公開後の運用では、更新を特別な作業として考えるよりも、通常の保守作業として扱う方が安全です。不具合を直したら、ローカルで確認し、バージョンを上げ、ZIPを作り直し、必要な掲載情報も合わせて見直します。

基本は新しいZIPをアップロードして再審査に出す

公開済みのChrome Web Storeアイテムを更新する基本手順は、次の流れです。

変更内容を決める
ローカルでコードや画像を修正する
manifest.json の version を上げる
拡張機能一式をZIP化する
Developer DashboardのPackageタブで新しいZIPをアップロードする
Store listing、Privacy practices、Distributionなど変更があるタブを更新する
Submit for Reviewで再審査に出す
審査通過後に公開され、ユーザーへ反映される

Chrome Web Storeの公式ドキュメントでも、既存アイテムをアップグレードするには、新しいZIPをアップロードし、変更したメタデータを更新し、新しいレビューに提出する流れが説明されています。

ここで大事なのは、変更したファイルだけをアップロードするのではないことです。拡張機能本体として必要なファイルをすべて含んだ新しいZIPを作ります。 manifest.json、popup、content script、background service worker、アイコン、CSS、HTMLなど、前回と変わっていないファイルも含めます。

manifest.jsonのversionを上げる

コードや同梱ファイルを変えた場合は、manifest.json の version を前回より大きい値にします。

{
  "manifest_version": 3,
  "name": "Sample Extension",
  "version": "1.0.1"
}

Chromeの自動更新では、公開されている拡張機能のバージョンが、インストール済みのバージョンより新しいかどうかが比較されます。そのため、同じ version のままZIPを作り直しても、通常の更新として扱えません。

バージョン番号は、1〜4個の整数をドットで区切る形式です。たとえば次のような形式が使えます。

1
1.0
1.0.1
2.3.0
2.3.0.15

小規模な拡張機能では、最初は次のように運用すると分かりやすいです。

変更内容	version例
初回公開	`1.0.0`
小さな不具合修正	`1.0.1`
軽い機能追加	`1.1.0`
大きな仕様変更	`2.0.0`

ただし、Chrome Web Storeが見るのは基本的に数値としての大小です。「修正内容の意味をどう表すか」は運用ルールなので、ブログやチーム内メモでは「どの変更でどのversionにしたか」を残しておくと後から追いやすくなります。

ZIPを作り直すときの注意点

ZIPを作るときは、拡張機能のルートに manifest.json がある状態で圧縮します。よくある失敗は、拡張機能フォルダそのものをZIPの中に入れてしまい、ZIPを開くとさらにフォルダがあり、その中に manifest.json がある状態になることです。

正しいイメージは次のような構成です。

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

更新前には、ローカルの chrome://extensions で拡張機能を読み込み直して確認します。ここでエラーが出る場合、Chrome Web Storeへ提出しても審査以前に問題になります。

特に確認したいのは次の項目です。

manifest.json のJSON構文が正しい
version が前回より大きい
不要な permissions や host_permissions を増やしていない
popup、content script、service workerが想定どおり動く
アイコンやHTML、CSSなど同梱ファイルの参照パスが壊れていない
APIキーやテスト用トークンなどの秘密情報を含めていない

公開済みの拡張機能では、ローカルで少し動いたかどうかだけでなく、既存ユーザーが使っている状態から更新されても問題ないかを見ます。保存データの形式を変える場合は、古いデータが残っていても壊れないようにしておきます。

Developer Dashboardで更新を提出する

新しいZIPができたら、Chrome Web Store Developer Dashboardで対象アイテムを開きます。 PackageタブにあるUpload New Packageから、新しいZIPをアップロードします。

その後、変更内容に合わせて各タブを確認します。

確認するタブ	見る内容
Package	新しいZIPがアップロードされているか、versionが正しいか
Store listing	説明文、スクリーンショット、機能説明が現在の実装と一致しているか
Privacy practices	収集データ、利用目的、外部送信の説明が実装と一致しているか
Distribution	公開範囲、国、支払い、公開チャンネルが意図どおりか

コードだけを直したつもりでも、機能説明やスクリーンショットが古いままになることがあります。たとえば「CSV出力機能を追加した」のに、ストア説明文に書いていなければユーザーに伝わりません。逆に、まだ実装していない予定機能を説明文に書くと、審査やユーザー体験の面で問題になります。

更新内容を提出する前に、Package、Store listing、Privacy practices、Distributionを一通り見直す習慣を付けると安全です。

再審査中は既存の公開版に影響しない

更新版をSubmit for Reviewで提出しても、その時点ですぐ既存ユーザーへ反映されるわけではありません。公式ドキュメントでは、レビューへ提出した更新は、公開されるまでは既存の公開済みアイテムに影響しないと説明されています。

つまり、審査中も既存ユーザーは現在公開されているバージョンを使い続けます。新規ユーザーも、更新版が公開されるまでは現在の公開版をインストールします。

これは運用上かなり重要です。更新版を提出したからといって、公開中の拡張機能がすぐ止まるわけではありません。ただし、審査が通って公開された後はユーザーへ反映されていくため、提出前のテストは必ず済ませておきます。

追加権限がある更新は特に注意する

更新で新しい権限を追加する場合は、通常の不具合修正より慎重に扱います。 Chrome Web Storeの公式ドキュメントでは、追加権限が必要な更新では、ユーザーがその権限を承認するか、拡張機能を無効にする必要があることが説明されています。

たとえば、最初は storage だけを使っていた拡張機能に、後から広い host_permissions や tabs を追加する場合、ユーザーから見ると「この拡張機能が急に強い権限を求めてきた」と感じられます。

権限を追加する前に、次の点を確認します。

本当にその権限が必要か
activeTab など、より狭い権限で代替できないか
host_permissions を対象サイトだけに限定できないか
ストア説明文に、権限が必要な理由を書いているか
Privacy practicesとプライバシーポリシーに矛盾がないか
ユーザーへ更新内容を告知する必要があるか

特に個人開発の拡張機能では、権限追加の理由を説明しないまま更新すると信頼を落としやすいです。「なぜ必要なのか」「何に使うのか」「どこには送信しないのか」を明確にしておきます。

公開タイミングを制御する

更新をSubmit for Reviewするとき、公開タイミングを制御できる場合があります。公式ドキュメントでは、審査通過後に自動公開せず、手動公開できる状態にするDeferred publishing optionが説明されています。

これは次のような場合に便利です。

告知記事やメール配信のタイミングに合わせたい
週末や深夜に自動公開されるのを避けたい
サポート担当者が見られる時間帯に公開したい
大きなUI変更の前に最終確認時間を取りたい

ただし、審査完了後にいつまでも保留できるわけではありません。公式ドキュメントでは、審査通過後に公開できる期間として最大30日が案内されており、その期間を過ぎると下書きに戻り、再度レビューへ提出する必要があります。

公開キャンセル・審査キャンセル・非公開化の違い

Developer Dashboardでは、アイテムの状態によってメニューに表示される操作が変わります。似た名前の操作があるため、目的を間違えないように整理しておきます。

操作	使う場面
Cancel review	審査待ちの提出を取り消し、下書きを直したい
Cancel publish	公開準備ができている提出を下書きへ戻したい
Defer publish	審査通過後に自動公開せず、手動公開にしたい
Unpublish	公開中のアイテムをChrome Web Storeから非公開にしたい

たとえば、提出直後に「ZIPに不要なファイルを入れていた」と気づいた場合は、審査待ちならCancel reviewで提出を取り消して直します。審査通過後に「まだ告知ページができていない」と気づいた場合は、公開タイミングを制御する考え方になります。

Unpublishは公開中のアイテムをストアから外す操作です。通常の不具合修正では、まず修正版の提出や公開延期、ロールバックを検討します。重大なセキュリティ問題やユーザーに大きな影響がある場合は、非公開化も選択肢になりますが、影響が大きいため慎重に判断します。

段階的ロールアウトが使える場合

ユーザー数が多い拡張機能では、更新を一部のユーザーだけに先に配信し、問題がなければ割合を増やしていく段階的ロールアウトが使える場合があります。

Chrome Web Storeの公式ドキュメントでは、7日間アクティブユーザーが10,000人を超える既存公開アイテムで、部分ロールアウトの割合を設定できることが説明されています。この機能は、新しい下書きがアップロードされた後に表示され、提出後の下書きでは無効になるなどの条件があります。

段階的ロールアウトの考え方は次の通りです。

ロールアウト	向いている場面
100%公開	小規模な不具合修正、影響範囲が狭い更新
一部公開	大きなUI変更、保存データ形式の変更、対象サイト依存の修正
割合を増やす	初期配信後に問題がないことを確認できた場合

部分ロールアウト済みのアイテムでは、後から配信割合を増やすことができます。公式ドキュメントでは、ロールアウト割合の変更は新しいレビューを発生させないと説明されています。

ただし、複数の部分ロールアウトを同時に走らせることはできません。部分ロールアウト中にさらに新しいバージョンを公開すると、前のバージョンのロールアウトはそれ以上進まなくなります。

小規模な個人開発ではこの機能を使える場面は少ないかもしれません。それでも、大きな拡張機能を運用する場合の考え方として、「全員へ一気に出す」以外の選択肢があることは知っておくと役立ちます。

バグが出たときは原因を切り分けて戻す

更新後に不具合が見つかった場合は、まず影響範囲を切り分けます。

どのversionで発生しているか確認する
どのOS、Chromeバージョン、対象サイトで発生しているか確認する
popup、content script、service worker、保存データのどこが原因か分ける
再現手順を記録する
修正版を作るか、前のバージョンへ戻すか判断する

Chrome Web Storeには、バグのある更新を出してしまったときに以前のバージョンへ戻すrollbackの仕組みがあります。すぐに被害を止めたい場合はロールバックを検討します。一方で、軽微な問題であれば修正版のversionを上げて再提出する方が分かりやすい場合もあります。

大事なのは、表面的な説明文だけを直して済ませないことです。権限が広すぎると言われたなら、実装で権限を狭められないかを見ます。 Privacy practicesに不足があるなら、Dashboard、プライバシーポリシー、本文説明をそろえます。対象サイトで動かないなら、DOM構造やセレクタ、例外処理を確認します。

公開後の運用チェックリスト

公開後の更新では、提出直前に次の項目を確認します。

チェック項目	確認内容
version	前回より大きい値にした
ZIP	`manifest.json` がZIP直下にある
動作確認	ローカル読み込みで主要機能を確認した
保存データ	古いデータが残っていても壊れない
権限	不要なpermissionsとhost_permissionsを追加していない
ストア説明	現在の機能と説明文が一致している
スクリーンショット	古いUI画像のままになっていない
Privacy practices	データの保存、送信、利用目的が実装と一致している
プライバシーポリシー	Dashboardの入力内容と矛盾していない
テスト手順	審査担当者が再現できる説明になっている
公開タイミング	自動公開か手動公開かを決めた
告知	追加権限や大きな変更をユーザーに伝える準備をした