E2EE(エンドツーエンド暗号化)とは、データを送る側と受け取る側だけが中身を読める形にする暗号化のやり方です。通信路だけを守る SSL/TLS とは守る範囲が違い、サービスを提供している事業者自身も保管した内容を読めなくなる点が最大の特徴です。
この記事は、問い合わせフォームやメールで「うちのサイトに書き込まれた内容は、結局どこの誰まで見えているのか」が気になっている、中小企業の Web 担当・情シス・問い合わせ担当の方に向けて書いています。暗号の数学的な中身には踏み込まず、鍵を誰が持つかという一点で説明します。
E2EE とは、送信者と受信者だけが復号できる暗号化のこと
E2EE(End-to-End Encryption / エンドツーエンド暗号化)とは、データを送信者の端末の中で暗号化し、受信者の端末の中でしか元に戻せないようにする方式です。
暗号化はよく「金庫に入れる」に例えられます。中身を読むには鍵が要ります。そして暗号技術の実務で本当に問題になるのは、暗号アルゴリズムの強さよりも「その鍵を誰が持っているか」です。E2EE の定義は、突き詰めるとこの一行になります。
鍵を持っているのは両端(エンド)の二者だけで、あいだを中継する事業者は鍵を持っていない。
たとえばメッセージアプリで A さんが B さんに送るとき、E2EE が効いていれば途中のサーバーには暗号文しか置かれません。運営者は「A から B へ、この時刻に、このサイズのデータが流れた」ことは分かりますが、本文は読めません。「読まないと約束している」のではなく、鍵がないので読めない状態です。約束は人が破れますが、構造は破れません。
共通鍵暗号と公開鍵暗号:E2EE を支える 2 つの部品
現実の E2EE は、共通鍵暗号と公開鍵暗号という性質の違う 2 種類を組み合わせて作られます。片方だけでは実用にならないためです。
| 共通鍵暗号(対称暗号) | 公開鍵暗号(非対称暗号) | |
|---|---|---|
| 鍵の数 | 1 つ。かける鍵と開ける鍵が同じ | 2 つ。公開鍵でかけ、秘密鍵で開ける |
| 代表的な方式 | AES | RSA、楕円曲線暗号(ECC) |
| 速度 | 速い。大きなデータでも軽い | 遅い。大きなデータには不向き |
| 得意なこと | 本文そのものの暗号化 | 鍵を安全に相手へ渡すこと |
| 弱点 | 鍵をどうやって相手に渡すかが難問 | 処理が重く、長文をそのまま扱えない |
公開鍵暗号は、この「鍵をどうやって相手に安全に届けるか」を解きます。受信者があらかじめ鍵を 2 つ作り、公開鍵は誰にでも配ってよい、秘密鍵は自分だけが持つという形にします。公開鍵でかけた鍵は、対になる秘密鍵でしか開きません。送信者は受信者の公開鍵を拾ってきて暗号化すれば、受信者以外には読めないデータを作れます。
そこで実務では次のハイブリッド方式を取ります。
- 送信側で、その 1 回限りのランダムな共通鍵(AES 鍵)を作る
- 本文はその共通鍵で暗号化する(速い)
- 共通鍵そのものを、受信者の公開鍵で暗号化して一緒に送る(小さいので重くない)
- 受信者は自分の秘密鍵で共通鍵を取り出し、それで本文を開く
「本文は共通鍵、共通鍵は公開鍵で包む」。E2EE を名乗る仕組みは、細部は違ってもだいたいこの形をしています。
SSL/TLS との違いは「守る区間」と「誰が鍵を持つか」
SSL/TLS は通信路(訪問者のブラウザとサーバーの間)を守る技術で、サーバーに届いた時点で暗号は解かれます。E2EE はさらに先の保管まで暗号のままにする技術です。守っている区間が違うので、どちらかを選ぶものではありません。
| SSL/TLS(HTTPS) | E2EE | |
|---|---|---|
| 守る区間 | 訪問者のブラウザ ⇄ サーバーの間 | 訪問者のブラウザ ⇄ 受信者の端末 |
| サーバー上での状態 | いったん平文に戻る | 暗号文のまま |
| 鍵を持つのは | サイト運営者(サーバー側) | 受信者本人だけ |
| 事業者は中身を読めるか | 読める | 読めない |
| 主に防げること | 通信の盗聴・改ざん | 保管データの漏えい、内部からの閲覧 |
| 使われている例 | ほぼすべての Web サイト | 一部のメッセージアプリ、一部の SaaS |
流れで見ると違いがはっきりします。
SSL/TLS だけの場合
訪問者のブラウザ ──[暗号化された通信路]── サーバー(ここで平文に戻る) ── DB(平文)
E2EE の場合
訪問者のブラウザ(ここで暗号化) ── サーバー(暗号文のまま) ── DB(暗号文のまま)
└─ 受信者の端末(ここで初めて復号)
SSL/TLS は運送中のトラックを守る仕組み、E2EE は荷物そのものに鍵をかける仕組みです。
問い合わせフォームに E2EE を適用すると何が変わるか
問い合わせフォームに E2EE を適用すると、フォームを預かる側(SaaS 事業者や制作会社)が保管内容を読めなくなり、漏えい時の被害の性質が変わります。
問い合わせフォームには、実はかなり踏み込んだ情報が書かれます。Hajik が分析した、美容商社(国内最大手・上場)の実フォームデータ(3 種類のフォーム・合計 1,894 件・約 20 か月分)を読んでいても、氏名・電話番号・会社名はもちろん、体調の相談、契約や見積の条件、引っ越し・入居の予定といった、本人が人に知られたくない類の内容が普通に入ってきます。なお、内容の傾向は業種・規模・フォームの性格によって大きく変わるもので、あくまで一社・一時点のサンプルです。これが平文でどこかのデータベースに何年分も積み上がっている状態は、預ける側からすると相当こわい話です。保管や委託先の管理は個人情報保護法が求める安全管理措置とも重なる部分で、事業者側に課される義務は個人情報保護法と問い合わせフォームで押さえる 6 つの義務に整理しています。
E2EE を入れると、次のように変わります。
- 保管データが漏れても暗号文。データベースのバックアップや管理画面のアカウントが侵害されても、鍵がなければ内容は読めません。
- 提供事業者の内部からも読めない。「担当者が見ようと思えば見られる」状態そのものが無くなります。
- 代わりに、鍵(パスワード)を失うと自分でも戻せない。これは E2EE の避けられない代償で、後述します。
なお、営業メールやスパムがなぜフォームに集中するのかという背景については、フォームに営業メールが届く理由と対策で実データをもとに整理しています。
Hajik での実装:保管は復号できない、判定の瞬間だけ内容を見る
Hajik の実装では、保管データは運営者も復号できませんが、AI 判定の瞬間だけは内容をそのまま扱います。別のレイヤの話なので、両方書きます。
Hajik は、お問い合わせフォームに届く営業メールを選別する日本語特化の B2B SaaS です(運営:GrowGroup 株式会社)。サイトに script タグを 1 行入れるだけで、送信された瞬間に判定します。そのとき何が起きているかを順に書きます。
1. ブラウザ内で機微情報 5 種を除去する クレジットカード番号・マイナンバー・銀行口座番号・パスポート番号・健康情報の 5 種は、送信される前に訪問者のブラウザ内で取り除きます。サーバーにも AI にも渡りません。
2. ブラウザ内で暗号化する(ハイブリッド方式) 前述のとおりの構成です。その 1 回限りの AES-GCM-256 の鍵で本文を暗号化し、その鍵を利用企業の RSA-OAEP-2048 公開鍵で包みます。暗号化はすべて訪問者のブラウザの中で完結し、サーバーには暗号文だけが届きます。
3. 秘密鍵は利用企業のパスワードで守られている 復号に必要な秘密鍵は、利用企業のログインパスワードから PBKDF2-SHA-256(60 万回)で導出した鍵で暗号化した状態で保管しています。Hajik 側はパスワードを平文で持っていないため、保管された内容を復号できません。これは方針ではなく暗号の構造による事実です。
4. ただし、判定のあいだだけは内容を読む AI が営業か本物かを判断するには、内容を読む必要があります。Hajik では判定の瞬間に、機微情報 5 種を除いた記入内容をメモリ上で AI に渡しています。永続化されるのは暗号文だけで、平文はデータベースに残りません。
4 は最初からこうだったわけではありません。以前は AI に渡す前に個人情報をマスクしていたのですが、ある入居申込フォームで、本文以外の選択項目や申込内容が AI から見えず、明らかに本物の申込が一律「要確認」に倒れてしまいました。私たちの原則では、営業を取りこぼすのは許容できても本物を落とすのは許容できません。そこで機微情報 5 種のブラウザ内除去は維持したまま、判定の瞬間だけは記入内容をそのまま渡す形に変えました。正直に説明できる範囲でトレードオフを取った、という判断です。
なお E2EE は当初サイトごとの任意設定でしたが、現在は全サイトで必須にしています。任意だと「暗号化しない方が運用が楽」という理由で選ばれ、看板と実態がずれるためです。全体像はセキュリティへの対応、判定機能は機能一覧にまとめています。
E2EE にできないこと(限界を先に知っておく)
E2EE は万能ではなく、鍵の紛失・端末の侵害・メタデータ・検索の 4 点では無力です。
| 限界 | 何が起きるか | 現実的な対処 |
|---|---|---|
| 鍵(パスワード)の紛失 | 過去に保管した内容を誰も復号できない。事業者にも復旧手段がない | パスワードマネージャーで確実に保管する。ヒントを設定する |
| 端末やアカウントの侵害 | 復号後の画面は見えてしまう。暗号は端末の中までは守れない | 端末のロック、二要素認証、退職者のアカウント整理 |
| メタデータは隠れない | 「いつ・どのフォームから・何件届いたか」は事業者側にも見える | そもそも隠す必要がない情報かを確認する |
| サーバー側で中身を扱えない | 全文検索や集計をサーバーでやりにくい。処理がブラウザ側に寄る | 検索は復号後の画面側で行う設計にする |
もうひとつ、暗号化は中身を守るだけで、送ってきた相手が名乗ったとおりの会社かどうかまでは保証しません。社名を騙る問い合わせの見抜き方はなりすましメールの対策で扱っています。
よくある質問
E2EE と SSL/TLS は、どちらかを選ぶものですか
いいえ、併用するものです。守っている区間が違います。SSL/TLS は通信路、E2EE は保管を含めた両端です。E2EE を採用しているサービスも、通信自体は SSL/TLS で保護しています。「HTTPS だから中身は誰にも見えない」というのは誤解で、HTTPS はサーバーに届くまでの区間を守る技術です。
E2EE なら、パスワードを忘れても復旧できますか
できません。事業者が復旧できてしまうサービスは、事業者が鍵を持っている(=E2EE ではない)ということになります。運用としては、パスワードマネージャーでの保管と、複数人でアクセスする場合の鍵共有の設計をあらかじめ決めておくことをおすすめします。
E2EE だと、AI で内容を判定することはできないのでは
保管を暗号化することと、判定の瞬間に内容を読むことは別のレイヤです。Hajik では、機微情報 5 種をブラウザ内で除去したうえで、判定の瞬間だけメモリ上で内容を AI に渡し、永続化するのは暗号文だけにしています。「内容をまったく見ない」とは言いません。見なければ判定できず、本物の問い合わせを守れないからです。
導入にあたって、フォームやサーバーの改修は必要ですか
Hajik の場合は script タグを 1 行追加するだけで、WordPress のプラグイン導入・DNS 変更・フォームの action 変更はいりません。暗号化はその script が訪問者のブラウザ内で行うため、サイト側のサーバーの改修も不要です。その他の疑問はよくあるご質問にまとめています。
効果はどのくらいですか
Hajik はスパム・営業メールの 99% 以上を遮断しますが、すべて止まるとは言いません。JavaScript を実行しない特殊なボットがすり抜けるごく稀なケースがあり、残り約 1% は自動でブロックせず担当者の判断に回します。本物の問い合わせを守ることを優先しているためです。判定の考え方は問い合わせフォームの営業メール対策(実務ガイド)で解説しています。
まとめ
確認すべきは、いま自社フォームに届いた内容がどこに何年分たまっていて、それを読めるのが誰か(制作会社や SaaS 事業者の担当者を含めて)の 2 点です。E2EE を入れるなら、鍵になるパスワードを誰がどこで保管するかもあわせて決めておきます。
まずは自社フォームの現状確認からで構いません。無料診断で、いま届いている問い合わせのどれくらいが営業なのかを把握できます。実際の判定を試す場合は14 日間の無料トライアルをご利用ください。