フリーWi-Fiの危険と、HTTPSで足りる範囲

先に、もう漏れないものから書きます。カフェや空港のWi-Fiにつないでいても、HTTPSで保護されたページでやり取りしている中身——入力したIDとパスワード、クレジットカード番号、表示されているページの本文、送信したメッセージ——は、Wi-Fiを提供している側からも、同じアクセスポイントにつないでいる他の利用者からも、そのままの形では読めません。 ここは、2010年代に「フリーWi-Fiは危ない」と言われていた頃といちばん変わった部分です。当時の警告文の多くは、通信が暗号化されていないことを前提にしていました。その前提が、現在は大きく変わっています。

そのうえで、まだ経路に残るものがあります。接続先のドメイン名（どのサイトを見ているか）、DNSの問い合わせ（そのドメインの住所を引く通信）、通信の量とタイミング、そしてHTTPのままのページの中身です。「何を書いたか」は見えにくくなり、「どこへ行ったか」は条件次第で見え得る、という配分になっています。

そして、保護されたページの中身が読まれ得る場面が、実質的にひとつだけ残っています。証明書に関する警告が出たときに、自分で「続行」を選んだ場合です。 逆に言えば、警告が出ていない状態でHTTPSのページを見ている限り、中身の盗み見という古典的な図式はそのままの形では起きにくくなっています。以下、この3つを順に分解します。

「フリーWi-Fiが危険」の“危険”は、いま何を指しているのか

公的機関が挙げてきた脅威は、大きく3つに整理されています。IPA（情報処理推進機構）はテクニカルウォッチ「公衆無線LAN利用に係る脅威と対策」で、通信の傍受・盗聴／なりすましアクセスポイント／端末への不正アクセスを脅威として挙げています（出典: 独立行政法人情報処理推進機構「IPAテクニカルウォッチ『公衆無線LAN利用に係る脅威と対策』」https://www.ipa.go.jp/security/technicalwatch/201600330.html 、2016年3月30日公開、2026年8月7日確認）。

総務省も、無線LANは無線を使う性質上、通信内容が傍受（盗聴）される危険性があるとしたうえで、ログイン情報やクレジットカード番号などをやり取りする場合には、自分と相手先との間で通信が暗号化されていることを確認するよう求めています。あわせて、公共の場で無線LANを使うときはファイル共有機能を解除するよう挙げています（出典: 総務省「安全な無線LANの利用」国民のためのサイバーセキュリティサイト https://www.soumu.go.jp/main_sosiki/cybersecurity/kokumin/security/business/staff/03/ 、2026年8月7日確認）。

ここで注目したいのは、公的な注意喚起が**「Wi-Fiにつなぐな」ではなく「通信が暗号化されているか確認しろ」という形になっている点です。総務省の「公衆Wi-Fi利用者向け 簡易マニュアル」でも、対策の柱として、接続するアクセスポイントをよく確認すること、正しいURLでHTTPS通信しているか確認すること、共有設定に注意することが挙げられています（出典: 総務省「無線LAN（Wi-Fi）の安全な利用（セキュリティ確保）について」https://www.soumu.go.jp/main_sosiki/cybersecurity/wi-fi/ 、2026年8月7日確認）。つまり脅威の中心は、回線そのものというより暗号化されていない通信とつないだ先が本物かどうか**に移っています。

HTTPSが閉じたのは、どこまでか

Mozillaは、通常のHTTPで転送されるデータは保護されておらず平文（cleartext）で送られるため、攻撃者がそのデータを閲覧・窃取・改ざんできる、と説明しています（出典: Mozilla Security Blog「Firefox 83 introduces HTTPS-Only Mode」https://blog.mozilla.org/security/2020/11/17/firefox-83-introduces-https-only-mode/ 、2020年11月17日投稿、2026年8月7日確認）。HTTPSはこの平文をやめる仕組みなので、**効く範囲は「その通信の中身」**です。

どれくらい行き渡ったのか。Googleは2025年10月28日の投稿で、Chromeにおけるナビゲーションのうち安全な接続の割合が2015年頃の30〜45%から2020年頃には95〜99%の範囲に達し、その後は横ばいだと説明しています。プライベートアドレスを除く公開サイトに限った内訳として、Linuxで約97%、Windowsで98%、AndroidとMacで99%超という数字も挙げています（出典: Google「HTTPS by default」https://blog.google/security/https-by-defau/ 、2025年10月28日投稿、2026年8月7日確認）。同じ投稿でGoogleは、残ったHTTPの割合も無視できるものではないとして、Chrome 147（2026年4月）で拡張保護機能を有効にしている利用者に「Always use secure connections」（安全な接続を常に使う設定）を既定で有効化し、Chrome 154（2026年10月）で全利用者の既定にする計画を示しています。この計画がそのとおりに実施されたかどうかは、当編集部では確認していません。

一方、効かない範囲もはっきりしています。HTTPSが守るのは通信の中身であって、自分がどこへ接続したかという事実そのものではありません。また、偽サイトに自分でIDとパスワードを入力してしまう経路（フィッシング）には、通信の暗号化は効きません。鍵マークは「通信が保護されている」ことを示すもので、「その相手が信用できる」ことを示すものではないからです。

経路に残るもの — 「どこへ行ったか」はどこまで隠れるか

接続先のドメイン名は、長らく暗号化の外側にありました。TLSの接続開始時に送られるServer Name Indication（SNI）が平文だったためです。Cloudflareは、SNIが平文で送られるということは、途中のどの中継者も接続の最初のパケットを見るだけで、どのウェブサイトを訪問しているかが分かることを意味する、と説明しています（出典: Cloudflare「Encrypted Client Hello - the last puzzle piece to privacy」https://blog.cloudflare.com/announcing-encrypted-client-hello/ 、2023年9月29日投稿、2026年8月7日確認）。

これを塞ぐ仕組みがEncrypted Client Hello（ECH）で、2026年3月にRFC 9849として標準化されました。同RFCは、ClientHelloの平文SNIがTLS 1.3で暗号化されずに残る情報のうちとりわけ機微なものだと位置づけています（出典: IETF「RFC 9849: TLS Encrypted Client Hello」https://www.rfc-editor.org/rfc/rfc9849.html 、2026年3月発行、2026年8月7日確認）。

ただし、ECHが実際に働くには条件が要ります。ブラウザ側では、FirefoxがECHを利用者に提供したのはFirefox 119です（出典: Mozilla「Firefox 119.0 Release Notes」https://www.firefox.com/en-US/firefox/119.0/releasenotes/ 、2026年8月7日確認）。Mozillaは、当初FirefoxがECHの動作にDoH（DNS over HTTPS）の有効化を必要としていたこと、Firefox 129以降はOSのDNSリゾルバ経由でも必要な情報を取得できるようになったこと、そしてECHのプライバシー上の利点を十分に得るにはDoHの利用を推奨することを記載しています（出典: MozillaWiki「Security/Encrypted Client Hello」https://wiki.mozilla.org/Security/Encrypted_Client_Hello 、2026年8月7日確認）。訪問先のサーバ側がECHに対応していることも要ります。

DNSのほうも条件付きです。Googleは、Chromeのセキュア DNS が既定で「自動」モードで有効になっていること、そしてこのモードでサイトの参照に問題が起きた場合は暗号化されていない方式で参照し直すことを説明しています（出典: Google「Manage Chrome safety and security」https://support.google.com/chrome/answer/10468685 、2026年8月7日確認）。自動モードは、いま使っているDNSの提供元が暗号化に対応している場合にそれを使う、という条件付きの動作です。

まとめると、接続先のドメインが経路上から見えにくくなるかどうかは、(1) ブラウザ、(2) DNSの設定、(3) 訪問先サーバの対応、という3つが揃うかどうかで決まります。 揃えば見えにくくなり、揃わなければ見え得ます。自分の環境でどうなっているかを確かめずに「隠れている」と考えるのは、根拠を1つ飛ばしています。ここで見え得るのは「どのドメインへ行ったか」であって、「そこで何を読み書きしたか」ではない、という区別も併せて持っておいてください。

中身が読まれ得る入口 — 証明書の警告

ここが、この記事でいちばん実務的な部分です。HTTPSで保護されたページの中身が第三者に読まれる状態は、利用者自身が警告を踏み越えたときに生まれます。

Chromeの日本語ヘルプには、サイトとの接続状態が「保護されていない通信」であるとき、そのサイトはプライベート接続を使用しておらず、送受信される情報は何者かに見られる、または変更される可能性がある、という説明が置かれています。「保護されていない通信、または危険」の状態については、そのページで個人情報や機密情報を入力しないようにという注意が書かれています。さらに、「この接続ではプライバシーが保護されません」というエラーメッセージがページ全体に表示された場合は、サイト、ネットワーク、デバイスのいずれかに問題がある、と説明されています（出典: Google「サイトの接続が安全かどうかを確認する」https://support.google.com/chrome/answer/95617?hl=ja 、2026年8月7日確認）。画面の表記はヘルプページの更新やChromeの版によって変わり得ます。読む時点での表記はリンク先でご確認ください。

この全画面のエラーが公衆Wi-Fiで出たとき、原因のひとつとして想定されるのが、IPAが挙げていたなりすましアクセスポイントです。施設が出しているように見えるアクセスポイントが、実際には別の誰かが立てたものである場合、接続先の証明書が本来のものと食い違い、この種の警告が出ます。このとき「続行」を押すか押さないかが、中身が読まれ得る状態に入るかどうかの分かれ目になります。 押さずに引き返す、という一手で足ります。

なお、本稿には警告画面のスクリーンショットを掲載していません。 上に書いたのは、Googleの公式ヘルプページに置かれている説明を確認日時点で読み取ったものであり、当編集部の端末で警告を再現して撮影した画像ではありません。この点は後述の3分類にも記載します。

もうひとつ、公衆Wi-Fiでは接続直後にログイン用のポータルページが開くことがあります。Googleは、カフェなどの公衆Wi-Fiネットワークに接続する場合にポータルページからのログインが必要になることがあり、多くの場合Chromeがそれを検出してログインを求めると説明しています（出典: Google「Chrome の接続エラーと読み込みエラーを解決する」https://support.google.com/chrome/answer/6098869?hl=ja 、2026年8月7日確認）。ポータルは正規の仕組みですが、ここで求められる情報が施設の利用に不釣り合いに多い場合（他サービスのIDとパスワードなど）は、入力せずに手を止める判断ができます。

何が起きていないか

恐怖の増幅を避けるために、起きていないことも書きます。

「つないだだけで端末が乗っ取られる」ではありません。 IPAが挙げた「端末への不正アクセス」は、共有設定が有効になっている、あるいは既知の脆弱性が放置されているといった条件と結びついた話です。総務省がファイル共有機能の解除を挙げているのは、そのためです（前掲、総務省「安全な無線LANの利用」）。条件を外せば、この経路は成立しにくくなります。

「アプリの通信だけは素通しになっている」でもありません。 Androidの開発者向けドキュメントには、Android 9（APIレベル28）以降、平文（cleartext）通信のサポートが既定で無効になっており、平文通信を必要とするアプリは明示的にオプトインする必要がある、と記載されています（出典: Google「Network security configuration」Android Developers https://developer.android.com/privacy-and-security/security-config 、2026年8月7日確認）。アプリごとの実装まで当編集部が確認したわけではありませんが、少なくとも「アプリだからブラウザより危ない」という一般化は、この既定値と噛み合いません。HTTPSで保護されている通信については、アプリでもブラウザでも同じことが言えます。

「Wi-Fiでパスワードが抜かれた」とされる事例の多くは、回線の盗み見ではなく、偽サイトへの入力、使い回していたパスワードの流用、端末に入っていたアプリ経由といった別の経路で説明できます。原因を回線に決めつけると、実際に手当てすべき場所を外します。

そして数字について。当編集部が探した範囲では、日本で「公衆Wi-Fiの利用に起因する被害」だけを切り出した公的な件数統計を確認できませんでした。 確認できていない以上、件数は書きません。「年間◯件の被害」という数字を見かけたら、その出典と調査対象の定義を確かめてください。

Wi-Fiを提供している側から、何が見えて何が見えないか

対照で並べます。いずれも上記の出典から導かれる範囲の整理で、当編集部が機材で測定した結果ではありません。

見え得るもの: 接続してきた端末の識別子（Appleは、プライベートWi-Fiアドレスがランダム化されたMACアドレスを使うことでネットワーク側の追跡を防ぐと説明しています。出典: Apple「Use private Wi-Fi addresses on Apple devices」https://support.apple.com/en-us/102509 、2026年8月7日確認）／接続時刻と接続時間／通信量／条件が揃わない場合の接続先ドメイン／暗号化されていない通信の中身。

見えにくいもの: HTTPSで保護されたページの中身（入力値・本文・ファイル）／保護された通信の中で送受信したメッセージ。

なお、暗号化のかかっていない（オープンな）アクセスポイントでは、Wi-Fiの区間そのものに暗号がかかっていないため、電波の届く範囲にいる第三者が通信を傍受し得る、というのが総務省の説明する構図です（前掲、総務省「安全な無線LANの利用」）。ただしこれは「Wi-Fiの区間に暗号がない」という話であって、その上を流れるHTTPSの通信の中身まで読めるという話ではありません。暗号のかかっていないアクセスポイントで実際に露出するのは、暗号化されていない通信と、上に挙げた見え得る項目です。 ここを混ぜると、オープンなWi-Fiにつないだ瞬間にすべてが見えるという誤った像になります。

お金をかけずに先にできること

順番に意味があります。上から順に、効果に対して手間が小さいものです。

1. ブラウザのHTTPS優先設定を入れる。 Chromeには「Always use secure connections」という設定があり、Googleはこれを有効にするとURLをHTTPSにアップグレードし、対応していないサイトを訪問する前に警告を表示すると説明しています（前掲、Google「Manage Chrome safety and security」）。Firefoxには HTTPS-Only Mode があり、Mozillaは、この機能が全サイトへ安全な接続を試み、安全な接続に対応していないサイトへつなぐ前に利用者の許可を求めると説明しています（前掲、Mozilla Security Blog）。どちらもブラウザの設定画面から切り替えられますが、設定項目の名称と場所は版によって変わるため、本稿では画面の遷移手順までは書きません。 手順を確認したうえで書く記事は別に用意します。
2. 共有設定を切る。 総務省が公共の場での対策として挙げている項目です（前掲）。
3. 自動接続をやめる。 一度つないだSSIDに自動で再接続する設定のままだと、同じ名前を出しているだけの別のアクセスポイントにも自動でつながり得ます。よく行く場所以外は「自動接続」を外しておくと、接続のたびに自分で選ぶ形になります。
4. ブラウザの証明書警告を踏み越えない。 前節のとおり、ここが中身の露出につながる入口です。判断材料としてその場で得られる数少ない情報でもあります。
5. OSとブラウザを更新しておく。 「端末への不正アクセス」の前提条件のひとつを外します。

ここまでで、多くの人にとっての実務的な部分は終わりです。この5つを済ませた状態なら、公衆Wi-Fiのために追加でお金を払う必要は、多くの使い方では出てきません。

VPNは何を「消す」のか — 実際には「移す」

そのうえでVPNに触れます。VPNを使うと、接続先のドメインやDNSの問い合わせが、その場のWi-Fi提供者や回線事業者から見えにくくなります。ただし、これは見える相手がいなくなるのではなく、見える相手がWi-Fi提供者からVPN事業者へ移るという構造です。ここを「消える」と説明している記事があれば、構造をひとつ飛ばしています。

そして、移った先の事業者が実際に何を保持していないかは、当編集部に検証する手段がありません。 事業者が「接続ログを保持しない」と表明していれば、それは表明という事実として扱えますが、その表明が実際に守られているかを外部から確かめる方法を当編集部は持っていません。この記事では特定の事業者の表明を引用していません（検証不能）。

効かない範囲も明確です。偽サイトに自分で認証情報を入力してしまう経路、アカウントにログインした状態でサービス側に残る記録、端末そのものに入っているアプリ経由の経路。ここにVPNは効きません。VPNが本当に効いているかを自分で確かめる方法は別記事にまとめています「VPNが本当に効いているか、自分で確かめる4つのチェック」。必要だと判断した場合の選び方は、要る人の条件から書いたページがあります「【hub】通信を暗号化する目的で選ぶVPN — 要る人の条件から」。

自分に要るのかどうかを先に決めたい場合は、こちらから読んでください。「要らない場面」から書いています。「VPNは必要か。まず「要らない場面」から書く」

この記事で検証したこと・していないこと・検証できないこと

検証済み: この記事にはありません。 当編集部の機材による測定は行っていません。証明書警告の再現も撮影も行っていないため、警告画面の実物のスクリーンショットは掲載していません。本文に書いたのは、公式ヘルプページに置かれている説明を確認日時点で読み取ったものです。

未検証: 本文に引いた仕様・数値・既定動作は、いずれも本文中にURLと確認日を付けた公開ドキュメントに記載されている内容で、当編集部の端末で1項目ずつ挙動を確認したものではありません。Chrome 147・Chrome 154の計画が予定どおり実施されたかも確認していません。Androidの平文通信の既定値についても、個々のアプリの実装までは確認していません。ブラウザの設定画面の遷移手順は、画面を確認していないため本稿では書いていません。日本国内での公衆Wi-Fi利用に起因する被害の件数統計は、当編集部が探した範囲では確認できませんでした。

検証不能: VPN事業者をはじめとする通信事業者が、自社の設備内部で実際に何を保持し、何を保持していないか。外部から確かめる手段を当編集部は持っていません。同様に、特定の施設が出しているアクセスポイントが本物かどうかを、接続前に外側から判定する方法も持っていません。

本記事の内容は、記載の確認日時点で当編集部が確認できた情報にもとづいています。仕様・既定動作・提供条件は、事業者の判断により予告なく変更されることがあります。設定の変更や契約の前に、事業者の公式ページで最新の情報をご確認ください。

本記事は情報提供であり、個別の状況に対する助言ではありません。また、法律に関する助言を行うものでもありません。金銭に関する被害が生じている場合、または生じるおそれがある場合は、消費者ホットライン 188 へご相談ください。緊急でない犯罪・トラブルの相談は、警察相談専用電話 #9110 で受け付けられています。緊急の危険があるときは 110番 です。