目次
- ※1 なぜ ExtensionSettings は HKLM、3rdparty/policy は HKCU なのか
- ※2 なぜ Action は Update なのか
- ※3 ExtensionSettings を HKLM と HKCU の両方に書くとなぜ競合するのか
- ※4 3rdparty/policy で同じ値名が HKLM と HKCU 両方にあるとどうなるか
- ※5 なぜ UserEmail をレジストリに直接書かず、環境変数参照にするのか
- ※6 実行ユーザーと HKCU 配信先の不一致（Run as Administrator・MDM 実行の落とし穴）
- ※7 なぜ edge://policy に 3rdparty/policy が表示されないのか
- 補足1: HKCU\Software\Policies の権限
- 補足2: 64bit レジストリビュー（/reg:64）
- Q. レジストリ設定後にブラウザの再起動は必要か？
- Q. 拡張機能をアンインストールするには？ GPO から外すだけで消える？
- Q. すでに配布済みの端末に再配布した場合はどうなる？
- Q. ExtensionSettings に競合警告が出ている場合は？
- Q. SKYSEA、LANSCOPE、SS1 などの資産管理ソフトがすでに ExtensionSettings を使っている場合は？
- Q. whoami /upn が使えない環境では？
- Q. Chrome と Edge で拡張機能 ID が違うのはなぜ？
- Q. 管理者権限なしで Software\Policies を書き換えられるか？
- batファイルのダウンロード
2-1.Admina ブラウザ拡張機能 セットアップガイド（Windows）
更新
by Yamaguchi Kaori
- ※1 なぜ ExtensionSettings は HKLM、3rdparty/policy は HKCU なのか
- ※2 なぜ Action は Update なのか
- ※3 ExtensionSettings を HKLM と HKCU の両方に書くとなぜ競合するのか
- ※4 3rdparty/policy で同じ値名が HKLM と HKCU 両方にあるとどうなるか
- ※5 なぜ UserEmail をレジストリに直接書かず、環境変数参照にするのか
- ※6 実行ユーザーと HKCU 配信先の不一致（Run as Administrator・MDM 実行の落とし穴）
- ※7 なぜ edge://policy に 3rdparty/policy が表示されないのか
- 補足1: HKCU\Software\Policies の権限
- 補足2: 64bit レジストリビュー（/reg:64）
- Q. レジストリ設定後にブラウザの再起動は必要か？
- Q. 拡張機能をアンインストールするには？ GPO から外すだけで消える？
- Q. すでに配布済みの端末に再配布した場合はどうなる？
- Q. ExtensionSettings に競合警告が出ている場合は？
- Q. SKYSEA、LANSCOPE、SS1 などの資産管理ソフトがすでに ExtensionSettings を使っている場合は？
- Q. whoami /upn が使えない環境では？
- Q. Chrome と Edge で拡張機能 ID が違うのはなぜ？
- Q. 管理者権限なしで Software\Policies を書き換えられるか？
- batファイルのダウンロード
第1章 概要
本資料の目的
本資料は、Admina ブラウザ拡張機能を Windows 環境に展開するためのセットアップガイドです。Active Directory の GPO（グループポリシー）または MDM を利用した一括配布と、個別端末での手動インストールの両方をカバーします。
対象読者
IT 管理者（Active Directory / Entra ID 管理者）、情報システム部門の担当者を想定しています。
前提条件
Windows 10 以降の端末で、Google Chrome または Microsoft Edge がインストール済みであることが必要です。GPO 配布の場合は Active Directory ドメイン環境と GPO 管理権限、MDM 配布の場合は対象 MDM の管理権限が必要です。
拡張機能のダウンロードとデータ送信のため、以下の通信経路が確保されている必要があります。
| 通信先 | ポート | 用途 |
|---|---|---|
clients2.google.com |
443 (HTTPS) | Chrome 拡張機能のダウンロード / 更新 |
edge.microsoft.com |
443 (HTTPS) | Edge 拡張機能のダウンロード / 更新 |
api.itmc.i.moneyforward.com |
443 (HTTPS) | Admina へのデータ送信 / API アクセス |
itmc.i.moneyforward.com |
443 (HTTPS) | Admina への Web アクセス |
アウトバウンド通信に制限がかかっているネットワーク環境では、プロキシや Firewall の許可リストにこれらのドメインを追加してください。通信確認の具体的な方法は第5章を参照してください。
免責事項
GPO / MDM の設定は各社の環境により大きく異なります。本資料に記載する配布手順は参考情報としてご利用ください。拡張機能自体の動作は検証済みですが、配布設定が既存のポリシーや環境に影響を与えないことを保証するものではありません。実施前に検証環境でのテストを推奨します。
第2章 構成の全体像
セットアップは レジストリ と ユーザー環境変数 の2つの層で構成されます。レジストリには「ブラウザ向けのポリシー」を書き、ユーザー環境変数には「ユーザーごとに違う値（メールアドレス）」を持たせます。ブラウザがポリシーを読むときに、レジストリ値に書かれた %USEREMAIL% がユーザー環境変数で展開されるため、1つのレジストリ値から各ユーザーに正しい値が届く仕組みです。
2.1 データフロー
┌─────────────────────────────────────────────────────────────┐
│ 配布フェーズ（管理者権限: GPO / MDM / bat） │
│ │
│ レジストリに書く: │
│ [HKLM] ExtensionSettings\<ID> │
│ installation_mode="force_installed" │
│ update_url="https://..." │
│ [HKCU] 3rdparty\extensions\<ID>\policy │
│ ApiKey, CreatedDate, OrganizationID │
│ UserEmail = "%USEREMAIL%" ← リテラル参照 │
│ UserPc = "%COMPUTERNAME%" │
│ │
│ ユーザー環境変数に書く（ログオンスクリプト）: │
│ USEREMAIL = user@example.com ← 各ユーザーの実値 │
└─────────────────────────────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────────────┐
│ 実行フェーズ（ユーザーログオン時） │
│ │
│ ブラウザ起動 → ポリシー読み込み → %USEREMAIL% を展開 │
│ │
│ 拡張機能が受け取る値: │
│ ApiKey = eyJhbG... │
│ UserEmail = user@example.com ← 展開後の実値 │
│ UserPc = DESKTOP-ABC1234 │
└─────────────────────────────────────────────────────────────┘
2.2 レジストリツリー
ExtensionSettings（強制インストール指示）は HKLM、3rdparty/policy（拡張機能に渡すパラメーター）は HKCU に配置するのが推奨構成です[※1]。
Chrome
HKLM\Software\Policies\Google\Chrome\
└─ ExtensionSettings\bdeanmdeckegmfjpbnngomallcedjold\
installation_mode = "force_installed"
update_url = "https://clients2.google.com/service/update2/crx"
HKCU\Software\Policies\Google\Chrome\
└─ 3rdparty\extensions\bdeanmdeckegmfjpbnngomallcedjold\policy\
ApiKey = <Admina 管理画面から取得>
CreatedDate = 2025-12-11T00:00:00Z
OrganizationID = <Admina 管理画面から取得>
UserEmail = %USEREMAIL%
UserPc = %COMPUTERNAME%
Edge
HKLM\Software\Policies\Microsoft\Edge\
└─ ExtensionSettings\flggmhlpipcopffjfkpgkoljghfkmfcg\
installation_mode = "force_installed"
update_url = "https://edge.microsoft.com/extensionwebstorebase/v1/crx"
HKCU\Software\Policies\Microsoft\Edge\
└─ 3rdparty\extensions\flggmhlpipcopffjfkpgkoljghfkmfcg\policy\
ApiKey = <Admina 管理画面から取得>
CreatedDate = 2025-12-11T00:00:00Z
OrganizationID = <Admina 管理画面から取得>
UserEmail = %USEREMAIL%
UserPc = %COMPUTERNAME%
2.3 パラメーター一覧
| パラメーター | 種別 | 用途 | 値のソース |
|---|---|---|---|
ApiKey |
固定値 | 認証トークン | Admina 管理画面 |
CreatedDate |
固定値 | ポリシー作成日時 | Admina 管理画面 |
OrganizationID |
固定値 | 組織 ID | Admina 管理画面 |
UserEmail |
動的 | 利用者のメールアドレス | ユーザー環境変数 USEREMAIL |
UserPc |
動的 | 端末ホスト名 | システム環境変数 COMPUTERNAME |
値の取得方法の詳細は 3.1 を参照してください。
第3章 設定手順
3.1 Admina 管理画面からの値取得
Admina にログインし、「設定 > 組織 > ブラウザ拡張機能 > 拡張機能のポリシー」を開きます。ポリシーを生成またはコピーし、クリップボードの内容をテキストエディタに貼り付けて ApiKey、CreatedDate、OrganizationID の3つの値を控えます。これら3つは全端末で共通の固定値です。
3.2 配布方式の選択
運用環境によって以下のいずれかを選びます。
- 3.3 GPO による配布: AD ドメイン環境。Registry Preferences で直接配信する方式を推奨します。
- 3.4 MDM による配布: Intune など。各 MDM 製品のスクリプトまたはレジストリ配布機能を使います。
- 3.5 スタンドアロン PC での手動実行: AD / MDM 管理下にない単独 PC。同梱 bat を管理者権限で実行します。
3.3 GPO による配布
GPO 配布では、2.2 のレジストリツリーを Computer Configuration（HKLM）と User Configuration（HKCU）の両方に分けて配信します。USEREMAIL 環境変数を設定するログオンスクリプトも合わせて配布します。
3.3.1 HKLM 側（ExtensionSettings）の配信
GPMC で対象 GPO を編集し、Computer Configuration → Preferences → Windows Settings → Registry を開きます。全項目共通で Hive = HKEY_LOCAL_MACHINE、Action = Update[※2] で以下4項目を新規作成します。
Chrome ExtensionSettings
Key Path: Software\Policies\Google\Chrome\ExtensionSettings\bdeanmdeckegmfjpbnngomallcedjold
| Value name | Value type | Value data |
|---|---|---|
installation_mode |
REG_SZ | force_installed |
update_url |
REG_SZ | https://clients2.google.com/service/update2/crx |
Edge ExtensionSettings
Key Path: Software\Policies\Microsoft\Edge\ExtensionSettings\flggmhlpipcopffjfkpgkoljghfkmfcg
| Value name | Value type | Value data |
|---|---|---|
installation_mode |
REG_SZ | force_installed |
update_url |
REG_SZ | https://edge.microsoft.com/extensionwebstorebase/v1/crx |
ExtensionSettings は HKLM と HKCU の両方に書くと競合して片方が無視されます[※3]。必ず HKLM のみに配置してください。
3.3.2 HKCU 側（3rdparty/policy）の配信
User Configuration → Preferences → Windows Settings → Registry を開きます。全項目共通で Hive = HKEY_CURRENT_USER、Action = Update で以下10項目を新規作成します。
Chrome 3rdparty Policy
Key Path: Software\Policies\Google\Chrome\3rdparty\extensions\bdeanmdeckegmfjpbnngomallcedjold\policy
| Value name | Value type | Value data |
|---|---|---|
ApiKey |
REG_SZ | （Admina から取得した値） |
CreatedDate |
REG_SZ | 2025-12-11T00:00:00Z など |
OrganizationID |
REG_SZ | （Admina から取得した値） |
UserEmail |
REG_SZ | %USEREMAIL% |
UserPc |
REG_SZ | %COMPUTERNAME% |
Edge 3rdparty Policy
Key Path: Software\Policies\Microsoft\Edge\3rdparty\extensions\flggmhlpipcopffjfkpgkoljghfkmfcg\policy
| Value name | Value type | Value data |
|---|---|---|
ApiKey |
REG_SZ | （Admina から取得した値） |
CreatedDate |
REG_SZ | 2025-12-11T00:00:00Z など |
OrganizationID |
REG_SZ | （Admina から取得した値） |
UserEmail |
REG_SZ | %USEREMAIL% |
UserPc |
REG_SZ | %COMPUTERNAME% |
3rdparty/policy を HKLM と HKCU の両方に書かないでください[※4]。同じ値名が両方に存在すると HKLM が優先され、HKCU 側で展開した
UserEmailの実値が負けます。
3.3.3 USEREMAIL 環境変数の配信（ログオンスクリプト）
UserEmail を %USEREMAIL% 参照で配信するには、各ユーザーのログオン時に USEREMAIL 環境変数を設定する必要があります[※5]。同梱の set_useremail_env.bat を SYSVOL に配置し、GPO のログオンスクリプトとして登録します。
set_useremail_env.batの冒頭DomainPart変数を環境のドメイン名（例:example.com）に編集- SYSVOL に配置:
\\<DOMAIN>\SYSVOL\<DOMAIN>\scripts\admina\set_useremail_env.bat - GPMC で対象 GPO を編集し、
User Configuration → Policies → Windows Settings → Scripts (Logon/Logoff) → Logonにスクリプトのパスを追加
スクリプトは whoami /upn で UPN 取得を試み、失敗時は USERNAME@DomainPart にフォールバックして、setx USEREMAIL "<値>" でユーザー環境変数に永続化します。
3.3.4 代替: スタートアップスクリプト方式
GPO Preferences の代わりに bat スクリプトで配信する方法もあります。edge_chrome_extension.bat を SYSVOL に配置し、スタートアップスクリプトとして登録します。bat 内の定数部と ExtSettingsRoot / PolicyRoot 変数を編集してください（3.5 参照）。
3.3.5 GPO の適用
GPO を対象 OU にリンクし、端末側で gpupdate /force を実行するか、再ログオンで反映します。
GPO 設定の詳細は以下の参考資料も参照してください: WindowsにGPOで配布する手順 - Admina Support
3.4 MDM による配布
MDM（Intune 等）を使用する場合は、各製品のスクリプト配布機能またはレジストリ配布機能で 2.2 のレジストリツリーを配布します。
- スクリプト配布:
edge_chrome_extension.batを配布・実行（bat の設定は 3.5 参照） - レジストリ配布: MDM のレジストリ管理機能で 2.2 のキーと値を直接定義
MDM から配信する場合、スクリプトは通常 SYSTEM アカウントで実行されます。この場合 HKCU が想定と違うハイブを指す点に注意が必要です[※6]。具体的な設定手順はご利用の MDM 製品のドキュメントに従ってください。
3.5 スタンドアロン PC での手動実行
AD / MDM 管理下にない単独の Windows PC で手動セットアップする場合、同梱の edge_chrome_extension.bat を使います。スタンドアロン PC では対象ユーザー = マシン利用者が1人に確定しているため、ExtensionSettings と 3rdparty/policy の両方を HKLM に書くのが最もシンプルで確実です。
3.5.1 スクリプトの編集
edge_chrome_extension.bat の冒頭定数部を編集します。
| 変数 | 設定内容 | スタンドアロン推奨値 |
|---|---|---|
DomainPart |
メールアドレスの @ 以降 |
example.com |
UserEmailMode |
DIRECT（スクリプトで解決）または ENV_REF（環境変数参照） |
DIRECT |
ApiKey |
3.1 で取得した値 | （Admina 管理画面から） |
CreatedDate |
3.1 で取得した値 | 2025-12-11T00:00:00Z など |
OrganizationID |
3.1 で取得した値 | （Admina 管理画面から） |
ExtSettingsRoot |
ExtensionSettings の配信先 | HKLM |
PolicyRoot |
3rdparty/policy の配信先 | HKLM |
3.5.2 実行方法
対象ユーザー自身がローカル管理者権限を持つ場合は、bat ファイルを右クリック →「管理者として実行」します。
対象ユーザーが管理者権限を持たず、別アカウントの管理者資格情報で昇格実行する場合は、必ず ExtSettingsRoot=HKLM かつ PolicyRoot=HKLM に設定してから実行してください[※6]。いずれかを HKCU にしたまま昇格実行すると、対象ユーザーではなく昇格に使った管理者アカウントのハイブに書き込まれます。
3.5.3 GPO/MDM 配信との違い
スタンドアロン運用で両方 HKLM に書く構成は、2.2 の推奨構成（ExtensionSettings=HKLM、3rdparty/policy=HKCU）とは異なります。スタンドアロンの場合はユーザー固有値（UserEmail）も HKLM に書き込まれる実値となるため、「1台1ユーザー」の前提が前提です。共用 PC や管理者と利用者が異なる環境では、GPO 方式での配布を検討してください。
第4章 動作確認
4.1 インストールスクリプトの出力確認
edge_chrome_extension.bat を手動実行した場合、実行中に各ステップの結果が表示されます。推奨構成（ExtensionSettings=HKLM、3rdparty/policy=HKCU）での正常出力例:
==============================
Edge + Chrome Extension Initializer
==============================
ExtensionSettings root: HKLM (HKEY_LOCAL_MACHINE)
3rdparty policy root : HKCU (HKEY_CURRENT_USER)
[1] Generating UserEmail ...
Got from whoami /upn
UserEmail = user@example.com
[2] Reading hostname for UserPc ...
Got from COMPUTERNAME
UserPc = DESKTOP-ABC1234
[3] Writing Chrome ExtensionSettings (HKLM) and 3rdparty policy (HKCU)...
The operation completed successfully.
Chrome extension and policy applied.
[4] Writing Edge ExtensionSettings (HKLM) and 3rdparty policy (HKCU)...
The operation completed successfully.
Edge extension and policy applied.
[5] Registry values written:
...(レジストリ値一覧が表示されます)...
==============================
FINISHED
==============================
[1] から [5] の各ステップでエラーが表示されていないこと、および [5] のレジストリ値一覧で各パラメーターが意図通りに書かれていることを確認します。
4.2 チェックスクリプトによる確認
同梱の check_extension_registry.bat はレジストリへの書き込みを行わず、HKCU と HKLM の両方をスキャンして結果を表示する読み取り専用ツールです。
推奨構成で配信した場合の正常な出力は、HKLM 側に ExtensionSettings のみ [OK]、HKCU 側に 3rdparty/policy のみ [OK] が並び、反対側は [--] NOT SET という形になります。[--] が出ている項目は「意図的にそちらに配置していない」ことを示しているだけで、エラーではありません。
================================================================
Extension Registry Checker (read-only)
================================================================
----------------------------------------
HKCU (HKEY_CURRENT_USER)
----------------------------------------
[Chrome ExtensionSettings]
[--] installation_mode NOT SET
[--] update_url NOT SET
[Chrome 3rdparty Policy]
[OK] ApiKey = xxxx...xxxx
[OK] CreatedDate = 2025-12-11T00:00:00Z
[OK] OrganizationID = <YOUR_ORG_ID>
[OK] UserEmail = user@example.com
[OK] UserPc = DESKTOP-ABC1234
[Edge ExtensionSettings]
[--] installation_mode NOT SET
[--] update_url NOT SET
[Edge 3rdparty Policy]
[OK] ApiKey = xxxx...xxxx
...
----------------------------------------
HKLM (HKEY_LOCAL_MACHINE)
----------------------------------------
[Chrome ExtensionSettings]
[OK] installation_mode = force_installed
[OK] update_url = https://clients2.google.com/service/update2/crx
[Chrome 3rdparty Policy]
[--] ApiKey NOT SET
[--] ... NOT SET
[Edge ExtensionSettings]
[OK] installation_mode = force_installed
[OK] update_url = https://edge.microsoft.com/extensionwebstorebase/v1/crx
[Edge 3rdparty Policy]
[--] ApiKey NOT SET
[--] ... NOT SET
スタンドアロン運用（全て HKLM）の場合は、HKLM 側にすべての値が [OK] で並び、HKCU 側は全項目 [--] NOT SET が正しい状態です。
4.3 拡張機能の表示確認
ブラウザがポリシーを再読み込みしたあと、拡張機能がインストールされていることを確認します。
- Chrome:
chrome://extensions - Edge:
edge://extensions
Admina 拡張機能が一覧に表示され、有効になっていれば成功です。強制インストールされた拡張機能は「組織によってインストール済み」と表示されます。
4.4 パラメーター受け渡しの確認
Chrome は chrome://policy を開き、「ポリシーを再読み込み」をクリックすると Admina 拡張機能のポリシーとして ApiKey、CreatedDate、OrganizationID、UserEmail、UserPc が一覧表示されます。
Edge は edge://policy に拡張機能パラメーターが表示されない仕様があり[※7]、別の方法で確認します。詳細は Appendix A を参照してください。
すべての値が正しく確認できれば、セットアップは完了です。最小5分から最大30分程度でデータの送信が開始されます。
第5章 疎通確認・データ確認
5.1 疎通確認
パラメーターが正しく設定・反映されている場合、最大30分程度でデータが Admina サーバーに届きます。Admina の「インテグレーション > イベントログ」で、ソースが「Chrome」「Edge」のエントリが登場することを確認してください。
5.2 不通の場合の調査
ブラウザで拡張機能のアイコンをクリックし、設定（⚙️）から設定ページを開きます。警告が表示されていなければデータは送信されているはずです。警告が出ている場合は、スクリーンショットと Diag データを添えてチャットからお問い合わせください。Diag データの確認方法 - Admina Support
5.3 ネットワーク調査
以下の通信先への疎通を確認します。
api.itmc.i.moneyforward.com:443（データ送信先 / API アクセス）itmc.i.moneyforward.com:443（Web アクセス）
PowerShell での確認例:
Test-NetConnection -ComputerName api.itmc.i.moneyforward.com -Port 443
成功時は1秒以内に応答があります。Waiting が長い場合は、経路上のどこかで詰まっている可能性があります。
第6章 技術解説（注釈の詳細）
本章では第2〜3章で示した注釈（※1〜※7）の背景を説明します。運用上の理由を理解したい場合、またはトラブルシューティングで原因を切り分ける際に参照してください。
※1 なぜ ExtensionSettings は HKLM、3rdparty/policy は HKCU なのか
レジストリに書ける場所は HKLM（マシン全体）と HKCU（ログインユーザー個別）の2種類があります。この2つは性質が違うため、ポリシーの種類によって使い分けます。
**ExtensionSettings は「マシン単位で共通する設定」**です。どのユーザーがログインしても「この拡張機能を強制インストールせよ」という指示は同じなので、HKLM に1回書けば十分です。全端末共通の値なので管理が単純になります。
**3rdparty/policy は「ユーザーコンテキストで評価されるパラメーター」**です。特に UserEmail はユーザーごとに違う値を渡す必要があります。HKCU に書いてユーザー環境変数 USEREMAIL で展開する構成にすれば、レジストリには %USEREMAIL% という参照を1種類だけ書いておけば、ログインユーザーごとに正しい実値に解決されます。
両方まとめて HKLM に書くことも技術的には可能ですが、その場合 UserEmail はマシン全体で固定値になります（共用 PC で問題）。両方 HKCU にすると、配信時のプロセスコンテキスト（※6）の影響を受けやすくなります。役割分担するのが運用上もっとも扱いやすい構成です。
※2 なぜ Action は Update なのか
GPO Preferences の Registry Item には以下の Action があります。
- Create: 値が存在しないときだけ作る。既存の値はスキップ。
- Update: 存在しなければ作成、存在すれば上書き。ただし同じキー配下の他の値は保持される。
- Replace: キーごと削除して再作成。同じキー配下の他の値も巻き添えで消える。
- Delete: 削除。
今回 Update を推奨する理由は3つあります。1つ目は、ApiKey など将来変更する可能性がある値を確実に最新化できる（Create だと初回のみ適用）。2つ目は、Replace のように「同じキー配下の他の値を消す」副作用がない。3つ目は、初回配信でも「存在しなければ作成」として機能するため、初回・再配信どちらも同じ Action で済みます。
※3 ExtensionSettings を HKLM と HKCU の両方に書くとなぜ競合するのか
ExtensionSettings は内部的に 辞書（dict）型のポリシー として扱われます。ブラウザはレジストリ上のサブキーを読み込む際、拡張機能ID単位のサブキーをすべて集約して1つの大きな JSON 辞書にしてから検査します。
Chromium のポリシー優先順位は「Platform/Machine（HKLM）> Platform/User（HKCU）」と決まっていて、HKLM と HKCU の両方に ExtensionSettings が存在する場合、HKLM 側の辞書が丸ごと採用され、HKCU 側の辞書は一切マージされません。たとえば HKLM に拡張機能 A、HKCU に拡張機能 B を別々に書いても、B は無視されます。
chrome://policy や edge://policy の画面で ExtensionSettings に競合警告（黄色・赤のマーカー）が出る場合はこの状態です。対処は HKLM か HKCU のどちらか一方に統一することです。
なお 3rdparty/policy はこの dict 集約の対象ではなく、値単位で独立しています。そのため HKLM と HKCU で値名が衝突しなければマージされて拡張機能に届きます（※4 も参照）。
※4 3rdparty/policy で同じ値名が HKLM と HKCU 両方にあるとどうなるか
3rdparty/policy は ExtensionSettings と違って辞書ごと勝つルールではありませんが、同じ値名が HKLM と HKCU に両方あると、HKLM が優先されます。これは Chromium のポリシー優先順位ルール（Machine > User）がそのまま適用されるためです。
本資料の推奨構成では 3rdparty/policy は HKCU のみに配置しているため、この競合は発生しません。ただし過去に HKLM 側にも書いた残骸がある環境では、HKCU の %USEREMAIL% 展開値が負けてリテラル文字列のまま拡張機能に届くといった事故になります。配信前に HKLM 側の 3rdparty/policy サブキーが空であることを確認してください。
※5 なぜ UserEmail をレジストリに直接書かず、環境変数参照にするのか
GPO Preferences で Computer Configuration（HKLM 側）のレジストリ項目に %USEREMAIL% を書くと、展開されずリテラル文字列のまま書かれます。これは GPO 適用時のプロセスコンテキストが SYSTEM アカウントになるためで、ユーザー環境変数である USEREMAIL が SYSTEM から見えません。これは Windows のアーキテクチャ上の制約で、回避不可能です。
一方 User Configuration（HKCU 側）の適用はログオンユーザーのコンテキストで行われるため、%USEREMAIL% が正しく展開されます。本資料が 3rdparty/policy を HKCU に配置する大きな理由の1つがこれです。
なお UserPc に使う %COMPUTERNAME% はシステム環境変数なので、HKLM/HKCU どちらに書いても展開されます。UserEmail だけが特殊なのは、それがユーザー環境変数だからです。
※6 実行ユーザーと HKCU 配信先の不一致（Run as Administrator・MDM 実行の落とし穴）
HKCU に書くとき、「どのユーザーの HKCU に書かれるか」は スクリプトを実行したプロセスのユーザーコンテキストで決まります。対象ユーザー本人が実行しない限り、対象ユーザーの HKCU には書かれません。
具体的に以下の2ケースで問題になります。
-
Run as Administrator で昇格実行した場合: 一般ユーザーが別アカウント（Administrator 等）の資格情報で「管理者として実行」すると、プロセスは Administrator のコンテキストで動きます。HKCU は Administrator のハイブを指し、対象ユーザーのブラウザは当然この値を読めません。
-
MDM や SCCM がシステムアカウントで実行した場合: MDM エージェント経由でスクリプトが配布されると、多くの場合
SYSTEMまたは MDM 専用のサービスアカウントで実行されます。HKCU はそのサービスアカウントのハイブを指し、実ユーザーには一切反映されません。
この問題を避けるため、推奨構成では HKCU 側の配信を GPO の User Configuration 経由（ログオンユーザーのコンテキストで適用）で行います。スタンドアロン実行の場合は、両方 HKLM に寄せてコンテキスト非依存にします。
※7 なぜ edge://policy に 3rdparty/policy が表示されないのか
Edge の edge://policy には、ブラウザ本体のポリシーと ExtensionSettings は表示されますが、3rdparty/extensions/
Edge で届いているかを確認する代替手段として、拡張機能の Service Worker コンソールから chrome.storage.managed.get() API を叩く方法があります。Appendix A.2 を参照してください。
補足1: HKCU\Software\Policies の権限
HKCU 配下は通常ユーザー自身で読み書き可能ですが、Software\Policies サブツリーだけはデフォルト ACL で管理者に制限されています。これは Windows の設計上、ポリシー領域はユーザーが勝手に書き換えられないようにするためです。
したがって本資料の配信手段は、GPO 経由（SYSTEM 権限で実行）、MDM 経由（SYSTEM 権限で実行）、管理者権限での手動実行のいずれかを前提としています。一般ユーザー権限のログオンスクリプトで HKCU\Software\Policies に直接書き込もうとしても Access Denied で失敗します。ユーザー側のログオンスクリプトで書けるのは USEREMAIL などのユーザー環境変数までで、レジストリポリシー自体は書けません。
補足2: 64bit レジストリビュー（/reg:64）
Chrome と Edge は 64bit アプリケーションのため、ポリシーを 64bit レジストリビューから読み込みます。通常 cmd.exe から実行される bat は 64bit ビューにアクセスしますが、SCCM や一部の MDM エージェントから 32bit コンテキストで呼び出された場合、HKLM への書き込みが HKLM\SOFTWARE\WOW6432Node\Policies\... にリダイレクトされ、ブラウザから読めない場所に書かれます。
同梱のスクリプトは reg add と reg query すべてに /reg:64 フラグを付けて、どのコンテキストから呼び出されても 64bit ビューに書き込み・読み取りを行うように実装されています。GPO Preferences からの配信は通常 64bit ビューに直接書かれるため、bat 経由と GPO 経由で書き込み先が完全に一致します。トラブル時の切り分けとして、HKLM\SOFTWARE\WOW6432Node\Policies\... に値が入っていないか regedit で確認するのも有効です。
Appendix A ブラウザ上でのポリシー確認方法
A.1 Chrome: chrome://policy
アドレスバーに chrome://policy を入力し、「ポリシーを再読み込み」ボタンをクリックすると最新状態になります。
画面下部の Extension policies セクションに、拡張機能ごとに ApiKey、UserEmail などの値が Source（Platform）と Scope（Machine / User）付きで表示されます。Scope 列で HKLM 由来か HKCU 由来かを判別できます。
A.2 Edge: 3rdparty/policy の確認方法
Edge の edge://policy では ExtensionSettings は表示されますが、3rdparty/policy は表示されません（※7 参照）。値が届いているかを確認するには以下の方法があります。
方法1: レジストリ直接確認
check_extension_registry.bat を実行するか、regedit で HKCU/HKLM 配下の該当キーを開いて値が入っていることを確認します。書き込まれていれば Edge は読み取っています。
方法2: chrome.storage.managed API で確認
拡張機能の Service Worker コンソールから、実際に届いている値を確認できます。
edge://extensionsを開き、開発者モードを ON- 対象拡張機能の「詳細」→「Service Worker を検査」をクリック
- DevTools の Console タブで以下を実行:
chrome.storage.managed.get(null, (data) => console.log(data))
出力例:
{
ApiKey: "eyJhbGciOiJIUzI1NiIs...",
CreatedDate: "2025-12-11T00:00:00Z",
OrganizationID: "99581857",
UserEmail: "user@example.com",
UserPc: "MYPC-001"
}
値が表示されれば、ポリシーが拡張機能に届いている証拠です。Chrome でも同じ方法が使えます。
方法3: Admina の Diag データで確認
Admina の Diag データから拡張機能に届いているパラメーターを確認できます。Diag データの確認方法 - Admina Support
Appendix B Q&A
Q. レジストリ設定後にブラウザの再起動は必要か？
必須ではありません。Chrome / Edge はバックグラウンドで定期的にポリシー設定を再読み込みするため、一定時間経過後に自動反映されます。即時反映したい場合は、chrome://policy または edge://policy を開いて「ポリシーを再読み込み」をクリックしてください。
Q. 拡張機能をアンインストールするには？ GPO から外すだけで消える？
GPO から項目を外すだけでは消えません。GPO Preferences の Update / Create アクションで配布した項目は、適用先の端末に「タトゥー」のように残ります（これは Windows のグループポリシー・プレファレンスの仕様です）。削除するには以下のいずれかを実施します。
- GPO で明示的に Delete アクションを配信: 対象4キー（Chrome/Edge の ExtensionSettings と 3rdparty/extensions）について、Action =
Delete、Value name 空欄で新規 Registry Item を作成。Value name を空にするとキー配下のサブツリーごと削除されます。 - 削除用 bat を配布:
reg delete "HKLM\Software\Policies\Google\Chrome\ExtensionSettings\<ID>" /f /reg:64のようなコマンドを端末で実行。
ブラウザが次回ポリシーを再読み込みしたタイミングで拡張機能が削除されます。削除用 GPO は全端末への適用が完了するまで（オフライン端末含めて通常は数週間〜1ヶ月）残してから撤去するのが定石です。
Q. すでに配布済みの端末に再配布した場合はどうなる？
GPO の Action が Update なら、レジストリ値が上書きされるだけで二重インストールは発生しません。ApiKey や UserEmail の更新時も、同じ GPO / スクリプトを再実行すれば安全に上書き反映されます。
Q. ExtensionSettings に競合警告が出ている場合は？
chrome://policy / edge://policy で ExtensionSettings のエントリに警告（黄色・赤のマーカー）が出る場合、HKLM と HKCU の両方に ExtensionSettings が存在している状態です（※3 参照）。HKLM 側が辞書ごと勝利し、HKCU 側は無視されます。
対処は HKLM か HKCU のどちらか一方に統一することです。本資料の推奨構成に合わせるなら、HKCU 側の ExtensionSettings サブキーを削除してください。
Q. SKYSEA、LANSCOPE、SS1 などの資産管理ソフトがすでに ExtensionSettings を使っている場合は？
これらの製品も自社の拡張機能を強制配布する仕組みを持ち、ExtensionSettings 配下に設定を書き込むことがあります。Admina 拡張機能は ID が他製品と異なる（Chrome: bdeanmdeckegmfjpbnngomallcedjold、Edge: flggmhlpipcopffjfkpgkoljghfkmfcg）ため、サブキー単位では共存できます。
ただし重要な注意点として、ブラウザが ExtensionSettings を読み取るレジストリハイブは HKLM か HKCU のどちらか一方です（※3 のルール）。資産管理ソフトが HKLM に書き込んでいる場合、Admina も HKLM に配信する必要があります。HKCU に書いているなら Admina も HKCU に揃えます。読み取り側は1箇所しか見ないため、配信先を揃えないと片方が完全に無視されます。
現在どちらに書いているかは、regedit で HKLM\Software\Policies\Google\Chrome\ExtensionSettings と HKCU\Software\Policies\Google\Chrome\ExtensionSettings の両方を覗いて確認してください。
3rdparty/extensions 側は拡張機能 ID 単位で完全に独立しているため、他製品と干渉しません。
Q. whoami /upn が使えない環境では？
オンプレミス AD のみの環境など UPN が取得できない場合、スクリプトは USERNAME@DomainPart にフォールバックします。スクリプト冒頭の DomainPart 変数に正しいドメイン名を設定してください。
環境の都合で正しいメールアドレスを組み立てられない場合でも、ここで設定した Email を Admina のディレクトリ上でセカンダリアドレスとして登録すれば、ユーザーとのマッチングが可能です。
Q. Chrome と Edge で拡張機能 ID が違うのはなぜ？
Chrome Web Store と Microsoft Edge Add-ons はそれぞれ独立したストアで、同じ拡張機能でも異なる ID が割り当てられます。配布スクリプトは両方に対応しています。
Q. 管理者権限なしで Software\Policies を書き換えられるか？
書き換えられません。HKCU 配下は通常ユーザー自身で書き込み可能ですが、Software\Policies サブツリーだけは例外で、デフォルト ACL により管理者のみに書き込み権限が付与されています。本資料の配信シナリオはすべて、GPO 経由・MDM 経由・管理者権限での手動実行のいずれかを前提としています。
batファイルのダウンロード
batファイルは、以下よりダウンロードいただけます。
※以下をクリックすると同じタブでファイルが開きます。ダウンロード後は、ブラウザの「戻る」ボタンで本ページにお戻りください。
