本文へ移動
合同会社SAiAI & SOFTWARE DEVELOPMENT
← ブログ一覧へ

メールの暗号化、AES-256なら安全?社長の4つの質問に答える

公開: 2026/10/11 / By 佐藤 駿介
読了時間: 約8分
約3,915文字

結論(要点)

メールの暗号化は「経路」と「中身」の2層。経路はTLSで、送信側と受信側のサーバー間を守るが、普通の設定では相手が非対応だと暗号化なしで送ってしまう(日和見TLS)。それを止めるのが強制TLSとMTA-STS。中身の暗号化はS/MIMEやPGPで、AES-256はその中で使われる部品の名前であって方式ではない。パスワード付きzipの別送(PPAP)は同じ経路で鍵も送るので守れておらず、ウイルス検査も妨げるため政府は2020年に廃止。中小企業の現実的な順番は、なりすまし対策(SPF/DKIM/DMARC)→主要な取引先と強制TLS→添付はリンク共有→ログインは多要素→本当に秘密の文書だけ中身を暗号化。

この記事の目次

いま、製造業のお客様の社内向けWEBメールを作っています。その打ち合わせで、社長から暗号化について4つの質問をいただきました。どれも、メールの安全を考える中小企業の方が必ず通る質問です。

結論を先に書くと、「AES-256にすれば安全」ではなく、「経路」と「中身」のどちらを、誰との間で守るかを決めることが先です。この記事では、4つの質問にそのまま答える形で、メールの暗号化の仕組みと、利便性を落とさない現実的な順番を書きます。

結論:メールの暗号化は2層。AES-256は「方式」ではなく「部品」

層何を守るか仕組み弱点
経路の暗号化自社のサーバーと相手のサーバーの間の通信TLS(STARTTLS)相手が非対応だと、普通の設定では暗号化なしで送ってしまう。相手のサーバーに届いたあとは守らない
中身の暗号化メール本文と添付そのものS/MIME、PGP送る側と受ける側の両方に証明書や鍵の準備が要る。取引先全員には広げにくい

AES-256は、TLSの中でもS/MIMEの中でもzipの暗号化でも使われている、暗号の計算方法の名前です。「AES-256で暗号化する」は、「車のエンジンは2,000ccにする」と言っているのに近く、どこを走るか(経路か中身か)を決めないと安全かどうかは決まりません。

質問1「送受信ともAES-256のような通信暗号化ができればいいのか」

通信の暗号化はTLSで行い、その中でAES-256が使われます。ここは「対応可能です」で終わりますが、決めるべきことは別にあります。TLSのバージョンを1.2以上に限る(古い1.0・1.1は無効にする)、相手の環境に合わせて安全な方式を自動で選ぶ、の2つです。暗号の方式を1つに固定すると、固定した方式が将来弱くなったときに全部を入れ替えることになるので、固定しないのが普通です。

当社が作るシステムはTLS 1.2以上を標準にしています(セキュリティポリシー)。

質問2「相手がTLSに対応しているか確認してから送るのか」

これが一番大事な質問です。普通のメールサーバーは、相手がTLSに対応していれば暗号化し、対応していなければ暗号化なしで送ります。これを日和見TLS(Opportunistic TLS)と言います。送る側は「暗号化して送ったつもり」でも、相手次第で平文になります。

それを止める仕組みが2つあります。

  1. 強制TLS:この相手には暗号化できないなら送らない、という設定。Microsoft 365でもGoogle Workspaceでも、取引先ごとに設定できます。主要な取引先だけに掛けるのが現実的です
  2. MTA-STS:受け取る側が「うちはTLSでしか受けません」と公開しておく仕組み(RFC 8461)。相手側の設定なので、自社だけでは決められませんが、自社のドメインに設定しておけば「うちに送るときは暗号化してください」と宣言できます

つまり「確認してから送る」は、人が確認するのではなく、サーバーに「暗号化できなければ送らない」と決めさせることです。

質問3「一時解除とは何か」

強制TLSを掛けた相手が、何かの事情でTLSに対応できなくなったとき(相手のサーバー更改など)、メールが届かなくなります。そのときに「この相手だけ、一時的に暗号化なしを許す」のが一時解除です。

当社がおすすめしている作りは、自動で解除せず、警告して止める形です。「〇〇社宛てのメールが暗号化できないため送信を止めています」と送信者と管理者に知らせ、人が判断して解除する。黙って平文で送るのが一番危ないので、そこだけは機械に決めさせません。

質問4「セキュリティのレベルを最高まで持っていきたい」

気持ちは分かります。ただ、最高にすると届かないメールが増えます。全相手に強制TLSを掛ければ、非対応の取引先には一通も送れません。全メールをS/MIMEで中身まで暗号化すれば、相手にも証明書の準備が要り、スマホで読めなくなる相手が出ます。

守りを上げるほど使いにくくなるのは、どのシステムも同じです。当社は「最高」ではなく、「どの相手と、どの情報を、どこまで」を決めて段階を上げる形を取っています。海外の取引先が増える場合も、国際的に広く使われている方式(TLS 1.2以上、SPF/DKIM/DMARC、必要な相手にS/MIME)を選んでおけば、相手側の対応も得やすいです。

パスワード付きzipの別送(PPAP)は、なぜ意味がないのか

「添付をzipにしてパスワードを掛け、パスワードを別のメールで送る」やり方は、日本で広く使われてきました。これは守れていません。

  • zipもパスワードも同じ経路で送るので、経路を見られていれば両方見られる
  • 暗号化されたzipはウイルス検査をすり抜ける。2019〜2020年のEmotetの感染経路の1つがこれだった
  • 受け取る側がスマホで開けない、パスワードを探す手間がかかる

このため、2020年11月に政府は中央省庁でこの方式を廃止しました。代わりは、添付をファイルのリンク共有にすることです。リンクには期限と閲覧者の制限を付けられ、送った後に取り消せます。ファイルそのものはメールの経路を通りません。

中小企業の現実的な順番(費用の安い順)

  1. なりすまし対策(SPF・DKIM・DMARC):自社のドメインを名乗る偽メールを止める。暗号化の前にこれ。設定だけで0円
  2. 主要な取引先と強制TLS:売上の大半を占める数社だけでいい。相手にも「暗号化できなければ送らない」設定を頼む
  3. 添付はリンク共有に:PPAPをやめる。期限・閲覧制限・取り消しができる
  4. ログインは多要素に:メールが漏れる原因の多くは、経路でなくアカウントの乗っ取り。10月7日の個人情報保護委員会の注意喚起でも、フィッシング耐性のある多要素認証が手法例に入った
  5. 本当に秘密の文書だけ中身を暗号化:契約書・図面・個人情報。S/MIMEか、リンク共有のうえ閲覧者を限定する

当社が社内メールを作るときの標準

いま作っている製造業のお客様の社内メールでは、上の順番をそのまま入れています。TLS 1.2以上を必須にし、暗号化できない相手には警告して止め、添付はリンク共有を基本にし、ログインはパスワードに固定の4桁PINを足して、PINを3回間違えると本人と管理者に知らせが届く形にしました。専用アプリやSMSに費用をかけず、使い続けられる形から始めて、正式提供のときにワンタイムコードかパスキーに上げる、と決めたうえでの選択です。

安全性と使いやすさをどう両立させるかは、安全にAIを入れる当社のやり方にまとめています。

よくある質問

Q. Gmail や Microsoft 365 を使っていれば、暗号化は済んでいますか?

経路の暗号化(TLS)は既定で有効です。ただし相手が非対応なら平文で送る日和見のままなので、主要な取引先には強制TLSの設定を足してください。なりすまし対策(SPF/DKIM/DMARC)と多要素認証は、自分で設定しないと有効になりません。

Q. 取引先から「PPAPで送ってください」と言われます。

先方の運用なので従うしかない場面はあります。その場合も、自社から送るときはリンク共有を提案し、受け取るときはウイルス検査を通してから開く運用にしてください。政府が廃止した理由(2020年11月)を一言添えると、切り替えてもらえることが多いです。

Q. S/MIME は中小企業でも使えますか?

使えますが、相手にも証明書が要るので、取引先全員には広げにくいです。契約書や図面を特定の相手と頻繁にやり取りする場合だけ、その相手との間で入れるのが現実的です。それ以外はリンク共有で足ります。

Q. 社内メールを自社で作る意味はありますか?

取引先ごとの強制TLS、暗号化できないときの警告、添付のリンク共有、PINの仕組みを、自社の使い方に合わせて1つの画面に入れられることです。既製のメールサービスで足りるなら、作る必要はありません。相談の最初に、そこから一緒に決めます。

まとめ

  • メールの暗号化は「経路(TLS)」と「中身(S/MIME)」の2層。AES-256は方式でなく部品
  • 普通の設定では相手が非対応なら平文で送る。止めるのは強制TLSとMTA-STS
  • 一時解除は自動にせず、警告して人が判断
  • 最高を目指すと届かない。相手と情報で段階を決める
  • PPAPは守れていない。添付はリンク共有へ
  • 順番は、なりすまし対策→強制TLS→リンク共有→多要素→必要な文書だけ中身の暗号化

社内メールや業務システムで、この順番を設計に入れたい方は、当社のやり方を見たうえで、下のフォームからどうぞ。

この記事を書いた人

佐藤 駿介

佐藤 駿介

Shunsuke Sato

代表 / Founder & Developer, 合同会社SAi

中小企業のAI・業務自動化を専門とする開発者。営業マンや下請けを介さず、ヒアリングから開発・運用まで一貫して直接対応。「月額1万円から始められる、本当に必要なAIだけ」をモットーに、フルスクラッチ開発を中小企業の手の届く価格で提供している。

ルールだけでは、貼る社員を止められません

漏洩の多くは、良かれと思って貼った社内情報が原因です。当社は、AIが読める範囲と書ける範囲をあらかじめ分け、誰が・どのデータを・何のために処理したかを記録に残す形で、社内のAI利用を仕組みにしています。社外にデータを出さない社内完結の構成もご相談いただけます。初期費用0円・月額制です。

「うちの使い方だと、どこまで許していいか」を、この場で聞いてみる

1営業日以内に返信します。内容を伺う前にNDAを結ぶこともできます。

この記事は編集方針にもとづいて作成しています。 PR掲載について