はじめに
GSA の Explicit Forward Proxy がパブリックプレビューとして公開されたのを見て、私は強い関心を持ちました。
それは新機能としての目新しさというよりも、
これまで個別に考えてきた AVD と GSA と テナント制限 に関する知見が、
ひとつの設計として整理できそうだと感じたからです。
本記事は、現時点での公式ドキュメントと、
これまでの検証・設計経験をもとにした 考察・整理記事 です。
実機検証については、今後あらためて行う予定です。
参考：私が取り組んできた GSA に関するストックリスト
https://qiita.com/carol0226/stocks/878e7bbc57b301e0deac
参考：私が取り組んできた AVD に関するストックリスト
https://qiita.com/carol0226/stocks/9b6759f2de8121689fc3
参考：[Entra ID] テナント制限 の実現方式を整理してみた
https://qiita.com/carol0226/items/6139f8c7eb2283dd6a10
初回投稿時に説明しきれていなかった観点（2026/5/3 追記）
これまで Global Secure Access に関心を持ってきた背景には、
AVD 環境における Microsoft 365 トラフィックに対して、Entra ID を前提としたテナント制限をスマートに実装したい という強い気持ちがありました。
とくに、GSA が提供する Microsoft Traffic や Universal テナント制限の考え方には魅力を感じていましたが、GSA クライアントが前提となるため AVD マルチセッション環境では設計として成立しない という制約があり、検討は途中で止まっていました。
Explicit Forward Proxy の提供は、そうした前提を見直すきっかけとなり、
GSA の設計思想を AVD マルチセッション環境に持ち込める可能性が見えてきた――
本記事は、その観点からの整理・考察です。
初回投稿の内容に対して、第１章へ テナント制限や Azure Firewall に関する 追加・変更 を行っています。
第1章：AVD マルチセッションに対応できるという点への注目
Explicit Forward Proxy のドキュメントを読んで、私がまず注目したのは
Azure Virtual Desktop（AVD）のマルチセッション環境で利用できそうだ
という点でした。
ポイント
Explicit Forward Proxy は、設計上 マルチセッション環境を考慮していることが示されています
公開情報：明示的な転送プロキシ (プレビュー) の概要
https://learn.microsoft.com/ja-jp/entra/global-secure-access/concept-explicit-forward-proxy?wt.mc_id=MVP_407731
（上記より抜粋）
- マルチセッション仮想デスクトップ インフラストラクチャ (VDI) ★来た！
- キオスク
- Linux デスクトップ上のブラウザー
- 簡易に管理されたデバイスの場合
- Microsoft Edgeと Intune アプリ ポリシーを使用した Bring Your Own デバイスの場合
私はこれまで、GSA と AVD の技術を中心に活動してきましたが、
GSA クライアントの前提と AVD マルチセッションの特性が噛み合わないため、
Global Secure Access（GSA）を AVD マルチセッションで利用する
という組み合わせのシナリオには、前提となる仕様が矛盾しているため、
現実的に取り組むことが不可能でした。
AVD マルチセッションと GSA クライアントの特性の矛盾点
AVD マルチセッション環境には、次のような特徴があります。
- 1つの OS
- 1つの IP アドレス
- 複数ユーザーが同時にログオン
一方で、GSA クライアントは
1 ユーザー = 1 デバイス
という前提で設計されています。
2026/5/1 時点
GSA クライアントのマルチセッションは、サポート外です。
GSA クライアントの前提条件
https://learn.microsoft.com/ja-jp/entra/global-secure-access/how-to-install-windows-client?wt.mc_id=MVP_407731
（上記より抜粋）
- 単一セッションAzure Virtual Desktopがサポートされています。
- Azure Virtual Desktopマルチセッションはサポートされていません。
- Windows 365がサポートされています。
この前提の違いにより、AVD マルチセッション環境では、
- ユーザーごとのセッション識別が難しい
- 条件付きアクセスの安定適用が困難
- 公式なサポート対象外となっている
という制約が存在していました。
結果として、
GSA クライアントが AVD マルチセッション上で利用できるようになることが、
公式にサポートされる見込み は無かったと考えています。
AVD 環境でテナント制限を実装するための選択
― 設計の行き詰まりと、Explicit Forward Proxy が示した転機 ―
これまで私は、AVD マルチセッション環境において、テナント制限をどのように実装するか
という点に強い関心を持ち続けてきました。
AVD 環境でテナント制限を実現しようとすると、
従来は 3rd Party 製のプロキシサービスを併用し、
テナント制限 v1 や Auth Plane TRv2 と組み合わせる構成が、
現実的な選択肢となるケースが多くありました。
[Entra ID] テナント制限 の実現方式を整理してみた
https://qiita.com/carol0226/items/6139f8c7eb2283dd6a10
技術的には実現可能である一方で、
外部のプロキシサービスを前提とする構成そのものに、私はあまり納得感を持てずにいました。
AVD 環境において、できるだけ Microsoft のプラットフォーム内で
テナント制限を完結させたいと考えていたからです。
そうした背景から、私が AVD 向けに提唱してきたのが TRv2 on Windows です。
この方式であれば、
- AVD マルチセッション環境で利用でき
- 外部プロキシを必要とせず
- OS レベルでテナント制限を実装できる
という点で、設計としての整合性が高いと考えていました。
参考：Microsoft Entra テナント制限v2 on Windows で 外部テナントへのアクセスをブロックする
https://qiita.com/carol0226/items/f0d9bcb8adffb66d49f2
ただしこの方式には、
Universal TRv2 が提供されるまでの “時限的な選択肢” である
という明確な制約がありました。
その後、GSA を利用した Universal TRv2 が提供され、
ようやくこの制約が解消されると期待したのですが、
実際には GSA クライアントが前提となり、AVD マルチセッションでは使用できない
という制約が存在していました。
この時点で、
AVD マルチセッション向けのテナント制限は、これからどうするのか？
という課題が、設計上はっきりと残ることになります。
一度 Universal TRv2 を見据えた以上、
今さら Auth Plane TRv2 に戻るという選択は取りたくない、
というのが正直な感覚でした。
そうした中で登場したのが、
Global Secure Access の Explicit Forward Proxy です。
GSA クライアントを前提とせず、
AVD マルチセッション環境からの通信を
GSA 側で制御できる可能性が示されたことは、
これまで行き詰まっていた設計に対して
新しい道筋が見えてきた瞬間でした。
なお、現時点 (2026/5/3) では GSA Explicit Forward Proxy は
Microsoft Traffic には対応しておらず、
Universal TRv2 を直接利用できる状態ではありません。
それでも、
AVD マルチセッション環境を GSA の制御モデルに載せられる可能性
そのものが示された点に、私は大きな意味を感じています。
本記事で Explicit Forward Proxy に強い関心を持っているのは、
このような設計上の経緯が背景にあるのです。
AVD 環境で Web フィルタ実装時の選択肢
それから、従来は AVD 環境で Web カテゴリフィルタリングやアクセス制御を実装する場合はどうなっていたのか？
現実的には、以下のような方法しかありませんでした。
- 3rd Party 製のプロキシ（Squid など）
- Microsoft Defender for Endpoint
- Azure Firewall（要：Premium SKU）
その結果、
- Entra ID を起点とした制御が難しい
- ネットワーク中心の設計になりがち
- GSA / Conditional Access と一貫したモデルを作りにくい
といった課題があり、Webフィルタとテナント制限を組み合わせて設計をシンプルに保つことが難しい状況でした。
補足：Azure Firewall Explicit Proxy という選択肢について（2026/5/3 追記）
なお、Azure Firewall Explicit Proxy というサービスも 同時期にプレビュー提供されています。
公開情報：Azure Firewall 明示的プロキシ (プレビュー)
https://learn.microsoft.com/ja-jp/azure/firewall/explicit-proxy
こちらも、AVD 利用時の Web フィルタリングの強力な選択肢となりますが、テナント制限 を制御する事はできない見込みです。
Web フィルタの選択肢に GSA EFP が加わったことによる変化まとめ
GSA EFP が出たことで、AVD マルチセッションで Web フィルタ を利用する際の選択肢が増えたことになります。
| # | テナント制限 | Web カテゴリ フィルタ |
M365 ローカル ブレイク アウト |
AVD マルチ セッション 対応可否 |
|---|---|---|---|---|
| 3rd Party 製のプロキシ （Squid など） |
〇 TRv1 AuthPlane TRv2 |
〇 製品次第 |
△ PACで実装 |
〇 |
| Defender for Endpoint | ✕ | 〇 | ✕ | 〇 |
| Azure Firewall (Premium SKU) |
✕ | 〇 | 〇 サービスタグ で実装 |
〇 |
| TRv2 on Windows | 〇 | ✕ | ✕ | 〇 |
| GSA クライアント | 〇 Universal TRv2 |
〇 | 〇 Microsoft Traffic で実装 |
✕ |
| GSA Explicit Forward Proxy |
★期待大 Universal TRv2 |
〇 | ★期待大 Microsoft Traffic |
〇 |
- ✕ の項目は、製品単独では機能を持っていないため、他製品と組み合わせて対応する必要があります。
→ Azure Firewall で、テナント制限をするには、プロキシ または、TRv2 on Windows と組み合わせる等 - ★期待大 としたのは、現時点では 対応は明記されていないものの、設計上 対応される流れになると私は信じています。
Explicit Forward Proxy が提示している新しい前提
Explicit Forward Proxy は、
- GSA クライアントを使わず
- PAC ファイルでブラウザーを制御し
- Microsoft Entra ID によるユーザー認証と条件付きアクセスを適用する
という仕組みです。
少なくとも設計思想としては、
1 OS / 1 IP に複数ユーザーが同居する環境を前提にしているように見える
点が、AVD を扱ってきた立場からは非常に興味深く感じられました。
次章では、
Explicit Forward Proxy が
ユーザー単位の通信制御をどのように実現しているのか、
その設計と方式の全体像を整理します。
第2章：Explicit Forward Proxy におけるセッション管理の考え方
Explicit Forward Proxy を理解するうえで重要なのが、
「この通信は、どのユーザーのものか」をどのように判断しているのか
という点です。
Explicit Forward Proxy は、
Microsoft Entra ID による認証と条件付きアクセスを
ネットワークトラフィックに適用するために、
通信とユーザーを結び付ける仕組みを内部に持っています。
この仕組みが、本章で扱う セッション管理 です。
セッション管理とは何か（Smart Session / HTTP Header の関係）
セッション管理とは、Explicit Forward Proxy が、
「この通信は、Entra ID で認証されたどのユーザーのものか」
を判断するための仕組みを指します。
EFP では、このセッション管理を実現する方式として、
- PAC を用いる Smart Session Management（既定）
- PAC を用いず、HTTP ヘッダーによって関連付ける HTTP Header Session Management（代替方式）
の 2 つが用意されています。
ブラウザー単位・ユーザー単位制御という要件
Explicit Forward Proxy は、
ブラウザーから直接 Microsoft Entra Internet Access に接続する
仕組みです。
そのため、単に通信を中継するだけでなく、次のような制御を行う必要があります。
- 通信先ごとの経路制御
- DIRECT と PROXY の切り分け
- ユーザー単位でのセッション維持
これらを実現するためには、
通信の発生源であるブラウザーを起点として、
ユーザーと通信をひも付けて制御できることが重要になります。
手動プロキシ設定では制御の粒度が粗く、
OS レベルの制御ではユーザー認証と結び付けることができません。
その結果として、Explicit Forward Proxy では、
ブラウザー起点で柔軟に通信を振り分けつつ、
ユーザー単位のセッション管理と両立できる方式
として、PAC ファイルを用いた
Smart Session Management が
基本的な設計として採用されています。
なお、既存の送信プロキシ基盤をすでに運用している環境では、
PAC を用いずに HTTP ヘッダーを介して
ユーザーと通信を関連付ける
HTTP Header Session Management という選択肢も用意されています。
公開情報：HTTP ヘッダー セッション管理
https://learn.microsoft.com/ja-jp/entra/global-secure-access/how-to-configure-explicit-forward-proxy-headers?wt.mc_id=MVP_407731
しかしこの方式は、
TLS インスペクションやヘッダー注入といった
ネットワーク基盤側の前提条件を必要とします。
そのため本記事では、
より一般的で導入しやすい
PAC ファイルを用いた Smart Session Management を前提に、
Explicit Forward Proxy の設計を整理していきます。
Smart Session Management と PAC
この方式では、
- ブラウザーが PAC ファイルを取得するタイミングで
- ランダムなセッション識別子が導入され
- その識別子と送信元 IP（IP affinity）を組み合わせて
- ユーザーごとのセッションを維持する
という考え方が採られています。
この構造から読み取れる重要な点は、
送信元 IP アドレス単独に依存していない という点です。
Smart Session Management では、
IP アドレスが共有される環境であっても、
セッション識別子を併用することでユーザー単位のセッションを識別できるよう設計されています。
そのため、少なくとも設計思想の上では、
- 1 台の OS
- 1 つの（あるいは少数の）送信元 IP
- 複数ユーザーが同時に利用する
といった環境、たとえば
Azure Virtual Desktop（AVD）のマルチセッション構成のようなケースも
前提として織り込まれているように読み取れます。
またこのことから、PAC ファイルは単なるプロキシ設定手段ではなく、
Explicit Forward Proxy におけるセッション管理の一部として設計に組み込まれている
という位置付けであることが分かります。
公開情報：明示的転送プロキシ (プレビュー) セッション管理
https://learn.microsoft.com/ja-jp/entra/global-secure-access/concept-explicit-forward-proxy-session-management?wt.mc_id=MVP_407731
PAC ファイルのホスティングという前提
Smart Session Management は、EFP を有効にすると既定で有効になり、
Microsoft がホストする EFP 用 PAC ファイルを前提とした
PAC ファイルホスティングの仕組みに依存して動作します。
なお、公式ドキュメントでは、次の 2 つの方式が示されています。
- Microsoft がホストする PAC ファイル（既定で動作）
- 利用者自身がホストする PAC ファイル（自己ホスト PAC）
Microsoft がホストする PAC ファイルは、
テナントごとに提供される標準の PAC であり、
Explicit Forward Proxy の利用を開始するうえでは最も簡単な方法です。
この方式では、
- Explicit Forward Proxy に推奨される基本構成が含まれている
- Smart Session Management が利用可能
- PAC ファイルの内容は利用者側でカスタマイズできない
という特徴があります。
一方で、通信制御をより細かく行いたい場合には、
PAC ファイルを自前で用意し、Web サーバー上に配置する
自己ホスト PAC を選択する形になります。
公式ドキュメントでも、この 2 つの方式の存在と使い分けが説明されています。
公開情報：PAC ファイルホスティング
https://learn.microsoft.com/ja-jp/entra/global-secure-access/concept-explicit-forward-proxy?wt.mc_id=MVP_407731#pac-file-hosting
（上記より抜粋）
2026/5/1 時点では、以下の通り カスタム PAC ファイルの利用が想定されていますが、まだ使えません。
自己ホスト PAC が想定されている理由の考察
公式には、
- 将来的にカスタム PAC をアップロード可能になる予定
- 現時点では、細かな制御を行う場合は自己ホストが必要
とされています。
これは、
- Microsoft 365 は DIRECT
- その他は Proxy
- Entra 認証系は明示的に除外
といった柔軟な設計を行ってきた私の立場から見ると、
設計思想の観点では、自然な整理だと感じられます。
なお、いざ 自己ホスト PAC のホスト場所が必要になったら、
以下の私の Qiita 記事を参考に構成可能です。準備は万端です！
プロキシ自動構成ファイル（PAC ファイル）の配置場所を作成する
https://qiita.com/carol0226/items/ed3c69f40ad659ff3b58
以下は、以前に Private Access 用に検討した Microsoft 365 用の PAC です。
自社要件向けに、この記事で解説している内容を踏まえて PAC を設計し、自己ホスト PAC として運用できるようになることが期待されます。
[GSA:Private] Microsoft 365 の ローカルブレイクアウト用 PACファイル の検討
https://qiita.com/carol0226/items/f5e69ad6926c4e528916
第3章：Explicit Forward Proxy によって整理される責務／引き続き残る設計判断
本章では、Explicit Forward Proxy によって「Microsoft 側が吸収した責務」と「設計者に残り続ける判断」を分離して整理します。
Explicit Forward Proxy の導入によって変わるのは、
通信制御やセッション管理を
「どのように成立させるか」という実装上の責務の一部が、
公式機能として明確に切り出された点です。
一方で、
通信制御の方針そのもの――
どの通信を対象とし、どこを例外とするか――
といった設計判断が
不要になるわけではありません。
Explicit Forward Proxy は、
すべての設計を自動化する仕組みではなく、
設計すべき責務の境界を
明確に切り分ける仕組みだと整理できます。
公式機能に委ねられるようになる責務
従来、GSA 環境で PAC を設計・配備する際には、
- セッションを安定して維持するための工夫
- 認証・条件付きアクセスと衝突しないための調整
- PAC 配布や更新に伴う運用上の考慮
といった点を、
利用者側で細かく考える必要がありました。
Explicit Forward Proxy では、
Microsoft がホストする PAC と
Smart Session Management によって、
これらの要素が
公式機能として整理・吸収されています。
これにより、
「PAC が正しく機能するための実装上の難所」は
利用者が意識しなくてよくなります。
引き続き利用者側で考える必要がある設計判断
一方で、次のような判断は
Explicit Forward Proxy 導入後も
利用者側に残ります。
- どの通信を制御対象とするか
- どの通信を例外（DIRECT）とするか
- どこまで TLS inspection を行うか
- ローカルブレイクアウトとのバランスをどう取るか
これらは、
自己ホスト PAC を利用する場合に限らず、
通信制御の方針そのものとして
引き続き検討が必要な要素です。
PAC は、
そうした設計判断を実装に落とし込むための表現手段として、
引き続き重要な役割を担います。
補足：条件付きアクセスによる「利用ネットワーク」の制御
Explicit Forward Proxy では、
Smart Session Management を利用している場合であっても、
セッション管理の一部に
IP アフィニティ をアンカーとして使用しています。
「IP アフィニティをアンカーとして使う」 とは、
EFP が『この通信は誰の続きか』を判断するときに、
送信元 IP アドレスを “頼れる手がかりの一つ” として使っている
という意味です。
そのため公式ドキュメントでは、
必須ではないものの、
Explicit Forward Proxy を利用できるネットワークを、
組織が信頼する範囲に限定することが
条件付きアクセスによって強く推奨されています。
ここで言う「信頼されたネットワーク」とは、
特定のデバイスや場所を意味するものではなく、
組織として出口 IP を把握・管理できている通信経路
を指します。
✅ 含められる例
- オンプレミス データセンターの固定 IP
- Azure / AWS など IaaS 環境のアウトバウンド IP
- Azure Virtual Desktop / VDI 環境のアウトバウンド IP
- SASE / SWG など、組織管理下のリモートネットワーク出口 IP
- 本社・拠点ネットワークの NAT 出口 IP
❌ 含めない例（デフォルトでは）
- 不特定の自宅回線
- ホテルやカフェなどの公衆 Wi-Fi
- キャリア NAT 背後のモバイル回線
- 組織が出口 IP を把握できない共有ネットワーク
この条件付きアクセスは、
Explicit Forward Proxy を「動作させるための必須要件」ではありませんが、
- 想定外の IP 共有環境でのセッション誤関連付け
- 意図しないネットワークからの利用
といったリスクを抑止するための
利用者側に残るセキュリティ設計上のガードレール
として位置付けることができます。
公開情報：明示的な転送プロキシの条件付きアクセス ポリシー
https://learn.microsoft.com/ja-jp/entra/global-secure-access/how-to-configure-conditional-access-policy-for-explicit-forward-proxy?wt.mc_id=MVP_407731
第4章：適用シナリオの整理
― AVD / BYOD / キオスク / VDI ―
Explicit Forward Proxy は万能ではありませんが、
特に有効そうなシナリオが見えてきます。
- AVD マルチセッション：最も適合しそう
- BYOD：クライアントを入れたくない環境（★）
- キオスク端末：ユーザー切り替え前提の利用
- シングルセッション VDI：クライアント方式との使い分け
Explicit Forward Proxy は、
GSA クライアントの代替 ではなく、
GSA クライアント前提ではない環境を
Entra ネイティブな形で扱うための選択肢
として整理するのが分かりやすいと感じています。
★BYOD シナリオ の補足
Microsoft Edge と Intune のアプリ構成／アプリ保護ポリシーを組み合わせることで、
端末を管理対象にしないまま、
Explicit Forward Proxy の設定や証明書信頼を配布する構成も考えられます。
公開情報：Intune モバイル アプリケーション管理ポリシーを使用してグローバル セキュア アクセス明示的転送プロキシ (プレビュー) を使用してMicrosoft Edgeを構成する
https://learn.microsoft.com/ja-jp/entra/global-secure-access/how-to-configure-explicit-forward-proxy-intune-policy?wt.mc_id=MVP_407731
第5章：現時点での整理と今後の視点
Explicit Forward Proxy は、
単にプロキシの新しい実装方式を提供するものではなく、
- AVD マルチセッション
- テナント制限
- Global Secure Access
といった、これまで個別に扱われがちだった要素を
ひとつの設計として再構成するための枠組み を提示しているように見えます。
本記事では、公式ドキュメントとこれまでの知見をもとに、
- なぜ PAC が設計の前提になっているのか
- なぜ Smart Session Management が必要だったのか
- どの責務を Microsoft が吸収し、何が利用者側に残るのか
- どのシナリオで Explicit Forward Proxy が特に有効そうか
を整理してきました。
この整理を通して見えてきたのは、
Explicit Forward Proxy が「万能な仕組み」ではない一方で、
GSA クライアント前提では成立しなかった環境を、
Entra ネイティブな形で扱うための現実的な選択肢
を、初めて明確な形で示した点に価値がある、ということです。
現時点では、
- 設計思想として大きな矛盾は見当たらない
- 既存の運用課題と整合する点が多い
- 実環境で検証する価値が十分にある
という段階だと整理しています。
今後は、実際の検証を通じて、
- 想定通りに機能する領域
- 制約や注意が必要なポイント
を確認しながら、
Explicit Forward Proxy を 「どこで使い、どこでは使わないか」
という判断を、より具体化していきたいと考えています。
なお、Explicit Forward Proxy の具体的な有効化手順や
管理センター上での設定方法については、
以下の公式ドキュメントが参考になります。
公開情報：明示的な転送プロキシを構成する方法 (プレビュー)
https://learn.microsoft.com/ja-jp/entra/global-secure-access/how-to-configure-explicit-forward-proxy?wt.mc_id=MVP_407731