日常会話、パスワード、一時的なID、仕事、危機管理など、プライバシーに求められる性質はそれぞれ異なります。私たちはメッセンジャーを交換可能な容器のように考えがちです。つまり、最も強力な暗号化を備えたものを選び、すべての会話をそこに集約すれば問題は解決すると考えます。しかし、実際のコミュニケーションはそれほど単純ではありません。
家族のグループには、信頼性と連絡先の見つけやすさが必要です。サポートチームには、検索機能、履歴の保持、そして管理責任が求められます。ジャーナリストが情報源と会う場合、電話番号や再利用可能なハンドルネームを避け、関係性を示すメタデータを最小限に抑えたいと考えるでしょう。APIトークンを転送する際、そもそも永続的なチャット記録を作成すべきではありません。インターネットが遮断された状況下では、アクセスできないクラウドサービスは何の役にも立ちません。
最適なメッセンジャーとは、セキュリティチェックリストが最も長いものではありません。その会話の失敗モード（リスク）に適合したものです。
本稿は普遍的なランキングではありません。コミュニケーションのユースケース、アーキテクチャの選択、そしてトレードオフ（メッセンジャーが不適切なツールとなる瞬間を含む）を調査に基づき整理したマップです。
セキュリティはリーダーボードではない
「安全」という言葉は、混同しやすい複数の性質を表しています。「コンテンツの機密性」は、サービス提供者やネットワーク上の監視者がメッセージを読み取れるかどうかを指します。「IDのプライバシー」は、電話番号、メールアドレス、ドメイン、あるいは固定された公開識別子を明かす必要があるかどうかに関わります。「メタデータ耐性」は、誰と誰がいつ、どのネットワークから通信したかを推測できるかどうかを測定します。「真正性」は、受信者が意図した人物やデバイスであることを検証できるかどうかを決定します。「可用性」は、サーバー障害、検閲、アカウント停止、インターネット接続の喪失が発生しても通信が維持されるかを問います。「復旧」は、デバイスの紛失や新しいデバイスの追加時に何が起こるかに関わります。「ガバナンス」は、組織がビジネス記録を保持、エクスポート、モデレート、またはアクセス取り消しできるかどうかを指します。
すべての性質を最大化できるアーキテクチャは存在しません。容易な復旧には、耐久性のある暗号化バックアップが必要になる場合があります。連絡先の検索機能は、固定された識別子を公開してしまう可能性があります。強力な組織的監視は、個人の匿名性とほぼ対極にあります。オフラインでの回復力は、多くの場合、利便性の低下と、より多くの手動による信頼判断を意味します。したがって、実務上の問いは「どのメッセンジャーが最も安全か」ではなく、「私たちはどのような結果を最も防ぎたいのか」となります。
日常のコミュニケーションは強力なデフォルトを優先する
日常の会話において、普及率はセキュリティの一部です。技術的に優れていても、友人や親戚、顧客が使ってくれないメッセンジャーは、結局SMSやメール、スクリーンショットでのやり取りに逆戻りさせるだけです。
WhatsAppのプライベートメッセージと通話は、デフォルトでエンドツーエンド暗号化を使用しています。Signalも同様にエンドツーエンド暗号化を標準モードとし、セーフティナンバーの検証を追加し、電話番号をプロファイル詳細に表示させずにユーザー名で連絡を開始できるようにしています。AppleのiMessageは、Appleデバイスのエコシステム内でエンドツーエンド暗号化を提供します。これらの製品は、日常的な感覚でプライベートな会話を行いたい場合に適しています。
ここでのトレードオフは、IDとエコシステムの結合です。Signalは登録に電話番号が必要であり、WhatsAppは電話番号をベースとしたIDと大規模なリーチを前提としています。iMessageは、全員が互換性のあるAppleデバイスを使用している場合に最も機能します。
復旧も重要です。マルチデバイスアクセスや暗号化バックアップは、紛失した電話から家族の歴史を守るのに役立ちますが、保護すべきデバイス、認証情報、復旧メカニズムの数を増やしてしまいます。エンドツーエンド暗号化はエンドポイント間の経路を保護しますが、ロックが解除されたエンドポイント、侵害されたOS、コピーされたエクスポート、あるいは画面を撮影する受信者までは保護できません。
通常の生活において、目指すべきゴールは通常「匿名性」ではありません。それは、強力な暗号化のデフォルト、理解可能な本人確認、保護されたデバイス、そして参加者が実際に管理できる復旧モデルです。
クラウドの利便性、コミュニティ、仕事には異なる信頼が必要
大規模なコミュニティや職場での会話では、継続性、モデレーション、検索、統合、共有されたコンテキストが優先されます。これらのニーズはセキュリティモデルを変化させます。
Telegramはこの区別を明確にしています。「クラウドチャット」はクライアントとサーバー間で暗号化され、Telegramのクラウドに保存されるため、デバイス間で同期できます。「シークレットチャット」はエンドツーエンド暗号化を追加し、デバイス固有のものであり、クラウドの一部ではありません。この製品が2つの異なる回答を提供しているのは、永続的なマルチデバイス履歴と、デバイスに縛られた機密性が異なるユースケースだからです。
Matrixは連合（フェデレーション）アプローチを採用しています。ユーザーやルームは独立して運用されるホームサーバーにまたがることができ、暗号化されたルームはデバイスキーとOlm/Megolmファミリーの暗号化プロトコルを使用します。これにより、コミュニティや組織はインフラストラクチャを選択できますが、同時にデバイス検証やキー復旧といった作業が発生します。連合は単一のグローバルオペレーターを排除しますが、サーバー管理やエンドポイントのリスクを排除するわけではありません。
Slackは別の正当なモデルを提示しています。公式資料では、保存時および転送時の暗号化、保持ポリシー、データエクスポート、法的ホールド、DLP、オプションのエンタープライズキー管理が強調されています。これはガバナンス指向のセキュリティです。企業はインシデントのタイムラインを保存したり、法的ホールドを満たしたりする必要があるかもしれません。従業員は、その組織的な管理と、管理者やポリシーを超えたプライベートなチャネルを混同すべきではありません。
有用なルールとして、ポリシーで明示されていない限り、仕事のチャットはビジネス記録であると考えるべきです。残すべき決定事項には使用し、匿名や否認可能な空間として扱うことは避けてください。
パスワードと秘密鍵はメッセージではない
パスワード、復旧コード、APIトークン、ウォレットの秘密鍵、シードフレーズは、通常の会話コンテンツではありません。これらは「権限」であり、入手した者は誰でもあなたとして行動できる可能性があります。
そのため、推奨されるワークフローが変わります。長期間有効な秘密情報をチャット履歴に貼り付けるのではなく、有効期限、アクセス制限、取り消し機能を備えた、専用の暗号化共有メカニズムを使用してください。例えばBitwarden Sendは、クライアントサイドでコンテンツを暗号化し、サーバーリクエストに暗号化キーを含めず、削除や有効期限の制御をサポートし、パスワードを要求することも可能です。そのドキュメントでは、パスワードを別のチャネルで共有することを推奨しています。
優れた秘密情報の転送手順は以下の通りです。まず、既存の信頼できるチャネルまたは直接会って受信者を検証します。次に、最小限のアクセス回数で短期間有効な暗号化された秘密リンクを作成します。その後、リンクを一つのチャネルで送信し、アクセスパスワードや鍵の断片を別のチャネルで送信します。最後に、会話の中で秘密情報を繰り返すことなく受信を確認し、共有を削除または取り消し、露出のリスクがある場合は認証情報を更新します。
消えるメッセージは日常的な履歴を減らすことはできますが、敵対的な削除を保証するものではありません。Signalが明言するように、記録を望む受信者は画面を撮影できます。タイマー機能は、通知プレビュー、コピーされたテキスト、スクリーンショット、エクスポート、マルウェアによるキャプチャ、あるいは既に他で使用された秘密情報を消去することはできません。
メッセンジャーは転送の調整に使用し、秘密情報の転送には専用の共有ツールを使用してください。
ウォレットのシードフレーズやマスター復旧キーの場合、最も安全なデフォルトはさらに厳格です。いかなるメッセンジャーを通じても送信しないでください。オフラインでの検証済み受け渡しや、慎重に設計されたマルチシグ、あるいは復旧プロセスを優先してください。
「一時的な通信」には4つの異なる意味がある
人々は、実際には以下の4つの性質のいずれかを必要としているにもかかわらず、「一時的なアカウント」を求めることがよくあります。1つ目は、日常のアカウントとリンクしていない「一時的なID」。2つ目は、招待やアドレスが新しい連絡先を受け付けなくなる「一時的な到達可能性」。3つ目は、タイマー後にメッセージが参加デバイスから消える「一時的なコンテンツ」。4つ目は、インフラストラクチャが参加者同士を長期間にわたって容易に結びつけられない「一時的なメタデータ」です。これらの性質は同等ではありません。
Signalのユーザー名は到達可能性のプライバシーを向上させます。変更が可能であり、電話番号を明かさずに連絡を開始できるからです。しかし、アカウント登録には依然として電話番号が必要であり、ユーザー名を変更しても新しい暗号化IDが作成されたり、既存のチャットが消去されたりするわけではありません。
Sessionは電話番号とメールアドレスの要件を排除し、分散型のオニオンルーティングを通じてメッセージを送信するため、どのルーティングノードも送信元と送信先を同時に知ることはできません。これにより、安定した市民IDやネットワークの起源を会話から切り離したい場合に魅力的ですが、リーチ、復旧、リアルタイム機能は主流プラットフォームに及ばない場合があります。
SimpleXはアドレス層でさらに一歩進んでいます。ネットワーク全体で共通のユーザー識別子を割り当てません。連絡先は一度限りの、あるいは一時的なリンクを通じて接続し、リレーサーバーは配信されるまでのみ暗号化されたメッセージを保持します。これにより連絡先間の相関関係は減少しますが、発見は帯域外の招待に依存し、ローカルでのデータ管理が重要になります。
ADAMANTは、電話番号やメールなしでBIP39ニーモニックからローカルにアカウントを生成できます。これにより、コンパートメント化されたIDを容易に作成できます。しかし、アカウントの暗号化メッセージトランザクションはブロックチェーンに書き込まれます。IDは使い捨てにできますが、承認されたトランザクション履歴は意図的に永続的なものとなります。
一時的なアカウントはIDのリンクを減らすことはできますが、既にコピー、バックアップ、または台帳に記録された記録を消去することはできません。
「バーナー」アカウントを作成する前に、どの形式の一時性が重要かを決定してください。さもなければ、システムが誤った問題を解決することになりかねません。
高リスクおよびオフラインの通信は回復力を優先する
脅威に広範なネットワーク監視、検閲、インターネットの遮断が含まれる場合、従来のクラウドの前提は崩れる可能性があります。
Briarはユーザーのデバイス間で直接同期します。インターネットアクセスがある場合はTorを使用し、ない場合はBluetoothやWi-Fi経由でデータを交換できます。連絡先リストはデバイス上で暗号化されたまま保持され、ブロックされる中央メッセージングサーバーは存在しません。これは、ジャーナリスト、活動家、災害対応、および混乱下での地域的な調整に適しています。
トレードオフは重大です。ユーザーネットワークが小さく、連絡先の導入には注意が必要で、状態はデバイス内に限定され、プラットフォームのリーチが制限され、主流の利便性が少なくなります。これらは製品の欠陥というよりは、より深刻な障害に最適化するためのコストです。
ADAMANTの立ち位置
ADAMANTは、メッセージングを分散型の信頼レイヤーとして捉えています。アカウントはニーモニックパスフレーズからローカルで生成され、結果として得られるキーペアがトランザクションに署名します。登録機関に電話番号、メールアドレス、連絡先帳を提供する必要はありません。
メッセージ資産はトランザクションに詰め込まれる前に暗号化されます。ADAMANTのドキュメントでは、鍵共有にCurve25519、暗号化にSalsa20、認証にPoly1305を使用したNaClボックス暗号化について説明されています。暗号化されたトランザクションは署名され、ネットワークにブロードキャストされ、独立したノードがその順序と真正性を検証します。
これにより、独自のユースケースが生まれます。メッセージング企業によって発行されない主権ID、単一プロバイダーのデータベースに依存しない通信履歴、検閲耐性のある配信と検証可能な順序付け、個人的な登録なしで作成される匿名またはコンパートメント化されたアカウント、そして転送、ボット、ブロックチェーンサービスと統合されたメッセージングです。
同時に、責任も生じます。ニーモニックパスフレーズはマスターシークレットであり、これを復旧できるヘルプデスクは存在せず、チャットで送信すべきではありません。ブロックチェーンの耐久性は、暗号化されたペイロードや必要なトランザクションメタデータが、デバイスや一時的なアカウントの背後にある意図よりも長生きすることを意味します。暗号化はコンテンツを保護しますが、トランザクションの存在や順序を消し去ることはできません。
これが、ADAMANTが単なる「もう一つの暗号化チャット」ではない理由です。オペレーターを生き延びる必要がある会話、独立して検証可能である必要がある会話、あるいは中央発行のIDなしで開始する必要がある会話において、そして参加者が自己管理と永続的な履歴のコストを受け入れる場合に、最も価値を発揮します。
最も安全なワークフローは複数のツールを使用する
人々は自然と、すべてを一つのアプリで行いたいと考えます。成熟したセキュリティプログラムは逆のことを行います。つまり、結果に応じてチャネルを分離します。
チームは、永続的な調整にはSlackやMatrixを、機密性の高い個人間通話にはSignalを、認証情報にはパスワードマネージャーを、ルートキーにはオフラインの復旧キットを使用するかもしれません。ジャーナリストは、最初の接触には一度限りのSimpleX招待を使用し、通話で本人確認を行い、長期にわたる検閲耐性のあるやり取りにはADAMANTへ移行するかもしれません。災害対策グループは、ネットワークが消失する日のためにBriarをインストールしたままにするかもしれません。
これは単なる断片化ではありません。一つの侵害されたアカウント、デバイス、管理者、またはプロバイダーが、あらゆる種類の通信における単一の障害点になることを防ぐためです。
7つの質問によるチャネルテスト
チャネルを選択する前に、コンテンツが漏洩した場合に何が起こるかを自問してください。軽い恥、経済的損失、身体的危険、あるいは取り返しのつかないアカウント乗っ取りでしょうか。関係が露呈した場合に何が起こるかも考えてください。メタデータは無害か、商業的に機密か、あるいは個人的に危険でしょうか。会話を存続させる必要があるか、復旧や保持が利益かリスクかを決定してください。記録を誰が管理すべきか（参加者、雇用主、コミュニティ、あるいは中央パーティーなし）を判断してください。IDをどのように検証するか（馴染みの電話連絡先、セーフティナンバー、QRコード、共有アドレス、対面チェック）を計画してください。どのインフラストラクチャが失敗し得るか（一つのデバイス、クラウドプロバイダー、アプリストア、インターネット、あるいは法的な運用能力）を考慮してください。最後に、それが本当にメッセージなのかを問いかけてください。もしそれがパスワード、鍵、復旧権限であるなら、専用の秘密情報ワークフローに移動してください。
これらの質問に答えることで、選択はイデオロギー的なものから、より実用的なものへと変わります。
プライバシーは「うまく選ぶ」習慣である
暗号化は不可欠ですが、それは一つのレイヤーに過ぎません。ID設計、メタデータ、デバイスセキュリティ、復旧、ガバナンス、インフラストラクチャの回復力が、実際の成果を形作ります。主流の暗号化メッセンジャーは日常のプライバシーを当たり前のものにします。連合型や職場向けのシステムはコミュニティを管理可能にします。識別子不要でオニオンルーティングされたネットワークはリンク可能性を低減します。オフラインのピアツーピアツールは混乱下でも通信を維持します。ADAMANTはローカル生成のIDとブロックチェーンによる継続性を追加します。専用の秘密共有ツールは、チャット履歴よりもはるかに安全に認証情報を扱います。
プライベートなコミュニケーションの未来は、一つの勝者となるメッセンジャーではありません。人々が各チャネルの約束を理解し、その瞬間に適切な約束を選択することにあります。