PPAPメールとは？脱PPAPの代替手段を11軸で比較｜PPAP対策の実務ガイド

同じ綴りの「PPAP」には、ピコ太郎氏の楽曲と、自動車業界の生産部品承認プロセス（Production Part Approval Process）があります。本記事が扱うのは、それらとは別の、メール添付にまつわる運用の話です。

編集方針について：本記事はクライアントワークOS「Terasu」を提供するTerasu編集部が作成しています。当社は脱PPAPを目的とした専用製品を販売していません。そのため本記事では、後半で「多くの場合、追加のツールを買う必要はない」という結論も含めて書いています。また、比較表に挙げる6分類のうち「顧客共有ワークスペース」は当社が属する分類です。他の5分類と同じ判定基準を当て、当社分類に不利な評価も併記しています。本記事が数値・引用の根拠として用いた資料は、2026年9月1日に原典を開いて確認し、URLを併記しました。

PPAPとは何を指す言葉か

PPAPは、パスワード付きzipファイルとそのパスワードを別々のメールで送る運用を指す通称です。正式な規格名や公的な用語ではなく、後から付けられた呼び名である点がまず重要です。この運用で送られるメールを、実務では慣用的にPPAPメールと呼びます。

何の略なのか

週刊BCNの2021年8月24日の記事によれば、PPAPは「『Password付きzipファイルを送ります』『Passwordを送ります』『An号化（暗号化）』『Protocol』の先頭の文字を取った言葉」とされています（2026年9月1日確認）。3つ目の「An号化」が示すとおり、英語の頭字語として整っているわけではなく、語呂合わせの色が濃い命名です。

この命名の来歴を知っておくと、実務上ひとつ得があります。社内規程や取引先との合意文書に「PPAP」という語だけを書くと、何を禁止・許可しているのかが曖昧になります。規程に落とすときは「暗号化した添付ファイルと、その復号パスワードを、いずれも電子メールで送信する行為」のように、動作で書いたほうが確実です。

誰が名付けたのか

同じ週刊BCNの記事は、命名者について「日本情報経済社会推進協会（JIPDEC）に所属していた大泰司章氏（現・PPAP総研代表社員）が、当時流行していたフレーズ『PPAP』にちなんで命名した」と記しています。

なお、命名された時期については、二次的な記事のあいだで年の記載に食い違いがあります。本記事では確認できた範囲にとどめ、時期は特定しません。

楽曲・自動車用語との違い

検索で「PPAP」とだけ入れると、楽曲の情報が多く混ざります。また製造業、とくに自動車の部品サプライヤーの現場では、PPAPは生産部品承認プロセス（Production Part Approval Process）を指し、量産開始前に部品の品質を承認する手続きの名前です。文脈がまったく異なるため、社内で用語を使うときは初出で補足しておくと混乱を避けられます。

PPAPメールの何が問題なのか

問題は大きく4つに分かれます。よく「セキュリティ上よくない」と一言でまとめられますが、それぞれ効いている相手も、代替手段で解決できるかどうかも違います。分けて理解しておくと、後の手段選びが楽になります。

暗号化されていると、ウイルス検査をすり抜ける

これが実務上もっとも直接的な害です。メールの経路上や受信側のサーバーに置かれたセキュリティ製品は、添付ファイルの中身を開いて危険なものが入っていないかを調べます。ところがパスワードで暗号化されていると、中身を開けないため検査ができません。

独立行政法人 情報処理推進機構（IPA）は、2020年9月2日に公開した「相談急増／パスワード付きZIPファイルを使った攻撃の例」で、次のように注意を促しています。

（前略）添付ファイルが暗号化されていることから、メール配送経路上でのセキュリティ製品の検知・検疫をすり抜け、受信者の手元に攻撃メールが届いてしまう確率が高く、より注意が必要です

— IPA「相談急増／パスワード付きZIPファイルを使った攻撃の例」2020年9月2日公開・最終更新2023年6月29日（2026年9月1日確認）

同じページによれば、IPAへのEmotet関連の相談は2020年7月から8月の2か月で34件でした。これに対し、感染したという相談とアカウントを乗っ取られたという相談が、9月1日から2日の午前中だけで23件に急増しています。そしてその渦中の9月2日、IPAは「パスワード付きのZIPファイルを添付したEmotetの攻撃メール」を確認したと報告しています。件数の急増そのものをパスワード付きzipに帰する記述は同ページにありませんが、IPAがこの手口を確認した時期が、相談の跳ね上がった時期と重なっていたことは読み取れます。

守るために暗号化しているつもりが、攻撃側にとっての通り道になっている。この逆転が、PPAPが問題視される最大の理由です。

同じ経路でパスワードを送れば、盗み見に対して効かない

2つ目は理屈の問題です。メールが盗み見られる状況を想定して暗号化しているのに、その鍵を同じメールで送れば、盗み見た相手は両方を手にします。

総務省の「テレワークセキュリティガイドライン 第5版」は、この点を次のように書いています。

しかしながら、この方式では（暗号化ファイルとパスワードを別メールで送信したとしても）、メールに添付された暗号化ファイルを通信経路上で窃取可能な攻撃者は、パスワードを記載したメールも窃取可能であると推測されることから、通信経路上での情報窃取に対するセキュリティ対策としての効果が疑問視されています。

— 総務省「テレワークセキュリティガイドライン 第5版」令和3年5月、80ページ【コラム】ファイルの暗号化（PPAP方式）（2026年9月1日確認。総務省の案内に従い、PDF直リンクではなく本文書を掲載しているページを示しています。第5版のPDFは同ページから辿れます）

「別のメールで送っているのだから経路は別だ」という反論を、この文章は先回りして否定しています。宛先も経路も同じであれば、通数を分けても攻撃者から見た難易度はほとんど変わりません。

誤送信への備えにもならない

3つ目は運用の問題です。PPAPを誤送信対策として説明する資料は今も見かけますが、実際には多くの環境で1通目と2通目の宛先は同じです。宛先を間違えたとき、2通とも同じ相手に届きます。

パスワードを手動で入力し直す運用なら、2通目を送る前に気づける可能性は残ります。ただしこれは「気づけることがある」という程度で、仕組みとしての歯止めではありません。自動でパスワードを別送するツールを使っている場合は、この一拍すら存在しません。

zipの暗号化は1種類ではない

見落とされがちですが、zipの暗号化には系統が2つあります。

従来方式に対する既知平文攻撃は、Biham と Kocher が1994年のFast Software Encryptionワークショップで発表した論文（論文集の刊行は1995年）で示された古典的な手法です。本記事はこの点について特定の実装や製品の既定設定を検証していないため、「どのツールがどちらを使うか」には踏み込みません。

つまり「パスワード付きzip」と一括りに語られていても、実際の強度は使ったツールと設定によって違います。送る側も受け取る側も、どちらの方式で暗号化されたかを意識していないことが多いのが実情です。

ここで重要なのは、AES-256を使えば安心という話にはならないことです。暗号方式を強くしても、ここまでに挙げた3つの問題は1つも解決しません。ウイルス検査はやはり通せませんし、パスワードを同じメールで送るのなら盗み見への効果は変わらず、誤送信の宛先も同じままです。暗号強度の話と、PPAPが抱える構造の話は別のレイヤーにあります。

「政府が禁止した」は正確か

PPAPを扱う記事の多くが「2020年に政府が禁止した」と書いています。ここは事実関係を正確に押さえておく価値があります。取引先に方針変更を説明するとき、根拠を誤って伝えると信頼を損なうためです。

廃止したのは内閣府と内閣官房

出発点は、2020年11月24日の記者会見です。当時デジタル改革を担当していた平井卓也内閣府特命担当大臣は、次のように述べています。

（前略）自動暗号化ZIPファイルの廃止については、先週17日の会見で、内閣府、内閣官房で廃止する方向で検討を進めているとお話ししましたが、明後日26日に廃止をする予定ということになりました

（中略）内閣府、内閣官房で採用していたZIPファイル送付と同じ経路でパスワードを自動で送る方式は、セキュリティ対策の観点からも、受け取る側の利便性の観点からも、適切なものではないと考えています

— 内閣府「平井内閣府特命担当大臣記者会見要旨」令和2年11月24日（2026年9月1日確認）

読み落としてはいけないのが「内閣府、内閣官房で採用していた」という限定です。廃止されたのは、この2つの組織が自ら使っていた運用でした。他省庁については、同じ会見で次のように述べるにとどまっています。

他省庁の状況についても、ＮＩＳＣと連携しながら実態調査を進めており、その結果を踏まえて、ZIPファイル送信、送付と同じ経路でパスワードを自動で送る方式については廃止するということを促したいと思っています。

— 同上

促したい、であって、命じるではありません。

したがって、政府全体への一律の禁止でもなければ、民間企業への禁止でもありません。「法律で禁止された」という説明は誤りです。

「デジタル庁が廃止した」は時系列が合わない

もうひとつよく見かけるのが、デジタル庁が廃止を決めた、あるいは全省庁に指示した、という説明です。これは時系列として成立しません。

デジタル庁設置法（令和3年法律第36号）の施行期日は令和3年、すなわち2021年9月1日です（e-Gov法令検索、2026年9月1日確認）。2020年11月の廃止表明の時点で、デジタル庁はまだ存在していませんでした。引用した会見要旨のタイトルが「平井内閣府特命担当大臣記者会見要旨」であることも、当時の肩書きがデジタル庁の長ではなかったことを示しています。

細かい話に見えるかもしれませんが、社内の稟議書や取引先への案内に「デジタル庁が禁止したため」と書いてしまうと、相手の情報システム部門が確認したときに根拠が崩れます。根拠として引くなら、次に述べる総務省のガイドラインのほうが実務的です。

総務省ガイドラインは「禁止」ではなく「効果が疑問視されている」

政府文書のうち、民間企業がそのまま参照しやすいのは総務省の「テレワークセキュリティガイドライン 第5版」（令和3年5月）です。80ページに【コラム】ファイルの暗号化（PPAP方式）という項目が置かれています。2026年9月時点で第6版は公表されておらず、これが最新版です。

このコラムの書きぶりは「禁止」ではありません。効果が疑問視されている、セキュリティ対策上デメリットが生じる点に留意が必要である、という表現です。そのうえで、次のように結んでいます。

ファイルを安全に送付するには、パスワードをあらかじめ取り決めた上で暗号化する方法のほか、クラウドストレージ等のファイル共有サービス（当該サービスへのアクセスに当たって認証を行うものや別経路でパスワード送付を行うもの）を活用する方法等が考えられます。求められる機密性やリスク等を考慮の上、適切な手法を利用することが必要です。

— 総務省「テレワークセキュリティガイドライン 第5版」令和3年5月、80ページ

ここも読み方に注意が要ります。原文は「方法等が考えられます」と結ぶ例示であって、網羅的な列挙ではありません。しかもクラウドストレージのほうには括弧で条件が付いています。この構造の意味は「脱PPAPしたつもりのPPAP」の章で扱います。

まとめると、禁止されてはいない。しかし、やめる理由は禁止とは別に立っています。効果が乏しく、検査を妨げ、相手に手間をかけ、そして後述するとおり（「送っても届かないことがある」）相手が受け取れないことすらある。それで十分です。

いま実際どれくらい使われているのか（2026年の実測）

「もうほとんど使われていない」のか「まだ半分くらい残っている」のかで、取るべき対応は変わります。送信側と受信側、両方から実測値を見てみます。

送る側の利用率は6.2%まで下がった

HENNGEは2026年6月30日に、自社サービスの利用状況からPPAPの利用率を集計した結果を公表しています。

— HENNGE「PPAP廃止が加速、利用比率は2年で約6％に半減：HENNGE Oneユーザー調査（後略）」2026年6月30日発表（2026年9月1日確認）

この数字を読むときは、母集団の性質を押さえておく必要があります。同社の発表によれば、集計対象は「HENNGE Oneユーザーが送ったファイル添付のあるメール」であり、「暗号化ファイルが添付されていたメール」をPPAPとしてカウントし、インフラを流通するメールからサンプル抽出したデータを基にした推計とされています。

同社は「営業日数等の条件を揃えるため、第1日曜日〜土曜日を抽出期間としています」としており、各時点とも1週間分（2021年10月3日〜9日／2024年7月7日〜13日／2026年6月7日〜13日）の抽出です。またこの定義では、本記事が後半で代替として挙げる「鍵を事前に取り決めた暗号化添付」もPPAPとして計上されます。そしてこれは、メールセキュリティサービスを導入している企業に限った数字です。そうしたサービスを導入している時点で、情報システムへの投資に積極的な組織に寄っています。日本企業全体の平均としては読めません。それでも、5年弱で4分の1以下という減り方は、方向性を示す材料になります。

受け取る側には、まだ届いている

一方、受信側から見た調査もあります。デジタルアーツが2025年1月29日に公開したセキュリティレポートは、「国内の約2,000組織を対象とし、『受信メールに何らかのファイルが添付されたもの』に限定し抽出した300万通以上の受信メール」を分析したものです。

このレポートによれば、添付ファイル付きの受信メールに占めるzipファイルの割合は、2020年2月調査の25%から2024年12月調査の12%へと半減しています。分母は受信メール全体ではなく、あくまで何らかの添付があるメールです。なおこちらも、同社が自社製品の判定機能で観測できた国内約2,000組織のデータであり、日本の全組織の平均ではありません。ただし同時に、「調査対象の2週間で6,000以上のドメインがパスワード付きZIPを利用」していたことも報告されています。観測できる組織を増やせばドメイン数は増えこそすれ減らないため、6,000は下限として読めます。

— デジタルアーツ「【セキュリティレポート】国内組織の受信メール添付ファイルを分析　ZIPファイル割合は5年前と比較し半減するも、調査対象の2週間で6,000以上のドメインがパスワード付きZIPを利用」2025年1月29日公開（2026年9月1日確認）

2つの調査は、それぞれ別の側面を映しています。送る側は確かに減った。しかし受け取る側から見ると、2週間で6,000のドメインという規模で、まだ届いてくる。

ここから導かれる実務上の結論は明快です。自社が送るのをやめることと、自社に届かなくなることは別の問題であり、後者は自社の努力だけでは終わりません。この非対称性への対処は本記事の後半で扱います。

「PPAPは意味ない」のか

検索では「PPAP 意味ない」という調べ方も一定数あります。強い言い方ですが、正確には「無意味」ではなく「想定していた脅威に効いていない」と言うべきです。PPAPメールが何に効かないのかと、わずかに残る効用を分けておきます。

効かないものは、前章で挙げた3つがそのまま当てはまります。通信経路上の盗み見、マルウェアの混入、宛先間違いによる流出。いずれにも効きません。

わずかに残るもの。ひとつは、誤送信に気づいてから相手が開くまでの時間差です。パスワードを送る前に間違いに気づけば、添付は開かれないまま終わる可能性があります。もうひとつは、パスワードを手で作って送るという一手間が、送信前の確認をもう一度だけ促す効果です。

ただし、どちらも仕組みではなく偶然に依存しています。前者は2通目を自動送信するツールを使っていれば消えますし、後者は担当者の集中力次第です。設計として数えられるものではありません。

そしてもうひとつ、しばしば見落とされる副作用があります。PPAPは受け取る側に負担を強います。スマートフォンでは解凍できないことがあり、日本語ファイル名が文字化けすることがあり、2通のメールを探して突き合わせる手間がかかります。送る側の安心感のために、受け取る側の時間を使っている構図です。冒頭に引いた大臣の発言が、セキュリティだけでなく「受け取る側の利便性の観点からも」適切でないと述べていたのは、この点を指しています。

脱PPAPしたつもりのPPAP

ここは移行後に見落とされやすい落とし穴です。そして、本記事が競合調査で読んだ6件（ベンダー解説記事3件・百科事典1件・製品LP1件・用語辞典1件）では、この論点はいずれも扱われていませんでした。

先ほど引用した総務省ガイドラインのコラムには、続きがあります。

なお、これは暗号化ファイルを使わず、ファイル共有サービスを使い、そのURLとパスワードを同じ通信経路（メール）で送る場合についても同様です。

— 総務省「テレワークセキュリティガイドライン 第5版」令和3年5月、80ページ

読み飛ばされがちな一文ですが、移行の可否を分ける核心です。zipをやめてクラウドストレージに変えても、共有URLとその閲覧パスワードを同じメールに並べて書いているなら、政府文書の判断では同じ問題が残っています。手段を変えただけで、構造は変えていない状態です。

よくある3つの失敗

移行後に残りやすい形を挙げます。

1つ目は、URLとパスワードの同送です。「共有リンクはこちらです／パスワードは1234です」と1通のメールに並べて書く。これは総務省の文言がそのまま当てはまります。zip時代よりむしろ後退している場合すらあります。少なくともPPAPは2通に分けていました。

2つ目は、全社共通の固定パスワードです。 運用を楽にするために共有パスワードを決めて使い回すと、いったん外部に漏れた時点で、そのパスワードで守られているすべてのファイルが開きます。誰に渡したかの記録も残りません。

3つ目は、リンクを知っている全員が閲覧できる設定です。 相手のアカウントを確認せずに済むので楽ですが、URLが転送されればそのまま第三者に届きます。この設定に起因する事故の具体的なパターンは、Google Driveで顧客に共有するときのリスクで個別に整理しています。

政府文書が挙げている方法

先に引用した総務省の結びを、もう一度構造で見ておきます。原文は「〜を活用する方法等が考えられます」と結んでおり、網羅的な列挙ではなく例示です。そのうえで、具体的に名前が挙がっているのは次の2つです。以下では便宜上、方法A・方法Bと呼びます。

方法A：パスワードをあらかじめ取り決めた上で暗号化する方法。 鍵を事前に共有しておき、以後はメールで鍵を送らない形です。原文ではこちらが先に挙げられています。

競合調査で読んだ6件のうち、方法Aに触れていたのは1件だけでした。そこでは見出しが「パスワードのみを別の方法で送付する」となっており、原文が言う「あらかじめ取り決める」形、すなわち以後メールで鍵を送らずに済ませる運用としては扱われていません。

運用上の制約は2つあります。ひとつは、鍵を使い回す形になるため、案件ごとに鍵を分ける必要があること。前節で挙げた「全社共通の固定パスワード」との違いはここにあります。もうひとつは、担当者が交代したときに鍵を変えても、交代前に渡したファイルは旧鍵で開けるままだということ。鍵の変更が守れるのは以後に渡す分だけで、配布済みのファイルは取り戻せません。

この方法をどういう場面で選ぶかは、「相手都合で詰まったときの実務」で扱います。

方法B：クラウドストレージ等のファイル共有サービスを活用する方法。 ただしこちらには括弧書きで限定が付いています。「当該サービスへのアクセスに当たって認証を行うものや別経路でパスワード送付を行うもの」。つまり、URLを知っているだけでは開けず相手が誰であるかを確認する仕組みがあるか、鍵をメール以外の手段で渡すか、どちらかを備えたサービスを指しています。

なお、方法Aは本記事の比較表にある「パスワード付きzip＋鍵は別経路」と実務上ほぼ同じ形になります。ただし総務省原文では、方法Aは「あらかじめ取り決める」ことを、方法Bの括弧内の「別経路でパスワード送付」は共有サービスの条件を指しており、両者を並べるのは本記事の整理です。この形については、廃止を表明した当の記者会見で、平井大臣自身が次のように述べています。

一方で、個人情報等の気密性の高い情報を含むファイルを送信する際には、例えばファイルにパスワードをかけるとともに、全く別の経路でパスワードを知らせるということが、まずは適切な対応ではなかったのかと思います。（「気密性」は原文ママ）

— 内閣府「平井内閣府特命担当大臣記者会見要旨」令和2年11月24日

廃止されたのは「同じ経路でパスワードを自動で送る方式」であって、暗号化そのものでも、パスワードを使うこと自体でもありません。この区別は、社内で方針を説明するときに効いてきます。

この括弧は、あくまで方法Bがどういうサービスであるべきかの限定であって、送付手段全般の合否を決める基準として書かれているわけではありません。ただし読み替えれば実務の物差しにはなります。本記事では以後、「相手が誰かを確認してから開かせる」か「鍵をメール以外で渡す」かのどちらかを満たしているかを、移行が前進したかどうかの判断に使います。 これは本記事の整理であって、総務省がその形で示した基準ではない点を断っておきます。

どちらも満たさないまま道具だけ変えたなら、移行はまだ完了していません。

代替手段6つを11軸で比較

ここからが本題です。代替手段を並べた比較表は他にもあります。本記事が競合調査で読んだ6件（ベンダー解説記事3件・百科事典1件・製品LP1件・用語辞典1件）のうち比較表を持っていたのは2件で、片方は「1回のファイルを安全に届けられるか」の5項目、もう片方は導入形態・導入負荷・機能・用途という製品選定の軸でした。いずれも必要な観点ですが、十分ではありません。

なぜ「安全に届いたか」だけでは足りないのか

ファイル転送サービスは、渡し切ることを前提に作られています。ダウンロード期限が来たらリンクは消え、それで役目は終わりです。単発の送付であれば、それで何の問題もありません。

しかし、受託・制作・コンサルのように顧客と数か月にわたって案件を進める場合、資料は1回で終わりません。要件定義書は版を重ね、デザイン案は差し替わり、議事録は毎週増え、途中で先方の担当者が交代し、自社側でもメンバーが入れ替わります。そして案件が終わったあと、検収や監査のために「いつ、誰が、何を確認したか」を出せるかが問われます。

このとき効いてくる評価軸は、送信時点では存在しません。渡した後に発生するからです。だから、渡し切りを前提とした製品の比較表には載らない。載らないから、選定時に見落とされる。これが構造的な理由です。

そこで本記事では、評価軸を単発の5軸と継続の6軸に分けます。

単発の5軸

1回のファイル送信を安全に完了できるかを見る軸です。

• ウイルス検査を妨げないか — 経路上のセキュリティ製品が中身を検査できるか
• 誤送信に歯止めがあるか — 宛先を間違えたときに、開かれる前に止められるか
• アクセス手段の強度は十分か — パスワード・暗号方式・アカウント認証のいずれかで、権限のない相手の到達を防げるか
• 盗み見に対して有効か — 経路上で内容とアクセス手段の両方を取られない設計か
• 相手が問題なく開けるか — 相手の端末・受信環境で実際に受け取れるか

継続の6軸

案件が続くあいだ共有し続ける場合に、後から効いてくる軸です。

• 差し替え — 新しい版を出したとき、相手の手元の古い版はどうなるか
• 参加者の入退 — 先方の担当交代や自社の退任者のアクセスを、あとから整理できるか
• 権限の粒度 — 案件ごと、ファイルごとに閉じられるか。社内用と顧客用を見せ分けられるか
• 閲覧証跡 — 誰がいつ何を見たかが記録され、必要なときに出せるか
• 期限切れの扱い — 有効期限が切れたあと、再依頼のやり取りが発生しないか
• 保管の一元性 — 案件の資料が1か所にまとまり、あとから探せるか

比較する6つの手段と、判定のルール

比較するのは次の6分類です。5つ目までは一般的な呼び方ですが、6つ目は聞き慣れないかもしれないので定義しておきます。顧客共有ワークスペースとは、案件ごとに顧客を招待し、資料・やり取り・記録を1か所にまとめて置く形式のツールを指します。 Google Workspace のような汎用のグループウェアとは別の分類です。そして、この分類には当社のTerasuが含まれます。以下の判定は、当社に不利な評価も含めて他の5分類と同じ基準で付けています。

判定の記号は次の意味で使います。判定語を先に固定し、6分類すべてに同じ問いを当てました。

• ○ — 分類として標準的に備わっている
• △ — 次のいずれか、または複数。どれであるかは各セルの短い注記が示す。①設定・製品・相手の環境によって可否が分かれる、②できるが粒度が粗い、または運用でカバーが必要、③抑止する仕組みはあるが完全ではない
• × — 分類として原理的に持たない
• — — その軸の概念自体が存在しない（良し悪しの評価ではない）

表の見方について、3点補足します。

ひとつは、ファイル転送サービス・クラウドストレージ・ビジネスチャット・顧客共有ワークスペースの4分類は、いずれも製品による幅が大きいことです。とくに閲覧証跡は、ページ単位で記録できる製品もあれば、まったく持たない製品もあります。当社が属する分類も例外ではありません。アクセス手段の強度と盗み見への有効性が△なのは、招待制を基本としつつリンク共有機能も持つ製品があり、その設定次第で結果が変わるためです。権限の粒度と閲覧証跡が△なのは、機能そのものの実装に製品差があるためです。分類として選ぶだけでは決まらず、製品を個別に確かめる必要があります。

ふたつめは、上の3行と下の3行では比べている土俵が違うことです。PPAP・鍵別経路・ファイル転送サービスはいずれも渡し切りを前提とした手段なので、継続の6軸を当てれば不利に出ます。それは設計思想の違いであって欠陥ではありません。ただし、渡し切り前提であることと、単発の5軸を満たすことは別です。この3行のうち単発の5軸で×が残らないのはファイル転送サービスだけで、上の2行は、他に選べる手段があるかぎり本記事は推奨しません。ただし後述するとおり、相手の環境で外部URLがどうしても開けない場合にかぎり、2行目（鍵は別経路）が残る選択肢になります（相手が金融機関の場合を除く）。

みっつめは、「相手が開けるか」で当社が属する分類も△であることです。顧客共有ワークスペースも外部のURLにアクセスしてもらう形式なので、相手の社内規程で外部クラウドが遮断されていれば開けません。この点はクラウドストレージやファイル転送サービスとまったく同じ制約を負います。

なお、資料を顧客に届ける手段そのものを、案件の文脈から切り離して比較したい場合は、資料を顧客に届ける手段の比較を参照してください。本記事は、PPAPをやめるという意思決定に絞って整理しています。

どれを選ぶか：3つの問いで絞る

上から順に答えていくと、手段がひとつに絞れます。

問い1：そのファイルを渡す相手とのやり取りは、1回で終わるか。

• はい（1回で終わる） → 継続の6軸は無視してよい。ファイル転送サービスか、既存のクラウドストレージの共有リンクを選ぶ。どちらも新しい契約は不要な場合が多い。ただし後者は、組織の管理者が社外共有を有効にしていることが前提になる。なお本記事の物差し（相手が誰かを確認してから開かせる／鍵をメール以外で渡す）は、この場合も満たすこと。共有URLと閲覧パスワードを1通のメールに並べて書いたなら、手段を変えただけで前進していない
• いいえ（案件として続く） → 問い2へ

問い2：相手が外部のクラウドURLを開ける環境にいるか。

• いいえ（社内規程で遮断されている） → まず遮断の範囲を相手に確認し、許可申請の窓口があれば試す（手順は「相手都合で詰まったときの実務」を参照）。相手が金融機関なら、まずメールの通信経路の暗号化（TLS）が使えるかを確認する。金融庁が「基本」と位置づけているのはこれで、パスワード付きファイルへの切り替えは提案しない。TLSも、相手が許可するストレージも使えないなら、本記事が推奨できる手段はない。先方の情報システム部門と方式を合意するまで、機微な資料を送らないこと。相手が金融機関以外で、かつ他に手段がない場合にかぎり前掲の方法A（パスワードをあらかじめ取り決めて暗号化する）に落ちる。ただし方法Aは、継続6軸のうち評価対象となる5軸すべてで×のため、案件が続くあいだの共有には向かない。やり取りの記録は別途、議事録などで残す前提で使う
• はい → 問い3へ

問い3：あとから「誰がいつ確認したか」を示す必要があるか。

• いいえ（相手が固定で、記録は不要） → 相手も同じ基盤を使っているならビジネスチャットが最も摩擦が少ない。そうでなければクラウドストレージ
• はい（検収・監査・社内決裁で問われる） → 閲覧証跡を持つ手段に限られる。クラウドストレージまたは顧客共有ワークスペースのうち、証跡機能を実際に備えた製品を個別に確認して選ぶ

問い3で「はい」になる典型は、検収時に提出を求められる案件、先方の社内で決裁が回る資料、NDAの対象になっている資料です。

単発の送付で済むなら、ツールは足さなくていい

先に結論を書きます。月に数回、単発で資料を送るだけなら、新しいツールを買う必要はほとんどありません。Microsoft 365 や Google Workspace をすでに契約しているなら、必要な機能の多くは契約済みの範囲に含まれています（ただし後述のとおり、社外共有が管理者設定で有効になっている必要があります）。

これは当社にとって都合のいい話ではありませんが、書いておきます。PPAP対策を名目にした導入を検討する前に、まず既存環境の設定で足りるかを確かめてください。

追加費用なしで今日できること

Microsoft 365 または Google Workspace を使っているなら、次の3つは今日から実行できます。

1. 共有リンクを、相手を指定して発行する。 どちらのサービスにも、リンクを知っている全員に開放する設定と、指定した相手だけに許可する設定があります。後者を既定にすれば、前掲の方法Bの限定にある「アクセスに当たって認証を行うもの」に当てはまります。運用としては、この既定を組織のポリシーで固定してしまうのが確実です。なお、この設定にすると受信者側でアカウントのサインインが必要になるため、相手に一言添えておくと問い合わせを減らせます。

ただし、その前提として、そもそも社外への共有ができるかどうかは組織の管理者が外部共有を有効にしているかに依存します（Microsoft の外部共有設定／Google の外部共有設定、いずれも2026年9月1日確認）。管理者がオフにしていればプランに関係なく使えません。この点は後述の自動zip暗号化と同じく、所管部署の確認が先になります。

2. パスワードが必要な場面では、鍵をメール以外で渡す。 電話、SMS、相手が使っているチャット。経路が分かれていれば、それだけで条件のもう一方を満たします。特別な製品は要りません。

3. 添付そのものを減らす。 添付は経路上に実体を残しますが、リンクなら後から権限を切れます。この差は、送ってしまった後に効いてきます。

これで、単発送付における主要な問題はおおむね解消します。すでに契約している環境の設定を変えるだけなので、追加の費用は発生しません。ただし「設定を変える」権限が現場にあるとは限らない点は、繰り返しになりますが押さえておいてください。

Outlookで自動的にzip暗号化される場合

Outlookをはじめとする社内のメール環境に、添付ファイルを自動でパスワード付きzipに変換し、パスワードを自動で別送するアドインや設定が入っていることがあります。この場合、担当者個人がいくら気をつけても、送信の瞬間に自動でPPAPメールが再生産されます。

この状態で最初にやるべきは、担当者への注意喚起ではなく、その自動化を止めることです。個人の運用改善では変えられない層に原因があるためです。Outlookのアドインとして入っている場合も、メールゲートウェイ側で変換している場合も、止める対象は同じく「自動で暗号化してパスワードを別送する処理」です。止めた結果として添付が平文で出ていくことが問題になるなら、前節の共有リンクへの切り替えとセットで進めます。

自動化を止める判断には、多くの場合、情報システム部門か、その設定を導入した時期の決裁者の合意が要ります。ここを飛ばして現場だけで動くと、設定が戻されて終わります。

それでも足りなくなる境界

一方で、次のような条件が重なってくると、既存環境の設定だけでは苦しくなります。

• 同じ相手と、数か月にわたって資料をやり取りし続ける
• 資料の版が増え、どれが最新かを相手に説明する手間が発生している
• 先方の担当者が交代し、誰がアクセスできる状態なのかを把握できていない
• 社内向けの資料と顧客向けの資料が同じフォルダに混在し、見せ分けに神経を使っている
• 「確認しました」を口頭で受けており、記録として残っていない

このいずれかが恒常的に起きているなら、それはもうPPAPの問題ではなく、共有の仕組みの問題です。次章で扱います。

案件単位で顧客と共有し続けるなら、要件が変わる

単発の送付と、案件が続くあいだの共有は、必要な要件が違います。前者は「安全に届くこと」が目的ですが、後者は「安全に見え続けること」が目的だからです。ここで想定しているのは、顧客と案件単位で進める働き方（クライアントワーク）です。この違いを、権限・証跡・誤送信の3点で具体化します。

権限：案件ごとに閉じ、社内用と顧客用を分ける

継続的な共有で最初に問題になるのは、権限の単位です。

フォルダ単位でしか権限を切れない環境では、顧客に見せたい資料と、社内でしか見せられない資料を、物理的に別のフォルダへ分けて管理することになります。作業としては可能ですが、案件が増えるほどフォルダの二重管理が膨らみます。そして厄介なのは、権限設定そのものを正しく行っていても、ファイルの置き場所を一度間違えれば同じ結果になることです。守りの強さが、日々の配置作業の正確さに依存してしまいます。

必要なのは、案件という単位で共有範囲が閉じていて、そのなかで顧客に見せる面と社内だけの面が分かれていることです。フォルダを分けて運用でカバーするのではなく、構造として分かれている状態を指します。

もうひとつが、人の入退です。案件が半年続けば、先方の担当者が交代することも、自社側のメンバーが抜けることもあります。共有リンクを都度発行する運用では、誰にどのリンクを渡したかの記録が残らないため、退任者のアクセスを止めきれません。招待と解除でメンバーを管理する仕組みなら、この棚卸しが一度で済みます。

ここで具体的に問うべきことは3つです。いま誰がこの案件の資料にアクセスできるかを、5分以内に一覧で出せるか。 出せないなら、退任者や交代した先方担当者のアクセスが残っている可能性を否定できません。アクセスを止めるのに、何か所を操作する必要があるか。 リンクごとに止める運用では、止め忘れが必ず出ます。社内用の資料が顧客に見えていないことを、設定画面ではなく顧客側の見え方で確認できるか。 権限設定が正しいことと、実際に見えていないことは別で、後者を直接確認できる手段があるかどうかが分かれ目になります。

この3つに答えられない状態で機微な資料を扱っているなら、PPAPをやめるかどうかより先に、そちらを整理したほうが効果が大きい場合があります。NDAを締結している資料を扱う場合の要件は、NDA対象の資料を共有するときの要件でさらに細かく整理しています。

閲覧証跡：「送った」ではなく「見られた」を残す

メールの送信履歴が証明しているのは、送ったことだけです。相手が開いたかどうか、どこまで読んだかは分かりません。

案件の進行中、これは単なる好奇心の問題ではありません。「先週お送りした要件定義書、ご確認いただけましたか」という確認のやり取りが毎週発生している状態は、記録がないことのコストです。そして案件の終盤、検収の段になって「その仕様は聞いていない」という食い違いが起きたとき、口頭の確認しか残っていなければ、話は水掛け論になります。

閲覧の記録が残っていれば、いつ誰がその資料を開いたかという事実を、双方が同じものとして参照できます。これは相手を追及するための道具ではなく、認識のずれを早く見つけるための道具です。「まだ見られていない」と分かれば、催促ではなく、相手の社内で何が起きているかを尋ねる会話に切り替えられます。

ただし、ここには先に断っておくべきことが2つあります。ひとつは、前掲の比較表で閲覧証跡を△とした理由がそのまま当てはまることです。記録の粒度は製品ごとにまったく違い、上位プランでしか使えないこともあります。選定時に個別の確認が要ります。

もうひとつは、閲覧を記録することを相手に伏せないほうがよいことです。案件の共有の場に招く時点で、閲覧状況が記録される旨を一言伝えておけば、後から気まずくなることはありません。記録できるからといって、相手に黙って行動を追う道具として使えば、信頼のほうを損ないます。仕組みそのものと、記録がどこまで取れるかの製品差については資料が読まれたかを記録するPDFトラッキングの仕組みで詳しく扱っています。

誤送信：運用ではなく設計で消す

誤送信対策として一般に語られるのは、送信前の確認、宛先のダブルチェック、送信保留の設定といった運用上の工夫です。どれも有効ですが、共通の弱点があります。毎回、人が宛先を選ぶという行為が残っている限り、間違える余地は消えません。

継続的な共有では、この前提そのものを変えられます。案件ごとの共有の場に相手を一度招待すれば、以後は資料をその場に置くだけで済み、送るたびに宛先を選ぶ行為が発生しません。宛先を間違えないようにするのではなく、宛先を選ぶ回数を減らす。これが構造的な排除の意味です。

もちろん、最初の招待を間違えれば同じことです。前掲の比較表で、顧客共有ワークスペースの「誤送信の歯止め」を○ではなく△にしているのはそのためです。ただし、事故が起きうる回数が違います。案件の期間中に繰り返し発生する送信操作と、案件開始時に1回だけ発生する招待操作では、間違える機会の数そのものが違う。そして招待は1回しかないぶん、そこだけを重点的に確認する運用が現実的に成り立ちます。毎回の送信すべてに同じ集中力を要求するのは、長い案件では続きません。

言い換えれば、これは誤送信をゼロにする話ではなく、注意を払うべき場面を、続けられる回数まで減らす話です。運用の工夫を否定しているのではありません。工夫が効く回数まで場面を絞る、というのがここでの設計の意味です。

顧客・社外メンバーを入れて案件を進める場合のツール選定は、顧客・社外メンバーと共有できるプロジェクト管理ツールの比較で12製品を実額で比較しています。提案資料に限った共有方法は提案資料をセキュアに共有する方法を参照してください。

相手都合で詰まったときの実務

ここまでは自社が送る側の話でした。しかし実務でいちばん手が止まるのは、相手都合の局面です。本記事が競合調査で読んだ6件のうち、この領域に触れていたのは1件だけで、それも「取引先に受け取ってもらえない」と指摘するにとどまり、ではどう頼むか、受け取った側は何をするかは書かれていませんでした。現場で判断の拠り所がありません。3つの局面に分けて整理します。

取引先がPPAPメールで送ってくる

自社が方針を決めても、取引先からは届きます。前述のとおり、受信側の調査では2週間で6,000以上のドメインからパスワード付きzipが届いていました。

判断は2段階で考えます。

まず、開封してよいかどうか。 ここで判断材料にしてはいけないのが「送信元が既知の相手かどうか」です。本記事が引用したIPAの注意喚起はEmotetを対象としたものです。JPCERT/CCは「一見すると業務に関係がありそうな内容で、取引先や知り合いから送付されているようにみえる添付ファイルであっても、Emotetの感染に繋がるメールや添付ファイルである可能性がある」と述べ、窃取された情報が「その後のEmotetの感染に繋がるなりすましメールで悪用されることがあります」としています（JPCERT/CC「マルウェアEmotetの感染再拡大に関する注意喚起」2022年2月10日公開・最終更新2023年3月20日、2026年9月1日確認）。

前掲のデジタルアーツのレポートによれば、Emotetは2023年3月末ごろを最後に活動を停止しています。ただし同レポートは、日本国内向けの大規模なばらまき型攻撃メールは見受けられないとしたうえで「圧縮ファイルを用いたばらまきメール型の攻撃は把握されています」とも述べており、手口そのものが消えたわけではありません。差出人が見慣れた相手であること、やり取りが続いていること、件名が実際の案件名であることは、いずれも安全の根拠になりません。

同じ注意喚起は「信頼できるものと判断できない限りは添付ファイルやリンクは開かず、確実な手段で送信元へ確認するといった対応を行うようご注意ください」としています。つまり使える判断材料は、メール以外の経路で送付の事実を確認できるかどうかです。電話でもチャットでも構いません。相手に「いま送りましたか」と一言確かめる。暗号化された添付は、経路上の検査を通らずに手元まで来ている状態そのものなので、この確認を省略できる条件は基本的にありません。

次に、組織として受け取らない方針にするかどうか。 受信をブロックする設定は技術的には可能ですが、取引が止まるリスクと引き換えです。現実的には、いきなり全面拒否にするのではなく、次の順で進めるほうが摩擦が少なくなります。

1. 受信は許容しつつ、開封前の確認手順を社内ルールとして決める
2. 主要な取引先に対して、次回以降の送付方法の変更を依頼する
3. 依頼が浸透した相手から順に、個別に受信の扱いを見直す

一足飛びに3から始めると、現場が「業務が回らない」と反発し、結局は例外運用が常態化します。

自社の脱PPAPを取引先に受け入れてもらう

依頼が通らない原因の多くは、伝え方にあります。「セキュリティ強化のため」だけでは、相手にとっては自社の都合であり、相手側にも設定変更や社内調整の手間が発生します。

通りやすい依頼には、次の要素が入っています。相手の情報システム部門に転送されても、そのまま判断材料になる形を意識します。

• 変更の対象が具体的である（何をやめて、何に変えるのか）
• 根拠が公的な文書である（政府文書を引く。ただし「禁止された」とは書かない）
• 相手の負担が明示されている（何をしてもらう必要があるのか、ないのか）
• 移行の期日と、それまでの扱いが書かれている
• 相手側の事情で難しい場合の代替案が用意されている

以下は、この5点を満たした依頼文の例です。

件名：資料の受け渡し方法変更のお願い（〇月〇日より）

株式会社〇〇
〇〇部 〇〇様

いつもお世話になっております。株式会社△△の□□です。

弊社では〇月〇日より、資料の受け渡し方法を変更いたします。
お手数をおかけしますが、ご確認をお願いいたします。

■ 変更内容
これまで：パスワード付きzipファイルをメールに添付し、パスワードを別メールで送付
これから：ご担当者様のメールアドレス宛に閲覧を許可した共有リンクをお送りします
　　　　　（パスワードが必要な資料の場合のみ、鍵は電話またはチャットで別途お伝えします）

■ 変更の背景
暗号化されたファイルはウイルス対策ソフトが中身を検査できないため、
安全性の確認ができないまま受信者に届く点が指摘されています。
総務省「テレワークセキュリティガイドライン 第5版」（令和3年5月、80ページ／
https://www.soumu.go.jp/main_sosiki/cybersecurity/telework/ ）でも、
本方式の効果に疑問が示されています。
法令等で禁止されているものではありませんが、弊社の方針として見直すものです。

■ 御社にお願いしたいこと
ソフトウェアの導入は不要です。
資料は、ご担当者様のメールアドレス宛に閲覧を許可した形でお送りします。
初回のみ、お使いのMicrosoft 365またはGoogleアカウントでのサインインを
お願いする場合があります。
アカウントをお持ちでない場合はお知らせください。別の方法をご用意します。

■ 変更日より前にお送りする分
従来の方法のままお送りします。切り替えは〇月〇日送付分からです。

■ 御社から弊社へお送りいただく場合
当面は従来の方法のままで差し支えありません。
将来的に受け渡し方法のご相談をさせていただく可能性がありますが、
その際はあらためてご連絡いたします。

■ ご事情により難しい場合
社内規程等で外部URLへのアクセスが制限されている場合は、
別の方法をご相談させていただきますので、お知らせください。

ご不明な点がございましたら、お気軽にお問い合わせください。
何卒よろしくお願いいたします。

ポイントは、相手から送る分については当面そのままで構わないと明示している点です。双方向の変更を同時に求めると、相手の社内調整の難度が上がり、話が止まります。まず自社から送る分だけを変える。その実績ができてから、必要に応じて相談する順序が現実的です。

メールの文面そのものの整え方や、添付とリンクの使い分けについては、資料送付メールの書き方と添付・リンクの使い分けにまとめています。

相手がクラウドのURLを遮断している

金融機関や公共分野の取引先では、社内規程で外部のクラウドサービスへのアクセスが制限されていることがあります。この場合、共有リンクを送っても相手は開けません。

ただし相手が金融機関の場合、暗号化した添付に切り替えるのは逆方向です。 金融庁は2025年5月13日の主要行等との意見交換会で提起した論点として、次のように述べています。

したがって、パスワード付きファイルの送付は基本的には行うべきではなく、電子メールの通信経路自体を暗号化することが基本である。通信経路を暗号化できない場合は、安全性の高いオンラインストレージを活用してファイルの安全性を確保する等、ほかの手段を用いていただきたい。

— 金融庁「業界団体との意見交換会において金融庁が提起した主な論点［2025年5月13日開催（主要行等との意見交換会）］」4項（2026年9月1日確認）

同じ論点は主要行だけに向けられたものではありません。2025年5月から7月にかけて公表された意見交換会の論点を通して確認したところ、10文書・11業態に同じ節が置かれていました（いずれも2026年9月1日確認）。

銀行・信用金庫・信用組合・労働金庫だけでなく、生損保・証券・信託・暗号資産交換業まで及んでいます。

ただし「金融機関ならすべて」ではありません。同じ意見交換会の枠組みに参加しながら、この論点を受け取っていない業態もあります。たとえば投資信託協会・日本投資顧問業協会・日本貸金業協会・金融先物取引業協会は、この節が置かれた2025年5〜7月のラウンドに開催回そのものがなく、その後の開催回でもこの節を含みません。また、上記11業態でも提起は各1回で、2025年8月から2026年前半の開催回では再提起されていません。取引先が上の表に載っている業態なら、この論点が共有されている前提で話を進めて構いません。

なお、本文の段落は業態間でほぼ同一ですが、末尾に差があります。信用組合・損保・生保・証券の4業態では、上に引用した段落の末尾に「経営陣においては、サイバーセキュリティに関する基本的な対策の一部として徹底していただきたい。」と名宛人が加わり、その後は「金融庁は、検査・モニタリング等を通じ、こうした慣行の払拭を促していく予定である。」で終わります。残る業態にはこの名宛人がなく、代わりに「金融庁としては、検査・モニタリング等を通じ、こうした慣行の払拭を促していく予定である。サイバーセキュリティに関する基本的な対策の一部として徹底する必要がある。」で終わります。業界の性質とは対応しないため、起案の版の違いと読むのが自然です。

例外がひとつあります。 暗号資産交換業向けの文書だけは、オンラインストレージを「通信経路を暗号化できない場合で、ほかに手段がない場合は」と一段絞ったうえで、他の9文書にはない次の一節を置いています。

こうした問題は、金融機関の規模の大小を問わず依然として見受けられるが、グローバルに見てこうした慣行が続けられていることは異例であり、我が国の金融業界のセキュリティ水準に疑義を生じさせているといった声が金融庁に寄せられている。

— 金融庁「業界団体との意見交換会において金融庁が提起した主な論点［2025年6月11日開催 日本暗号資産等取引業協会］」（3）（2026年9月1日確認）

海外の取引先とやり取りがある場合、この一節は社内を説得する材料になります。

いずれの版でも、金融庁が検査・モニタリングを通じて慣行の払拭を促す方針である点は共通しています。したがって金融機関が相手なら、順序は次のようになります。

1. メールの通信経路の暗号化（TLS）が使えるかを確認する。 金融庁が「基本」と位置づけているのはこれです。本記事の比較表はファイルの渡し方を軸にしているため通信経路の暗号化を分類として立てていませんが、相手が金融機関の場合はここが最初の選択肢になります
2. それが使えないなら、相手が許可しているオンラインストレージを尋ねる
3. パスワード付きファイルへの切り替えは、相手の側が避けようとしている手段なので提案しない

なお、これは意見交換会で提起された論点の公表であって、通達や監督指針の改正ではありません。それでも、相手の担当者が社内でこの方針を共有されている可能性は高く、こちらから提案する前に相手の意向を聞くほうが確実です。

以下は相手が金融機関以外の場合の手順です。まず、遮断されているのが特定のサービスなのか、外部URL全般なのかを相手に確認します。特定サービスだけであれば、相手が許可しているサービスに合わせるのが最短です。全般であれば、相手側に許可申請の窓口があるかを尋ねます。案件単位で一時的に許可が下りる場合があります。

加えて公共分野の取引先では、金融庁に相当する所管当局が同様の方針を示しているかどうかを本記事では確認できていません。金融機関と同じ扱いにはしませんが、上の確認に先立って、相手の情報システム部門に受け渡し方法の方針を尋ねておくと手戻りが減ります。

相手が金融機関以外で、上の手順をすべて試しても難しい場合に残るのが、前掲の方法A、すなわちパスワードをあらかじめ取り決めた上で暗号化する形です。案件の開始時に一度だけ、電話や対面で鍵を決めておけば、以後のメールで鍵を送る必要そのものがなくなります。ただし、鍵を変えても相手の手元に渡し済みのファイルと旧鍵は残るため、変更が効くのは以後に渡す分だけです。また案件ごとに鍵を分ければ、そのたびに電話や対面での鍵の受け渡しが発生します。手間と引き換えの選択である点は押さえておいてください。

ただし、この形でも検査を妨げる問題は残ります。さらに、次章で述べるとおり、暗号化された添付は相手側のゲートウェイで隔離される可能性があります。初回だけは、別の経路で相手に届いたかどうかを確かめてください。相手の事情で選択肢が限られている以上、実行可能な範囲での最善という位置づけです。

大切なのは、こうした例外を場当たりで運用しないことです。どの取引先に、どういう理由で、どの方法を使っているかを一覧にしておけば、相手の環境が変わったときに見直せます。

送っても届かないことがある — 受信側ブロックの実際

もうひとつ、送信側から見えにくい問題があります。暗号化された添付ファイルは、相手の受信環境で止められることがあります。そして、止められたことに送信側が気づけないことがあります。

Googleは「Gmail でブロックされるファイルの種類」というヘルプページで、添付できないファイルを列挙しています。そのなかに「アーカイブ コンテンツが格納された、パスワードで保護されているアーカイブ」という項目があります（Gmail ヘルプ、2026年9月1日確認）。

ここは正確に読む必要があります。Web上には「Gmailはパスワード付きzipをブロックする」という要約が広く流通していますが、公式ページに明記されているのは、パスワードで保護されたアーカイブの中にさらにアーカイブが入っている場合です。パスワード付きzip単体が常に弾かれると読み取れる記述にはなっていません。

では単体なら安全かというと、そうとも言えません。受信側の組織が、自社のメールゲートウェイで暗号化された添付を隔離する設定にしていることがあるからです。中身を検査できない添付を危険とみなす方針は、前述のIPAの指摘を踏まえれば合理的です。

問題は、この設定が送信側からは見えないことにあります。相手の組織がどういう方針で運用しているかは、送る前に確認できません。そして隔離された場合、送信者に通知が返らないことがあります。送ったつもりで届いておらず、相手からの返信がないのは検討中だからだと解釈したまま、時間だけが過ぎる。この非対称性が、実務上いちばん静かな損失です。

共有リンクであれば、アクセスログを持つ製品にかぎり、相手が開いたかどうかを確認できます（前掲の表で閲覧証跡を△とした理由です）。それでも、届いていないことに気づける手段があるかないかの差は、実務では小さくありません。

移行の進め方

ここまでを踏まえて、組織として進める場合の順序をまとめます。一度に全部を変えようとすると、どこかで止まります。

段階1：現状を把握する。 自社から出ている暗号化zipが、どの部署から、どのくらいの頻度で出ているかを確認します。個人の判断で送っているのか、メール環境の設定で自動化されているのかで、打ち手がまったく違います。自動化されている場合は、以降の段階より先にその設定の所管を特定します。

段階2：受信の方針を先に決める。 自社が送るのをやめても、届くほうは止まりません。開封前の確認手順、心当たりのない送信元の扱い、判断に迷ったときの相談先を先に決めておきます。ここを決めずに送信側だけ変えると、現場が受信で混乱します。

段階3：送信をやめる。 共有リンクの既定を「指定した相手のみ」に変更し、パスワードが必要な場面では鍵を別経路で渡す運用に切り替えます。前述のとおり、多くの場合これは既存環境の設定変更で足ります。新しいツールの検討は、この段階で足りないと分かってからで構いません。

段階4：取引先へ通知する。 主要な取引先から順に、前掲の依頼文の形で連絡します。全社一斉ではなく、やり取りの多い相手から個別に進めるほうが、例外への対応が現実的な量に収まります。

段階を飛ばしたときに起きることも書いておきます。段階1を飛ばすと、現場に注意喚起を出しても設定側で自動生成が続くため、いつまでも数字が下がりません。段階2を飛ばすと、送信は止まったのに受信の判断が現場任せになり、「開いていいのか」という問い合わせが情報システム部門に集中します。段階4を全社一斉でやると、外部URLを遮断している取引先からの問い合わせが同時に来て、例外対応が捌けなくなります。

チェックリストは段階ごとに分けています。

段階1：現状把握

• 暗号化zipの送信元（部署・自動化設定）を特定した
• 自動でzip暗号化する設定の所管部署を確認した

段階2：受信方針

• 受信したときの開封判断の手順を決めた（送信元の既知性ではなく、別経路での確認を基準にする）
• 判断に迷ったときの相談先を決めた

段階3：送信の切り替え

• 共有リンクの既定を「指定した相手のみ」に変更した
• パスワードを渡す別経路（電話・チャット等）を決めた
• 受信者にサインインが必要になる旨を案内する文面を用意した

段階4：取引先への通知

• 主要取引先への通知文を用意した
• 外部URLを遮断している取引先を洗い出し、代替手段を決めた
• 例外運用の一覧（相手・理由・方法）を作った
• 例外の見直し時期を決めた（相手の環境は変わるため、作りっぱなしにしない）

「PPAP対策」として何を買うべきか

最後に、この記事でいちばん誤解されやすい点を書いておきます。「PPAP対策」という名前の製品カテゴリを探しはじめると、メールゲートウェイ製品、ファイル転送製品、暗号化製品、それぞれのベンダーが自社の分類を答えとして提示してきます。どれも間違いではありませんが、そもそも買う必要があるかどうかは、ここまでの段階1〜3をやってみないと分かりません。

段階3まで進めて、既存のMicrosoft 365やGoogle Workspaceの設定変更で運用が回るなら、追加の投資は不要です。回らないとすれば、その理由はここまでに述べた3つのどれかに絞られているはずです。

• 送信の自動化を止める権限が現場にない（「Outlookで自動的にzip暗号化される場合」で述べた、設定の所管と決裁の問題）
• 例外運用が管理しきれない量になっている（「相手がクラウドのURLを遮断している」で述べた、一覧化と定期見直しの問題）
• 案件が継続し、版・権限・証跡の管理が必要になっている（「案件単位で顧客と共有し続けるなら、要件が変わる」で述べた要件）

製品で解けるのは3番目だけです。 1番目は決裁の問題、2番目は運用の問題なので、ツールを入れても原因が別のところにあるため解決しません。3番目に該当したときにかぎり、前掲の継続6軸の比較表が意思決定の材料になります。

よくある質問

まとめ

PPAPは法令で禁止されているわけではありません。2020年11月に廃止を決めたのは内閣府と内閣官房であり、その時点で他省庁へは要請にとどまり、民間への強制力もありませんでした。ただし業界によっては状況が動いています。金融庁は2025年5〜7月、業界団体との意見交換会で提起した論点として、パスワード付きファイルの送付は「基本的には行うべきではなく」と述べ、検査・モニタリングを通じた払拭を促す方針を示しました。それでもやめる理由は、禁止とは別のところに十分あります。ウイルス検査を妨げ、盗み見への効果は乏しく、誤送信の歯止めにもならず、相手に手間をかけ、ときに届きさえしない。

移行で気をつけるべきは、道具を替えただけで満足しないことです。総務省のガイドラインが明記しているとおり、クラウドストレージに変えてもURLとパスワードを同じメールで送るなら同じ問題が残ります。相手が誰かを確認してから開かせるか、鍵をメール以外で渡すか。本記事の物差しでは、このどちらかを満たして初めて移行は前に進みます。

そして、単発で渡すのか、案件が続くあいだ共有し続けるのかで、必要な要件は変わります。前者なら、多くの場合は既存環境の設定変更で足り、新しい費用は発生しません。後者であれば、権限をどの単位で閉じられるか、誰がいつ確認したかを残せるか、宛先を選ぶ回数そのものを減らせるかが問われます。自社がどちらの状況にいるのかを見極めることが、対策の出発点になります。