Microsoft Edgeのローカルネットワーク制限で社内Webシステムやローカル機器との通信に問題が出ている場合、当面は一時回避ポリシーを継続利用できます。LocalNetworkAccessRestrictionsTemporaryOptOutの削除予定が、Microsoft Edge 152より後からEdge 156より後へ延期されたためです。Edge 152へ更新しても、このポリシーが直ちに使えなくなるわけではありません。(Microsoft Learn)
ただし、延期されたのは一時回避ポリシーの削除時期であり、Local Network Access、以下LNAと表記、の制限そのものではありません。Microsoftは、許可するサイトを限定するポリシーやWebアプリ側の対応へ移行する方針を維持しています。
Edge 156 Stableの提供予定は2026年10月22日の週、次のEdge 157は11月5日の週です。日程は変更される可能性がありますが、最速ケースを考えるなら、2026年10月までにTemporaryOptOutへの依存を解消するのが安全です。(Microsoft Learn)
EdgeのLocalNetworkAccessRestrictions一時回避策、削除は156より後へ延期
Microsoft Edge 152のStableリリースノートでは、LocalNetworkAccessRestrictionsTemporaryOptOutの削除予定が次のように変更されました。
| 項目 | 従来の予定 | 更新後の予定 |
|---|---|---|
| 一時回避ポリシーの削除 | Edge 152より後 | Edge 156より後 |
| Edge 152更新時の扱い | 使用できなくなる可能性があった | 現在の計画では継続利用可能 |
| 管理者が取るべき対応 | 緊急移行 | 猶予期間内に段階的に移行 |
| 恒久対応の必要性 | あり | 変更なし |
重要なのは、Microsoftの表現が「Edge 156で削除」ではなく、Edge 156より後に削除予定となっている点です。
そのため、現時点では次のように判断します。
- Edge 156までは削除対象ではない
- Edge 157で必ず削除されるとは確定していない
- Edge 157以降は、いつ削除されても対応できる状態にしておく
- 延期を恒久サポートと解釈しない
なお、Microsoftはリリースノートで削除予定の変更を公表していますが、延期理由までは説明していません。互換性問題が理由だと断定することは避けるべきです。(Microsoft Learn)
Microsoft Learn内の旧記載に注意
2026年8月30日時点では、MicrosoftのLNA移行ガイドの一部に「Edge 152より後に削除」という旧情報が残っています。一方、現在のStableリリースノートと個別ポリシーのリファレンスは「Edge 156より後」に更新されています。(Microsoft Learn)
運用判断では、次の順序で情報を確認すると混乱を避けられます。
- 最新のStableリリースノート
LocalNetworkAccessRestrictionsTemporaryOptOutの個別ポリシーリファレンス- LNA全体の移行ガイド
古い手順書や社内資料に「Edge 152で削除」と記載している場合は、日付と根拠を添えて更新しておきましょう。
LocalNetworkAccessRestrictionsTemporaryOptOutとは
LNAは、インターネット上のWebサイトが、利用者のPCや社内ネットワーク上にある機器へ無断でリクエストを送ることを防ぐ仕組みです。
たとえば、次のような通信が対象になり得ます。
- クラウド型の管理画面から社内プリンターへアクセスする
- Webアプリから
localhostで動作する連携エージェントを呼び出す - 公開Webサイトから
192.168.x.xなどのプライベートIPアドレスへ通信する - Webページ内の別ドメインのiframeから社内サーバーへアクセスする
- VPNやプロキシ利用時に、公開ホストがローカル用アドレスとして判定される
Microsoft Edgeでは、Edge 143 StableからLNAが既定で有効になりました。アクセスが必要な場合、ユーザーの許可を求めたり、Webアプリ側にPermissions Policyの設定を要求したりします。(Microsoft Learn)
LocalNetworkAccessRestrictionsTemporaryOptOutを有効にすると、LNAチェックに失敗してもリクエストを制限せず、Edgeの開発者ツールに警告を表示する動作になります。無効または未構成の場合は、通常のLNA制限が適用されます。(Microsoft Learn)
ポリシーの主な仕様
| 項目 | 内容 |
|---|---|
| ポリシー名 | LocalNetworkAccessRestrictionsTemporaryOptOut |
| データ型 | Boolean |
| 有効時 | LNA制限を一時的に回避し、失敗したチェックをDevToolsの警告にする |
| 無効・未構成時 | Edgeの既定のLNA動作を適用 |
| Windows | Edge 143以降 |
| macOS | Edge 143以降 |
| Android | Edge 144以降 |
| iOS | 非対応 |
| 動的なポリシー更新 | 対応 |
| 推奨ポリシーとしての設定 | 非対応 |
| 削除予定 | Edge 156より後 |
このポリシーは、特定のサイトだけを許可するものではありません。LNA制限全体から一時的にオプトアウトするため、影響範囲が広い回避策です。
また、無効になるのはLNAの制限であり、CORS、Webアプリの認証、プロキシ、ファイアウォール、ネットワークACLなどが解除されるわけではありません。TemporaryOptOutを有効にしても通信できない場合は、LNA以外の原因も調査する必要があります。(Microsoft Learn)
今回の延期で影響を受ける組織
すでにTemporaryOptOutを有効にしている組織
Edge 152へ更新しても、現時点では設定を継続できます。社内システムが止まることを避けるために有効化していた場合、Edge 152への更新だけを理由にポリシーを削除する必要はありません。
ただし、次の対応は進める必要があります。
- TemporaryOptOutを必要としているサイトを特定する
- 通信先がlocalhost、プライベートIP、CGNのどれかを確認する
- iframeを使っているか確認する
- URL単位の許可ポリシーへ置き換える
- Webアプリの改修可否をベンダーへ確認する
TemporaryOptOutを設定していない組織
今回の延期によって、LNAの既定動作が無効になるわけではありません。TemporaryOptOutが未構成なら、従来どおりLNA制限や許可プロンプトが適用されます。
つまり、今回の発表は「Edge 156までLNA制限が始まらない」という意味ではありません。
Webシステムを開発・提供している事業者
ローカル機器との通信をTemporaryOptOutに依存している場合、削除時期の延期は改修期間が延びたことを意味します。
特に次の仕組みを使う製品は確認が必要です。
- ローカル印刷用エージェント
- ICカードやバーコードリーダーとのブラウザー連携
- 電子署名用のlocalhostアプリ
- NASやプリンターの管理ツール
- 端末内のWebSocket・HTTPサービス
- 別ドメインのiframeを利用する業務システム
製品提供者が対応しなければ、利用企業側でTemporaryOptOutを解除できない状態が続きます。ベンダーには「LNA対応済みか」だけでなく、iframeのPermissions Policyにも対応しているかを確認しましょう。
TemporaryOptOutの設定状況を確認する方法
Edgeのポリシー画面で確認する
対象端末のMicrosoft Edgeで、次の内部ページを開きます。
edge://policyページ内でLocalNetworkAccessRestrictionsTemporaryOptOutを検索し、次の項目を確認します。
- ポリシーが表示されているか
- 値が
trueまたは1になっているか - ポリシーの適用元
- ユーザー単位かデバイス単位か
- エラーや競合が表示されていないか
現在のEdgeバージョンは、次のページで確認できます。
edge://versionグループポリシーを変更した直後に反映されない場合は、対象端末で次のコマンドを実行し、Edgeを再起動します。
gpupdate /forceMicrosoftは、適用済みのEdgeポリシーをedge://policyで確認する方法を案内しています。(Microsoft Learn)
ポリシーが表示されない場合
グループポリシーエディターに設定項目が見つからない場合、Microsoft EdgeのADMXテンプレートが古い可能性があります。
最新のポリシーテンプレートに含まれる次のファイルを、中央ストアまたはローカルのPolicyDefinitionsフォルダーへ配置します。
msedge.admx- 使用言語に対応した
msedge.adml
ADMXとADMLのバージョンが一致していないと、グループポリシーエディターでエラーが発生することがあります。両方を同じテンプレート一式から更新してください。(Microsoft Learn)
グループポリシーで一時回避策を設定する手順
TemporaryOptOutを緊急回避策として維持する場合は、次の場所で設定します。
コンピューターの構成
または
ユーザーの構成
└ 管理用テンプレート
└ Microsoft Edge
└ ネットワークの設定
└ Specifies whether to opt out of Local Network Access restrictions設定を「有効」にします。
このポリシーは推奨設定ではなく、必須ポリシーとして提供されています。そのため、「Microsoft Edge – 既定の設定」側ではなく、通常のMicrosoft Edgeポリシー側で構成します。(Microsoft Learn)
適用対象は必要な端末や利用者に限定する
TemporaryOptOutを全社一律で設定すると、LNAの許可確認が組織全体で回避されます。
可能であれば、次の単位に分けて適用してください。
- 問題が発生する業務システムの利用者
- ローカル機器を使用する部門
- 検証用のパイロット端末
- 対象システム専用端末
- ベンダー改修待ちの利用グループ
適用対象を限定できない場合でも、対象システム、利用部門、設定理由、解除予定日を台帳に残しておくことが重要です。
レジストリで設定する方法
Windowsのレジストリ設定は次のとおりです。
| 項目 | 値 |
|---|---|
| パス | SOFTWARE\Policies\Microsoft\Edge |
| 値の名前 | LocalNetworkAccessRestrictionsTemporaryOptOut |
| 種類 | REG_DWORD |
| 有効 | 1 |
端末全体に設定する場合は、管理者権限のコマンドプロンプトまたはPowerShellで次を実行します。
reg.exe add "HKLM\SOFTWARE\Policies\Microsoft\Edge" `
/v LocalNetworkAccessRestrictionsTemporaryOptOut `
/t REG_DWORD `
/d 1 `
/f一時回避設定への依存を解消した後は、値を削除します。
reg.exe delete "HKLM\SOFTWARE\Policies\Microsoft\Edge" `
/v LocalNetworkAccessRestrictionsTemporaryOptOut `
/fユーザー単位で設定する場合はHKLMではなくHKCUを使用できます。ただし、Active DirectoryやIntuneで管理している環境では、端末上で直接レジストリを変更しても管理ポリシーによって上書きされます。
直接編集は検証や緊急対応に限定し、本番環境ではグループポリシーまたはMDMを設定元にするのが安全です。
Intuneで設定する方法
Microsoft Intuneでは、Settings CatalogからMicrosoft Edgeのポリシーを構成できます。
- Intune管理センターを開く
- ［デバイス］から［構成］を開く
- Windows 10以降を対象にSettings Catalogプロファイルを作成する
- 設定ピッカーで
LocalNetworkAccessRestrictionsTemporaryOptOutを検索する - 設定を有効にする
- まず検証用グループへ割り当てる
- 対象端末の
edge://policyで反映を確認する
Intuneの画面構成や日本語表記は更新されることがあります。設定名で見つからない場合は、英語のポリシー名をそのまま検索してください。MicrosoftはSettings Catalogで対象のEdge設定を検索し、ユーザーまたはデバイスグループへ割り当てる手順を案内しています。(Microsoft Learn)
恒久的なLocal Network Accessモデルへの移行方法
TemporaryOptOutを解除するには、すべての環境に同じ設定を適用するのではなく、問題の原因ごとに対応を分ける必要があります。
| 状況 | 推奨する恒久対応 | 注意点 |
|---|---|---|
| 特定の信頼済みWebサイトがローカル機器へアクセスする | LocalNetworkAccessAllowedForUrls | 許可する起点サイトを限定する |
| iframe内からローカル通信する | iframeにallow="local-network-access"を追加 | 埋め込み元とiframe側の両方を確認する |
| iframeを改修できない | LocalNetworkAccessPermissionsPolicyDefaultEnabledとURL許可を組み合わせる | 適用範囲が広がるため限定配布する |
| VPNやプロキシでCGNアドレスがローカル扱いになる | LocalNetworkAccessIpAddressSpaceOverrides | ネットワーク設計を確認してから設定する |
| HTTPで提供しているWebアプリ | HTTPSへ移行する | LNAの許可要求には安全なコンテキストが必要 |
| 特定サイトのローカルアクセスを禁止したい | LocalNetworkAccessBlockedForUrls | 許可ポリシーとの競合を確認する |
| 原因をすぐ修正できない | TemporaryOptOutを限定的に継続 | 解除期限を設定する |
特定サイトだけを許可する
恒久対応の中心になるのがLocalNetworkAccessAllowedForUrlsです。このポリシーでは、LNAチェックから除外する起点サイトのURLパターンを指定できます。WindowsとmacOSではEdge 140以降、AndroidではEdge 144以降が対象です。(Microsoft Learn)
たとえば、次のような構成を考えます。
起点となるクラウドサービス:
https://print.example.com
アクセス先:
http://192.168.10.50許可ポリシーに登録するのは、原則としてリクエストを開始する側のhttps://print.example.comです。プリンターのIPアドレスだけを登録しても、想定どおりに動作しない可能性があります。
ポリシーはワイルドカード*も受け付けますが、すべてのサイトを許可するとTemporaryOptOutに近い広い例外になります。可能な限り、スキーム、ホスト名、ポートを限定してください。
iframeはWebアプリ側の対応が必要
LNA通信が別ドメインのiframe内で行われる場合、URLの許可ポリシーを設定しただけでは解決しないことがあります。
Webアプリを改修できる場合は、iframeへ次のようなPermissions Policyを追加します。
<iframe
src="https://device-service.example"
allow="local-network-access">
</iframe>iframeが別のオリジンへ移動する場合は、通信を行う可能性があるオリジンも含めて設計する必要があります。また、入れ子になったiframeでは、途中のiframeにも許可の委任が必要です。(Microsoft Learn)
iframeを改修できない場合
ベンダー製システムなどでiframeのHTMLを変更できない場合は、次の組み合わせを検討します。
LocalNetworkAccessAllowedForUrlsLocalNetworkAccessPermissionsPolicyDefaultEnabled
LocalNetworkAccessPermissionsPolicyDefaultEnabledを有効にすると、クロスオリジンのサブフレームがLNAのPermissions Policyを既定で継承できるようになります。通常は明示的な委任が必要なため、このポリシーを使う場合は対象ユーザーや端末を限定してテストしてください。(Microsoft Learn)
CGNアドレスの誤判定を修正する
VPNやプロキシ環境では、公開サービスの名前解決結果がCarrier-Grade NATのアドレス範囲100.64.0.0/10になることがあります。Edgeがこの範囲をローカルネットワークとして扱うことで、意図しないLNA制限が発生するケースがあります。(Microsoft Learn)
ネットワーク構成上、その範囲を公開アドレスとして扱って問題ないことを確認できた場合は、LocalNetworkAccessIpAddressSpaceOverridesで次のように再分類できます。
100.64.0.0/10=publicこのポリシーはCIDR単位やIPアドレスとポートの組み合わせで、アドレス空間をpublic、local、loopbackとして上書きできます。(Microsoft Learn)
ただし、組織内で実際に100.64.0.0/10をローカル用途に使っている場合、一律にpublicへ変更すると意図しない通信を許可するおそれがあります。VPN、プロキシ、DNS、ルーティングの担当者と確認してから設定してください。
Edge 156までの移行スケジュール例
Edge 152以降、Stableチャネルの主要バージョンは原則として2週間ごとに更新されます。削除期限が4バージョン延びても、長期の猶予ではありません。(Microsoft Learn)
Microsoftの予定を基にすると、次のように進めるのが現実的です。
| Edgeバージョン | Stable提供予定 | 管理者の目標 |
|---|---|---|
| 152 | 2026年8月27日 | TemporaryOptOutの利用状況を確認 |
| 153 | 2026年9月10日の週 | 対象サイト、通信先、iframeの有無を棚卸し |
| 154 | 2026年9月24日の週 | URL単位の許可ポリシーをパイロット展開 |
| 155 | 2026年10月8日の週 | TemporaryOptOutを無効にした業務テストを完了 |
| 156 | 2026年10月22日の週 | 本番環境でTemporaryOptOutへの依存を解消 |
| 157 | 2026年11月5日の週 | ポリシー削除や動作変更がないか監視 |
リリース日はビルド状況により変わる可能性があります。日付だけで管理するのではなく、Edge 154、155、156といったバージョンを移行マイルストーンにしてください。
実務で使える移行テスト手順
影響する通信を棚卸しする
対象システムごとに、最低限次の情報を記録します。
| 確認項目 | 記録例 |
|---|---|
| 起点サイト | https://portal.example.com |
| 通信先 | http://192.168.1.50 |
| 通信先の種類 | localhost、プライベートIP、CGN |
| 通信方法 | fetch、iframe、サブリソース |
| iframe | あり・なし |
| 利用部門 | 総務部、窓口端末 |
| TemporaryOptOutなしでの結果 | 許可プロンプト、ブロック、正常 |
| 恒久対策 | URL許可、HTML改修、IP空間上書き |
| ベンダー対応状況 | 対応済み、改修予定、未回答 |
「どのシステムが使えないか」だけではなく、どの公開オリジンから、どのローカルアドレスへ通信しているかまで把握することが重要です。
パイロット端末でTemporaryOptOutを外す
本番全体から一度に削除せず、検証グループで次の順序を試します。
- TemporaryOptOutを有効にした状態で正常動作を確認する
LocalNetworkAccessAllowedForUrlsなどの恒久設定を追加する- パイロット端末だけTemporaryOptOutを未構成にする
- Edgeを再起動する
- 許可プロンプト、DevTools、業務機能を確認する
- VPN接続時と社内LAN接続時の両方をテストする
- 問題がなければ対象グループを段階的に広げる
Microsoftも、部門ごとに異なるWebアプリを使う代表ユーザーでテストし、結果に応じてポリシーを調整する方法を案内しています。(Microsoft Learn)
よくある失敗と対処法
「削除延期＝LNA制限の延期」と誤解する
延期されたのはTemporaryOptOutポリシーの削除です。LNAはEdge 143から既定で有効であり、TemporaryOptOutを設定していない端末には通常のLNA動作が適用されます。
古いLocalNetworkAccessRestrictionsEnabledを設定する
LocalNetworkAccessRestrictionsEnabledは旧ポリシーで、Edge 144より後では機能しません。名前が似ていますが、今回削除延期されたLocalNetworkAccessRestrictionsTemporaryOptOutとは別のポリシーです。(Microsoft Learn)
既存のGPOやスクリプトに旧ポリシーが残っている場合は、設定を整理してください。
AllowedForUrlsを設定してもiframeが動かない
LocalNetworkAccessAllowedForUrlsは、iframeに必要なPermissions Policyを自動的に追加するものではありません。
許可リストを設定しても動かない場合は、次を確認します。
- 通信がiframe内で実行されていないか
- iframeに
allow="local-network-access"があるか - iframeが別オリジンへリダイレクトしていないか
- 入れ子のiframeすべてで許可が委任されているか
LocalNetworkAccessPermissionsPolicyDefaultEnabledが必要か
Microsoftのガイドでも、許可ポリシーを正しく設定しているのに動作しない場合、iframeの修正が必要な可能性が高いと説明されています。(Microsoft Learn)
許可リストに通信先IPを登録する
LocalNetworkAccessAllowedForUrlsは、基本的にリクエストを開始するWebサイトのオリジンを照合します。
たとえば、クラウドサービスがプリンターへ通信している場合、登録すべきなのはプリンターのIPだけではなく、クラウドサービス側の起点オリジンです。
ワイルドカードですべて許可する
*を設定すれば動作確認は容易ですが、すべての起点サイトを対象にする広い例外になります。
まず完全一致に近いURLパターンで検証し、必要な場合のみサブドメイン単位へ広げてください。
TemporaryOptOutを解除する日を決めていない
延長されたことで、設定がそのまま放置される可能性があります。
ポリシー台帳には少なくとも次を記録します。
- 設定理由
- 対象システム
- 適用ユーザーまたは端末
- システム管理者
- ベンダー担当者
- 恒久対応の内容
- 次回確認日
- 解除期限
解除期限は「Microsoftが正式な削除日を発表した日」ではなく、Edge 156の展開前に設定するのが安全です。
LNA関連の不具合を切り分けるポイント
| 症状 | 考えられる原因 | 次に確認すること |
|---|---|---|
| ユーザーにローカルネットワークの許可が表示される | LNAの通常動作 | 許可後に機能するか |
| 許可しても機能しない | iframeの委任不足 | iframeのallow属性 |
| TemporaryOptOutなら動く | LNA設定が原因 | URL許可やiframe対応へ置換 |
| URL許可を入れても動かない | 起点URLの指定ミス、iframe | edge://policyとDevTools |
| VPN接続時だけ失敗する | CGNや名前解決の変化 | 解決後IPとルーティング |
| HTTPページで失敗する | 安全なコンテキストではない | HTTPS化 |
| 設定項目がGPOにない | ADMXが古い | 最新テンプレートへ更新 |
| ポリシーが反映されない | 適用範囲、競合、管理元 | edge://policyのソースとエラー |
ユーザーが許可または拒否した状態は、次のEdge設定画面でも確認できます。
edge://settings/privacy/sitePermissions/allPermissions/localNetworkAccessただし、組織ポリシーで許可または禁止されている場合、ユーザー操作だけでは変更できないことがあります。
まとめ：延期期間は回避策の維持ではなく依存解消に使う
LocalNetworkAccessRestrictionsTemporaryOptOutは、Edge 152で削除されず、Edge 156より後まで利用できる計画に変更されました。Edge 152への更新直後に社内システムが停止するリスクは下がりましたが、ポリシーが恒久化されたわけではありません。
管理者が今すぐ行うべきことは、次の3点です。
edge://policyでTemporaryOptOutの利用状況を確認する- 対象サイトを
LocalNetworkAccessAllowedForUrlsなどの限定的な設定へ移行する - Edge 156の展開前に、TemporaryOptOutを外した状態で業務テストを完了する
特に、URL許可だけでは解決しないiframe、VPNやプロキシで発生するCGN判定、HTTPで提供されている旧式Webアプリを優先的に確認してください。最終的な目標は、TemporaryOptOutを残すことではなく、LNAの許可モデルに対応した状態でTemporaryOptOutを削除できることです。
コメント