Active DirectoryのGPOで管理対象のブラウザから個人のGoogleアカウント利用を制限してみた

Last updated at 2026-09-13Posted at 2026-09-13

はじめに

Dirbatoの社内技術横断支援組織Backbeatに所属しているアーキテクトの福岡です。
先端技術の研究から開発のほか、技術情報の発信を行っている組織です。

今回はActive Directoryとブラウザの話です。
会社のPCから個人のGoogleアカウントを使わせたくない。GmailやGoogle Driveを業務用アカウントに限定したい。
こうした要件ではプロキシやSASEを検討することがありますが、Googleのサインイン制限はもう少し手軽に始められます。
EdgeやChromeにGPOを配布するとブラウザ自身に制限用のHTTPヘッダーを付けさせることができます。
実際に検証したところEdgeからのヘッダー送信と個人Googleアカウントのログイン拒否まで確認できました。
ただし、これだけで端末からのGoogle利用をすべて統制できるわけではありません。
対応ブラウザでもプロファイルに注意が必要ですし、ブラウザ以外の通信は別に考える必要があります。
今回は設定手順に加えて、実運用で気を付けたい範囲までまとめます。

通信途中でヘッダーを追加する構成ではないため、この方式にプロキシやTLSインスペクションは必要ありません。

検証日：2026年9月9日
公式仕様の確認日：2026年9月13日

本記事は公開用に構築した独立検証環境で確認した内容です。
顧客環境および社内本番環境のデータは使用しておらずドメイン名、OU名、GPO名、端末名などは説明用の値になっています。

まずは仕組みから

使うポリシーは AllowedDomainsForApps です。

許可するドメインを設定すると対応ブラウザが google.com とその配下へのHTTP/HTTPSリクエストに X-GoogApps-Allowed-Domains ヘッダーを追加します。

Active Directory
    │ GPOを配布
    ▼
管理対象のEdge / Chrome
    │ ブラウザがヘッダーを付与
    │ X-GoogApps-Allowed-Domains: example.co.jp
    ▼
Googleの対応する認証・サービス処理
    └ 許可対象外のアカウントによる利用を制限

GPOがGoogleアカウントを判定しているわけではなく、あくまでもブラウザの設定を配布する役割です。
ブラウザはヘッダーを送る役割でアカウントの判定はGoogle側になります。
この役割分担なのでヘッダーを付けるためだけに新しいプロキシを用意する必要はありません。

設定するのはGoogleアカウント側のドメイン

許可リストへ指定するのは、Google Workspaceなどで管理しているGoogleアカウントのドメインです。
ADのDNSドメイン名をそのまま設定するという意味ではありません。
たとえばADが ad.example.co.jp で業務用Googleアカウントが user@example.co.jp なら許可対象として確認するのは後者の example.co.jp です。
この制限専用のクラウド側ポリシーを新設しなくても使える点は便利ですが、許可したい管理対象Googleアカウントやドメインが存在することは前提です。

検証環境と確認したこと

項目	内容
ドメインコントローラー	Windows Server 2019 × 2台
GPO適用確認用	Windows Server 2022 / 2025 メンバーサーバー
設定対象のブラウザ	Microsoft Edge / Google Chrome
テンプレートの配置	セントラルストア
GPOの対象	検証用OU配下のコンピューター

Windows Server 2022ではGPO適用まで確認済みです。Windows Server 2025は追加確認用としてドメイン参加から確認を進めています。

EdgeとChromeへ同じ値を配布し、両方のレジストリへの反映を確認しています。
このうちブラウザのポリシー画面、実際のヘッダー送信、個人アカウントの拒否までを画面で確認した例として紹介するのはEdgeです。

Google Cloudやほかのブラウザについては後半で公式仕様を整理します。今回の実測結果とは分けて読んでいただければ幸いです。

以降のドメイン名、OU名、GPO名は説明用の例に置き換えています。

1. ブラウザのADMXを用意する

Microsoft Edge

Microsoft Edge for Businessからポリシーファイルを取得します。
ダウンロード画面の構成は変更されることがあるため、詳しい流れはMicrosoftの設定手順も参照してください。
今回使うのは msedge.admx と対応する言語ファイルです。

ファイル	用途
`msedge.admx`	Edge本体のポリシー定義
`ja-JP\msedge.adml`	日本語の表示リソース
`en-US\msedge.adml`	英語の表示リソース

更新管理用の msedgeupdate.admx などもありますが今回のポリシーだけならEdge本体の定義が対象です。
私が取得したパッケージはCABの中にZIPがある構成でした。
CABを展開してからZIPを展開すると windows\admx に到達できます。
ここは取得時の形式に合わせてください。常にZIPが直接ダウンロードされるとも、常に同じ入れ子構造だとも決め打ちしない方がよさそうです。

Google Chrome

Chrome Enterpriseのダウンロードページからポリシーテンプレートを取得します。
Chromeは chrome.admx だけでなく、google.admx もセットで配置します。
Googleの公式手順も両方のコピーを案内しています。

windows\admx\
├─ chrome.admx
├─ google.admx
├─ ja-JP\
│  ├─ chrome.adml
│  └─ google.adml
└─ en-US\
   ├─ chrome.adml
   └─ google.adml

バンドルの種類によって展開先の構造は変わるため、実際にADMXが入っているフォルダを確認してください。
google.admx は小さいファイルですが省略しないようにします。
対応するADMLも同じパッケージのものを使います。

2. ADMXを配置する

セントラルストアは必須ではありません。検証用の管理端末だけで編集するならローカルへのブラウザテンプレート追加でも設定できます。
ただ、本番では複数の管理者や管理端末からGPOを編集することもあります。
端末ごとに参照するADMXのバージョンが異なると設定項目の表示や運用に差異が生じるため、本番運用ではセントラルストアへの集約を検討してください。

方式	配置先
ローカル	`C:\Windows\PolicyDefinitions`
セントラルストア	`\\<ADドメイン>\SYSVOL\<ADドメイン>\Policies\PolicyDefinitions`

ただし、セントラルストアが存在するとGPMCは既定でそちらを参照します。 ローカルに追加したブラウザ設定が見つからない場合は、最初にここを確認します。両方のフォルダを自動で混ぜて表示する仕組みではありません。

$dom = $env:USERDNSDOMAIN

if ([string]::IsNullOrWhiteSpace($dom)) {
    throw 'ADドメイン名を取得できません。$domへ対象のADドメイン名を設定してください。'
}

$cs = "\\$dom\SYSVOL\$dom\Policies\PolicyDefinitions"
Test-Path -LiteralPath $cs

セントラルストアを新しく作る場合

ブラウザのADMXだけで作らず対象Windowsに合った標準のADMXとADMLも用意します。
今回の検証ではDCの C:\Windows\PolicyDefinitions を基に作成しました。
本番では管理対象OSに必要な定義がそろうかも確認します。

Windows標準の定義を入れ忘れた場合に起きるのは、主にGPMCで該当する管理用テンプレートの項目を表示できなくなることです。
※既存GPOの設定そのものが消えるという話ではありません。

既存のセントラルストアがある場合はバックアップしてから更新してください。
別の管理者が使っている定義もあるので、ドメコンのローカルファイル一式を無条件に上書きするのは避けた方がよいです。

以下のコードは新しくセントラルストアを作る場合の例です。

$dom = $env:USERDNSDOMAIN

if ([string]::IsNullOrWhiteSpace($dom)) {
    throw 'ADドメイン名を取得できません。'
}

$cs = "\\$dom\SYSVOL\$dom\Policies\PolicyDefinitions"

# このコードは新規作成用
if (Test-Path -LiteralPath $cs) {
    throw "セントラルストアは既に存在します: $cs"
}

New-Item `
    -Path $cs `
    -ItemType Directory `
    -Force | Out-Null

Copy-Item `
    -Path "C:\Windows\PolicyDefinitions\*" `
    -Destination $cs `
    -Recurse `
    -Force

今回の検証では、セントラルストア作成からWindows標準定義のコピーまでPowerShellで実行しました。

ブラウザ定義を追加する例

Windows標準の定義を配置済みのセントラルストアへEdgeとChromeの定義を追加します。
以下は今回の検証で使った流れを展開先のパスだけ記事用に置き換えたものです。
管理権限とSYSVOLへの書き込み権限がある環境で実行してください。
既存の同名ファイルは上書きするため、すでにブラウザのADMXを配置している環境では事前にバックアップしておいてください。

$ErrorActionPreference = 'Stop'

# セントラルストア
$dom = $env:USERDNSDOMAIN

if ([string]::IsNullOrWhiteSpace($dom)) {
    throw 'ADドメイン名を取得できません。'
}

$cs = "\\$dom\SYSVOL\$dom\Policies\PolicyDefinitions"

if (-not (Test-Path -LiteralPath $cs)) {
    throw "セントラルストアがありません: $cs"
}

# ADMXを展開したフォルダ
$edge   = 'C:\Temp\EdgeADMX\windows\admx'
$chrome = 'C:\Temp\ChromeADMX\windows\admx'

if (-not (Test-Path -LiteralPath $edge)) {
    throw "EdgeのADMXフォルダがありません: $edge"
}

if (-not (Test-Path -LiteralPath $chrome)) {
    throw "ChromeのADMXフォルダがありません: $chrome"
}

Edgeの追加

今回のポリシーで必要なのは msedge.admx です。

# Edge ADMX
Copy-Item `
    -LiteralPath "$edge\msedge.admx" `
    -Destination $cs `
    -Force

# Edge ADML
foreach ($lang in 'ja-JP', 'en-US') {

    $srcLang = Join-Path $edge $lang
    $dstLang = Join-Path $cs $lang

    New-Item `
        -Path $dstLang `
        -ItemType Directory `
        -Force | Out-Null

    Copy-Item `
        -LiteralPath "$srcLang\msedge.adml" `
        -Destination $dstLang `
        -Force
}

# 配置確認
Get-ChildItem $cs -Filter 'msedge.admx'
Get-ChildItem "$cs\ja-JP" -Filter 'msedge.adml'

ここでの New-Item -Force は残しておいて平気です。
上でWindows標準定義をコピーしているので通常は ja-JP などのフォルダもありますが、存在していても何も壊さず無ければ作るだけなので保険として残しておけます。

Chromeの追加

こちらは chrome.admx と google.admx の両方を配置します。

# Chrome ADMX
Copy-Item `
    -LiteralPath "$chrome\chrome.admx" `
    -Destination $cs `
    -Force

Copy-Item `
    -LiteralPath "$chrome\google.admx" `
    -Destination $cs `
    -Force

# Chrome ADML
foreach ($lang in 'ja-JP', 'en-US') {

    $srcLang = Join-Path $chrome $lang
    $dstLang = Join-Path $cs $lang

    New-Item `
        -Path $dstLang `
        -ItemType Directory `
        -Force | Out-Null

    Copy-Item `
        -LiteralPath "$srcLang\chrome.adml" `
        -Destination $dstLang `
        -Force

    Copy-Item `
        -LiteralPath "$srcLang\google.adml" `
        -Destination $dstLang `
        -Force
}

# 配置確認
Get-ChildItem $cs -Filter '*.admx' |
    Where-Object Name -Match 'chrome|google'

Get-ChildItem "$cs\ja-JP" -Filter '*.adml' |
    Where-Object Name -Match 'chrome|google'

今回の検証でも chrome.admx と google.admx、対応するADMLを配置してからGPOを設定しました。

複数DCがある場合はSYSVOLのレプリケーション状況も確認します。
配置後はGPMCの編集画面を開き直します。

3. 検証用OUを作り、対象コンピューターだけへGPOをリンクする

ここからはGUIで進めます。
最初からドメイン全体へGPOを当てず、検証用OUに対象コンピューターだけを入れて確認しました。

今回のイメージは次のとおりです。

ADドメイン
└─ BrowserRestriction-Test
   ├─ 検証対象のコンピューター
   └─ BrowserDomainRestriction をリンク

OUを作成する

Active Directory ユーザーとコンピューター を開く
OUを作る場所を右クリック
新規作成 → 組織単位 を選択
例として GoogleBlock を作成

今回はコンピューターの構成を使うのでユーザーではなく対象PCやメンバーサーバーのコンピューターオブジェクトをこのOUへ入れます。

検証対象のコンピューターを移動する

Active Directory ユーザーとコンピューター で対象のコンピューターを探す
対象を右クリックして 移動
作成した検証用OUを選択
OU配下へ移動したことを確認

GPOを作成してOUへリンクする

次に グループポリシーの管理 を開きます。

フォレスト → ドメイン → 対象ドメインを展開
作成した検証用OUを右クリック
このドメインにGPOを作成し、このコンテナーにリンクする を選択
例として GoogleBlock という名前で作成
GPOのスコープ画面でリンク先が検証用OUになっていることを確認

すでに作成済みのGPOを使う場合は、OUを右クリックして 既存のGPOのリンク から選択できます。

今回はコンピューターの構成を使います。ユーザーオブジェクトだけをOUへ移動しても目的の設定は配布されません。
また、同じGPOがドメイン直下など別の場所にもリンクされていないか確認します。検証用のつもりが広い範囲へ適用されるのを避けるためです。

必要ならセキュリティフィルターやWMIフィルターも確認します。
今回のようにOUで対象を切るだけなら、まずはリンク先とコンピューターオブジェクトの配置を確認するのが分かりやすいです。

4. AllowedDomainsForAppsを設定する

Edge

GPOを右クリックして 編集 を開きます。
設定場所は次のとおりです。

コンピューターの構成
  └ ポリシー
     └ 管理用テンプレート
        └ Microsoft Edge

設定数が多いので、右ペインのフィルターから Workspace で絞り込むと探しやすいです。

対象は Google Workspace へのアクセスを許可するドメインを定義する です。
識別名は AllowedDomainsForApps です。

有効 にして許可するドメインを入力します。

example.co.jp

複数指定する場合はカンマ区切りです。

example.co.jp,example.com

Chrome

同じGPOの編集画面で次の場所を開きます。

コンピューターの構成
  └ ポリシー
     └ 管理用テンプレート
        └ Google
           └ Google Chrome

Edgeと同じく Google Workspace へのアクセスを許可するドメインを定義する を有効にして、同じドメインを入力します。
Edge側を設定しただけでChromeへ自動的に反映されるわけではありません。

consumer_accountsは追加しない

個人アカウントを制限したい場合、許可リストへ consumer_accounts は追加しません。
これは個人用Googleアカウントを許可する特別な値です。@gmail.com や @googlemail.com に加え、会社ドメインのメールアドレスで作成された一般ユーザー向けGoogleアカウントも対象になります。

visitor_accounts はGoogle側で定義されるビジターアカウント向けの特殊値です。ブラウザのゲストモードやMicrosoft Entra IDのゲストユーザーとは別の概念ですので、利用する場合は導入時点のGoogle公式仕様を確認してください。
今回の基本構成では追加しません。

設定後はGPMCでGPOの 設定 タブを開き、EdgeとChromeの両方へ値が入っていることを確認します。

5. 設定の配布から実際の拒否まで確認する

GPOを設定しただけで終わらせずに段階を分けて確認します。

GPOが適用されているか

対象端末の管理者権限のターミナルで実行します。

gpupdate /force
gpresult /r /scope:computer

適用されたグループポリシーの一覧に、作成したGPOがあることを確認します。
※見つからなければブラウザ設定を見る前にOU、リンク、セキュリティフィルターを確認してください。

レジストリへ反映されているか

Get-ItemProperty 'HKLM:\SOFTWARE\Policies\Microsoft\Edge' `
    -Name AllowedDomainsForApps

Get-ItemProperty 'HKLM:\SOFTWARE\Policies\Google\Chrome' `
    -Name AllowedDomainsForApps

今回はEdgeとChromeの両方へ設定値が入っていることを確認できました。

ブラウザが設定を読み込んでいるか

Edgeは edge://policy、Chromeは chrome://policy を開きます。
ポリシーを再読み込みして AllowedDomainsForApps の値と状態を確認します。
反映が分かりにくい場合はブラウザを終了して起動し直します。
今回のEdgeでは適用先がデバイス、レベルが必須、状態が OK になっていました。

実際のリクエストにヘッダーが付いているか

Edgeで開発者ツールを開き、Networkタブを選択してからGoogleのページを再読み込みします。
google.com 配下へ送信されたリクエストを選び、Request Headersを確認します。

X-GoogApps-Allowed-Domains: example.co.jp

今回の検証では、このヘッダーが送られていることを確認できました。

開発者ツールの画面を公開する際はCookieやAuthorizationヘッダーを載せないようにします。
メールアドレスや認証URLのパラメーターにも注意が必要です。
上の画像は制限用ヘッダー周辺だけを切り出しています。

個人アカウントが拒否されるか

検証対象のEdgeプロファイルで、許可対象外の個人GoogleアカウントによるGoogle Workspace／Google Cloudへのサインインが拒否されることを確認

ヘッダーの送信だけでなく、Google側で拒否されるところまで確認できたことになります。
一方で、拒否できたことだけでは業務用アカウントが正常に使える証明にはなりません。
本番導入前には許可側も含めて確認する必要があります。

確認する操作	見たい結果
許可ドメインの業務用アカウントで利用	必要なサービスが正常に使える
個人用Googleアカウントで利用	対象サービスで拒否される
許可していない別組織のアカウントで利用	対象サービスで拒否される
設定前からログイン済みのアカウントで利用	既存セッションでも要件を満たすか確認する
別プロファイルや許可する別ブラウザで利用	同じ制限が成立するか確認する

この表は本番前の確認項目です。
※すべてを今回実測済みという意味ではありません。

どこまで制限できるのか

Googleサービス全体の接続禁止ではないです。この設定はURLブロックではなくアカウントに関する制限だからです。
Googleは認証不要のGoogle検索やYouTubeの利用までは禁止しないと説明しています。
Google Cloudでも対象サービスや認証経路に応じて X-GoogApps-Allowed-Domains が利用されます。ただし、ブラウザGPOが直接制御するのは当該ブラウザから送信されるリクエストです。gcloud CLI、デスクトップアプリ、直接のAPI通信については別途、対応範囲とヘッダー付与経路を確認する必要があります。

対象	この記事の方式で考える範囲
Gmail / Drive / Docsなど	対応サービスでのアカウント利用を制限する
Google Cloud Console	Google公式がヘッダー対応を明記。今回の個別実測とは別
Google検索・YouTubeの匿名利用	閲覧そのものを禁止する設定ではない
YouTubeなどのログインを伴う操作	認証経路も含めて確認する。ホスト名だけで対象外と決めない
CLI・デスクトップアプリ・直接のAPI通信	ブラウザGPOだけで統制できるとは考えない

youtube.com は google.com 配下ではないからログインも必ず素通りとまでは言えません。
ログインの途中でGoogleの認証先を使うことがあるためです。
匿名で見られることと個人アカウントでログインできることは別の確認項目として扱う必要があります。

制限するのはアカウントであり、アクセス先ではない

この設定で指定するのは、Googleへのログインを許可するアカウントのドメインです。
許可された会社アカウントが外部プロジェクトへのアクセス権を持っている場合、その外部プロジェクトにもアクセスできます。アクセス先を自社のGoogle Cloud組織やプロジェクトだけに限定する設定ではありません。
一方、Google Cloudのiam.allowedPolicyMemberDomainsなどによるドメイン制限付き共有は、管理対象のリソースに対してどのドメインのユーザーへIAM権限を付与できるかを制限する仕組みです。
端末からGoogleへログインできるアカウントを制限する本設定とは制御対象と目的が異なりますので注意です。

ほかのブラウザはどうなのか

Chrome系だから全部同じ設定が適用できるとは考えない方がよいです。
対応ポリシーと配布方法をブラウザごとに確認します。
反対にChromium系ではないから非対応とも限りません。

（ざっと調べてみたところ）

ブラウザ	公式情報で確認できたこと	今回の扱い
Edge	`AllowedDomainsForApps` を提供	設定配布・ヘッダー送信・個人アカウント拒否を確認
Chrome	`AllowedDomainsForApps` を提供	GPO設定とレジストリへの反映を確認
Firefox	同名ポリシーを提供。Firefox 89 / ESR 78.11以降	公式仕様の確認。今回の実機検証対象外
Comet	Enterprise向け公式カタログに同名ポリシーを掲載	公式仕様の確認。今回の実機検証対象外
Vivaldi	今回の調査では同名ポリシーの公式対応を確認できず	未確認。非対応と断定しない
Wavebox	今回の調査では同名ポリシーの公式対応を確認できず	未確認。非対応と断定しない

FirefoxはMozillaのWindows向けポリシーでも AllowedDomainsForApps を提供しています。
Chrome用のGPOを設定しただけでFirefoxへ設定されるわけではないので使うならFirefox側のテンプレートとポリシーも管理します。
Cometも公式カタログに AllowedDomainsForApps がWindows / macOS向けのポリシーとして明記されています。
ただし、公式に項目があることと自分の環境で期待どおり動いたことは別です。
承認ブラウザへ追加する前にヘッダーとログイン結果まで確認するのが安全です。

Safariは今回のWindows検証から外しています。

Edgeはプロファイルにも注意する

ブラウザ名だけで判断すると見落としやすい部分です。
Microsoftの AllowedDomainsForApps の仕様には、MicrosoftアカウントでサインインしたEdgeプロファイルには適用されないと記載されています。
これはWebサイトでGoogleアカウントにログインする話ではなく、Edge自体のプロファイルへ何のアカウントでサインインしているかという話です。

今回確認できたプロファイルで制限が動いたからといって、端末上のすべてのEdgeプロファイルでも同じとは決めつけられません。
実運用ではプロファイルの利用方針も決めます。
組織の方針に応じて RestrictSigninToPattern などのブラウザサインイン制御も検討してください。

ここは今回の実測を追加した話ではなくMicrosoftの公式仕様から読み取れる注意点です。

ブラウザを設定して終わりではない

ここまで設定したブラウザ以外から自由に通信できるなら端末全体の制限は保証できません。
ヘッダーを送らない未管理ブラウザや別アプリが利用可能なら今回の設定を通らない経路が残ります。
だからといってGPOに意味がないわけではありません。
設定したブラウザでの効果と、端末全体で回避経路をなくすことを分けて考えるのが大事です。
ブラウザ方式で統制するなら承認したブラウザと設定だけを利用できる状態にする必要があります。
その手段としてAppLockerやApp Control for Businessを検討できます。

AppLockerとApp Control for Business

仕組み	主な対象・特徴
AppLocker	アプリ、スクリプト、インストーラーなどの実行制御。ユーザーやグループ単位のルールを扱える
App Control for Business	アプリに加えてカーネルモードのドライバーも制御対象。より強い実行制御が必要な場合の候補

MicrosoftはAppLockerを多層防御の一要素と位置付けています。
より堅牢な保護が必要な場合はApp Control for Businessを検討する説明になっています。
ここでは本番向けの完成したアプリ制御ポリシーを提示するのではなく、設計時に気を付けたい点だけ整理します。

AppLockerはエディションだけで諦めない

Microsoftの現行要件では、KB5024351以降、Windows 10 version 2004以降とWindows 11では特定のエディションでなくてもAppLockerポリシーを適用できます。
古いEnterprise / Education中心の情報だけで判断しない方がよさそうです。

Application Identityサービスを起動する

AppLockerの強制には Application Identity サービスが必要です。
停止するとAppLockerポリシーは適用されません。

Get-Service AppIDSvc

GPOでAppLockerを配布する場合、MicrosoftはAppLockerルールを適用する少なくとも1つのGPOでApplication Identityを自動起動にするよう案内しています。

発行元・パス・ハッシュは使い分ける

AppLockerの主な条件は発行元、パス、ファイルハッシュです。
自動更新する署名済みブラウザでは発行元ルールが扱いやすい候補になります。
一方、パスルールにも保護された配置先を許可する用途があります。
ファイルハッシュはバージョン更新で値が変わるため継続的な更新が必要ですが、署名のない固定アプリでは使いどころがあります。
どれか1種類だけが正解というより対象アプリに合わせて選びます。

既定ルールを残したままではEdgeとChromeだけにならない

AppLockerの実行可能ファイルの既定ルールには、Windowsフォルダ、Program Files、ローカルAdministratorsに対する広い許可があります。
その状態でEdgeとChromeの許可ルールを足しただけでは、EdgeとChromeだけを実行可能にしたことにはなりません。
OS、業務アプリ、更新処理まで含めてルールを設計します。
いきなり強制せず、まず監査のみで動作を確認してから限定展開する方が現実的です。

補足：AzureやAWSでも同じことができる？

今回のGoogleの仕組みを、そのまま3クラウド共通の仕組みとは考えない方がよいです。
代表的な方式だけ並べると次のようになります。
対象サービスや保護範囲が同じという比較ではありません。

対象	代表的な方式	今回のGoogle方式との違い
Google	対応ブラウザの `AllowedDomainsForApps`	ブラウザへドメイン一覧を設定してヘッダーを送る
Microsoft Entraのテナント制限v2	クラウド側ポリシーとWindows端末設定、プロキシ、Global Secure Accessなど	クラウド側のポリシー構成が必要。展開方式によって対象が異なる
Microsoft Entraのテナント制限v1	プロキシによる認証通信へのヘッダー付与	プロキシとTLSインスペクションを含む構成
AWS Management Console Private Access	VPCエンドポイントとエンドポイントポリシー	経路、DNS、許可するAWSアカウントやOrganizationを設計する

Entraのテナント制限v2にはプロキシなしのWindows方式がありますが、公式には一部ブラウザを保護しない部分的な方式として説明されています。
Windowsへ設定すれば全ブラウザへ同じ制御が掛かるというものではありません。

AWS Management Console Private AccessもVPCエンドポイントを作るだけで完了するわけではなく、コンソールまでの通信経路とエンドポイントポリシーを合わせて設計します。
今回はこの中のGoogle向けブラウザ設定を実際に検証した記事です。

まとめ

GPOから AllowedDomainsForApps を配布することでEdge自身が制限用ヘッダーを送り、個人Googleアカウントが拒否されるところまで確認できました。
プロキシやTLSインスペクションを追加せずに始められるのはなかなか便利です。
ただしGoogleのサイトを丸ごと遮断する設定でも端末上のすべてのアプリを制御する設定でもありません。
利用するブラウザだけでなくプロファイルと認証経路まで確認して、必要に応じてアプリケーション制御などを組み合わせる必要があります。

設定できたことと、運用要件を満たしたことは別です。
レジストリに値が入ったら終わりにせず、ヘッダーと実際のログイン結果まで確認するところが今回のポイントでした。

同じ要件を検討している方の参考になれば幸いです！

参考文献

本記事の執筆と公開前の仕様確認では、以下の公式ドキュメントを参照しました。
いずれも2026年9月13日時点で確認しています。

Microsoft Edge - AllowedDomainsForApps
- Edgeにおける AllowedDomainsForApps、X-GoogApps-Allowed-Domains、consumer_accounts、Edgeプロファイルに関する仕様
Google Workspace - Block access to consumer accounts
- 個人Googleアカウントの利用制限、consumer_accounts、visitor_accounts、Google Cloudなどの対象範囲
Chrome Enterprise - AllowedDomainsForApps
- Chromeにおける AllowedDomainsForApps の仕様
Google Chrome Enterprise - WindowsでChromeブラウザのポリシーを設定する
- chrome.admx、google.admx、ADMLを利用したWindows向けポリシー配布
Microsoft - Group Policy Administrative TemplatesのCentral Storeを作成、管理する
- SYSVOL上の PolicyDefinitions とセントラルストアの管理
Mozilla - Firefox Enterprise Policy Templates
- Firefoxにおける AllowedDomainsForApps を含むEnterprise Policyの仕様
Microsoft - App Control for Business and AppLocker overview
- AppLockerとApp Control for Businessの位置付け
Microsoft Entra - Tenant restrictions v2
- Microsoft Entraにおけるテナント制限とGoogle方式との違い
AWS - AWS Management Console Private Access
- AWS Management Consoleへのプライベートアクセスと、Google方式との違い

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up