はじめに（この記事で分かること）#

メッセンジャーの匿名性は、「End-to-End暗号化されているか」という問いでは評価できない。SignalはE2EEを標準としているが、電話番号がアカウントの識別子になる。Telegramは「秘密チャット」以外ではE2EEが適用されない。

この記事では、アカウント識別子・メタデータ保護・ネットワーク形態・管轄・検閲耐性の5軸で、7つのメッセンジャーを比較する。

前提: 脅威モデルの整理#

メッセンジャーの匿名性が有効な相手は、脅威モデル入門で整理した5種類の相手のうち、主に3者だ。

プラットフォーム（メッセンジャー事業者）は、アカウント識別子とメタデータを保有する。ISPは、どのメッセンジャーに接続しているかという事実を知る。標的型攻撃者は、アカウント識別子から実名への紐付けを試みる。

5軸の比較表#

メッセンジャー識別子メタデータ保護ネットワーク管轄匿名決済
SimpleX Chat一切なし最強（ペアワイズ・キューID）リレーサーバー（自己ホスト可）--
SessionSession ID（66文字の公開鍵）高い（onionネットワーク）Session Node（onion requests）--
ThreemaThreema ID（8文字）高い（配送後即削除）中央サーバースイス有料アプリ一回払い
Briarなし（P2P）強い（メタデータはリレーに存在しない）P2P（Tor・Bluetooth・WiFi）--
Signal電話番号（必須）E2EEは強いが番号紐付け中央サーバー米国寄付
Olvid電話番号不要サーバーがメタデータを保持しない中央サーバーフランス有料
Telegram電話番号（必須）E2EEは非標準中央サーバー不明寄付

各メッセンジャーの評価#

SimpleX Chat: IDなしの徹底#

SimpleXは「not even random numbers」——ユーザーに識別子を割り当てない初のメッセンジャーである。連絡先ごとに異なるペアワイズ・キューIDを使い、リレーサーバーでも「同じユーザーが複数の連絡先と通信している」ことを観測不能にする。

リレーサーバーが改ざん・侵害されてもメッセージ内容は保護される。VPN併用が推奨されるが、IDがないためIPからの特定には至らない。自己ホストも可能である。

弱みは、連絡先の追加がQRコードや招待リンクの共有に依存することだ。Signalのような電話番号検索による連絡先発見は存在しない。

Session: 匿名IDとonionネットワーク#

Sessionは電話番号・メール不要のメッセンジャーで、アカウントはランダム66文字の公開鍵ベースIDである。通信はSession Nodeネットワークのonionルーティングで保護される。

Sessionの「はまりどころ」は、Sessionの落とし穴で詳しく扱う。リンクプレビューのIP漏れ、onion経路の自己交差、トラフィック分析耐性の限界がある。

Threema: スイス管轄と一回払いモデル#

Threemaは、スイス管轄の有料アプリ（一回払い）である。広告やデータモデルに依存しない構造的な独立性を持つ。オープンソースで、reproducible buildsを提供している。

弱みは、中央サーバーであることだ。スイスの管轄は比較的強いが、中央サーバーが単一障害点になる。

Briar: P2Pと検閲耐性#

Briarは中央サーバーを持たないP2Pメッセンジャーである。Tor連携、Bluetooth/WiFi直結に対応しており、通信が遮断された環境でも動作する。

弱みは、相手がオンラインでないとメッセージが届かないことだ。日常的なメッセンジャーとして使うには制約が大きい。

Signal: 電話番号の問題#

SignalはE2EEの標準であるが、電話番号がアカウントの識別子になる。電話番号は実名SIMと紐付き、物理的な場所・個人情報と接続する。この脅威モデルでは、Signalの電話番号要件が匿名性の最大の弱点になる。

匿名SIMと併用する場合の注意点もある。匿名SIMの入手自体が痕跡を生む。

Telegram: 避けるべき選択#

Telegramは「秘密チャット」でのみE2EEが適用される。通常のチャットはサーバー側で復号可能であり、メタデータは保持される。Threemaの公式比較表でも「E2EE of all messages: no」と明記されている。

脅威モデル別の推奨#

一般ユーザー（広告ブロック層）#

Signalで十分である。電話番号は露出するが、日常的なメッセージングの匿名性要求は低い。

ジャーナリスト層#

SimpleXまたはSessionを選ぶ。SimpleXはIDがないためメタデータ保護が最も強い。SessionはonionネットワークでIPを隠すが、リンクプレビューの漏れに注意する必要がある。取材源との通信では、SimpleXの自己ホスト + VPN併用が合理的になる。

開発者層#

SimpleXの自己ホストを検討する。リレーサーバーを自分で管理することで、メタデータの第三者流出を防ぐ。Threema Workも法人向けの選択肢になる。

限界と残るリスク#

どのメッセンジャーを選んでも、端末自体が侵害されればメッセージの内容は露出する。メッセンジャーの匿名性は、端末のセキュリティとは別の問題だ。

Sessionの落とし穴で説明するリンクプレビューのIP漏れは、匿名IDを持つメッセンジャーでも周辺機能が匿名性を崩す例である。メッセンジャーの匿名性は、プロトコルではなく、全機能がどのネットワーク経由で動くかで決まる。

まとめ#

メッセンジャーを選ぶ基準は、「E2EEがあるか」ではなく「アカウント識別子が何か」である。電話番号を識別子とするSignalとTelegramは、匿名性の要求が高い場面では選択肢から除外される。

SimpleXはIDがないためメタデータ保護が最強である。Sessionは匿名IDとonionネットワークを提供するが、リンクプレビューの漏れに注意が必要である。Threemaは一回払いモデルの構造的独立性を持つ。Briarは中央サーバーを持たないP2Pで、検閲環境に最強である。

自分の脅威モデルに合ったメッセンジャーを選ぶことは、脅威モデル入門で説明した「脅威モデルXなら〜が合理的」の考え方の直接的な適用である。

出典#