安全なメッセージアプリの選び方：根拠を確かめる12の質問

メッセージアプリに鍵のアイコンが表示され、プライバシーを守るとうたわれていても、重要な疑問が未回答のまま残っていることがあります。

どの会話が暗号化されるのでしょうか。添付ファイルも保護されますか。鍵はどこに保存されますか。サーバーはどの情報を保持しますか。端末を失うとどうなりますか。暗号鍵が警告なく変わることはありますか。

こうした詳細から、役立つ保護と、まだ不足している証拠の両方を見極められます。チェックリストだけで製品の安全性を認証することはできません。

このガイドでは、個人的な会話、機密ファイル、機微な業務を暗号化メッセージアプリに託す前に確認したい、12の実用的な質問を紹介します。

安全なメッセージアプリとは？

安全なメッセージアプリとは、不正アクセス、傍受、アカウントの侵害、意図しないデータ露出から会話を守るよう設計された通信サービスです。

プライバシーに真剣に取り組むメッセージアプリは、少なくとも安全なネットワーク通信、強いアカウント認証、慎重なアクセス制御、明確なデータ取扱方針を備えるべきです。

特にプライバシーが重要な会話には、エンドツーエンド暗号化も提供されるべきです。

エンドツーエンド暗号化、つまりE2EEは、対応する内容を送信者の端末で暗号化し、許可された受信者の端末で復号することで保護します。サービスは、読めるメッセージ本文を必要とせずに暗号化データを配送できます。

ただし、暗号化はメッセージの安全性の一部にすぎません。

完全な評価では、次の点も考慮する必要があります。

• どの会話が暗号化されるか
• 写真やファイルにも同じ保護が適用されるか
• 秘密鍵をどこに保存するか
• 連絡先同士で鍵をどう検証するか
• どのメタデータが見えるままか
• アカウントと鍵の復旧がどう機能するか
• 端末が侵害されるとどうなるか
• サービスが制約をどのように文書化しているか

より詳しい入門としては、「エンドツーエンド暗号化の解説」をお読みください。

「暗号化」という言葉だけでは不十分な理由

ほぼすべての現代的なメッセージサービスは、HTTPS、TLS、その他の保護された通信方式でネットワークトラフィックを暗号化しています。

その保護は重要ですが、必ずしも会話がエンドツーエンド暗号化されているとは限りません。

通信経路の暗号化では、端末とサービスの間を移動するデータが保護されます。それでもサービスは、読める内容を受け取ってから、別の保護された接続で届けることができます。

E2EEでは、対応するメッセージ内容がサービスに到達する前に、参加者向けに暗号化されます。

この違いは、技術的に誰がメッセージ本文にアクセスできるかに影響します。

だからこそ、一般的な「暗号化済み」という表示を受け入れるのではなく、正確な質問をすべきなのです。

主張	確認すべき質問
「チャットは暗号化されています」	通信中だけですか。それともエンドツーエンドですか。
「データは安全です」	どのデータを、どの脅威から、どの期間守るのですか。
「私たちはメッセージを読めません」	個別チャット、グループ、メディア、通話、バックアップも含みますか。
「設計段階からプライバシーを重視」	どのメタデータや運用情報が利用可能なままですか。
「安全な復旧」	誰が暗号鍵を復元でき、どの秘密情報が必要ですか。

1. どの会話がエンドツーエンド暗号化されるか

一つの暗号化に関する説明が、アプリのすべての部分に適用されると思い込まないでください。

メッセージサービスは、次の対象に異なる保護を提供する場合があります。

• 一対一の個別会話
• 非公開グループ
• 公開グループ
• 配信用チャンネル
• 音声通話とビデオ通話
• ストーリーや一時的な投稿
• ボットや自動化されたアカウント
• 同期される会話履歴

事業者に正確な境界を示してもらいましょう。

具体性のある回答は、例えば次のようなものです。

個別メッセージの本文とメディアは参加者の端末で暗号化されます。互換性のある非公開グループはLGS1でエンドツーエンド暗号化され、メンバー変更時には送信者鍵が自動で更新されます。チャンネルはサーバーが読める別の構成を使い、E2EEとは説明していません。

具体性に乏しい回答は、例えば次のようなものです。

あなたの通信は軍用レベルの暗号化で保護されています。

前者は評価できる情報を提供しています。後者は印象的な表現を使っているだけで、保護する内容や脅威モデルを定義していません。

2. 写真、動画、添付ファイルも暗号化されるか

アプリはテキストを暗号化しながら、アップロードされたメディアを別のシステムで処理する場合があります。

そこで重要になるのが、写真はアップロード前にクライアント側で暗号化されるのか、それともサーバーの権限設定と通信経路の暗号化だけで保護されるのか、という質問です。

次の対象について尋ねてください。

• 写真と動画
• 文書
• 音声メッセージ
• リンクのプレビュー
• サムネイル
• 一時的なアップロードファイル
• キャッシュされたメディア
• ダウンロードの認可

メディア保護は、「メッセージ」についての広い説明に埋もれさせず、別に説明されるべきです。

暗号化されたバイト列へのアクセスと、復号鍵へのアクセスも分けて尋ねましょう。設計によっては、制限が緩いストレージ経由で暗号化添付ファイルを配布します。それだけで平文の露出とは限りません。重要なのは、許可されていない第三者が読めるメディアやその鍵を取得できるか、そして保存経路からどんなメタデータが分かるかです。

3. 暗号鍵はどこで生成・保存されるか

暗号化の信頼性は、鍵の取り扱いの信頼性を超えません。

クライアント側のE2EEでは、秘密鍵の情報は参加者の端末の管理下に置かれるべきです。公開鍵は連絡先との暗号化通信を確立するために共有できますが、秘密鍵にはより強い保護が必要です。

次の質問への明確な答えを探してください。

• 秘密鍵は端末上で生成されますか。
• 暗号化せずにアップロードされることはありますか。
• 事業者はそれを導出したり置き換えたりできますか。
• 別のサインイン済み端末が自動的に取得できますか。
• ローカルの鍵保存領域は保護されていますか。
• 鍵のリセット後はどうなりますか。
• アプリを再インストールすると新しい本人性確認用の鍵が作られますか。

文書ですべての実装詳細を公開する必要はありません。ただし、秘密鍵の所有関係とライフサイクルは説明されるべきです。

4. 連絡先同士で鍵を検証できるか

エンドツーエンド暗号化が会話を保護できるのは、暗号鍵が意図した参加者のものである場合だけです。

多くの安全なメッセージシステムは、公開鍵をフィンガープリント、安全番号、QRコード、その他の検証値で表します。

二人の連絡先は、例えば次のような信頼できる経路でその値を比較できます。

• 対面での会合
• 相手を確認済みの音声通話
• 以前に認証済みのアカウント
• 信頼できる社内名簿

鍵の検証により、想定した鍵が使われているという確信を高められますが、それ自体が本人の身元証明になるわけではありません。Signalの自動検証のように、鍵の透明性を確認する機能を持つ製品もあります。すべての製品に手動だけの運用を求めるのではなく、対応するアカウントとバージョンの条件を確認してください。

フィンガープリントが変わったときの動作も尋ねましょう。

鍵の変更には、リセット、端末交換、復旧操作など問題のない理由もあります。ただし、変更は見えるべきです。通知のない置き換えは、予期しない本人性確認用の鍵の変更を見つけにくくします。

5. サービスはどのメタデータを保持するか

メッセージ内容とメッセージのメタデータは、別の種類の情報です。

サービスはE2EEのメッセージ本文を読めなくても、会話の配送、同期、表示に必要な情報を処理している場合があります。

システムによっては、次のものが含まれます。

• 送信者と受信者のアカウント識別子
• 会話のメンバー情報
• メッセージのタイムスタンプ
• 配信確認と既読通知
• メッセージのサイズ
• リアクションや編集のイベント
• 端末のセッション
• 同期カーソル
• 公開鍵の情報
• プッシュ通知トークン
• 不正利用防止とセキュリティの記録

運用上のメタデータが存在するだけで、サービスが危険になるわけではありません。

重要なのは次の質問です。

• 何を収集しますか。
• なぜ必要ですか。
• どのくらい保持しますか。
• 誰がアクセスできますか。
• ユーザーはエクスポートや削除ができますか。
• 広告や関係のないプロファイリングに使いますか。

事業者が何をメタデータと考えるか定義せずに「メタデータは一切保存しない」と主張する場合は注意してください。

6. アカウントはどのように認証されるか

強いメッセージ暗号化でも、弱いアカウント保護を補うことはできません。

アカウントを乗っ取った攻撃者は、ユーザーになりすます、新しい鍵を登録する、サーバーが読める内容にアクセスする、復旧を妨げる、といった行為が可能になる場合があります。

サービスが次のような保護を提供するか評価しましょう。

• 安全なパスワード処理
• レート制限
• セッションの失効
• 明確な端末・セッション管理
• 認証情報のリプレイ攻撃への対策
• 安全なパスワードリセット手順
• 適切な場面での多要素認証
• 重要なアカウント変更の通知

アカウント認証とメッセージ暗号化も区別してください。

サインインは、その人がアカウントの認証情報を持つことを示します。しかし、その端末が元の暗号化用秘密鍵を持つことまで証明するとは限りません。

7. 暗号化された復旧はどう機能するか

復旧は、プライベートなメッセージサービスで特に難しいトレードオフの一つです。

端末を交換した後も会話履歴にアクセスしたいとユーザーが考えるのは当然です。しかし、事業者がすべての秘密鍵を気付かれずに復元できるなら、ユーザーが想定する以上の復号能力を持っているかもしれません。

保護された復旧設計では、クライアントでバックアップを暗号化し、復旧用秘密情報、パスキー、信頼済み端末による承認を必要とする場合があります。最初にバックアップの内容を確認してください。アカウントの本人性情報、連絡先、メッセージ履歴はそれぞれ別のものです。

次を尋ねましょう。

• バックアップはアップロード前に暗号化されますか。
• アカウントのパスワードだけで復元できますか。
• 事業者は復旧用秘密情報を知っていますか。
• サポート担当者はその秘密情報をリセットできますか。
• 秘密情報を失うとどうなりますか。
• 復元後も同じ公開鍵フィンガープリントが保たれますか。
• 復旧機能を無効にできますか。

信頼できる回答には、受け入れにくい制約も含まれるかもしれません。秘密鍵と復旧用秘密情報の両方を失うと、古い暗号化内容が復元不能になることがあります。

それは製品の欠陥ではなく、実際のセキュリティ境界がある証拠になり得ます。

8. 接続が切れるとどうなるか

安全性と信頼性は両立しなければなりません。

モバイル接続は途切れ、ブラウザーは休止し、端末はネットワークを切り替えます。よく設計されたメッセンジャーは、メッセージの重複、順序の喪失、暗号化の弱体化を起こさずに一時切断へ対応するべきです。

次のことができるオフライン・同期モデルを探しましょう。

1. 送信操作をローカルで一時保存する。
2. その操作に安定した識別子を割り当てる。
3. 再接続後に安全に再試行する。
4. 重複送信を避ける。
5. サーバーの受領確認と状態を照合する。
6. オフライン中に取り逃した変更を取得する。

送信待ちの間にネットワーク上のデータとローカル送信キューをどう保護するかは、分けて尋ねてください。E2EEだからといって、ローカルキューが保存時に暗号化されている証明にはなりません。

ネットワークの再試行で、本来エンドツーエンド暗号化されているメッセージの平文コピーを配送サービスへ渡す必要があってはいけません。

9. アップロードや保存済みオブジェクトへのアクセスはどう認可されるか

メディアの安全性には暗号化以外も含まれます。

サービスは、アバター、メッセージ添付ファイル、壁紙、ストーリー、一時アップロード、生成されたサムネイルを扱う場合があります。それぞれのオブジェクトにアクセス方針が必要です。

アプリが次のことを行うか確認してください。

• 非公開メディアの取得に認証を要求する
• 要求したアカウントが対象の会話に属することを確認する
• 公開素材と非公開メッセージのオブジェクトを分離する
• 紐づけられていないアップロードを整理する
• 期限切れの一時オブジェクトを削除する
• アカウントをまたぐキャッシュを防ぐ
• 予測困難な識別子を使いつつ、予測困難さを認可の代わりにしない

非公開の平文ファイルが、URLを推測されただけで読めてはいけません。暗号化オブジェクトでは、鍵とアクセス権限がどのように配布・失効されるかを確認しましょう。OWASPの認可ガイドは、静的リソースも含めアクセス判断を一貫して適用することを勧めています。予測困難な識別子だけでは完全な認可方針にはなりません。

10. グループチャットは異なる方法で保護されるか

グループの暗号化とメンバー管理には、個別チャットの暗号化とは異なる論点があります。

メンバー変更、複数端末、メッセージ履歴、管理者の役割、招待、削除、鍵の更新は、いずれも設計上の追加要件を生みます。

個別チャットとグループの両方でE2EEを提供するサービスもあります。一方、個別会話だけにE2EEを提供し、グループはTLS、認証付きストレージ、サーバー側アクセス制御で保護するサービスもあります。

後者も意味のある安全性を提供できますが、信頼境界は異なります。

サーバーがグループの内容を処理できるか、また次のときに保護が変わるかを尋ねてください。

• メンバーが参加する
• メンバーが退出する
• 管理者が誰かを削除する
• メッセージを編集する
• 履歴を新しい端末へ同期する
• ボットや連携機能がグループに入る

ある種類の会話に表示された鍵が、ほかのすべての種類にも自動的に当てはまるとは考えないでください。

11. ユーザーにはどのようなプライバシー設定があるか

プライバシーには、情報がサービスに届いた後の管理も含まれます。

次のような実用的なアカウント・会話の管理機能を探しましょう。

• アカウントデータのエクスポート
• アカウントの削除
• セッションの失効
• ローカル履歴や同期済み履歴の消去
• 許可される範囲での送信済みメッセージ削除
• 既読通知の管理
• プロフィール公開範囲の設定
• 望まない連絡先のブロック
• 通知プレビューの管理
• 鍵バックアップの無効化や削除

事業者は、削除によって自分のコピーだけが消えるのか、全参加者のコピーが消えるのか、サーバー上の記録自体が消えるのかを説明するべきです。

受信者はすでにメッセージをダウンロード、コピー、転送、撮影しているかもしれません。どの削除機能も、すべての端末からの消去を保証できません。

12. セキュリティ上の主張は具体的で検証できるか

優れたセキュリティ文書は境界を定義します。

次の点に関する具体的な記述を探してください。

• アルゴリズムと鍵長
• クライアント側とサーバー側の処理
• E2EEの対象となる会話の種類
• メディアの暗号化
• 保存する情報
• 認証
• 復旧
• 鍵の変更
• アクセス制御
• 既知の制約
• 文書の最終更新日

次のような曖昧な表現には注意しましょう。

• 破れない暗号化
• 絶対的なプライバシー
• 軍用レベルの安全性
• 完全な匿名性
• メタデータゼロ
• ハッキング不可能
• 将来も無敵の暗号化

複雑な通信システムを、標語だけで評価するべきではありません。

独立監査、公開技術文書、再現可能なクライアント、専門家のレビュー、範囲が明確なセキュリティ報告は、追加の安心材料になります。証拠の強さはすべて同じではありませんが、裏づけのない最上級の表現より有用です。

安全なメッセージサービスの良い兆候と警告兆候

良い兆候	警告兆候
事業者がE2EEの対象となる会話を明示する	すべての機能を単に「暗号化」と説明する
秘密鍵の所有関係を説明する	鍵の扱いを一切説明しない
鍵の変更が見える	鍵が無通知で変わり得る
復旧の制約を文書化する	方法を説明せずサポートがすべて復元できるとする
メタデータの種類を列挙する	定義なしに「メタデータゼロ」をうたう
メディア保護を別に説明する	テキストメッセージだけに言及する
グループの信頼境界を定義する	個別チャットの主張がグループにも及ぶと示唆する
セキュリティページに現在の実装詳細がある	宣伝文句が技術文書と矛盾する
制約を明示する	絶対的、または破れない保護を主張する

Livaraの公開された主張にチェックリストを当てはめる

Livaraのセキュリティページは製品文書であり、独立した認証ではありません。現在の境界では、次のように区別されています。

• **個別メッセージ：**LVR1はP-256とML-KEM-768を組み合わせた鍵合意と、対応する内容への認証付き暗号を使用します。
• **互換性のある非公開グループ：**LGS1の送信者鍵による保護を使います。メンバーシップと役割は、別のサーバー権限境界のままです。古い非互換グループにE2EEの表示を引き継がせるべきではありません。
• **公開チャンネル：**サーバーが内容を読めるため、E2EEではありません。
• **復旧：**本人性情報はアップロード前に暗号化して封じられます。その復元はチャット履歴の復元ではありません。
• **メタデータと端末：**配送経路の記録と侵害された端末は、内容暗号化の約束の対象外です。

これらは、インストールしているバージョンや脅威モデルと照らして確認すべき主張として扱ってください。プロトコル仕様、ローカルのテストベクトル、特定バージョンの監査、実稼働サービスの観察は、それぞれ異なる形の証拠です。証拠の不足を、完全な安全性や実証済みの脆弱性という思い込みで埋めないでください。

60秒で確認する安全なメッセージのチェックリスト

アカウントを作る前に、各質問に答えられるか確認しましょう。

• どの種類の会話がエンドツーエンド暗号化されますか。
• 画像、動画、文書、音声メッセージも対象ですか。
• 秘密鍵は参加者の端末で生成・保持されますか。
• 連絡先同士で鍵のフィンガープリントや安全番号を比較できますか。
• 鍵の変更が見えますか。
• プライバシーポリシーで保存するメタデータが示されていますか。
• アカウント認証の説明がありますか。
• 鍵の復旧手順は通常のサインインと分かれていますか。
• 非公開メディアの要求には認証と認可が行われますか。
• オフライン送信待ちでも暗号化は維持されますか。
• グループとチャンネルに正確なセキュリティ境界がありますか。
• 誇大な約束をせずに制約が記載されていますか。

答えがない項目は「不明」とし、自動的に「安全」「危険」と判定しないでください。事業者がすべての競合と同じ構成を採用する必要はありません。

ただし、ユーザーが何を信頼しているか理解できるだけの、正確な回答は必要です。

最も安全な選択は脅威モデルによって異なる

どんな人、どんな状況にも自動的に最適となる、万能のメッセージアプリはありません。

家族のグループ、職場、記者と情報源、医療チーム、公開コミュニティでは、次の要素の異なる組み合わせが必要になる場合があります。

• 機密性
• 本人確認
• 匿名性
• グループ管理
• メッセージ保持
• 法規制への対応
• 復旧
• 複数端末への対応
• オープンソースのコード
• 独立監査
• 使いやすさ

まず、何を誰から守るのかを考えてください。

日常的な個人のやり取りでは、主なリスクはアカウント盗難、安全でないネットワーク、端末の紛失、過剰なデータ収集かもしれません。

リスクの高い通信では、検証済みの身元、消えるメッセージの運用方針、強化した端末、厳格な運用手順、独立したセキュリティレビューも必要になる場合があります。

暗号化は侵害された端末を修復できず、信頼した受信者がメッセージを共有することも防げません。

プライバシーは正確な期待から始まる

信頼できるメッセンジャーは、すべてのリスクが消えたと信じるようユーザーに求めません。

次のことを説明します。

• 何が保護されるか
• どの端末が鍵を持つか
• サーバーが何を処理するか
• どのメタデータが残るか
• 復旧がどう機能するか
• E2EEがどこで始まり、どこで終わるか
• まだ実装していない保護は何か

その明確さによって、ユーザーは十分な情報に基づいて判断できます。

明確な文書は評価に必要ですが、それだけで最も安全なアプリを決めるには足りません。実装の品質、迅速な更新、独立した調査結果、実際の利用に伴うリスクも重要です。EFFのツール選択ガイドも、自分の脅威から考え、公開性を保証ではなく検証の機会として捉えるよう勧めています。

次の一歩として、無害な試用を行いましょう。一人の連絡先を検証し、サンプルの添付ファイルを送り、リンク済み端末を確認し、バックアップの範囲を調べ、双方が設定を確実に扱えるか確認してください。守ろうとしている機密資料をテストに使ってはいけません。

よくある質問

何がメッセージアプリを安全にするのですか。

安全なメッセージアプリは、保護されたネットワーク通信、強い認証、慎重なアクセス制御、安全な鍵管理、責任あるデータ処理、明確に文書化されたプライバシー境界を組み合わせます。非公開のメッセージ内容には、エンドツーエンド暗号化が重要な追加の保護層になります。

暗号化メッセージアプリなら自動的にプライバシーも守られますか。

いいえ。メッセージ内容を暗号化しながら、アカウント情報、タイムスタンプ、メンバー情報、配信確認、端末情報、その他のメタデータを処理することは可能です。プライバシーは暗号化と、サービス全体のデータ取扱いの両方に左右されます。

エンドツーエンド暗号化は誰とやり取りしたかも隠しますか。

必ずしもそうではありません。E2EEは主に対応するメッセージ内容を保護します。会話の配送と同期のために、サービスは送信者、受信者、メンバー、時刻、経路の情報を必要とする場合があります。

メッセージ事業者はE2EEのメッセージを復元できますか。

鍵とバックアップの設計によります。事業者が暗号化されたメッセージ履歴を保存していても、それを開く秘密鍵を持たない場合があります。復旧システムは、ユーザーが別の復旧用秘密情報を提供したときだけ鍵を復元できるかもしれません。

ブラウザー上の安全なメッセージ機能は安心して使えますか。

ブラウザーは強力なクライアント側暗号処理を実行できます。ただし、安全性はアプリの実装、ブラウザーの完全性、端末の安全性、鍵の保存、サーバーからのアプリコード配信、ユーザーの拡張機能やOSにも依存します。

グループチャットは常にエンドツーエンド暗号化されていますか。

いいえ。グループにE2EEを提供するサービスもあれば、個別会話だけに適用するサービスもあります。正確な境界は事業者の文書を確認してください。

暗号鍵が変わるとどうなりますか。

新しい端末、再インストール、鍵のリセット、復旧手順によって鍵が変わる場合があります。安全なメッセンジャーは変更を見えるようにし、連絡先が新しいフィンガープリントを検証できるようにするべきです。

非常に機微な通信にはE2EEだけで十分ですか。

E2EEは対応する端末間の内容を保護しますが、感染した端末やロック解除済みの端末は守れず、受信者の行動も保証せず、メタデータを自動的に隠すものでもありません。リスクの高いユーザーには、強い端末保護と運用上の安全対策も必要です。