はじめに
このたび、AI エージェントによる自律運転を実現する Project Opal に対して、Global Secure Access (以降: GSA) を適用させることに成功したので、記事にしてみました。
Project Opal が利用する Windows 365 Cloud PC に対して、GSA の Explicit Forward Proxy（以降: EFP）を適用し、
- Web フィルタ
- 脅威インテリジェンス
- TLS インスペクション
- AI プロンプトポリシー
- アクセスログ
といった GSA を用いたガードレールを適用する方法を紹介します。
本検証の結論としては、
「Project Opal が利用する Edge に対してのみ EFP を適用する」
という構成により、Project Opal の自律運転と GSA のガードレールを両立できることを確認しました。
この記事でわかること
以下の内容を確認できます。
- Project Opal へ EFP を適用する方法
- Cloud PC 環境での条件付きアクセス設計
- GSA ガードレールの適用結果
- Project Opal と GSA を両立するためのポイント
接続の流れ（図ではスマホから操作していますが、PCのブラウザからでも操作可能です）
今回の構成は、
- Entra ID
- Conditional Access
- Device Filter
- Intune
- Windows 365
- Project Opal
- GSA
- EFP
といった、私が普段扱っている技術要素をほぼ総動員して実現しています。
そのため、単なる単体機能の紹介ではなく、複数のクラウドサービスを組み合わせた実践的な検証事例としても参考になるのではないかと思います。
経緯
5月末に Project Opal に出会ってから、比較的早い段階で、GSA との連携を検証していました。
ところが、なかなかうまく動作させることができずにハマっていたのですが、両立可能な構成を見つけることができたと考えています。
実は、Project Opal と EFP は、私が今年特に注目してきた機能でもあります。
そのため、両者を組み合わせた構成をようやく実現できたことは、個人的にも非常に感慨深い出来事でした。
個人的には、今年の一押し機能である Project Opal と EFP のマリアージュがようやく実現したことが、一番うれしかったポイントかもしれません。
Project Opal 標準機能 と GSA の違い
Project Opal は Web サイトへのアクセス制御機能を持っています。
以下の Websites Access 欄に URL を入力することで、サイトブロックの制御が行えます。
公開情報：Web サイトの既定のアクセス動作
https://learn.microsoft.com/ja-jp/microsoft-365/copilot/opal-settings-manage?wt.mc_id=MVP_407731#default-website-access-behavior
しかし、企業環境では既存のセキュリティポリシーや運用基盤と統合して管理したいケースも少なくありません。
Project Opal 標準機能と GSA を比較すると、以下のような違いがあります。
| 項目 | Project Opal 標準機能 |
GSA |
|---|---|---|
| URL ブロック | ○ | ○ |
| Web カテゴリベース制御 | ✖ | ○ |
| 脅威インテリジェンス | ✖ | ○ |
| TLS インスペクション | ✖ | ○ |
| AI プロンプトポリシー | ✖ | ○ |
| 統合ログ・監査 | ✖ | ○ |
Opal 標準機能だけでも特定サイトへのアクセス制御は可能ですが、GSA を利用することで、既存ユーザー向けに整備しているセキュリティガードレールを AI エージェントにも適用できるようになります。
本記事では、Project Opal が利用する Windows 365 Cloud PC に対して GSA の EFP を適用し、これらのガードレールを実現する方法を紹介します。
GSA とは何か？
GSA についてわからない方は、以下の私の記事を参照してください。
[GSA:Internet] Microsoft Entra インターネット アクセス を構成する
https://qiita.com/carol0226/items/ae2bfdb209170fb41bae
Project Opal との組み合わせに最適な GSA の接続方式とは？
GSA を利用するためには、以下の２通りの方法があります。
-
GSA クライアント
PC にアプリケーションをインストールして利用する従来からある GSA の接続方式 -
明示的なプロキシ - Explicit Forward Proxy (EFP)
2026 年 5 月に Preview 提供された プロキシを使ったインストールレスな GSA の接続方式
EFP については、以下の私の記事を参照してください。
[GSA : Internet] Explicit Forward Proxy (Preview) の構成手順と検証レポート
https://qiita.com/carol0226/items/1ea6d0608c177923a667
上記の記事でも触れていますが、EFP は プロキシを使うため アプリのインストールが不要になるため、Windows 365 の Cloud PC をベースとして動作する Project Opal とは相性が良いはずだと直感的に思いました。
GSA に接続するための仕組みの違い
| 項目 | GSA クライアント | Explicit Forward Proxy (EFP) |
|---|---|---|
| アプリのインストール | 必要 | 不要 |
| 導入方法 | クライアント配布 | PAC ファイル配布 |
| 対象トラフィック | OS レベル | ブラウザー中心 |
| 対象プロトコル | TCP / UDP | HTTP / HTTPS |
| 利用可能なチャネル | Internet Access Private Access Microsoft Traffic |
Internet Access のみ |
| Web フィルタ | ○ | ○ |
| 脅威インテリジェンス | ○ | ○ |
| TLS インスペクション | ○ | ○ |
| AI プロンプトポリシー | ○ | ○ |
| AVD マルチセッション | ✖ | ○ |
| BYOD への適用 | ✖ | ○ |
| Project Opal との親和性 | 未検証 | ○ 本記事の構成で動作確認済み |
なぜ GSA クライアントを使わなかったのか？
GSA クライアントを Cloud PC へ Intune で配布して利用する方法も考えられますが、それには抵抗を感じました。いくつか理由がありますが、無人で利用するものなので、GSA クライアントの状態を制御できないことが理由のひとつです。
それに対して EFP は追加ソフトウェアが不要であり、Opal が管理する Cloud PC に対する影響を最小限に抑えられることから、今回は EFP を採用しました。
なお、GSA クライアントを導入した構成については本記事では検証していません。
そのため、Project Opal と共存できるかどうかは現時点では未確認です。
ただし、次章の試行錯誤したこと で説明している通り、OS レベルでプロキシを適用すると Project Opal の自律運転が行えなくなったことから、GSA クライアントによって OS 全体の通信を制御した場合も、同様の影響が発生する可能性があるのではないかと私は考えています。
あくまで私の推測であり、実際の動作については別途検証が必要です。
Project Opal x GSA を実現するために試行錯誤したこと
① OS のインターネットオプションで設定 をトライしましたが、うまく行きませんでした。
② Edge のプロファイルに対して プロキシ設定を実施する を実施して、うまくいきました。
① OS のインターネットオプションで設定 → NG
まずは、EFP の環境を構成し、Project Opal の Cloud PC に適用してみました。
OS の設定パネルを使い、インターネットオプションの設定で、EFP の PAC ファイルの URL を指定しました。
すると、通信は GSA 経由にすることはできたものの、Project Opal による AI 自律運転が行えなくなりました。
これは、OS をプロキシ経由の通信とすることで、Project Opal の制御を妨げてしまっている可能性が考えられました。
Project Opal がどのような通信を行っているのかは情報が開示されていませんし、簡単には実現できないことを察しました。事実、ここから2か月間は進展させることができませんでした。
② Edge のプロファイルに対して プロキシ設定を実施する
2か月の沈黙を破り、この案を思いつきました。
これだったら 該当のブラウザセッションだけがプロキシ経由となり、その他の OS 上の通信は、非プロキシ扱いになるのではないかと考えました。
Edge プロファイルに対して、プロキシ設定を行うためには、Intune 構成ポリシーを使います。
思惑通り、この方法で Project Opal の Cloud PC に対して GSA を適用させることに成功しました。
Intune の機能を使って、Cloud PC に、Edge のプロキシ (PAC) を構成しています
構成手順
1. EFP の構成
以下の私の記事を参考に、手持ちの物理 PC や、仮想マシンなどを使って、GSA を EFP で接続できるところまで構成してください。
[GSA : Internet] Explicit Forward Proxy (Preview) の構成手順と検証レポート
https://qiita.com/carol0226/items/1ea6d0608c177923a667
2. Intune 構成ポリシー
Intune の設定カタログを利用して、Project Opal が利用する Microsoft Edge に対して PAC ファイル設定を配布します。
手順
1．Microsoft Entra 管理センターを開き、下図の場所から PAC ファイルの URL の内容をコピーしておきます。
設定する内容
上記でコピーした PAC の URL は、このあと Intune 管理センターで以下の設定を行う際に使用します。
- Choose how to specify proxy server settings (Device) = "Use a .pac proxy script" を選択
- URL to a proxy .pac file (Device) = 項番１でコピーした PAC の URL を貼り付け
2．Intune 管理センターを開き、構成ポリシー（設定カタログ）の作成を開始します。
3．基本情報 タブでは、任意の名前を付与して 次へ を押して進めます。
4．構成設定 タブでは、＋設定の追加 を押して、設定ピッカーで Microsoft Edge Update￥プロキシサーバー を選択し、以下の２つの設定値にチェックを入れます。
- Choose how to specify proxy server settings
- URL to a proxy .pac file
5．２つのトグルスイッチを Enabled へ変更します。
すると、テキストの入力欄が現れるため、以下の通りに設定を記入して、次へ を押して進めます。
- Choose how to specify proxy server settings (Device) = "Use a .pac proxy script" を選択
- URL to a proxy .pac file (Device) = 項番１でコピーした PAC の URL を貼り付け
6．スコープタグ は、そのまま 次へ を押して進めます。
7．割り当て タブでは、グループの追加 を選択し、Opal App Device Group を選択します。
8．以下のように表示されたら、次へ を押して進めます。
9．レビューと作成 タブで、作成 を押します。
10．以下のように構成ポリシーが作成されれば OK です。
3. 条件付きアクセスの考慮
3-1. 条件付きアクセスの課題
Cloud PC 環境で EFP を利用する際に、もう一つ課題となったのが、条件付きアクセスで推奨されているネームドロケーションの扱いです。
公開情報：明示的フォワードプロキシの適用範囲を既知のネットワークに制限する
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#scope-explicit-forward-proxy-to-known-networks
上記の EFP の公開情報では、条件付きアクセスで ネームドロケーションを使ったアクセス制御を実施することが推奨されています。しかし、Cloud PC の場合は、アクセス元の IP アドレスが不定なため、ネームドロケーションを使った制御を実現することができなくなるという矛盾が発生します。
矛盾発生の理由
私の EFP の記事の通りに構成していた場合は、以下のような設定になっています。
ネットワークの設定が有効
ネットワークの設定で、対象外 を指定
アクセスのブロック が構成されている
しかし、Cloud PC の IP アドレスは動的に割り当てられるため、EFP で推奨されているネームドロケーションを利用した構成は、Cloud PC 環境ではそのまま適用できないという課題があります。
3-2. 条件付きアクセスの課題解決 - デバイスフィルターによる制御
前章の課題を解決する方法として、デバイスフィルターによる制御を採用しました。
※Project Opal によって管理されている Cloud PC の場合という条件を加えることが可能になります。
Project Opal が作成する Cloud PC は model に "Microsoft 365 Copilot" が含まれていたため、これを利用して識別することにしました。
※2026年8月時点の筆者環境で確認した内容です。
"Microsoft 365 Copilot" が含まれていたら、このポリシーは 適用しない
つまり、EFP 推奨のブロックポリシーは Project Opal の Cloud PC は対象外になります。
"Microsoft 365 Copilot" が含まれていたら、このポリシーを 適用する
上記の条件が成立した場合は、以下の通り Intune 準拠を要求します。
以上の構成により、Cloud PC はネームドロケーションでは制御ができませんが、代わりに Intune 準拠を強制することで、セキュリティを確保するようにしています。
動作確認
各方式で動作させた結果です。
これにより、Project Opal からのアクセスについても一般ユーザーと同様の保護を適用できることが分かります。
GSA を経由したアクセスの確認 (CMAN)
CMAN (https://www.cman.jp) は、IT技術者向けに情報公開やサービスを提供しているサイトです。この CMAN では、ネットワークに接続している接続元の グローバル IP アドレスを表示する機能を提供してくれています。
CMAN の IP アドレス確認機能 (https://www.cman.jp/network/support/go_access.cgi) を使って、Project Opal の Cloud PC からの通信が、GSA を経由していることを確認しました。
[GSA:Internet] Microsoft Entra インターネット アクセス を構成する
https://qiita.com/carol0226/items/ae2bfdb209170fb41bae
GSA を経由して外部のサイトへアクセスした場合には、以下のエグレス IP 範囲のいずれかとなります。
128.94.0.0/19 (128.94.0.1 ～ 128.94.31.254 の範囲)
151.206.0.0/16 (151.206.0.1 ～ 151.206.255.254 の範囲)
公開情報：グローバル セキュア アクセスのエグレス IP 範囲
https://learn.microsoft.com/ja-jp/entra/global-secure-access/reference-points-of-presence?wt.mc_id=MVP_407731#global-secure-access-egress-ip-ranges
TLS インスペクションの確認
HTTPS 通信に対して TLS インスペクションが有効となり、復号後のポリシー評価が行われることを確認しました。
Web サイトの証明書を確認してみると、Microsoft Global Secure Access Intermediate CA2 になっていることで確認することができます。
[GSA : Internet] TLS インスペクションを構成する完全ガイド（AD CS 対応）
https://qiita.com/carol0226/items/9cda8cfa8c6b437f1161
Web コンテンツフィルタリングの確認
GSA のカテゴリベース Web フィルタが、Project Opal の Cloud PC 上で動作することを確認しました。一般ユーザー向けに利用している既存ポリシーを、そのまま Project Opal にも適用できます。
SNS のカテゴリがブロックされている環境で TikTok を表示させようとした場合
More Info を開くことで ブロックされた理由（該当の Category）を確認できます。
[GSA:Internet] Web コンテンツ フィルタリングを構成する
https://qiita.com/carol0226/items/e33dd928ae848691bb1e
脅威インテリジェンスの確認
既知の悪性サイトへアクセスした際に、GSA の脅威インテリジェンスによる検知および制御が動作することを確認しました。悪意のあるサイト（テスト用 https://entratestthreat.com ）にアクセスした際に、ブロックされることで確認できます。
脅威インテリジェンスでブロックされた画面
More Info を開くことで ブロックされた理由（脅威インテリジェンス = MaliciousUrl）を確認できます。
[GSA: Internet] 脅威インテリジェンスで悪意のあるサイトへのアクセスを防止する
https://qiita.com/carol0226/items/bf6e6c765cbbff5e5f00
生成 AI 情報分析ログ（AI プロンプトシールド）
Project Opal が実行した生成 AI へのアクセスについても、GSA 側でログを取得できることを確認しました。これにより、Project Opal の利用状況やアクセス先を運用チーム側で把握できるようになります。
Opal への指示で Gemini へプロンプトの投稿を指示しています。
以下のように Opal が Gemini へ投稿したプロンプトが 生成 AI 情報分析ログに記録されていることが分かります。
[GSA: Internet] プロンプトシールドによる生成AI防御：構成と実機検証・ログ確認
https://qiita.com/carol0226/items/379b4c0fbc534f639415
注意
今回の検証では、生成 AI 情報分析ログへの記録までは確認できました。
一方で、プロンプトシールドによるブロック動作については期待通りの結果にはなりませんでした。
本来のプロンプトシールドでは、悪意のあるプロンプトを検出して、ブロックする機能を持っています。
ところが、GSA クライアントで動作させた時にはブロックできるのですが、EFP で動作させた場合、ブロックされる動作を確認することができませんでした。
考察
今回の検証では、OS レベルで EFP を適用した場合は Project Opal の自律運転が行えず、Microsoft Edge のみに EFP を適用した場合は正常に動作しました。
Project Opal の内部実装は公開されていないため断定はできませんが、自律運転を実現するためにブラウザー以外の通信も利用しており、OS 全体をプロキシ経由にしたことで影響を受けた可能性があります。
一方で、Edge のみを EFP の対象とした場合は、Project Opal が利用する Web アクセスだけを GSA 経由にできたため、自律運転とセキュリティガードレールを両立できたものと考えています。
今回の検証により、人間向けに整備された GSA のポリシーを AI エージェントにも適用できる可能性を確認できました。
まとめ
今回の検証では、Project Opal が利用する Windows 365 Cloud PC に対して、GSA の EFP を適用し、既存のインターネットアクセス向けガードレールを Project Opal にも適用できることを確認しました。
検証の過程では、OS 全体にプロキシを適用する構成も試しましたが、Project Opal の自律運転が正常に動作しないという課題に直面しました。一方で、Project Opal が利用する Microsoft Edge のみに EFP を適用する構成とすることで、自律運転と GSA によるアクセス制御を両立できることを確認できました。
また、Cloud PC のように送信元 IP アドレスが固定されない環境では、ネームドロケーションによる制御よりも、Entra ID のデバイスフィルターを活用した制御が有効な選択肢となることも確認できました。
今回の構成により、Project Opal に対しても以下のような GSA のガードレールを適用できるようになります。
- Web フィルタ
- 脅威インテリジェンス
- TLS インスペクション
- AI プロンプトポリシー
- アクセスログ
Project Opal には標準の Web アクセス制御機能も用意されていますが、企業環境では既存のセキュリティポリシーや運用基盤と統合して管理したいケースも少なくありません。そのような観点からも、今回の構成は AI エージェントに対して既存のセキュリティガバナンスを適用する一つの実践例になるのではないかと思います。
個人的には、今年の一押し機能である Project Opal と GSA(EFP) のマリアージュを実現できたことが、今回の検証で最もうれしかったポイントでした。
今回の検証で興味深かったのは、AI エージェント専用の新しいセキュリティ製品を導入するのではなく、既存ユーザー向けに整備してきた GSA のガードレールを、そのまま AI エージェントにも適用できた点です。
AI の活用が進むほど、AI だけを特別扱いするのではなく、既存のユーザーやデバイスと同じガバナンスの枠組みで管理する考え方が重要になると感じています。
本記事が、Project Opal の実運用や、AI エージェントを既存のゼロトラスト環境へ統合する際の参考になれば幸いです。
検証時点に関する注意
- 本記事は2026年8月時点の Microsoft Frontier 版 Project Opal、および EFP に基づく実機検証です。Microsoft が Project Opal と EFP の組み合わせを公式リファレンス構成として保証したものではありません。
- EFP が取得するのは Microsoft Entra Internet Access の Web 通信であり、Microsoft 365 Traffic、Private Access、PAC を使用しないアプリケーション通信、Edge 外の OS 通信は対象外です。EFP では TLS インスペクションが必須です。
- OS レベル PAC で Opal が動作しなかった結果と、Edge 単位 PAC で成功した結果は筆者環境での観測であり、すべてのテナント・リージョン・将来バージョンで同じ動作を保証するものではありません。
- Intune ポリシー、GSA-ExplicitForwardProxy、Security Profile、Prompt Injection Protection、Opal 既定ポリシーは Preview／Frontier 更新により変更される可能性があります。適用前に Microsoft Learn の最終更新日、既知の制限、サインインログ、GSA Traffic Logs、edge://policy を再確認してください。