Chaos and Order

💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

원문 렌더가 준비되기 전까지 텍스트 가이드로 표시합니다.

プロローグ — なぜ2026年にまたメッセージングなのか

2010年代後半、セキュアメッセージングは「SignalかWhatsApp」の二語でほぼ整理されていた。WhatsAppがSignalプロトコルを採用した2016年4月以降、一般ユーザーにとってエンドツーエンド暗号化(end-to-end encryption、E2EE)はもはや選択肢ではなくデフォルトとなった。iMessageも、Telegramのシークレットチャットも、WireもThreemaも、すべてその変奏だった。

2026年春は異なる。三つの出来事が風景を変えた。

第一に、2023年7月にIETFがRFC 9420としてMLS(Messaging Layer Security)を正式に標準化した。エンドツーエンドグループメッセージングの鍵合意を「ツリーベース」で定義したこの標準は、大規模グループにおける鍵更新コストを対数時間に縮めた。2024年以降WhatsApp、Webex、X PremiumがMLSを順次採用した。

第二に、2023年9月にSignalがPQXDHを発表した。X3DH(extended triple Diffie-Hellman)の後継で、CRYSTALS-Kyberベースの鍵カプセル化を加えて量子コンピュータに対する事前防御を作った。「今盗聴しておいて後で復号する」というhold-now-decrypt-later攻撃に対する最初の量産的回答だった。

第三に、2024年9月にSignal Foundationの信頼委員長の席が変わった。Trust Ackerが辞任し、Meredith Whittaker会長がより強い発言権を持つようになった。Signalは依然として黄金標準である。この事実は変わらない。

そしてその間に、より小さな陣営が自らの座を固めた。SimpleXは「ユーザーID自体を持たない」設計でメタデータ抵抗の新しい基準を作り、SessionはLoki/Oxen分散ネットワークでSignalプロトコルを匿名化した。Briarはインターネットが切断された環境でもBluetooth/Wi-Fi Directで動作するP2Pを実証し、CwtchはTorの上に匿名グループチャットを乗せた。Wireは欧州企業市場に、Threemaはスイス有料市場に、Olvidはフランス政府に、Wickrのコンシューマ版はAWSの手で消えた。

2026年春、私たちはもはや「Signalを使ってください」とだけ言うことはできない。誰が使うのか、どの脅威モデルか、メタデータをどこまで隠したいかによって選択肢が異なる。本稿はそのすべての枝を14章で整理する。

第1章 · 2026年セキュアメッセージング地図 — 中央集権 / 連合 / P2P 三つのモデル

2026年のセキュアメッセージングを一枚の地図に描くと、三つのアーキテクチャが現れる。

**1. 中央集権型(centralized)** — 単一企業がサーバインフラを運営。Signal、Threema、Wire、WhatsApp、iMessage、Telegramがここに属する。ユーザー登録は電話番号やメールまたはIDに紐付き、メッセージはすべてのユーザーが同じサーバクラスタを経由する。長所は単純さと一貫したユーザー体験。短所は会社が消えたり方針を変えたりするとユーザーも一緒に影響を受けることだ。

**2. 連合型(federated)** — 複数のサーバが互いに通信するモデル。Matrix.orgエコシステムが代表的。あるサーバのユーザーが別のサーバのユーザーと自由に対話でき、ユーザーは自分のサーバを直接運営することもできる。XMPP + OMEMOも依然としてこのモデルを保つ。長所は自律性と検閲耐性。短所はサーバ運営の負担と、クライアントによってユーザー体験が分かれることだ。

**3. P2P / 分散型(peer-to-peer / distributed)** — サーバを取り除くか、匿名分散ネットワークの上に乗せたモデル。SimpleX(メッセージのルーティングはサーバを経由するがユーザーIDはサーバに存在しない)、Session(Loki/Oxenノード網)、Briar(Bluetooth/Wi-Fi Direct/Tor)、Cwtch(Torベース)がここに属する。長所はメタデータ抵抗の極限。短所はユーザー体験が荒く、グループチャットやメディア転送に大きな制約があることだ。

三つのモデルはそれぞれ異なる脅威モデルを前提とする。中央集権型は「会社を信頼できる」を前提とし(Signal Foundationの非営利構造がこの信頼を強化)。連合型は「自分のサーバまたは自分が選んだサーバを信頼する」を前提。P2Pは「いかなる単一主体も信頼しない」を前提とする。

本稿の第2〜4章は中央集権型(Signal)、連合型(Matrix)、P2P(SimpleX)を扱う。第5〜7章はより小さな分散陣営(Session、Briar、Cwtch)。第8章は企業/有料/政府市場。第9〜11章はプロトコル層(MLS、sealed sender、ポスト量子)。第12〜14章は適用事例(WhatsApp MLS、韓国、日本)。最後の第15章は誰が何を選ぶべきかを整理する。

第2章 · Signal — 標準の座、PQXDHとMeredith Whittakerの時代

Signalは2026年も依然として黄金標準である。セキュリティ研究者が一般人に最初に勧めるメッセンジャーであり、米国と欧州の活動家、ジャーナリスト、弁護士、セキュリティ専門家が最も広く使うツールだ。その座を作ったのは三つだ。

**第一に、Signalプロトコル。** ダブルラチェット(Double Ratchet)+ X3DH(extended triple Diffie-Hellman)の組み合わせ。ダブルラチェットはメッセージごとに鍵を変えて、一つのメッセージ鍵が漏洩しても過去と未来のメッセージが安全に保たれるようにする。X3DHは二人のユーザーが初めて出会った時に非対称鍵合意を安全に行う。この組み合わせは2014年頃にモクシー・マーリンスパイク(Moxie Marlinspike)とトレバー・ペリン(Trevor Perrin)が作り、その後WhatsApp、Facebook Messenger、Skype Private Conversations、Google Allo、Wireがすべてこれを採用した。

**第二に、2023年9月のPQXDH。** Signalブログ(signal.org/blog/pqxdh)で発表されたPQXDHは、X3DHにCRYSTALS-Kyberベースの鍵カプセル化メカニズム(KEM)を追加した。すなわち、クラシックなX3DH(楕円曲線)と耐量子KEMを同時に実行し、両者の結果を合わせてセッション鍵を導出する。二つのうち一つだけでも安全ならばセッションは安全だ。「今盗聴しておいて後で量子コンピュータで復号する」hold-now-decrypt-later攻撃に対する最初の産業的回答だった。Apple iMessageも2024年2月にPQ3で同様の道を辿った。

**第三に、非営利財団構造とMeredith Whittaker。** Signal Foundationは2018年にモクシー・マーリンスパイクとブライアン・アクトン(元WhatsApp共同創業者)が一緒に設立した。アクトンは5000万ドルの無利子貸付で財団を出発させた。2022年にマーリンスパイクはCEO職を退き、2024年からMeredith Whittaker(元Google、AI Now Institute共同創立者)が会長として地位を固めた。Whittakerは公然と強く発言する人だ。2024年5月にはEUのChat Control法案に対して「SignalはEU市場を離れる」と明示し、同年6月の英国Online Safety Billについても同様の立場を堅持した。

**2024年9月の信頼委員長辞任。** 詳細な人事事情は公開されていないが、Signal Foundationのガバナンス委員会の一部が交代し、Whittakerの発言権はより強くなった。外部の視点では、これはSignalが「技術標準」から「政治的立場」へとさらに一歩進んだ信号として読まれた。米議会のEARN IT Act、EUのChat Control、英国のOnline Safety Billのようなバックドア強制立法に対して、Signalは「我々は去る」を明確にする数少ないメッセンジャーだ。

**Signalの弱点はメタデータ。** メッセージ内容は完璧に暗号化されるが、誰がいつ誰と対話したかというメタデータはサーバ運営者が一部見ることができる。Signalはこれを減らすためにsealed sender(2018)、private contact discovery(SGXベース)、ユーザー名(2024年ベータ)のような機能を順次追加してきた。しかし電話番号登録という基本モデルは依然そのままで、これがSimpleXやSessionのような陣営が批判する点である。

**2026年現在Signalは:** ユーザー数約7000万〜1億人(公式数字は非公開)、Android/iOS/デスクトップ(Windows、macOS、Linux)対応、グループチャット最大1000人、グループ通話最大50人、ビデオ通話、ステッカー、ストーリー(2022)、ユーザー名(2024)、PQXDH(2023.9)、ロックされたチャット(2024)。次のステップはPQXDHのダブルラチェット統合(現在は初期合意のみ耐量子)と、メタデータをさらに減らす方向のグループチャット再設計だという。

第3章 · Matrix.org + Element X — Rustで書き直したクライアント

Matrixは2014年にAmdocsから分社した新しい非営利財団(現Matrix.org Foundation)が作った連合型メッセージングプロトコルである。XMPPができなかったことをやり直してみるという野心から出発し、2017年の1.0リリース以降、最大の連合型メッセージングエコシステムとして地位を固めた。

**核心概念。** Matrixは「メッセージ」ではなく「ルーム(room)」を中心に設計された。ルームは一つの分散状態(eventually-consistentなJSONイベントのグラフ)であり、複数のサーバに同時に存在する。あるサーバがダウンしても、そのサーバ以外のユーザーが送ったイベントが他のサーバに複製されている限り、ルームは生きている。

**ホームサーバ(homeserver)とID。** ユーザーは@alice:matrix.orgのようにユーザー名+ホームサーバ形式のIDを持つ。Synapse(Python参照実装)、Dendrite(Go)、Conduit(Rust)が代表的なホームサーバ実装だ。自分のサーバを運営すれば自分のデータを持てる。運営が負担なら、matrix.org、beeper.com、Elementのようなホスティングサービスを使えばよい。

**E2EE(Olm + Megolm)。** Matrixのエンドツーエンド暗号化は二層構造になっている。1:1の対話はOlm(Signalのダブルラチェットに着想を得たライブラリ)。グループの対話はMegolm(group ratchetで大きなグループでも一つのメッセージを一度だけ暗号化する)。Olm/MegolmはMatrix仕様の一部であり、すべての互換クライアントが同じアルゴリズムを使う。

**Element X — Rustで書き直したクライアント。** 2022〜2023年にElementは既存のReact NativeベースのElementモバイルを捨て、コアSDKをRustで書き直したmatrix-rust-sdkの上に新しいクライアントElement Xを作った。2024年に正式リリースされたElement Xは(1)sliding syncで遅かった初期同期を高速化し、(2)メッセージ検索をクライアント側インデックスで即時可能にし、(3)UIを単純化して新規ユーザーの参入障壁を下げた。同じRust SDKはデスクトップ(Element Desktopの次世代)にも入る。

**sliding sync(MSC3575)とは。** 既存の/sync APIはすべてのルームの状態を毎回要求するため、数百のルームを持つユーザーの初回ログインが数十秒かかっていた。sliding syncは「今表示されている画面に必要なルームだけを優先して同期」する方式。モバイルでアプリを開くなり最新の対話がすぐ見え、スクロールすると残りが段階的にロードされる。

**連合型の政治学。** Matrixは2020年からフランス政府の公式メッセンジャー(Tchap)、ドイツ軍のBwMessenger、米軍の一部通信インフラに採用された。自分のサーバを運営できる点、オープンソースである点、そして標準が公開されている点が政府採用の核心理由だった。2024年にはNATOの一部チャンネルにも入った。

**Matrixの弱点はメタデータ。** 連合型なので一つのサーバ運営者がすべてのメッセージを見ることはできないが、自分のサーバのユーザーがどのルームに属し、どのユーザーと頻繁に対話するかは十分に見える。Matrix財団はsliding syncと共にMSC1228(decentralized user IDs)のようにメタデータを減らす方向の仕様を進めている。

**2026年現在Matrixは:** 公式発表ユーザー約8000万人(homeserverアクティブアカウント基準)、Element X(iOS/Android)、Element Desktop、Cinny、FluffyChatのようなクライアントがある。企業/政府市場ではSynapse + Elementを一度にまとめて売るElement Server Suiteが主力。ビデオ通話はElement Call(2024年正式、WebRTC SFUベース)。

第4章 · SimpleX — ユーザーIDの無い分散メッセージング

SimpleX(simplex.chat)は2021年頃に出発した比較的新しいメッセンジャーだ。出発点は単純な質問だった。「なぜメッセンジャーにユーザーIDが必要なのか?」

電話番号(Signal、WhatsApp)、メール(Wireの一部)、Matrix ID(Matrix)、ユーザー名(Telegram、Threema、Session)はすべて、サーバがユーザーを識別する単一識別子だ。この単一識別子が存在する限り、サーバは「誰が誰と対話したか」のグラフを作ることができる。

**SimpleXの答え。** ユーザーIDをなくす。SimpleXはユーザーではなく「キュー(queue)」を識別子として使う。二人のユーザーが初めて接続する時、一方が使い捨てのSMP(Simplex Messaging Protocol)キューを作り、そのアドレスをQRコードやリンクで相手に直接渡す。相手はそのキューに最初のメッセージを送り、二人のユーザーはその中で鍵を交換する。以降、すべてのメッセージは彼らだけが知るキューにルーティングされる。サーバには「あるユーザー」ではなく「あるキュー」だけが存在する。

**複数のSMPサーバ。** SimpleXは自前のSMPサーバを運営するが、誰でも自分のSMPサーバを運営でき、ユーザーは複数のサーバを同時に使える。一つの対話の送信キューと受信キューが互いに異なるサーバに置かれることもある。こうすればどの一つのサーバ運営者も両側のメッセージフローを両方とも見ることはできない。

**E2EE。** SimpleXは自前のダブルラチェット実装を使う。2024年からはPQXDHスタイルの耐量子KEMもオプションとして追加された。

**グループチャット。** グループはユーザー間のメッシュとして実装されている。一つのメッセージをグループのすべてのメンバーに送るには、送信者がメンバー数だけ各キューにメッセージを送る。この構造は大きなグループ(数百人以上)では非効率だが、メタデータ抵抗を最大化する代償だ。2025年以降、SimpleXはsuper-peerベースのグループルーティングを追加してこのコストを減らしている。

**弱点。** (1)UI/UXが荒い。(2)複数デバイス間の同期が制限的(原理上、各デバイスが別ユーザー)。(3)電話番号がないので連絡先を見つける方法がQRコード/リンク共有しかない。(4)プッシュ通知が他のメッセンジャーより遅い。

**誰が使うか。** 高リスクの活動家、ジャーナリスト、セキュリティ研究者が主要なユーザー層だ。一般ユーザーに勧めるのは難しいが、「メッセージ内容だけでなく誰と対話したかさえも隠したい」ユーザーにはほぼ唯一の選択肢に近い。

第5章 · Session — Signalプロトコル + Loki/Oxen分散

Session(getsession.org)は2019年にオーストラリアのLoki Foundation(現Oxen Foundation)が作ったメッセンジャーだ。出発はSignal Androidのフォークだった。Signalの検証済みエンドツーエンド暗号化はそのまま使いつつ、サーバ依存を取り除き、匿名ネットワーク上で動作するようにした。

**Loki/Oxenネットワーク。** SessionはLoki(現Oxen)ブロックチェーンのサービスノード(service node)ネットワーク上で動作する。ユーザーがメッセージを送ると、そのメッセージはonion routeを経由して受信者の「スワーム(swarm、メッセージ保存ノードクラスタ)」に到達する。受信者は自分のスワームをポーリングしてメッセージを受け取る。この構造はTorと似た匿名性を提供するが、Torと違ってメッセージ保存(store-and-forward)も可能だ。

**ユーザーID。** Sessionは電話番号もメールもユーザー名も使わない。ユーザーはランダムに生成された66文字のSession ID(公開鍵ベース)を持つ。このIDを相手と直接交換すれば対話を開始できる。

**E2EE。** 初期にはSignalプロトコル(ダブルラチェット + X3DH)をそのまま使っていたが、2021年に1:1チャットではSession Protocol(自前の単純化バージョン)に変えた。グループチャットではClosed Groups(エンドツーエンド暗号化された小さなグループ、最大100人)とOpen Groups(サーバに平文で保存される大きなグループ)がある。2024年からMLSベースの新しいグループプロトコルへの移行が進行中だ。

**弱点。** (1)Loki/Oxenブロックチェーンに依存するので、そのエコシステムが困難になればSessionも影響を受ける。(2)メッセージ伝達遅延が他のメッセンジャーより大きい(スワームポーリングモデルのため)。(3)Closed Groupsの鍵ローテーションが非効率だ。

**誰が使うか。** 匿名性を重視しつつ、Signalよりも強いメタデータ抵抗を望むユーザー。ダークネット市場ユーザーと活動家が大きな比重を占める。

第6章 · Briar — インターネットが無くても動作するP2P

Briar(briarproject.org)は英国で2014年頃に出発したAndroid専用メッセンジャーだ。出発点はまた別の質問だった。「インターネットが切断された環境、または政府がインターネットを遮断した環境でも動作するメッセンジャーは可能か?」

**3種類の伝送方式。** Briarは同じメッセージを三つの方式で伝送できる。

1. **Tor over Internet** — インターネットがある時、Tor隠しサービスを通じて二つのデバイスが直接接続される。中央サーバはない。

2. **Wi-Fi Direct** — 同じWi-Fi網にある時、またはWi-Fi Directで直接接続。

3. **Bluetooth** — インターネットもWi-Fiも無い時、Bluetooth範囲(約10メートル)内で直接メッセージ交換。

この三つは同じアプリ内で自動的に切り替わる。第一が失敗すれば第二を試み、それも失敗すれば第三を試みる。

**なぜ意味があるか。** 2011年アラブの春でエジプト政府がインターネットを遮断した時、2019年香港デモでデータトラフィックがモニタリングされた時、2022年イランデモで通信が検閲された時、すべて「インターネットが遮断された状況でどう通信するか」が核心問題だった。Briarはそのシナリオのために設計された。

**E2EE。** Briarは自前のプロトコル(Bramble Transport Protocol、BTP)を使う。ダブルラチェットと似た構造だが、メッセージ伝達信頼性(特にインターネットが間欠的な環境で)を最優先する。

**弱点。** (1)Android専用。iOSバージョンは長らく計画だけある(2026年春時点でベータ)。(2)グループチャットが小さい(最大数十人)。(3)同じWi-Fi/Bluetooth範囲にいる必要があるためP2Pモードが動作し、一般ユーザーには活用度が低い。(4)プッシュ通知がない(サーバが無いので原理上不可能)。

**誰が使うか。** デモ現場、検閲環境の活動家、インターネットインフラが不安定な地域。またセキュリティ研究の参照実装としてもよく引用される。

第7章 · Cwtch — Torの上に匿名グループチャット

Cwtch(cwtch.im、ウェールズ語で「抱擁」の意味)はカナダのOpen Privacy Research Societyが作ったメッセンジャーだ。2018年頃に始まり、2022年に1.0が出た。

**核心設計。** CwtchはすべてのメッセージをTor隠しサービスを通じてルーティングする。ユーザーIDはTor v3 onionアドレス(56文字)だ。メッセージは二人のユーザー(またはグループ)のonionアドレスの間で直接流れる。中央サーバはない。

**メタデータ抵抗。** CwtchはBriarよりさらに一歩進んでいる。(1)ユーザー識別子がonionアドレスのみ。(2)すべてのトラフィックがTorを通過。(3)グループメッセージはグループ鍵で暗号化され、任意のuntrustedサーバ(誰でも運営可能)に保存され、グループメンバーのみ復号可能。すなわちサーバ運営者は誰がグループに属しているかさえ知らない。

**弱点。** (1)Tor依存なので遅い。(2)プッシュ通知がない。(3)グループ運営にuntrustedサーバを選ばなければならない負担がある。(4)UI/UXが技術者向けだ。

**誰が使うか。** メタデータ抵抗を最優先に置くセキュリティ研究者、ジャーナリスト、高リスク活動家。

第8章 · Wire / Threema / Olvid / Wickr — 企業 / 有料 / 政府 / 消えたもの

この節は中央集権型陣営の四つの変奏である。

**Wire(wire.com)。** 2014年スイスで出発(後にベルリンに本社移転、米国資本買収)。最初はコンシューマメッセンジャーとして始まったが、2019年以降は企業市場(Wire for Business、Wire Red)に集中。Signalプロトコルの変種(Proteus)を使い、2022年にMLSベースのグループメッセージングへ移行。ドイツ連邦政府と一部EU機関が採用した。コンシューマ版は依然無料だが、会社の核心売上は企業だ。

**Threema(threema.ch)。** 2012年スイスで出発。有料メッセンジャー(2026年春時点で約4.99 CHFの一度限り決済)で、電話番号無しのランダム8文字のThreema IDで動作する。スイスデータ保護法の強力な保護を受け、2017年にコードをオープンソース公開した(GitHubのthreema-android、threema-ios)。スイス軍と政府、一部欧州企業、そしてプライバシー意識の強い一般ユーザーが使う。ユーザー数は約1100万人(2024年公式)。

**Olvid — フランス政府買収(2023)。** Olvidは2019年にフランスで出発したメッセンジャーだ。最大の特徴は「いかなるディレクトリサービスも信頼しない」という原則。二人のユーザーが初めて接続する時、直接会うか安全なチャネルで鍵を交換しなければならない。2023年11月、フランス政府がすべての大臣と公務員の公式メッセンジャーとしてOlvidを採用すると発表し、同じ頃に会社の持分の相当部分を購入した。詳細な買収条件は非公開。コンシューマ用無料版はそのまま提供されるが、ガバナンスには変化がある。

**Wickr — AWSのコンシューマ終了(2023)。** Wickrは2012年米国で出発したメッセンジャー。2021年にAWSが買収し、2022年にAWS Wickrサービスに統合された。2023年1月、AWSは無料コンシューマ版(Wickr Me)を終了し、以降Wickrは政府/企業/AWS顧客専用ツールとなった。かつてダークネットでよく使われていたWickr Meの終了は、そのユーザー層がSession、SimpleX、Signalに分散する結果をもたらした。

第9章 · XMPP + OMEMO — 古いプロトコルが今も生きている理由

XMPP(Extensible Messaging and Presence Protocol)は1999年にJabberという名前で出発し、2002年にIETFで標準化された最も古い連合型メッセージングプロトコルだ。かつてGoogle Talk、Facebook Chat、WhatsApp初期バージョンがすべてXMPP変種を使っていた。

**OMEMO(OMEMO Multi-End Message and Object Encryption)。** 2015年にXEP-0384として標準化されたXMPPエンドツーエンド暗号化拡張。Signalプロトコルのダブルラチェットとほぼ同じアルゴリズムをXMPPのメッセージフローの上に乗せたもの。Conversations(Android)、Dino(デスクトップ)、Gajim、Beagle IM、Siskin(iOS)のようなクライアントがOMEMOをサポートする。

**なぜ今も生きているか。** (1)標準が完全に公開されており参入障壁が低い。(2)セルフホスティングが容易(Prosody、ejabberdのような軽いサーバがある)。(3)互換クライアントが多様。(4)自分のデータを自分のサーバに置きたい技術ユーザーに魅力的。

**誰が使うか。** 自前のインフラを運営する小規模組織、自分のドメインのIDを持ちたい個人ユーザー、そして一部の非政府機関(NGO)。Matrixに比べてユーザー体験は荒いが、インフラ負担が軽い。

第10章 · MLS(RFC 9420、2023.7) — グループメッセージングの新しい標準

2023年7月にIETFがRFC 9420としてMLS(Messaging Layer Security)を正式に標準化した。MLSはエンドツーエンドグループメッセージングの新しい基盤プロトコルだ。

**なぜ新しい標準が必要だったか。** Signalのダブルラチェットは1:1と小さなグループでは効率的だが、大きなグループ(数百〜数千人)では鍵更新コストがグループサイズに比例する。あるメンバーがグループを離れたり新しいメンバーが入るたびに、すべてのメンバーの間の鍵を再合意しなければならない。

**TreeKEM。** MLSの核心はTreeKEMというツリーベースの鍵合意アルゴリズムだ。グループメンバーを二分木の葉(leaf)に配置し、各内部ノード(internal node)はその下の葉の共有鍵を持つ。あるメンバーを追加または削除する時、そのメンバーの葉から根(root)までの経路(path)にある鍵だけを更新すればよい。この経路の長さはグループサイズの対数(log)であり、したがって鍵更新コストも対数時間だ。

**Forward secrecyとpost-compromise security。** MLSは二つのセキュリティ属性を共に保証する。forward secrecyは「一つの鍵が漏洩しても過去のメッセージは安全」を、post-compromise securityは「一つの鍵が漏洩しても次の鍵更新以降のメッセージは再び安全」を意味する。ダブルラチェットが1:1で保証するのと同じ属性を、MLSは大きなグループでも保証する。

**核心RFC。**

- RFC 9420: The Messaging Layer Security (MLS) Protocol(2023年7月)

- RFC 9421: MLS Architecture(同時期)

- その他MLS extensions(メタデータ保護、federationなど)はIETFで進行中

**実装。** OpenMLS(Rust)、mls-rs(AWSのRust)、MLSpp(C++)、js-mlsなど複数の実装がある。すべてRFC 9420互換を目標とする。

**限界。** MLSは鍵合意の効率を解決したが、「誰がグループに属しているか」のメンバーシップメタデータは依然としてサービスプロバイダが知ることができる。メタデータ保護はMLSの次段階拡張として進行中だ。

第11章 · Sealed Sender / メタデータ抵抗技法

E2EEはメッセージ内容は隠すが、「誰がいつ誰に送ったか」のメタデータはそのまま露出する。メタデータ抵抗はこの露出を減らす一連の技法だ。

**Sealed Sender(Signal、2018)。** Signalが導入した最初のメタデータ保護技法。送信者のIDを別の封筒(envelope)で暗号化して受信者のみ復号できるようにする。サーバは「Xに何らかのメッセージが到着した」事実は知るが、「誰が送ったか」を直接見ることはない。ただし、受信者のIDは依然として見える。

**Private Contact Discovery(Signal)。** ユーザーが自分のアドレス帳のどの番号がSignalユーザーかを確認する時、Intel SGXのようなtrusted execution environmentでマッチングを実行する。サーバは自前のデータベースをどの外部リクエストとマッチングしたかを知らない。

**ユーザー名(Signal、2024)。** 電話番号を露出せずユーザー名で対話を開始できるようにする。メタデータ自体よりは識別子分離に近い変化。

**Onion routing(Session、Cwtch、Briar)。** TorまたはTor類似のonionルーティングを通じて、メッセージの出発地と到着地を同じサーバが見ないようにする。

**No persistent user ID(SimpleX)。** ユーザーID自体を取り除き、キュー(queue)単位でのみ識別。サーバが作ることのできる最大のグラフは「このキューが活性化されている」程度。

**Mixnet(Loopix、Nym)。** メッセージを任意の遅延と共に複数のノードを経由させて、時間相関関係でも追跡が困難になるようにする。一部実験的メッセンジャー(Katzenpost、Nymの上に乗せたツール)が使用。

**現実の限界。** メタデータを完璧に隠すシステムはほぼ常にユーザー体験を犠牲にする。プッシュ通知遅延、同期の困難、グループチャット非効率、メディア転送制約。だから一般ユーザーはSignalのsealed sender程度で十分で、高リスクユーザーのみSimpleX/Cwtchのような極端まで行く。

第12章 · ポスト量子暗号 — SignalのPQXDH(2023.9)

量子コンピュータが十分に大きくなれば、今日使われているRSA、ECDH、ECDSAのような非対称暗号はShorアルゴリズムで解かれる。対称暗号(AES、ChaCha20)とハッシュ(SHA-256、SHA-3)はGroverアルゴリズムで半分の鍵長が破られるが、十分な長さなら安全。

**Hold now, decrypt later。** 量子コンピュータがまだ無いと安心はできない。攻撃者が今日暗号化されたトラフィックを保存しておき、5年または10年後に量子コンピュータで解くシナリオ(harvest now, decrypt later)が現実的な脅威だ。だからメッセージセキュリティは量子以前の時代より早く耐量子へ移行する必要がある。

**SignalのPQXDH(2023年9月)。** X3DHの後継。CRYSTALS-Kyber(NISTが2024年に標準化したML-KEMの前身)ベースのKEMとクラシックなX3DHを同時に実行し、二つの結果を共にハッシュしてセッション鍵を作る。二つのうち一つだけ安全でもセッションが安全。Signalブログ記事「Quantum Resistance and the Signal Protocol」(signal.org/blog/pqxdh)が詳細な仕様を公開した。

**Apple iMessage PQ3(2024.2)。** Appleも同様の時期にPQ3で耐量子鍵合意を導入。さらに「持続的な耐量子再設定」でセッションが長くなっても耐量子性を維持するようにした。Appleのセキュリティブログ(security.apple.com)に仕様公開。

**限界。** (1)ダブルラチェットの毎メッセージ鍵合意はまだECDHベース(2026年春時点)。PQXDHは初期合意のみ保護する。(2)耐量子アルゴリズムは鍵と署名のサイズが大きい(Kyber-768公開鍵約1.2KB)。(3)標準がまだ安定化中(NISTが2024年にML-KEM、ML-DSA、SLH-DSAを正式発表)。

第13章 · WhatsAppがMLSを採用した — 何が変わるか

Metaは2024年からWhatsAppのグループメッセージングをMLSに転換していると公に明らかにしている。Engineering at Metaブログ(engineering.fb.com)で詳細な設計が公開された。

**なぜ転換したか。** WhatsAppの既存グループメッセージングはsender keysモデルだった。各メンバーが自前の送信鍵をグループのすべてのメンバーに予め配布し、その鍵でメッセージを暗号化。メンバーが入るか出るたびにすべてのメンバーが新しい鍵を受け取る必要がある。大きなグループ(1024人以上)でこのコストが非常に大きくなる。

**MLS転換以降。** TreeKEMのおかげで鍵更新が対数時間に縮まる。5000人以上の大きなコミュニティチャンネルでも鍵更新が即時可能になる。またMLSの標準化のおかげで、将来他のメッセンジャーとの相互運用性(interoperability)の可能性が開かれる。

**EU Digital Markets Act(DMA)と相互運用性。** 2024年3月からDMAが発効され、「gatekeeper」地位のメッセンジャー(現在WhatsApp一つだけ指定)は他のメッセンジャーとの相互運用性を提供する必要がある。WhatsAppは自前のブリッジAPIでこれを提供しており、今後標準化されたインターチェンジの候補としてMLSが取り沙汰される。しかし2026年春時点で、Signalと他のメッセンジャーはWhatsAppとの相互運用を拒否した(Signal:「プライバシー低下の懸念」)。

**WhatsAppのメタデータ。** MLS転換とは別に、WhatsAppがMeta本社と共有するメタデータ(連絡先、グループメンバーシップ、使用パターン)は依然として豊富だ。これがSignalとWhatsAppの決定的な違いとして残る。

**他のMLS採用者。** Cisco Webex(2024年)、X(旧Twitter) Premiumの暗号化DM(2024年)、そしてWireが2022年に既にMLSベースのグループへ転換した。Matrixは自前のMegolmを維持するが、MLS統合仕様(MSC2883)が進行中だ。

第14章 · 韓国 — カカオトーク秘密チャット、テレグラム使用

韓国のメッセージング風景は2026年春時点でカカオトークが圧倒的だ。月間アクティブユーザー(MAU)約4800万、事実上すべての韓国居住者が使う。しかしカカオトークの基本チャットはエンドツーエンド暗号化ではない。

**カカオトーク秘密チャット。** 2014年9月導入。Signalプロトコル変種を使うと知られており、1:1とグループ(最大100人)で動作する。一般チャットとは別のメニューから開始する必要があり、マルチデバイス同期に制約があり、一般ユーザーは活用度が低い。2024年末からカカオは一般チャットにも一部E2EE適用を段階的に進めると発表したが、2026年春時点で基本チャットは依然サーバ保存。

**テレグラムの韓国使用。** 2014年9月の「サイバー監視」論争以降、一度大規模な離脱がテレグラムに向かい、以降も政治家、ジャーナリスト、一部活動家がテレグラムを補助チャネルとして使う。しかしテレグラムの基本チャットはエンドツーエンド暗号化ではなく、秘密チャット(secret chat)のみエンドツーエンドだ。また秘密チャットはデバイス間の共有ができない。2020年の「n番部屋事件」でテレグラムの秘密グループが犯罪に悪用された事実が明らかになって以降、韓国社会はテレグラムの政策協力意志に対して批判的だ。

**ライン(LINE)。** カカオトークとは別に、ラインは依然として一部の韓国ユーザー(特に日本居住者とのコミュニケーション)に使われている。ラインのエンドツーエンド暗号化はLetter Sealingという自前の名前の機能で2015年導入。2026年時点で1:1、グループ、音声/映像通話に適用。

**セキュアメッセンジャー使用比率。** 一般韓国ユーザーにSignal、Matrix、SimpleXはまだほとんど使われていない。セキュリティ意識が高い職域(ジャーナリズム、情報セキュリティ、一部法曹)のみで補助チャネルとして使われる。

**立法。** 韓国は2020年代中盤以降、デジタル性犯罪対応を名分にメッセンジャーに対する政府アクセス権限の議論が繰り返された。2024〜2025年に一部立法案が発議されたが、市民社会と業界の反発で通過しなかった(2026年春時点)。

第15章 · 日本 — LINE Letter Sealing、+メッセージ

日本はLINEがカカオトークと類似した位相を占める。MAU約9700万、事実上すべての日本居住者が使う。

**LINE Letter Sealing。** 2015年10月導入されたLINEのエンドツーエンド暗号化。ECDH鍵交換とAES-CBCメッセージ暗号化が基盤。2018年以降グループチャットにも適用され、2020年代に入って音声/映像通話に拡大。LINEは韓国と日本で別の会社として認識されるが、親会社LY Corporationは韓国Naverと日本Softbankが共同所有。

**韓日データ紛争(2023〜2024)。** 2023年LINEヤフーの個人情報漏洩事故以降、日本総務省はLINEのデータ処理に対して「ネイバークラウド依存を減らせ」という行政指導を下した。これは韓国と日本の間の外交的摩擦にも広がった。2024〜2025年LINEヤフーはデータインフラを日本国内に段階的に移転する計画を発表。

**+メッセージ(PlusMessage)。** 日本3大通信社(NTTドコモ、KDDI au、ソフトバンク)が共同運営するRCS(Rich Communication Services)ベースのメッセージングサービス。2018年開始。電話番号で動作し、写真/ステッカー/グループチャットをサポートし、2021年以降エンドツーエンド暗号化もオプションで提供。一般ユーザーの中でLINEの代わりに、または補完として使う人がいる。

**Signalとテレグラムの日本使用。** 日本はSignalとテレグラム両方とも韓国よりも使用比率が小さい。一部の技術者と外国人居住者が使い、一般ユーザーにはほとんど知られていない。

**立法。** 日本は2024年に通信の秘密の保障とサイバー犯罪捜査の間のバランスについての議論があったが、メッセンジャーバックドア義務化のような強い立法はない(2026年春時点)。

第16章 · 誰が何を選ぶべきか — 一般 / 活動家 / 企業 / メタデータ回避

最後の章はユーザータイプ別の推奨だ。

**一般ユーザー(家族、友人、日常)。** Signalを基本メッセンジャーとして推薦。無料、広告なし、よく検証されたエンドツーエンド暗号化、耐量子PQXDH。カカオトーク/LINEを日常で使いつつ、敏感な対話はSignalに移す方式も現実的だ。WhatsAppも同じSignalプロトコルだが、Metaのメタデータ収集モデルを信頼できるかが決定要因。

**ジャーナリスト、弁護士、市民団体。** Signalを一次、Matrix(Element X)を組織内部協業用に。自前のMatrixホームサーバを運営すれば組織のすべてのデータが自前のインフラに留まる。情報源(source)との最初の接触用にはSignalのユーザー名機能が有用。

**高リスク活動家(検閲環境、政府監視対象)。** SimpleXまたはSessionを一次、Briarを非常用に。一般メッセンジャーは使用自体が危険信号になり得るので慎重に。Tor BrowserとともにOSレベル保護(Tails、Qubes OS、GrapheneOSなど)も一緒に検討。

**企業(中小規模)。** Wire for BusinessまたはThreema Work。SaaS形式で始めて必要時に自前ホスティングに転換。Slack/Teamsを補助チャネルに置き、敏感な対話のみエンドツーエンドツールで。

**企業(大規模 / コンプライアンス)。** Element Server Suite(Matrixホスティング + コンサルティング)またはWickr(AWS GovCloud)。データガバナンス、監査ログ、組織ディレクトリ統合が必要な場合。

**政府 / 軍。** Olvid(フランス)、Tchap(フランス、Matrixベース)、BwMessenger(ドイツ軍)、自前ホスティングMatrixが主要選択肢。標準RFC 9420 MLSの採用が今後の標準化の核心。

**メタデータまで避けたいユーザー。** SimpleXとCwtchを併用。同じ人と複数のメッセンジャーで対話してメタデータグラフを分散。電話番号と分離されたデバイス、匿名SIMまたはデータ専用SIM使用も一緒に。

**韓国/日本の一般ユーザーへ。** カカオトークとLINEを離れるのは現実的に難しい。代案は「日常はカカオトーク/ライン、敏感な対話はSignal」の二重使用モデル。家族と友人をSignalに移すことは難しいが、補助チャネルとしてでも置くことが最初の一歩だ。

結論 — 2026年のメッセージングはもはや一行ではない

2010年代の答えは単純だった。「Signalを使ってください。」2026年の答えは長くなった。

- 一般人には依然としてSignal。PQXDHで耐量子性まで補強された黄金標準。

- 組織にはMatrix + Element X。自前のインフラの上でのエンドツーエンド協業。

- メタデータまで隠したいならSimpleXまたはCwtch。使いやすさを犠牲にする代わりに追跡グラフを断つ。

- インターネット遮断環境ではBriar。Bluetoothでも動作する真のP2P。

- 大規模グループと将来の標準化はMLS RFC 9420。WhatsAppが採用し、他のメッセンジャーが追随する。

- 量子コンピュータに備えてはPQXDH(Signal)とPQ3(Apple iMessage)。両方ともhold-now-decrypt-later攻撃を阻む最初の量産的回答。

2026年春、セキュアメッセージングは政治的事件と技術的進歩の間でもう一度再定義されている。Meredith WhittakerのSignalはEUと英国のバックドア立法に対抗して「我々は去る」を明確にする数少ないメッセンジャーであり、MLSはグループメッセージングの新たな基盤となった。その間にSimpleX、Session、Briar、Cwtchはメタデータ抵抗の新しい基準線を作り、Olvidのフランス政府買収とWickrのAWSコンシューマ終了はメッセンジャーが地政学的資産になった事実を見せた。

あなたがどの脅威モデルの中にいるかによって答えは異なる。しかし少なくともこの記事を読んだ後からは、「Signalを使ってください」がすべての人に同じく正解ではないことを知る。それが2026年春のセキュアメッセージングである。

参考 / References

- Signal Foundation — signal.org

- Signal Blog, "Quantum Resistance and the Signal Protocol"(2023.9) — signal.org/blog/pqxdh

- Signal Blog, "Phone numbers are no longer required"(2024.2) — signal.org/blog/phone-number-privacy-usernames

- Meredith Whittaker, Signal president — signal.org/blog/author/meredith

- Matrix.org Foundation — matrix.org

- Matrix Spec — spec.matrix.org

- Element X(Rust SDK) — element.io/blog/element-x-ios-everything-you-need-to-know

- matrix-rust-sdk — github.com/matrix-org/matrix-rust-sdk

- MSC3575 Sliding Sync — github.com/matrix-org/matrix-spec-proposals/blob/main/proposals/3575-sliding-sync.md

- SimpleX Chat — simplex.chat

- SimpleX Whitepaper — github.com/simplex-chat/simplexmq/blob/master/protocol/overview-tjr.md

- Session — getsession.org

- Oxen Foundation — oxen.io

- Briar — briarproject.org

- Cwtch — cwtch.im

- Open Privacy Research Society — openprivacy.ca

- Wire — wire.com

- Threema — threema.ch

- Threema GitHub — github.com/threema-ch

- Olvid — olvid.io

- French government Olvid adoption(2023.11) — gouvernement.fr 関連報道

- Wickr / AWS — aws.amazon.com/wickr

- AWS Wickr Me sunset(2023.1)

- XMPP Standards Foundation — xmpp.org

- XEP-0384 OMEMO — xmpp.org/extensions/xep-0384.html

- Conversations(Android XMPPクライアント) — conversations.im

- RFC 9420 The Messaging Layer Security (MLS) Protocol(2023.7) — datatracker.ietf.org/doc/rfc9420/

- RFC 9421 MLS Architecture

- OpenMLS — github.com/openmls/openmls

- mls-rs(AWS Rust MLS implementation) — github.com/awslabs/mls-rs

- Engineering at Meta, "WhatsApp + MLS" — engineering.fb.com

- Cisco Webex MLS adoption — webex.com

- X Premium encrypted DMs — help.x.com

- Apple iMessage PQ3(2024.2) — security.apple.com/blog/imessage-pq3

- NIST PQC Standards(ML-KEM, ML-DSA, SLH-DSA, 2024.8) — csrc.nist.gov/projects/post-quantum-cryptography

- EU Chat Control proposal — edri.org 関連分析

- UK Online Safety Bill — gov.uk

- EU Digital Markets Act(DMA) — digital-markets-act.ec.europa.eu

- カカオトーク秘密チャット — kakao.com セキュリティポリシー

- LINE Letter Sealing — engineering.linecorp.com

- +メッセージ(PlusMessage) — plus-msg.com

- Tchap(フランス政府Matrix) — tchap.gouv.fr

- BwMessenger(ドイツ軍Matrix) — bundeswehr.de 関連報道