マニュアル: ブラウザ拡張機能を構築する

Priyaさん——先週、作っている価格下落ウォッチャーは「念のため」商品ページを毎分ポーリングすべきかと聞かれましたね。それを組み込む前に、全体を説明させてください。実はポーリング間隔は最も小さな判断であり、最初に構成を正しくしておけば、ローンチ前のレビューを1、2回省けるからです。

まずプロンプト自体から始めましょう。「このページを監視して、価格が下がったら教えてくれる拡張機能」とおっしゃいましたね。良いアイデアですが、まだ仕様にはなっていません——ビルダーは何をするかだけでなく、いつ動作するかを知る必要があります。あなたのウォッチャーは3つのトリガー形態のうち3番目にあたります。あなたには他の2つは不要ですが、知っておく価値はあります。というのも、形態によって必要な権限が決まり、権限によってレビューにかかる期間が決まるからです。

• クリックで実行が最も安価です:誰かがツールバーアイコンを押した時に現在のページに対して一度だけ実行されるポップアップです——「このページのすべての価格をリストに取り込む」といったイメージです。
• 常時稼働のコンテンツスクリプトは、指定したURLパターンで自動的に実行されます——あるドメイン配下のすべてのページで競合他社の名前をハイライトする、といった用途に向いていますが、パターンは明示的に指定する必要があります。「社内サイトで」と言っても、意図したより狭く解釈されてしまうためです。
• あなたのケースは3番目です:バックグラウンドウォッチャー——タブが開いているかどうかに関わらず状態が持続し、MV3のサービスワーカー上で動作し、何か変化があればアイコンにバッジを表示します。

これは、ビルダーが確認の質問であなたに問い返してくるべき唯一の形態であり、実際にそうなります——ポーリングの数値は形式的なものではなく、実際のトレードオフだからです。

それが「毎分」という直感の話に戻ります。以前、ほぼあなたと同じもの——ページを監視し、価格変化があればアイコンにバッジを表示する——を依頼したことがあり、最初のパスは60秒ごとにポーリングしていました。1人がローカルでテストする分には問題ありませんでした。しかし実際にこれをインストールする人数分だけ掛け算すると、理由もなく誰かの商品ページを叩き続けることになります。通常の小売の商品ページで、価格が1日に何度も変わることはまずないからです。プロンプトでは「30分ごとに確認」とビルダーに伝えてください。これは妥協ではなく、より正直な要求です——ブラウザ拡張機能に1分未満の通知を求める人はいませんし、レビュアーに「なぜこの拡張機能は1日1,440回も母艦に連絡するのか」を説明せずに済んで、後で自分に感謝することになるはずです。

考える必要のない部分

マニフェストについて不安だとおっしゃっていましたね——大丈夫です、それこそ本当に触る必要のない唯一のものです。両方のストアは現在マニフェストV3を必須としています。MV2は新規リスティングでは受け付けられなくなり、Chromeはまだ稼働中のMV2拡張機能を積極的に段階的廃止しています。MV3の目玉となる変更は、バックグラウンドロジックが常駐型のバックグラウンドページの代わりにサービスワーカーとして実行されることです——イベントが起きると起動し、イベントの合間にブラウザによって停止されうるため、状態は単に変数に保持するのではなく chrome.storage を経由させる必要があります。これはまさにビルダーがデフォルトで正しく書くタイプのライフサイクルの詳細です。マニフェストファイルは、あなたが自分から探しに行かない限り目にすることはないでしょう。

実際に注意を払うべきなのは権限です。というのも、レビューの速さを左右するのはコードではなくそれだからです。あなたのウォッチャーはポーリングのために alarms が必要で、おそらく最後に確認した価格を記憶するために storage も必要ですが——不要なのは tabs または <all_urls>です。もし「将来的に拡張するかもしれないから、いずれどんなサイトでも動作できるようにしたい」と依頼すると、ビルダーはその通りに構築してしまい、まだ存在しない機能のために広範なホストアクセスを要求することになります。それはインストールダイアログの中で最も不安を煽る一文——「アクセスするすべてのサイトのデータを読み取り、変更する」——であり、自動レビューを手動レビューに引き上げる原因にもなります。今日それが何をするかを記述してください。本当に必要になったら、後で拡大すればいいのです。

これで完成と言う前に、あと2つ、30秒ほど注意を払う価値があるものがあります:ポップアップUIとアイコンです。

• ポップアップUI——デフォルトのオプションページ、階層のないただのチェックボックスの羅列は、拡張機能が実際に動作するかどうかとは無関係に星1つのレビューを生む本当の原因です。あなたの場合、設定はほんの数個(URL、おそらく間隔)しかありませんが、それでもフォームの寄せ集めではなく、製品の一部らしく見えるべきです。
• アイコン——Chromeの4つのサイズすべて(16、32、48、128px、Firefox用には若干異なるマトリックス)でアイコンを確認してもらってください。128pxではくっきり見えるロゴでも、16pxでは滲んでしまうことがあり、しかもそのサイズこそが混雑したツールバーの中で一日中表示される場所だからです。

どちらのストアにも触れる前に

これを実際にテストしてください、チャットのプレビューだけでなく。ビルドから得られるのは実際に読み込み可能な拡張機能ですから chrome://extensions、開発者モードをオンにして「パッケージ化されていない拡張機能を読み込む」を選び、実際に気になっている本番のプロダクトページに対して動かしてみてください——それを模したバージョンではなく。個人的に手動で確認するのは次の2点です。インストール時の権限プロンプトは、あなたがリクエストした内容から予想される表示になっているか。そして、コンテンツスクリプトが想定外のページに当たったときに何が起こるか——静かに失敗するのか、それとも目に見えるエラーを出すのか。どちらも1分もかからず確認できますが、見てみれば一目瞭然、見なければ気づかない類のバグです。

実際に公開する準備ができたら、両方のストアで自分自身の開発者アカウントを通して手続きすることになります——リスティングはあなた自身が所有するもので、このプラットフォームが代わりに管理するわけではありません。そして、2つのストアはまったく対称ではないことを伝えておきたいです。同じだと思ってローンチ日を計画してほしくないからです。

ビルド完了後に生成されるリスティングキットは、モックアップではなく実際に動作している拡張機能から撮影されたスクリーンショット、リスティングのコピー、そして記憶ではなく実際のコードと照合されたプライバシー慣行の回答も作成します。この最後の部分は、外部ページとやり取りするもの向けには見た目以上に重要です。Chromeのプライバシーアンケートはデータ処理について単純な「はい/いいえ」形式で尋ねますが、ウォッチャーが価格をポーリング・保存しているのに「データを収集していますか」に「いいえ」と答えるのは、公開前に却下されるだけでなく、公開後に取り下げられる類のちょっとした不誠実さです。答えを実際のコードと照合しておくことで、そのギャップは自動的に埋まります。

最後に一つ、あなたのことはよく分かっているので言いますが——公開後に「複数デバイス間でウォッチリストを同期する」「時系列で価格履歴を追跡する」を追加したいと、もう考えているのではないでしょうか。それは構いませんが、それぞれが新しい権限を意味し、新しい権限はたった今通過したものより遅いレビューを意味しかねないことは知っておいてください。より大きなバージョンが欲しいと確信しているなら、今それをプロンプトに含めて、ゆっくりしたレビューを一度受ける方が、権限を少しずつ増やしていくよりも本当に良い方法です。まだ確信が持てないなら、今あるものを公開してください——きちんとスコープを絞ったウォッチャーは早く通過し、実際の利用実績を得られます。そして今この瞬間は、長い機能リストがChromeのキューで待たされているよりも、実際の利用実績の方がずっと価値があります。後からいくらでも追加を依頼できますが、まだ必要のなかったもののせいで手動レビューで止まってしまったローンチは、取り戻せません。