三菱UFJ銀行のPPAP廃止は、半歩前進で半歩後退

三菱UFJ銀行が2026年6月8日付で「当行からの添付ファイル送信方法の変更に関するご案内」を公表しました。 日本を代表するメガバンクがまだPPAPやっていたと衝撃を受けました。 内容を読んで考えさせられたので記録しておきます。

三菱UFJ銀行のアナウンス

要点はシンプルです。

同行は、お客さま側のセキュリティを確保するため、パスワード付き添付ファイルのメール送信を原則取り止めると発表しました。 2026年7月18日より順次、添付ファイルを送る際は専用のダウンロードサイトを利用する方式へ変更されます。

理由として挙げられているのは次の2点です。 これまでの「メールでパスワード付きZIPファイルを送り、パスワードを別送する方法」、いわゆる PPAP は、ファイルが暗号化されているためメール受信時のマルウェアチェックが困難であること。 そして近年、パスワード付きZIPファイルを悪用したサイバー攻撃の事例が確認されていることです。

新方式では、同行の役職員が添付ファイルを送る際、メール本文に専用ダウンロードサイトへアクセスするためのURLを記載します。 受け手はそのサイトにアクセスし、別送されるダウンロード専用のパスワードを使ってファイルを取得します。

PPAPの何が問題だったのか

PPAPの是非については、昨年「AWSからSMSにメッセージを送る」という記事で一度整理しました。

そのとき、機密文書をメールで送る手段を秘匿性と本人確認性の観点で並べて評価したのですが、結論は変わっていません。

PPAP、つまり暗号化ファイルとパスワードを同じ経路で送る方法は、1通盗まれればすべて漏洩します。 パスワードを別メールにしても、同じメールインフラを流れる以上、傍受や誤送信のリスクは本質的には下がりません。 加えて、暗号化されたZIPはメールゲートウェイでウイルススキャンできないため、マルウェアの運び屋になりやすい。 三菱UFJ銀行が今回理由として挙げているのは、まさにこの最後の点です。

ですから、PPAPをやめるという判断そのものは正しいと思います。 日本でも2020年に政府がPPAPの廃止方針を打ち出して以降の流れに沿っていますし、銀行という立場で旗を振る意味も小さくありません。

新方式は本当に安全になったのか

問題は、その置き換え先です。

新方式は「メール本文にダウンロードサイトのURLを記載し、パスワードは別送する」というものでした。 マルウェアスキャンの観点では確かに前進しています。 ファイルが暗号化ZIPとしてメールに乗らなくなるので、受信側のゲートウェイで中身を検査できるようになるからです。

しかし、フィッシング耐性という観点では、むしろ後退しかねません。

ひとつは、銀行が自ら「メール本文のURLをクリックさせる」習慣を送信先に植え付けてしまう点です。 銀行はこれまでフィッシング対策として、「当行からのメールにURLは記載しません」「メール内のリンクは開かないでください」と顧客には教育してきたはずです。 メールの送信先は顧客ではないと思いますが、今回はその逆を習慣づけることになります。 なりすましメールに偽のダウンロードURLが貼られていても、利用者は見分けがつかなくなります。

もうひとつは、「パスワードを別送する」という発想がPPAPのままという点です。 日ごろ支援しているコンサルテーション会社やITベンダーはちゃんと技術的に支援できなかったんでしょうか？

URLとパスワードを両方メールで送るのであれば、構造的にはPPAPの暗号化ZIPをWebサイトに置き換えただけです。 同じ経路を流れる以上、傍受や誤送信による漏洩リスクは解決していません。 マルウェアの問題は片付いても、秘匿性の問題は手つかずなのです。

整理すると、今回の変更は「マルウェアスキャン」という一点ではマシになる一方で、フィッシング耐性では弱点を抱え込む、惜しい設計だと感じます。

本来あるべき姿

以前の記事でも書きましたが、 現実的なのは認証付きのクラウドストレージで共有する方法でした。 受け手がログインして初めてファイルにアクセスできる仕組みなら、URLが単体で漏れても無効ですし、誰がいつアクセスしたかのログも残せます。 パスワードを別送する必要すらありません。

メールの送付先は取引業者だと思いますから、銀行が共通の認証を払い出すのは困難です。 たとえばBoxやDropboxのようなクラウドストレージであれば、受け手は無料のアカウントを気軽に作れます。 銀行側が取引先ごとにアカウントを発行・運用しなくても、受け手がログインして初めてファイルにアクセスできる仕組みを成り立たせられるわけです。 URLが単体で漏れても無効ですし、誰がいつアクセスしたかのログも残ります。

さらに言えば、この方式ならメールにリンクを書く必要すらありません。 ファイルを共有すれば、受け手にはクラウドストレージ側から「共有されました」という通知が届きます。 受け手は自分が信頼しているサービスにログインしてファイルを取りに行くだけです。 冒頭で挙げた、メール内URLをクリックさせる習慣づけという問題が、根本から消えてなくなるのです。

より根本的な解はないのか

もっとも、銀行ともあろうものがファイルの受け渡しを外部のクラウドサービスに丸ごと預けるのも、それはそれで引っかかります。 委託先管理やデータの所在、サービスへの従属といった問題が新たに生じるからです。 だとすれば、現実的な落としどころは、銀行が認証付きの受け渡しポータルを自前で持つことでしょう。 インターネットバンキングという認証基盤と運用ノウハウをすでに備え、取引先の本人確認も日常的に行っている組織です。 Boxがやっていることを内製すればよいだけです。技術力と体力の両面で、銀行はそれができる立場にあります。

では、もっと教科書的な根本解はないのか。 あります。受け手の証明書でメールそのものを暗号化・署名するS/MIME、いわゆるPKIです。 外部サービスやポータル、パスワードの別送といった仕組みが一切要らず、本人性と秘匿性をエンドツーエンドで担保できる、理屈のうえでは最も美しい解です。

ところがPKIは、米国ですら普及しませんでした。 証明書の発行や管理が高コストで手作業が多く、ユーザーごと・端末ごとに鍵を入れて回る運用負荷に耐えられなかったためです。 そして決定的なのは、送り手と受け手の双方が対応していないと成り立たないという両側依存です。 暗号化して送るには、相手があらかじめ証明書を用意していなければなりません。 相手が対応していなければ、文字どおり意味がない。 この鶏と卵の構造ゆえに、誰も最初の一歩を踏み出せませんでした。 受け手に「アカウントを作ってログインする」という自己完結した操作しか求めないポータル方式に世界が流れたのは、そのためです。

それでもリーダーシップを期待したかった

ここで私が惜しいと思うのは、まさにこの一点です。 PKIが普及しなかった最大の理由が「最初の一歩を誰も踏み出せなかった」ことなら、その一歩を踏み出せる体力と影響力を持つ組織こそ、日本を代表するメガバンクのはずです。

率先してS/MIMEを導入し、添付ファイルをやり取りするような主要な取引先には導入を促す。 場合によっては証明書発行の基盤を貸し出したり、運用を支援したりする。 そうやって両側依存の壁を、影響力のある側から崩していく。 そんなリーダーシップを見せてくれたら、日本全体のメール文化が一段前に進んだかもしれません。

現実的な着地は認証付きポータルでよいと思います。 ただ、PPAPをやめるという入口が正しかっただけに、出口がもう一歩踏み込めなかったのは惜しい。 日本をリードする銀行のやることだからこそ、ここにこそリーダーシップを期待したかった、というのが私の正直な感想です。

References