ローカルネットワークの制限を一時的に外す企業向けポリシーは、ChromeStatusではChrome 156で削除される予定 ── 自社サイトが訪問者のlocalhostや社内に通信していないか確認する13項目（2026年10月時点）

目次

1. 01 何が起きたか — ローカルネットワークへの制限を一時的に外す企業向けの設定が、ChromeStatusでは、Chrome 156で削除される予定になっている
   1. ChromeStatusに書かれた、156での削除
   2. 「予定」であって、156の安定版はまだ出ていない
   3. どんな通信が「ローカルネットワークへの通信」にあたるか
2. 02 なぜ・背景 — 公開のサイトから家庭や会社の機器に通信できてしまうことが、攻撃の足がかりになるため
   1. 制限が入った理由
   2. すでに入っている制限と、これから変わる部分
   3. 削除される設定は、何をするものか
   4. 削除される版の書き方は、文書によって3つある
3. 03 用語 — 読み違えやすい言葉を先にそろえる
   1. ローカルネットワークと、ループバック
   2. 権限の名前が、2つに分かれた
   3. 公開サイトと、イントラネット
   4. 企業向けのポリシーは「Chromeの設定」であって「サイトの設定」ではない
4. 04 型別 — 自社のサイトがどれに当たり、何を、どの順で確かめるか
   1. 🅰 適用範囲 — 影響を受けるのは、手元の機器やアプリに通信するサイトと、その埋め込み
   2. 🅱 公式が書いていないこと
   3. この記事が確かめていないこと
   4. 🅲 手順1 — 自社のコードの中を、7種類の文字で探す
   5. 🅲 手順2 — 提供元のコードと埋め込みを、同じ文字で探す
   6. 🅲 手順3 — 実際のChromeで、許可の確認が出るかを見る
   7. 🅲 手順4 — 提供元に、問い合わせる
   8. 🅲 手順5 — 社内システムを持つ会社は、管理設定を調べる
5. 05 自分のサイトで確認するチェックリスト
6. 06 代替・他の選択肢 — 通信している場合に、公式が挙げている道
   1. 宛先を宣言して、混在コンテンツの扱いを分ける
   2. 管理されたChromeでは、許可リストを使う
   3. 確認の手がかりになる、当サイトの無料ツール
7. 07 当サイトで確かめたこと
   1. 4ページで、読み込まれるコードを、12種類の語で探した
   2. 見つかった4件は、通信の宛先ではなかった
   3. この結果から言えることと、言えないこと
8. 08 このテーマの、これまで
   1. ローカルネットワークアクセスをめぐる、日付つきの記録
   2. 当サイトの、関連する過去の記事
9. 09 この記事のまとめ

01 何が起きたか — ローカルネットワークへの制限を一時的に外す企業向けの設定が、ChromeStatusでは、Chrome 156で削除される予定になっている

ChromeStatusに書かれた、156での削除

Chromeの機能の状況を公開しているChromeStatusに、「Local network access restrictions」（訳: ローカルネットワークアクセスの制限）という項目がある。2026年10月7日に、この項目を開いて読んだ。項目の更新日は、ChromeStatusのAPIの応答によると2026年7月15日である。項目の概要の最後の一文は、次のとおりである。

"In Chrome 156, the LocalNetworkAccessRestrictionsTemporaryOptOut policy will be removed."

（訳: Chrome 156で、LocalNetworkAccessRestrictionsTemporaryOptOutというポリシーは削除される。）

「ポリシー」とは、会社や学校がChromeを一括で管理するための設定（企業向けの管理設定）のことである。この名前のポリシーは、ローカルネットワークへの接続を確認する仕組みを、一時的に外すためのものである。中身は、02章で書く。

「予定」であって、156の安定版はまだ出ていない

Chromiumのリリースの予定表（2026年10月7日に取得）は、Chrome 156について、ベータの最初の日を2026年9月30日、安定版の日を2026年10月20日と書いている。2026年10月7日の時点で、156は一般向けの安定版ではない。Chrome 156のリリースノートのページは、同じ日に開こうとしたところ、見つからなかった（404）。

予定表には、ほかにも安定版の前後の日付が並んでいる（たとえば、“early_stable”という欄に2026年10月7日）。この記事は、その欄が何を指すかを確かめていないので、一般向けの安定版の予定日は10月20日とだけ書く。この記事も、ChromeStatusの文も、「156で削除された」とは書いていない。「削除される予定」と書かれている。

どんな通信が「ローカルネットワークへの通信」にあたるか

同じChromeStatusの項目は、制限の対象を、次のように書いている。

"A local network request is any request from a public website to a local IP address or loopback, or from a local website (for example, intranet) to loopback."

（訳: ローカルネットワークへのリクエストとは、公開のウェブサイトからローカルのIPアドレスまたはループバックへのリクエスト、あるいはローカルのウェブサイト（たとえばイントラネット）からループバックへのリクエストを指す。）

つまり、インターネットに公開されているサイトのページが、訪問者のパソコンの中（localhost）や、訪問者の会社・家の中のアドレスに向けて通信する場合が、対象になる。社内向けのサイトから、同じパソコンの中のlocalhostに通信する場合も、対象に入る。

02 なぜ・背景 — 公開のサイトから家庭や会社の機器に通信できてしまうことが、攻撃の足がかりになるため

制限が入った理由

Chromeの開発者向けのブログは、この制限の目的を、次のように書いている。

"The aim is to protect users from cross-site request forgery (CSRF) attacks targeting routers and other devices on private networks, and to reduce the ability of sites to use these requests to fingerprint the user's local network."

（訳: 目的は、プライベートなネットワークにあるルーターなどの機器を狙った、クロスサイトリクエストフォージェリ（CSRF）の攻撃から利用者を守ること、そして、サイトがこうしたリクエストで利用者のローカルネットワークを識別する力を減らすことである。）

仕様の草案（Web Incubator Community Groupの文書）も、同じ方向の目的を書いている。

"Local Network Access aims to prevent these undesired requests to insecure devices on the local network."

（訳: ローカルネットワークアクセスは、ローカルネットワーク上の、安全でない機器へのこうした望まない要求を防ぐことを目指す。）

すでに入っている制限と、これから変わる部分

ブログの更新（2025年9月29日付）は、「ローカルネットワークアクセスの許可の確認は、Chrome 142で始まる」と書いている。Chrome 142のリリースノート（安定版は2025年10月28日）も、次のように書いている。

"Chrome 142 restricts the ability to make requests to the user's local network, gated behind a permission prompt."

（訳: Chrome 142は、利用者のローカルネットワークへのリクエストを行う力を、許可の確認の後ろに置いて制限する。）

つまり、制限そのものは、Chrome 142からすでに入っている。156で予定されているのは、その制限を会社の管理設定で一時的に外していた設定の削除である。

削除される設定は、何をするものか

Chrome Enterpriseのポリシーの説明（英語版）は、LocalNetworkAccessRestrictionsTemporaryOptOutについて、次のように書いている。

"When this policy is set to Enabled, Local Network Access requests will only display warnings in Chrome DevTools due to Local Network Access checks failing."

（訳: このポリシーを有効にすると、ローカルネットワークアクセスの検査に失敗しても、そのリクエストは、Chrome DevToolsに警告を表示するだけになる。）

この設定を有効にしている組織のChromeでは、検査に失敗しても、通信が止められずに警告だけが出る。この設定が削除されれば、その組織のChromeでも、既定の扱いになる。同じ説明は、長い目で見た代わりの方法も書いている。

"Long term, the policy LocalNetworkAccessAllowedForUrls can be used to allowlist URL patterns that should be automatically granted the Local Network Access permission."

（訳: 長い目で見ると、LocalNetworkAccessAllowedForUrlsというポリシーで、ローカルネットワークアクセスの権限を自動的に与えるURLのパターンを、許可リストに入れられる。）

削除される版の書き方は、文書によって3つある

ChromeStatusは「Chrome 156で削除される」と書いている。一方、Chrome Enterpriseのポリシーの説明は、次のように書いている。

"This enterprise policy is temporary, and will be removed after M152."

（訳: この企業向けのポリシーは一時的なもので、M152のあとに削除される。）

Chromiumのソースコードの、このポリシーの定義ファイル（policy_definitions/LocalNetworkAccessSettings/LocalNetworkAccessRestrictionsTemporaryOptOut.yaml・main の枝を2026年10月7日に開いた）には、さらに別の版が書かれていた。

"This enterprise policy is temporary, and will be removed after M163."

（訳: この企業向けのポリシーは一時的なもので、M163のあとに削除される。）

つまり、削除の版は、ChromeStatusが156、Chrome EnterpriseのページがM152のあと、ChromiumのソースがM163のあとと、3つの書き方がある。矛盾しているとは限らないが、3つが同じ版を指しているかは、確かめられていない。この記事は、ChromeStatusの書き方（156）を軸にし、版の書き方が3つあることを、そのまま伝える。

03 用語 — 読み違えやすい言葉を先にそろえる

ローカルネットワークと、ループバック

権限の名前が、2つに分かれた

公開サイトと、イントラネット

企業向けのポリシーは「Chromeの設定」であって「サイトの設定」ではない

ポリシーは、組織が自分たちのChromeに配る設定である。サイトの運営者が、訪問者のChromeに対して設定できるものではない。そのため、運営者が確かめるのは、「自社のサイトが、訪問者のlocalhostや社内のアドレスに通信していないか」と、「自社の組織でこのポリシーを使っていないか」の2つに分かれる。

04 型別 — 自社のサイトがどれに当たり、何を、どの順で確かめるか

🅰 適用範囲 — 影響を受けるのは、手元の機器やアプリに通信するサイトと、その埋め込み

公式文書から読み取れる範囲では、影響を受けるのは次の3つである。1つ目は、自社のコードが、訪問者のlocalhostや社内のアドレスに通信しているサイト。2つ目は、提供元のタグや埋め込みが、そうした通信をしているサイト。3つ目は、社内向けのサイトを持ち、Chromeの管理設定で、この制限を外していた組織である。

通常のホームページや記事のサイトで、手元の機器やアプリと連携していなければ、影響は小さいと考えられる。ただし、小さいか大きいかは、確かめるまで分からない。

🅱 公式が書いていないこと

次のことは、確かめた範囲の公式文書には書かれていない。この記事も、断定しない。

• 削除が、ChromeStatusの言う156なのか、ポリシーの説明の言う152より後、またはChromiumのソースの言う163より後のどの版なのか。
• 削除のあと、権限の確認が出ないままで通信できていた組織のChromeに、何が起きるかの詳しい動作。
• Chrome 156の安定版で、ほかに何が変わるか（リリースノートが見つからなかった）。

ChromeStatusの記載では、Firefoxは「出荷中」、Safariは「意見の表明なし」とされている。この記事は、各社の実装を確かめていない。

この記事が確かめていないこと

自社のサイトが、実際のChromeで、許可の確認を出すかどうかは、サイトごとに違うため、この記事では確かめていない。確かめ方は、手順3に書いた。

🅲 手順1 — 自社のコードの中を、7種類の文字で探す

最初に、自社が管理しているテンプレート・JavaScript・設定のフォルダを、エディタのフォルダ内検索で調べる。探す文字は、次の表のとおりである。

探す文字	何を指すか	注意すること
localhost	訪問者のパソコン自身（ループバック）	通信の宛先ではなく、アドレスを比べるだけの文でも出る
127.0.0.1	同じく、ループバックのIPアドレス	127で始まるアドレス全体が対象になる
[::1]	IPv6のループバック	括弧つきで書かれることが多い
192.168.	家庭や会社で使われる私用のアドレス	10.で始まるものと172.16〜31で始まるものも、私用のアドレスの範囲
.local	機器の名前の末尾に付く形（ブログの例ではrouter.local）	ドメインの末尾に付いた場合だけ数える
ws://とwss://	WebSocketの接続先	Chrome 147から、ローカルの宛先は権限の確認の対象
targetAddressSpace	通信の宛先の種類を宣言する、fetchの指定	ブログが例として挙げる指定。使っていれば、宛先がローカルだと宣言した書き方になっている

🅲 手順2 — 提供元のコードと埋め込みを、同じ文字で探す

自社が書いていないコード（タグ・チャット・予約・読取機器の連携など）は、ページを開いたときに読み込まれる。Chromeの開発者ツールのNetworkパネルには、検索の機能があり、公式の説明は、次のように書いている。

"Use the Search tab when you need to search the HTTP headers and responses of all resources for a certain string or regular expression."

（訳: 特定の文字列や正規表現を、すべての資源のHTTPの見出しと応答から探したいときは、検索のタブを使う。）

画面を開いたあと、Macなら Command + F、WindowsやLinuxなら Control + F で検索のタブが開く。代表のページを3つ開いて、手順1の文字を1つずつ検索し、見つかった資源の名前（どの提供元のファイルか）を書く。

ただし、文字が見つかったことと、そこへ通信していることは別である。07章で、当サイトの実例を書く。

🅲 手順3 — 実際のChromeで、許可の確認が出るかを見る

Chrome 142以降で、代表のページを開く。制限が働くなら、ローカルネットワークへの接続を許可するかを、利用者に尋ねる確認が出る。ChromeStatusは、通信が止められる場合について、次のように書いている。

"When a request would be blocked under LNA, we add a new DevTools Issue with details."

（訳: LNAのもとでリクエストが止められる場合は、詳細つきの新しいDevToolsのIssue（問題）を追加する。）

したがって、確認が出なくても、開発者ツールの「Issues」パネルを開いて、項目が出ていないかを見る。ただし、IssuesパネルのChrome公式の説明は、2020年が最終更新で、報告する種類にこの制限を挙げていない。公式の説明に載っていないことと、パネルに出ないことは別なので、出るかどうかは、自社のサイトで確かめるしかない。

ChromeStatusは、許可されなかったときの影響を、次のように書いている。

"if users deny the permission functionality may break (potentially requiring additional support from site owners)"

（訳: 利用者が許可しないと、機能が壊れる場合がある（サイトの運営者による追加の対応が必要になる可能性がある）。）

🅲 手順4 — 提供元に、問い合わせる

手順2で見つかった提供元や、手元の機器・アプリと連携する提供元には、問い合わせの文章を送る。次のような文面が使える。

Chromeでは、公開のサイトから訪問者のlocalhostや社内のアドレスへの通信に、
許可の確認が出ます（Chrome 142以降）。貴社のタグまたは部品について、
1. 訪問者のlocalhostや社内のアドレスへ通信しますか。
2. 通信する場合、許可の確認が出ても、機能は動きますか。
3. 当社の側で、設定の変更や作業が必要ですか。

返事は、提供元の名前、問い合わせた日、返事の日、要点を、一覧に書き足す。

🅲 手順5 — 社内システムを持つ会社は、管理設定を調べる

社内向けのサイトを持つ会社は、情報システムの担当者に、LocalNetworkAccessRestrictionsTemporaryOptOutを使っているかを聞く。使っている場合は、削除のあとに、同じ社内のサイトが動くかを、先に試す。長い目で見た代わりの方法として、公式の説明は、LocalNetworkAccessAllowedForUrlsを挙げている。その説明は、次のように書いている。

"Network requests initiated from websites served by matching origins are not subject to Local Network Access checks."

（訳: 一致するオリジンから配信されるウェブサイトが始めたネットワークへのリクエストは、ローカルネットワークアクセスの検査の対象にならない。）

05 自分のサイトで確認するチェックリスト

下の13項目は、1項目5分ほどでできる作業である。項目1〜6が手順1、項目7〜8が手順2、項目9と10が手順3、項目11が手順4、項目12が手順5、項目13が全体の記録に対応している。チェックの状態はブラウザの中にだけ保存され、サーバーには送られない。

• 自社のテンプレートとJavaScriptのフォルダを、エディタのフォルダ内検索で開き、「localhost」を検索して、見つかった件数を書く
• 同じ検索で「127.0.0.1」と「[::1]」を検索し、見つかった件数を、語ごとに書く
• 同じ検索で「192.168.」を検索し、さらに正規表現で「10.」から始まるアドレスと、「172.16」から「172.31」で始まるアドレスを検索して、件数を書く
• 同じ検索で「.local」を検索し、ドメインの末尾が「.local」になっている文字列の件数を書く
• 同じ検索で「ws://」と「wss://」を検索し、見つかった接続先を1つずつ書いて、自社のサーバーかを「はい」か「いいえ」で書く
• 見つかった行を1件ずつ開き、「通信の宛先」「比べているだけ」「そのほか」のどれかを書き、「通信の宛先」の件数を数える
• 代表のページを3つ、Chromeで開き、開発者ツールのNetworkパネルの検索で、「localhost」と「127.0.0.1」を探し、ページごとに見つかった件数を書く
• 項目7で見つかった資源の提供元の名前を書き出し、自社の提供元の一覧と、1つずつ照らし合わせる
• 同じ3つのページを、Chrome 142以降で開き、ローカルネットワークへの接続の許可を求める確認が出るかを、ページごとに「出る」か「出ない」で書く
• 同じ3つのページで、開発者ツールのIssuesパネルを開き、項目が出るかを、ページごとに「出る」か「出ない」で書く
• 手順2で名前の出た提供元のうち、3つを選んで、問い合わせの文面を送り、送った日と、返事の有無を書く
• 社内向けのサイトがあるかを情報システムの担当者に聞いて「ある」か「ない」で書き、ある場合は、LocalNetworkAccessRestrictionsTemporaryOptOutを使っているかを「使っている」「使っていない」「分からない」で書く
• 結果を日付つきで1つのファイルに保存し、安定版の予定日の2026年10月20日の後に、項目9と10をもう一度行う予定を、カレンダーに1つ登録する

時間が限られているときは、項目1・6・9・11の4つだけでも、概要は分かる。手元の機器やアプリと連携していないサイトなら、項目1〜6で何も見つからなければ、確認は終わりに近い。

06 代替・他の選択肢 — 通信している場合に、公式が挙げている道

宛先を宣言して、混在コンテンツの扱いを分ける

Chromeのブログは、許可を得たローカルネットワークへのリクエストが、混在コンテンツの検査から外れる条件を挙げている。宛先が私用のIPアドレスそのもの、.localのドメイン、あるいは、fetchにtargetAddressSpaceという指定を付けた場合の3つである。コードを書いている側の選択肢としては、この指定が1つの手がかりになる。ブログは、この指定を、混在コンテンツの検査から外れる条件として書いている。許可の確認をなくす指定とは、書いていない。

管理されたChromeでは、許可リストを使う

会社のChromeに配る側の選択肢は、LocalNetworkAccessAllowedForUrlsである。一致するURLのパターンには、権限の検査が適用されない、と書かれている。一方、LocalNetworkAccessBlockedForUrlsは、逆に、一致するオリジンからのローカルネットワークへのリクエストを止める。Chrome 147のリリースノートは、WebSocketの制限にも、この2つと一時的な外し方の設定が、これまでどおり適用される、と書いている。

確認の手がかりになる、当サイトの無料ツール

公開ページの基本情報を一覧で見たいときは、当サイトの無料ツール🔧 WEBサイト総合分析・レポートツールが使える。cssやjsのファイルを読んで確かめたいときは、🔧 cssファイル、jsファイルのソースチェックツールが手がかりになる。どちらも、ローカルネットワークへの通信の有無を判定するツールではない。

外部の提供元の洗い出しは、当サイトの記事「Chrome 153のリリースノートで、広告とクッキーに関わるAPI 5つが「廃止予定」になった ── 自社のタグと埋め込みの提供元に確認する14項目（2026年10月時点）」で扱い、埋め込みの高さの扱いは、記事「Chrome 154で、iframeの高さを中身に合わせる指定が入った。ただし親のCSSと子のmetaの2か所が要る ── 自社の埋め込みを「両側を持つもの」と「提供元に頼むもの」に分ける13項目（2026年10月時点）」で扱った。この記事は、それらの内容を繰り返さない。

07 当サイトで確かめたこと

4ページで、読み込まれるコードを、12種類の語で探した

2026年10月7日15時43分に、当サイトの4ページ（トップ・ブログの1本・無料ツールの1つ・サイト紹介）を取得し、コメントの中を除いて、読み込まれているスクリプトを調べた。4ページの延べで、読み込まれるスクリプトが70本、ページに直接書かれたスクリプトが37本あった。70本とも取得でき、ページ本体と、直接書かれたスクリプトとあわせて、次の語を探した。localhost、127で始まるアドレス、192.168.、10.、172.16〜31、169.254.、機器名の末尾の.local、[::1]、ws://とwss://、targetAddressSpace、WebSocket、WebTransportである。

結果は、1か所を除いて、すべて0件だった。対象ページには、jQuery・Googleのタグ・カルーセル・シェアのボタンなどの部品が含まれている。

見つかった4件は、通信の宛先ではなかった

1か所だけ、語が見つかった。無料ツールのページが読み込む、Googleのログイン用の部品（accounts.google.comから読み込むファイル）の中に、localhostが4件あった。3回取得して、3回とも4件だった。文字の前後を読むと、4件とも、ページのアドレスや、指定されたログイン後の戻り先のアドレスを調べる比較だった。「https以外は認めない。ただし、localhostは認める」という条件の書き方である。訪問者のlocalhostへ通信する書き方ではなかった（コードを目で読んだ範囲）。

この結果は、手順2の注意の実例である。文字が見つかったことと、そこへ通信していることは別である。針の確認として、12種類の語を1つずつ含む短い文字列に同じ探し方を当てると、12種類のどれも1件以上と数えられた。

この結果から言えることと、言えないこと

言えるのは、確かめた4ページで、取得した範囲のスクリプトの中に、ローカルのアドレス宛ての通信を指す書き方は見つからなかったことである。言えないことは、3つある。1つ目は、ページを開いたあとにJavaScriptが組み立てる通信は、取得しただけでは分からないこと。2つ目は、確かめていないページが残っていること。3つ目は、実際のChromeで許可の確認が出るかは、この記事では確かめていないことである。

外から確かめるときに、画面の種類を確かめてから読むことは、当サイトの記事「外から取った画面は、目当ての画面とは限らない ── 遮断の画面を404と読み、引用符の違いでnoindexを「無い」と読みかけた」で書いた。自動で写した画面が、読者の画面と違うことは、記事「「吹き出しが出ていない」と写った ── 壊れていたのは、作ったものではなく写し方だった。自動のスクリーンショットが読者の画面と違う3つ（動き・幅・枚数）」に書いてある。この記事の許可の確認も、取得だけでは見えないので、実際の画面で見る手順にした。

08 このテーマの、これまで

ローカルネットワークアクセスをめぐる、日付つきの記録

日付・版	出来事
2025年3月6日	ChromeStatusに、この項目が作られた（APIの応答の作成日より）
2025年6月9日	Chrome for Developersのブログで、新しい許可の確認の予告が出た。Chrome 138では、フラグで試せると書かれた
2025年10月28日	Chrome 142が安定版になった。ローカルネットワークへのリクエストが、許可の確認の後ろに置かれた
2026年2月10日	Chrome 145が安定版になった。権限が、local-networkとloopback-networkに分かれた
2026年4月7日	Chrome 147が安定版になった。WebSocketとWebTransportも、制限の対象になった
2026年9月30日	Chrome 156のベータが始まる予定の日（予定表より）
2026年10月20日	Chrome 156の安定版の予定日。一時的に外す設定は、156で削除される予定（ChromeStatus）

Chrome 146で、IPアドレスの範囲を公開・私用として扱い直すポリシーと、埋め込みへの権限の引き継ぎを既定で有効にするポリシーの2つが追加された、とChromeStatusには書かれている。Chrome 146のリリースノートで同じ記載を探したが、見つからなかった。

この記事は、削除される日が、この表のどの行にも含まれていないことを、そのまま書く。

当サイトの、関連する過去の記事

• 外から取った画面は、目当ての画面とは限らない ── 遮断の画面を404と読み、引用符の違いでnoindexを「無い」と読みかけた — 外から取った画面が、目当ての画面とは限らなかった話。
• 「吹き出しが出ていない」と写った ── 壊れていたのは、作ったものではなく写し方だった。自動のスクリーンショットが読者の画面と違う3つ（動き・幅・枚数） — 自動のスクリーンショットが、読者の画面と違った話。
• 記事に書いた弱点が、自分のサイトにあった ── 公開した日にチェック項目を当てたら、エラー画面の返し方と、サイトの名前の書き方がそろっていなかった — 記事に書いた弱点が、自分のサイトにもあった話。
• AIは331回来たと書いた。実際は11,024回だった ── HTTPのログだけを52日間 見ていた — 見ていた範囲が狭かったために、数字が小さく出た話。
• 「リンク切れ0本」を確認して、安心しかけた ── 自社ブログの内部リンク、59.2%はnoindexへの飛び先だった — 「0本」を確認して、安心しかけた話。