QR Send

スマホとPCのChrome間で、URLやテキストをQRコード1回のペアリングで送り合える自作Chrome拡張。アカウント不要・無料。

使ってみる →

作ったChrome拡張をChromeウェブストアで公開するまで（Manifest V3・審査を通すコツ）

個人開発

動くようになったコードを、誰でも入れられる形にする

Chrome拡張機能は「動くコードを書く」ところまではローカルで完結しますが、それを他の人に使ってもらうには、Chromeウェブストア（CWS）に登録して審査を通す、というもう一段のハードルがあります。自分の場合、URLをスマホからPCのChromeへ送る拡張「QR Send」（https://qrsend.app）を作ったときに、このあたりで思ったより時間を取られました。今回はコードそのものよりも、公開までの手続きと審査で気をつけたポイントを整理しておきます。

拡張が完成してから公開までの流れ

大まかな流れは次のとおりです。

  1. manifest.jsonを含めた拡張一式をzipにまとめる
  2. Chrome Web Store Developer Dashboardにデベロッパー登録（初回のみ登録料が必要）
  3. zipをアップロードし、ストア掲載用の説明文・アイコン・スクリーンショット・プライバシー関連の設問に回答
  4. 審査に提出
  5. 審査通過後、公開（公開・限定公開・非公開を選べる）

このうち手間がかかるのは3と、審査に落ちたときの4です。コードを直す作業よりも、ストア側の設問にどう答えるかで詰まることの方が多い印象でした。

manifest.jsonの必須項目とアイコン

Manifest V3ではmanifest_versionが必須で、V2で書いていた拡張は書き換えが必要です。最低限必要なのはこのくらいです。

{
  "manifest_version": 3,
  "name": "拡張の名前",
  "description": "拡張の説明",
  "version": "1.0.0",
  "icons": {
    "16": "icons/icon16.png",
    "48": "icons/icon48.png",
    "128": "icons/icon128.png"
  },
  "action": {
    "default_popup": "popup.html"
  }
}

アイコンは16/48/128の3サイズを用意しておくと、ツールバー・拡張機能一覧・ストア掲載ページのそれぞれで正しく表示されます。1サイズだけ用意して拡大縮小に任せると、ストアのプレビューで輪郭がぼやけて見えることがあったので、面倒でも3サイズ書き出しておくのが無難です。

権限は最小限に絞る

審査で地味に効いてくるのがpermissionsとhost_permissionsです。QR Sendでは最終的に次のところまで絞りました。

"permissions": ["alarms", "storage", "tabs"],
"host_permissions": ["https://ntfy.sh/*"]
  • alarms: バックグラウンドで一定間隔ごとに新着URLを確認するため
  • storage: 設定と送信履歴をローカルに保存するため
  • tabs: 受信したURLを新しいタブとして開くため
  • host_permissions: 通信先を中継サーバーのドメイン1つだけに限定

最初は<all_urls>のような広い権限を入れておけば何かと便利だろう、と考えがちですが、審査担当からすると「この拡張は何にでもアクセスできる＝リスクが高い」に見えます。実装上必要な権限だけを積み上げていき、host_permissionsもワイルドカードで広げず通信先ドメインを具体的に書く方が、説明もシンプルになりますし審査側の心証もよくなります。

ストア掲載情報（説明文・スクショ・プライバシー記述）

Developer Dashboardでは、説明文とスクリーンショット、そしてプライバシーに関する設問（収集するデータの種類、その用途、第三者への提供有無など）にすべて答える必要があります。ここで気をつけたのは次の点です。

  • 説明文には「拡張が実際に何をするか」を具体的に書く。宣伝文句だけでなく、動作の説明を優先する
  • スクリーンショットは実際の画面（ポップアップや設定画面）をそのまま使う。加工しすぎた画像は差し戻しの対象になりうる
  • プライバシーポリシーのURLを求められるので、簡単でよいので専用ページを1つ用意しておく。個人開発だからと省略すると、後述するように審査で止まる

zipアップロードと審査

コードをzip化してアップロードすると、自動チェックと人によるレビューが行われます。自分の体感では、初回提出から結果が出るまで数日単位でした。差し戻された場合は理由がメールで届くので、該当箇所を直して再提出します。

審査で弾かれやすい点

実際に経験した・見聞きした範囲だと、弾かれやすいのは次のようなケースでした。

  • 要求権限が実装内容に対して過剰: 使っていない権限がmanifest.jsonに残っている、あるいは説明文で権限の必要性が読み取れない
  • 説明不足: 拡張が何をするのか、なぜその権限が必要なのかが説明文から伝わらない
  • プライバシーポリシー未整備: 個人情報やユーザーデータを扱わない拡張でも、ポリシーページ自体が存在しない・リンク切れになっていると差し戻される

いずれも「機能を削る」対応ではなく「説明を足す・権限を削る」対応で解決できることがほとんどです。逆に言うと、権限を最小限にしておくほど、説明文で言い訳しなければいけないことも減ります。

公開後の更新（バージョン上げて再提出）

公開後にコードを直す場合は、manifest.jsonのversionを上げてから同じ手順でzipを再アップロードします。

"version": "1.0.4"

バージョン番号を上げ忘れると同じ番号のまま提出できずエラーになるので、更新のたびに必ず上げる習慣にしています。軽微な修正でも初回と同様に審査が入るため、「公開したら終わり」ではなく、更新のたびに多少の待ち時間があることは織り込んでおくとよさそうです。

おわりに

Chrome拡張の公開は、コードを書く力とは別に「権限を絞る」「説明を尽くす」というストア側の作法に合わせる作業が必要になります。今回のQR Sendでの経験を踏まえると、最初から権限を絞り込んで説明文を具体的に書いておくのが、結局いちばん近道でした。QR Send自体の機能については以前の記事（https://www.katsulog.tech/qr-send-chrome-extension-intro/）で紹介しているので、よければあわせてどうぞ。

コメント

タイトルとURLをコピーしました