はじめに
業務システムを使っていると、画面にちょっとした入力補助や確認表示を追加したくなることがあります。
たとえば、コードを入力したときに名称を確認表示する、特定の画面遷移を補助する、庁内ネットワーク特有のURL変換を行う、といった用途です。
こういう用途では、Microsoft Edgeの拡張機能がかなり便利です。
ただし、自治体や閉域ネットワークの端末で配布しようとすると、すぐに次の問題に直面します。
- Microsoft Edge Add-onsに公開するわけにはいかない
- インターネット接続が制限されている
- 庁内Webサーバを自由に用意できない
- 開発者モードでは警告や確認メッセージが出る
- 手動配布では更新がつらい
- すでにSKYSEAなどの管理系拡張が入っていることがある
今回は、拡張機能の中身ではなく、閉域・庁内ネットワークでMicrosoft Edge拡張機能をどう配布するかを整理します。
前提
今回は、自治体の閉域ネットワーク内にある性質の異なる2つの環境で確認しました。
検証した環境は次のとおりです。
| 環境 | OS | Microsoft Edge |
|---|---|---|
| 閉域ネットワーク1 | Windows 11 Enterprise 10.0.22631 | 140.0.3485.130 64bit |
| 閉域ネットワーク2 | Windows 11 Pro 23H2 | 139.0.3405.111 64bit |
どちらの環境でも、インターネット上のMicrosoft Edge Add-onsや外部Webサーバを使わず、庁内のファイルサーバに置いた update.xml と .crx を参照する構成を検証しています。
一方で、端末へ正式に展開する方法は環境によって異なります。
少数端末での検証や許可された範囲での手動配布で済む場合もあれば、全端末に配布するためにGPOや端末管理の正式ルートを使う方が望ましい場合もあります。
ただし、どちらにも共通する重要なポイントがあります。
Edge拡張機能の自己配布では、更新用のXMLとCRXを置く場所として file:// URLが使える場合がある、という点です。
この記事は、私の環境での検証メモです。
組織の端末管理ルールやセキュリティポリシーによっては使えない場合があります。
結論
今回の検証では、ファイルサーバ上に置いた update.xml と .crx を、次のような file://// URLで参照する構成で動きました。
file:////server/share/EdgeExtensions/my-extension-update.xml
file:////server/share/EdgeExtensions/my-extension.crx
自前配布の拡張機能というと、庁内Webサーバに update.xml と .crx を置くイメージがありました。
しかし、少なくとも今回の環境では、Webサーバを用意しなくても、ファイルサーバ上の file:// URLで新規インストールできました。
また、更新については次の結果になりました。
ExtensionInstallForcelist のみ:
新規インストールはできた
既存拡張の更新は確認できなかった
ExtensionInstallForcelist + ExtensionSettings:
override_update_url:true を設定すると、edge://extensions/ の「更新」ボタンで更新できた
つまり、今回の検証環境では、新規配布はForcelistだけで可能、更新まで制御するにはExtensionSettingsの追加が必要でした。
大まかな構成は次のとおりです。
Edge
↓
Edgeポリシー
↓
file:////server/share/.../update.xml
↓
update.xml
↓
file:////server/share/.../extension.crx
↓
拡張機能をインストール
↓
必要に応じてExtensionSettingsで更新URLを制御
配布方法の選択肢
Edge拡張機能を閉域環境で扱う方法として、今回は開発時の読み込み方法、手動インストール、自動インストール、インストール済み拡張機能の更新まで整理します。
| 方法 | 用途 | 自動配布 | 更新 | 向いている場面 |
|---|---|---|---|---|
| 開発者モード | 開発・検証 | × | × | 自分の端末で動作確認する |
| Allowlist + ExtensionInstallSources | 手動CRX配布 | × | △ | 許可されたCRXを手動で入れる |
| ExtensionInstallForcelist | 自動・強制配布 | ○ | △ | 全端末配布する |
| Forcelist + ExtensionSettings | 自動・強制配布 | ○ | ○ | インストール済み拡張を継続更新する |
ここでいう「更新」は update.xml 経由の継続更新のことで、今回の検証では ExtensionSettings の override_update_url:true が必要でした。
1. 開発者モードで読み込む
開発中はこれが一番楽です。
edge://extensions/
↓
開発者モード ON
↓
展開して読み込み
ソースフォルダをそのまま読み込めるため、CRX化も update.xml も不要です。
ただし、業務端末に日常利用させる配布方法としては弱いです。
理由は、開発者モードで読み込んだ拡張機能では、Edge側で確認メッセージや警告が出ることがあるためです。
私の環境では、Edgeで開発者モード拡張を使っていると、開発者モード拡張機能の通知が表示されました。
Microsoft公式Supportでは、この通知は未検証または安全でない可能性がある拡張機能からユーザーを保護するためのもので、通知を無効化・非表示化することはできないと説明されています。
また、通知を表示したくない場合は、拡張機能のテストにMicrosoft EdgeのDevまたはCanaryチャネルを使うことが推奨されています。
私の環境では、この通知のメニューに「2週間後に通知する」「ブラウザーの再起動を通知する」という選択肢が表示されました。
これは通知を無効化できるという意味ではなく、再通知のタイミングを選ぶものと考えています。
業務端末で継続利用するなら、開発者モードではなく、Edgeポリシーによる配布に寄せたほうがよいと思います。
2. Allowlist + ExtensionInstallSourcesで手動インストールする
次に、CRXを手動インストールする方式です。
使うポリシーは主に次の2つです。
ExtensionInstallAllowlist
ExtensionInstallSources
ExtensionInstallAllowlist は、特定の拡張機能IDを許可するためのポリシーです。
ExtensionInstallSources は、どこから拡張機能をインストールしてよいかを許可するポリシーです。
たとえば、ファイルサーバ上のCRXを許可する場合は、次のような指定になります。
file:////server/share/EdgeExtensions/*
この状態で、CRXを edge://extensions/ にドラッグ&ドロップしてインストールします。
これは、開発者モードよりは本番寄りですが、自動配布ではありません。
整理すると、次のようになります。
Allowlist + Sources
→ そのCRXをインストールしてよい、という許可
Forcelist
→ その拡張機能を自動で入れる
個別端末での検証や、少数端末への暫定配布ならAllowlist方式でもよいと思います。
ただし、全端末に配るならForcelistのほうが向いています。
3. ExtensionInstallForcelistで自動インストールする
本番配布の本命は ExtensionInstallForcelist です。
これは、指定した拡張機能をサイレントインストールするEdgeポリシーです。
ユーザーは、原則としてその拡張機能をアンインストールしたり無効化したりできません。
レジストリでは次の場所です。
HKLM\SOFTWARE\Policies\Microsoft\Edge\ExtensionInstallForcelist
値は次の形式で登録します。
拡張ID;update.xmlのURL
例です。
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa;file:////server/share/EdgeExtensions/my-extension-update.xml
ここで重要なのは、ExtensionInstallForcelist に書くのは .crx のURLではなく、update.xml のURLであることです。
ExtensionInstallForcelist に書くもの
拡張ID;update.xmlのURL
update.xml に書くもの
CRX本体のURL
なお、今回の検証では、Forcelistだけで新規インストールはできましたが、既存拡張の更新は確認できませんでした。
更新については、後述の ExtensionSettings で対応しています。
配布ファイルの構成
ファイルサーバ上には、次のように置きます。
EdgeExtensions/
├─ my-extension.crx
└─ my-extension-update.xml
.pem は配布フォルダには置きません。
管理者保管場所/
└─ my-extension.pem
.pem は、CRX作成時に使う秘密鍵です。
同じ .pem を使ってCRXを作り直せば、拡張機能IDは維持されます。
update.xmlの例
update.xml は、Edgeに対して「この拡張機能IDの最新版CRXはここにある」と伝えるファイルです。
codebase は、Edgeが取得するCRX本体のURLを指定する属性です。
例です。
<?xml version="1.0" encoding="UTF-8"?>
<gupdate xmlns="http://www.google.com/update2/response" protocol="2.0">
<app appid="aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa">
<updatecheck
codebase="file:////server/share/EdgeExtensions/my-extension.crx"
version="1.0.0" />
</app>
</gupdate>
各項目の意味は次のとおりです。
| 項目 | 意味 |
|---|---|
appid |
拡張機能ID |
codebase |
Edgeが取得するCRX本体のURL |
version |
配布する拡張機能のバージョン |
version は、CRX内の manifest.json の version と一致させます。
たとえば manifest.json が次の場合、
{
"manifest_version": 3,
"name": "My Extension",
"version": "1.0.0"
}
update.xml も次のようにします。
version="1.0.0"
UNCパスとfile URL
WindowsのUNCパスが次の場合、
\\server\share\EdgeExtensions\my-extension-update.xml
Edgeポリシーや update.xml に指定するURLは、次のようにしました。
file:////server/share/EdgeExtensions/my-extension-update.xml
CRX本体も同じです。
\\server\share\EdgeExtensions\my-extension.crx
であれば、
file:////server/share/EdgeExtensions/my-extension.crx
です。
Windowsパスでは \ を使いますが、URLでは / にします。
レジストリで検証する
正式展開の前に、検証端末でローカルレジストリに設定して動作確認できます。
ただし、ここは注意が必要です。
まず、レジストリ変更が組織の運用上許可されている端末か確認してください。
自治体の閉域ネットワーク端末では、作業者が端末管理者ではない場合があります。
管理者権限がない端末や、端末管理ソフトで保護されている端末では、HKLM配下を書き換えられない場合があります。
また、ローカルレジストリに手動で設定できたとしても、GPOや端末管理ポリシーが再適用されると、値が削除されたり、管理側の設定で上書きされたりすることがあります。
そのため、ローカルレジストリでの検証はあくまで動作確認用と考え、全端末へ展開する場合はGPOや端末管理の正式ルートに乗せるのが安全です。
また、変更前に必ずEdgeポリシーをバックアップしておきます。
mkdir C:\Temp 2>$null
reg export "HKLM\SOFTWARE\Policies\Microsoft\Edge" "C:\Temp\edge-policy-before-change.reg" /y
戻す場合は次です。
reg import "C:\Temp\edge-policy-before-change.reg"
ExtensionInstallForcelist に自作拡張を追加する例です。
reg add "HKLM\SOFTWARE\Policies\Microsoft\Edge\ExtensionInstallForcelist" /v 2 /t REG_SZ /d "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa;file:////server/share/EdgeExtensions/my-extension-update.xml" /f
ここで /v 2 としているのは、すでに 1 に別の管理系拡張が入っていることがあるためです。
既存のForcelistを上書きしない
庁内端末では、SKYSEAなどの管理系拡張がすでに ExtensionInstallForcelist に入っていることがあります。
たとえば次のような状態です。
HKLM\SOFTWARE\Policies\Microsoft\Edge\ExtensionInstallForcelist
1 = xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx;http://localhost:xxxxx/EdgeAddon/updates.xml
この状態で、自作拡張を入れようとして 1 を上書きしてはいけません。
悪い例です。
1 = 自作拡張
良い例です。
1 = 既存の管理系拡張
2 = 自作拡張
すでに 1 が使われている場合は、2 以降の空いている番号に追加します。
この点はかなり重要です。
Edge拡張のポリシーは、業務端末管理やセキュリティ製品で使われていることがあります。
「自分の拡張を入れる」ことだけを考えて既存値を上書きすると、既存の管理系拡張を壊す可能性があります。
Edgeポリシーの再読み込み
レジストリに書いたら、Edgeで次を開きます。
edge://policy
「ポリシーを再読み込み」を押します。
ExtensionInstallForcelist に値が出れば、Edgeがポリシーを認識しています。
その後、次を開きます。
edge://extensions/
拡張機能が自動で入っているか確認します。
反映されない場合は、Edgeを完全終了して起動し直します。
Stop-Process -Name msedge -Force -ErrorAction SilentlyContinue
Forcelistだけで更新できるか確認する
まず、ExtensionSettings を入れず、ExtensionInstallForcelist だけで更新できるか確認しました。
検証内容は次のとおりです。
1. Forcelist に 拡張ID;file:////.../update.xml を登録する
2. version 1.0.0 のCRXをインストールさせる
3. manifest.json の version を 1.0.1 に上げる
4. 同じ .pem でCRXを作り直す
5. update.xml の version も 1.0.1 に上げる
6. edge://extensions/ の「更新」ボタンを押す
この状態では、既存拡張は更新されませんでした。
ExtensionSettingsで更新URLを上書きする
Forcelistだけでは更新できなかったため、ExtensionSettings を追加しました。
設定する場所はここです。
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Edge
例です。
{"aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa":{"installation_mode":"force_installed","override_update_url":true,"update_url":"file:////server/share/EdgeExtensions/my-extension-update.xml"}}
ここでのポイントは override_update_url:true です。
この設定を入れた後、edge://policy で「ポリシーを再読み込み」を押し、ExtensionSettings がOKになっていることを確認しました。
その後、edge://extensions/ で開発者モードをONにし、「更新」ボタンを押すと、拡張機能が 1.0.0 から 1.0.1 に更新されました。
更新ボタンを押さない場合
今回の検証では、edge://extensions/ の「更新」ボタンを押すと即時更新されました。
一方、押さない場合に即時更新されるわけではありません。
Microsoft Edgeの公式ドキュメント「Hosting and updating extensions」では、Edgeはインストール済み拡張機能のホストを定期的に確認し、新しいバージョンがあれば自動更新すると説明されています。
ただし、Edge公式ドキュメントでは更新確認の具体的な間隔までは明記されていません。
そのため、検証時にすぐ結果を見たい場合は、edge://extensions/ の開発者モードをONにし、「更新」ボタンを押して確認するのがよいです。
ExtensionSettingsの注意点
ExtensionSettings は、1つのJSON文字列です。
Microsoftの「Microsoft Edge の拡張機能管理リファレンス」でも、ExtensionSettings はWindowsのグループポリシーエディターやレジストリでJSON文字列として設定するポリシーとして説明されています。
すでに別の拡張機能の設定が入っている環境で、単純に上書きすると既存設定を消してしまいます。
既存値がない場合は、次のようなJSONを登録します。
{"aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa":{"installation_mode":"force_installed","override_update_url":true,"update_url":"file:////server/share/EdgeExtensions/my-extension-update.xml"}}
既存値がある場合は、そのJSONに追記します。
たとえば既存がこうなら、
{"bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb":{"installation_mode":"force_installed"}}
追記後はこうです。
{"bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb":{"installation_mode":"force_installed"},"aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa":{"installation_mode":"force_installed","override_update_url":true,"update_url":"file:////server/share/EdgeExtensions/my-extension-update.xml"}}
JSONが壊れていると、edge://policy で ExtensionSettings が構文エラーになります。
設定後は必ず edge://policy でエラーが出ていないか確認します。
全端末展開する場合
今回、GPOによる全端末展開までは検証していません。
ただし、管理者権限があり、組織として全端末へ配布する場合は、GPOや端末管理の正式ルートで設定するのが望ましいと思います。
GPOの管理画面では、次の場所に ExtensionInstallForcelist に対応する設定項目があることを確認しました。
コンピューターの構成
管理用テンプレート
Microsoft Edge
拡張機能
サイレント インストールされる拡張機能を制御する
また、ExtensionSettings に対応する設定項目も同じ場所にあります。
コンピューターの構成
管理用テンプレート
Microsoft Edge
拡張機能
拡張機能の管理設定を構成する
今回は項目の存在確認までで、GPOへの値設定や端末への適用検証は行っていません。
まとめ
今回の検証では、update.xml とCRXを file://// のファイルサーバ参照にしても新規配布できました。
一方で、Forcelistだけでは既存拡張の更新は確認できず、更新まで制御するには ExtensionSettings の override_update_url:true が必要でした。
既存のEdgeポリシーを上書きしないこと、組織の端末管理ルールに沿って検証・展開することには注意が必要です。
その前提を守れば、小さな業務改善用のEdge拡張を庁内・閉域ネットワークで配布する方法として、file:// 配布はかなり現実的な選択肢だと感じました。