Microsoft Edge 147では、InPrivate モードでだけ特定サイトをブロックできる InPrivateModeUrlBlocklist が追加されました。2026年4月10日公開の Stable 147.0.3912.60 のリリースノートでは新規ポリシーとして案内されており、仕様ページでは Windows、macOS、Android、iOS の 147 以降がサポート対象です。つまり、InPrivateModeAvailability のように InPrivate を丸ごと禁止しなくても、「この業務サイトだけは InPrivate で開かせない」という制御ができるようになった、というのが今回の要点です。 (Microsoft Learn)
この変更は、社内ポータル、認証基盤、ファイル共有、業務SaaSのように、通常プロファイルでの利用を前提にしたサイトを運用している組織ほど効果が大きい更新です。ここでは、URLBlocklist や InPrivateModeUrlAllowlist との違い、設計の考え方、GPOでの見方、URLパターンで失敗しやすいポイントまで、Microsoft Edgeのポリシー管理という観点で実務向けに整理します。 (Microsoft Learn)
Edge 147で何が変わったのか
2026年4月10日付の Edge 147 リリースノートでは、InPrivateModeUrlAllowlist と InPrivateModeUrlBlocklist が新規ポリシーとして追加されています。ポリシー一覧のドキュメントでも、どちらも Microsoft Edge バージョン 147 の新規ポリシーとして掲載されています。これによって、InPrivate に対する制御が「使える・使えない」の二択から、「InPrivate ではこのURLを許可する／ブロックする」という細かい粒度に広がりました。 (Microsoft Learn)
InPrivateModeUrlBlocklist は InPrivate 専用です。通常ウィンドウまで止めたい場合は、従来どおり URLBlocklist を使います。また、InPrivateModeUrlBlocklist と InPrivateModeUrlAllowlist を同時に設定した場合は許可リストが優先され、どちらにも一致しない URL は一般の URLBlocklist / URLAllowlist の挙動に従います。ここを理解せずに設定すると、「ブロックしたはずなのに開ける」「InPrivate だけ止めたつもりが通常モードも止まった」という混乱が起きやすくなります。 (Microsoft Learn)
重要なのは、
InPrivateModeUrlBlocklistは「InPrivate だけに効く」ことです。通常モードまで止めたいなら、選ぶべきポリシーは別です。 (Microsoft Learn)
まずは既存ポリシーとの違いを整理する
目的別に使い分けると、設計で迷いにくくなります。 (Microsoft Learn)
| やりたいこと | 主に使うポリシー | 効く範囲 | 向いている場面 |
|---|---|---|---|
| InPrivateそのものを禁止したい | InPrivateModeAvailability | InPrivate 全体 | 共用端末、厳格な運用端末 |
| InPrivateで特定サイトだけ禁止したい | InPrivateModeUrlBlocklist | InPrivate のみ | 業務サイトだけ通常ウィンドウ必須にしたい |
| InPrivateで特定サイトだけ許可したい | InPrivateModeUrlAllowlist | InPrivate のみ | 例外運用を明確にしたい |
| 通常モードも含めて特定サイトを禁止したい | URLBlocklist | すべての閲覧モード | そもそもアクセス自体を止めたい |
「業務サイトは通常ウィンドウ必須だが、InPrivate は全面禁止したくない」という要件なら、今回追加された InPrivateModeUrlBlocklist が最も自然です。逆に、「InPrivate を使わせる理由がない」なら InPrivateModeAvailability のほうが設定も説明も簡単です。URLBlocklist は強力ですが、通常モードまで止めるので、今回の用途では効きすぎることがあります。 (Microsoft Learn)
InPrivateModeUrlBlocklist が向いている利用シーン
このポリシーが刺さるのは、InPrivate そのものが問題なのではなく、特定サイトだけ通常プロファイル前提で使わせたいケースです。
たとえば、次のような場面では使い勝手が良いです。
- 社内ポータルや申請システムを、通常ウィンドウのブックマークや既存セッション前提で使わせたい
- 共有PCで、一般的なWeb閲覧は許可しつつ、重要な業務SaaSだけは InPrivate 利用を避けたい
- InPrivate の全面禁止は現場の反発が大きいが、少数の業務サイトだけは運用上ルールを徹底したい
特に実務では、「すべてを禁止する」よりも「困るサイトだけ絞って制御する」ほうが定着しやすいことがあります。今回の追加は、そのためのちょうどよい中間手段です。
設定前に決めるべきこと
ドメイン単位で止めるのか、ホストやパスまで絞るのか
Edge の URL リスト系ポリシーは、単純な完全一致ではありません。フィルター形式は [scheme://][.]host[:port][/path][@query] で、先頭にドットを付けない contoso.com は contoso.com だけでなくサブドメインにも一致します。一方で .www.contoso.com のようにドットを付けると、そのホスト名にだけ正確一致します。 (Microsoft Learn)
この違いを知らないまま contoso.com を入れると、www.contoso.com や sub.contoso.com まで巻き込むことがあります。逆に、正確に1ホストだけ止めたいのにドットを付け忘れると、想定以上に広くブロックしてしまいます。最初に「ドメイン全体」「特定ホスト」「特定パス」のどこまで狙うのかを決めてから登録するのが安全です。 (Microsoft Learn)
例外が必要なら、Allowlist の優先順位を先に理解する
InPrivateModeUrlBlocklist と InPrivateModeUrlAllowlist を併用した場合、許可リストが優先されます。つまり、ブロック対象に見えても allowlist に一致していれば開けます。 (Microsoft Learn)
さらに見落としやすいのが、InPrivateModeUrlAllowlist を単独で設定したときの挙動です。この場合、InPrivate で開けるのは allowlist に載せた URL だけになり、それ以外はブロックされます。「一部だけ例外許可のつもり」で単独投入すると、想定以上に強い制御になるので要注意です。 (Microsoft Learn)
バージョンと適用条件を確認する
InPrivateModeUrlBlocklist は Windows、macOS、Android、iOS で 147 以降がサポート対象です。必須ポリシーとして設定でき、推奨設定には対応していません。動的ポリシー更新とプロファイル単位の適用には対応しています。 (Microsoft Learn)
あわせて確認したいのが、仕様ページで「Microsoft アカウントでサインインしたプロファイルには適用されない」とされている点です。個人アカウント混在の端末では、管理対象プロファイルだけでなく、実際に利用されるプロファイルの形まで見たうえでテストしたほうが安全です。 (Microsoft Learn)
GPOで設定するときの実務ポイント
Windows のグループポリシーでは、InPrivateModeUrlBlocklist の GPO 名は Block access to a list of URLs in InPrivate mode、配置場所は Administrative Templates/Microsoft Edge、ADMX は MSEdge.admx です。データ型は文字列リストで、レジストリでは SOFTWARE\Policies\Microsoft\Edge\InPrivateModeUrlBlocklist 配下に 1、2、3 のような名前で REG_SZ を並べる構成になります。 (Microsoft Learn)
実務では、次の順で進めると失敗しにくくなります。
- Edge クライアントが 147 以降か確認する
- 使用中の
MSEdge.admxが新ポリシーを含む世代か確認する - まずは 3〜10 件ほどの URL だけで小さく試す
- 通常ウィンドウでは開けること、InPrivate では止まることを両方確認する
- 例外が必要なら
InPrivateModeUrlAllowlistを別途整理する
GPO 項目が見つからないときは、端末の Edge バージョンだけではなく、管理サーバー側の ADMX 世代が古いケースを疑うと切り分けが早くなります。ポリシーそのものは 147 で追加されているため、古いテンプレートでは当然表示されません。 (Microsoft Learn)
URLパターンの書き方で失敗しやすいポイント
URLパターンは、思っているより一致範囲が広かったり狭かったりします。以下の感覚を持っておくと、テストのやり直しがかなり減ります。 (Microsoft Learn)
| パターン例 | 一致の考え方 | 実務上の注意 |
|---|---|---|
contoso.com | contoso.com とそのサブドメインに一致 | 1ホストだけ止めたい用途には広すぎることがある |
.www.contoso.com | www.contoso.com のみ正確一致 | ピンポイントで止めたいとき向き |
https://server:8080/path | スキーム、ポート、パスまで含めて絞れる | http と https は別物として扱う |
* | すべてのホストに一致 | かなり強い指定なので、通常は検証用以外では慎重に使う |
さらに、スキームとホストは大文字小文字を区別しませんが、path と query は区別します。また、最も具体的なフィルターが優先され、同程度で競合した場合は allowlist が blocklist より優先されます。「一部だけ通る」「似たURLなのに効き方が違う」というときは、まずこのルールを疑うのが近道です。 (Microsoft Learn)
導入時の注意点
運用で特に詰まりやすい点は、次の4つです。
- エントリ数は最大 1000 件です。 大量登録に走る前に、ドメイン単位に寄せられないかを見直したほうが運用しやすくなります。 (Microsoft Learn)
- allowlist が常に優先されます。 過去の例外設定が残っていると、blocklist を追加しても対象URLが開けることがあります。 (Microsoft Learn)
- InPrivate リストに一致しない URL でも、一般の
URLBlocklist/URLAllowlistが最終挙動に影響します。 InPrivate 専用設定だけを見ても原因が分からないケースがあります。 (Microsoft Learn) - 個人の Microsoft アカウント利用が残る端末は事前検証が必須です。 仕様上、このポリシーは Microsoft アカウントでサインインしたプロファイルには適用されないとされています。 (Microsoft Learn)
まず何から始めるべきか
Edge 147 の InPrivateModeUrlBlocklist は、InPrivate を全面禁止せずに、必要なサイトだけ通常ウィンドウへ戻したい組織に向いた追加です。設計を成功させるコツは、最初から大量登録しないことです。4月10日公開の Edge 147 で追加された新ポリシーという位置づけを踏まえると、まずは少数サイトで挙動と例外設計を固めるのが現実的です。 (Microsoft Learn)
最初の一歩としては、「InPrivate で開かせたくない URL」を 3〜10 件洗い出す → exact host かサブドメイン込みかを決める → 既存 allowlist と一般の URLBlocklist を確認する → 小規模展開で検証する、の順で進めてください。これだけで、「ポリシーは入ったのに効き方が読めない」という典型的な失敗はかなり減らせます。
コメント