ノーログVPN選びで難しいのは、「ノーログ」と書かれたサービスを見つけることではなく、その文言を額面通り受け取れるかの判断だ——ほぼすべての事業者がこの言葉を公式サイトに並べている。本記事はスローガンの一覧ではなく、1項目ずつ検証できるチェック方法を提示する:登録に何を求められるか、支払い方法に実名の手がかりが残るか、公衆Wi-Fi環境で防御が本当に機能するか、そしてプロトコルと暗号化の面で何を見て、どんな話術に乗らないか。
ノーログとは何を指すのか:まず4種類のログを区別する
「ノーログ」は曖昧な表現なので、まず分解して考える。事業者のログは通常4種類に分かれ、プライバシーへの影響はまったく異なる:
| ログの種類 | 代表的なフィールド | プライバシーへの影響 | 運営上の必要性 |
|---|---|---|---|
| 接続ログ | 接続時刻、接続時間、出口IP | 利用時間帯と位置のパターンを復元できる | 課金に必要、匿名化して関連付け不能にできる |
| トラフィックログ | アクセスしたドメイン、接続先IP、コンテンツのメタデータ | 閲覧行為をそのまま露出させる | サービス提供上は不要 |
| 決済記録 | 注文番号、決済チャネルの取引記録 | 実名と関連付けられる可能性 | 課金に必要、支払い方法次第 |
| クラッシュ・デバッグログ | エラースタック、クライアントのバージョン | 閲覧内容は通常含まれない | トラブルシューティングに必要、オフまたは匿名化できるべき |
あるサービスが「ノーログ」と宣言する場合、厳密には接続ログとトラフィックログの2種を記録しないことを指す。課金・決済記録はチャネルの要件上存在せざるを得ず、完全には消せない部分だ。だから検証の焦点は「一切の記録があるかないか」ではなく2点にある:減らせる記録を減らしているか、残った記録を具体的な個人と結び付けられるか。前者は登録のハードルとログポリシー、後者は支払い方法で判断する——まさに次の2節の内容だ。
登録情報の最小化:最初に検証できる関門
登録フォームに何を入力させるかは、「ノーログ」を試す最も直接的な試金石だ。アカウントシステムのフィールドが1つ増えるごとに、アカウントと実名を結ぶ糸が1本増える:メールアドレスから登録者を逆引きでき、長いフォームはそれだけ関連付けの手がかりになる。逆に、ユーザー名とパスワードだけを求めるサービスなら、アカウントと本人の間にはもともと明示的な糸が1本少ない——接続記録を完全に匿名化しなくても、関連付けの足がかりがない。
VPNFPの登録に必要なのはユーザー名とパスワードだけで、メールアドレスは不要、認証ステップもない。プライバシー重視のユーザーにとって、この種の登録ハードル自体が検証可能な事実だ:目の前のフォームに書かれているので、約束を信じる必要がない。
支払いはもう1つの実名ルートだ。AlipayとWeChat Payは実名チャネルを通るため、注文が決済アカウントと結びつく。USDTのような暗号資産決済は実名体系を経ないため、注文と本人の間は切断される。VPNFPは3方式とも対応しており、プライバシー重視の組み合わせは:登録情報を最小化し、USDTで支払う。
この順番で登録と決済をチェックする:
- ✅ 登録フォームはユーザー名とパスワードのみ、メールアドレス不要
- ✅ USDTなど実名を経ない決済手段に対応
- ✅ ログポリシーが具体的——何を記録し、何を記録せず、どれだけ保持するかが書いてある。「一切記録しない」の一言でない
- ❌ 登録にメールアドレスの入力と認証が必須——メールは最も典型的な本人特定の手がかり
- ❌ フォームが氏名・住所などサービス提供に不要な個人情報を求める
公衆Wi-Fi環境:防御はその場で検証できるか
公衆Wi-Fiはプライバシー上もっとも現実的な脅威だ:同じネットワーク内の他の端末が平文トラフィックを盗聴でき、偽のアクセスポイントやARPスプーフィングで悪意あるゲートウェイへ誘導され、DNSハイジャックは気づかないうちに名前解決の結果を書き換える。この場面でのVPNの役割は、全トラフィックを暗号化トンネルに収めること——ローカルネットワークから見えるのは自分とノードの間に暗号化された接続が1本あるという事実だけで、中身もアクセス先も見えない。
しかし「接続できた」イコール「守れている」ではない。次の3点は必ず実測したい。
DNSリーク:トンネルの脇に開いた裏口
システムがDNSクエリをローカルネットワークのDNSサーバーに直接送り、トンネルをバイパスすることがある——これがDNSリークだ。クエリの中身はアクセス予定のドメインを露出し、暗号化トンネルの脇に裏口を残すのと同じだ。検出手順:
- VPN接続後、ブラウザで任意のDNSリーク検証サイトを開く;
- 表示されたDNSサーバーを確認する:すべてノード側に位置すべきで、自分のネットワークのプロバイダであってはならない。サイト内のIP確認ページで出口位置を突き合わせてもよい;
- IPv4とIPv6の両方のプロトコルスタックでテストし、切断して再接続した後にもう一度測り、結果の安定を確認する。
キルスイッチ:切断のほうが平文流出よりマシ
トンネルが不意に切れた瞬間、キルスイッチがなければトラフィックは平文の直接接続へ落ちる——公衆Wi-Fiの環境では、それまでの防御が一瞬でゼロになる。検証方法は簡単だ:接続状態で手動でノードを切断し、任意のサイトへのアクセスを試みる。キルスイッチが有効なクライアントは平文を通さず、接続を拒否するはずだ。
分流ルール:除外した部分がそのまま露出する
分流ルールは、どのトラフィックをトンネルへ、どれを直接接続へ流すかを決める。高速化の場面では分流は体験を改善するが、プライバシーの場面では、除外されたドメインがそのままローカルネットワークに露出する部分になる。グローバルモードを使うか、少なくともクライアントのデフォルトルールでどのドメインが除外されているか、自分で変更できるかを確認したい。
プロトコルと暗号化:何を見るか、何を信じないかを知る
プロトコルの実装詳細を研究する必要はないが、それぞれの得意な場面は知っておきたい:Shadowsocksは軽量で普及している。VMessとVLESSはV2Ray系で、TLSと組み合わせてトラフィックを通常のHTTPSに偽装できる。TrojanはTLSをそのまま使い、挙動は通常のHTTPSサイトへのアクセスと変わらない。Hysteria2とTUICはQUICベースで、パケットロスが多く回線が弱い環境でスループットに強い。
暗号強度については、これらのモダンなプロトコルはいずれもAES-256またはChaCha20クラスの共通鍵暗号を採用しており、いわゆる銀行レベルの暗号化に相当する。ただし明確にしておきたい:暗号化が解決するのは「伝送中に見られる」問題で、「サーバー側にどんな記録が残るか」という問題は解決しない。両者を混同させるのが、よくある宣伝文句の手口だ。
またクライアント差にも注意したい:プラットフォームごとにキルスイッチ、分流、DNS処理の対応度は異なる。検証は自分が常用するプラットフォームで行う——Windows、macOS、iOS、Android、Linuxを一通り試して初めて結論が成立する。
検証ポイントを1枚の選択基準にまとめる
プライバシー重視のユーザーなら、検証の優先順位はこう並べるべきだ:まず登録ハードルと支払い方法という「フォームに書いてある」事実、次にDNSリークとキルスイッチという「その場で試せる」挙動、最後にプロトコルと暗号化という「どこでも公式サイトに書ける」パラメータ。順番を間違えると、宣伝に引き回されやすい。