技術解説
各方式の手順の背景を説明します。運用上の理由を理解したい場合や、トラブルシューティングで原因を切り分けるときに参照してください。ExtensionSettings は HKLM、3rdparty/policy は HKCU に置く理由
レジストリに書ける場所は HKLM（マシン全体）と HKCU（ログインユーザー個別）の2種類があります。この2つは性質が違うため、ポリシーの種類によって使い分けます。 ExtensionSettings は「マシン単位で共通する設定」 です。どのユーザーがログインしても「この拡張機能を強制インストールせよ」という指示は同じなので、HKLM に1回書けば十分です。全端末共通の値なので管理が単純になります。 3rdparty/policy は「ユーザーコンテキストで評価されるパラメーター」 です。特にUserEmail はユーザーごとに違う値を渡す必要があります。HKCU へ書くことで、ログインユーザーごとに正しい実値を渡せます。
両方まとめて HKLM に書くことも技術的には可能ですが、その場合 UserEmail はマシン全体で固定値になります（共用 PC で問題）。両方 HKCU にすると、配信時のプロセスコンテキスト（実行ユーザーと HKCU の書き込み先のずれ）の影響を受けやすくなります。役割分担するのが運用上もっとも扱いやすい構成です。
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 で値名が衝突しなければマージされて拡張機能に届きます（3rdparty/policy の同じ値名が HKLM と HKCU の両方にある場合 も参照）。
3rdparty/policy の同じ値名が HKLM と HKCU の両方にある場合
3rdparty/policy は ExtensionSettings と違って辞書ごと勝つルールではありませんが、同じ値名が HKLM と HKCU に両方あると、HKLM が優先されます。これは Chromium のポリシー優先順位ルール（Machine > User）がそのまま適用されるためです。 推奨構成では 3rdparty/policy は HKCU のみに配置しているため、この競合は発生しません。ただし過去に HKLM 側にも書いた残骸がある環境では、HKCU の値が負けて意図しない値が拡張機能に届くといった事故になります。配信前に HKLM 側の 3rdparty/policy サブキーが空であることを確認してください。実行ユーザーと HKCU の書き込み先のずれ（管理者として実行の注意点）
HKCU に書くとき、「どのユーザーの HKCU に書かれるか」は スクリプトを実行したプロセスのユーザーコンテキストで決まります。対象ユーザー本人が実行しない限り、対象ユーザーの HKCU には書かれません。 Run as Administrator で昇格実行した場合、一般ユーザーが別アカウント（Administrator 等）の資格情報で「管理者として実行」すると、プロセスは Administrator のコンテキストで動きます。HKCU は Administrator のハイブを指し、対象ユーザーのブラウザは当然この値を読めません。この問題を bat 実行だけで回避する簡単な方法はないため、手動セットアップでは対象ユーザー自身が管理者権限を持つアカウントでサインインして実行することが前提です。対象ユーザーが管理者権限を持たない場合は GPO または Intune による配布をご利用ください。bat スクリプトはPolicyRoot=HKLM を invalid として拒否する設計のため、ユーザー固有値がマシン全体のハイブに書き込まれる事故は起きません。
edge://policy に 3rdparty/policy が表示されない理由
Edge のedge://policy には、ブラウザ本体のポリシーと ExtensionSettings は表示されますが、3rdparty/extensions//policy 配下のカスタムポリシーは表示されません。値自体は拡張機能に正しく届いており、画面で見えないだけです。
Edge で届いているかを確認する代替手段として、拡張機能の Service Worker コンソールから chrome.storage.managed.get() API を叩く方法があります。Edge: 3rdparty/policy の確認方法 を参照してください。
HKCU\Software\Policies の権限
HKCU 配下は通常ユーザー自身で読み書き可能ですが、Software\Policies サブツリーだけはデフォルト ACL で管理者に制限されています。これは Windows の設計上、ポリシー領域はユーザーが勝手に書き換えられないようにするためです。
したがって、手動で書き込む場合は管理者権限が必要です。一般ユーザー権限では HKCU\Software\Policies に直接書き込もうとしても Access Denied で失敗します。
64bit レジストリビュー（/reg:64）
Chrome と Edge は 64bit アプリケーションのため、ポリシーを 64bit レジストリビューから読み込みます。通常 cmd.exe から実行される bat は 64bit ビューにアクセスしますが、32bit コンテキストで呼び出された場合、HKLM への書き込みがHKLM\SOFTWARE\WOW6432Node\Policies\... にリダイレクトされ、ブラウザから読めない場所に書かれます。
同梱のスクリプトは reg add と reg query すべてに /reg:64 フラグを付けて、どのコンテキストから呼び出されても 64bit ビューに書き込み・読み取りを行うように実装されています。トラブル時の切り分けとして、HKLM\SOFTWARE\WOW6432Node\Policies\... に値が入っていないか regedit で確認するのも有効です。
ブラウザ上でのポリシー確認方法
Chrome: chrome://policy
アドレスバーにchrome://policy を入力し、「ポリシーを再読み込み」ボタンをクリックすると最新状態になります。
画面下部の Extension policies セクションに、拡張機能ごとに ApiKey、UserEmail などの値が Source（Platform）と Scope（Machine / User）付きで表示されます。Scope 列で HKLM 由来か HKCU 由来かを判別できます。
Edge: 3rdparty/policy の確認方法
Edge のedge://policy では ExtensionSettings は表示されますが、3rdparty/policy は表示されません（edge://policy に 3rdparty/policy が表示されない理由 参照）。値が届いているかを確認するには以下の方法があります。
方法1: レジストリ直接確認
check_extension_registry.bat を実行するか、regedit で HKCU/HKLM 配下の該当キーを開いて値が入っていることを確認します。書き込まれていても、ポリシーの競合や同名値の優先順位で無視されることがあります（競合の仕組みを参照）。確実な確認は方法 2（chrome.storage.managed）です。
方法2: chrome.storage.managed API で確認
拡張機能の Service Worker コンソールから、実際に届いている値を確認できます。
edge://extensionsを開き、開発者モードを ON- 対象の拡張機能の「詳細」→「Service Worker を検査」をクリック
- DevTools の Console タブで以下を実行:
Q&A
Q. レジストリ設定後にブラウザの再起動は必要か？
必須ではありません。Chrome / Edge はバックグラウンドで定期的にポリシー設定を再読み込みするため、一定時間の経過後に自動反映されます。即時反映したい場合は、chrome://policy または edge://policy を開いて「ポリシーを再読み込み」をクリックしてください。
Q. すでに配布済みの端末に再実行した場合はどうなる？
同じスクリプトを再実行すると、レジストリ値が上書きされるだけで二重インストールは発生しません。ApiKey や UserEmail の更新時も、同じスクリプトを再実行すれば安全に上書き反映されます。
Q. ExtensionSettings に競合警告が出ている場合は？
chrome://policy / edge://policy で ExtensionSettings のエントリに警告（黄色・赤のマーカー）が出る場合、HKLM と HKCU の両方に ExtensionSettings が存在している状態です（ExtensionSettings を HKLM と HKCU の両方に書くと競合する理由 参照）。HKLM 側が辞書ごと勝利し、HKCU 側は無視されます。
対処は HKLM か HKCU のどちらか一方に統一することです。推奨構成に合わせる場合は、HKCU 側の ExtensionSettings サブキーを削除してください。
Q. SKYSEA、LANSCOPE、SS1 などの資産管理ソフトがすでに ExtensionSettings を使っている場合は？
これらの製品も自社の拡張機能を強制配布する仕組みを持ち、ExtensionSettings 配下に設定を書き込むことがあります。Admina 拡張機能は ID が他製品と異なる（Chrome:bdeanmdeckegmfjpbnngomallcedjold、Edge: flggmhlpipcopffjfkpgkoljghfkmfcg）ため、サブキー単位では共存できます。
ただし、ブラウザが ExtensionSettings を読み取るレジストリハイブは HKLM か HKCU のどちらか一方です（ExtensionSettings を HKLM と HKCU の両方に書くと競合する理由 のルール）。資産管理ソフトが 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 が使えない環境では？
オンプレミス Active Directory のみの環境など UPN が取得できない場合、スクリプトはUSERNAME@DomainPart にフォールバックします。
お使いのスクリプトの DomainPart 変数に正しいドメイン名を設定してください。手動セットアップでは edge_chrome_extension.bat（ENV_REF モードの場合は Set-UserEmailEnv.bat）、GPO 配布では Set-UserEmailEnv.bat が対象です。
環境の都合で正しいメールアドレスを組み立てられない場合でも、ここで設定したメールアドレスをディレクトリ上でセカンダリアドレスとして登録すれば、ユーザーとのマッチングが可能です。
Q. Chrome と Edge で拡張機能 ID が違うのはなぜ？
Chrome Web Store と Microsoft Edge Add-ons はそれぞれ独立したストアで、同じ拡張機能でも異なる ID が割り当てられます。Windows の配布方式（手動・GPO・Intune）では、Chrome と Edge の両方に対応しています。Q. 管理者権限なしで Software\Policies を書き換えられるか？
書き換えられません。HKCU 配下は通常ユーザー自身で書き込み可能ですが、Software\Policies サブツリーだけは例外で、デフォルト ACL により管理者のみに書き込み権限が付与されています。そのため、手動で書き込む場合は管理者権限が必要です。