用語集 — セキュリティGlossary — Security

E2E暗号化
（エンドツーエンド暗号化）とはWhat is End-to-End
(E2E) Encryption?

Q: シンプルメモはE2E暗号化ですか？

いいえ。受信者であるユーザー自身が普段のメールアプリで本文を読めるよう、メール送信は標準 SMTP プロトコルを使用しています。代わりに、Outbox と送信履歴の端末内 AES-GCM-256 暗号化、メール本文の恒常保存なし、というデータ最小化モデルでプライバシーを保護しています。E2EE が必要な用途には Standard Notes・Signal・ProtonMail などをご検討ください。

E2E暗号化（エンドツーエンド暗号化）は、データを送信者のデバイスで暗号化し、受信者のデバイスでのみ復号できる方式です。中間サーバーではデータの内容を読むことができません。Obsidian連携シンプルメモは「サーバーに保存しない」という異なるアプローチでプライバシーを保護しています。 E2E (end-to-end) encryption encrypts data on the sender's device so only the recipient's device can decrypt it. No intermediate server can read the content. Simple Memo takes a different privacy approach: never storing data on servers at all.

著者: AI Ataka By AI Ataka · 最終更新: 2026年09月05日 · Updated: September 5, 2026

定義

E2E暗号化（End-to-End Encryption）は、通信の両端（エンドポイント）でのみデータを復号可能にする暗号化方式です。送信者のデバイスでデータを暗号化し、通信相手の端末が持つ鍵で復号します。メッセージを中継するサーバー、ネットワーク事業者、さらにはサービス提供者自身もデータの中身を読むことができません。WhatsApp、Signal、Proton Mailなどがこの方式を採用しています。

Definition

End-to-End Encryption (E2E) is an encryption scheme where data can only be decrypted at the two endpoints of a communication channel. Data is encrypted on the sender's device and is decrypted using keys held by the communicating endpoints. Servers relaying the message, network providers, and even the service operator itself cannot read the data. WhatsApp, Signal, and Proton Mail use this approach.

E2E暗号化の仕組み — 概念を4つのステップで理解するHow E2E Encryption Works — 4 Steps

E2E暗号化の要点は「中継サービスが復号に必要な鍵を持たない」ことです。以下は公開鍵暗号とメッセージ暗号化の役割を理解するための概念図です。実際のSignal Protocolには本人確認・鍵合意・鍵更新があり、この4段階だけで実装できるものではありません。 E2EE keeps decryption keys away from the relay service. The following is a conceptual overview of key agreement and message encryption, not an implementation recipe for Signal. Real protocols also need authentication and key-update mechanisms.

1. 端末が鍵ペアを作る1. Each device generates a key pair

各端末が公開鍵と秘密鍵のペアを生成します。公開鍵は配ってよい鍵、秘密鍵は端末の中だけに置く鍵です。サービス事業者は公開鍵を預かって相手に渡す「電話帳」の役割だけを担います。Each device generates a public/private key pair. The public key can be shared freely; the private key stays on the device. The service operator only acts as a directory that hands public keys to the other party.

2. 相手と共通鍵を合意する2. Agree on a shared session key

相手の公開鍵と自分の秘密鍵から、両者だけが計算できる共通のセッション鍵を導き出します（Diffie–Hellman鍵合意）。鍵そのものはネットワークを流れないため、通信をすべて記録されても鍵は割り出せません。From the other party's public key and your own private key, both sides derive the same session key that nobody else can compute (Diffie–Hellman key agreement). The key itself never travels over the network, so recording all traffic does not reveal it.

3. 送信端末で暗号化して送る3. Encrypt on the sender's device

本文はセッション鍵を使い、AES-GCMやChaCha20-Poly1305のような認証付き共通鍵暗号で暗号化されます。サーバーが受け取るのは暗号文だけで、受信側は認証タグを検証して改ざんを検出します。The message body is encrypted with the session key using an authenticated symmetric cipher such as AES-GCM or ChaCha20-Poly1305. The server receives only ciphertext, and the recipient verifies an authentication tag to detect tampering.

4. 受信端末だけが復号する4. Only the recipient's device decrypts

復号に必要な鍵を扱うのは通信の両端の端末で、中継サーバーではありません。SignalのDouble Ratchetではメッセージごとに鍵を更新し、削除済みの過去の鍵を後から得られにくくします（前方秘匿性）。侵害後に新しい鍵素材を交換して将来の通信を再び保護する性質は侵害後の回復として区別されます。端末が継続して侵害されている場合まで安全を保証するものではありません。The communicating endpoints handle decryption keys; the relay server does not. Signal’s Double Ratchet updates keys per message to protect earlier messages whose keys have been deleted (forward secrecy). Recovery after compromise depends on incorporating fresh key material. Neither property guarantees protection while an endpoint remains compromised.

通信路暗号化・保存時暗号化・E2E暗号化の違いIn-Transit vs At-Rest vs End-to-End Encryption

「暗号化しています」という説明には3種類あり、守れる範囲がまったく違います。HTTPS（TLS）は端末とサーバーの間だけ、保存時暗号化はサーバーのディスク上だけを守り、どちらもサービス事業者は中身を読めます。E2E暗号化だけが「事業者にも読めない」を実現します。 "We encrypt your data" can mean three different things with very different coverage. HTTPS (TLS) protects only the hop between your device and the server; at-rest encryption protects only the disks — in both cases the operator can still read the content. Only E2EE makes content unreadable to the operator.

観点	通信路暗号化（TLS / HTTPS）	保存時暗号化（at rest）	E2E暗号化
守る区間	端末とサーバーの間の通信	サーバーやディスク上のデータ	送信端末から受信端末までの全区間
鍵を持つ者	端末とサーバーの両方	サービス事業者	両端のユーザーの端末だけ
事業者は中身を読めるか	読める（サーバー到着後は平文）	読める（鍵を管理しているのは事業者）	読めない
通信の盗聴	防げる	対象外	防げる
サーバー侵害・内部不正	防げない	鍵が同じ場所にあれば防げない	防げる（漏れるのは暗号文だけ）
サーバー側の検索・共同編集・AI処理	可能	可能	原則できない（中身を読めないため）
代表例	ほぼすべてのWebサービス	クラウドストレージ全般	Signal・WhatsApp・iMessage・Standard Notes

Aspect	In transit (TLS / HTTPS)	At rest	End-to-end
What is protected	The hop between device and server	Data on servers and disks	The whole path from sender device to recipient device
Who holds the key	Both device and server	The service operator	Only the two users' devices
Can the operator read it?	Yes (plaintext once it arrives)	Yes (the operator manages the key)	No
Eavesdropping on the wire	Prevented	Not addressed	Prevented
Server breach / insider access	Not prevented	Not prevented if keys sit alongside the data	Prevented (only ciphertext leaks)
Server-side search, co-editing, AI	Possible	Possible	Generally impossible (server cannot read content)
Typical examples	Almost every web service	Cloud storage in general	Signal, WhatsApp, iMessage, Standard Notes

主なサービスのE2E暗号化対応E2EE Support in Common Services

同じ「暗号化」でも、既定でE2EEなのか、設定を有効にしたときだけなのか、そもそも設計上E2EEではないのかで大きく分かれます。各社の公開ドキュメントに基づく2026年9月時点の整理です。仕様は変わるため、重要な判断の前には公式情報で再確認してください。 Services differ on whether E2EE is on by default, only when you enable a setting, or not part of the design at all. This summary is based on each vendor's public documentation as of September 2026; specifications change, so re-check official sources before an important decision.

サービス	E2E暗号化	補足
Signal	既定でE2EE	Signal Protocol。メッセージ・通話・添付すべてが対象
WhatsApp	既定で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で自分の受信箱へ配信し、サーバーに恒常保存しない

Service	E2EE	Notes
Signal	E2EE by default	Signal Protocol; messages, calls and attachments
WhatsApp	E2EE by default	Uses the Signal Protocol; encrypted cloud backups are opt-in
iMessage	E2EE between Apple devices	iCloud backups are decryptable by Apple until Advanced Data Protection is enabled
LINE	E2EE for 1:1 text chats	Letter Sealing (on by default); some content types are not covered
Gmail and ordinary email	Not E2EE	TLS in transit, provider-managed encryption at rest; the provider can read content
Proton Mail	E2EE between Proton users	Password-protected emails extend E2EE to external recipients
Standard Notes	E2EE by default	All notes are E2EE; a lost password is unrecoverable
Apple Notes	Depends on settings	Regular notes: Apple holds the key (E2EE with Advanced Data Protection). Locked notes are encrypted with a password-derived key
Notion	Not E2EE	Encryption in transit and at rest only; co-editing and search run server-side
Obsidian Sync	E2EE (with your own encryption password)	Obsidian cannot decrypt; the local vault itself is not encrypted
Simple Memo - for Obsidian	Not E2EE	On-device Outbox and send history encrypted with AES-GCM-256; bodies delivered over standard SMTP to your own inbox, never stored persistently on servers

E2E暗号化でも守れないものWhat E2EE Does Not Protect

E2E暗号化は「途中」を守る技術であって、「端」とその周辺は守りません。E2EEのアプリを使っていても情報が漏れる経路は、実際にはこの4つに集中しています。 E2EE protects the middle of the path, not the endpoints or their surroundings. Even with an E2EE app, leaks in practice come from these four places.

端末そのものThe device itself

復号された平文は端末上に存在します。端末がマルウェアに感染していたり、ロック解除された状態で他人の手に渡れば、暗号化とは関係なく読まれます。端末のロック・OSの更新・端末内暗号化が前提条件です。Decrypted plaintext lives on the device. Malware or an unlocked phone in someone else's hands defeats any encryption. Device lock, OS updates and on-device encryption are prerequisites.

メタデータMetadata

「誰が・誰に・いつ・どれくらいの量を」送ったかは、本文がE2EEでも多くのサービスに残ります。Signalのようにメタデータを最小化する設計もありますが、ゼロにはなりません。Who sent what to whom, when and how much often remains visible to the service even when the body is E2EE. Some designs (Signal) minimise metadata, but none eliminate it.

バックアップBackups

会話はE2EEでも、クラウドバックアップが事業者の鍵で保存されていれば、そこから読めます。WhatsAppのバックアップ暗号化は任意設定、iMessageのバックアップは「高度なデータ保護」を有効にしない限りAppleが復号できます。A conversation can be E2EE while its cloud backup is readable with the provider's key. WhatsApp backup encryption is opt-in; iMessage backups are decryptable by Apple unless Advanced Data Protection is on.

受信者の行動The recipient

受け取った相手が転送・スクリーンショット・コピーをすれば、暗号化は何の制約にもなりません。E2EEは「相手を信頼できる」ことが前提の技術です。If the recipient forwards, screenshots or copies the content, encryption imposes no constraint. E2EE assumes you trust the other end.

どのレベルの暗号化が必要か — 脅威モデルで決めるHow Much Encryption Do You Need? Decide by Threat Model

「E2EEでなければ危険」でも「TLSがあれば安心」でもありません。誰から何を守りたいのかを先に決めると、必要なレベルはほぼ3つに分かれます。 Neither "anything short of E2EE is unsafe" nor "TLS is enough" is right in general. Decide who you are protecting against first, and the required level falls into three tiers.

通信の盗み見を防ぎたいStop eavesdropping on the wire

正しく検証されたHTTPS（TLS）は、端末と接続先サーバーの間の通信を保護します。メール配送では経路ごとにTLS対応やポリシーが異なるため、HTTPSでAPIに接続したことだけで、送信から受信までの全経路が保護されるとは判断できません。Properly validated HTTPS (TLS) protects the connection between a device and the server it contacts. Email hops can have different TLS support and policies, so an HTTPS API connection alone does not establish protection along the entire delivery path.

事業者・サーバー侵害からも守りたいProtect against the operator and server breaches

医療記録・法律相談・内部告発・機密性の高い私信のように、サービス事業者にも読まれてはならない内容なら、E2EEを既定で提供するサービス（Signal・Proton Mail・Standard Notes など）を選びます。For medical records, legal consultations, whistleblowing or highly confidential private messages — anything the operator must never read — choose a service with E2EE by default (Signal, Proton Mail, Standard Notes).

自分の受信箱に届けばよい日常メモEveryday memos into your own inbox

アイデア・ToDo・買い物リストのように「自分のGmailに届いて、あとで検索できればよい」用途なら、端末内暗号化とデータ最小化（サーバーに本文を残さない）で実用上十分です。Obsidian連携シンプルメモはここに位置します。For ideas, to-dos and shopping lists that just need to reach your own Gmail and be searchable later, on-device encryption plus data minimisation (no memo bodies kept on servers) is sufficient in practice. That is where Simple Memo sits.

シンプルメモは E2E 暗号化ですか？Is Simple Memo E2E encrypted?

いいえ。Simple Memo は End-to-End 暗号化（E2EE）を提供していません。メール本文を、受信者であるユーザー自身の通常のメールクライアント（Gmail / Apple Mail / Outlook など）で読めるようにするため、標準的な SMTP プロトコルで配信しています。代わりに「端末内暗号化 + データ最小化」というモデルでプライバシーを保護しています。E2EE が必要な用途には、Standard Notes・Signal・ProtonMail などの専用サービスをご検討ください。 No. Simple Memo is not End-to-End Encrypted (E2EE). Memo bodies are delivered through standard SMTP so you (the recipient) can read them in your normal mail client (Gmail / Apple Mail / Outlook). The privacy model is "on-device encryption + data minimization" instead. For workloads requiring true E2EE, consider purpose-built services such as Standard Notes, Signal, or ProtonMail.

E2E 暗号化のモデルE2EE model

Standard Notes や ProtonMail などのサービスは、データを暗号化された状態でサーバに保存します。サーバ運営者でも内容を復号できません。同期・バックアップが可能ですが、暗号文がサーバ上に永続的に存在し続けます。受信者は専用クライアントで復号して読みます。Services like Standard Notes and ProtonMail keep data on their servers in encrypted form. The operator cannot decrypt content. Sync and backup work, but ciphertext persists on the server. The recipient decrypts with a dedicated client.

Simple Memo のモデルSimple Memo's model

オフライン送信待ちの Outbox と送信履歴を端末内で AES-GCM-256 暗号化。鍵は Apple Keychain。通信は TLS。メール本文は標準 SMTP で配信されるため通信路の中間サーバや受信メールサーバから見える可能性があります。当社サーバには本文を恒常的に保存しません。受信者は普段のメールアプリでそのまま読めます。The on-device Outbox and history are encrypted with AES-GCM-256 (key in Apple Keychain). API calls use TLS. The memo body itself is delivered over standard SMTP, so intermediate mail servers can see it as part of normal delivery. We don't persistently store memo bodies on our infrastructure. You read them in your regular mail app.

どちらを選ぶべきかWhich to choose

脅威モデル次第です。医療記録・法律相談・内部告発のように、受信メールサーバ運営者にも見られたくない内容なら E2EE 専用サービス（Standard Notes / Signal / ProtonMail 等）。日常のアイデアメモ・ToDo・買い物リストのように、自分の Gmail に届けばよいなら Simple Memo のモデルが実用的です。It depends on your threat model. For medical records, legal counsel, or whistleblowing — content that even the recipient's mail server should not see — pick a dedicated E2EE service (Standard Notes / Signal / ProtonMail). For everyday idea capture, todos, shopping lists, etc. that just need to land in your own Gmail, Simple Memo's model is the pragmatic choice.

よくある質問（E2E暗号化）FAQ: E2E Encryption

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の公式情報で確認してください。

What is E2E encryption?

End-to-end encryption encrypts data on the sender's device so only the recipient can decrypt it. No server or network provider in between can read the content.

Does Simple Memo use E2E encryption?

No. Memo bodies are delivered through standard SMTP so you (the recipient) can read them in your regular mail client. The privacy model is on-device AES-GCM-256 encryption for the Outbox and send history, plus a no-persistent-server-storage policy for memo bodies — data minimization, not end-to-end encryption. For workloads needing true E2EE, consider Standard Notes, Signal, or ProtonMail.

What is the difference between E2E encryption and AES-GCM?

E2E encryption is an architectural concept (who can decrypt). AES-GCM is an encryption algorithm (how to encrypt). E2E implementations may use AES-GCM internally.

How is E2EE different from TLS (HTTPS)?

TLS protects only the hop between your device and the server; once data arrives, the operator can read it. With E2EE, nobody on the path — the operator included — can read the content until it reaches the recipient's device.

Is E2EE completely secure?

No. It protects against leaks on the path and at the operator. It does not protect against a compromised device, unencrypted cloud backups, metadata, or a recipient who forwards or screenshots the content.

Is email (Gmail etc.) end-to-end encrypted?

Ordinary email uses TLS in transit and provider-managed encryption at rest, but it is not E2EE. Making it E2EE requires PGP, S/MIME, or a system where both ends participate, such as Proton Mail to Proton Mail.

参考文献・外部リンク

References

端末内暗号化＋データ最小化のシンプルなアプローチOn-device encryption + data minimization

Obsidian連携シンプルメモは、オフライン Outbox と送信履歴を端末内で AES-GCM-256 暗号化し、メール本文をサーバに恒常的に保存しません。E2E 暗号化ではありませんが、日常のメモを自分のメール受信箱に送るための実用的なプライバシーモデルです。ダウンロードは無料。Simple Memo encrypts the on-device Outbox and send history with AES-GCM-256 and does not persistently store memo bodies on our servers. Not end-to-end encrypted — a pragmatic privacy model for routing your everyday memos into your own email inbox. Free to download.