Googleは2026年8月27日、Android 17に導入した4つのネットワーク保護を公表した。家庭内Wi-Fiに関わる変更では、アプリが同じネットワーク上のテレビ、プリンター、カメラなどを探す際に、利用者の許可を求めるようになった。従来は外部のWebサービスへ接続するための「インターネット」権限が、そのまま家庭内LANへの通行証にもなっていた。Android 17はこの二つを分離したが、端末を更新した日に全アプリの通行証が失効するわけではない。
399アプリの調査が捉えた、無許可アクセスの実態
ローカルネットワークでは、スマートTVやネットワークカメラなどの機器が、自分の存在や利用できるサービスを知らせている。ゲーム機からスピーカー、プリンターまで同じ仕組みを使う。キャストや印刷には便利だが、機器名とサービスの組み合わせは家庭の輪郭も描く。Google自身、LANへの無制限なアクセスが機器構成による識別や、位置を推測する代替手段になり得ると説明している。
危険は想定上の話に限られない。2025年の査読研究は399本のAndroidアプリを854回手動検査し、89本で想定外のLANアクセス、93本でネットワーク走査を確認した。LANへアクセスした124本のうち100本は、利用者がプライバシーポリシーへ同意する前に通信を始めた。Proceedings on Privacy Enhancing Technologiesに掲載された論文「LANShield」は、前景・背景動作、プライバシーポリシーへの同意、実行時権限の有無を変えながら検査している。
| 調査項目 | 結果 |
|---|---|
| 手動検査したアプリ | 399本 |
| 検査回数 | 854回 |
| 想定外のLANアクセスを確認 | 89本 |
| ローカルネットワーク走査を確認 | 93本 |
| ポリシー同意前にLAN通信を開始 | 124本中100本（80.6%） |
399本は5カテゴリーから選ばれた非無作為標本であり、結果をGoogle Play全体の発生率へ一般化することはできない。また、89本がすべて悪意あるアプリだった、という結果でもない。研究者がアプリの機能と操作から「想定外」と分類した通信も含むためだ。それでも93本がLANを走査し、LANへ接続した124本の80.6%が利用者の同意前に通信を始めた事実は、インターネット権限の範囲が広すぎたことを示している。
研究チームはさらに、インターネット権限しか持たない悪意あるアプリを使い、LAN内の情報を得る、機器探索の通信を操作して通信経路へ割り込む、LAN上の機器を直接攻撃するといった複数の実証例を作った。調査対象のアプリが同じ攻撃を実行していたわけではない。しかし、外部からはルーターに守られた機器でも、同じWi-Fiにいるスマートフォン上のアプリが内側から接触できるという攻撃面は確認された。
Android 17はソケットの深い層でLANを分ける
Android 17で新設されたACCESS_LOCAL_NETWORKは、特定の機器探索APIだけを塞ぐ権限ではない。外向きと内向きのTCP接続、UDPのユニキャスト、マルチキャスト、ブロードキャストの送受信まで対象にする。直接ソケットを開くコードに加え、CronetやOkHttpなどのライブラリ、その上に構築されたAPIにも制限が及ぶ。
機器を見つける経路も同じだ。Multicast DNS（マルチキャストDNS、mDNS）、Simple Service Discovery Protocol（SSDP）、AndroidのNsdManager、末尾が.localの名前解決にはローカルネットワーク権限が必要になる。アプリが別のAPIへ乗り換えるだけで回避できないよう、Googleはネットワークスタックの深い層で通信を判定する。
ただし、端末の通信を丸ごと止める仕組みではない。LAN上のDNSサーバーとポート53で通信する場合は例外となる。OSが仲介するデバイス選択画面で利用者が選んだ機器のアドレスにも、広い権限なしで接続できる。Android 17が加えたのはLANの禁止ではなく、「外部インターネットへ接続できるアプリなら家庭内の全機器にも接触できる」という権限の束ね方を解く境界である。
Googleが同時に紹介したEncrypted Client Hello（ECH）、証明書透明性の既定化、通信事業者による2Gの既定無効化は、それぞれ別の通信面を守る。ECHは訪問先ドメインの露出、証明書透明性は不正な証明書、2G制御は偽基地局によるダウングレードを扱う。ローカルネットワーク保護が閉じるのは、端末内のアプリから同じLANへ向かう経路だ。
API 37へ更新するまで、古い通行証は残る
AndroidのLAN保護はAndroid 16で開発者向けの任意試験として始まり、Android 17でAPI 37を対象にするアプリへ強制された。一方、2026年8月31日からGoogle Playが新規アプリと更新に求める最低対象はAPI 36であり、OS公開時点ではAPI 37への一斉移行は求められていない。iOSは同種の利用者許可をiOS 14で導入していた。
Android 17端末を使っていても、API 36以下を対象にしたアプリは従来どおりLANへ接続できる。Googleは互換性を保つため、こうしたアプリにはインターネット権限からACCESS_LOCAL_NETWORKを暗黙に付与する。保護が強制されるのは、開発者がアプリの対象をAndroid 17のAPI 37以上へ引き上げた時点である。
移行はAndroid 16から始まっていた。同版では開発者が任意でローカルネットワーク保護を試し、一時的にNEARBY_WIFI_DEVICES権限を使って依存箇所を洗い出せた。Android 17は試験を正式なACCESS_LOCAL_NETWORK権限へ置き換え、API 37向けアプリに強制した。
ここに普及の時間差が生じる。2026年8月31日からGoogle Playが新規アプリと更新に求めている最低ラインは、Android 16のAPI 36以上だ。API 37は現在の提出要件ではない。開発者は先行して移行できるが、ストアの要件だけを満たすアプリは当面API 36に残れる。Google PlayがAPI 37を必須にする日程も、9月1日時点の公式ページには掲載されていない。
したがって、「Android 17でアプリは家庭内LANを無断走査できなくなった」という説明には条件が付く。API 37へ移行したアプリでは正しい。一方、対象APIが36以下の既存アプリには古い通行証が残る。利用者側から見た保護範囲は、端末のOSバージョンと各アプリの対象APIの組み合わせで決まる。
許可画面を増やさずに機器を選ぶ設計
開発者には二つの経路がある。スマートホーム管理のようにLAN内の複数機器へ広く、継続して接続するアプリは、ACCESS_LOCAL_NETWORKを宣言し、実行時に利用者へ許可を求める。拒否や後からの取り消しも想定して、通信できない状態を処理しなければならない。
動画を一台のテレビへ送る、特定のサービスを一つ選ぶといった用途では、OSが仲介するデバイス選択画面を使える。Google Cast対応アプリは出力先切替画面を使い、mDNSで一般機器を探すアプリはNsdManagerの選択画面を呼び出す。OSが候補を表示し、アプリには利用者が選んだ接続先だけを渡すため、LAN全体を見せる広い権限を求めずに済む。
この設計は、権限画面の回数を減らす以上の意味を持つ。利用者が「付近の機器へのアクセス」を一括で許す代わりに、接続したい一台を選べるからだ。写真アプリへ全ライブラリの閲覧権限を渡さず、選んだ写真だけを共有する方式に近い。
もっとも、ACCESS_LOCAL_NETWORKは既存のNEARBY_DEVICES権限グループに入る。同じグループにあるBluetoothなどの権限を既に許していれば、ローカルネットワークのための新しい確認画面は出ない。通信は技術的に制御されても、利用者が新しい権限の追加を認識できるとは限らない。広い許可を求めるアプリは、どの機器へ何のために接続するかを画面上で具体的に説明する必要がある。
iOS 14から6年、普及を測る条件
Appleは2020年のiOS 14でローカルネットワークプライバシーを導入し、アプリが初めてLANへ接続する際に利用者へ確認する方式を採った。Androidが正式な強制へ進んだのは2026年のAndroid 17で、導入時期には6年の開きがある。Androidは互換性を維持しながら対象APIで段階移行する道を選んだ。
先行した仕組みが完全だったわけでもない。LANShield論文はiOSの保護を分析し、権限を迂回できる複数の手法を報告した。Android 17の開発者文書も、DNS、選択済み機器、従来アプリへの暗黙付与といった例外を明記している。権限の有無を、すべてのLAN攻撃を防ぐ保証と受け取るべきではない。
Android 17の実効性を測る数字は、OSの導入率だけでは足りない。API 37へ移行したアプリの割合、広い権限ではなくOSの選択画面を採用した機器連携アプリの数、そしてVPN、IPv6、複数サブネットを含む独立試験で迂回を許さないかが判断材料になる。その条件がそろえば、家庭内LANはようやく外部インターネットとは別の私的な空間として、Androidの権限モデルに組み込まれる。
