Chrome Extension Kit

ARTICLE

Manifest V3で最初に理解すること

Manifestとservice workerの構成を表す階層図。

Manifest V3 は、現在の Chrome 拡張開発で前提になる拡張機能プラットフォームです。 新しくChrome Web Storeへ提出する拡張では Manifest V3 を前提に考える必要があります。

Manifest V3を理解するときに最初に見るべきなのは、JavaScriptの細かい書き方ではなく、拡張全体の役割分担です。 どの処理がユーザーに見える画面で動くのか、どの処理がバックグラウンドで動くのか、どの処理がWebページの中へ入るのかを分けて考えると、設計の見通しがよくなります。

manifest.json は拡張機能の入口です。 ここには拡張名、バージョン、Manifestのバージョン、PopupやOptions pageのパス、service worker、必要な権限などを書きます。 このファイルは単なる設定ではなく、Chromeに対して「この拡張は何をする予定なのか」を伝える契約のようなものです。

Manifest V3では、従来の永続的なバックグラウンドページではなく、extension service worker がバックグラウンド処理を担当します。 service worker は必要なときに起動し、処理が終わると停止する前提で設計します。 そのため、メモリ上の変数に状態を持ち続ける設計は避け、必要な状態は chrome.storage やサーバー側へ保存します。

この性質は、有料Chrome拡張でも重要です。 たとえば「購入済みかどうか」を service worker の変数だけで持つと、worker が停止したあとに状態が失われます。 ライセンス状態は保存領域にキャッシュし、重要な判定はサーバー側APIで再確認できる設計にするべきです。

拡張ページには、Popup、Options page、Side panel などがあります。 これらは通常のWebページに近いUIとして作れますが、拡張機能の権限やCSPの制約を受けます。 外部から任意のJavaScriptを読み込んで実行する設計は避け、拡張パッケージに含まれるコードで機能が分かる状態にします。

Manifest V3の学習で大切なのは、最初から全APIを覚えようとしないことです。 まずは manifest.json、Popup、Options page、service worker、storage の5つだけを押さえれば、小さな拡張は作れます。 その上で、Content script、host permissions、Chrome Web Storeのポリシー、有料機能のライセンス確認へ進むと、理解が崩れにくくなります。

References