次の方法で共有

Microsoft Edge での新しいローカル ネットワーク アクセス制限に Web サイトを適応させる

最終更新日: 2025 年 10 月 1 日

ローカル ネットワーク アクセス制限は、Microsoft Edge 143 で既定で出荷を開始します。 ローカル ネットワーク アクセスとは何か、およびローカル ネットワーク要求を行う際にユーザーのアクセス許可を要求する動機の詳細については、「 ローカル ネットワーク アクセスの仕様」を参照してください。

localhost を実行しているサーバーまたはユーザーのローカル ネットワーク上のどこか (サード パーティのライブラリを介して) に接続する必要がある Web サイトがある場合、このドキュメントでは、一般的な質問に回答し、これらの新しい制限に対応するように Web サイトを適応させる方法に関するガイダンスを提供します。

多くの場合、ローカル ネットワーク要求は以前と同じように機能し続ける必要がありますが、ユーザーには、サイトで初めて発生した場合にアクセス許可のプロンプトが表示されます。 場合によっては、これらの要求が機能し続けるためにサイトを調整する必要があります (混合コンテンツとしてブロックされません)。 たとえば、ローカル ネットワーク アドレスに解決されるパブリック ドメイン名に対して fetch() 要求を行う場合は、fetch() 呼び出しにローカル アドレスへの移動として明示的にタグを付ける必要があります。 また、コンテンツのブロックが混在しているために (HTTPS ではなく) HTTP で Web サイトをホストする必要がある場合は、サイトを LNA アクセス許可を要求するための HTTPS 要件からサイトを一時的に除外するために 、Origin Trial にサインアップする必要があります。

Microsoft Edge の LNA 制限の現在のスコープは何ですか?

アクセス許可プロンプトは、ローカル ネットワークまたは localhost 上の宛先への接続が行われたときにトリガーされます。 Microsoft Edge 143 以降では、LNA の制限が適用されます。

  • サブリソース要求
  • fetch() 要求
  • サブフレームの移動

LNA の制限は、最初は次の接続の種類には適用されませんが、近日中に含める予定です。

  • WebSocket
  • WebTransport
  • WebRTC

現在、メイン フレーム ナビゲーションに LNA 制限を適用する計画はありません。 (Edge 139 以前のドラフト実装のバグが、メイン フレーム ナビゲーションに誤って影響を与えました)。

現時点では、拡張機能に LNA 制限を適用する予定はありません。 現在、必要な ホストアクセス許可 を持つ拡張機能は、ローカル ネットワーク要求を行うことができます。

LNA 制限は Android WebView には適用されません。 ローカル ネットワーク要求を行う WebView を埋め込む Android アプリは、代わりに Android の新しい ローカル ネットワークアクセス許可の対象になります。

LNA アクセス許可プロンプトの追加コンテキストをユーザーに提供するにはどうすればよいですか?

アクセス許可を要求する場合は、アクセス許可が必要な理由と使用する目的のために、Web アプリでユーザーに追加のコンテキストを提供すると便利です。 Permissions API を使用すると、ユーザーが特定のアクセス許可を付与 (または拒否) したかどうかを照会し、それに応じて UI をカスタマイズできます。

アクセス許可 API のしくみにより、ローカル ネットワーク アクセスアクセス許可の状態を照会すると、ユーザーがアクセス許可を付与または拒否されていない場合、LNA 機能フラグが有効になっているかどうかに関係なく、"prompt" が返されます。 Microsoft Edge 143 では機能フラグが既定で有効になっているため、ユーザー エージェント文字列のメジャー バージョンに基づいて異なる動作をディスパッチできます。

LNA アクセス許可プロンプトをトリガーする前に、より多くのコンテキストを提供するために、現在のガイダンスでは、次のようなパターンを使用します。

  • クライアントが Edge < 143 の場合、ローカル ネットワーク要求はサイレントモードで動作する必要があります
  • クライアントが Edge >= 143 の場合は、アクセス許可 API にクエリを実行します (下の呼び出し例を参照してください)。
    • アクセス許可が付与されている場合は、要求の試行に進みます
    • アクセス許可が拒否された場合は、必要に応じて UI を表示して、必要に応じてユーザーの修復に役立ちます
    • アクセス許可の状態が "prompt" の場合は、プロンプトが発生したことをアプリでコンテキスト化します

Permissions API 呼び出しの例:

navigator.permissions.query({ name: "local-network-access" })
.then((result) => {
  console.log(`LNA permission state: ${result.state}`)
});

注: Permissions API は、HTTP ページから呼び出されると常に "denied" を返します。

アクセス許可プロンプトをプログラムでトリガーするにはどうすればよいですか?

リモート エンドポイントへの接続が確立されていない場合、LNA アクセス許可プロンプトはトリガーされません。 ローカル デバイスへの接続を確立する前にワークフローがアクセス許可プロンプトをトリガーするのが簡単な場合、その 1 つの方法は、ホスト名 (localhost、ループバック、またはローカル IP アドレス リテラル) を視覚的に調べることによって、ローカルまたはループバック アドレス空間内にあることが確認できるホスト名に対して fetch() 要求を行う方法です。

実際には、localhost への接続に対するアクセス許可プロンプトをトリガーする場合、JavaScript で次のように fetch() 呼び出しがトリガーされることを意味します。

fetch("http://localhost")

または、ローカル デバイスへの接続に関するアクセス許可プロンプトをトリガーする場合は、次のようにします。

fetch("https://10.0.0.1")

いくつかの注意事項:

  • Microsoft Edge 144 以降で動作する
  • ユーザーがアクセス許可を受け入れた (または拒否した) 場合、ユーザーには別のアクセス許可プロンプトが表示されません。
  • fetch() が実行されたコンテキストに localhost (またはローカル ネットワーク) に接続するためのアクセス許可が必要ない場合、アクセス許可プロンプトはトリガーされません。

iframe 内からローカル ネットワーク要求を行うにはどうすればよいですか?

iframe 内からローカル ネットワーク要求を行うには、埋め込みドキュメントで iframe のローカル ネットワーク アクセス アクセス許可ポリシー フラグを指定する必要があります。 たとえば、domainA.example に domainB.example の iframe が含まれている場合は、次のようにアクセス許可を iframe に明示的に委任する必要があります。

<iframe src="domainB.example" allow="local-network-access"></iframe>

埋め込みドキュメントからローカル ネットワーク要求が行われると、 埋め込み ドキュメントが LNA アクセス許可を要求したかのように扱われ、ユーザーによるアクセス許可の決定は埋め込みドキュメントの配信元に関連付けられます。

iframe 内のドキュメントが、ローカル ネットワーク要求を行う他のドキュメントに移動する場合は、アクセス許可ポリシー フラグでローカル ネットワーク要求を行うことができる可能性があるすべてのドキュメントのすべての配信元を指定する必要があります。 上記の例を拡張するには、domainB.example が iframe を domainC.example に移動し、domainB.example と domainC.example の両方がローカル ネットワーク アクセス要求を行う場合は、次のように両方の配信元にアクセス許可を明示的に委任する必要があります。

<iframe src="domainB.example" allow="local-network-access domainB.example domainC.example"></iframe>

また、allow="local-network-access *" を指定して、iframe で読み込まれる可能性のあるすべての配信元がローカル ネットワーク要求を行えるようにすることもできます (必ずしも事前に認識されていない場合でも)。 たとえば、これは、iframe が localhost にリダイレクトする前に別の配信元 (SSO など) に任意のリダイレクトを行う場合に役立ちます。

その他の注意事項:

  • LNA アクセス許可を要求するには、埋め込みページと iframe の両方が セキュリティで保護されたコンテキスト である必要があります。
  • 入れ子になった iframe 内から LNA アクセス許可を要求する (例: domainA.example は domainB.example の iframe を埋め込み、domainC.example の iframe を埋め込み、ローカル ネットワーク要求を行う) には、すべての iframe でローカル ネットワーク アクセスアクセス許可ポリシー フラグを指定する必要があります。
  • アクセス許可ポリシーは、 エンタープライズ ポリシーを使用してアクセス許可プロンプトをバイパスしている場合でも、ローカル ネットワーク要求を行う iframe に設定する必要があります。

Service Worker または Shared Worker からローカル ネットワーク要求を行うにはどうすればよいですか?

Service Worker と Shared Worker からのローカル ネットワーク要求は、ワーカーの配信元にメイン ウィンドウ コンテキストで LNA アクセス許可が既に付与されている限りサポートされます。 メイン アプリケーション ウィンドウから最初のローカル ネットワーク要求を行ってアクセス許可を要求しようとすると、ワーカーはそのアクセス許可 (バックグラウンドを含む) を利用できます。

専用 Worker からローカル ネットワーク要求を行うにはどうすればよいですか?

専用 Worker は既存のメイン ウィンドウによって厳密に所有されているため、専用 Worker からのローカル ネットワーク要求によって、所有ウィンドウで LNA アクセス許可プロンプトがトリガーされます。

ローカル ネットワーク要求を混合コンテンツとしてブロックしないようにするにはどうすればよいですか?

LNA では、特定のローカル ネットワーク要求が混合コンテンツ ブロックから除外されるようになりました。これにより、HTTPS サイトは次の HTTP エンドポイントに対してローカル ネットワーク要求を行うことができます。

  • .local ドメイン (例: http://printer.local)
  • プライベート IP リテラル (例: http://192.168.0.1/)

さらに、fetch() API を使用する場合は、targetAddressSpace オプションを指定して、要求がローカル ネットワークまたはループバック アドレス宛てであることをマークできます。 以下に例を示します。

  • fetch('http://domainA.example', {targetAddressSpace: 'local'}) は、domainA.example が 192.168.10.1 のようなローカル IP アドレスに解決された場合に機能します
  • fetch('http://domainB.example', {targetAddressSpace: 'ループバック'}) は、domainB.example がループバック アドレス 127.0.0.1 に解決された場合に機能します

これらはすべて混合コンテンツ ブロックから除外されます。

HTTP ページからローカル ネットワーク要求を行うにはどうすればよいですか?

LNA アクセス許可を要求するには、HTTPS 経由で提供されるサイト (つまり、LNA にはセキュリティで保護されたコンテキストが必要です)。 ただし、ローカル ネットワーク要求の作成が複雑であるため、宛先が現在パブリックに信頼されている HTTPS をサポートしていない場合があるため、これらの HTTP ローカル ネットワーク要求は混合コンテンツとしてブロックされる可能性があります。

LNA は一般的なケースの例外を切り開こうとします ( 「ローカル ネットワーク要求を混在コンテンツとしてブロックしないようにするにはどうすればよいですか」のセクションを参照してください)、混在コンテンツの問題を回避するためにサイトを簡単に適応させることが難しい場合があります。

HTTPS を使用するようにサイトを切り替える時間が長く必要な場合、または Microsoft Edge で現在実装されている LNA の混合コンテンツ例外でブロックの問題が発生した場合は、 配信元試用版 にサインアップして、HTTP サイトが LNA のアクセス許可を一時的に要求できるようにします。

メモ： 配信元の試用版トークンは HTTP ヘッダー経由で提供 する必要があります 。 この配信元試用版では、メタ タグを介して、または JS を介してプログラムによって配信されるトークンはサポートされていません。

ブラウザー間の互換性を最も良く維持するにはどうすればよいですか?

ブラウザーによってこれらの制限が異なる時期にロールアウトされるため、互換性を最大化するためにユーザー エージェント検出ロジックを実装する必要がある場合があります。

新しいローカル ネットワーク アクセス仕様をサポートするブラウザーと、まだ 混在コンテンツを中心にしていないブラウザーの主な互換性の違い。 LNA をサポートするブラウザーでは、ローカル ネットワーク アクセスと LNA アクセス許可は、セキュリティで保護された配信元からのみ使用できます。 安全でない配信元からの要求は失敗します。

LNA 仕様をまだサポートしていないブラウザーでは、ローカル リソースへの安全でない要求が混在コンテンツとして識別されないように、安全でない配信元からほとんどのローカル ネットワーク アクセスが実行された可能性があります。

現在、この混合コンテンツ ブロックのために HTTP 経由でページを提供している場合は、HTTPS for Microsoft Edge 143 以降へのリダイレクトを提供できますが、(LNA の制限と混合コンテンツの例外も含まれるまで) HTTP 経由で他のブラウザーの提供を続行できます。

localhost に対してのみローカル ネットワーク要求を行う場合、localhost は混合コンテンツ仕様によって安全な配信元と見なされ、混合コンテンツとしてブロックされないため、HTTPS 経由でサイトを提供できる必要があります。

Microsoft Edge のロールアウト中に、 配信元試用版 に登録して、安全でない (HTTP) 配信元で LNA アクセス許可プロンプトを 一時的に 有効にすることができます。 配信元試用版への登録の詳細については、こちらをご覧ください。 この配信元試用版は、Microsoft Edge 146 (2026 年 3 月に安定チャネルに移動する予定) でのみ利用できます。 配信元試用版のユーザーは、その前に HTTPS への移行を目指す必要があります。

EdgeDriver/Selenium/etc で LNA アクセス許可をテストするにはどうすればよいですか?

ローカル ネットワーク アクセス許可は、WebDriver/EdgeDriver を使用して管理できます。 Edge 固有の機能に関する Selenium ドキュメントと、WebDriver を使用した Microsoft Edge の自動化に関する Microsoft Edge ドキュメントを参照してください。 アクセス許可を具体的に管理するには、 WebDriver setPermissions コマンド と プロトコルの仕様に関するページを参照してください。

ローカル テストで LNA プロンプトをトリガーするにはどうすればよいですか?

LNA の制限はまだローカル→ローカルまたはローカル→ループバック要求には適用されないため、一般的なローカル開発セットアップ (localhost でサーバーを実行する場合など) は、Microsoft Edge でアクセス許可プロンプトをトリガーしません。

ただし、アクセス許可プロンプトがローカル テストでトリガーされるのに役立ちます。たとえば、UI をカスタマイズしてプロンプトの前にコンテキストを追加したり、ユーザーがアクセス許可を拒否した場合の回復に役立てたりする場合に役立ちます (「 LNA アクセス許可プロンプトにユーザーにさらにコンテキストを提供する方法」を参照してください)。 上記)。

Microsoft Edge では、ページをパブリック アドレスから提供されたかのように扱う 2 つの方法が用意されています。

  • HTML ドキュメントの Content-Security-Policy: treat-as-public-address ヘッダーを使用すると、そのドキュメントはパブリック アドレスから提供されたかのように扱われます。
  • --ip-address-space-overrides コマンド ライン フラグを使用すると、特定の IP アドレスを特定のアドレス空間 (パブリック、ローカル、またはループバック) として強制的に処理できます。

アドレス空間オーバーライド フラグの例: メインのローカル開発サーバーは 192.168.10.11 で実行され、192.168.10.12 で実行されている別のサーバーに要求が行われます。 Microsoft Edge を実行するときに、--ip-address-space-overrides=192.168.10.11:0=public を渡して、192.168.10.11 をパブリック アドレスとして強制的に処理できます (0 のポートは "すべてのポートに適用" を意味します)。 その後、192.168.10.12 で実行されているサーバーに要求が行われると、ローカル ネットワーク要求として扱われ、アクセス許可プロンプトがトリガーされます。

自動テストで LNA プロンプトをトリガー しないように するにはどうすればよいですか?

LNA の制限はまだローカル→ローカルまたはローカル→ループバック要求には適用されませんが、一部のブラウザー ベースのテストセットアップには、LNA プロンプトがトリガーされる可能性があるローカル サーバーが含まれる場合があります。 これが予期せず、テストしている実際のユーザー体験と一致しない場合 (たとえば、運用サイトではパブリック サービスへの要求のみを行います)、--ip-address-space-overrides=ip-address>:<port>=<address-space コマンド ライン フラグを使用して特定の IP アドレスをパブリックとして扱うように Microsoft Edge を構成できます。そのため、パブリック サイトからの要求は LNA プロンプトをトリガーしません。

ポート 0 を指定して、その IP アドレス上のすべてのポートにオーバーライドを適用できます。 複数のオーバーライド規則をコンマで区切って指定できます (例: ip-address-space-overrides=192.168.0.1:8080=public,10.0.1.20:0=ループバック)。 フラグの完全な文法については、 こちらを参照してください。

例: ステージング サーバーは 23.220.75.232 (パブリック IP アドレス) で実行されますが、10.0.1.108 (プライベート IP アドレス) で内部的に実行されるサービスに対して要求を行います。 運用環境では、このサービスはパブリック IP アドレスで実行されるため、実際のユーザーには LNA プロンプトが表示されません。 このサービスの自動テスト ハーネスでは、コマンドライン フラグ --ip-address-space-overrides=10.0.1.108:0=public を渡して、その IP アドレスへのすべての接続がパブリックと見なされ、テストで LNA プロンプトがトリガーされることはありません。

サイトが LNA によってブロックされる理由を判断する方法

Web アプリケーションがローカル ネットワーク内にあると見なされるリソースへのアクセスを試みるたびに、ユーザーがこのような要求を許可またはブロックできるようにするプロンプトがトリガーされます。

testingnotsecure

通常、アクセスを許可すると、Web アプリケーションが期待する機能のブロックが解除されます。 現時点では、ローカル ネットワーク アクセス試行がローカル ネットワーク内にあると見なされるクロスオリジン iframe に対する (またはからの) 場合、Web アプリケーションを (手動またはグループ ポリシーを使用して) 除外することはできません。

この iframe シナリオには、一般的に DevTools コンソール エラーが伴います。

Access to fetch at 'http://127.0.0.1:8080/data' from origin 'https://example.com'  

has been blocked by CORS policy: Permission was denied for this request to access the `unknown` address space.

iframe に対して定義されているクロスオリジンホストと最上位ホストを識別する。 影響を受ける Web アプリケーションを適応させ、iframe に 'local-network-access' アクセス許可を追加することをお勧めしますが、Web アプリケーション コードを直接制御しないと不可能な場合があります。

クロスオリジン iframe 内で使用できる Web アプリケーションで使用される特定のライブラリは、バージョン 4.26.1 以降に含まれる MSAL-browser などの必要な LNA アクセス許可をサポートする修正プログラムを既にリリースしています。

クロスオリジン iframe の影響を軽減する方法

最上位または iframe ホストがローカル ネットワーク内にあると見なされる場合、特定のネットワーク条件に応じて、コードの変更を実行せずに影響を軽減する唯一の方法は、 LocalNetworkAccessRestrictionsTemporaryOptOut ポリシー設定を使用することです。

このシナリオを克服するために、2 つの追加のポリシー設定を提供する計画があります。1 つは クロスオリジン iframe が最上位のホスト LNA アクセス許可を継承できるように し、もう 1 つは 、特定のアドレス空間をローカル ネットワークと見なされないように する予定です ( キャリア グレードの NAT アドレス範囲など)。 Microsoft Edge がこれらのポリシーの公式サポートを提供すると、ドキュメントが更新されます。

LNA に関するフィードバックを一般的に提供するにはどうすればよいですか?

GitHub のローカル ネットワーク アクセス仕様リポジトリに関するフィードバックに関する問題を報告します。

Microsoft Edge の LNA 実装のバグを報告するにはどうすればよいですか?

Microsoft Edge のローカル ネットワーク アクセスの実装に固有の問題については、Microsoft Edge フィードバック チャネルを使用するか、エンタープライズ顧客向けのMicrosoft サポートにお問い合わせください。

[エンタープライズ]ローカル ネットワーク要求の許可リストまたはブロックリスト URL の方法

LNA には、 LocalNetworkAccessAllowedForUrls と LocalNetworkAccessBlockedForUrls の 2 つのエンタープライズ ポリシー があります。 これらは、アクセス許可プロンプトを表示せずに URL からのローカル ネットワーク要求を許可したり、URL がローカル ネットワーク要求を行うことをブロックしたりするために使用できます。

これらのポリシーでは、 URL パターン 構文を使用したワイルドカードもサポートされています。

LocalNetworkAccessAllowedForUrls ポリシーは、要求を行うサイトの最上位の配信元に適用されます。 そのページ (または入れ子になった iframe 内) に埋め込まれた iframe 内で実際のローカル ネットワーク アクセスが行われている場合、 すべての iframe でアクセス許可ポリシー フラグを設定する必要があります。

[エンタープライズ]LocalNetworkAccessAllowedForUrls を設定しましたが、まだ問題が発生しています

LocalNetworkAccessAllowedForUrls ポリシーを正しく設定しているが、アプリケーションがまだ動作していない場合は、iframe を修正する必要がある可能性があります。 上の「iframe 内からローカル ネットワーク要求を行うにはどうすればよいですか?」というタイトルのセクションを参照してください。

一時的なエンタープライズ ポリシー LocalNetworkAccessRestrictionsTemporaryOptOut もあります。これにより、企業はすべての LNA 制限をオプトアウトできます。 このポリシーは一時的なポリシーであり、Edge 152 の後に削除されます。

注: これらのポリシーは、グループ ポリシー (ADMX テンプレート経由)、Microsoft Intune (設定カタログを使用)、またはその他の Mobile デバイス管理 (MDM) ソリューションを使用して構成できます。 Microsoft Edge ポリシーの構成の詳細については、「Microsoft Edge ポリシー設定の構成」を参照してください。

  • Last updated on