iCloud Private Relay が実際の IP アドレスを漏らしている

macOSTahoe ·
iCloud Private Relay が実際の IP アドレスを漏らしている

iCloud Private Relay を有効にしていても Web サイトが実際の IP を取得できる 3 つの経路が見つかりました。漏洩の仕組み、テスト方法、そして今すべきことを解説します。

あなたが iCloud Private Relay をオンにした理由はひとつでしょう。アクセスしたサイトに、自分がどこから接続しているかを知られたくないからです。それこそがこの機能の売り文句そのものです。Apple は Safari の通信を 2 段のホップで中継し、どの当事者も——インターネットプロバイダも、Web サイトも——あなたの身元と接続先を結びつけられないようにしています。ところが、ある特定の種類のリクエストについては、その約束が守られていません。

2026 年 8 月 4 日、セキュリティ研究者の Tommy Mysk 氏と Talal Haj Bakry 氏が、Private Relay がオンで正常に動作している状態でも Web サイトがあなたの実際の IP アドレスを取得できることを示す調査結果を公開しました。報道は 8 月 5 日に続き、MacRumors、9to5Mac、TechCrunch、The Hacker News などが取り上げています。漏洩経路は 3 つあり、それぞれ仕組みとしては互いに無関係で、そのうち最も鋭い一撃はパスキーに関わるものです。パスキーは、Apple がパスワードのより安全な代替として何年もかけて推進してきたログイン技術にほかなりません。

本記事では、Private Relay が実際に何を約束しているのか、研究者が何を実証したのか、3 つの漏洩がそれぞれどう機能するのか、自分の Mac でどうテストするのか、そして本当にやる価値があるのは何かを順に見ていきます。何よりも先に範囲について一言。これはネットワーク上の身元の漏洩であって、ブラウジング内容やアカウントの漏洩ではありません。誰かが暗号化された通信を読んでいるわけではありません。誰かが iCloud に侵入しているわけでもありません。漏れているのは IP アドレスであり、それが自分にとって問題かどうかは、あなたが誰であり、誰が見ているかで完全に決まります。

要点

  • 3 つの独立した経路、ひとつの結末。 Mysk 氏と Haj Bakry 氏は、WebAuthn／パスキーのセレモニー、DNS プリフェッチ、WebTransport のいずれもが、Private Relay 有効時に実際の IP アドレスを Web サイトへ露出させうることを実証しました。これらは互いに独立したバグでありながら、同じ失敗へ収束しています。
  • パスキーの漏洩は、パスキーを持っていなくても起きる。 研究者によれば、サイトはセレモニーを 開始 しさえすればよく、パスキーを使うサイトも、使うふりをするだけのサイトもリクエストを発生させられます。あなたが何かをクリックしたり、ログインを完了したりする必要は一切ありません。
  • これは IP 漏洩であって、侵害ではない。 ブラウジングの暗号化された内容が露出することはなく、アカウントが侵害されたわけでもなく、CVE も割り当てられていません。露出するのはネットワーク上の身元、つまり実際のアドレスと、DNS のケースでは実際のリゾルバです。
  • Apple は調査中で、現時点で修正は存在しない。 Apple は 404 Media に対し、報告内容を調査していると述べました。9to5Mac は、Apple から研究者へ送られたステータスメッセージが問題に対処する方針を示しており、修正は 2026 年秋を目標としていると報じています。MacRumors はこの問題を、WebKit の動作そのものに織り込まれたものと表現しました。
  • Private Relay をオフにするのは誤った対応。 この機能はネットワーク上の受動的な観測者に対して、いまも実質的な仕事をしています。現実的な脅威モデルを抱える人にとっての妥当なアップグレードは本物の VPN ですが、信頼の預け先を Apple から VPN 事業者へ移すというトレードオフは正直に受け止める必要があります。

iCloud Private Relay とは実際に何であり、Apple は何を約束しているのか

漏洩を評価する前に、そもそも何が漏れている「約束」なのかを正確に押さえておくと役立ちます。というのも、この件をめぐる混乱の多くは、Private Relay をそもそも売り出されていないものとして期待している人たちから生じているからです。

iCloud Private Relay は iCloud+ の機能です。つまり、OS に付属するのではなく、有料の iCloud ストレージプランに付いてきます。Apple の位置づけは一貫していて、かなり限定的です。あなたの IP アドレスとブラウジング行動を、ネットワーク事業者と訪問先の Web サイトから隠すために設計されている、というものです。それが約束の内容です。「Mac 上のすべてを暗号化します」でもなければ、「あなたを匿名にします」でもありません。

2 ホップ設計

アーキテクチャこそがこの機能の面白いところで、実際によく考えられています。Private Relay が有効なとき、Safari からのリクエストは目的のサーバーへ直接届きません。2 つのプロキシを順に経由します。

1 番目のホップである イングレスプロキシ は Apple が運用します。Apple はあなたが誰かを知っています——なにしろ iCloud アカウントにサインインしていますし、デバイスは特定のネットワークから接続しています。Apple が得られないのは接続先です。訪問先サイトのアドレスは、イングレスプロキシが読めない形で暗号化されています。

2 番目のホップである エグレスプロキシ は、Apple ではなく第三者のコンテンツ配信パートナーが運用します。実際に目的の Web サイトと通信するのはこのプロキシです。どこへ向かうかは知っていますが、あなたが誰かは知りません。元の IP アドレスも iCloud の身元も見ておらず、リクエストは Apple のイングレスプロキシから受け取っているからです。

結果として生まれるのは、意図的な知識の分割です。どちらの当事者も、機微な組み合わせの両方を持ちません。Apple は「誰か」を知るが「どこか」は知らない。パートナーは「どこか」を知るが「誰か」は知らない。連鎖の末端にある Web サイトが見るのは、あなたのアドレスではなくエグレスプロキシのアドレスです。さらに Apple は、サイトに見えるアドレスが大まかにあなたの地域と一致するようにする、粗い位置情報の設定も用意しています。ピンポイントで特定されることなく、ローカル検索結果やニュースが役立つようにするためです。

これは多くの人が思っているよりよくできた設計であり、すでに iCloud ストレージに課金しているなら追加費用は実質ゼロです。プラットフォームの他の保護機能との関係を含めて広く見渡したい場合は、macOS Tahoe セキュリティ・プライバシー完全ガイド が周辺機能を扱っています。

決定的な前提：これは VPN ではない

漏洩を理解するうえで肝心なのがここです。Private Relay は VPN ではありませんし、Apple も VPN だと説明したことは一度もありません。

VPN は、適切に設定されていればネットワーク層で通信を捕まえます。マシン上のすべてのアプリ、すべてのプロトコル、すべてのソケット——OS のルーティングテーブルがそちらへ送るので、すべてがトンネルを通ります。VPN が重く、いろいろなものを壊し、ときにカーネル機能拡張やシステムネットワーク機能拡張を必要とするのはそのためです。

Private Relay の適用範囲はもっと狭く、カバーするのは次のものです。

  • Safari のブラウジング通信。 これが看板となるユースケースです。
  • DNS 解決。 DNS クエリはリレー経由で送られることになっており、リゾルバがあなたの訪問先の記録になってしまうのを防ぎます。
  • 暗号化されていないアプリ通信の一部。 アプリが発行する非セキュアな HTTP リクエストは、堅牢化策としてリレーに取り込まれます。

これが境界線です。Chrome の通信はここを通りません。メールクライアントの通信も通りません。サードパーティ製アプリの暗号化された通信も通りません。アプリケーションが独自のネットワークスタックで独自の接続を開くなら、Private Relay はその経路にはいませんし、いると主張したこともありません。

この区別は些末な技術論ではなく、今回の発見を評価するための枠組みそのものです。研究者が見つけた 3 つの漏洩のうち 2 つは、あるレベルでは、Private Relay が引いた境界線からリクエストが抜け出した事例です。バグは境界線が存在することではありません。バグは、ユーザーが「Safari でのブラウジング」として体験しているものから生じたリクエストが、何の合図もないまま、目に見えない形で境界の外へ出てしまうことです。

研究者が見つけたもの

Tommy Mysk 氏と Talal Haj Bakry 氏にとって、この種の仕事は初めてではありません。両氏は Apple プラットフォームのプライバシー上の主張を丹念に解体してきた実績があり、マーケティング上の説明と実装の隔たりが誰の予想より大きいことをたびたび見つけ出しています。やり方は一貫しています。実証を組み立て、公開し、プレスリリースではなく成果物そのものに語らせる、というものです。

Private Relay に関する両氏の調査結果の日付は 2026 年 8 月 4 日 です。報道はその翌日の 8 月 5 日 に、MacRumors、9to5Mac、TechCrunch、The Hacker News などの媒体で出ました。

主張の核心を平易に言えば、iCloud Private Relay が有効でも、Web サイトはあなたの実際の IP アドレスを取得できる ということです。先に攻撃を受けている必要があるような特殊なサイドチャネル経由でもなければ、こちら側の設定ミスを突くものでもありません。どのサイトでも呼び出せる、ごく普通の Web プラットフォーム機能を通じて起こります。

3 つの経路は次のとおりです。

  1. WebAuthn／パスキー。 パスキーによるログインが発するネットワークリクエストは、Safari ではなく OS の資格情報サービスが発行するため、プロキシ経路に入りません。
  2. DNS プリフェッチ。 OS 26 世代で追加されたパフォーマンス機能で、ユーザーの実際の DNS リゾルバを明かしてしまいます。
  3. WebTransport。 26.4 世代で追加された新しいトランスポート API で、プロキシを迂回する直接的な HTTP/3 接続を開くことがあります。

露出するのは Safari および WebKit ベースのブラウジング です。iOS では、大半の法域で依然としてすべてのブラウザが内部で WebKit を使うことが求められているため、代替ブラウザも影響を受けます。Safari から別の iPhone ブラウザへ乗り換えても、実際に処理しているエンジンは変わりません。Mac では事情が異なります。露出の中心は Safari と、アプリ内ブラウジングのために WebKit を埋め込んでいるアプリであり、Chrome や Firefox のような非 WebKit ブラウザは独自のエンジンと独自のネットワークスタックを使います。これは Mac ユーザーにとって意味のある違いであり、それが何をもたらし、何をもたらさないかは後ほど改めて扱います。

報じられている Apple の反応は次のとおりです。同社は 404 Media に対し、報告内容を 調査中 だと述べました。9to5Mac は、Apple から研究者へ送られたステータスメッセージが、報告された問題に対処する方針を示しており、修正は 2026 年秋 を目標としていると報じています。Apple に公に帰属させられているのはここまでです。特定のリリースは挙げられておらず、出荷日が Apple によって公に確認されたこともなく、3 つの経路のいずれにも CVE は割り当てられていません。

現時点で修正は存在しません。 MacRumors はこの問題を、WebKit の動作そのものに織り込まれたものと表現しました。修正がひとつの関数へのパッチではなく、どのサブシステムがネットワークリクエストを所有するのかという再考を要する種類のバグを言い表すには、妥当な表現です。

パスキー経路を正しく理解する

3 つのうち、詳しく理解する価値があるのはこれです。最も意外で、最も避けにくく、最も居心地の悪い含意を持つからです。

WebAuthn のセレモニーとは実際に何か

パスキーは、公開鍵認証のための Web 標準である WebAuthn の上に構築されています。多くの人が抱くイメージはおおむね正しいものです。サーバーへパスワードを送る代わりに、デバイスが秘密鍵を保持し、サーバーが対応する公開鍵を保持し、ログインとはチャレンジに署名して秘密鍵を制御していることを証明すること。使い回せるものは通信路を渡りません。パスキーのフィッシングはパスワードのフィッシングのようには成立しません。署名がオリジンに紐づいているからです。

これを成し遂げる一連の手順は セレモニー と呼ばれます。サイトの JavaScript がブラウザを呼び出し、ブラウザがプラットフォームに資格情報の生成または検証を依頼し、あなたが Touch ID かデバイスのパスコードでローカルに認証し、署名済みのアサーションが返ってきます。Apple プラットフォームでは、資格情報そのものは「パスワード」App に置かれ、iCloud キーチェーン経由で同期されます。Apple がその方面をどう作り込んできたかという広い文脈は、「パスワード」App と自動パスワード変更 の記事で取り上げています。

ほとんど誰も意識しないのは、セレモニーが純粋にローカルで完結するわけではないという点です。その一部にはネットワーク越しのデータ取得が含まれます。リライングパーティの設定情報、サイトのドメインとそれを扱える資格情報を結びつける関連付けデータなどです。それを取得するために、何かが HTTPS リクエストを発行しなければなりません。

そのリクエストを発行するのは誰か

ここで話がおかしくなります。研究者の説明に関する報道を引用します。

WebKit は WebAuthn のセレモニーを OS の資格情報サービスに引き渡し、そのサービスがホストアプリの設定したプロキシを一切認識しないまま、デバイスから直接 HTTPS リクエストを自ら発行する。

一語一語が意味を持っているので、注意して読んでください。WebKit はセレモニーを自分で実行せず、資格情報を所有するシステムサービスへ委譲します。そのサービスは自前で外向きの HTTPS リクエストを発行します。そして決定的なのは、ホストアプリの設定したプロキシを一切認識しない ことです。資格情報サービスは、Safari が通信を Private Relay の 2 ホップ経路へ流すよう設定されていることを知りませんし、気にもしません。別のネットワーク設定を持つ別のプロセスが、設計どおりのことをしているだけです。

その帰結も、同じく報道から引きます。

フェッチを発行するのは Safari ではなく OS の資格情報サービスであるため、それが Private Relay のプロキシ経路に入ることはない。

つまりリクエストは、あなたのデバイスから、あなたの実際の IP アドレスから、Web サイトが管理するサーバーへ直接出ていきます。サイトはその接続を見ます。アドレスを記録します。Private Relay はその間ずっと動いていて、単にその経路にいなかっただけです。

アーキテクチャの観点からは、誰も不注意でなかったのにこうなった経緯が見えてきます。資格情報の扱いはブラウザから隔離される べき です。その分離は誤りではなくセキュリティ上の性質です。任意の Web サイトから来る信頼できない JavaScript を実行するプロセスから鍵素材を遠ざけるのは、まさに正しい判断です。問題は、その分離がセキュリティのために引かれた一方で、プライバシーの境界を引き直した人が誰もいなかったことです。資格情報サービスはプロセス分離を受け継ぎましたが、プロキシ設定は受け継ぎませんでした。

最も鋭い点：パスキーを持っている必要すらない

ここが、興味深いアーキテクチャの話を実際のプライバシー問題へと変える細部です。

研究者は、これが パスキーを使うサイト、あるいは使うふりをするだけのサイト で発火すると指摘しています。サイトは、あなたがログインを完了しなくてもセレモニーを起動できます。そのサイトのパスキーを持っている必要はありません。アカウントを持っている必要すらありません。ログインボタンを押す必要も、Touch ID のプロンプトを承認する必要も、何かを操作する必要もありません。

ページが API を呼び出せば、ネットワークリクエストが発生します。セレモニーが最終的に成功するか、失敗するか、放棄されるかは漏洩とは無関係です。漏洩は認証ロジックが問題になる前の、フェッチの時点で起きるからです。

これは機能の意味を反転させます。WebAuthn は認証をより安全にするために存在します。ところがこの構成では、認証機構を呼び出したという事実そのものが、どのページでも静かに、読み込み時に引ける匿名化解除のトリガーになります。トラッカーは何かを侵害する必要すらありません。誰も完了しないセレモニーを開始するスニペットを埋め込むだけで、そのページを読み込んだすべての Private Relay ユーザーの実際の IP を集められます。

これが起きるとき、ユーザーに見える合図は何もありません。プロンプトも、許可シートも、ツールバーのインジケータもありません。資格情報のセレモニーを開始することは無害な行為だ、というのが設計上の前提であり、通常の状況ではそのとおりなのです。

パスキー認証フローのイラスト

DNS プリフェッチ経路

2 つ目の漏洩は影響としては小さいものの、まったく別のサブシステムで同じ根本パターンが現れることを示しており、示唆に富んでいます。

プリフェッチは何のためにあるのか

Web ページの読み込みは、依存関係のあるルックアップの連鎖です。ブラウザは HTML を取得し、あるドメインのスタイルシート、別のドメインのフォント、3 つ目のドメインの解析スクリプト、4 つ目のドメインの画像を参照していることを見つけます。それぞれのドメインは接続を開始する前に DNS 解決を必要とし、DNS 解決には時間がかかります。うまくいって数十ミリ秒、モバイル回線の状態が悪ければもっとかかります。

DNS プリフェッチはこれに対する素直な最適化です。ブラウザがまだページを解析している間に、参照されているリンクやリソースを先読みし、それらのホスト名をあらかじめ解決しておきます。パーサーが実際に接続を必要とする地点に到達するころには、アドレスはすでにキャッシュされていて接続がすぐ始まります。ページ読み込み指標の実測値に効いてくる類の変更であり、だからこそブラウザのエンジニアはこの種の機能を追加し続けます。

この実装が登場したのは OS 26 世代、つまり Apple の各プラットフォームにおける Tahoe 世代のリリースです。

何が露出するのか

研究者は、これらのプリフェッチクエリが ユーザーの実際の DNS リゾルバ を明かしてしまうことを発見しました。

通常の Private Relay 動作では、DNS はリレーがカバーする対象に含まれているはずです。これは意図的かつ重要な点です。もしクエリが平文で ISP のリゾルバへ届いてしまえば、ISP はあなたが引いたすべてのドメインのタイムスタンプ付き一覧を保持することになり、実際の通信がどれだけよく暗号化されていようと、それはほぼ完全なブラウジング履歴です。Private Relay の存在意義の大部分は、まさにそのつながりを断つことにあります。

プリフェッチのクエリがその経路から抜け出すと、クエリはデバイスに実際に設定されているリゾルバへ向かいます。通常は現在のネットワークで DHCP から渡されたリゾルバであり、たいていは ISP、勤務先、あるいは接続中の Wi-Fi の運営者を意味します。

ここで漏れるものは、生の IP アドレスより狭い範囲です。観測者が知るのはあなたが使っているリゾルバであり、これはどのネットワークにいるか、そしてしばしばどの事業者のサービスを受けているかについての強い手がかりになります。他の手がかりと組み合わされればフィンガープリントに寄与します。また、本来はそのリゾルバの運営者から遮蔽されるはずだったルックアップが、当人に見えてしまうことも意味します。

パスキー経路より小さな問題であり、得られる手がかりも粗いものです。それでも無害ではありません。トンネルを使いながら macOS の DNS 挙動と格闘した経験があれば、この一部には見覚えがあるでしょう。システムリゾルバとプロキシ経由の通信の相互作用は混乱の絶えない原因であり、macOS VPN トラブルシューティング完全ガイド がこの種の問題の一般的な形を扱っています。

WebTransport 経路

3 つ目の漏洩は 3 つの中で最も新しい技術に関わるもので、構造的な問題を最も明快に示しています。

WebTransport は何のためにあるのか

WebTransport は、ブラウザとサーバーの間で低遅延の双方向通信を行うための現代的な Web API です。WebSocket の後継で、TCP ではなく HTTP/3 と QUIC の上に構築されている、と考えるとよいでしょう。

これが存在する理由は、リクエスト／レスポンスより優れた何かを必要とする Web アプリケーションが相当数あるからです。マルチプレイヤーゲームは状態を絶えず送り続ける必要があり、遅延よりは時折の更新の取りこぼしのほうが許容できます。ライブ映像・音声アプリケーションも同様です。共同編集エディタ、リモートデスクトップツール、リアルタイムのテレメトリダッシュボード——いずれもオーバーヘッドの小さい持続的なチャネルと、信頼性が遅延コストに見合わない場面で信頼性なしのデータグラムを送れる能力を求めています。

WebTransport は QUIC の上で動くことでそれを実現します。QUIC は UDP ベースのトランスポートで、暗号化が組み込まれており、ストリーム間のヘッドオブラインブロッキングがありません。解こうとしている問題に対して、これは実に優れたエンジニアリングです。

Apple の実装が登場したのは 26.4 世代 です。

直接的な HTTP/3 接続がプロキシを無力化する理由

Private Relay のプロキシ処理は、Safari の通常のネットワーク経路が生み出す従来型の Web 通信、そのリクエストパターンを前提に組み立てられています。それらは 2 ホップのイングレス／エグレス連鎖を通ります。

研究者は、WebTransport がプロキシを迂回する 直接的な HTTP/3 接続 を開きうることを発見しました。デバイスから宛先サーバーへ直接その接続が確立されてしまえば、サーバーはプロキシを介さないあらゆる接続と同じように、デバイスの実際のアドレスを見ることになります。

ここでのパターンは、関係するコードがまったく無関係であるにもかかわらず、パスキーの事例と同一です。プラットフォームに新しい機能が追加される。その機能はネットワーク接続を開く。プロキシ層は、新しい機能より前の「ネットワーク接続とは何か」というモデルに基づいて作られている。両者を結ぶものは何もなく、新しい機能は静かに境界の外側で動作する。

MacRumors の枠づけ——問題は WebKit の動作そのものに織り込まれている——が単なる修辞以上のものである理由がここにあります。エンジンの進化は、ネットワークと会話できるサブシステムを増やし続けます。すべてがそこを通らざるをえないレベルでプロキシ境界が強制されない限り、新しいサブシステムはどれも同じバグの候補です。特定の 3 つの漏洩を直したところで、それだけでは 4 つ目を防げません。

自分の Mac でテストする方法

研究者は公開のテストツールを用意しました。読者の視点から見て、今回の公表で最も有用なのがこれです。誰かの言葉を鵜呑みにする必要はありません。

ツールの場所は https://leaks.psylo.app/ です。

テストの実行手順

  1. まず Private Relay がオンであることを確認する。 リレーが動いていなければ漏洩をテストする意味がありません。システム設定を開き、サイドバー上部の Apple アカウントをクリックし、iCloud、そして Private Relay を選び、有効になっていることを確認します。不確かなら、Private Relay の状態確認のセクションへ先に進んでください。この機能は多くの人が思っている以上の頻度で勝手にオフになります。
  2. リレー経由の IP がどう見えるはずかを控える。 リレーをオンにした Safari で「what is my IP」系のサービスを開くと、自分のものではなく Apple のエグレスパートナーに属するアドレスが表示されます。それが基準です。サイトに見えるはずのアドレスということです。
  3. Safari でテストページを開く。 macOS では経路が WebKit 固有なので、必ず Safari を使ってください。ツールが各種チェックを実行し、あなたの接続について観測できた内容を報告します。
  4. 結果を比較する。 クリーンな結果とは、テストした各経路でツールが観測したアドレスがリレー経由のアドレスと一致している状態——プロキシが持ちこたえた、ということです。漏洩の結果とは、少なくともひとつの経路がリレー以外のアドレスを露出させた状態であり、そのアドレスはあなたのものです。
  5. 気になるネットワークごとにテストする。 自宅のネットワーク、社内ネットワーク、公衆 Wi-Fi では結果が異なりうるもので、その一因は Private Relay 自体の利用可否がネットワークによって違うことにあります。

正直な留保

テストツールが教えてくれるのは、そのツールが実装している経路についてだけです。あらゆる可能性のある経路について教えてくれるわけではありません。

これは通常の免責事項以上に重要で、理由は前述の構造的な論点にあります。根本の問題が「新しい WebKit のサブシステムがプロキシ境界の外でネットワーク接続を開けること」なのだとしたら、経路の集合は固定されていません。それは「これまでに発見された分」でしかないのです。3 つを調べるツールでクリーンな結果が出たということは、そのテストで、そのネットワークで、その瞬間に、その 3 つが漏れなかったという意味です。知らないままでいるよりは有意に良い。しかし匿名性の証明書ではありません。

このテストは、あらゆる否定的なセキュリティ結果と同じように扱ってください。特定の一群の問題について証拠がなかったということであって、一般に問題が存在しないことの証拠ではありません。

今すぐ実際にできること

インストールできる修正はありません。以下は、実際にどれだけ効くかでおおよそ順位づけしたもので、各項目にはその代償も添えてあります。代償を明かさない緩和策は、助言ではなく売り込みだからです。

1. 脅威モデルが正当化するなら本物の VPN を使う

これは報道で挙げられている緩和策であり、このリストの中で唯一、問題を正しい層で扱う選択肢です。適切に設定された VPN はネットワーク層で通信を捕まえます。これら 3 つの経路が動作する地点より下の層です。資格情報サービスの HTTPS リクエストも、プリフェッチの DNS クエリも、WebTransport の QUIC 接続も、すべて OS のネットワークスタックを通り、システムレベルの VPN はそのすべての下に位置します。

トレードオフは現実のもので、実行に移す前に声に出して言うべきです。あなたは信頼の預け先を Apple から VPN 事業者へ移している のです。Private Relay の 2 ホップ設計は、単一の当事者があなたの身元と接続先の両方を見ないよう、あえてそう構成されています。従来型の 1 ホップ VPN にはその性質がありません。VPN 事業者は両方を見ます。あなたは事業者のログ方針、法域、運用上のセキュリティ、そして誠実さに賭けており、Apple のアーキテクチャと違って、その賭けは設計によって担保されていません。プライバシーポリシー上の約束によって担保されているだけです。

これは VPN に反対する論ではありません。意図をもって選ぶべきだという論です。独立監査を受けていること、法域が明確であること、そしてビジネスモデルがあなたのデータに依存していないこと。この道を選ぶなら、設定上の癖にしばらく時間を取られる覚悟をしてください。macOS VPN トラブルシューティング完全ガイド が、とりわけ macOS で人がつまずく失敗パターンを扱っています。

2. Private Relay をオフにしない

これは最もありがちな反射的行動で、しかも逆効果です。

Private Relay は受動的な観測者に対していまも実質的な仕事をしています。リレーを通っているぶんの DNS クエリから、ISP がブラウジング記録を組み立てることは依然としてできません。喫茶店の Wi-Fi の運営者は、依然としてあなたの訪問先を覗けません。Safari の通信の大半はいまもプロキシ経由で、訪問先サイトからあなたのアドレスを隠し続けています。漏洩は抜け出す特定の経路であり、しかもサイト側が能動的に試みる必要があります。ページがパスキーのセレモニーを呼び出すか、WebTransport を使うか、プリフェッチの挙動を誘発するか、です。

リレーをオフにしても、これらの漏洩はひとつも塞がりません。リレーがきちんと防いでいた露出をすべて呼び戻すだけです。何の見返りもなく、以前より確実にプライバシーの少ない状態に行き着きます。

3. どのサイトにセレモニーを開始させるか意識する

これは聞こえるほど強い助言ではないので、なぜそうなのかを正直に述べておく価値があります。

パスキー経路は操作なしで発火します。そもそも尋ねられていないセレモニーを断ることはできません。切り替えられる設定も、拒否できるプロンプトもありません。

手元に残るのは そもそもどのページを読み込むか の制御です。IP の露出が本当に問題になることをしているなら、開くページはどれも——リンクから辿り着いたページも、アプリ内ブラウザの埋め込みビューも——この経路を呼び出しうるページだと意識してください。これは区画化を支持する論拠になります。機微なブラウジングは、他のすべてと同じセッションではなく、意図して選んだ環境で行うということです。避けるべきサイトのチェックリストを作る論拠にはなりません。これを悪用するようなサイトは、そうと名乗るタイプではないからです。

4. ロックダウンモードがここで何をして何をしないかを理解する

ロックダウンモードは、標的型攻撃のリスクがあるユーザー向けの Apple の極端な保護設定です。ジャストインタイム JavaScript コンパイルをはじめとする各種の複雑な機能を含む、長い一覧の Web 技術を無効化します。存在しない攻撃面は悪用されえない、という考え方に基づいています。

ロックダウンモードが想定している層に自分が当てはまるなら、検討する価値はあります。個別のバグにパッチを当てるのではなく機能そのものを取り除くアプローチであり、取り除かれた機能は漏らしようがないからです。ただし論の運びには注意が必要です。ロックダウンモードは堅牢化の姿勢であって、これら 3 つの経路に対する的を絞った修正ではありませんし、報道のどれもがこれを本件の対処法として位置づけてはいません。すでに候補に当てはまる人が検討するに値するもの、と捉えてください。この特定の問題への答えではありません。また、ごく普通の Web ブラウジングの多くを壊しますが、それは設計どおりであり、Apple が一般利用に勧めていない理由でもあります。

5. ブラウザを乗り換えると何が起きるか——そしてどこでは何も起きないか

ここではプラットフォームが物を言います。

iOS では、ブラウザの乗り換えは役に立ちません。大半の法域は依然としてすべてのブラウザに WebKit をエンジンとして使うことを求めているため、インストールした代替ブラウザは同じエンジンの上に別のインターフェースを被せたもので、経路も同じです。iPhone の Chrome は Chrome のエンジンではありません。

Mac では、事情が本当に異なります。非 WebKit ブラウザは独自のエンジンと独自のネットワークスタックを使うため、これら WebKit 由来の特定の経路に関しては挙動が異なります。ただし、それが何をもたらし何をもたらさないかを注意深く見てください。そもそも Private Relay は Safari 以外のブラウザの通信をプロキシしません。macOS で Chrome や Firefox へ移ることは、リレーの内側に入ることではなく、リレーの外側へ完全に出ることです。漏洩を直したのではなく、保護を放棄したのです。それが改善になるのは、すべてをカバーする VPN と組み合わせている場合だけです。時間の大半を Safari で過ごしていて、そこからもっと引き出したいなら、誤った理由で断行するブラウザ移行より Safari パワーユーザーガイド のほうが注意を向ける価値があります。

これらのどれについても、自分に過剰な約束をしないでください。選択肢 2 から 5 は露出を減らすか、事態を悪化させないだけです。経路が動作する層で対処するのは選択肢 1 だけであり、しかもそれは信頼関係をひとつ別のものに置き換えることで成し遂げられます。

ネットワークプライバシーの層構造のイラスト

本当に気にすべきなのは誰か

プライバシーの話題は大騒ぎに報い、均衡感覚を罰しがちです。だからこそ、誰がどの程度影響を受けるのかを正確に述べておきましょう。

大半の人にとって、これは非常事態ではなく浸食である

普通の脅威モデルを持つ普通のユーザーなら、正直な評価はこうです。お金を払っている機能が、特定の状況で宣伝より働いていない。これは腹立たしく、Apple が直すべきことですが、あなたにとっての実際的な帰結はほぼゼロです。

実際に何が漏れるかを考えてみてください。あなたの IP アドレスが、それをわざわざ取りに来たサイトに渡ります。多くのサイトはすでに、はるかに優れた識別子をあなたについて持っています。ログインしているし、Cookie もあるし、ネットワークを移動すれば変わる IP アドレスよりずっと弁別力の高いブラウザフィンガープリントもあります。広告エコシステムにとって IP アドレスは補助的な手がかりであって、至宝ではありません。仮にこれを悪用している企業があるとすれば、それは Private Relay がそもそも止められない手段であなたを包括的に追跡している企業でしょう。

あなたが失うのは、あるはずだと信じる理由のあった多層防御の一枚です。それは正当な不満です。しかし生き方を変える理由ではありません。

行動すべき人

これを真剣に受け止めるべきなのは、脅威モデルに IP ベースの匿名化解除が実際に含まれている人たちです。具体的には次のとおりです。

  • 情報源と仕事をする記者。 記者と場所やネットワークとの結びつきそのものが機微な情報である場合です。
  • 活動家や組織者。 ネットワークアドレスがリスクを伴う現実の身元に対応づく環境にいる人たちです。
  • 特定の個人を避けている人。 ストーカー、暴力的な元パートナー、サイトやリンクを用意してそこに接続してくるものを読み取る技術的手段と動機を併せ持つ相手です。IP アドレスが本当に危険になるのはこのケースです。おおよその所在を推定でき、特定の人物が特定のリンクを開いたことを確認できてしまうからです。
  • 勤務先や所属機関に調べている内容を知られてはならない人。 とくにその機関が管理するネットワーク上にいる場合です。

これらのいずれかに当てはまるなら、そもそも正しい姿勢は Private Relay 単体ではありませんでした。適切に選んだ VPN か Tor、しかるべき区画化、そして便利機能はどれも壊れうるという前提です。今回の公表はその原則を変えるものではなく、思い出させるものです。Mac セキュリティ・プライバシーガイド 2026 が多層構成の作り方をより深く扱っており、露出をより広く減らすことを考えているなら、AI ツールをクラウドではなくローカルで動かす が同じ理屈をスタックの別の部分に適用しています。

中間の層

「自分には無関係」と「安全がこれにかかっている」の間に、残りのすべての人がいます。そこでの妥当な姿勢は行動ではなく較正です。Private Relay のカバー範囲は、多くの人が抱いているイメージより狭いのだと理解すること。VPN として扱うのをやめること。VPN ではありませんし、いまやその違いの具体的な実証があります。それでもオンのままにしておくこと。設計上の想定内の観測者に対しては依然として役立つからです。そして、身元を特定されると本当に困ることをしていると気づいたら、たまたま有効になっている道具に頼るのではなく、その仕事のために作られた道具に手を伸ばすことです。

そもそも Private Relay がオンかどうかを確認する方法

あなたが使っているネットワークの少なくともひとつで、いま Private Relay がオフになっていて、しかもそれに気づいていない可能性はかなり高いです。この機能はいくつかの状況で、たいした前触れもなく自ら無効になります。漏洩を心配する前に、リレーがそもそも動いているかを確認しておく価値があります。

主要な設定

Mac では次のとおりです。

  1. システム設定 を開きます。
  2. サイドバー上部の 自分の Apple アカウント をクリックします。
  3. iCloud を選びます。
  4. 一覧から Private Relay を見つけて開きます。
  5. トグルがオンであることを確認します。ついでに IP アドレスの位置情報 の設定も見ておきましょう。「一般的な位置情報を維持」は地域向けコンテンツを機能させ、「国またはタイムゾーンを使用」は見かけ上の位置をさらに広げます。

Private Relay がそもそも表示されない場合、通常の説明は有料の iCloud+ プランに入っていないことです。これは iCloud+ の機能であり、無料のストレージ枠には現れません。

ほとんど誰も知らないネットワークごとのトグル

これには本当に多くの人が引っかかります。Private Relay は、グローバル設定とは独立に、個々の Wi-Fi ネットワークごとに 別々の オン／オフ状態を持っています。

確認方法は、システム設定を開き、Wi-Fi へ進み、接続中のネットワークの隣にある 詳細 をクリックし、そこにある Private Relay の項目を探すことです。グローバル設定がオンでも、その特定のネットワークではオフになっていることがあります。

これは本当に便利な挙動です。リレーがないと動かない社内ネットワークだけオフにしつつ、全体としてはオンのままにできるからです。しかし同時に、「Private Relay をオンにした」と「Private Relay はいま動いている」が別の主張であることも意味します。テストで予期しない結果が出たネットワークでは、ネットワークごとの設定を確認してください。

静かに自ら無効になる経路

2 つのトグル以外にも、目立った警告なしにリレーを無効化する条件がいくつかあります。

  • 非対応のネットワーク。 Private Relay が依存するプロトコルやエンドポイントをブロックするネットワークがあります。その場合 macOS は通常、リレーなしでそのネットワークを使うか、接続しないかの選択を提示し、そのとき選んだ内容が保持されます。
  • 企業ネットワークと管理対象ネットワーク。 企業はしばしば意図的に Private Relay を無効化します。接続先アドレスを隠すプロキシは、ネットワークレベルのコンテンツフィルタリングや監視と本質的に相容れないからです。管理対象デバイスでは、構成プロファイルによって無効化され、ユーザー向けのトグルがまったく存在しないこともあります。
  • 国と地域の制限。 Private Relay はどこでも使えるわけではありません。Apple はいくつかの法域で利用できないことを確認しており、それらの地域では設定にかかわらず機能が単に動きません。
  • 携帯通信事業者の構成。 自社ネットワークでこれを無効化する構成を配信している事業者があります。
  • VPN や DNS 設定との競合。 システム VPN を動かしていると、一般に Private Relay は待機状態になります。VPN が先に通信を取るからです。カスタム DNS 設定や特定の DNS フィルタリングプロファイルも、これを無効化することがあります。

共通するのは、Private Relay が大きな音を立てて失敗するのではなく、開いたまま失敗するということです。動作を止めても、あなたはブラウジングを続けられます。便利機能の設計判断としては擁護できるものです——代替案は人々のインターネットを壊すことですから——が、それは定期的な確認だけが自分の実際の状態を知る手段だということを意味します。

修正はどのようなものでなければならないか

Apple が実際に何を作らなければならないのかを考えてみる価値はあります。報じられている時間軸がポイントリリースではなく数か月単位である理由が見えてくるからです。

浅い修正は、各経路を個別にパッチすることです。資格情報サービスにホストアプリケーションのプロキシ設定を認識させ、セレモニーのフェッチをそれに従って流す。プリフェッチの DNS クエリをリレーの DNS 経路の内側へ戻す。WebTransport の QUIC 接続をプロキシ連鎖経由にするか、リレーが有効なときは直接の確立を拒否する。的を絞った 3 つの変更、塞がれた 3 つの穴です。

それで報告された問題は直りますが、根本の状態は直りません。3 つすべてに共通するパターンは同じです。ネットワークへ到達できるサブシステムが、プロキシ境界を受け継がずに作られている。境界が、すべての下で強制されるものではなく、各サブシステムが自ら選んで従うものである限り、これは起き続けます。

より深い修正はアーキテクチャ上のものです。WebKit に隣接するあらゆるネットワーク経路が必ず通る層でリレーを強制し、新しい機能が「知らないから」といって迂回できないようにすることです。これは大きな変更で、何かを壊す現実的なリスクを伴い、セキュリティアップデートではなくメジャーリリースに載る類の作業です。さらに、本当にリレーできないリクエストをどう扱うかの明確な方針も必要になります。フェイルクローズで機能を壊すか、フェイルオープンで漏らすか。どちらの答えも心地よくなく、どちらを選ぶかはエンジニアリングであると同時に製品上の判断です。

3 つ目の要素は、おそらく最も価値のあるもので、ユーザーに見えるものです。リクエストがリレーの外へ出たときの何らかの合図です。いま、この機能は自らのカバー範囲について完全に沈黙しています。開いているページが完全にプロキシされたのか、部分的にプロキシされたのか、まったくされていないのかを知る術がありません。3 つの実装上の隙間を「約束が破られた」という物語へ変えたのは、この不透明さです。ユーザーには、動いている状態と動いていない状態の違いを観測する方法がなかったのですから。

2026 年秋のリリースで注目すべきこと

Apple から研究者へ送られたステータスメッセージに関する 9to5Mac の報道によれば、修正は 2026 年秋を目標としています。報じられているのはそこまでで、Apple は特定のリリースや日付を公に約束していませんし、保証として扱うべきでもありません。

もし何かが出荷されたら、確認する価値があるのは次の点です。

  • 3 つの経路すべてが対処されるのか、パスキーだけなのか。 見出しを取ったのはパスキー経路です。他の 2 つはより地味で、後回しにされる可能性も十分にあります。
  • 修正が的を絞ったものか、構造的なものか。 リリースノートがこれを直接述べることはまずありませんが、研究者が再テストして報告する可能性が高く、彼らのテストツールは他の誰もが独立に検証する手段を与えてくれます。
  • ユーザーに見える何かが登場するか。 ページ単位でのリレーのカバー状況を示す表示があれば、現在の沈黙に対する有意な改善になります。
  • Private Relay の適用範囲が説明し直されるか。 Apple がこの機能のカバー範囲に関する表現を引き締めるなら、それも示唆的です。解決が全面的にコードの問題ではなく、部分的には期待値の問題であることを意味するからです。

それまで状況は変わりません。漏洩は現実であり、リレーは受動的な観測者に対していまも有用な仕事をしており、その二つの隙間こそが、あなた自身が判断を下すべき場所です。

よくある問題のトラブルシューティング

Private Relay がグレーアウトしている、または見当たらない

問題: システム設定から自分の Apple アカウント、iCloud と進んでも、Private Relay が一覧にないか、トグルが反応しない。

解決策: 原因を順に潰していきます。まず、有料の iCloud+ プランであることを確認してください。Private Relay は無料枠には存在せず、項目がないことの最も一般的な説明がこれです。次に地域を確認します。この機能はいくつかの国で利用できず、提供されていない場所には表示されません。3 つ目に、その Mac が勤務先や学校の管理下にあるなら、システム設定の「一般」から「デバイス管理」を開いて構成プロファイルを探してください。組織はネットワークフィルタリングを無効化してしまうという理由で日常的に Private Relay を無効にしており、プロファイルレベルの制限はローカルでは上書きできません。4 つ目に、iCloud+ の契約を持つアカウントでサインインしているかを確認します。副次的なアカウントではないか、ということです。4 つすべてが問題なくてもトグルが反応しないなら、iCloud からサインアウトして再度サインインし、その後で再起動してください。

特定のネットワークでだけ Private Relay が勝手にオフになり続ける

問題: 自宅ではリレーが動くのに、オフィス、特定のカフェ、あるいは特定のホテルの Wi-Fi では一貫してオフになっている。

解決策: まずネットワークごとのトグルを確認してください。ほぼ必ずこれが原因です。システム設定を開き、Wi-Fi へ進み、そのネットワークの隣にある「詳細」をクリックして、そこの Private Relay 設定を探します。これはグローバルのスイッチとは独立していて、「このネットワークは Private Relay をブロックします」というプロンプトを、リレーなしで続行する選択で閉じたことがあれば、その選択はそのネットワークについて記憶されています。オンに戻して、接続がまだ機能するか見てください。ネットワークが本当にリレーをブロックしているなら再度プロンプトが出るはずで、その時点で古い設定ではなく上流のブロックだと分かります。とくに企業ネットワークはファイアウォールで意図的にブロックする傾向があり、クライアント側の回避策はありません。そうしたネットワークでアドレスのプライバシーが必要なら、ネットワークが許可している前提で、VPN が唯一の道です。

テストツールが漏洩を示したので、どうすべきか知りたい

問題: 研究者のツールを開いたところ、ひとつ以上の経路で実際のアドレスが見えていると報告され、次の一手を知りたい。

解決策: まず、これを侵害と解釈しないでください。漏洩という結果は、サイトがあなたの IP アドレスを知りうるという意味であって、何かが盗まれた・アクセスされた・侵害されたという意味ではありません。保護すべきアカウントも、変更すべきパスワードもありません。次に、その結果が経路によるものなのか、単にリレーがオフなだけなのかを確認します。グローバルとネットワークごとの Private Relay 設定を確認して再テストしてください。リレーが無効なら、あらゆる経路で実際のアドレスが表示されますが、それはまったく別の、簡単に直せる問題です。3 つ目に、リレーがオンであることを確認したうえで漏洩が続くなら、報告された挙動を再現できたということであり、ユーザー側で可能な修正はありません。自分の脅威モデルに基づいて判断してください。大半の人にとっての正しい対応は、記録に留めてそのまま続けることです。アドレスのプライバシーが本当に必要な人にとっては、先に述べた信頼のトレードオフを伴う VPN が利用可能な緩和策です。2026 年秋のアップデートがあったら再テストしてください。

Private Relay を使っているせいでサイトにブロックされる、または壊れる

問題: 銀行のサイトが読み込まれない、ストリーミングサービスに違う国にいると言われる、ストアの決済が失敗する、あるいはサイトが繰り返し CAPTCHA を出してくる。

解決策: これは、サイトがあなたのアドレスではなくエグレスプロキシのアドレスを見ているために起きます。そのアドレスが住宅回線として認識されないか、想定外の場所にジオロケーションされるか、フラグの立った共有レンジに属しているかのいずれかです。まず位置情報の設定から始めます。Private Relay のパネルで、より広い国レベルの選択肢になっている場合は「IP アドレスの位置情報」を「一般的な位置情報を維持」に切り替えてください。これで地理的な不一致の大半は解消します。それでも足りなければ、グローバルにではなくネットワークごとのトグルでそのネットワークだけリレーを無効にするか、その特定のサイトには別のブラウザを使ってください。ただし macOS の Safari 以外のブラウザはそもそもリレーの外側にあることを忘れずに。頑固なサイト 1 つのためにリレーをグローバルにオフにするのは過剰な補正で、戻すのを忘れるのが落ちです。

VPN と Private Relay が互いに競合する

問題: VPN に接続すると Private Relay が非アクティブと表示される、あるいは両者を併用すると DNS が壊れる、接続が失敗する、ブラウジングが使い物にならないほど遅くなる。

解決策: まず、これは大部分が想定どおりだと理解してください。システム VPN は Private Relay が見るより前のネットワーク層で通信を捕まえるため、macOS は VPN が有効なとき一般にリレーを待機させます。これはバグではありませんし、無防備になるわけでもありません。VPN はいまやリレーより厳密に広い範囲の通信をカバーしているからです。実務的な指針は、どちらか一方を選び、経路の所有権をそれに委ねることです。本記事で述べた理由で VPN を使っているなら、リレーが待機するのは正しい結果です。リレーが非アクティブと表示されるだけでなく実際に壊れているなら、よくある犯人は DNS 設定の競合、通信を部分的にしか捕まえない VPN クライアント、あるいは以前インストールした VPN のネットワーク機能拡張の残骸です。これ以上のデバッグに進む前に、システム設定で古い VPN 構成プロファイルを削除してください。古いプロファイルはこの種の問題の不釣り合いに大きな割合を占めています。

FAQ

これは私のブラウジング履歴が露出したという意味ですか？

いいえ。漏れるのは IP アドレス、つまりネットワーク上の身元であって、内容ではありません。ブラウジングの暗号化された内容は暗号化されたままで、どのページを読んだかについて、すでにあなたを識別しようとしていたサイトへ接続したという事実を超えて、これらの経路が明かすものはありません。アカウントの認証情報は関与しておらず、アカウントが侵害されたわけでもありません。

これを理由にパスキーの使用をやめるべきですか？

いいえ。パスキーは依然としてパスワードよりかなり安全です。フィッシング耐性があり、使い回せるものがネットワークを渡りません。今回の漏洩はパスキー認証そのものの弱点ではなく、セレモニーを支えるネットワークリクエストが Private Relay を迂回することにあります。パスキーを捨てるのは、現実のセキュリティ上の利得を、わずかなプライバシー上の利得と引き換えにすることになります。

これに CVE は割り当てられましたか？

3 つの経路のいずれについても CVE は報告されていません。調査結果は Mysk 氏と Haj Bakry 氏によって 2026 年 8 月 4 日に公開され、翌日に報道されました。Apple は 404 Media に調査中だと述べています。この問題について特定の CVE 識別子を挙げる情報源には警戒してください。公開されたものは存在しません。

Mac で Chrome や Firefox を使えば解決しますか？

多くの人が想定する意味では解決しません。それらのブラウザは独自のエンジンを使っており、これら WebKit 固有の経路の影響を受けませんが、そもそも Private Relay はそれらの通信をプロキシしていませんでした。乗り換えてもリレーの内側に入るのではなく、リレーから完全に外れるだけです。それが役立つのは、すべてをカバーする VPN と組み合わせた場合だけです。

iPhone と Mac では状況が違いますか？

はい。iOS では大半の法域がすべてのブラウザに WebKit の使用を求めているため、デバイス上のすべてのブラウザが同じ露出を共有し、アプリを変えても何も変わりません。Mac では、他のブラウザが独自のエンジンを積んでいるため、影響を受けるのは Safari と WebKit を埋め込むアプリだけです。経路そのものの振る舞いは、どちらのプラットフォームでも同じです。

Apple はいつ修正しますか？

9to5Mac は、Apple から研究者へ送られたステータスメッセージが、同社がこの問題に対処する方針であることを示しており、修正は 2026 年秋を目標としていると報じました。Apple は 404 Media に調査中だと認めた以外、特定のリリースや日付を公に約束していません。今日利用できる修正はなく、MacRumors はこの問題を WebKit の動作そのものに織り込まれたものと表現しています。

まとめ

Mysk 氏と Haj Bakry 氏の調査結果は現実のもので、十分に文書化されており、Apple が狭くパッチを当てるのではなくきちんと修正するに値します。3 つの独立した WebKit のサブシステム——パスキーのセレモニーを扱う資格情報サービス、DNS プリフェッチ、そして WebTransport——はいずれも、Private Relay が有効だと表示されたまま鎮座しているその横で、あなたの実際の IP アドレスを、それを探しに来た Web サイトの前に差し出しうるのです。3 つの中でパスキー経路が最も鋭いのは、サイトがセレモニーを開始するだけでよく、完了させる必要がなく、あなたから何も必要としないからです。

これが何でないか。侵害でも、アカウントの乗っ取りでも、うろたえる理由でもありません。Private Relay は VPN であったことはなく、そう主張したこともなく、止めるために作られた観測者——ISP、いま座っているネットワーク、サイトに能動的に探らせることはできないまま通信を見ている受動的な監視者——に対して、いまも作られた目的の仕事を果たしています。その保護は無傷であり、機能をオフにすることは何の見返りもなくそれを差し出すだけです。

これが何であるか。この機能のカバー範囲が多くの人の抱くイメージより狭いこと、そしてその境界が、新しいプラットフォーム機能が必ず従わなければならない場所のどこでも強制されていないことの、明確な実証です。誰かに IP アドレスを知られることが本当に脅威モデルに含まれているなら、答えは常に、その仕事のために作られた道具を、信頼のトレードオフを理解し受け入れたうえで使うことでした。そうでないなら、この件を頭に留め、リレーはオンのままにし、興味があればテストを走らせ、秋に何が出荷されるかを見守ってください。

関連記事: Mac セキュリティ・プライバシーガイド 2026