配布ファイルのダウンロード
セットアップに使用する bat ファイルは、以下よりダウンロードいただけます。 ※以下をクリックすると同じタブでファイルが開きます。ダウンロード後は、ブラウザの「戻る」ボタンで本ページにお戻りください。
まとめて欲しい場合は すべてのファイルを ZIP でダウンロード をご利用ください。
各ファイルの使い方は 3.2 で説明します。
第1章 概要
本資料の目的
本資料は、Active Directory や MDM の管理下にない単独の Windows PC で、ブラウザ拡張機能を手動でセットアップするためのガイドです。対象読者
IT 管理者、情報システム部門の担当者、または対象 PC のローカル管理者権限を持つユーザーを想定しています。 一括配布（GPO や Intune）の手順は、それぞれ次のガイドを参照してください。前提条件
Windows 10 以降の端末で、Google Chrome または Microsoft Edge がインストール済みであることが必要です。本手順は、対象 PC のローカル管理者権限をすでに持っているユーザー自身が実行することを前提としています。管理者権限を持たないユーザーが「管理者として実行」で別の管理者アカウントの ID / パスワードを入力して昇格する方法は、本ガイドの手順では動作しません。昇格したプロセスは入力した管理者アカウントのコンテキストで動くため、レジストリが対象ユーザーの HKCU ではなく昇格に使ったアカウントの HKCU に書き込まれてしまいます。対象ユーザーが管理者権限を持たない場合は、Windows GPO を使った配布 または Windows Intune による配布 をご利用ください。
アウトバウンド通信に制限がかかっているネットワーク環境では、プロキシや Firewall の許可リストにこれらのドメインを追加してください。通信確認の具体的な方法は第5章を参照してください。
免責事項
本資料に記載する配布手順は参考情報としてご利用ください。拡張機能自体の動作は検証済みですが、レジストリ設定が既存のポリシーや環境に影響を与えないことを保証するものではありません。実施前に検証環境でのテストを推奨します。第2章 構成の全体像
セットアップは レジストリ と ユーザー環境変数 の2つの層で構成されます。レジストリには「ブラウザ向けのポリシー」を書き、ユーザー環境変数には「ユーザーごとに違う値（メールアドレス）」を持たせます。ブラウザがポリシーを読むときに、レジストリ値に書かれた%USEREMAIL% がユーザー環境変数で展開されるため、1つのレジストリ値から各ユーザーに正しい値が届く仕組みです。
スタンドアロン構成では UserEmailMode=DIRECT を使い、bat 実行時に whoami /upn からメールアドレスを自動解決します。USEREMAIL 環境変数を別途設定する必要はありません。
2.1 データフロー
2.2 レジストリツリー
ExtensionSettings（強制インストール指示）は HKLM、3rdparty/policy（拡張機能に渡すパラメーター）は HKCU に配置するのが推奨構成です[※1]。Chrome
Edge
2.3 パラメーター一覧
値の取得方法の詳細は 3.1 を参照してください。
第3章 設定手順
3.1 管理画面からの値取得
ログインし、「設定 > 組織 > ブラウザ拡張機能 > 拡張機能のポリシー」を開きます。ポリシーを生成またはコピーし、クリップボードの内容をテキストエディタに貼り付けてApiKey、CreatedDate、OrganizationID の3つの値を控えます。これら3つは全端末で共通の固定値です。
3.2 スタンドアロン PC での手動実行
AD / MDM 管理下にない単独の Windows PC で手動セットアップする場合、同梱のedge_chrome_extension.bat を使います。スタンドアロン構成でも、2.2 の推奨構成と同じく ExtensionSettings は HKLM、3rdparty/policy は HKCU に書き込みます。
スタンドアロンでは対象ユーザーが自分で bat を実行するため、UserEmailMode=DIRECT（スクリプト内で whoami /upn から自動解決）を使えます。
3.2.1 スクリプトの編集
edge_chrome_extension.bat の冒頭定数部を編集します。
PolicyRoot=HKLM は bat スクリプトで拒否されます。3rdparty/policy はユーザー固有のパラメーター（UserEmail など）を保持する領域なので、ハイブは常に HKCU を指定してください。3.2.2 実行方法
対象ユーザー自身がローカル管理者権限を持つアカウントでサインインし、bat ファイルを右クリック →「管理者として実行」します。PolicyRoot=HKCU 指定で、対象ユーザーの HKCU に書き込まれます。
「管理者として実行」の画面で別アカウントの管理者 ID / パスワードを入力して昇格する方法は使えません。プロセスが昇格に使ったアカウントのコンテキストで動くため、HKCU は対象ユーザーではなく昇格アカウントのハイブを指してしまいます[※6]。対象ユーザーが管理者権限を持たない場合は、GPO または Intune による配布（3.2.3 参照）をご利用ください。
3.2.3 他の配布方式との違い
スタンドアロンと GPO / Intune 配信でレジストリ配置先（ExtensionSettings=HKLM、3rdparty/policy=HKCU）は同じです。違いは主にUserEmail の解決方法で、スタンドアロンは UserEmailMode=DIRECT（実行時に解決）、GPO / Intune は ENV_REF（%USEREMAIL% を実行時に各ユーザーの環境変数で展開）を使います。
第4章 動作確認
4.1 インストールスクリプトの出力確認
edge_chrome_extension.bat を手動実行した場合、実行中に各ステップの結果が表示されます。推奨構成（ExtensionSettings=HKLM、3rdparty/policy=HKCU）での正常出力例:
[1] から [5] の各ステップでエラーが表示されていないこと、および [5] のレジストリ値一覧で各パラメーターが意図通りに書かれていることを確認します。
4.2 チェックスクリプトによる確認
同梱のcheck_extension_registry.bat はレジストリへの書き込みを行わず、HKCU と HKLM の両方をスキャンして結果を表示する読み取り専用ツールです。
推奨構成で配信した場合の正常な出力は、HKLM 側に ExtensionSettings のみ [OK]、HKCU 側に 3rdparty/policy のみ [OK] が並び、反対側は [--] NOT SET という形になります。[--] が出ている項目は「意図的にそちらに配置していない」ことを示しているだけで、エラーではありません。
4.3 拡張機能の表示確認
ブラウザがポリシーを再読み込みしたあと、拡張機能がインストールされていることを確認します。- Chrome:
chrome://extensions - Edge:
edge://extensions
4.4 パラメーター受け渡しの確認
Chrome はchrome://policy を開き、「ポリシーを再読み込み」をクリックすると Admina 拡張機能のポリシーとして ApiKey、CreatedDate、OrganizationID、UserEmail、UserPC が一覧表示されます。
Edge は edge://policy に拡張機能パラメーターが表示されない仕様となっており[※7]、別の方法で確認します。詳細は Appendix A を参照してください。
すべての値が正しく確認できれば、セットアップは完了です。最小5分から最大30分程度でデータの送信が開始されます。
第5章 疎通確認・データ確認
5.1 疎通確認
パラメーターが正しく設定・反映されている場合、最大30分程度でデータがサーバーに届きます。「インテグレーション > イベントログ」で、ソースが「Chrome」「Edge」のエントリが登場することを確認してください。5.2 不通の場合の調査
ブラウザで拡張機能のアイコンをクリックし、設定（⚙️）から設定ページを開きます。警告が表示されていなければデータは送信されているはずです。警告が出ている場合は、スクリーンショットと Diag データを添えてチャットからお問い合わせください。Diag データの確認方法5.3 ネットワーク調査
以下の通信先への疎通を確認します。api.itmc.i.moneyforward.com:443（データ送信先 / API アクセス）itmc.i.moneyforward.com:443（Web アクセス）
第6章 技術解説（注釈の詳細）
本章では第2〜3章で示した注釈（※1、※3〜※7）の背景を説明します。運用上の理由を理解したい場合、またはトラブルシューティングで原因を切り分ける際に参照してください。※1 なぜ ExtensionSettings は HKLM、3rdparty/policy は HKCU なのか
レジストリに書ける場所は HKLM（マシン全体）と HKCU（ログインユーザー個別）の2種類があります。この2つは性質が違うため、ポリシーの種類によって使い分けます。 **ExtensionSettings は「マシン単位で共通する設定」**です。どのユーザーがログインしても「この拡張機能を強制インストールせよ」という指示は同じなので、HKLM に1回書けば十分です。全端末共通の値なので管理が単純になります。 **3rdparty/policy は「ユーザーコンテキストで評価されるパラメーター」**です。特にUserEmail はユーザーごとに違う値を渡す必要があります。HKCU へ書くことで、ログインユーザーごとに正しい実値を渡せます。
両方まとめて HKLM に書くことも技術的には可能ですが、その場合 UserEmail はマシン全体で固定値になります（共用 PC で問題）。両方 HKCU にすると、配信時のプロセスコンテキスト（※6）の影響を受けやすくなります。役割分担するのが運用上もっとも扱いやすい構成です。
※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 の値が負けて意図しない値が拡張機能に届くといった事故になります。配信前に HKLM 側の 3rdparty/policy サブキーが空であることを確認してください。※6 実行ユーザーと HKCU 配信先の不一致（Run as Administrator の落とし穴）
HKCU に書くとき、「どのユーザーの HKCU に書かれるか」は スクリプトを実行したプロセスのユーザーコンテキストで決まります。対象ユーザー本人が実行しない限り、対象ユーザーの HKCU には書かれません。 Run as Administrator で昇格実行した場合、一般ユーザーが別アカウント（Administrator 等）の資格情報で「管理者として実行」すると、プロセスは Administrator のコンテキストで動きます。HKCU は Administrator のハイブを指し、対象ユーザーのブラウザは当然この値を読めません。この問題を bat 実行だけで回避する簡単な方法はないため、スタンドアロン実行は対象ユーザー自身が管理者権限を持つアカウントでサインインして実行することが前提です。対象ユーザーが管理者権限を持たない場合は GPO または Intune による配布をご利用ください。bat スクリプトはPolicyRoot=HKLM を invalid として拒否する設計のため、ユーザー固有値がマシン全体のハイブに書き込まれる事故は起きません。
※7 なぜ edge://policy に 3rdparty/policy が表示されないのか
Edge のedge://policy には、ブラウザ本体のポリシーと ExtensionSettings は表示されますが、3rdparty/extensions//policy 配下のカスタムポリシーは表示されません。これは Edge の既知の仕様で、Microsoft 公式にも「Edge は 3rdparty レジストリエントリを尊重するが、UI で表示するサポートがない」と明記されています。値自体は拡張機能に正しく届いており、画面で見えないだけです。
Edge で届いているかを確認する代替手段として、拡張機能の Service Worker コンソールから chrome.storage.managed.get() API を叩く方法があります。Appendix A.2 を参照してください。
補足1: HKCU\Software\Policies の権限
HKCU 配下は通常ユーザー自身で読み書き可能ですが、Software\Policies サブツリーだけはデフォルト ACL で管理者に制限されています。これは Windows の設計上、ポリシー領域はユーザーが勝手に書き換えられないようにするためです。
したがって本資料の配信手段は、管理者権限での手動実行を前提としています。一般ユーザー権限では HKCU\Software\Policies に直接書き込もうとしても Access Denied で失敗します。
補足2: 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 で確認するのも有効です。
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 タブで以下を実行:
Appendix B Q&A
Q. レジストリ設定後にブラウザの再起動は必要か？
必須ではありません。Chrome / Edge はバックグラウンドで定期的にポリシー設定を再読み込みするため、一定時間の経過後に自動反映されます。即時反映したい場合は、chrome://policy または edge://policy を開いて「ポリシーを再読み込み」をクリックしてください。
Q. 拡張機能をアンインストールするには？
レジストリから以下のキーを削除します。HKLM\Software\Policies\Google\Chrome\ExtensionSettings\bdeanmdeckegmfjpbnngomallcedjoldHKLM\Software\Policies\Microsoft\Edge\ExtensionSettings\flggmhlpipcopffjfkpgkoljghfkmfcgHKCU\Software\Policies\Google\Chrome\3rdparty\extensions\bdeanmdeckegmfjpbnngomallcedjoldHKCU\Software\Policies\Microsoft\Edge\3rdparty\extensions\flggmhlpipcopffjfkpgkoljghfkmfcg
reg delete "HKLM\Software\Policies\Google\Chrome\ExtensionSettings\<ID>" /f /reg:64
ブラウザが次回ポリシーを再読み込みしたタイミングで拡張機能が削除されます。
Q. すでに配布済みの端末に再実行した場合はどうなる？
同じ bat を再実行すると、レジストリ値が上書きされるだけで二重インストールは発生しません。ApiKey や UserEmail の更新時も、同じスクリプトを再実行すれば安全に上書き反映されます。
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 をディレクトリ上でセカンダリアドレスとして登録すれば、ユーザーとのマッチングが可能です。
Q. Chrome と Edge で拡張機能 ID が違うのはなぜ？
Chrome Web Store と Microsoft Edge Add-ons はそれぞれ独立したストアで、同じ拡張機能でも異なる ID が割り当てられます。配布スクリプトは両方に対応しています。Q. 管理者権限なしで Software\Policies を書き換えられるか？
書き換えられません。HKCU 配下は通常ユーザー自身で書き込み可能ですが、Software\Policies サブツリーだけは例外で、デフォルト ACL により管理者のみに書き込み権限が付与されています。本資料の配信シナリオは管理者権限での手動実行を前提としています。