エンドツーエンド暗号化（E2EE）とは、データを送信者の端末の上で暗号化し、鍵を持つ受信者だけが元に戻せるようにする仕組みです。途中でデータを保存したり届けたりするサービス自身も、中身を読むことはできません。一般的な「暗号化されたサービス」は、通信中とサーバー上のデータを守っていても鍵はサービス側が持っています。エンドツーエンド暗号化なら、サービスが目にするのは意味をなさない暗号化データだけです。
この違いは技術的に聞こえますが、サーバーが侵害されたとき、社員が見てはいけないものを見ようとしたとき、法的な開示請求が来たときに、誰がファイルを読めるかを左右します。この記事では、よく見かける3種類の暗号化の違い、ファイル転送でのエンドツーエンド暗号化の仕組み、iPhone、X、LINEなど身近なアプリでの使われ方、そして実際の限界を解説します。
3種類の暗号化の違い
| 種類 | 守るもの | 鍵を持つのは | サービスは中身を読める？ |
|---|---|---|---|
| 通信の暗号化（TLS、ブラウザの鍵マーク） | ネットワーク上を移動中のデータ | ブラウザとサーバー（通信ごと） | はい、届いたあとは |
| 保存時の暗号化（AES-256など） | 事業者のディスクに保存されたデータ | 事業者 | はい |
| エンドツーエンド暗号化 | 送信者と受信者の端末以外のすべての場所にあるデータ | 鍵を持つ人だけ | いいえ |
通信の暗号化にはTLS（現在はTLS 1.3、RFC 8446）が使われ、ネットワーク上の盗聴を防ぎます。保存時の暗号化は、ディスクが盗まれた場合などからデータを守ります。どちらも標準的で価値のある対策ですが、鍵を管理しているのはサービス側なので、サービスはデータを復号できます。エンドツーエンド暗号化は、その上にサービス側では外せない保護を重ねるものです。
ファイル転送でのエンドツーエンド暗号化の仕組み
ステップ 1
ブラウザで鍵が作られる
エンドツーエンド暗号化をオンにすると、ブラウザがランダムな秘密鍵を生成します。入力したり覚えたりする必要はありません。
ステップ 2
アップロード前にファイルを暗号化する
各ファイルは、改ざんも検知できるGCMモードのAESなどの暗号方式で、端末の上で暗号化されます。
ステップ 3
暗号化データだけがアップロードされる
サービスは、自分では読めない暗号化データを保存し、届けるだけです。
ステップ 4
鍵はリンクに入れて渡す
鍵はダウンロードリンクの「#」以降に付け加えられます。URLのこの部分はブラウザの中にとどまります。
ステップ 5
受信者のブラウザが復号する
受信者が完全なリンクを開くと、ブラウザが暗号化されたファイルをダウンロードし、鍵を使って端末の上で復号します。
「#」以降の鍵がサーバーに送られない理由
URLの末尾には、「#」で始まるフラグメントという部分を付けられます。HTTPの標準仕様（RFC 9110）では、フラグメントはブラウザ側で処理するためのもので、リクエストには含まれないと定められています。受信者がリンクを開くと、ブラウザはフラグメントを除いたURLでサーバーにページを求め、そのあとで鍵を端末内で読み取ります。これは、Mozillaのかつてのサービス「Firefox Send」で広く知られるようになった設計で、Transfrのエンドツーエンド暗号化も同じ仕組みを使っています。
エンドツーエンド暗号化で守れるもの
- 事業者のサーバーへの侵入： 盗まれたファイルは、鍵がなければ読めません。
- 内部の人によるアクセス： サービスのスタッフもファイルを開けません。
- 事業者への開示請求： サービスは、そもそも持っていない読める状態のデータを渡すことができません。
- 設定ミスによる公開： 保存領域が誤って公開されても、中身は暗号化データです。
法令の面でも利点があります。日本の個人情報保護委員会のガイドラインでは、漏えい等したデータに「高度な暗号化その他の個人の権利利益を保護するために必要な措置」が講じられていれば、委員会への報告を要しないとされています。EUのGDPRでも、データが暗号化などで第三者に読めない状態になっていれば、本人への通知が不要になる場合があります（第34条3項(a)）。ただし、鍵が漏れていないことが前提です。詳しくは「個人情報をファイルで送付するときの注意点」をご覧ください。
エンドツーエンド暗号化で守れないもの
- 漏れたリンク： 完全なリンクを持っている人は、鍵も持っていることになります。
- 乗っ取られた端末： 送信者や受信者のパソコンにマルウェアや悪意のあるブラウザ拡張機能があれば、暗号化前や復号後のファイルを見られてしまいます。RFC 9110自体も、フラグメントはページ内のスクリプトからは見えると注記しています。
- メタデータ： サービスによっては、ファイル名、サイズ、日時、メールアドレスなどが見える状態で残ります。
- 受信者がそのあとどうするか： 復号して保存されたファイルは、普通のファイルです。
エンドツーエンド暗号化のデメリット
サービスがファイルを読めないということは、サービスがファイルに対してできることも限られるということです。Transfrの場合、エンドツーエンド暗号化をオンにすると次のようになります。
- ファイルはブラウザでAES-128-GCMによって暗号化され、鍵はリンクのフラグメントに入ります。その下では、保存時の暗号化（AES-256）も引き続き適用されます。
- プレビューは、復号後に受信者のブラウザで作られます。対象は2GBまでのファイルで、リンクに鍵が含まれている場合だけです。それより大きいファイルはダウンロードして確認します。
- フォルダ構成は保持されず、中断したアップロードはページを再読み込みすると再開できません。また、Drimeから取り込んだファイルは、Transfrがコピーする仕組みのためエンドツーエンド暗号化できません。
- 鍵がTransfrのサーバーに保存されることはありません。ただし、Transfrがリンクをメールで送るとき（受信者へのメールや、ログイン中の送信者への確認メール）は、メールにリンクを載せるために、ブラウザが鍵を含む完全なリンクをサーバーに渡します。鍵はそのメールのためだけに使われますが、メール自体は受信箱に残ります。最も厳格にしたい場合は、リンクを自分でコピーし、信頼できる経路で渡してください。
これらは欠陥ではなく、中身を見られないサービスであることの当然の結果です。日常的なファイルならパスワードと有効期限で十分なことも多く、機密ファイルならこうした制約と引き換えにする価値があります。
次の転送をエンドツーエンド暗号化する
Transfrなら無料。パスワードや有効期限とも組み合わせられ、1回100GBまで送れます。
iPhoneのエンドツーエンド暗号化とは
Appleによると、iPhoneのメッセージアプリでiMessageとして送るメッセージはエンドツーエンドで暗号化され、会話の上部に鍵のアイコンが表示されます。一方、SMSやMMSはエンドツーエンドで暗号化されません。RCSは、iOS 26.5以降で、参加者全員が暗号化に対応した通信事業者を使っている場合にエンドツーエンドで暗号化されます（2026年10月時点ではベータ版）。
iCloudには「標準のデータ保護」と「高度なデータ保護」があります。標準では、パスワードとキーチェーン、ヘルスケアデータなど15のカテゴリがエンドツーエンドで暗号化され、ほかのデータの鍵はAppleのデータセンターで管理されます。オプションの高度なデータ保護（iOS 16.2以降）をオンにすると、iCloudバックアップ、iCloud Drive、写真なども含めて25のカテゴリに広がります。ただし、iCloudメール、連絡先、カレンダーは対象外で、「リンクを知っている人はだれでも」で共有したものもエンドツーエンド暗号化されません。
X（旧Twitter）のエンドツーエンド暗号化とは
Xのダイレクトメッセージ機能「チャット」は、エンドツーエンド暗号化に対応しています。X公式ヘルプによると、初めてチャットに入るとユーザーごとに秘密鍵と公開鍵のペアが作られ、秘密鍵は端末から外に出ないPINコードで保護されてXのサーバーに保管されます。暗号化された会話では、メッセージ、リンク、メディア、ファイル、リアクションが暗号化されます。
- やり方： ツールバーの「チャット」タブを開くか、X Chatアプリにログインし、表示される指示に従ってPINを設定します。送信者と受信者の両方がチャットに登録している必要があります。
- 暗号化されない場合： 相手がチャットに登録していないと、メッセージは暗号化されずに送られ、送信ボタンの横にロック解除のアイコンが表示されます。メッセージリクエストも、相手が承認するまでは暗号化されません。
- 注意点： 受信者や作成時刻などのメタデータは暗号化されません。Grokに送った画像やテキストも暗号化されなくなります。また、Xは現時点で前方秘匿性がないことを明記しています。
LINEのエンドツーエンド暗号化（Letter Sealing）
LINEのLetter Sealing（レターシーリング）は、トークルームの参加者以外の人やLINEサービスにメッセージの内容がわからないようにする暗号化技術で、エンドツーエンド暗号化を使っています。LINEのヘルプによると、対象はテキストメッセージ、位置情報、画像・動画・ボイスメッセージ、ファイル、1対1トークの音声・ビデオ通話です。グループトークの通話、ミーティング、アルバム、ノートは対象外で、画像やファイルはアプリのバージョンや環境によって暗号化されない場合があります。現在はオンの状態で提供されており、オフにはできません。
身近なツールのエンドツーエンド暗号化
| サービス | エンドツーエンド暗号化の対象 | 注意点 |
|---|---|---|
| iMessage（iPhone） | メッセージ | SMS・MMSは対象外 |
| X（チャット） | 暗号化された会話のメッセージ、メディア、ファイル | メタデータは対象外。相手が未登録だと暗号化されない |
| LINE（Letter Sealing） | テキスト、画像、動画、ファイル、1対1の通話 | グループ通話、アルバム、ノートは対象外 |
| 通話、メッセージ、写真、動画、ファイル、グループ（標準で有効） | バックアップの暗号化は任意 | |
| Discord | 音声・ビデオ通話（2026年5月から標準） | テキストメッセージは対象外 |
| Transfr | 暗号化を選んだ転送のファイル、ファイル名、メッセージ | 任意・無料。フォルダ構成は保持されない |
クラウドストレージのE2EEは？
一般的なクラウドストレージは、通信時と保存時にデータを暗号化しますが、鍵は事業者が管理しているのが普通です。Proton Drive、Tresorit Send、Wormholeのように、アップロード前にブラウザでファイルを暗号化するサービスもあります。どのサービスが無料でエンドツーエンド暗号化を使えるかは「無料のファイル転送サービスの比較」で、専門職がパスワードや短い有効期限と組み合わせる方法は「法律事務所向けの安全なファイル転送」で紹介しています。
エンドツーエンド暗号化とパスワードの違い
2つは別の問題を解決するもので、組み合わせると効果的です。パスワードは誰がダウンロードページを開けるかを管理しますが、確認するのはサービス側なので、サービスはファイルにアクセスできます。エンドツーエンド暗号化は、サービスも含めて誰が中身を読めるかを管理します。両方を使えば、リンクが漏れただけでは開けず、事業者も中身を見られません。パスワードと有効期限の選び方は「パスワード付きリンクと有効期限」で解説しています。
エンドツーエンド暗号化を使うべき場面は？
| 場面 | E2EEはおすすめ？ |
|---|---|
| 家族への旅行写真 | 任意 |
| 取引先への納品物（デザイン、動画） | 未発表の作品なら有効 |
| 契約書、給与明細、本人確認書類 | はい |
| 医療・法律・財務の記録 | はい。パスワードと短い有効期限も |
| ソースコード、製品計画、M&A資料 | はい |
本当にエンドツーエンド暗号化か確かめるには
- 暗号化が「当社の安全なサーバー上」ではなく、アップロード前にブラウザやアプリで行われること。
- サービスが鍵を保存しないと明言していること。鍵がリンクのフラグメントにあるか、自分だけが知る秘密から作られるかを確認し、サービスがリンクをメールで送るときにどうなるかも見ておきます。
- 鍵なしで、暗号化したファイルのプレビューやスキャンをサーバー側で表示できるなら、エンドツーエンドではありません。
- 「銀行並みのセキュリティ」といった言葉だけでなく、暗号方式や設計の説明があること。
パスワードから受信者の選び方まで、より幅広い習慣は「ファイルを安全に送るチェックリスト」と「ファイルを安全に送る方法」をご覧ください。