Microsoft Entra の Global Secure Access Web コンテンツ フィルタリングは、Web カテゴリ、URL、FQDN を使ってインターネットアクセスを制御するための機能です。今回確認すべきポイントは、単なる「URL ブロック機能」ではなく、セキュリティ プロファイルと条件付きアクセスを組み合わせて、ユーザーやグループ、利用状況に応じた細かな制御を行う設計になっている点です。公式ドキュメントでは、ソース トラフィック種別や HTTP メソッド単位の制御、リモートネットワークへの適用、反映時間、既存ポリシーへの影響など、運用時に見落としやすい注意点が整理されています。(Microsoft Learn)
特に管理者が最初に確認すべきなのは、既存の Web Content Filtering Policy (V1) に「Deprecating soon」と表示されても、公式情報では表示エラーと説明されており、既存ポリシーは影響を受けず、現時点で対応は不要とされている点です。移行期限が示されている変更ではないため、慌ててポリシーを作り直すのではなく、設定内容、適用範囲、条件付きアクセスとの連携、ログ確認の手順を点検することが重要です。(Microsoft Learn)
Microsoft Entra Global Secure Access Web コンテンツ フィルタリングとは
Microsoft Entra Global Secure Access の Web コンテンツ フィルタリングは、Microsoft Entra Internet Access の Secure Web Gateway 機能として提供されるインターネットアクセス制御です。Web サイトのカテゴリ、URL、FQDN を条件に、組織のインターネット利用を許可またはブロックできます。Microsoft Entra ID と条件付きアクセスに統合されるため、単にネットワーク境界でブロックするのではなく、「誰が」「どの条件で」「どの宛先に」アクセスするかを踏まえて制御できるのが特徴です。(Microsoft Learn)
従来のファイアウォールやプロキシの URL フィルタリングと比較すると、Global Secure Access の強みは ID ベースの制御です。たとえば、全社員にはギャンブルや不審なサイトをブロックし、開発部門には一部の AI サービスを検証用途で許可し、外部委託ユーザーにはより厳しいカテゴリ制限を適用するといった運用がしやすくなります。
| 観点 | 従来型の URL フィルタリング | Global Secure Access Web コンテンツ フィルタリング |
|---|---|---|
| 主な制御軸 | IP、ネットワーク、プロキシ設定 | ユーザー、グループ、条件付きアクセス、Web カテゴリ、URL、FQDN |
| ポリシー適用 | ネットワーク境界中心 | Microsoft Entra ID と Security Service Edge によるクラウドエッジ適用 |
| リモートワーク対応 | VPN やプロキシ構成に依存しやすい | Global Secure Access クライアントやリモートネットワーク経由で制御 |
| 実務上の利点 | 既存ネットワーク構成に組み込みやすい | ID と端末利用状況を踏まえた粒度の細かい制御が可能 |
2026年6月30日の更新で押さえるべきポイント
今回のトピックでは、2026年6月30日に更新された公式リポジトリ上の変更を含めて確認する必要があります。GitHub の履歴では、対象ファイルに対して 2026年6月30日に「Update GSA Purview text content type docs」というコミットがあり、対象記事では関連リンク文言の更新などが含まれています。一方、Microsoft Learn ページ上の ms.date および表示上の最終更新日は 2026年6月1日です。社内の変更管理では、「Learn 表示上の更新日」と「GitHub 上の更新履歴」を分けて記録しておくと、監査や運用レビュー時に混乱を避けられます。(GitHub)
実務上の主な確認ポイントは、次の4つです。
| 確認項目 | 管理者が見るべきポイント |
|---|---|
| 既存ポリシーへの影響 | Web Content Filtering Policy (V1) の「Deprecating soon」表示はエラーとされ、既存ポリシーに影響はない |
| 設定モデル | Web コンテンツ フィルタリング ポリシーを作成し、セキュリティ プロファイルにまとめ、条件付きアクセスで配布する |
| 新しい粒度の制御 | ソース トラフィック種別と HTTP メソッド要求の条件を使えるが、いずれもプレビュー要素を含む |
| グローバル運用 | クライアント端末、拠点のリモートネットワーク、Explicit Forward Proxy 利用環境で適用方法が異なる |
何ができるようになるのか
Global Secure Access Web コンテンツ フィルタリングでは、現在、Web カテゴリ、URL、FQDN に基づくフィルタリングがサポートされています。さらに、オプションのルール条件として、ソース トラフィック種別フィルタリングと HTTP メソッド要求フィルタリングもサポートされています。(Microsoft Learn)
Web カテゴリ、URL、FQDN でアクセスを制御する
基本となるのは、宛先ベースの制御です。Web カテゴリを使えば、SNS、ギャンブル、ストリーミング、ニュース、AI サービスなどの分類に基づいて制御できます。URL や FQDN を使えば、特定のサービスやドメインを名指しで許可またはブロックできます。
実務では、まずカテゴリで大枠を制御し、業務上必要な例外を URL または FQDN で調整する設計が扱いやすくなります。たとえば「SocialNetworking カテゴリは原則ブロック。ただし、企業公式アカウント運用チームには特定の SNS 管理ツールを許可する」といった形です。
AI エージェント、ブラウザー、アプリケーション単位で制御する
ソース トラフィック種別フィルタリングでは、トラフィックの発生元を Agent、Browser、Application、Unknown といった種別で扱えます。これにより、ブラウザーからの閲覧は許可しつつ、AI エージェントからのアクセスは制限するといった制御が可能になります。公式例では、AI エージェントによるソーシャルネットワーキングサイトへのアクセスをブロックし、ブラウザーやアプリケーションからのアクセスは許可する構成が紹介されています。(Microsoft Learn)
この機能は、生成 AI や自律型エージェントの利用が増える組織で特に重要です。人間のユーザーには問題ない操作でも、AI エージェントが同じサイトへ自動アクセスする場合、情報漏えいや想定外の投稿、外部サービスへのデータ送信リスクが高まるためです。
HTTP メソッド単位で読み取りと書き込みを分ける
HTTP メソッド要求フィルタリングでは、GET、POST、PUT、PATCH、DELETE などのメソッドを条件にできます。たとえば、GET による閲覧は許可し、PUT、PATCH、DELETE のような変更系の操作をブロックするといった最小権限の設計が可能です。公式ドキュメントでは、AI エージェントによる PUT、PATCH、DELETE 操作をブロックする例が示されています。(Microsoft Learn)
ただし、HTTPS トラフィックで HTTP メソッドを判定するには TLS 検査が必要です。TLS 検査を有効にしない場合、Secure Web Gateway は HTTP メソッドヘッダーを確認できず、SNI ベースの Web コンテンツ フィルタリングのみが適用されます。(Microsoft Learn)
設定の全体像
Global Secure Access Web コンテンツ フィルタリングの設定は、1つの画面で完結する単純なブロックリストではありません。基本の流れは、インターネット トラフィック転送を有効化し、Web コンテンツ フィルタリング ポリシーを作成し、それをセキュリティ プロファイルにまとめ、条件付きアクセス ポリシーでユーザーやグループに適用する構成です。(Microsoft Learn)
| 手順 | 作業内容 | 実務上の注意点 |
|---|---|---|
| 事前準備 | Global Secure Access の開始設定、クライアント導入、必要ロールの確認 | Global Secure Access Administrator と Conditional Access Administrator の役割を分けて確認する |
| トラフィック転送 | Internet Access traffic forwarding profile を有効化 | 対象ユーザーやグループに割り当てないと検証できない |
| フィルタリング ポリシー作成 | カテゴリ、URL、FQDN、アクションを定義 | 命名規則と優先順位の設計が重要 |
| セキュリティ プロファイル作成 | 複数のフィルタリング ポリシーをまとめる | 部門別、拠点別、委託先別などの単位で設計すると管理しやすい |
| 条件付きアクセス連携 | Session control で Global Secure Access security profile を指定 | 反映に時間がかかる場合があるためテスト計画に含める |
| 検証 | Traffic logs とクライアント診断で確認 | ブロック画面だけで判断せず、ログで allow/block を確認する |
管理者が設定時に注意すべきポイント
FQDN の書き方を間違えると意図どおりに一致しない
FQDN を指定する場合は、プロトコル、ポート番号、URL パスを含めず、ドメイン名のみを入力します。たとえば https://contoso.com:443/path ではなく、contoso.com と入力します。また、*.contoso.com は www.contoso.com のようなサブドメインには一致しますが、ルートドメインの contoso.com には一致しません。両方を対象にする場合は、*.contoso.com,contoso.com のように両方を指定する必要があります。(Microsoft Learn)
複数の FQDN をカンマ区切りで入力する場合、カンマの後にスペースを入れない点も注意が必要です。さらに、URL フィルタリングのプレビューでは、テナントあたり最大 1,000 URL という制限が示されています。(Microsoft Learn)
| やりたいこと | 推奨される指定例 | 避けたい指定例 |
|---|---|---|
| ルートドメインを対象にする | contoso.com | https://contoso.com |
| サブドメインを対象にする | *.contoso.com | https://*.contoso.com/path |
| ルートとサブドメインを両方対象にする | *.contoso.com,contoso.com | *.contoso.com だけ |
| 複数ドメインを指定する | contoso.com,fabrikam.com,*.example.com | contoso.com, fabrikam.com |
条件の評価は OR と AND の組み合わせで考える
ポリシー評価では、同じ属性内では OR、異なる属性間では AND として評価されます。たとえば、ソース種別に Agent と Browser を選んだ場合は、どちらかに一致すれば条件を満たします。一方で、ソース種別に Agent、HTTP メソッドに DELETE を指定した場合は、Agent であり、かつ DELETE である場合にのみルールが適用されます。競合するアクションが複数一致した場合は、より制限の強い Block が優先されます。(Microsoft Learn)
この仕様を理解していないと、「許可ポリシーを作ったのにブロックされる」「特定ユーザーだけ例外にしたはずなのに反映されない」といったトラブルにつながります。許可例外を作る場合は、優先順位、セキュリティ プロファイル、条件付きアクセスの割り当て範囲をセットで確認してください。
ソース トラフィック種別はリモートネットワークでは使えない
ソース トラフィック種別フィルタリングは、Global Secure Access クライアントがタスクやプロセスメタデータを提供することで分類する仕組みです。そのため、リモートネットワーク トラフィックではソース トラフィック種別ルールはサポートされません。リモートネットワークには、ソース種別条件を含まない Web カテゴリ、URL、FQDN、HTTP メソッドのルールをベースライン プロファイル経由で適用できます。(Microsoft Learn)
グローバル拠点を持つ企業では、この違いが重要です。本社やリモートワーカーの端末にはクライアントベースの細かな制御を適用し、支社や工場などの拠点単位の通信にはベースライン プロファイルで大枠の制御を適用する、といった住み分けが現実的です。
HTTPS で HTTP メソッドを制御するなら TLS 検査が前提になる
HTTP メソッド要求フィルタリングは便利ですが、HTTPS 通信では TLS 検査を有効にしないとメソッドヘッダーを確認できません。TLS 検査が無効な環境では、SNI ベースの制御に限定されるため、「DELETE だけブロックする」「POST だけ制限する」といった意図は実現できない場合があります。(Microsoft Learn)
TLS 検査を導入する場合は、技術面だけでなく、プライバシー、法務、監査、例外サイト、証明書配布、業務アプリへの影響も確認が必要です。特に金融、医療、人事、個人メールなど、復号検査の対象にすべきでない通信がある組織では、導入前に例外設計を行ってください。
リモートネットワークとベースライン プロファイルの扱い
リモートネットワーク接続を使うと、個々のデバイスにクライアントを入れずに、支社や拠点の通信を Global Secure Access に接続できます。Web コンテンツ フィルタリングをリモートネットワーク トラフィックへ適用する場合は、ベースライン セキュリティ プロファイルを使います。ベースライン プロファイルは、Global Secure Access 経由でルーティングされるすべての Internet Access トラフィックに適用され、条件付きアクセス ポリシーの構成は不要です。(Microsoft Learn)
ここで誤解しやすいのは、通常のユーザー単位の条件付きアクセス連携と、リモートネットワーク向けのベースライン適用が同じではない点です。クライアント端末では条件付きアクセスによるユーザー・コンテキスト対応がしやすい一方、リモートネットワークでは拠点単位のキャッチオール制御としてベースライン プロファイルを使うイメージです。
| 適用対象 | 推奨される適用方法 | 使える主な条件 | 注意点 |
|---|---|---|---|
| 社員 PC、リモートワーカー端末 | Global Secure Access クライアント + 条件付きアクセス | ユーザー、グループ、セキュリティ プロファイル、ソース種別、HTTP メソッドなど | トークン更新や条件付きアクセス反映時間を考慮する |
| 支社、工場、店舗などの拠点 | リモートネットワーク + ベースライン プロファイル | Web カテゴリ、URL、FQDN、HTTP メソッドなど | ソース トラフィック種別はサポートされない |
| Explicit Forward Proxy 利用環境 | EFP 用の条件付きアクセス ポリシーを別途確認 | EFP の構成に依存 | All internet resources with Global Secure Access には EFP プレビューが含まれない |
Explicit Forward Proxy (EFP) プレビューは、公式ドキュメント上で「All internet resources with Global Secure Access」グループに現在含まれないと説明されています。EFP を利用している組織では、通常の条件付きアクセス構成だけで対象になると考えず、EFP 向けの条件付きアクセス ポリシーを別途確認する必要があります。(Microsoft Learn)
既存ポリシーへの影響と移行期限
今回、管理者が最も気にしやすいのは、Web Content Filtering Policy (V1) の「Deprecating soon」表示です。公式情報では、この赤いラベルは誤って表示されているものであり、既存の Web コンテンツ フィルタリング ポリシーは影響を受けず、構成どおりに動作し続け、現時点でアクションは不要と説明されています。(Microsoft Learn)
そのため、現時点で公式ドキュメントから読み取れる運用判断は次のとおりです。
| 項目 | 判断 |
|---|---|
| 既存ポリシーの即時削除 | 不要 |
| V1 ポリシーの緊急移行 | 公式情報上は不要 |
| 移行期限 | 対象ページでは明示されていない |
| 管理者が行うべきこと | 既存ポリシーの棚卸し、表示エラーの周知、ログ確認、今後の公式更新監視 |
ただし、「対応不要」は「何も確認しなくてよい」という意味ではありません。既存ポリシーが意図どおりに動作しているか、条件付きアクセスとの紐づけが適切か、例外許可が増えすぎていないか、退職者・委託先・部門変更により対象グループが古くなっていないかは、このタイミングで見直す価値があります。
反映時間と検証方法
Global Secure Access の設定変更は、種類によって反映時間が異なります。公式ドキュメントでは、Web コンテンツ フィルタリングに関連する Global Secure Access 側の構成変更は通常 5 分以内、条件付きアクセス側の構成変更は約 1 時間で有効になると説明されています。また、新しいセキュリティ プロファイルの適用は、アクセス トークンにセキュリティ プロファイル ID が含まれる必要があるため、最大 60〜90 分かかる場合があります。(Microsoft Learn)
| 変更内容 | 目安となる反映時間 | 検証時の注意 |
|---|---|---|
| Global Secure Access 側の Web フィルタリング設定 | 通常 5 分以内 | すぐに結果が変わらない場合もログで確認する |
| 条件付きアクセス設定 | 約 1 時間 | トークン更新の影響を受ける |
| 新しいセキュリティ プロファイル適用 | 最大 60〜90 分程度 | テストユーザーでセッション取り消しを使うと検証を早められる場合がある |
| 既存セキュリティ プロファイル内の変更 | 新規適用より早く反映される傾向 | ただし本番展開では余裕を持って確認する |
検証では、Global Secure Access クライアントが入った Windows デバイスで、対象ユーザーとしてサインインし、許可サイトとブロックサイトの両方を確認します。クライアントの Advanced Diagnostics で Forwarding profile を確認し、Internet Access の取得ルールが存在するか、閲覧時にホスト名やフローが取得されているかを確認します。さらに、Global Secure Access の Traffic logs で、対象トラフィックが Allow または Block として記録されているかを確認します。(Microsoft Learn)
ブロック時のユーザー体験にも注意が必要です。公式ドキュメントでは、現在のブロック体験として、HTTP トラフィックではプレーンテキストのブラウザーエラー、HTTPS トラフィックでは「Connection Reset」相当のエラーが発生すると説明されています。ユーザーからは「Web サイトが壊れている」「ネットワーク障害に見える」と報告される可能性があるため、ヘルプデスク向けに代表的な画面例と切り分け手順を共有しておくとよいでしょう。(Microsoft Learn)
グローバル企業での影響範囲
グローバル展開している企業では、地域、拠点、デバイス、業務部門によって影響が変わります。特に、各国の拠点が異なるプロキシや DNS 設定を使っている場合、同じポリシーでも通信取得のされ方が異なる可能性があります。
| 影響を受ける領域 | 想定される影響 | 管理者の確認ポイント |
|---|---|---|
| エンドユーザー端末 | Web アクセスが許可・ブロックされる | Global Secure Access クライアント、DNS、IPv4 優先、QUIC 対策 |
| 支社・拠点ネットワーク | 拠点単位でカテゴリ制限がかかる | リモートネットワーク、ベースライン プロファイル、CPE 側のバイパス設定 |
| AI エージェント利用部門 | Agent 種別のアクセスが制限される | AI ツールの業務要件、Unknown 扱い、ログ確認 |
| 開発・運用部門 | API や管理画面への HTTP メソッド制御が影響する | POST、PUT、PATCH、DELETE のブロック範囲、TLS 検査 |
| ヘルプデスク | Connection Reset などの問い合わせが増える可能性 | ブロック時の説明、ログ確認フロー、例外申請手順 |
| セキュリティ監査 | ポリシー適用範囲の説明が必要 | 命名規則、変更履歴、例外許可の承認記録 |
導入・見直し時の実務的な設計例
例1：全社共通の危険カテゴリをブロックする
最初に作るべきなのは、全社共通のベースラインです。マルウェア、不審サイト、ギャンブル、成人向けなど、業務上の必要性が低くリスクが高いカテゴリをブロックします。リモートネットワークも含めて適用したい場合は、ベースライン プロファイルへのリンクを検討します。
この設計では、ユーザーごとの差を作りすぎないことが重要です。例外が必要な場合も、個人単位ではなく、セキュリティ承認済みのグループ単位で管理すると運用負荷を抑えられます。
例2：AI エージェントの外部アクセスだけを制限する
AI エージェントを利用する部門では、ブラウザー閲覧は許可しつつ、Agent からのアクセスを制限する設計が有効です。たとえば、AI エージェントが SNS、個人向けストレージ、外部掲示板、ソースコード共有サイトにアクセスするのを制限することで、意図しないデータ送信や自動操作のリスクを下げられます。
ただし、ソース トラフィック種別は Unknown になる場合があります。Unknown を許可したままにすると抜け道になる可能性があるため、検証期間中はログで Unknown の発生状況を確認し、必要に応じて Unknown 向けのルールも検討してください。(Microsoft Learn)
例3：読み取りは許可し、変更操作をブロックする
管理画面、リポジトリ、社内外の SaaS に対して、GET は許可し、PUT、PATCH、DELETE をブロックする設計は、最小権限の考え方に合います。特に AI エージェントや自動化ツールが外部サービスにアクセスする場合、閲覧は許可しつつ変更系メソッドを制限することで、誤操作のリスクを下げられます。
ただし、Web アプリによっては POST を検索や画面遷移に使うことがあります。POST を一律にブロックすると、ログイン、検索、フォーム送信、管理画面操作が想定外に止まる場合があります。まずは Traffic logs を確認し、業務アプリの通信パターンを把握してから段階的に適用するのが安全です。
管理者が今すぐ確認すべきチェックリスト
| チェック項目 | 確認内容 |
|---|---|
| 公式更新日の記録 | Microsoft Learn 表示日と GitHub 更新履歴を分けて記録しているか |
| 既存 V1 ポリシー | 「Deprecating soon」表示を誤表示として扱い、不要な作り直しをしていないか |
| ポリシーの棚卸し | 使われていないポリシー、重複ポリシー、古い例外許可がないか |
| セキュリティ プロファイル | 部門別・拠点別・委託先別など、管理しやすい単位になっているか |
| 条件付きアクセス | 対象ユーザー、グループ、All internet resources with Global Secure Access、Session control を確認したか |
| FQDN 記法 | プロトコル、ポート、パスを入れていないか。ワイルドカードとルートドメインを両方指定しているか |
| TLS 検査 | HTTP メソッド制御に必要な TLS 検査の要否を判断したか |
| リモートネットワーク | ベースライン プロファイルで適用すべきポリシーを整理したか |
| EFP 利用環境 | Explicit Forward Proxy 用の条件付きアクセス構成を別途確認したか |
| ログ検証 | Traffic logs とクライアント診断で Allow/Block を確認したか |
| ヘルプデスク対応 | Connection Reset などの問い合わせに対する切り分け手順を用意したか |
失敗しやすいポイント
よくある失敗は、カテゴリブロックだけを作って満足してしまうことです。実際の運用では、条件付きアクセスで誰に適用するか、セキュリティ プロファイルの優先順位をどうするか、例外許可をどのポリシーで表現するかが重要になります。
もう1つの失敗は、検証直後に「効かない」と判断してしまうことです。条件付きアクセスや新しいセキュリティ プロファイルの反映には時間がかかる場合があります。検証時は、テストユーザー、対象グループ、トークン更新、ログ反映、クライアントの Forwarding profile を順番に確認してください。
また、グローバル展開では DNS over HTTPS、QUIC、IPv6、プロキシ、PAC ファイル、拠点 CPE のバイパス設定が影響します。公式の既知の制限では、Secure DNS の無効化、QUIC の非サポート、IPv6 トラフィックがクライアントに取得されないことなどが説明されています。これらを無視すると、ポリシーを作成しても一部の通信が期待どおりにトンネルされない可能性があります。(Microsoft Learn)
まとめ：移行ではなく、設計と検証を見直すタイミング
Microsoft Entra Global Secure Access Web コンテンツ フィルタリングの今回の確認ポイントは、既存ポリシーの緊急移行ではありません。重要なのは、Web カテゴリ、URL、FQDN、ソース トラフィック種別、HTTP メソッド、セキュリティ プロファイル、条件付きアクセスを組み合わせて、組織に合ったインターネットアクセス制御を設計できているかを見直すことです。
まずは既存ポリシーを棚卸しし、V1 の表示エラーに対する社内周知を行い、テストユーザーで条件付きアクセス連携とログ確認を実施してください。そのうえで、AI エージェント制御、リモートネットワークへのベースライン適用、HTTP メソッド制御、TLS 検査の要否を段階的に検討するのが安全です。グローバル環境では、地域ごとの DNS、プロキシ、クライアント、拠点ネットワークの違いも含めて、ポリシー設計と検証手順を標準化しておくことが、運用トラブルを減らす近道になります。
コメント