合同会社小村ソフト
メニュー

なぜメールセキュリティにおいて PPAP はダメなのか。正しいやり方は？

· · メールセキュリティ, PPAP, 情報漏えい対策, B2B, 既存資産活用

「パスワード付き ZIP を送り、そのあと別メールでパスワードを送る運用は本当に安全なのか」。 この疑問は今でもよく出ます。見た目には暗号化しているので安全そうに見えますが、実務ではそこが落とし穴です。

先に結論を言うと、いわゆる PPAP は、盗聴対策として弱く、誤送信対策としても不十分 で、しかも メール経路上の検査を邪魔しやすい ため、現在のメールセキュリティでは勧めにくい方式です。1234

この記事では、2026 年 4 月時点で確認できる公的資料や一次情報をもとに、PPAP の問題点と、実務でどう置き換えるのが自然かを整理します。12536748910

目次

  1. 1. まず結論
  2. 2. そもそも PPAP とは何か
  3. 3. なぜ PPAP がダメなのか
    • 3.1 盗聴対策として弱い
    • 3.2 誤送信対策として不十分
    • 3.3 マルウェア検査を妨げる
    • 3.4 真正性とアクセス制御を担保しない
  4. 4. 正しいやり方は「目的別に分けること」
    • 4.1 普通の業務メール
    • 4.2 機密ファイルの受け渡し
    • 4.3 どうしても添付が必要な場合
  5. 5. 中小企業での置き換え手順
    • 5.1 まず止めるもの
    • 5.2 次に決めるもの
    • 5.3 最小構成の考え方
  6. 6. 判断フロー
  7. 7. よくある誤解
    • 7.1 「ZIP を暗号化しているのだから安全」
    • 7.2 「別メールで送れば十分」
    • 7.3 「PPAP をやめると添付できなくなる」
    • 7.4 「S/MIME は大企業向けで現実的ではない」
  8. 8. まとめ
  9. 関連記事
  10. 参考資料

1. まず結論

PPAP をやめる話は、暗号化をやめる話ではありません。 やめるべきなのは、「添付ファイルを ZIP で暗号化し、同じメール系統で後からパスワードを送る」 という設計です。

代わりに考えるべきなのは次の 3 つです。

  1. 通常の業務メールは、TLS / STARTTLS のような通信路保護を前提にする。710
  2. メール自体の真正性や暗号化が必要なら、S/MIME のような仕組みを使う。536
  3. 機密ファイルの受け渡しは、添付ではなく認証付きダウンロードやアクセス制御付き共有に寄せる。489

要するに、メールの問題を ZIP のパスワードで全部解決しようとしないことが大事です。

2. そもそも PPAP とは何か

ここでいう PPAP は、一般に次の流れを指します。

  1. ファイルをパスワード付き ZIP にする
  2. 1 通目のメールで ZIP を送る
  3. 2 通目のメールでパスワードを送る

この運用は、「平文で送っていないから安全」と理解されがちです。 ただし、実際には守れている範囲がかなり限定的です。

観点 PPAP で十分か 実際の評価
通信経路上の秘匿性 弱い 同じメール系統で別送すると効果が薄い
誤送信対策 不十分 宛先を間違えた時点で事故が成立しやすい
マルウェア対策 むしろ不利 経路上検査を妨げやすい
送信者の真正性 守れない なりすまし対策ではない
アクセス制御 守れない 誰が閲覧できるかの制御が弱い

見た目ほど万能ではなく、「何となく安全そう」に見えるわりに、肝心な部分を守れていないのが PPAP の問題です。

3. なぜ PPAP がダメなのか

3.1 盗聴対策として弱い

内閣府は、ZIP ファイル送付と同じ経路でパスワードを自動送信する方式は適切でないと整理しています。1 重要なのは、ファイルを暗号化したかどうかだけでなく、鍵をどう渡すかまで含めて設計しないと意味が薄いという点です。

同じメール環境、同じ受信箱、同じ相手に後追いで送るだけでは、ZIP を見られる人とパスワードを見られる人がほぼ同じになりやすいからです。 これでは「暗号化している」という事実だけが残って、実質的な秘匿性はそれほど強くありません。

3.2 誤送信対策として不十分

PPAP を誤送信対策だと考える運用もありますが、そこも弱いです。

IPA の応用情報技術者試験の解答例では、PPAP の問題点として、本文メールを誤送信すると復号用パスワードも誤送信した相手に届いてしまう点が挙げられています。3 デジタル庁の資料でも、「別なメールとして相手方に送るのは、同じ相手に送ることになりコントロールとして機能しない」という趣旨の整理が示されています。4

つまり、間違った相手に ZIP を送ったあと、習慣的にパスワードも送り切ってしまえば、事故はそのまま完成するということです。 本当に必要なのは、宛先確認、承認、送信前レビュー、送信後の失効や回収が可能な受け渡し方式です。

3.3 マルウェア検査を妨げる

これは PPAP の中でもかなり重要です。

IPA は、パスワード付き ZIP を添付した Emotet 攻撃メールについて、添付ファイルが暗号化されているため、メール配送経路上のセキュリティ製品の検知・検疫をすり抜け、受信者の手元に届いてしまう確率が高いと注意喚起しています。2

送信側は「暗号化して安全にしたつもり」でも、受信側や中継側から見ると、中身を検査しにくい添付ファイルになってしまいます。 この点でも、PPAP は現在のメール防御と相性がよい方式とは言えません。

3.4 真正性とアクセス制御を担保しない

PPAP は、送信者が本物であることを証明しません。 また、誰がいつダウンロードしたか、あとから失効できるか、相手ごとに権限を分けられるかといったアクセス制御もほとんど持っていません。

一方で、IPA は S/MIME のような電子署名付きメールを扱っており、PPAP の代替としても文脈上つながっています。56 また、IPA の Web セキュリティ資料では、非公開情報を扱う Web には認証機能とアクセス制御が必要だと整理されています。8

この 2 つを合わせて考えると、答えはかなり明確です。

  • メールの真正性や改ざん検知がほしいなら S/MIME
  • ファイルの閲覧権限や失効管理がほしいなら認証付きダウンロード

ZIP のパスワード別送は、そのどちらにもきれいには答えていません。

4. 正しいやり方は「目的別に分けること」

「安全に送りたい」という要求は、実際には 1 つではありません。 ここを分けないと、全部 PPAP で済ませようとして設計が崩れます。

4.1 普通の業務メール

通常の業務メールなら、まずは TLS / STARTTLS のような通信路保護が前提です。710 その上で、送信者の真正性、改ざん検知、メール本文自体の暗号化が必要なら S/MIME を検討するのが筋です。536

4.2 機密ファイルの受け渡し

相手本人だけにファイルを渡したい、閲覧権限を制御したい、あとから失効したい。 この要件なら、添付よりも認証付きダウンロードやアクセス制御付き共有のほうが自然です。489

例えば次のような要件は、添付より Web 側で管理したほうが扱いやすくなります。

  • ログイン後にダウンロードできる
  • 期限付きリンクにできる
  • 相手ごとに権限を分けられる
  • 必要なら履歴を残せる

4.3 どうしても添付が必要な場合

相手の事情でどうしても添付しか使えない場面はあります。 その場合は、内閣府の整理にもあるように、ファイルとパスワードを全く別の経路で伝えることが最低限の線になります。1

ただし、これは完成形ではなく暫定策です。 毎回の標準運用として固定するより、将来的には認証付き共有へ移す前提で考えるほうがよいです。

5. 中小企業での置き換え手順

中小企業で PPAP をやめるときは、最初から大きな仕組みを入れるより、まず分類を明確にするほうが効きます。

5.1 まず止めるもの

  • 自動 ZIP 暗号化
  • 同じメール系統での自動パスワード別送
  • 「重要ファイルは全部 PPAP」という一律ルール

5.2 次に決めるもの

  • 何を通常メールで送ってよいか
  • 何を添付禁止にするか
  • 何を認証付きダウンロードへ回すか
  • 例外的に添付する場合の承認手順をどうするか

5.3 最小構成の考え方

最初は次の 2 系統に分けるだけでも十分です。

  1. 通常メール
    • 業務連絡
    • 必要に応じて S/MIME
  2. 機密ファイル
    • 認証付きダウンロード
    • 権限設定
    • 期限付き共有

ここが曖昧だと、現場は結局「とりあえず PPAP」に戻りやすくなります。

6. 判断フロー

flowchart TD
    A[相手に何を渡したいか] --> B{機密性の高いファイルか}
    B -- いいえ --> C[通常の業務メール]
    C --> C1[TLS / STARTTLS を前提に送る]
    C --> C2[真正性や暗号化が重要なら S/MIME]

    B -- はい --> D{相手がログインして受け取れるか}
    D -- はい --> E[認証付きダウンロード / アクセス制御付き共有]
    E --> E1[必要に応じて権限・期限・失効を設定]

    D -- いいえ --> F{どうしても添付が必要か}
    F -- はい --> G[暗号化ファイル + 別経路の手動パスワード]
    F -- いいえ --> E

この図で重要なのは、PPAP を万能な中間解として置かないことです。 メールとファイル受け渡しは、分けて考えたほうが設計しやすくなります。

7. よくある誤解

7.1 「ZIP を暗号化しているのだから安全」

暗号化していても、鍵の渡し方が弱ければ十分ではありません。 しかもパスワード付き ZIP は、経路上検査を妨げることがあります。12

7.2 「別メールで送れば十分」

同じ相手、同じメール系統への後送では、強いコントロールにはなりません。14

7.3 「PPAP をやめると添付できなくなる」

そうではありません。 通常メール、S/MIME、認証付きダウンロード、例外時の別経路パスワードを使い分けるだけです。

7.4 「S/MIME は大企業向けで現実的ではない」

相手側の対応状況は見ますが、少なくとも PPAP よりは、何を守りたいのかに対して筋が通っています。 また、S/MIME が合わない相手には、認証付きダウンロードという別の選択肢があります。

8. まとめ

PPAP がダメなのは、暗号化しているのに安全になった気がしやすいところにあります。 実際には、

  • 同じメール系統での別送は秘匿性が弱い
  • 誤送信対策として不十分
  • パスワード付き ZIP は経路上検査を妨げる
  • 送信者の真正性やアクセス制御は担保できない

という問題が残ります。1234

したがって、やるべきことは PPAP 風の運用を少し変えて延命することではありません。 メールはメールとして守り、ファイル受け渡しはファイル受け渡しとして設計することです。

一言でまとめるなら、こうです。

PPAP をやめるとは、暗号化をやめることではなく、間違ったコントロールをやめて、目的に合ったコントロールへ置き換えることです。

関連記事

参考資料

  1. 内閣府, 平井内閣府特命担当大臣記者会見要旨 令和2年11月24日 ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7

  2. IPA, 相談急増／パスワード付きZIPファイルを使った攻撃の例（2020年9月2日） ↩ ↩2 ↩3 ↩4 ↩5

  3. IPA, 令和5年度 秋期 応用情報技術者試験 解答例 ↩ ↩2 ↩3 ↩4 ↩5 ↩6

  4. デジタル庁, デジタル改革に向けたマルチステークホルダーモデルの運用（処分通知等のデジタル化）・意見概要 ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7

  5. IPA, 令和5年度 秋期 応用情報技術者試験 採点講評 ↩ ↩2 ↩3 ↩4

  6. IPA, 電子署名について ↩ ↩2 ↩3 ↩4

  7. IPA, 中小企業の情報セキュリティ対策ガイドライン 第4.0版 ↩ ↩2 ↩3

  8. IPA, 安全なウェブサイトの作り方 - 1.11 アクセス制御や認可制御の欠落 ↩ ↩2 ↩3 ↩4

  9. NIST, Security Considerations for Exchanging Files Over the Internet ↩ ↩2 ↩3

  10. IPA, CPG（CISA Cross-Sector Cybersecurity Performance Goals）日本語版 ↩ ↩2 ↩3

関連トピック

このテーマと近いトピックページです。記事を起点に、関連するサービスや他の記事へ進めます。

このテーマがつながるサービス

この記事は次のサービスページにつながります。近い入口からご覧ください。

著者プロフィール

記事の著者プロフィールページです。

小村 豪

合同会社小村ソフト 代表

Windows ソフト開発、技術相談、不具合調査を中心に、既存資産が残る案件や原因が見えにくい障害調査に強みがあります。

お問い合わせ

公開リンク

ブログ一覧に戻る