Manifest V3とは？Chrome拡張機能開発で知っておきたい新しい基本

公開日：2026/05/30

Chrome拡張機能を調べていると、かなり早い段階で Manifest V3 という言葉が出てきます。

前回の記事「Chrome拡張機能とは？できること・Webアプリとの違い」では、Chrome拡張機能には manifest.json、popup、content script、background service worker などの部品があると説明しました。今回は、その中でも拡張機能全体の前提になる Manifest V3 について整理します。

Manifest V3は、Chrome拡張機能を作るときの現在の基本ルールです。

ただし、初心者が最初から細かい仕様をすべて覚える必要はありません。まずは「なぜManifest V3を意識する必要があるのか」「以前の作り方と何が違うのか」「最初にどこを押さえればよいのか」が分かれば十分です。

この記事では、Manifest V3を初心者向けに解説します。実際にファイルを作って読み込む手順は後続の記事で扱い、ここでは考え方と重要な変更点に絞ります。

Manifestとは何か

まず、Manifest V3の前に、manifestとは何かを確認します。

Chrome拡張機能におけるmanifestは、拡張機能の設定を書いたファイルです。ファイル名は manifest.json です。

このファイルには、拡張機能の名前、バージョン、説明、表示するアイコン、使うファイル、必要な権限などを書きます。

Chromeは manifest.json を読んで、その拡張機能をどう扱うかを判断します。

たとえば、非常に短く書くと次のような形です。

{
  "manifest_version": 3,
  "name": "Sample Extension",
  "version": "1.0.0",
  "action": {
    "default_popup": "popup.html"
  }
}

ここで重要なのが "manifest_version": 3 です。

これは、この拡張機能がManifest V3の形式で作られていることを示します。

つまり、Manifest V3とは、単に manifest.json の中に書く数字だけではありません。Chrome拡張機能を作るときの設計方針や制約も含めた、現在の基本ルールだと考えると分かりやすいです。

Manifest V3で変わった考え方

Manifest V3では、拡張機能をより安全で、ブラウザに負担をかけにくい形にする方向へ変わっています。

初心者が最初に押さえるべき大きなポイントは、次の3つです。

ポイント	内容
background処理の考え方	常に動くbackground pageではなく、service workerを使う
コードの扱い	外部から読み込むリモートコードに依存しない
ネットワーク要求	ブロック処理や変更処理の仕組みが見直されている

細かいAPIや移行手順を最初から覚える必要はありません。

ただ、これから新しくChrome拡張機能を作るなら、Manifest V3を前提に考える必要があります。

古い記事やサンプルコードを見ると、Manifest V2向けの書き方が残っていることがあります。たとえば、background.scripts を使う例や、常に動くbackground pageを前提にした説明です。

そうした情報をそのまま使うと、現在のChrome拡張機能ではうまく動かないことがあります。

そのため、これから学ぶ場合は、サンプルコードがManifest V3向けかどうかを確認する習慣が大切です。

background page から service worker へ

Manifest V3で初心者が特につまずきやすいのが、background処理です。

以前のManifest V2では、裏側で動く処理としてbackground pageやbackground scriptを使う考え方がありました。

Manifest V3では、background処理は基本的に extension service worker として扱います。

ざっくり言えば、ずっと開きっぱなしの裏画面を持つのではなく、必要なイベントが起きたときに起動して処理する方式です。

たとえば、Manifest V2では次のような書き方を見かけることがあります。

{
  "background": {
    "scripts": ["background.js"]
  }
}

Manifest V3では、次のように service worker として指定します。

{
  "background": {
    "service_worker": "background.js"
  }
}

この違いは、単なる書き方の違いではありません。

service workerは、常に動き続ける前提ではありません。イベントに応じて起動し、必要な処理を行い、不要になれば停止します。

そのため、以前のbackground pageの感覚で「変数をずっと保持しておけばよい」「常に裏側で監視し続ければよい」と考えると、思った通りに動かないことがあります。

データを残したい場合は、chrome.storage や IndexedDB など、永続化できる場所に保存する設計が必要になります。

リモートコード禁止の考え方

Manifest V3では、リモートコードの扱いも重要です。

Chrome拡張機能では、外部サーバーからJavaScriptを読み込んで実行するような作り方は避ける必要があります。

たとえば、外部URLからライブラリを読み込んで実行する、サーバーから取得したコード文字列を eval のように実行する、といった作り方は問題になります。

なぜなら、拡張機能はユーザーのブラウザ上で動き、閲覧中のページやデータに関われる場合があるからです。あとから外部サーバー上のコードを差し替えられる設計だと、審査時に確認した内容と実際に動く内容が変わってしまうリスクがあります。

そのため、拡張機能で使うJavaScriptは、基本的に拡張機能のパッケージ内に含めます。

初心者向けに言えば、「必要なJavaScriptは拡張機能のフォルダに入れておく」と考えると分かりやすいです。

もちろん、外部APIと通信してデータを取得すること自体がすべて禁止という意味ではありません。外部APIと通信する場合でも、実行するコードは拡張機能側にあり、外部から取得した任意のコードを実行しない、という考え方が大切です。

このあたりは、公開時の審査やセキュリティにも関係します。詳細は、権限設計やChrome Web Store公開前チェックの記事で扱う予定です。

ネットワーク要求まわりの変更

Manifest V3では、ネットワーク要求まわりの考え方も見直されています。

以前の拡張機能では、ネットワーク要求を細かく監視したり変更したりする処理に webRequest API が使われることがありました。

Manifest V3では、リクエストをブロックしたり変更したりする用途では、より宣言的な仕組みである declarativeNetRequest が中心になります。

これは、拡張機能がその場で毎回リクエストを処理するのではなく、あらかじめルールを宣言しておき、Chrome側がそのルールに基づいて処理する考え方です。

初心者が最初からこのAPIの詳細を覚える必要はありません。

ただし、広告ブロック、通信制御、特定リクエストの変更など、ネットワーク要求を深く扱う拡張機能を作る場合は、Manifest V3のルールに沿って設計する必要があります。

一方で、ページ上にボタンを追加する、popupを表示する、ページタイトルやURLを保存する、といった初歩的な拡張機能では、最初からネットワーク要求まわりの詳細を深掘りしなくても始められます。

この記事では、「ネットワーク要求を扱う仕組みもManifest V3で変わっている」と覚えておけば十分です。

古いサンプルコードを見分けるポイント

Chrome拡張機能について検索すると、現在でもManifest V2向けのサンプルコードが見つかることがあります。公開日が古い記事だけでなく、更新されていないリポジトリや、以前の書き方を前提にした解説もあるため注意が必要です。

まず確認したいのは、manifest.json の manifest_version です。値が 2 なら、そのまま新しい拡張機能へ使うのではなく、Manifest V3向けに書き換える必要があります。

次に、background処理の指定方法を確認します。background.scripts や background.page が使われている場合は、Manifest V2向けの可能性があります。Manifest V3では、基本的に background.service_worker を使います。

外部URLからJavaScriptを読み込んでいないかも確認します。たとえば、HTML内で外部CDNのJavaScriptを直接読み込む例は、通常のWebページでは便利でも、Chrome拡張機能ではそのまま採用できません。必要なライブラリは、拡張機能のパッケージ内に含めます。

ネットワーク要求を変更するサンプルでは、webRequestBlocking を前提にしていないか確認します。Manifest V3では、用途に応じて declarativeNetRequest を検討します。

古いサンプルを参考にするときは、次の点を順番に確認すると判断しやすくなります。

manifest_version が 3 になっているか
background処理が service worker として書かれているか
外部から取得したJavaScriptを実行していないか
必要以上に広い権限を要求していないか
ネットワーク要求の変更方法がManifest V3向けになっているか
Chrome公式ドキュメントで現在の書き方を確認したか

すべてを一度に理解する必要はありません。まずは manifest.json を見て、Manifest V3向けのサンプルかどうかを確認する習慣を付けることが重要です。

小規模な拡張機能でも確認したい設計ポイント

Manifest V3は、大規模な拡張機能だけの話ではありません。個人用の小さなツールでも、最初に基本を押さえておくと、あとから機能を増やしやすくなります。

たとえば、popupから現在のページ情報を取得して保存する拡張機能を作る場合を考えます。popupの表示だけなら、background service workerが不要なこともあります。一方で、複数の画面から共通の処理を呼び出したい場合や、特定のイベントを受け取って処理したい場合は、service workerの役割を検討します。

ページ上の情報を扱う場合は、content scriptが本当に必要かを考えます。現在のタブのタイトルやURLを取得するだけなら、popup側からChrome APIを使う設計で足りることがあります。Webページ内の要素を読み取ったり、ボタンを追加したりする場合は、content scriptを使います。

権限も必要になった時点で追加します。最初から広い権限を要求すると、利用者に不安を与えやすくなり、公開時の説明も難しくなります。どの機能のために、どの権限が必要なのかを説明できる状態にしておくことが大切です。

データを保存する場合は、保存場所も意識します。service workerの変数だけに値を入れても、停止後に保持されるとは限りません。設定値や小さなデータは chrome.storage、履歴のように件数が増えるデータは IndexedDB など、用途に合わせて選びます。

最初の設計では、次の順番で考えると整理しやすくなります。

popupだけで完結できるか確認する
Webページ内を操作するならcontent scriptを追加する
イベント処理や共通処理が必要ならservice workerを検討する
必要な権限だけを追加する
残したいデータは永続化できる場所へ保存する

この順番で小さく作ると、Manifest V3の制約を意識しながら、必要以上に複雑な構成になることを避けられます。

初心者が最初に押さえるポイント

Manifest V3について、初心者が最初に押さえるポイントを整理します。

まず、manifest.json では "manifest_version": 3 を使います。

次に、background処理を書く場合は、Manifest V3では service worker として考えます。常に動き続ける前提ではなく、イベントに応じて動く処理として設計します。

また、必要なJavaScriptは拡張機能の中に含めます。外部からコードを読み込んで実行するような作り方は避けます。

さらに、権限や外部通信は最小限にします。どの権限が必要か、何のために使うのかを説明できるようにしておくことが大切です。

まとめると、最初に意識したいのは次の点です。

新しく作るならManifest V3を前提にする
manifest.json に "manifest_version": 3 を書く
background処理は service worker として考える
常に動き続ける前提で設計しない
JavaScriptは拡張機能パッケージ内に含める
権限と外部通信は最小限にする
古いManifest V2向けの記事やコードをそのまま使わない

Manifest V3でよくある混乱

Manifest V3でよくある混乱のひとつは、「Manifest V3にすれば何でも安全になる」と考えてしまうことです。

Manifest V3は、拡張機能の安全性やパフォーマンスを高める方向の仕組みですが、開発者が何を保存するか、どの権限を要求するか、どの外部サービスと通信するかを適切に設計する必要があります。

たとえば、ユーザーの閲覧ページから情報を取得して外部サーバーに送る場合は、その目的や送信内容を明確にする必要があります。

また、「service workerだから常に裏で動く」と考えるのも誤解です。必要なときに起動して処理するものとして扱います。

さらに、古いサンプルコードを見て background.scripts をそのまま使おうとしてつまずくこともあります。Manifest V3では、background処理の指定方法が変わっています。

最初は、公式ドキュメントや新しいサンプルを見ながら、Manifest V3向けの書き方に慣れることが大切です。

後続記事で扱う内容

この記事では、Manifest V3の全体像に絞りました。

後続の記事では、次のような内容を扱う予定です。

実際に manifest.json を書いて最小構成の拡張機能を作る
popup画面を作る
content scriptでWebページを操作する
chrome.storage で設定を保存する
IndexedDBで履歴データを保存する
権限設計とプライバシーの考え方
Chrome Web Store公開前のチェックポイント

Manifest V3は、それ単体で覚えるというより、実際に拡張機能を作りながら理解していく方が分かりやすいです。

まずは、manifest.json が拡張機能の設定ファイルであり、現在はManifest V3を前提に書く、というところから始めれば十分です。

参考リンク

まとめ

Manifest V3は、現在のChrome拡張機能開発で前提になる基本ルールです。

manifest.json に "manifest_version": 3 を書くことで、Manifest V3形式の拡張機能として扱われます。

Manifest V3では、background処理は service worker として考えます。常に動き続ける裏画面ではなく、イベントに応じて動く処理として設計します。

また、外部からコードを読み込んで実行するような作り方は避け、必要なJavaScriptは拡張機能パッケージ内に含めます。

ネットワーク要求まわりの仕組みも見直されており、通信制御を扱う拡張機能ではManifest V3のルールに沿った設計が必要です。

最初は難しく感じるかもしれませんが、初心者がまず押さえるべきことは限られています。

新しくChrome拡張機能を作るなら、Manifest V3を前提にする。manifest.json を中心に考える。background処理はservice workerとして考える。外部コードに依存しない。

この基本を押さえておくと、次回以降の実装記事でファイル構成やコードの意味が理解しやすくなります。

Manifest V3とは？Chrome拡張機能開発で知っておきたい新しい基本

Manifestとは何か

Manifest V3で変わった考え方

background page から service worker へ

リモートコード禁止の考え方

ネットワーク要求まわりの変更

古いサンプルコードを見分けるポイント

小規模な拡張機能でも確認したい設計ポイント

初心者が最初に押さえるポイント

Manifest V3でよくある混乱

後続記事で扱う内容

参考リンク

まとめ

その他のカテゴリー

Your Message コメントをキャンセル

最新記事

プロフィール

よく読まれている記事

タグ

サイト内検索

カテゴリー

Pickup

ブログの更新情報をお届け

記事が気に入ったらシェアお願いします