はじめに

企業の認証基盤として利用される Active Directory は、可用性と冗長性の確保が極めて重要です。特に、災害対策 (DR) や拠点間冗長構成を前提とした設計では、ドメインコントローラーの配置やトラフィック制御がシステム全体の安定性を左右します。

近年、Microsoft Entra Global Secure Access (GSA) を活用することで、オンプレミス環境とクラウド環境をシームレスに接続し、セキュアなアクセスを実現するケースが増えています。

しかし、GSA を冗長構成の Active Directory サイトに展開する際には、Kerberos 認証の維持、DNS 解決の設計、コネクタグループの組み合わせ、ネットワークトラフィックの効率性 など、複数の設計上のポイントを押さえる必要があります。

本記事では、東京をメインサイト、シンガポールをサブサイトとする冗長構成を例に、GSA 展開設計のベストプラクティスを整理します。公式ドキュメントを参照しながら、設計上の落とし穴や選択肢のメリット・デメリットを比較し、実務に役立つ指針を提示します。

記事の執筆時点 (2025/12/22) の GSA の仕組みを使って評価した内容を記載しています。
将来、GSA の動作に変更が加えられた場合は、設計そのものの考え方が変わってくる可能性もありますので、あらかじめご承知おきください。

1. 前提事項

この環境を構成するために必要な情報です。
参照されたい方は、▶ を押してください。

前提事項を参照するには、ココをクリック

1-1. Active Directory が構成された環境

本記事では、メインサイトとサブサイトにそれぞれドメインコントローラーを配置されていることを前提としています。

Active Directory ドメインサービス (ADDS) の導入
https://qiita.com/carol0226/items/b94f93adc309b5dc8ee8

２台目のドメインコントローラーの構築手順は、私の記事では用意が無いのですが、ドメインコントローラーの昇格を行う際に、以下のように 既存のドメインにドメインコントローラーを追加する を選ぶことがポイントです。

1-2. Microsoft Entra Connect が構成されていること

Microsoft Entra Connect とは（旧：Azure AD Connect）
https://qiita.com/carol0226/items/487874f07d2fe90f8e0c

Microsoft Entra Connect の冗長化は？
Entra Connect では、パスワードハッシュ同期 (PHS) と パススルー認証 (PTA) の 2 種類の認証方式があります。
冗長化を検討する際は、これらの違いを踏まえて ステージングサーバー の導入有無を判断します。

■ PHS の場合
Active Directory のアカウント情報をクラウドへ同期しているだけなので、
メインの Entra Connect が停止しても、すぐにサインインできなくなるわけではありません。

ただし、停止中にオンプレミス側でアカウント変更があっても
Entra 側には同期されないため、この点を考慮して
ステージングサーバーを導入するかを検討します。

■ PTA の場合
クラウド認証時も、必ず Entra Connect を経由してオンプレ AD が認証します。
そのため、Entra Connect がダウンするとサインインができなくなります。

PTA を利用する場合は、ステージングサーバーの導入が必須です。

Support Blog：ステージングサーバーのすゝめ
https://jpazureid.github.io/blog/azure-active-directory-connect/introduction-staging-server/

1-3. Microsoft Entra Hybrid Join が構成されていること

以下の記事を参考に Hybrid Join を構成してください。

Microsoft Entra ハイブリッド参加（旧HAADJ）を構成してみた
https://qiita.com/carol0226/items/7c16c4813e2b54a76789

1-4. Microsoft Entra Kerberos の構成（パスワードレス環境では必須）

Active Directory 環境で GSA を利用する場合、Kerberos 認証が正しく動作することが必要です。

GSA は、OS のログオン前はオフラインの状態であり、ログオン後にアクティブになります。
これが影響し、パスワードレス (WHfB や FIDO2 セキュリティキー）によるサインインの場合は、Kerberos チケットが取得できません。

Entra Kerberos を構成することで、GSA 経由のアクセスでも Kerberos チケットを取得可能となり、ドメイン参加済みのクライアントが従来通りの認証フローを維持できます。

特に、ファイルサーバーや社内ポータルなど Kerberos 前提のアプリケーションを利用している場合、この設定がないと認証失敗が頻発するため、押さえておくべきポイントです。

公開情報：Microsoft Entra Private Access でリソースへのシングルサインオン (SSO) に Kerberos を使用する
https://learn.microsoft.com/ja-jp/entra/global-secure-access/how-to-configure-kerberos-sso?wt.mc_id=MVP_407731

Microsoft Entra Kerberos 認証を構成しオンプレミスへ SSO する
https://qiita.com/carol0226/items/a52a54ff63c19fa957e6

1-5. GSA プライベートアクセスを構成済みであること

以下の記事を参考に GSA プライベートアクセスを構成してください。

Microsoft Entra Global Secure Access の全体像
https://qiita.com/carol0226/items/29cba6c32a22893a1349

[GSA] グローバルセキュアアクセスクライアントの導入手順
https://qiita.com/carol0226/items/8e30fc6caf36c83894dc

[GSA] プライベートネットワークコネクタの導入手順
https://qiita.com/carol0226/items/3f2572dc2169abf26ca4

2．導入設計ベストプラクティス

本章で紹介する内容を考慮に入れた設計を行うことで、災害対策 (DR) や 可用性確保が可能になります。
※評価検証は Azure を使い東日本リージョンと、東南アジアリージョンを活用して実施しています。

評価検証で使った構成図

凡例

水色 = GSA クライアントと接続場所（拠点、日本国内、海外）
黄緑 = プライベートネットワークコネクタ (PNC)
桃色 = ドメインコントローラー (DC)
橙色 = 基幹系システム（Act-Act 構成：主系）
青色 = 基幹系システム（Act-Act 構成：副系）

評価検証で使った AD 構成

シングルフォレスト、シングルドメイン
ドメイン名：avd.server-on.net
ドメインコントローラー(DC)：２台

評価検証で使ったネットワーク構成

#	メインサイト	サブサイト	拠点
場所	東京	シンガポール	日本国内の物理拠点
ネットワーク	10.10.0.0/16	10.20.0.0/16	192.168.100.0/24
DNS サーバー	10.10.10.5	10.20.10.4	192.168.100.1
AD サーバー名	AZ-NOGUCHIS-ADS .avd.server-on.net	AD02 .avd.server-on.net	なし
AD サイト名	JapanEast	SouthEastAsia	JapanEast
GSA プライベートコネクタ (PNC)	GSA .avd.server-on.net	GSA02 .avd.server-on.net	なし

想定シナリオ
メインサイト、サブサイト、拠点は VPN 回線で接続されています。
各サイトにドメインコントローラーとプライベートコネクタが最低１台ずつ配置されています。

PC には、GSA クライアントがインストールされており、社内外を行き来します。
つまり、拠点の社内 LAN に接続して利用したり、社外に持ち出して GSA プライベートアクセスを利用するということを想定しています。

2-1. Active Directory サイトとサービス

※この構成は、他の構成と組み合わせて、検証済みです。

ドメインコントローラーのサイト設計を GSA と組み合わせて構成する方法についてです。

通常時はメインサイトのドメインコントローラーへトラフィックを転送
DR 時にはサブサイトへ自動切替

GSA プライベートアクセス経由の通信は NAT によりソース IP が合成 IP (6.6.0.0/16) に変換されるため、Active Directory サイトによる DC 参照先の判定に影響します。

そのため、6.6.0.0/16 をサブネットに追加し、メインサイトに割り当てます。

公開情報：Active Directory サイトとサービスの概要
https://learn.microsoft.com/ja-jp/security-updates/planningandimplementationguide/19871944?wt.mc_id=MVP_407731

このように構成しておくことで、GSA 経由のドメインコントローラーへのアクセスは、メインサイトが優先されるようになります。

参考：合成 IP（6.6.0.0/16）について
GSA のプライベート DNS を利用した場合、クライアントが内部リソースの FQDN を名前解決すると、実際のサーバー IP アドレスではなく 6.6.x.x の IPアドレスが返されます。

このアドレスは、“合成 IP（Synthetic IP）” と呼ばれています。

これは、アプリケーションの通信を必ず GSA エッジ経由にルーティングするための仕組みです。
アプリケーションはこの合成 IP に向けて通信しますが、実際には GSA によって内部ネットワークの本来の IP へ転送されます。
一般的な業務アプリでは問題ありませんが、下記のようなケースでは注意が必要です。

アプリケーションが「実 IP アドレス前提」で動作している
ファイアウォールや ACL が “クライアント → サーバーの本来の IP” を期待している
IP アドレスをログ解析やアクセス元制御に利用している

多くの環境ではそのまま利用できますが、IP アドレスを直接扱うアプリケーションがある場合は、事前に動作確認を行うことをお勧めします。

公開情報：Microsoft Entra プライベート DNS について
https://learn.microsoft.com/ja-jp/entra/global-secure-access/concept-private-name-resolution?wt.mc_id=MVP_407731

（上記の公開情報より抜粋）

ユーザーは、 app.contoso.comの DNS クエリを要求します。ローカルにキャッシュされていない場合、DNS クエリは GSA エッジの DNS プロキシに送信されます。
DNS プロキシは、キャッシュから応答するか、クイックアクセスで定義されているコネクタグループにクエリを転送します。
コネクタサーバーは、オペレーティングシステムレベルで構成された DNS サーバーに DNS クエリを送信します。
DNS プロキシは、内部 IP を使用してクライアントに応答します。クライアントは内部 IP アドレスを格納し、合成 IP をアプリケーションに返します。

なぜ合成 IP が使われているのか
合成 IP が使われる理由は、単なる「IP アドレス衝突回避」に留まりません。
GSA の設計では、以下のような複数の要因が重なっています。

クライアントから内部リソースへの通信を必ず GSA Edge に流すため（強制トンネル化）
実 IP を返すと OS のルーティングや VPN/LAN でバイパスされる可能性があり、
これを防ぐために “存在しない” 合成 IP を返して GSA に強制的に中継させます。
自宅や支店のプライベート IP と企業ネットワークの IP が重複していても問題なく通信できるようにするため
内部リソースの実 IP をクライアントに晒さない（Zero Trust 的なセキュリティ向上）
どのネットワーク（社内LAN／自宅／カフェ／ホテル／モバイル回線）でも一貫した動作をさせるため
合成 IP に統一することで、クライアント OS のルーティング設定や上位ネットワーク構成の差異を GSA が吸収できるようになります。

これらの理由から、GSA は内部 IP の代わりに “存在しない” 合成 IP（6.6.x.x）を DNS 応答として返し、実通信は GSA Edge → Connector → 内部リソースの経路で処理されます。

2-2. コネクタグループ

コネクタグループをどう構成するかで、トラフィック制御の柔軟性が変わります。

単一グループにまとめるとロードバランスが可能
サイトごとに分けると経路制御が明確化

しかしながら、現時点では非常に制約が多い状況であり、制約をしっかりと理解しておかないと、コネクタグループの設計はままなりません。その点について説明していきます。

2-2-1. 国／地域

コネクタグループを構成する前に、重要な制約事項を理解しておく必要があります。

テナントの既定の Geo 場所によって、Default コネクタグループの国／地域が決まっており変更できません
クイックアクセスでは、上記の国／地域しか利用できません
プライベート DNS は、クイックアクセスでしか利用できません
→　つまり、プライベート DNS 機能は、固定された国／地域を使う以外に選択肢はありません。

重要
私の身の回りの各種テナントの状況（手元、同僚、お客様など）を見ると日本国内でサインアップしたテナントであっても、国／地域が、日本の場合とアジアの場合の２通りがありました。
※これは、私の勘ですがテナントをサインアップした時期による違いのような気がしています。

まずは、運用に利用する環境の Default コネクタグループの国／地域を把握しておくことが重要です。

注意点
上記の制約を無視して、対応していない国／地域をコネクタグループに設定しようとすると、以下のエラーが発生して構成することができません。

公開情報：概要
https://learn.microsoft.com/ja-jp/entra/global-secure-access/how-to-enable-multi-geo?wt.mc_id=MVP_407731#overview
（上記の公開情報より抜粋）

公開情報：最も近いアプリケーションプロキシクラウドサービスを使用するようにコネクタグループを最適化する
https://learn.microsoft.com/ja-jp/entra/identity/app-proxy/application-proxy-network-topology?wt.mc_id=MVP_407731#optimize-connector-groups-to-use-closest-application-proxy-cloud-service
（上記の公開情報より抜粋）

国／地域の種類について
国／地域は、コネクタグループを作成する際に選べますが、現時点 (2025/12/22) で私のテナントでは、北米、ヨーロッパ、オーストラリア、アジア、日本の５箇所しか選べませんでした。

2-2-2. 複数地域機能 (Multi-Geo コネクタ)

複数地域機能を利用することで、アプリごとのアクセス（エンタープライズアプリ）に限って、国／地域を指定することが可能になっています。

公開情報：Microsoft Entra Private Access の複数地域機能を有効にする
https://learn.microsoft.com/ja-jp/entra/global-secure-access/how-to-enable-multi-geo?wt.mc_id=MVP_407731#enable-multi-geo-capability

（上記の公開情報より抜粋）

上記の注意事項にも記載がありますが、Multi Geo コネクタは、クイックアクセスには使用できません。
前章でしたように、クイックアクセスには、テナントに定められた国／地域を使用するしかありません。

2-2-3. コネクタグループの制約を踏まえた DR の設計とは？

前章までに説明した、重い制約を踏まえて DR を設計する必要があります。

プライベート DNS は、クイックアクセスを使用する必要がある
→　Active Directory のドメインの利用には、プライベート DNS が必須です。
Multi-Geo の利用は、アプリごとのアクセスを使用する必要がある
→　ネットワークセグメントのトラフィックフローを最適化するには、アプリごとのアクセスが必要です。

設計段階で「どのトラフィックをどこに流すか」を明示的に決めておくことが重要です。

テナントの国／地域の違いによって、以下のような構成例が考えられます。

テナントの国／地域が ”日本” だった場合の構成例

#	メインサイト	サブサイト	国内拠点
コネクタグループ名	Default	Backup	Default
国／地域	日本（固定）	任意の場所 ※日本 or アジア	任意の場所 ※日本が推奨
データセンターの場所	東京	シンガポール	国内拠点
名前解決を行う場所	〇
コネクタの割り当て	GSA.avd.server-on.net <※３台以上を推奨>	GSA02.avd.server-on.net <※３台以上を推奨>	未割当

テナントの国／地域が ”アジア” だった場合の構成例

#	メインサイト	サブサイト	国内拠点
コネクタグループ名	Active	Default	Active
国／地域	任意の場所 ※日本を推奨	アジア（固定）	任意の場所 ※日本を推奨
データセンターの場所	東京	シンガポール	国内拠点
名前解決を行う場所		〇
コネクタの割り当て	GSA.avd.server-on.net <※３台以上を推奨>	GSA02.avd.server-on.net <※３台以上を推奨>	未割当

プライベートコネクタの可用性
上記のキャプチャは PoC なので各サイトにコネクタが１台ずつしかありませんが、運用を考慮すると各サイトに３台以上のコネクタを配置することが、ベストプラクティスであると Microsoft 社から聞きました。

※公式ドキュメントでは「2 台以上」が HA の最低要件ですが、
実運用では自動メンテナンスや負荷分散を考慮し、3 台以上を Microsoft から推奨されるケースが多いとのことです。

公開情報：コネクタの更新
https://learn.microsoft.com/ja-jp/entra/global-secure-access/concept-connectors?wt.mc_id=MVP_407731#connector-updates

公開情報：Microsoft Entra プライベートネットワークコネクタグループ
https://learn.microsoft.com/ja-jp/entra/global-secure-access/concept-connector-groups?wt.mc_id=MVP_407731

2-3. DNS のためのクイックアクセス設定

※この構成は、他の構成と組み合わせて、検証済みです。

通常、クイックアクセスはデータセンターのネットワーク全体を許可するなど、おおざっぱに接続をさせたい場合に使う機能です。そしてアプリごとのアクセスは、よりきめ細かな設定を行う場合に使います。

しかし、ドメインコントローラーの名前解決を行えるようにする「プライベート DNS」の機能はクイックアクセスでしか使えません。GSA × AD 連携で最も重要なポイントの一つです。

名前解決以外の通信（IP アドレスベースの通信）を、クイックアクセスで構成しても、Active Directory の通信としては問題はありませんが、DR の設計を考慮した場合には、後述する「アプリごとのアクセス」で構成ことを考える必要が出てきます。

項目	クイックアクセス	アプリごとのアクセス
主な用途	広範囲のネットワークや DNS をまとめて許可	サイトごとの詳細な経路制御、セグメント単位の通信制御
役割	プライベート DNS が動作する唯一の場所	個別アプリ・ネットワークセグメントへの接続制御
柔軟性	低い（広い範囲を一括許可する設計）	高い（詳細な制御が可能）
Geo の制約	あり（Default と同じ Geo でなければ設定不可）	なし（任意の Geo のコネクタを選択可能）
典型的な用途	- DNS 解決用（AD / Kerberos に必須） - 大規模ネットワークの簡易許可	- メインサイト／サブサイトへの最適経路分離 - DC やファイルサーバーなどの明示的ルーティング
AD × GSA で必要か	必須（DNS がクイックアクセスでしか動作しないため）	サイト分離を行う場合に必須
制御粒度	粗い	細かい（セグメント単位）

次章では、DNS のためのクイックアクセスを構成していきます。

後述する 2-3-1 と 2-3-2 の設定は、GSA で Active Directory を利用するためには、マストな設定になります。これを行わないと、ドメイン内の名前解決や Kerberos 認証が出来なくなります。

手順の流れ（画面遷移）は、以下の記事も参考にしてください。

[GSA:Private] クイックアクセスを構成する
https://qiita.com/carol0226/items/0ebd719f3e7ff805faa9

2-3-1. アプリケーションセグメントタブ

ドメイン名 (FQDN) に対して、DNS のトラフィック（TCP/UDP Port:53) を登録します。
ドメイン名にアスタリスク（＊）があるものと無いもので２行追加してください。

2-3-2. プライベート DNS タブ

プライベート DNS を有効にする（緑枠）
ドメインコントローラーや社内アプリケーションへのアクセスでは、正しい名前解決が必須です。GSA の「プライベート DNS」機能を利用することで、ドメイン名を解決できるようになります。

DNS サフィックス（水色枠）
ドメイン名を入力します。

公開情報：プライベート DNS サフィックスを追加する
https://learn.microsoft.com/ja-jp/entra/global-secure-access/how-to-configure-quick-access?wt.mc_id=MVP_407731#add-private-dns-suffixes

2-3-3. クライアント PC の DNS サフィックスリスト

既定ではホスト名のみの名前解決に際して、xxxx.globalsecureaccess.local がサフィックスとして付与されますが、これに依存すると一部アプリケーションが動作しなくなるケースがあります。例えば、ホスト名だけでアクセスする設計のアプリでは、意図しないサフィックスが付与されることで認証や接続が失敗します。
そのため、ポリシーで正しい DNS サフィックスを配布し、クライアントがドメイン名を正しく解決できるようにすることが重要です。

以下の図のように、１行目にドメイン名 (avd.server-on.net) を追加することで対応します。

以下のように GPO で設定することも可能であり、テスト済みです。
コンピューターの構成－管理用テンプレート－ネットワーク－DNS クライアント－DNS サフィックス検索一覧

本カスタマイズが必要となる理由
（GSA が接続されていない場合）
既定では以下のように、プライマリ DNS サフィックスが利用されるようになっています。
この場合、ホスト名（例：gsa）のみの名前解決を行うと、プライマリ DNS サフィックス (avd.server-on.net) を付加した FQDN (gsa.avd.server-on.net で名前解決が行われます。

以下のような結果が返されます（プライマリ DNS が付加）

（GSA が接続された状態）
自動的に以下の設定に切り替わるようになっています。
この場合、ホスト名（例：gsa）のみの名前解決を行うと、DNS サフィックスリスト(xxxx.globalsecureaccess.local) を付加した FQDN (gsa.xxxx.globalsecureaccess.local で名前解決が行われます。

以下のような結果が返されます（DNS サフィックスリストの１番目が付加）

2-3-4. アプリごとのアクセス

※この構成は、他の構成と組み合わせて、検証済みです。

メインサイトとサブサイトを分けて構成する場合、DNS の参照先だけをクイックアクセスに残す ことがベストプラクティスです。前章でも解説しましたが、プライベート DNS は、クイックアクセスしか使えないためです。

各サイトへのアクセス制御は、アプリごとのアクセスを使います。
これにより、各サイトごとに最適な経路を明示することができます。

テナントの国／地域が ”日本” だった場合の構成例

#	メインサイト	サブサイト
コネクタグループ	Default - 日本	Backup - アジア
セグメント	10.10.0.0/16	10.20.0.0/16

テナントの国／地域が ”アジア” だった場合の構成例

#	メインサイト	サブサイト
コネクタグループ	Active - 日本	Default - アジア
セグメント	10.10.0.0/16	10.20.0.0/16

メインサイト

サブサイト

公開情報：グローバルセキュアアクセスアプリケーションを使用してアプリごとのアクセスを構成する方法
https://learn.microsoft.com/ja-jp/entra/global-secure-access/how-to-configure-per-app-access?wt.mc_id=MVP_407731

2-3-5. オンプレミスアプリケーションに条件付きアクセス/MFA を適用する

※まだ、この機能は検証できていません。

この章の構成をしなくても、前章までの構成で、Active Directory x GSA は動きます。

必須ではありませんが、セキュリティ強化の観点からは推奨される機能です。特に、管理者向けポータルや機密性の高いアプリケーションに対して MFA を適用することで、社外からの不正アクセスリスクを大幅に低減することが期待できます。

公開情報：Active Directory ドメインコントローラー用に Microsoft Entra Private Access を構成する (プレビュー)
https://learn.microsoft.com/ja-jp/entra/global-secure-access/how-to-configure-domain-controllers?wt.mc_id=MVP_407731

2-3-6. インテリジェントローカルアクセス

※この構成は、他の構成と組み合わせて、検証済みです。

AD ドメイン参加の PC の場合、社内と社外を行き来するシーンが多いと思います。そのような場面で活かせる機能です。

社内 LAN では余計な遅延を回避
社外からはセキュアに GSA 経由で接続
という二重のメリットが得られます。

「AD および、プライベートコネクタと社内 LAN 回線で結ばれた拠点」のネットワークアドレスを追加していくことで、GSA クライアントがそのネットワーク帯に接続された場合は、LAN 回線が優先されるようになります。

公開情報：インテリジェントローカルアクセスを有効にする (プレビュー)
https://learn.microsoft.com/ja-jp/entra/global-secure-access/enable-intelligent-local-access?wt.mc_id=MVP_407731

3. 参考情報

Active Directory と直接関係ありませんが、社内と社外を行き来する端末であることを想定した場合に、考慮しておいた方が良いと思われる情報です。

3-1. プロキシサーバーの撤廃を検討する

一般的に、プロキシサーバーは社内 PC からインターネットへのアクセス制御で用いられています。（サイト制限、ログ記録など）

GSA インターネットアクセスを利用すると、Web フィルタリングや、脅威インテリジェンス、TLS インスペクション、ログ記録などのセキュリティ機能を利用することができるようになります。

GSA を常に有効にして利用することで、社内／社外を一元化したインターネットセキュリティポリシーを適用することが可能となり、社内プロキシサーバーの代替にできるかもしれません。

補足
インターネットアクセスは、ライセンスが必要ですし、社内プロキシを撤廃できない事情もあると思います。そのような場合は、後述するプロキシ除外設定やローカルブレイクアウトの利用を検討してみてください。

3-2. プロキシサーバー利用時に必要なプロキシ除外設定

自社データセンター内にプロキシサーバーを採用しており、社外でも GSA プライベートアクセス経由で、プロキシを参照させたい場合は、以下の記事を参考にしてください。私の研究の成果が詰まった記事になっています。

[GSA] グローバルセキュアアクセスクライアント用のプロキシ除外設定
https://qiita.com/carol0226/items/df821a681986b1020ab3

3-3. Microsoft 365 通信のローカルブレイクアウト

ローカルブレイクアウトの目的

Microsoft 365 は最適化された先（Microsoft のフロントドア）に最短で届けるべき
プロキシ経由にすると「遅延」「帯域集中」が発生しやすい
Microsoft 公式も “M365 トラフィックはプロキシしない方がよい” と明示している

社内プロキシは使う必要があるが、Microsoft 365 の通信はプロキシを使いたくない・・・という場合は、PAC ファイルを作成し、プロキシの対象から除外することも検討しましょう。

ですが、GSA 用の除外設定と Microsoft365 用の除外設定を抱き合わせて構成する必要があって、ちょっと大変です。このあたりは、今後研究の成果を記事にしていければと思っています。

公開情報：Microsoft 365 の URL と IP アドレスの範囲
https://learn.microsoft.com/ja-jp/microsoft-365/enterprise/urls-and-ip-address-ranges

公開情報：重要な Microsoft 365 トラフィックの直接ルーティングに PAC ファイルを使用する
https://learn.microsoft.com/ja-jp/microsoft-365/enterprise/managing-office-365-endpoints?view=o365-worldwide#use-a-pac-file-for-direct-routing-of-vital-microsoft-365-traffic

PowerShell Gallary：Get-PacFile
https://www.powershellgallery.com/packages/Get-PacFile/1.0.4

Support Blog：ローカルエリアネットワーク (LAN) の設定について
https://microsoft.github.io/jpbrowsers/internet-explorer-microsoft-edge/LAN-Settings/

4. BCP 発動時の切替方法

BCP 発動時の切替手順を説明します。

4-1. テナントの国／地域が ”日本” だった場合の手順

正常時

メインサイト全滅時の切替手順
ちょっと、違和感を覚えるかもしれませんが、以下の手順で切り替えます。

アプリごとのアクセス (10.20.0.0/16) に割り当てるコネクタグループを Default - 日本 に変更します。
サブサイト（シンガポール）のプライベートコネクタを Default - 日本 に変更します。

この切替を行っても、すでに GSA クライアントがシンガポールのコネクタを利用していた場合でも、切断はされないので、安心してください。
※利用中のコネクションは継続される動作となっているようです。

なぜ、このような切替になるのか？

Geo は GSA のアクセスポイントの位置であり、企業の DC の位置を意味しない
Geo はテナントごとに固定のため、BCP 時も変えられない

まず、メインサイト（東京）側のデータセンターが全滅した場合、サブサイト（シンガポール）への IP アドレスベースのアクセスは生き残ります。
そのとき、クイックアクセスには Default - 日本が割り当てられているため、名前解決ができなくなります。

普通に考えると、クイックアクセスに割り当てられているコネクタグループを Backup - アジアに切り替えれば良さそうに見えますが、GSA の制約によってその切り替えができないのです。

そのため、本章で紹介した手順で切り替えることによって、名前解決と IP アクセスの両方をメインサイトに切り替えるようにしています。

分かりづらい理由
メインサイト（東京）側のデータセンターが全滅している時に、サブサイト（シンガポール）のコネクタを Default - 日本に切り替えるのは違和感があると思います。しかし、顧客のメインサイトのデータセンターが止まっていても、 GSA 接続先 (Geo 日本) は稼働しています。
プライベート DNS は、Geo を変更できない仕様なので、それを使い続けることを前提に設計するしかないのです。

注意点
なお、日本沈没のようなことが起こり、自社の日本データセンターと GSA の日本 Geo が両方ダウンするようなことがあった場合は、名前解決はあきらめなければならなくなる可能性があります。

4-2. テナントの国／地域が ”アジア” だった場合の手順

正常時

メインサイト全滅
メインサイト（東京）が全滅した場合は、メインサイトへの疎通が失われます。
サブサイト（シンガポール）への疎通や名前解決は引き続き提供されます。
なお、VPN 経由でサブサイト経由でメインサイトへのアクセスが出来ることを期待して、以下の切替手順を実施します。

切替手順
以下の手順で切り替えます。

アプリごとのアクセス (10.10.0.0/16) に割り当てるコネクタグループを Default - アジア に変更します。

サブサイト全滅
サブサイト（シンガポール）が全滅した場合は、名前解決が出来なくなるため、以下の切替を実施します。

切替手順
以下の手順で切り替えます。

アプリごとのアクセス (10.10.0.0/16) に割り当てるコネクタグループを Default - アジア に変更します。
メインサイト（東京）のプライベートコネクタを Default - アジア に変更します。

5. 候補の組み合わせパターン

前章までの構成で、DR 設計および BCP 発動時の切替方法まで紹介しました。

実は、前章までに紹介した設定は、以下の３つうちのパターン１の構成でした。
本章では、異なる方法の紹介と、メリット・デメリットについてまとめています。

パターン１：
ネットワーク効率が最適であり、メインサイトの全滅時でも IPベースのアクセスが残る点でバランスが良いため、これを元に手順として説明することにしました。
※両方のサイトが同じくらいアクティブに利用される環境でも、パターン１が良いように思います。
　
パターン２：
メインサイトへのアクセスに寄せており、ネットワーク効率はベター。メインサイト全滅時の影響が大きいため、パターン１の方が良いと考えました。
　
パターン３：
何といっても、切替なしで運転できることが最大のメリットです。しかし、通常時のトラフィックの半分がサブサイトのコネクタを経由して、VPN 回線を通って、メインサイトに到達することになるため、回線遅延の影響と VPN 回線のトラフィック増加（コストも増加？）という悩ましい課題が生じます。

テナントの国／地域が ”日本” だった場合

#	パターン１前章までに紹介	パターン２	パターン３
コネクタグループ Default	GSA	GSA	GSA GSA02
コネクタグループ Backup	GSA02	GSA02	未使用
メインサイトへの経路	日本 Geo	日本 Geo	1. 日本 Geo 2. アジア Geo -> シンガ DC -> VPN 回線 ※50 対 50
サブサイトへの経路	アジア Geo	日本 Geo -> 東京 DC -> VPN 回線	1.日本 Geo -> 東京 DC -> VPN 回線 2. アジア Geo ※50 対 50
プライベート DNS	コネクタグループ Default - 日本	コネクタグループ Default - 日本	コネクタグループ Default - 日本
エンタープライズアプリ 10.10.0.0/16	コネクタグループ Default - 日本	コネクタグループ Default - 日本	コネクタグループ Default - 日本
エンタープライズアプリ 10.20.0.0/16	コネクタグループ Backup - アジア	コネクタグループ Default - 日本	コネクタグループ Default - 日本
メインサイト全滅時	名前解決できない IP ベースのアクセスは可	全滅	継続利用可能
BCP 切替方法	（手動） - 10.20.0.0/16 を Default に変更 - サブサイトの PNC を Default に変更	（手動） - サブサイトの PNC を Default に変更	（自動）
VPN 回線トラフィック	ほぼ無し	サブサイト行きのトラフィックがメインサイト経由	メインサイト行きの 50% がサブサイト経由サブサイト行きの 50% がメインサイト経由

テナントの国／地域が ”アジア” だった場合

#	パターン１前章までに紹介	パターン２	パターン３
コネクタグループ Active	GSA	GSA	両サイトに、追加コネクタが必要
コネクタグループ Default	GSA02	GSA02	GSA GSA02
メインサイトへの経路	日本 Geo	日本 Geo	1. 日本 Geo 2. アジア Geo -> シンガ DC -> VPN 回線 ※50 対 50
サブサイトへの経路	アジア Geo	日本 Geo -> 東京 DC -> VPN 回線	1. 日本 Geo -> 東京 DC -> VPN 回線 2. アジア Geo ※50 対 50
プライベート DNS	コネクタグループ Default - アジア	コネクタグループ Default - アジア	コネクタグループ Default - アジア
エンタープライズアプリ 10.10.0.0/16	コネクタグループ Active - 日本	コネクタグループ Active - 日本	コネクタグループ Active - 日本
エンタープライズアプリ 10.20.0.0/16	コネクタグループ Default - アジア	コネクタグループ Active - 日本	コネクタグループ Active - 日本
メインサイト全滅時	名前解決とサブサイトは通信継続	全滅	継続利用可能
BCP 切替方法	（手動） - 10.10.0.0/16 を Default に変更	（手動） - 10.10.0.0/16 を Default に変更 - 10.20.0.0/16 を Default に変更	（自動）
VPN 回線トラフィック	ほぼ無し	サブサイト行きのトラフィックがメインサイト経由	メインサイト行きの 50% がサブサイト経由サブサイト行きの 50% がメインサイト経由

パターン２と３の構成図については、後日公開予定です。
表の設定値をもとに構成していただければ、動作を確認することが可能ですので、ぜひ各パターンに切り替えて、実際の動作を比較してみていただけると宜しいかと思います。

6. まとめ

本記事では、Active Directory のサイト冗長構成に Microsoft Entra Global Secure Access（GSA）を安全かつ効率的に統合するための設計ポイントを整理しました。

GSA × AD を正しく動作させるためには、次の 3 つの領域をバランス良く設計することが重要です。

1. 認証・名前解決レイヤーの安定化

クイックアクセスでしか動作しないプライベート DNS の制約を理解する
合成 IP（6.6.x.x）による強制トンネル化の仕組みを把握する
パスワードレス環境では Entra Kerberos を導入して Kerberos 認証を維持

2. ネットワーク経路の最適化

コネクタグループでサイトごとの経路制御を明確化
AD サイトに合成 IP (6.6.0.0/16) を登録し DC 参照先を安定化
社内 LAN にいるときはインテリジェントローカルアクセスで最短経路

3. DR・障害時を “最初から織り込む” 設計

GSA の Geo は変更できない前提で、名前解決の生死ラインを理解する
障害時にどのパターンで切り替わるかを設計段階で決めておく

結論
これらのポイントを押さえて設計することで、
✔ AD と GSA の相互依存を理解した安全な構成
✔ サイト障害時にも破綻しない可用性
✔ 社内外で快適に利用できるユーザー体験

を同時に実現できます。

GSA × AD の組み合わせは制約も多いですが、設計原理を理解して、可用性・セキュリティ・運用性のバランスが取れた最適なハイブリッドアクセス基盤の構築を目指しましょう！