Chrome拡張機能は説明文ではなくマニフェストで判断する

私はChrome拡張機能を運営しています。そのマニフェストはidentity権限、自分のSupabaseバックエンドに限定したホスト権限、そして——このどちらよりも重要なことに——訪れるすべてのhttp://およびhttps://ページで動作するコンテンツスクリプトをリクエストします。実際にChromeの最も広範な「アクセスしたサイトのすべてのデータの読み取りと変更」という警告を引き起こしているのは、このコンテンツスクリプトであって、バックエンドのホスト権限ではありません。これらすべてが何のためにあるかについては、このサイトの別記事で全体を詳しく説明しています。ここで改めて、しかも冒頭で名指ししているのは、「拡張機能はセールストークではなくマニフェストで判断する」という主張全体を持つ記事が、まず自分自身の著者に向けられても成立して初めて、その主張をする権利を得るからです。

それを踏まえた上で、実際にマニフェストをどう読むか、そして人々が毎日インストールしている8本の拡張機能にこの方法を当てはめると何が見えてくるか、そして自分の拡張機能がどこに位置するかについての自己批判的な考察をお届けします。

自分でどんな拡張機能のマニフェストも読む方法

Chrome ウェブストアのインストールプロンプトは要約にすぎません。マニフェストが原典です。両者を比較する前に知っておくべきことがいくつかあります。

• 権限、ホスト権限、コンテンツスクリプトは、それぞれ独立して同じ広範な警告を引き起こしうる3つの別々の宣言です。 ある拡張機能はpermissions配列だけを見ると狭く見えても、広いmatchesを持つcontent_scriptsブロックや、<all_urls>のhost_permissionsエントリのせいで、実はすべてのページで動作していることがあります。インストールプロンプトがたまたま最初に要約するものだけでなく、3つすべてを読んでください。
• 宣言された権限は上限であり、実際に使われている保証ではありません。 マニフェスト上は広いアクセスを宣言していても、より狭いデフォルトの動作を出荷し、その機能が必要とする場合に明示的にオプトインしたときだけフルスコープを行使する拡張機能もあります。これは思い込みで済ませず確認する価値のある実際の区別です。そして逆方向にも成り立ちます——紙の上では狭く見えるマニフェストでも、持っているアクセスを使って知っておくべき何かをしていることもあります。
• optional_permissionsとoptional_host_permissionsは、インストール時に同じアクセスを要求するのとは意味的に異なる主張です。 特定の機能をクリックした瞬間にだけChromeが求める権限は、すべてのインストールに束ねられている同じ権限よりも、たとえ発動後に得られるAPIアクセスが同一だったとしても、より小さく、より説明責任のある要求です。
• Manifest V3は、リスクのカテゴリを丸ごと1つ、構造的に閉じています。 拡張機能はもはや実行時にリモートサーバーから任意のJavaScriptを取得して実行することができません。これはもはや控えめな推奨ではありません。Chromeは2025年にManifest V2拡張機能の実行を停止しており、Googleは2026年8月31日をもって、残っているMV2拡張機能をChrome ウェブストアから完全に削除します。V3へ移行していない拡張機能は、もはや「一応確認しておくべきもの」ではなく、すでに動作しないか、まもなく消えるもののどちらかです。
• オープンソースなら、要約ではなく実際のリポジトリ内のmanifest.jsonを読んでください。この記事の要約も含めてです。 クローズドソースなら、Chrome ウェブストア掲載ページ自体の権限開示が、入手できる中で最も信頼できる公開情報です。ソースコードほど詳細ではありませんが、それでもその上にある機能説明よりは正確です。
• 端末から何が、どんな条件で出ていくのかを名指ししたプライバシーポリシーは、「サービス向上のために情報を収集することがあります」と書かれたものより価値があります。 曖昧なポリシーは、拡張機能自体がどれだけ優れていても定型文にすぎません。
• これは一度きりのチェックではありません。 拡張機能の所有権は、あなたがすでにインストールしたあとで譲渡されることがあり、新しい所有者は同じ名前と同じインストール基盤のまま、新しい機能を持つアップデートを配信することがあります。それがどう見えるかは、この記事の後半で扱います。

実際の拡張機能8本に当てはめるとどうなるか

以下それぞれについて、オープンソースであればプロジェクト自身のGitHubリポジトリから、そうでなければChrome ウェブストア自体の権限開示から、実際のマニフェストを取得しました。

この表から埋もれさせず取り出しておく価値があることがいくつかあります。OneTabとGoFullPageは、この中で最もホストアクセスが少なく、どちらも自由にアクセスできるサイトを1つも要求していません。それは偶然ではありません。タブ一覧ツールとスクリーンショットツールは、実際に操作した以上のページコンテンツを見る必要が本質的になく、だから要求しないのです。しかし「アクセスが最も少ない」は「読む価値のある権限が何もない」とは違います。OneTabは依然としてtabsを宣言しており、これはクリックした1つのタブだけでなく、今開いているすべてのタブのURLとタイトルを渡してしまいます。これは、他のどれよりも狭く見えるツールについて知っておくべき、本物の具体的な事実です。（タブの溜め込みが実際に解決したい問題なら、OneTabとSecond Bookmark Barの比較も、どちらのアプローチにするか決める助けになるよう書いてあります。）Bitwarden、Privacy Badger、Dark Reader、Vimiumはいずれもインストール時から広く、いずれも妥当です。それぞれが行うことが構造的にすべてのページを見る必要があるからです——自動入力、サイト横断のトラッカー検出、CSSの書き換え、そしてユニバーサルなキーボードキャプチャは、Webの一部でしか動かないバージョンを持ちません。ClearURLsはマニフェストの理由だけで見れば同じグループに属するはずです（URL書き換えはすべてのURLを見る必要がある）が、その根拠がほぼ理論上のものになっていることも知っておく価値があります。Manifest V2から一度も移行しておらず、Chromeは2025年にMV2拡張機能の実行を停止しています。

uBlock Origin Liteは最も興味深いケースであり、私が最初の読みで間違えた例でもあります。そのマニフェストは確かに<all_urls>を、一切の留保なく宣言しています。しかし、その宣言はほとんどのユーザーが決してオンにしないオプションモードの上限です。デフォルトで有効になっているモード「基本」は、declarativeNetRequestの事前コンパイル済みルールセットだけでブロックし、特定のサイトで明示的にフィルタリングレベルを上げない限り、実際にページの内容を読み取ることはありません。教訓は「uBlock Origin Liteの権限はゼロだ」ではありません——それは誤りです。そうではなく、マニフェストが教えてくれるのは拡張機能ができる最大値であり、それが日々実際に意味を持つかどうかを知るには、デフォルトで実際に何をしているかを別途確認しなければならない、ということです。

そして、自分の番です。Second Bookmark Barはこの表のトップには立たず、そうあるべきでもありません。すべてのページで動作するコンテンツスクリプトは、正真正銘の広範なアクセスであり、「ドラッグしたときだけ要素を読み取る」というのは、マニフェストが宣言している内容を何も変えません。それは、この表の他のすべての行に適用しているのと同じ基準であり、自分の行にも適用しなければ、この記事全体が権限監査の衣をまとったマーケティングになってしまいます。そのコンテンツスクリプトが持っているアクセスで実際に何をし、何をしないかについての詳細な、事例ごとの説明が必要なら、こちらが安全性についての全体記事です。会社を代表して評価している場合には、同じ開示のセキュリティレビュアー向けバージョンもあります。

権限確認は一度きりのチェックではない

2026年2月、QuickLensという「Google Lens」風の画面検索ツールで、インストール数約7,000のChrome拡張機能が所有者を変更しました。発表からほどなくサードパーティの拡張機能マーケットプレイスに売りに出されており、2月1日までには、別の名前で運営する新しい所有者のもと、研究者たちが「ほとんど機能していない」と評したドメインでホストされたプライバシーポリシーに差し替えられていました。2月17日、新バージョンが配信され、MetaMask、Phantom、Coinbase Walletを含む複数のインストール済み暗号資産ウォレットを検出し、それらを空にするために必要な認証情報を収集しようとするコードが追加されました。複数のセキュリティ研究者やメディアが、これを噂ではなく、実際に確認されたサプライチェーン事件として報じています。

そのストーリーには、ほとんどのユーザーが気づくようなマニフェストの変更は一切必要ありませんでした。拡張機能のインストール基盤も、名前も、掲載情報も同じままでした。変わったのは、誰がそれを支配していたか、そしてその新しい所有者が何を配信することにしたかです。それが上のすべての正直な限界です。マニフェストを読むことは、現在それを支配している人々が、今この瞬間に何ができるかを教えてくれます。1年後に誰がそれを支配し、何を追加することにするかは教えてくれません。インストール時に一度権限を確認するのは合理的な習慣です。そのチェックを永続的なものとして扱うのは、そうではありません。

会社のChromeが拡張機能をブロックしている場合

この監査のすべては、インストールプロンプトを目にする前に、雇用主のChromeポリシーが拡張機能を完全にブロックしてしまっている場合には関係ありません。これは、実際に危険なマニフェストであるケースよりもはるかによくある、別の状況です。あの灰色の「組織によりブロックされています」ダイアログに遭遇したことがあるなら、それが実際に何なのか、インストール申請の流れがどう動くのか——IT管理者が承認を求められたときに実際に何を見るかも含めて——まとめてあります。逆に、自分だけでなくチームのために拡張機能を承認するかどうか判断する立場にあるなら、そのレビュアーのために書かれた権限ごとのレビューが、その判断のために作られたページです。