E2E暗号化
（エンドツーエンド暗号化）とは
E2E暗号化（エンドツーエンド暗号化）は、データを送信者のデバイスで暗号化し、受信者のデバイスでのみ復号できる方式です。中間サーバーではデータの内容を読むことができません。Obsidian連携シンプルメモは「サーバーに保存しない」という異なるアプローチでプライバシーを保護しています。
E2E暗号化（End-to-End Encryption）は、通信の両端（エンドポイント）でのみデータを復号可能にする暗号化方式です。送信者のデバイスでデータを暗号化し、通信相手の端末が持つ鍵で復号します。メッセージを中継するサーバー、ネットワーク事業者、さらにはサービス提供者自身もデータの中身を読むことができません。WhatsApp、Signal、Proton Mailなどがこの方式を採用しています。
E2E暗号化の仕組み — 概念を4つのステップで理解する
E2E暗号化の要点は「中継サービスが復号に必要な鍵を持たない」ことです。以下は公開鍵暗号とメッセージ暗号化の役割を理解するための概念図です。実際のSignal Protocolには本人確認・鍵合意・鍵更新があり、この4段階だけで実装できるものではありません。
通信路暗号化・保存時暗号化・E2E暗号化の違い
「暗号化しています」という説明には3種類あり、守れる範囲がまったく違います。HTTPS（TLS）は端末とサーバーの間だけ、保存時暗号化はサーバーのディスク上だけを守り、どちらもサービス事業者は中身を読めます。E2E暗号化だけが「事業者にも読めない」を実現します。
| 観点 | 通信路暗号化（TLS / HTTPS） | 保存時暗号化（at rest） | E2E暗号化 |
|---|---|---|---|
| 守る区間 | 端末とサーバーの間の通信 | サーバーやディスク上のデータ | 送信端末から受信端末までの全区間 |
| 鍵を持つ者 | 端末とサーバーの両方 | サービス事業者 | 両端のユーザーの端末だけ |
| 事業者は中身を読めるか | 読める（サーバー到着後は平文） | 読める（鍵を管理しているのは事業者） | 読めない |
| 通信の盗聴 | 防げる | 対象外 | 防げる |
| サーバー侵害・内部不正 | 防げない | 鍵が同じ場所にあれば防げない | 防げる（漏れるのは暗号文だけ） |
| サーバー側の検索・共同編集・AI処理 | 可能 | 可能 | 原則できない（中身を読めないため） |
| 代表例 | ほぼすべてのWebサービス | クラウドストレージ全般 | Signal・WhatsApp・iMessage・Standard Notes |
主なサービスのE2E暗号化対応
同じ「暗号化」でも、既定でE2EEなのか、設定を有効にしたときだけなのか、そもそも設計上E2EEではないのかで大きく分かれます。各社の公開ドキュメントに基づく2026年9月時点の整理です。仕様は変わるため、重要な判断の前には公式情報で再確認してください。
| サービス | E2E暗号化 | 補足 |
|---|---|---|
| Signal | 既定でE2EE | Signal Protocol。メッセージ・通話・添付すべてが対象 |
| 既定でE2EE | Signal Protocolを採用。クラウドバックアップの暗号化は任意設定 | |
| iMessage | Apple端末間はE2EE | iCloudバックアップは「高度なデータ保護」を有効にするまでAppleが鍵を保持 |
| LINE | 1対1トークのテキストはE2EE | Letter Sealing（既定で有効）。対象外のコンテンツもある |
| Gmailなど一般的なメール | E2EEではない | 通信路はTLS、保存時は事業者が暗号化。事業者が中身を読める設計 |
| Proton Mail | Proton同士はE2EE | 外部宛はパスワード保護メールでE2EE化できる |
| Standard Notes | 既定でE2EE | すべてのノートがE2EE。パスワードを失うと復旧できない |
| Apple メモ | 設定次第 | 通常のメモはAppleが鍵を保持（「高度なデータ保護」でE2EE化）。ロック付きメモはパスワード由来の鍵で暗号化 |
| Notion | E2EEではない | 通信時・保存時の暗号化のみ。共同編集・検索をサーバー側で行う設計 |
| Obsidian Sync | E2EE（自分で暗号化パスワードを設定した場合） | Obsidian社も復号できない。ローカルの保管庫そのものは暗号化されない |
| Obsidian連携シンプルメモ | E2EEではない | 端末内のOutboxと送信履歴をAES-GCM-256で暗号化。本文は標準SMTPで自分の受信箱へ配信し、サーバーに恒常保存しない |
E2E暗号化でも守れないもの
E2E暗号化は「途中」を守る技術であって、「端」とその周辺は守りません。E2EEのアプリを使っていても情報が漏れる経路は、実際にはこの4つに集中しています。
どのレベルの暗号化が必要か — 脅威モデルで決める
「E2EEでなければ危険」でも「TLSがあれば安心」でもありません。誰から何を守りたいのかを先に決めると、必要なレベルはほぼ3つに分かれます。
シンプルメモは E2E 暗号化ですか？
いいえ。Simple Memo は End-to-End 暗号化（E2EE）を提供していません。メール本文を、受信者であるユーザー自身の通常のメールクライアント（Gmail / Apple Mail / Outlook など）で読めるようにするため、標準的な SMTP プロトコルで配信しています。代わりに「端末内暗号化 + データ最小化」というモデルでプライバシーを保護しています。E2EE が必要な用途には、Standard Notes・Signal・ProtonMail などの専用サービスをご検討ください。
よくある質問（E2E暗号化）
E2E暗号化とは何ですか？
データを送信者のデバイスで暗号化し、受信者のデバイスでのみ復号できる方式です。中間サーバーやネットワーク事業者はデータを読むことができません。
シンプルメモはE2E暗号化ですか？
いいえ。受信者であるユーザー自身が普段のメールアプリで本文を読めるよう、メール送信は標準 SMTP プロトコルを使用しています。代わりに、Outbox と送信履歴の端末内 AES-GCM-256 暗号化、メール本文の恒常保存なし、というデータ最小化モデルでプライバシーを保護しています。E2EE が必要な用途には Standard Notes・Signal・ProtonMail などをご検討ください。
E2E暗号化とAES-GCMの違いは？
E2E暗号化はアーキテクチャの概念（誰が復号できるか）。AES-GCMは暗号化アルゴリズム（どう暗号化するか）。E2E暗号化の内部実装にAES-GCMを使うことも可能です。
E2E暗号化とTLS（HTTPS）の違いは？
TLSは端末とサーバーの間の通信路だけを守り、サーバーに着いた時点で事業者は内容を読めます。E2E暗号化は受信者の端末に届くまで、経路上の誰も（事業者を含めて）内容を読めません。
E2E暗号化なら絶対に安全ですか？
いいえ。守れるのは通信経路と事業者からの漏えいです。端末の侵害、暗号化されていないクラウドバックアップ、メタデータ、受信者による転送やスクリーンショットは防げません。
メール（Gmailなど）はE2E暗号化されていますか？
通常のメールはTLSで通信路を守り、保存時は事業者が暗号化しますが、E2EEではありません。E2EEにするにはPGPやS/MIME、あるいはProton Mail同士のように送受信の両端が対応した仕組みが必要です。
LINEはE2E暗号化ですか？
1対1トークのテキストは「Letter Sealing」と呼ばれるE2E暗号化が既定で有効です。ただし対象外のコンテンツもあるため、詳細はLINEの公式情報で確認してください。
参考文献・外部リンク
