「プライバシー VPN はどれがいいか」という問いが尋ねているのは、実は回線数や速度の数字ではなく、3 つの点です。相手のノーログ方針を検証できるか、登録・支払いの段階でどの程度ひも付け可能な情報が残るか、そして公共 Wi-Fi のような信頼できないネットワークで受け止められるか。以下ではこの 3 点に分けて、それぞれ実行できる確認方法を示します。「信頼できます」という宣伝文句ではありません。

ノーログ方針の 3 つの言い方と確認手順

「ノーログ」はプライバシー系サービスで最も引用される言葉であり、最も情報量の少ない言葉でもあります。何を記録しないのか、どれくらい保持するのか、どのような形で保持するのかが示されなければ、この言葉は検証できません。その約束に価値があるかを見極めるには、まずログそのものを分類する必要があります。

3 種類のログを分けてから約束を語る

業界で言う「ログ」は少なくとも 3 種類を指します。混ぜて議論すると永遠に整理できません。

  1. 閲覧履歴ログ:アクセスしたドメイン、DNS クエリ、接続の開始・終了時刻。この類が最も機微で、その人の関心範囲を復元できてしまいます。
  2. 接続メタデータ:ログイン時刻、割り当てられた入口ノード、セッション時間、通信量。課金と障害対応に必要で、多くのサービスが一定期間保持します。
  3. アカウントと支払い情報:ユーザー名、注文履歴、サポートチケットの記録。オンラインでの行動を表すものではありませんが、あなたと 1 件の契約を結び付けられます。

よくある 3 つの言い方と、それぞれの実際の意味

  • 「閲覧内容は記録しません」:通常は 1 種類目を保持しないという意味で、2 種類目は残る可能性があります。業界で最もよく見られる表現です。
  • 「ゼロログ」:どの種類がゼロなのか、保持期間はどれくらいか、集計統計なのかアカウントまで遡れる形なのかを問い返す必要があります。
  • 「匿名」:登録時に身元情報を求めないという意味に限って理解すべきで、識別されないという意味ではありません。

3 つの確認手順

  1. 原文を読み、宣伝文句は読まない。プライバシー説明には、何を収集し、用途は何で、どれくらい保持し、誰と共有するかが項目ごとに書かれているべきです。「ログは記録しません」の一言だけで範囲の定義がないなら、何も言っていないのと同じです。
  2. 登録時に何を求められるかを見る。取らなくても済むものを取らないほうが、どんなに長い約束の文章よりも説得力があります。登録がユーザー名とパスワードだけで、メールアドレスを求めないなら、ひも付け可能な識別子が 1 つ減ります。
  3. クライアントがどのスイッチを利用者に委ねているかを見る。分流ルール、DNS の扱い、ローカル接続ログが見られるかどうか——これらは自分で確かめられます。検証できるものに信頼は要りません。

独立監査を受けていると主張するサービスなら、もう一段深く見る価値があります。監査機関はどこか、対象期間はいつか、報告書の原文は公開されているか、監査範囲にログシステム自体が含まれるか。「第三者監査済み」の数文字だけで確認できる原文がないなら、検証の根拠には足りません。

判断の順序は、まず何を集めているか、次に約束に何が書かれているか、最後に自分で検証できるか。約束は文字であり、収集範囲と検証可能な項目こそが事実です。

登録情報の最小化:ユーザー名から支払い方法まで

情報最小化の原則はごく素朴です。集められた情報のそれぞれが、将来あなたをひも付けるために使われうる識別子になります。目標は「隠すこと」ではなく、その連鎖を最初から発生させないことです。

情報の種類 通常残るもの 最小化の方法
アカウント登録 メールアドレスまたはユーザー名、パスワード、登録時刻 ユーザー名とパスワードだけで登録し、メールは入力しない。SNS で使っているニックネームを流用しない
支払い 決済チャネルの取引履歴、注文番号、購入したプラン 実名アカウントに紐づかない手段を優先する。第三者の決済記録は取引そのものしか指さない
クライアントとサブスクリプション サブスクリプション URL、ローカル設定、ローカル接続ログ サブスクリプション URL はパスワード同様に管理し、外部に送らない。ローカルログは必要に応じて無効化するか定期的に削除する
サポートでのやり取り 会話の内容、添付したスクリーンショット トラブルシューティングに必要な情報だけを渡し、スクリーンショットはアカウントと注文番号をマスクしてから

ユーザー名の使い回しが最も見落とされやすいひも付けポイント

同じニックネームがフォーラム、クラウドストレージ、サブスクサービスで繰り返し現れると、無関係な複数のデータを結び付けられてしまいます。サブスクサービス専用に、どの SNS でも使わないユーザー名を 1 つ用意する——コストはゼロ、効果は直接的です。

支払い方法の選び方

Alipay / WeChat Pay は実名アカウントを通るため、取引記録は決済チャネル側に残ります。記録されるのは「サブスクを 1 件購入した」という事実で、その後の閲覧行動は含みません。USDT のようなオンチェーン決済は実名アカウントを経由しませんが、アドレスと送金記録を自分で管理する必要があります。どちらを選ぶかは、取引記録の帰属を重視するか、操作の手軽さを重視するかで決まります。プランとトラフィックパックの種類・期間・価格は購入ページに明記されており、登録前に追加情報を求められることはありません。

サブスクリプション URL にはサーバーアドレスと認証パラメータの両方が含まれます。友人に転送したり、公開フォーラムに貼ったり、出所不明の「速度テストツール」に投入したりするのは、アカウントを渡すのと同じです。多くのサービスにはサブスクリプション URL を再生成する入口があり、漏えいが疑われるときに再生成すれば古い URL は無効になります。

公共 Wi-Fi の実際のリスクと接続順序

公共 Wi-Fi のリスクは 2 つの方向から誤解されがちです。「つないだだけでアカウントを盗まれる」という説と、「今は全サイトが HTTPS だから問題ない」という説です。リスクは実際には層になっており、その大半は接続順序で解消できます。

リスクは 4 層

  1. 同一セグメントの盗聴。オープンなネットワークでは、暗号化されていない HTTP 通信が同じセグメントの端末から読まれます。現在はほとんどのサイトが HTTPS を使っており、この層の露出は 10 年前よりずっと小さいものの、ゼロではありません。
  2. 暗号化の外側にある部分。DNS クエリ、一部アプリの平文リクエスト、ポータルページのリダイレクト。これらは必ずしも TLS の保護範囲にありません。
  3. 偽ホットスポット。攻撃者が同名のホットスポットを立て、接続するとすべての通信がその端末を経由します。公共 Wi-Fi で最も警戒すべき類型です。
  4. ログインページでの収集。空港やホテルのポータルページが、ネット接続のためにメールアドレスや SNS アカウントの入力を求めることがあります。この段階で集められる情報は、ネット利用そのものと何の関係もありません。

ツールより接続の順序が大事

  1. 端末の「既知のネットワークに自動接続」をオフにする。同名のホットスポットは自動接続のときに選ばれやすい。
  2. Wi-Fi につないだら、まずブラウザを開かずにクライアントを起動し、トンネルが確立したことを確認する。
  3. トンネルが通ってからポータルページのログインを処理する。ポータルがメールを強制する場合は、使い捨てのメールアドレスで代用する。
  4. システムのファイル共有と公開の送信機能を切る。たとえば AirDrop の受信設定を「連絡先のみ」にする。
  5. 使い終わったら手動で切断し、システム上でそのネットワークを「忘れる」。

Wi-Fi につないでからトンネルが確立するまでには数秒の空白があり、その間にシステムが DNS クエリ、時刻同期、自動更新のリクエストを送っている可能性があります。「先にトンネル、それからブラウザ」を習慣にすれば、この空白は最小限に抑えられます。

ブラウザ側では「HTTPS のみ」モードを有効にすると、平文リクエストを黙って送信せず、失敗させられます。資金や仕事のアカウントに関わる操作は、トンネルの確立を確認してからにしましょう。

DNS と分流ルール:漏えい点はどこか

トンネルが確立しても、クエリがトンネルを通っているとは限りません。DNS リークとはこの不一致を指します。通信は国際回線を通るのに、ドメイン名の解決はローカルネットワークや ISP が行う——つまり「どのドメインにアクセスしたか」をその場に残してしまうのです。

DNS リークの自己点検方法

  • 接続後に DNS リーク検出ページを開き、リゾルバの所在地が選択した回線と一致するか確認する。
  • クライアントの説明で、DNS が通信と同じトンネルを通るか確認する。
  • クライアントのオン・オフで、同じ検出ページが出すリゾルバの結果が変わるか比べる。

分流モードのトレードオフ

ルールモードはルールに一致したドメインだけをトンネルに通すため、通信量を節約でき遅延も低い一方、DNS の扱いにはより高い精度が求められます。ドメインはルールでトンネルを通るのに、DNS は直結で解決されると、「接続は外に出たのにクエリはローカルに残る」という不一致が起きます。確認は簡単です。クライアントの DNS 処理と分流ルールが同じロジックを使っているか、別々に分担していないかを確かめます。

プロトコルは通信の見た目を決めるが、ログ方針は決めない

Shadowsocks、VMess、Trojan、VLESS、Hysteria2、TUIC は一般的な転送プロトコルです。Trojan と VLESS は通常 TLS と組み合わせて使われ、通信の見た目は普通の HTTPS リクエストに近くなります。Hysteria2 と TUIC は QUIC ベースで、パケットロスが多い不安定な回線でより安定します。これらが決めるのは通信の形と転送性能であり、「サーバー側がログを取るかどうか」とは因果関係がありません。ログ方針は運用側の選択であり、この 2 つは分けて評価すべきです。

DNS クエリ自体にページの内容は含まれませんが、ドメインの一覧があればその人の関心範囲を描き出せます。だからこそ、個別に確認する価値があるのです。

選定基準:プライバシー要件を確認項目に変える

ここまでの内容を 1 枚のチェックリストに圧縮します。前半は歓迎できるシグナル、後半は警戒すべきシグナルで、判断基準はどれも「信じられるかどうか」といった主観ではありません。

  • ✅ プライバシー説明に、記録するもの・しないもの・保持期間が項目ごとに書かれている
  • ✅ 登録に必要なのはユーザー名とパスワードだけで、メールアドレスを求めない
  • ✅ 支払い手段に、実名アカウントに紐づかない選択肢がある
  • ✅ クライアントが DNS と分流ルールの扱いを説明しており、自分で検証できる
  • ✅ サブスクリプション URL を再生成でき、漏えい時の止血手段がある
  • ❌ 「一切ログを記録しません」とだけ書き、ログの範囲を定義していない
  • ❌ 「匿名」を絶対的な約束として宣伝している
  • ❌ 登録時に課金と無関係な情報を求める
  • ❌ クライアントが分流と DNS について何も説明せず、既定値任せ

パラメータと約束は分けて見る

約束は秤にかけられませんが、パラメータはかけられます。回線のカバレッジ、対応プラットフォーム、返金期間——これらはページに書かれた事実で、いつでも照合できます。VPNBL は 100+ の国・地域、230+ の回線をカバーし、Windows / macOS / iOS / Android / Linux の全プラットフォームで利用可能、台数制限なし、60 日間の理由を問わない返金に対応。登録に必要なのはユーザー名とパスワードだけで、メールアドレスは求めません。

100+ 対応国・地域
230+ 回線ノード
60 日 理由を問わない返金期間

プライバシー VPN を選ぶ順序はまず除外し、それから比較するのがおすすめです。スローガンだけを掲げる、登録時に多くを求める、DNS と分流の説明が曖昧な候補を先に外し、残ったものを回線と価格で比べます。多くの人にとって、登録時にメールアドレスを求めない・支払い方法を選べる・クライアントで自分で検証できる、この 3 点だけで候補の大半をふるい落とせます。