ここ数年「PPAPはもうやめよう」という論調が強まっていますが、メールに依存する現場で完全に排除するのは難しいのが実情です。PPAPが批判される理由と、SMTP自体が秘匿ファイルに不向きな構造を整理し、代替策と、やむを得ず使うときの落とし所をまとめます。
PPAPの簡単な整理
- Password付きZIPファイルと、そのパスワードを別メールで送る運用の通称がPPAPです。
- 目的は、宛先外から添付ファイルを簡単に閲覧されないよう最低限の防御を置くこと。
- とはいえ、同じSMTP経路でパスワードを流すため盗聴リスクは残り、解凍手間や誤送信対策としては弱い、という批判が大きくなっています。
「PPAP=絶対ダメ」ではないが、万能でもない
- ZIP暗号化は総当たり耐性が高く、クラウド事業者やメールプロバイダーが中身を自動参照するのを抑止する効果はあります。
- しかし「誤送信を防ぐ」「盗聴を防ぐ」「マルウェア拡散を止める」といった本質的な課題は十分に解決しません。
- 使い所を間違えると手間だけ増えて守りは強化されない――このギャップが批判の主因です。
SMTPが秘匿ファイル送信に向かない理由
- 通信経路の分散保管：SMTPは宛先まで複数サーバーを経由し、平文保存される区間が残るケースがあります。TLSで輸送路を守れても、途中や受信側の保管を強制できません。
- ウイルス拡散経路としての歴史：添付メールはマルウェア配布に広く使われており、組織のスキャン運用や受信拒否設定に左右されます。添付に頼るほど配送失敗や隔離のリスクが増えます。
ファイル送信はSMTP以外を基本にする
- 期限付きリンクやアクセス制御があるストレージ共有（OneDrive/SharePoint/Box/Google Driveなど）。
- エンドツーエンド暗号化を備えたビジネス向けメッセージング（Teams/Slackの権限付き共有等）。
- 監査ログやダウンロード制御を備える専用ファイル転送サービス（SFTP/HTTPSベースの社内FTなど）。
- これらに切り替えることで、配送可否の透明性と誤送信後の回収手段を確保できます。
それでもSMTPで送りたい場合の最低ライン
- 添付前にファイルをAES暗号化し、パスワードはSMSや別チャットなど異なる経路で共有する（PPAPの弱点を少しでも緩和）。
- メール本文でパスワードを推測しにくくする／再利用しない。短寿命パスワードを発行する。
- 受信側も解凍前にウイルススキャンを通す運用を合わせる。
- 上記は「リスクを受容した上での次善策」にすぎず、秘匿性や誤送信リカバリーは限定的だと理解しておくことが重要です。
まとめ：ポリシーとしての線引きを明確に
- 機密度が高いものは「SMTPで送らない」を原則にし、代替チャネルを標準化する。
- メールしか使えない相手・状況では、PPAP的な暗号化を最低限の防御として実施しつつ、送信ログや件名で機密性を落とす工夫を加える。
- 「手間の割に守れない」状態を避けるため、運用負荷・残余リスク・代替手段の有無をセットで判断する――これが現実的な落とし所です。