1. はじめに：なぜ今、PPAPは「危険」とされるのか
長年、日本のビジネスシーンで慣習化していたPPAP（パスワード付きZIPファイルの送付）は、現在急速に廃止が進んでいます。その最大の理由は、セキュリティ対策であるはずの暗号化が、逆に脅威を招いているという皮肉な現実にあります。
パスワードで暗号化されたZIPファイルは、企業のメールゲートウェイやウイルス対策ソフトの中身検査（スキャン）をすり抜けてしまいます。その結果、Emotetなどのマルウェアが添付ファイルとして相手の受信ボックスに直接届いてしまうリスクが顕在化しました。
しかし、このPPAPを廃止し代替手段を選定する段階で、多くの企業が「通信の安全性（盗聴防止・ウイルス検知）」と「宛先間違い（誤送信防止）」を混同しているという新たな課題に直面しています。
本資料では、現在提唱されている主要な脱PPAPソリューションの限界を浮き彫りにし、真に求められる「送信後でも制御可能なセキュリティ」のあり方を考察します。
2. TLS確認方式の限界：マルウェアは防げても「誤送信」は防げない
現在、ユーザーの手間がゼロであることから、脱PPAPの有力候補として「TLS確認方式」が注目されています。これは、通信経路がTLS（Transport Layer Security）で暗号化されていれば、パスワードをかけずに生ファイルを配送する仕組みです。
ウイルス検知は可能になるが
この方式のメリットは、ファイルが生（平文）で送られるため、受信側のサーバーで正しくウイルスチェックが行える点にあります。これにより、PPAPの課題であった「ウイルスチェックのすり抜け」は解決されます。
「土管」の暗号化は宛先間違いを救えない
しかし、ここには情報漏洩という観点で致命的なリスクが残ります。TLSはあくまでサーバー間の安全な「土管」を確保するものであり、「誰に送るか」を制御しません。
- 宛先間違いに無力
- 送信者がメールアドレスを間違えた場合、暗号化された経路を通って第三者の手元に生ファイルが届いてしまいます。
- End-to-Endではない
- サーバー間は安全でも、相手先サーバー内（保存時）の暗号化までは保証されません。
つまりTLS確認方式は、「外部からの攻撃（盗聴・マルウェア）」には有効ですが、「内部からの流出（誤送信）」に対しては、PPAP以下の無防備な状態を作り出す可能性があります。
3. 一般的なOTP（ワンタイムパスワード）の落とし穴
「パスワードを別送する」という点でPPAPと似ているものの、システムが自動発行するため代替案として普及しているのがOTP方式です。しかし、これも誤送信対策としては不十分な側面があります。
「惜しい」セキュリティの欠点
一般的なOTPソリューションは、「メールを送る」→「システムがパスワードを別メールで自動送信する」という流れを取ります。
- 二重の誤送信リスク
- 宛先を間違えると、誤送信先にファイル（またはURL）とOTPの両方が届きます。
- 結果
- 誤送信先でも正規手順でOTPを入力でき、ファイルを開封できてしまいます。
ベンダー選定では「宛先を間違えた相手が開けてしまうか」を必ず確認し、「できてしまう」製品は誤送信対策として不十分と判断すべきです。
4. 送信一時保留・上長承認の限界：「人」に依存する防御の脆さ
誤送信対策として「送信を即時実行しない」「上長承認を必須にする」方式もありますが、構造的な限界があります。
PPAP対策（脱PPAP）としての不十分さ
この方式は配送タイミングを制御するだけで、送付方式自体を変えません。承認されれば従来通り送られるため、PPAP由来の課題（ウイルス検査すり抜け等）の根本解決にはなりません。
「送信後」のコントロール不可と形骸化リスク
- 承認後のリスク
- 承認が誤っていた場合でも、送信後にファイルを回収できません。
- 形骸化のリスク
- 承認依頼が増えると形式的チェック（メクラ判）になり、防御壁として機能しなくなります。
5. コンテンツ検査（DLP）の限界：文脈を理解できない機械の壁
AIやキーワード辞書で機密情報を検知するDLP方式も有効ですが、業務文脈の誤りには限界があります。
例えば「通常の見積書をA社ではなくB社へ送ってしまう」といった文脈ミスは、データパターン検知だけでは防げません。
6. 真の解決策：受取人を「固定」する認証基盤の構築
これまでの対策の共通課題は、「手元を離れたファイルの制御が、送信者の注意力や機械検知に依存している」点です。これを打破するのが、アクセス権を厳密に管理する認証型アプローチです。
アプローチA：IRM/DRM（ファイル権限管理）
- あとから制御できる
- 権限を剥奪すれば、相手PCに保存済みのファイルでも再閲覧を禁止できます。
- 操作制限
- コピー禁止・印刷禁止など、詳細なポリシー設定が可能です。
アプローチB：認証型クラウドストレージ（ダウンロード認証）
URL配布時に単純なパスワード入力ではなく、メールアドレス認証やID連携で本人確認を行う方式です。
- 本人確認の徹底
- 受信者に本人情報入力を求め、許可リストと一致しない場合は認証コードを発行しません。
アプローチB ダウンロード認証（Transfer Center）がもたらす安心感
特に誤送信対策として有効なのが、Transfer Center（https://transfercenter.jp/）に代表される「宛先事前指定型の認証（ダウンロード認証）」です。
仕組み：なぜ誤送信しても開けないのか
決定的な違いは、「認証される人を、ファイルアップロード時に送信メールとは別で設定・限定する」点にあります。
- 認証対象の事前設定
- 送信者は、ダウンロードを許可する相手を事前登録します（メールアドレス・電話番号に対応）。
- 受信者の操作
- URLクリック後、本人確認画面でメールアドレスまたは電話番号を入力します。
- システム判定
- 許可リストに一致する相手のみ認証コードが発行され、第三者には発行されません。
「気づかなくていい」セキュリティ
最大の利点は、送信者がミスに気づかなくても、システムが継続的に第三者アクセスを遮断することです。PPAPのウイルス検査不可と、TLS方式の誤送信対策不足を同時に解決できます。
7. 結論：PPAP対策の本質は「信頼の自動化」にある
PPAP廃止後に目指すべきは、単なる暗号化の自動化ではなく、「正当な受取人確認の自動化」です。
TLS確認方式は通信路の安全とウイルス検知に有効ですが、誤送信には無力です。ヒューマンエラーを前提にするなら、「送信後に何もしなくても第三者に開かせない」設計思想を持つIRMやダウンロード認証の導入こそ、運用負荷と安全性を両立する現実解だと言えます。
