Intune設定カタログによるEdge/ChromeブラウザのURLBlocklist一括配信と除外設定

社内セキュリティポリシーに基づき、特定のSNSや業務に関係のないサイトへのアクセスをブラウザレベルで禁止。一方で、一部の部門のみ特定のSNSへのアクセスを許可するような柔軟な運用が求められます。

原因と落とし穴

レジストリを直接叩く運用では反映状況の把握が難しく、EdgeとChromeで別々に設定を配信するとメンテナンス性が低下します。また、Blocklistだけで運用すると「全面禁止」か「全面許可」の二択になりがちです。

切り分け・対処手順

設定カタログの作成: Intuneの構成プロファイル(設定カタログ)から「Microsoft Edge」および「Google Chrome」を選択し、URLBlocklistに拒否URL(例: facebook.com)を追加します。

URLAllowlistによる例外: URLAllowlistに許可したい特定のパスや部門専用のURLを記述し、拒否設定を上書きします。

デバイスへの割り当て: 全社用と特定部門用のプロファイルをフィルター機能やグループ分けで使い分け、正しくポリシーが適用されているかブラウザのアドレスバーに edge://policy 等を入力して確認します。

まとめ

設定カタログを活用したURLフィルタリングは、管理工数を抑えつつ、業務実態に即した細やかなWeb利用制御を可能にします。

付録: URLBlocklist / URLAllowlist のパターン早見表

（2026-10-01 追記）Microsoft Learn「Filter formats for Microsoft Edge policies」の内容を、よく使う形に絞ってまとめました。Chromeも同じ書式です。書式は [スキーム://][.]ホスト[:ポート][/パス][@クエリ] です。

どちらが勝つか（判定の順番）

①ホストがいちばん長く一致するものを選ぶ → ②スキームやポートが合わないものを外す → ③パスがいちばん長く一致するものを選ぶ → ④クエリの条件が多いものを選ぶ。ここでパスの長さとクエリの数が同じなら、許可リストが勝つ → ⑤何も残らなければ、ホストの左端を1つ削ってやり直す。最後まで一致しなければ「許可」になる。

つまり「許可リストが優先」なのは、同じ具体性で並んだときだけです。たとえば次のようになります。

・ブロック example.com、許可 example.com/business → /business 配下だけ開ける（許可の方がパスが長い）
・ブロック www.example.com、許可 example.com → www.example.com は開けない（ブロックの方がホストが長く一致する）

間違えやすい点

・ホストとスキームは大文字小文字を区別しない。パスとクエリは区別する（/Path と /path は別物）
・「#」より後ろは無視される
・URLAllowlist は1000件まで。それより後ろは無視される
・Cookieの許可・ブロックなど一部のポリシーは [*.]contoso.com という別の書式を使う。同じ感覚で書くと効かない

出典: Microsoft Learn「Filter formats for Microsoft Edge policies」（2025-10-03更新）、「URLAllowlist」（2026-05-20更新）

■ 取引先からセキュリティ対策を問われたときに

SCS評価制度（★3・★4）の評価基準に沿って、自社の対策状況を無料で自己点検できます（非公式）。
▶ SCS評価制度の自己点検（無料）

■ この記事に関連するテンプレート

どのURLを全社で禁止し、どの部門に例外を認めたかは、決めた理由と一緒に残しておかないと、後から見直せなくなります。セキュリティ設定の方針と例外を整理して管理するためのNotionテンプレートを作りました。
まずは無料版で、使い方が合うかを確かめてみてください。

▶ 無料版（情シス向けNotionテンプレート3種）を見る
▶ 中小企業向けセキュリティベースライン設計キット（¥2,980）