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

小村 豪

doi:10.5281/zenodo.21589758

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

2026年04月03日 01:00 · 更新日: 2026年08月02日 · 小村豪 · メールセキュリティ, PPAP, 情報漏えい対策, B2B, 既存資産活用

更新履歴(4件・最終更新 2026年08月02日)

この記事に加えた変更の記録です。アーカイブした更新前のバージョンは、DOI付きの固定URLから読めます。

2026年08月02日: 記事の冒頭に「この記事の知識マップ」節を追加しました。本文で扱っている概念とその関係を、要約・図・詳細ページへのリンクにまとめたものです。本文の主張は変えていません。
2026年08月01日: 外部レビュー(1283件)への対応として本文を更新しました。個々の変更内容は、この下の履歴を参照してください。
2026年08月01日: 代替手段の章を具体化し、何を満たせばPPAPの代わりになるかの比較表、すでに契約している範囲でできること、自前で作る場合にそろえる6項目を追加しました。判断フロー図に同じ内容の表を併記し、用語表と対象読者の表を冒頭に置きました。脚注の列挙順を初出順に直し、表示される番号が昇順になるようにしました。
2026年07月31日: 参考リンクの並び順が本文で参照している順と食い違っていたのを揃え、関連記事リンクの文言をリンク先の現在のタイトルに直しました。
2026年04月03日: 初版公開

この記事を引用する(DOI: 10.5281/zenodo.21589758)

この記事はZenodoにアーカイブされています。常に最新版へ解決されるDOIと、いま表示している版に固定されたDOIの両方を下に示します。

小村豪(2026)「なぜメールセキュリティにおいて PPAP はダメなのか。正しいやり方は？」合同会社小村ソフト. https://doi.org/10.5281/zenodo.21589758 https://staging.comcomponent.com/blog/2026/04/03/000-why-ppap-is-bad-and-what-to-do/

DOI(最新版): 10.5281/zenodo.21589758
DOI(この版): 10.5281/zenodo.21732776

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

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

この記事では、2026 年 4 月時点で確認できる公的資料や一次情報をもとに、PPAP の問題点と、実務でどう置き換えるのが自然かを見ていきます。¹²³⁴⁵⁶⁷⁸⁹¹⁰

この記事の対象読者と前提

項目	内容
対象読者	中小企業の情シス担当者、メール運用の管理者、社内ルールを決める立場の方。「PPAP をやめろと言われたが、代わりに何を用意すればよいのか」を判断したい人を想定しています
前提とする知識	メールの送受信ができること。暗号やメールプロトコルの知識は前提にしません
前提とする環境	特定の製品に依存しません。Microsoft 365、Google Workspace、レンタルサーバーのメール、オンプレのメールサーバーのいずれでも同じ判断になります
判断に必要なもの	自社が今どのメール基盤を使っているかと、社外とのファイル受け渡しが月にどのくらい発生しているか。この 2 つが分かれば、第 4 章の選択に進めます

この記事で使う用語

第 3 章以降で説明なしに出てくる言葉を、先に一行ずつ整理しておきます。

用語	ひとことで言うと
TLS	通信そのものを暗号化する仕組み。Web の HTTPS と同じ技術です。守るのは通信路だけなので、届いた先のメールボックスの中では平文に戻ります
STARTTLS	平文で始めたメール送受信の接続を、途中から TLS に切り替えるための命令。既存のポートのまま暗号化へ移行できるため、メールでは広く使われています
S/MIME	メールそのものに電子署名や暗号化を施す仕組み。証明書を使うので、送信者が本人であることと途中で改ざんされていないことを受信側が確認できます。通信路ではなくメールの中身を守るため、経路の途中に何が挟まっても効き目が変わりません
認証付きダウンロード	ファイルを添付せず、相手にログインしてもらってから渡す方式。誰がいつ取得したかの記録、期限、失効、相手ごとの権限を扱えます
失効	いったん渡したリンクやファイルへのアクセスを、あとから無効にできること。誤送信に気づいたあとで止められるかどうかが分かれ目になります

1. まず結論

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

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

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

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

この記事の知識マップ

PPAPはパスワード付きZIPを送ったあと同じメール系統でパスワードを別送する運用ですが、盗聴対策としては弱く、誤送信が起きるとパスワードごと同じ相手に届いて事故が完成し、暗号化された添付がマルウェア検査をすり抜けやすく、送信者の真正性やアクセス制御も担保しません。代替として、通常の業務メールはTLS/STARTTLSによる通信路保護を前提にし、真正性や本文の暗号化が必要ならS/MIMEを使い、機密ファイルの受け渡しは権限設定・期限・失効を扱える認証付きダウンロードやOneDrive・Googleドライブのアクセス制御付き共有に置き換えることが実務上の答えになります。どうしても添付が必要な場合に限り、パスワードを別経路で伝える運用は暫定策として位置づけられます。

flowchart LR
    accTitle: PPAPがダメな理由と代替策の知識マップ
    accDescr: PPAPが盗聴対策や誤送信対策として弱くマルウェア検査もすり抜けやすいこと、そして通常メールのTLSやS/MIMEでの保護と、機密ファイルの認証付き共有への置き換えが必要になることを示す図。
    ppap["PPAP"]
    authenticated_file_sharing["認証付きダウンロード/アクセス制御付き共有"]
    password_protected_zip_attachment["パスワード付きZIP添付"]
    same_channel_password_delivery["同じメール系統でのパスワード別送"]
    email_confidentiality["メールの盗聴対策(秘匿性)"]
    misdirected_email_impact["誤送信時の被害"]
    malware_scan_evasion["マルウェア検査のすり抜け"]
    emotet["Emotet"]
    sender_authenticity["送信者の真正性"]
    email_access_control["メール・ファイルのアクセス制御"]
    tls_email_transport["TLS/STARTTLSによる通信路保護"]
    normal_business_email["通常の業務メール"]
    smime["S/MIME"]
    confidential_file_transfer["機密ファイルの受け渡し"]
    link_revocation["リンク・アクセス権の失効"]
    access_expiration["共有の有効期限"]
    onedrive_sharepoint_sharing["OneDrive/SharePointの共有機能"]
    google_drive_sharing["Googleドライブの共有機能"]
    manual_out_of_band_password_delivery["パスワードの別経路手動伝達"]
    ppap -->|"利用する"| password_protected_zip_attachment
    ppap -->|"利用する"| same_channel_password_delivery
    ppap -->|"用いるのは非推奨"| email_confidentiality
    ppap -.->|"原因になり得る"| misdirected_email_impact
    ppap -->|"原因になり得る"| malware_scan_evasion
    emotet -->|"利用する"| malware_scan_evasion
    ppap -->|"用いるのは非推奨"| sender_authenticity
    ppap -->|"用いるのは非推奨"| email_access_control
    tls_email_transport -->|"推奨される対応"| normal_business_email
    smime -.->|"推奨される対応"| normal_business_email
    smime -->|"実装を担う"| sender_authenticity
    authenticated_file_sharing -->|"推奨される対応"| confidential_file_transfer
    authenticated_file_sharing -->|"前提とする"| email_access_control
    authenticated_file_sharing -->|"前提とする"| link_revocation
    authenticated_file_sharing -->|"前提とする"| access_expiration
    ppap -->|"両立しない"| link_revocation
    onedrive_sharepoint_sharing -->|"実装を担う"| authenticated_file_sharing
    google_drive_sharing -->|"実装を担う"| authenticated_file_sharing
    onedrive_sharepoint_sharing -->|"で構成できる"| access_expiration
    google_drive_sharing -.->|"で構成できる"| access_expiration
    authenticated_file_sharing -->|"の後継"| ppap
    manual_out_of_band_password_delivery -.->|"推奨される対応"| confidential_file_transfer

図の実線は常に成り立つ関係、破線は条件付きの関係です(成立条件は詳細ページの各関係の説明に記載)。関係すべての一覧(全22件、根拠・確度つき)と主要概念の定義は知識マップ詳細ページにまとめています。データ: JSON-LD / Turtle

2. そもそも PPAP とは何か

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

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

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

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

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

3. なぜ PPAP がダメなのか

3.1 盗聴対策として弱い

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

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

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

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

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

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

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

これは PPAP の問題の中でも見逃せない点です。

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

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

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

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

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

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

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

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

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

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

4.1 普通の業務メール

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

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

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

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

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

「何を買えばよいか」の前に、満たすべき条件を決める

製品名から入ると比較できなくなるので、先に条件を並べます。PPAP との差は、この 6 行に集約されます。

満たしたい条件	PPAP	認証付きダウンロード / アクセス制御付き共有
受け取る人を限定できる	できない。ZIP とパスワードが揃えば誰でも開けます	できる。相手のアカウントで認証させれば、転送されても開けません
誤送信のあとで止められる	止められない。送った時点で終わりです	止められる。リンクの失効やアクセス権の削除で後追いできます
期限を切れる	切れない	切れる
誰が受け取ったか分かる	分からない	分かる（履歴が残る製品を選べば）
経路上のウイルス検査が効く	効きにくい。暗号化されているため検査をすり抜けます²	効く。暗号化されていないファイルとして保管・検査できます
相手の手間	ZIP の解凍とパスワード貼り付け	リンクを開く（アカウントが必要な場合はサインイン）

この表の左から右へ移すことが「PPAP をやめる」の実体です。逆に言えば、この 6 行を満たさない代替策なら、乗り換える意味は薄いということでもあります。

多くの場合、すでに契約している範囲でできる

新しい製品を買う前に、今の契約でどこまでできるかを確認するほうが先です。代表的なところでは、次のようになっています。

使っているもの	できること
Microsoft 365（OneDrive / SharePoint）	共有リンクを作るときに「特定のユーザー」を選んで相手を限定でき、「有効期限の設定」と「パスワードの設定」も指定できます（Microsoft 365 サブスクリプション向けの機能です）¹¹
Google Workspace（Google ドライブ）	相手を指定して「閲覧者」「閲覧者（コメント可）」「編集者」の権限を分けられます。対象となる職場・学校アカウントでは、アクセスに「有効期限」を付けられます¹²

優先順位は、「特定の相手を指定した共有」が第一、「パスワード付きリンク」は次善策です。相手がアカウントを用意できない場合に限ってパスワード付きリンクを使い、そのパスワードは電話や SMS など、メールとは別の経路で伝えます。ここで同じメール系統に流してしまうと、置き換えたつもりで PPAP と同じ構造に戻ります。

自前で作る場合に最低限そろえるもの

自社サイトにダウンロード機能を作る場合も、考えることは変わりません。

相手を識別する手段 受け渡し相手にアカウントを発行するか、案件ごとに使い捨てのトークン付き URL を発行します。
期限 URL とトークンの両方に有効期限を持たせます。期限切れは「見えない」ではなく「失効しました」と明示的に返します。
失効の操作 運用担当が管理画面から即座に無効化できることが必要です。ここが無いと、誤送信に気づいても何もできません。
アクセスログ いつ、どの IP から、どのファイルが取得されたかを残します。事故が起きたときに「渡ったのか、渡っていないのか」を答えられるかどうかが分かれ目です。
ファイルの置き場所の保護 URL を知っていれば誰でも取れる状態にしない、ということです。IPA も、非公開情報を扱う Web サイトには認証機能とアクセス制御が必要だと整理しています。⁸
アップロード側の扱い 相手から受け取る場合も同じ仕組みに寄せます。受信専用のフォームを作るほうが、メール添付を受け続けるより安全です。

この 6 つのうち、2 と 3 が PPAP との決定的な差です。作るにせよ買うにせよ、ここが無いものは代替になりません。

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

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

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

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

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

5.1 まず止めるもの

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

5.2 次に決めるもの

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

5.3 最小構成の考え方

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

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

ここが曖昧だと、現場は結局「とりあえず 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

図が表示されない環境のために、同じ判断を表にもしておきます。上から順に見て、最初に当てはまった行の結論を採ります。

渡したいもの	相手の状況	結論
機密性の高いファイルではない	─	通常の業務メールで送る。TLS / STARTTLS を前提にし、真正性や暗号化が重要なら S/MIME を足す
機密性の高いファイル	ログインして受け取れる	認証付きダウンロード / アクセス制御付き共有。必要に応じて権限・期限・失効を設定する
機密性の高いファイル	ログインできないが、添付でなくてもよい	同上。相手にアカウントを用意してもらうか、期限付きの個別リンクを発行する
機密性の高いファイル	ログインできず、どうしても添付が必要	暗号化ファイルを添付し、パスワードはメール以外の経路で手動で伝える（暫定策）

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

7. よくある誤解

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

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

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

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

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

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

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

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

8. まとめ

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

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

という問題が残ります。¹²³⁴

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

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

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

参考資料

内閣府, 平井内閣府特命担当大臣記者会見要旨令和2年11月24日 ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷
IPA, 相談急増／パスワード付きZIPファイルを使った攻撃の例（2020年9月2日） ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶
IPA, 令和5年度秋期応用情報技術者試験解答例 ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶
デジタル庁, デジタル改革に向けたマルチステークホルダーモデルの運用（処分通知等のデジタル化）・意見概要 ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷
IPA, 令和5年度秋期応用情報技術者試験採点講評 ↩ ↩² ↩³ ↩⁴
IPA, 電子署名について ↩ ↩² ↩³ ↩⁴
IPA, 中小企業の情報セキュリティ対策ガイドライン第4.0版 ↩ ↩² ↩³
IPA, 安全なウェブサイトの作り方 - 1.11 アクセス制御や認可制御の欠落 ↩ ↩² ↩³ ↩⁴ ↩⁵
NIST, Security Considerations for Exchanging Files Over the Internet ↩ ↩² ↩³
IPA, CPG（CISA Cross-Sector Cybersecurity Performance Goals）日本語版 ↩ ↩² ↩³
Microsoft サポート, Share OneDrive files and folders ↩
Google ドライブヘルプ, Share files from Google Drive ↩

同じタグを共有する最新の記事です。さらに近い話題で知識を深められます。

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

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

HP制作

認証付きダウンロードページや本人確認付きの受け渡し導線は、Web 側の設計と整備が中心になるためです。

サービスを見るお問い合わせ

技術相談・設計レビュー

既存のメール運用を分類し、どこを TLS / S/MIME / 認証付き共有へ切り替えるかは、実装前の設計レビューとして整理しやすいためです。