脱PPAP：パスワード付きZIPをやめる理由と代替手段の選び分け・社内ルールの決め方

パスワード付きZIPを添付し、パスワードを後続のメールで送る。この手順を社内標準にしている会社が、取引先から「別の方法で送ってほしい」と連絡を受ける場面が増えています。内閣府と内閣官房は2020年11月26日にこの方式を廃止し、JPCERT/CCはマルウェアEmotetがパスワード付きZIPを添付形式として使った事実を注意喚起に記録しました。この記事では、PPAPが何を守れていないのかを暗号と鍵配送の関係から整理し、共有リンク・ファイル転送サービス・S/MIME・TLS強制の4方式を適用範囲で比較します。そのうえで受信ポリシーの決め方から、基幹システムからの帳票自動送付の作り替えまで、社内ルールとシステム設定に落とす順序を示します。

まとめ：脱PPAPの結論と代替手段の選び分け

結論から示します。PPAPは廃止してよい方式です。理由は暗号が弱いからではなく、暗号の鍵であるパスワードを暗号文と同じ経路に流すため、経路を盗まれた時点で暗号が無意味になる構造にあります。加えて受信側のマルウェア検査が中身を開けられず、攻撃者にとっては検知を避ける都合のよい包装になります。

移行先は用途で分けます。日常の社外授受はクラウドストレージの共有リンクへ一本化し、大容量の単発送付だけをファイル転送サービスに残す。契約書など相手が限定された取引にはS/MIME、全社の下支えにはメールサーバ間のTLS強制を敷く。この4層で足ります。

着手順序を間違えないことが移行の成否を決めます。送信側の切り替えより先に、自社が「パスワード付きZIPを受け取らない」と決めてください。受信ポリシーが無いまま送信方法だけ変えると、社外から届くZIPを開き続ける運用が残り、検知の穴は塞がりません。最後に残るのが基幹システムや複合機からの自動送信で、ここはシステム改修になります。

PPAPの定義と送信手順の内訳：略語の由来とパスワード別送が守れない範囲

まず言葉の整理から始めます。何を指す語なのかを手順の粒度で確認しておくと、後の判断がぶれません。

PPAPという略語の由来と、自動車業界の同名プロセスとの区別

PPAPは、パスワード付きZIPを添付したメールと、そのパスワードを記した後続メールを同じ相手に送る運用を指す語呂合わせです。日本のセキュリティ実務でだけ通じる俗称で、英語圏の標準用語ではありません。同名語が2つあるため社内文書では注意が必要で、自動車業界の生産部品承認プロセス（Production Part Approval Process）と2016年に流行した楽曲がそれにあたります。「PPAP禁止」とだけ書くと品質保証部門に誤読されるので、社内規程では「パスワード付きZIPファイルの分割送信」と書き下してください。

同一経路のパスワード別送で、AES暗号の強度が意味を失う仕組み

ZIPの暗号化そのものは弱くありません。ZIP 2.0互換のZipCrypto方式は既知平文攻撃に耐えられないため避けるべきですが、7-ZipやWindows以外の圧縮ソフトが対応するAES-256方式なら、暗号アルゴリズムの側から破る現実的な手段はありません。問題は暗号方式ではなく鍵の配送経路にあります。

暗号は暗号文と鍵が別の経路にあることを前提に成り立ちます。PPAPは両方を同じメール経路に流すため、経路上の1点を押さえた攻撃者は暗号文と鍵をまとめて手にします。メールボックスへの不正アクセス、誤送信、転送設定の乗っ取り、どれも2通が同じ場所に届く事故です。鍵の管理と方式の選び方は暗号化の基礎と共通鍵・公開鍵の違いで整理しました。鍵を別経路にできないなら、暗号化の手間は守りに変わりません。

PPAPが実務で生む問題：マルウェア検知の失敗と漏えい報告への影響

PPAPをやめる理由は「政府が廃止したから」ではありません。受信側の防御が働かなくなる、そして誤送信時に法定の報告義務から逃れられなくなる、という2つの実害があります。順に見ていきます。

Emotetがパスワード付きZIPを選んだ経緯とJPCERT/CCの観測記録

JPCERT/CCのマルウェアEmotetの感染再拡大に関する注意喚起（発行2022年2月10日、最終更新2023年3月20日）には、攻撃側が添付形式を変えてきた経過が日付付きで残されています。2021年11月後半に活動が再開し、2022年2月第一週に感染が急拡大。2022年4月25日頃からは、ショートカットファイル（LNKファイル）あるいはそれを含むパスワード付きZipファイルを添付する手法が観測されました。

攻撃者がこの形式を選んだ理由は、受信側のセキュリティ製品が中身を検査できないからです。同じ注意喚起には、2023年3月7日以降に展開後500MBを超えるdocファイルを使う変化も記録され、検知回避を狙ったものと説明されています。パスワードによる包装は、その回避手法の系列にあります。取引先を装って返信の形で届く手口は標的型攻撃メールの見分け方と多層防御で扱いました。

メールゲートウェイのウイルス検査とDLPをすり抜ける構造上の理由

メールゲートウェイのウイルス検査は、添付を展開して中身のパターンや振る舞いを見ます。パスワードで暗号化されたZIPは展開できず、検査対象から外れて素通りします。サンドボックスで挙動を見る製品も、パスワードが分からなければ実行に持ち込めません。

影響は受信時だけではありません。送信側で機密情報の外部流出を検知するDLPも、暗号化された添付を読めないため、マイナンバーや口座情報が含まれていてもキーワード検査は反応しません。PPAPは受信側のマルウェア検知と送信側の情報流出検知を同時に無効化します。総当たりで解除する機能を持つゲートウェイ製品もありますが、攻撃者にも同じ手が使える裏返しなので防御の根拠にはなりません。

誤送信が漏えい等報告の対象になる範囲と、速報3〜5日以内の期限

個人情報保護法では2022年（令和4年）4月1日から、個人データの漏えい等について個人情報保護委員会への報告と本人への通知が義務になりました。漏えい等報告・本人への通知の義務化についてのとおり、報告対象は施行規則第7条の4類型、すなわち要配慮個人情報を含む場合、財産的被害のおそれがある場合、不正の目的による行為の場合、本人の数が1,000人を超える場合です。

期限も定められています。漏えい等の対応とお役立ち資料では、事態を知った後、速やか（概ね3〜5日以内）に速報を提出し、原則30日以内に確報を出すこととされました。宛先を1文字誤ってZIPとパスワードを社外へ送った程度の事故でも、中身が1,000人超の名簿ならこの時計が動き出します。3〜5日は、原因調査と並行して報告文を書く時間としては短い幅です。

高度な暗号化による報告義務の除外がPPAPでは成り立たない理由

ここが実務で最も誤解されている論点です。個人情報保護委員会のガイドライン（通則編）3-5-3-1には、規則第7条各号の説明として「高度な暗号化等の秘匿化がされている場合等、『高度な暗号化その他の個人の権利利益を保護するために必要な措置』が講じられている場合については、報告を要しない」との記載があります。暗号化していれば報告義務を免れる余地がある、という条文構造です。

この除外を根拠にPPAPを続ける説明を社内で聞いたら、そこは崩してください。除外が成り立つのは、漏えいした情報を第三者が復元できない状態のときです。パスワードを同じ経路の後続メールで送っていれば、経路を押さえた相手にとって暗号文と鍵は一体です。誤送信なら、誤った宛先に鍵も届きます。秘匿化が機能していない以上、除外の前提を満たしません。逆に、鍵を電話や別サービスで渡していれば除外を主張できる余地は残ります。PPAPをやめる判断は、この一点だけでも合理性があります。

行政と取引先の廃止動向：内閣府が2020年11月26日に踏み切った経緯

方式を変える提案は、社内では「取引先が困る」で止まりがちです。行政の廃止事例は、その反論に対して使える材料になります。会見録に残った理由の書き方まで見ておきます。

内閣府と内閣官房が廃止に踏み切った経緯と大臣会見で示された理由

2020年11月17日、当時の平井内閣府特命担当大臣は記者会見で、アイデアボックスに寄せられた提案のうち得票数第1位が「暗号化ZIPファイルの廃止」だったことを挙げ、内閣府・内閣官房で廃止する方向で検討していると述べました。省庁の外から出た要望が起点になっている点が特徴です。

1週間後の11月24日の会見では、11月26日に廃止する予定と明言されました。理由の説明は「セキュリティ対策の観点からも、受け取る側の利便性の観点からも、適切なものではない」というものです。安全性だけでなく受信側の手間を並べて廃止理由にしているところを、社内提案ではそのまま引いてください。反対意見の多くは送信側の都合を根拠にしています。

代替手段が未定のまま廃止した事実から読み取れる移行の着手順序

同じ11月24日の会見で、廃止後にどう送るのかを問われた大臣は「それはまだ決まっていません」と答え、当面は電話でパスワードを伝える形にならざるを得ないという見通しを述べています。代替システムの調達を待たずに、まず方式を止めたわけです。

この順序は民間でも使えます。共有ストレージの選定や稟議には数か月かかる一方、「パスワードを同じ経路で送らない」という決定は今日から実行できます。電話や別サービスでの鍵渡しは効率が悪く、恒久策にはなりません。それでも暫定の受け皿としては成立します。最も長く穴を残すのは、完璧な代替が決まるまで現行方式を続ける判断です。なりすましメールの被害は個人情報保護委員会が注意喚起を出す水準で続いています。

代替手段4方式の比較：共有リンク・転送サービス・S/MIME・TLS強制の適用範囲

代替手段は1つに絞る必要がありません。用途の違う4方式を層として組み合わせるのが実務解です。どこにどれを当てるかを、受信側の手間と監査ログの有無で比べます。

代替4方式の適用範囲と運用コストを2軸で並べた比較表の読み方

次の表は、4方式を「主な用途」と「受信側の手間」「監査ログ」「導入の壁」で並べたものです。全社標準に据えられるのは1行目だけで、残りは補完の位置づけになります。

読み方の要点は、受信側の手間が最も軽いTLS強制が単独では誤送信を防げない、という非対称性にあります。TLSはメールサーバ間の盗聴を防ぐだけなので、宛先を間違えれば暗号化されたまま正しく誤配されます。共有リンクは受信側にひと手間を課す代わり、宛先限定と失効という回復手段を持つ点で対照的です。

クラウドの共有リンクで設定すべき有効期限・宛先限定などの5項目

共有リンクへ移すとき、既定値のままでは「URLを知っていれば誰でも開ける」状態になりがちです。テナント側で最低限そろえる設定は次の5項目です。

• 有効期限：営業日で7日程度を既定にし、期限なしを管理者が禁止する
• 宛先限定：組織外リンクは相手のメールアドレスで認証し、URLだけでは開かせない
• 権限：既定を閲覧のみにし、編集権限は個別申請にする
• ダウンロード回数と再共有：転送された先での二次配布を止める
• 監査ログ：誰がいつ開いたかを90日以上保持し、事故調査に使える形にする

事故対応で効くのは監査ログと宛先限定です。誤送信に気づいた時点でリンクを失効させ、開封の有無をログで確認できれば、漏えいが発生していないと説明する材料になります。製品ごとの設定範囲と料金は法人向けクラウドストレージの比較にまとめました。

S/MIMEとTLS強制が解く問題と、解けない問題の切り分け方

S/MIMEは電子証明書でメール本文と添付を暗号化し、送信者を署名で証明します。解けるのは経路上の盗聴となりすましの2つ、解けないのは誤送信です。宛先を間違えれば相手の公開鍵で正しく暗号化して届きます。証明書を社外の相手に配布し期限切れを管理する負荷も残るため、取引先が数社に限られる契約業務向けと考えてください。

TLS強制（MTA間のSMTP over TLS）は全社に敷く土台です。相手のメールサーバが対応していれば経路は暗号化され、送信者も受信者も操作は変わりません。必須にすると非対応の相手に届かなくなるため、日和見TLSから始めて到達性を確認し、主要取引先を強制対象へ移す進め方が現実的です。大容量の単発送付にファイル転送サービスを使う場合は、部門ごとの契約が乱立しないよう全社で1つに絞り、監査ログが取れる製品に限ってください。

社内ルールの書き換え手順：受信ポリシーを先に決める移行の進め方

ここからは社内文書とシステム設定の作業です。順序を逆にすると移行が止まるため、決める順番から説明します。

パスワード付きZIPを受け取らない受信ポリシーを先に決める理由

脱PPAPを送信方法の変更として始めると、たいてい途中で止まります。取引先の同意を待つ工程が入るからです。先に決めるべきは受信側、つまり自社に届くパスワード付きZIPをどう扱うかです。ゲートウェイで隔離し、送信者へ「別の方法で再送してほしい」と自動返信する。この設定は相手の同意を必要とせず、自社の判断だけで完了します。

先に置く効果は、マルウェア検知の穴が即日で塞がること、社内の送信運用を変える動機が生まれること、取引先への通知に「弊社では受信できません」と具体的な理由を書けることの3つです。通知文には隔離の開始日、代替として案内する自社の共有リンク、緊急時の連絡先を入れてください。「セキュリティ強化のため」だけの通知は、相手の担当者が上司に説明できず差し戻されます。

取引先への周知と例外運用の期限設定、複合機や基幹からの自動送信の棚卸し

周知と切り替えは次の順で進めます。全体を4か月程度で区切ると、例外が恒久化しません。

1. 受信ポリシーの決定とゲートウェイ設定（社内決裁のみで完了。1か月目）
2. 送信経路の棚卸し。人が送るメールだけでなく、複合機のスキャン送信、基幹システムの帳票配信、EDIの補助送信を洗い出す（1〜2か月目）
3. 共有リンクの設定変更と全社案内。既定の有効期限と権限をここで固定する（2か月目）
4. 取引先への通知と受信の隔離開始。例外申請は期限付きで受け付ける（3か月目）
5. 例外の棚卸しと打ち切り。残った例外はシステム改修の課題として起票する（4か月目）

棚卸しで漏れやすいのが2番目の自動送信です。人手の運用は通知で変わりますが、複合機の宛先帳に登録されたパスワード付きZIP設定や、基幹システムが夜間バッチで送る明細書は、担当者の記憶から抜け落ちます。SMTPログを送信元IPで集計し、人以外が送っているメールを先に特定してください。認証やアクセス制御の考え方を境界の外側まで広げる整理はゼロトラストと境界型防御の違いにまとめています。

システム設定に落とす脱PPAP：帳票自動送付の作り替えと見送り条件

最後に残るのは、人の運用変更では消えない部分です。ここは設計と開発の話になります。受託開発の現場で実際に工数がかかる箇所と、逆に急ぐ必要のない条件を分けて示します。

請求書や帳票の自動送付を、共有リンク発行へ作り替えるときの設計

基幹システムや販売管理システムが月末に請求書PDFをパスワード付きZIPで自動送信している場合、代替は2案に絞られます。1つはストレージのAPIを叩いて共有リンクを発行し、本文にURLだけを載せる案。もう1つは自社の顧客ポータルに帳票を置き、通知メールから認証付きで取りに来させる案です。

判断の分かれ目は取引先数と証跡の要件です。取引先が数十社で受領確認が不要ならAPI発行で足り、改修は帳票配信バッチの出力先変更とリンク生成処理の追加で収まります。受領日時を請求の証跡として残すなら、ポータル側にダウンロード履歴を持たせてください。どちらの案でも、リンクの有効期限が帳票の保存期間より短いという食い違いが起きます。期限切れ後の再取得先を決めないまま公開すると、経理への問い合わせが増えます。

脱PPAPを急がない方がよい条件と、先に手を付けるべき優先順位

方針としては廃止でよいのですが、今すぐ全経路を切り替えるべきでない場面もあります。次の2つの条件に当てはまるなら、順番を後ろに回してください。1つは、送っている中身が公開情報や個人データを含まない事務連絡だけで、かつ相手が官公庁の指定様式でZIPを求めている場合です。もう1つは、電子カルテや制御系のように、外部ストレージへの接続そのものが監査で制限されている閉域ネットワークからの送信です。

この2つ以外は先送りの理由になりません。特に「取引先が対応できない」は根拠として弱く、受信ポリシーの決定と自動送信の棚卸しは相手の同意なしに進められます。優先順位は、受信の隔離、自動送信の特定、共有リンクの既定設定、送信運用の周知の順です。逆にやってはいけないのは、ZIPのパスワードを固定文字列にして取引先と事前共有する折衷案です。これは鍵の使い回しであり、退職者や委託先の担当交代で失効させられません。

SaaS標準機能・内製・受託開発の切り分けと文書管理基盤の位置

作業をどこまで自前でやるかは、対象が人の操作かシステムの出力かで切り分けます。人が送るファイルは、Microsoft 365やGoogle Workspaceの共有リンク機能とゲートウェイ設定で完結するため、開発は不要です。テナント設定と社内規程の改訂で終わります。一方、基幹システムからの帳票配信、部門ごとに分かれた台帳、契約書の保存期間管理が絡むと標準機能の外に出ます。

この境目で有効なのが、社外授受の窓口を文書管理基盤に寄せる設計です。ファイルの版管理と保存期間、閲覧権限、外部共有の記録を1か所に集めれば、脱PPAPは「メールの送り方」ではなく「文書の置き場所」の問題に変わります。基盤に求める機能の整理は文書管理システムの機能とファイルサーバーとの違いを参照してください。既存の基幹システムと接続しながら外部共有の証跡を残す形にしたい場合は、文書管理システム開発で要件整理から対応しています。

よくある質問

脱PPAPの検討でよく出る質問を、判断に必要な範囲で答えます。

PPAPとは何の略ですか？

パスワード付きZIPファイルを添付して送り、そのパスワードを別のメールで送る運用を指す日本国内の俗称です。頭文字の語呂合わせから来ており、法令用語でも国際標準用語でもありません。自動車業界の生産部品承認プロセス（Production Part Approval Process）や同名の楽曲と混同されるため、社内規程では「パスワード付きZIPファイルの分割送信」と書き下すことをおすすめします。

PPAPは本当に意味がないのですか？

暗号としての意味は、パスワードを同じメール経路で送っている限りほぼありません。暗号文と鍵が同じ場所に届くため、経路を押さえた相手には両方が渡ります。加えて受信側のウイルス検査が中身を開けられず、防御を1段落とす副作用があります。ただしパスワードを電話や別サービスで伝えている場合は、鍵配送が分離されているので同じ評価にはなりません。問題は暗号化ではなく別送先の選び方です。

パスワードを別のメールアドレスに送れば問題ないのでしょうか？

同じ組織のメールサーバに届くなら、経路の分離になっていません。攻撃者が侵害するのはメールボックスやサーバであり、宛先アドレスの違いではないためです。分離として成立するのは、電話やSMS、チャットツールのように到達経路と認証が別系統のものです。手間は残るので、共有リンクへ切り替えるまでの暫定手段と考えてください。

取引先がパスワード付きZIPで送ってきた場合はどう対応しますか？

ゲートウェイで隔離し、管理者の確認を経てから開く運用にします。そのうえで送信者へ、自社では受信できないこと、代替として案内する共有リンクのURL、緊急時の連絡先を返します。官公庁の指定様式でZIPを求められるなど例外が要る場合は、期限を付けて申請を受け付けてください。期限のない例外は、数年後に誰も理由を説明できない設定として残ります。

脱PPAPにかかる費用はどのくらいですか？

人が送るファイルの切り替えだけなら、追加費用はほぼ発生しません。Microsoft 365やGoogle Workspaceを既に契約している会社なら、共有リンクの既定設定とゲートウェイの隔離ルールを変えるだけで済み、費用は社内工数と規程改訂に限られます。費用が発生するのは、基幹システムからの帳票自動送付の改修と、文書管理基盤を新設する場合です。前者の規模は対象システム数と証跡要件で決まります。

関連記事

• 認証・ID管理とは？MFA・SSO・OIDC・IDaaSの違いと選定を解説：共有リンクの宛先限定を成り立たせる、社外ユーザーの認証方式の選び方を扱っています
• クラウドストレージとは？仕組み・3つの種類とオンプレとの違い：共有リンクの発行をAPIで自動化するときの前提知識を実装目線で整理しています
• 暗号化とは？共通鍵・公開鍵の違いと企業が守るべきデータの判断：鍵配送の分離という本記事の前提を、暗号方式の側から説明しています