Microsoft Edge拡張機能の公開は、.zipファイルをアップロードして終わりではありません。2026年5月時点の公式情報で特に重要なのは、Partner Centerでの公開手順に加えて、プライバシー情報、権限の利用理由、リモートコードの有無、ストア掲載文の正確性を実装内容と矛盾なく申告することです。これらを後回しにすると、審査の遅延、再提出、企業内展開時のブロックにつながりやすくなります。Microsoft Edge拡張機能は、開発・テスト後に Microsoft Edge Add-ons へ公開し、Partner Centerを通じて配布する流れが基本です。既存のChrome拡張機能をMicrosoft Edge向けに展開する場合も、公開前に移植・互換性・ストア掲載情報を確認しておく必要があります。(Microsoft Learn)
Microsoft Edge拡張機能の公開でまず押さえるべき結論
Microsoft Edge拡張機能を公開する開発者は、次の4点を最優先で確認してください。
| 確認項目 | 実務上の意味 | 見落とした場合のリスク |
|---|---|---|
| Privacy情報 | 拡張機能の目的、権限、データ収集、プライバシーポリシーを申告する | 審査遅延、追加確認、却下 |
| 権限の理由 | manifestで要求した権限ごとに、なぜ必要か説明する | 過剰権限と判断されやすい |
| リモートコード | Manifest V3ではリモートホストされたコードの読み込み・実行が許可されない | 実装修正、再パッケージ化 |
| ストア掲載情報 | 説明文、ロゴ、スクリーンショット、検索語句を整備する | ユーザーに機能が伝わらない、入力エラーで公開できない |
今回のポイントは、公開フローが「提出作業」から「透明性を示す申告作業」へ重みを増している点です。特にPrivacyページでは、拡張機能の単一目的、権限の利用理由、リモートコード、データ利用、プライバシーポリシーを入力する構成が示されており、不完全・誤解を招く・不正確な開示は、追加レビューや認定遅延、却下につながる可能性があります。(Microsoft Learn)
何が変わるのか：注目すべき変更点と実務への影響
Privacy情報の入力がより重要になる
公式ドキュメントでは、Partner Centerの公開フロー内でPrivacy情報を専用ページに入力する形が示されています。更新のロールアウト状況によっては、従来どおりPropertiesページにPrivacy項目が表示される場合もありますが、開発者は今後「Privacyページでまとめて申告する」前提で準備したほうが安全です。(Microsoft Learn)
開発者が準備すべき内容は、単なるプライバシーポリシーURLだけではありません。たとえば、次のような説明を事前に用意しておくと、Partner Centerでの入力がスムーズになります。
| 入力項目 | 良い説明の例 | 悪い説明の例 |
|---|---|---|
| Single Purpose | 「社内SaaSの申請画面で、ユーザーが選択したテンプレートをフォームに入力補助する」 | 「業務を便利にする」 |
| Permission justification | 「storageはユーザーが選択したテンプレートIDをローカル保存するために使用する」 | 「必要だから」 |
| Data usage | 「メールアドレスを識別子として利用し、外部送信はしない」 | 「個人情報は扱わない」だけで実装説明がない |
| Privacy policy | 収集データ、利用目的、保存期間、第三者提供の有無を明記 | 汎用的な会社サイトのプライバシーページだけ |
ポイントは、実装、manifest、ストア説明文、Privacy申告の内容を一致させることです。コード上はユーザーデータを扱っているのに、Privacy申告では「収集しない」としている場合、審査で矛盾と見なされる可能性があります。
権限は「必要最小限」と「理由の明文化」が前提になる
Partner CenterのPrivacyページでは、manifestで宣言した権限ごとに利用理由を入力する項目が表示されます。不要な権限が残っている場合は、提出前にmanifestから削除し、新しいパッケージをアップロードすることが推奨されています。Microsoftの公式情報でも、拡張機能は機能提供に必要な最小限の権限のみを要求すべきだとされています。(Microsoft Learn)
たとえば、すべてのWebサイトにアクセスできる広いhost permissionを指定している場合、実際に必要なのが自社ドメインだけなら、対象を絞るべきです。
{
"host_permissions": [
"https://example.co.jp/*"
]
}「将来使うかもしれないから広めに取る」という設計は避けてください。審査だけでなく、企業管理者が拡張機能を許可する際にも、過剰な権限はブロック理由になります。
Manifest V3ではリモートコードに注意が必要
公式ドキュメントでは、リモートコードはManifest V2でのみサポートされ、Manifest V3ではリモートホストされたコードの読み込みや実行は許可されないと説明されています。また、リモートコードを使用する場合は理由を申告する必要があり、追加レビューや認定時間の増加につながる可能性があります。(Microsoft Learn)
実務では、次のような実装を見直してください。
| 見直すべき実装 | 対応方針 |
|---|---|
| 外部URLからJavaScriptを読み込んで実行する | 拡張機能パッケージ内に同梱する |
| CDN上のスクリプトに依存している | ローカルファイル化し、バージョン管理する |
| サーバーから取得した文字列をコードとして実行する | データとして処理し、実行コードにしない |
| Manifest V2のまま運用している | Manifest V3移行の影響を洗い出す |
特にChrome拡張機能をMicrosoft Edge向けに移行する場合、見た目の動作確認だけでなく、manifest_version、権限、リモートコード、外部通信先まで確認する必要があります。
AIによる説明文生成は便利だが、最終責任は開発者にある
Partner Centerには、拡張機能の説明文をAIで生成する機能が用意されています。AIはアップロード済みの拡張機能パッケージ、manifest、コードファイル、画像、スクリーンショット、任意のプロンプト入力などをもとに説明文を生成します。ただし、生成文はそのまま公開するのではなく、開発者が内容を確認し、必要に応じて編集する前提です。公式ドキュメントでも、AI生成文が不正確になる可能性があり、公開前に検証・編集することが強く推奨されています。(Microsoft Learn)
AI生成を使う場合は、次の観点で必ず人間が確認してください。
- 実装していない機能を説明していないか
- 収集しないデータを収集すると書いていないか
- 逆に、実際に扱うデータや権限の説明が抜けていないか
- 日本語説明文として、ユーザーが導入判断できる具体性があるか
- 法務・セキュリティ部門の確認が必要な表現が含まれていないか
AI生成は「下書き作成の補助」と考えるべきです。審査やユーザーからの問い合わせに対応するのは、AIではなく公開者です。
対象者別の影響範囲
新規にMicrosoft Edge拡張機能を公開する開発者
新規開発者は、公開前にPartner Centerの開発者アカウント、拡張機能パッケージ、manifest、ストア掲載情報、Privacy情報を一通り準備する必要があります。拡張機能パッケージは.zip形式で、manifest、画像、その他必要ファイルを含めます。manifest内の名前や説明はストア掲載にも反映されるため、後で直せばよいと考えず、アップロード前に表記を確認しておくことが重要です。(Microsoft Learn)
特に注意したいのは、manifest由来の項目です。ストア掲載ページで編集できる項目もありますが、拡張機能名や短い説明など、manifest更新と再アップロードが必要になる項目があります。公開直前に表記ゆれが見つかると、パッケージ作成からやり直しになる可能性があります。
既存のChrome拡張機能をMicrosoft Edgeに移行する開発者
既存のChrome拡張機能をMicrosoft Edge向けに公開する場合、Chromiumベースであることから多くの実装を流用できます。ただし、Microsoft Edge Add-onsへの公開には、Partner Centerでの提出、ストア掲載情報、Privacy申告、Microsoft Edge向けの審査が必要です。公式情報でも、既存のChrome拡張機能をMicrosoft Edgeユーザー向けにリリースする場合は、Microsoft Edgeへの移植情報を確認するよう案内されています。(Microsoft Learn)
移行時は、次の順番で確認すると失敗を減らせます。
| 順番 | 確認内容 | 判断基準 |
|---|---|---|
| 1 | Microsoft Edgeで主要機能が動くか | edge://extensionsで読み込み、業務フローを実行できる |
| 2 | manifestがEdge公開に適しているか | name、description、permissions、default_localeが適切 |
| 3 | リモートコードがないか | Manifest V3で外部コード実行に依存していない |
| 4 | 権限が過剰でないか | 機能ごとに権限の必要性を説明できる |
| 5 | ストア掲載文がEdge向けか | Chrome専用表現や古いスクリーンショットが残っていない |
「Chromeでは動いていた」だけでは、公開準備としては不十分です。Microsoft Edge Add-onsでユーザーが見る説明文、企業管理者が見る権限、審査担当者が見るPrivacy申告まで整える必要があります。
企業のIT管理者・セキュリティ担当者
企業管理者にとって、Microsoft Edge拡張機能の公開情報は「社内で許可するか」「強制配布するか」「どのサイトでは実行させないか」を判断する材料になります。Microsoftの管理者向けガイダンスでは、組織は拡張機能を評価し、ユーザーや企業データへのアクセスを管理する必要があるとされています。また、拡張機能をブロック・許可したり、必要な拡張機能を強制インストールしたり、必要最小限の権限だけを許可する考え方が示されています。(Microsoft Learn)
公開された拡張機能を企業内で展開する場合は、次の観点を確認してください。
| 管理項目 | 確認すべきこと |
|---|---|
| 拡張機能ID | 強制インストールや許可リストに使うIDを確認する |
| 権限 | 社内ポリシー上、許可できる権限か確認する |
| host permission | 社内の機密サイトにアクセスできる範囲を確認する |
| 更新方法 | Microsoft Edge Add-ons経由か、別の更新URLを使うか確認する |
| 展開範囲 | テスト、パイロット、本番の段階展開にする |
| ユーザー影響 | ユーザーが無効化できない設定にするか判断する |
ExtensionInstallForcelistを使うと、ユーザー操作なしで拡張機能を自動インストールできます。このポリシーでインストールされた拡張機能はユーザーがアンインストールまたは無効化できず、権限も暗黙的に付与されます。また、このポリシーはExtensionInstallBlocklistより優先され、リストから削除した拡張機能は自動的にアンインストールされます。(Microsoft Learn)
強制インストールは便利ですが、影響も大きい設定です。全社展開前に、少人数の検証グループで業務アプリ、認証、プロキシ、DLP、EDRとの相性を確認してください。
公開前に確認すべき設定と提出項目
manifest.jsonの確認ポイント
manifestは、審査・ストア掲載・企業管理の基礎情報になります。公開直前ではなく、開発中から次の項目を整理してください。
| 項目 | 確認ポイント |
|---|---|
name | ストア上で表示したい名称になっているか |
description | 機能が分かる説明になっているか |
permissions | 不要な権限が残っていないか |
host_permissions | 対象ドメインを広く取りすぎていないか |
manifest_version | Manifest V3前提でリモートコードに依存していないか |
default_locale | 多言語対応時に設定されているか |
_locales | 各言語のmessages.jsonが正しく配置されているか |
多言語対応でよくある失敗は、_localesフォルダーを用意しているのに、manifestのnameやdescriptionが固定文字列のままになっているケースです。この場合、Partner Centerで複数言語が検出されないことがあります。公式ドキュメントでは、nameとdescriptionをi18nプレースホルダーに置き換え、default_localeを指定し、各言語のmessages.jsonを適切に配置する方法が示されています。(Microsoft Learn)
{
"manifest_version": 3,
"name": "__MSG_extensionName__",
"description": "__MSG_extensionDescription__",
"default_locale": "ja"
}_locales/ja/messages.jsonの例は次のようになります。
{
"extensionName": {
"message": "社内フォーム入力補助"
},
"extensionDescription": {
"message": "社内申請フォームでテンプレート入力を補助するMicrosoft Edge拡張機能です。"
}
}日本語と英語の両方で公開する場合は、ストア掲載文だけでなく、manifest、スクリーンショット、サポート情報の整合性も確認してください。
Availabilityで公開範囲を決める
Partner Centerでは、VisibilityとMarketsを設定します。Visibilityには、検索や閲覧で見つけられるPublicと、検索・ブラウズには表示されずURLを共有して配布するHiddenがあります。PublicからHiddenに変更しても、Public時にインストール済みのユーザーは引き続きアクセスでき、Microsoft Edge Add-onsで提供される更新も受け取れます。(Microsoft Learn)
Marketsは、拡張機能を提供する市場を指定する項目です。既定では、今後追加される市場も含めたすべての市場が対象になります。市場設定を変更した場合、対象市場で利用可能なときにインストールしたユーザーは拡張機能へアクセスできますが、提供対象外になった市場のユーザーは将来の更新へアクセスできなくなる点に注意が必要です。(Microsoft Learn)
| 配布パターン | おすすめ設定 | 注意点 |
|---|---|---|
| 一般ユーザー向けに広く公開 | Public、対象Marketsを明確化 | サポート対象地域と言語を一致させる |
| 取引先・限定ユーザー向け | Hidden、URL配布 | URL管理とサポート導線を用意する |
| 社内利用中心 | Hiddenまたは別途企業ポリシー展開 | 強制配布ポリシーとの整合性を確認する |
| 一部地域で未対応 | Marketsを絞る | 更新提供の影響を事前に確認する |
Hiddenは「非公開」ではなく、「検索に出ない公開」です。URLを知っているユーザーはアクセスできるため、機密性の高い社内専用機能をHiddenだけで守る設計は避けてください。
Store Listingsでユーザーに伝わる情報を整える
ストア掲載情報は、審査担当者だけでなく、インストールを検討するユーザーや企業管理者も見る情報です。公式ドキュメントでは、説明文は各言語で必須、長さは250文字以上10,000文字以下で、機能を明確・完全・適切に説明する必要があるとされています。また、ロゴは各言語で必須、検索語句は任意ですが、最大21語、最大7件、各検索語句30文字までという制限があります。(Microsoft Learn)
説明文には、次の情報を入れると導入判断がしやすくなります。
- 何をする拡張機能か
- 誰に向いているか
- どの画面・サイトで使うか
- どのデータを扱うか
- 外部サービスと通信するか
- 管理者向けの注意点
- サポート窓口やヘルプページ
悪い例は「業務を効率化する便利な拡張機能です」のような抽象的な説明です。良い例は「社内申請フォームで、ユーザーが選択した申請テンプレートをフォームに反映し、入力ミスを減らします。対象サイトはexample.co.jp配下で、設定情報はローカルストレージに保存します」のように、機能・対象・データの扱いが具体的な説明です。
審査・公開時に失敗しやすいポイント
認定テスト用メモを空欄にしない
拡張機能を提出する際は、認定テスト担当者向けのNotes for certificationを入力できます。公式ドキュメントでは、テスト用のユーザー名・パスワード、隠し機能やロックされた機能にアクセスする手順、地域や設定による機能差、既存拡張機能の更新内容などを記載する例が示されています。提出後、認定プロセスには最大7営業日かかる場合があります。(Microsoft Learn)
特にログインが必要な拡張機能では、テストアカウントがないと審査担当者が機能を確認できません。次のようなメモを用意しておくとよいでしょう。
テスト手順:
1. Microsoft Edgeで拡張機能をインストールします。
2. https://example.co.jp/demo にアクセスします。
3. 以下のテストアカウントでログインします。
ID: [email protected]
Password: ********
4. 画面右上の拡張機能アイコンをクリックします。
5. 「テンプレートA」を選択すると、申請フォームの件名と説明欄にサンプル文が入力されます。
注意:
日本市場向けの機能です。米国リージョンでは一部の申請テンプレートは表示されません。審査担当者が再現できない機能は、開発者の環境では動いていても認定で止まりやすくなります。
Partner Centerのエラーは環境要因も疑う
提出時にPartner Centerでエラーが出る場合、公式ドキュメントでは、ブラウザーのキャッシュとCookieの削除、InPrivateまたはIncognitoモードの利用、Microsoft Edge・Google Chrome・Firefoxなど別ブラウザーでの再試行が対処法として示されています。(Microsoft Learn)
実務では、次の順番で切り分けると時間を無駄にしにくくなります。
| 症状 | まず確認すること |
|---|---|
| アップロード後に検証エラーが出る | .zip内のmanifest、不要ファイル、権限、画像パス |
| 入力項目が完了にならない | 各言語の必須項目、ロゴ、説明文の文字数 |
| Partner Center画面が不安定 | キャッシュ削除、InPrivate、別ブラウザー |
| 多言語が表示されない | manifestのi18nプレースホルダー、default_locale、_locales |
| マルウェア・PUAの可能性で止まる | 不要な権限、外部通信、難読化、不要なバイナリを見直す |
マルウェアや望ましくない可能性のあるアプリとしてフラグ付けされた場合、Microsoftはセキュリティ上の理由から正確なトリガーを開示しないとしています。公開直前に原因を探すのではなく、開発段階から過剰権限、外部コード、不要な通信、説明と実装の不一致を減らすことが重要です。(Microsoft Learn)
管理者が展開前に確認すべき運用設計
すぐ全社展開せず、段階的に配布する
企業でMicrosoft Edge拡張機能を展開する場合、公開完了後にすぐ全社員へ配布するのは避けたほうが安全です。Microsoftの管理者向けガイダンスでも、必要な拡張機能のリスト作成、テスト環境での検証、機密サイトの確認、必要権限の判断、マスターリスト作成、小規模な試験運用、段階的展開、フィードバック確認、定期的な見直しという流れが示されています。(Microsoft Learn)
おすすめは、次の3段階です。
| フェーズ | 対象 | 確認内容 |
|---|---|---|
| テスト | 開発者、IT、セキュリティ担当 | インストール、更新、権限、ログ、競合 |
| パイロット | 一部部署、実業務ユーザー | 業務フロー、問い合わせ内容、パフォーマンス |
| 本番 | 全社または対象部門 | 配布ポリシー、サポート体制、更新手順 |
特に強制インストールを使う場合、ユーザーが無効化できないため、不具合があると影響が広がります。配布前に、削除時の手順、旧バージョンへの戻し方、問い合わせ窓口も決めておきましょう。
権限ベースの許可・ブロックを検討する
従来は、特定の拡張機能を許可リストまたはブロックリストで管理する方法が一般的でした。しかし、Microsoft Edgeでは、拡張機能が要求する権限や、実行できるサイトを基準に管理する考え方も示されています。たとえば、機密性の高い社内サイトでは拡張機能の実行を制限し、業務に必要な拡張機能だけを許可する運用が考えられます。(Microsoft Learn)
管理者が公開前に開発者へ確認すべき質問は、次のとおりです。
- どの権限を要求しているか
- その権限が必要な機能は何か
- どのドメインで実行されるか
- 社内の機密サイトで実行される可能性はあるか
- 収集・送信するユーザーデータは何か
- 更新時に権限が増える可能性はあるか
- 問題発生時に無効化・削除できる手順はあるか
この質問に開発者が明確に答えられない場合、公開や社内展開の前に設計を見直すべきです。
開発者向けの公開前チェックリスト
公開直前は、以下を順番に確認してください。
| チェック項目 | 完了条件 |
|---|---|
| 機能テスト | Microsoft Edge上で主要機能が再現できる |
| manifest | name、description、permissions、host_permissions、default_localeが適切 |
| 権限 | 各権限について利用理由を説明できる |
| リモートコード | Manifest V3で外部コード実行に依存していない |
| Privacy | データ収集、利用目的、プライバシーポリシーURLが整っている |
| ストア説明文 | 250文字以上で、機能・対象者・注意点が具体的 |
| 画像 | ロゴ、必要に応じてタイル、スクリーンショットを用意 |
| 多言語 | messages.jsonとStore Listingsの各言語が一致 |
| Availability | Public/Hidden、Marketsの設定意図が明確 |
| 認定メモ | テストアカウント、操作手順、更新内容を記載 |
| 管理者展開 | 拡張機能ID、ポリシー、段階展開の計画を共有 |
このチェックリストの目的は、提出エラーを減らすことだけではありません。審査担当者、ユーザー、企業管理者が「この拡張機能は何をし、どのデータにアクセスし、なぜその権限が必要なのか」を判断できる状態にすることです。
いま取るべき次の行動
Microsoft Edge拡張機能を公開する予定があるなら、まずmanifestとPrivacy申告の棚卸しから始めてください。既存のChrome拡張機能を移行する場合も、Microsoft Edgeで動作するかだけでなく、Partner Centerで説明できる状態かを確認する必要があります。
開発者は、不要な権限を削除し、Manifest V3でリモートコードに依存しない実装へ整理します。管理者は、公開後の配布方法、強制インストールの有無、許可・ブロック方針、段階展開の計画を決めます。プライバシー担当やセキュリティ担当は、データ利用、プライバシーポリシー、ストア説明文が実装と一致しているか確認します。
Microsoft Edge拡張機能の公開で失敗しないための要点は、「公開ボタンを押す前に、審査・利用者・管理者の3者に説明できる状態にしておくこと」です。Partner Centerへの提出作業を最後の事務処理ではなく、品質・セキュリティ・展開計画を確認する最終ゲートとして扱うと、公開後のトラブルを大きく減らせます。
コメント