## はじめに 「PPAPはやめましょう」という声を、あちこちで聞くようになった。パスワード付きのZIPファイルをメールに添付し、そのパスワードを別のメールで送る——あの慣習のことである。いまや「時代遅れ」「悪しき形式主義」とまで言われている。だが、「PPAPをやめてクラウドストレージのリンクにしましょう」という定番の号令を、私はそのまま受け入れることができない。号令に従おうとすると、現場でこういうことが起きるからだ。 > 上司：「PPAPはやめます。これからはクラウドストレージのリンクで送ってください」 > 担当者：「わかりました。でも、送信先の相手から『うちはクラウドストレージへのアクセスを禁止しているので、その方法では受け取れない』と言われました。どうすればいいですか？」 この担当者に、私は何と答えればよいのか。ずっと考えてきた。その考えの、いまのところの到達点を書いておく。先に言っておくと、スマートな解決策では無いし、この問いに対する完璧な回答でも無い。 なお、この文章では「事実」（誰でも確かめられること）と、「私の解釈」「私の仮説」を、なるべく分けて書くようにする。混ぜて語ると、私の思い込みを事実のように押し付けてしまうからだ。 > **【筆者注記】利害関係の開示** > 筆者は本稿で取り上げた組織・企業・団体・プロジェクト等との業務上の関係、出資関係、競合関係はない。 > 本稿はいかなる外部主体からの委託・資金援助も受けておらず、独立した調査・分析に基づく。 > **本記事の作成プロセス** > 本記事は、運営者とAIの協働により作成しています。作成プロセスおよび品質管理の詳細は、[[サイトポリシー#1.2 AI の利用について]]をご参照ください。 --- ## 1. 「クラウドストレージのリンク」は、受け取る側にとって意味があるのか 脱PPAPの定番の代替策は、「ファイルはメールに添付せず、クラウドストレージに置いて、そのリンクをメールで送る」というものだ。だが、これを**受け取る側**の立場で考えてみたい。 送る側が、どれだけ安全なクラウドストレージを用意したとしよう。しかし受け取る側にとって、それは他人が用意した仕組みの一部でしかない。 （私の解釈）受け取る側には、そのリンクが「送信者が意図した正しいストレージ」なのか、それとも「攻撃者が偽装した罠」なのかを、クリックする前に見分ける手立てがない。メールの画面に映るのは、どちらも「ここをクリックしてください」という同じリンクである。だから受け取る側は、送信者がどれだけ「安全です」と主張しようとも、そのリンクに慎重にならざるを得ない。 つまり、こういうことだ。**「うちは脱PPAPしました」という事情は、受け取る側がクラウドストレージへのアクセスを緩める理由には、まったくならない。** 相手が慎重なのは、正しい。緩めてくれとお願いするのは、筋が違う。それは「自分の送り方を成立させるために、相手の防御を緩めてくれ」と頼むことであって、かつてPPAPが「受け取る側のウイルスチェックを邪魔する」と批判されたのと、向きが違うだけで同じ迷惑のかけ方である。 --- ## 2. そもそも、クラウドのリンクはEmotet対策になるのか 脱PPAPが持ち出す最大の理由は、「パスワード付きZIPはウイルスチェックをすり抜ける。Emotetのようなマルウェアの温床になる」というものだ。これは事実である。 だが、クラウドストレージのリンク方式が、この問題を解決しているだろうか。 （事実）Emotetという有名なマルウェアは、パスワード付きZIPを添付する手口だけを使っていたわけではない。メール本文に書いたリンクを踏ませ、その先で悪意のあるファイルをダウンロードさせる手口も、あわせて使っていた。JPCERT/CCの注意喚起も、パスワード付きZipファイルの添付と、メール本文中のリンクをクリックさせる手口の、両方を観測したと記している[^1]。 （私の解釈）ということは、「ZIPをやめてクラウドのリンクにしましょう」というのは、受け取る側から見れば、**Emotetが使っていた攻撃の形の一つに、正規の業務のほうから歩み寄る**ことになる。しかもマルウェア本体はメールを通らず、リンクの先で降ってくるので、メールの入り口(ゲートウェイ)の検査もすり抜ける。検査の穴が、メールからWebに移っただけで、塞がってはいない。 そして、ここが肝心だ。**受け取る側が真面目にEmotet対策をしているなら、まさにそのリンクを警戒し、場合によっては弾かざるを得ない。** 送る側の「正しい脱PPAP」と、受け取る側の「正しいEmotet対策」が、正面からぶつかる。だから、クラウドのリンクは、受け取る側にとって、容易には許容できないのである。 --- ## 3. 脱するべきは、たった一つ「Password」だけである ここで、PPAPという言葉を分解してみたい。 - **P**assword付きZIPファイルを送ります - **P**asswordを送ります - **A**ngoka（暗号化） - **P**rotocol（手順） このうち、本当に問題なのはどれだろうか。 （私の解釈）暗号化（A）は悪くない。中身を守るのは、むしろ良いことだ。ZIPという容器そのものも、手順（P・Protocol）も、それ自体が有害なわけではない。**有罪なのは、二つ目のP——Passwordを、ファイルと同じメールで送ること、ただそれだけ**である。 PPAPの弱点を一つひとつ辿っていくと、そのほとんどが「パスワードという、送り手と受け手だけが知っているべき秘密を、どう安全に渡すか」という一点に集まる。同じ経路で送るから盗聴される。弱いパスワードだから破られる。管理が面倒だから付箋に書く。——全部、パスワードの話だ。 だとすれば、PPAPをまるごと捨てる必要はない。**脱するべきは、Passwordの渡し方だけでよい。** これが、私の出発点である。 --- ## 4. メールの入り口(ゲートウェイ)は、何をする場所なのか もう一つ、立ち止まって考えたいことがある。「暗号化するとウイルスチェックができなくなる」という批判は、裏を返せば「メールの入り口で、中身を検査すべきだ」という前提に立っている。私は、この前提に、少し引っかかる。 たとえば、こういう例を考えてみる。誰かが嫌がらせで、封筒にカミソリを入れて郵便で送ったとする。宛先は正しい。切手も貼ってある。郵便局は、これを配達するだろう。中身が危険物であっても、である。 郵便局はX線検査をするかもしれない。だが、それはおそらく、**受取人の安全を守るためではなく、郵便のシステムや、仕分ける機械、配達する人を守るため**だろう。郵便局は、あなたに届く危険物を代わりに判断して止めてくれる、あなたの護衛ではない。 （私の解釈）メールの入り口も、これと同じだと私は考える。メールの入り口が、システム自身を守るために振る舞うのは、正当な自衛だ。しかし、「受取人を守るために、中身を開いて検査し、良し悪しを判断して通す/通さないを決める」のは、話が別である。それは、突き詰めれば**検閲**だ。 私は、**盗聴は防ぎたい。しかし検閲は、あまりしたくない。** メールの中身を、送り手と受け手の同意なしに第三者が読み、判定することには、慎重でありたい。そう考えると、答えは自然に出てくる。 **コンテンツの安全性は、そのコンテンツを開く人が、開くときに確保せよ。** これは精神論ではない。技術的にも、暗号化された中身を検査できる唯一の場所は、それを復号する地点——つまり受け取った人の手元(エンドポイント)である。経路の途中で検査しようとするから、中身を暴く検閲が必要になる。検査を「開く瞬間」に移せば、中身を暴かずに、安全を確かめられる。 （補足）「開く人が守れ」というと、末端に丸投げするように聞こえるかもしれない。だが、まともな組織なら、受け取る側の端末にウイルス対策やEDRといった仕組みを、たいてい既に入れているはずだ。メールの入り口の検査は、いくつもある防御のうちの一つにすぎない。だから、入り口の検査「だけ」に頼る必要はない。開く瞬間に、手元の仕組みが守ってくれる。 --- ## 5. では、私はどのように「脱PPAP」するのか ここまでを踏まえて、私自身のやり方を書く。優先順位の高い順に、三段構えである。 ### 第一：相手がPGPを使えるなら、PGPを使う PGP（gpgとも呼ばれる）は、公開鍵暗号という仕組みを使う。ここで大事なのは、**やり取りすべき「秘密のパスワード」が存在しない**ことだ。 送る側は、相手の「公開鍵」でファイルを暗号化する。公開鍵は、その名の通り公開してよいもので、盗聴されようが誤送信されようが構わない。復号できるのは、対応する「秘密鍵」を持つ相手だけだ。パスワードを盗聴の危険にさらしながら渡す、というPPAP最大の悩みが、そもそも発生しない。 （私の解釈）だから、方式としてはこれが一番強い。ただし、相手も同じ仕組みを運用している必要がある。これは、なかなか高いハードルだ。私自身、かつて「PGPを使えばいいと思うが、今は相手がいない」と、どこかで書いたことがある。 ### 第二：パスワードは、別の経路で伝える 相手がPGPを使えないなら、コンテンツは暗号化してメールで送り、**パスワードだけは、メールとは別の経路で渡す。** 電話、SMS、チャット。何でもよい。要は、ファイルとパスワードが同じ経路に乗らなければよい。 それも難しければ、「相手が知っていそうで、悪意のある第三者は知りにくい情報」を探してみる。探せば、案外ある。たとえば、相手の内線電話番号のような、事前に共有された、外からは分かりにくい情報だ。 ### 第三（最後の手段）：コンテンツはメールに、パスワードだけをクラウドに置く PGPも別経路も、すべて封じられた。そういう窮地のための、最後の手段である。ここは、定番の脱PPAPと発想を**逆さま**にする。 - コンテンツは暗号化してZIPにし、**メールに添付する**（クラウドには置かない）。 - クラウドストレージには、「**パスワードだけを書いたファイル**」を置き、そのリンクを渡す。 なぜ、こうするのか。 （私の解釈）第一に、**コンテンツをクラウドに置かないので、そのクラウドが侵害されても安全である。** 漏れるのは「パスワードだけ」だ。しかも、そのパスワードが何のファイルに対するものかは、そこには書いていない。何の鍵か分からない鍵は、盗んでも使えない。——逆に、定番のやり方のようにコンテンツをクラウドに置けば、そのクラウドが破られたとき、コンテンツそのものが漏れてしまう。後はその（暗号化されているであろう）コンテンツのパスワードの難しさだ。ここで重要なのは、暗号化されたコンテンツというのは、言わば「鍵穴」がそこにあり、後はそれに合う鍵が出来るかどうかと言うこと、つまり正解となる鍵穴がそこにある。しかし、鍵だけでは、それは、どれかの「鍵穴」に合う鍵だとは分かるけど、「何の鍵穴なのか」が分からない点にある。 第二に、置いてあるのがパスワードだけなら、**そのリンクに、アクセス制限も認証も、たぶん要らない。** 守るべき中身がそこにないからだ。リンクの有効期限も、無期限で構わないかもしれない。 第三に、これは前の「別経路」とも繋がる。相手のポリシーでクラウドにアクセスできなくても、**パスワードは短いので、電話で読み上げれば済む。** コンテンツはもう手元(メール)に届いている。定番のやり方だと、コンテンツがクラウドにあるので、アクセスできなければそこで詰んでしまう。私のやり方には、逃げ道が残る。 第四に、**社内での転送が楽になる。** たとえば、A社のαさんから、B社のβさんに見積書が添付されたメールが届いたとする。βさんは、それを社内の上長γさんに回したい。私のやり方なら、コンテンツ(暗号化ZIP)はもうβさんの受信箱にあるので、βさんはパスワードを得たら、そのメールをγさんに転送し、本文に「αさんからのメールを転送します。パスワードは＊＊＊＊です」と書き添えるだけでよい（B社内は安全である、という前提のもとで）。ところが、コンテンツをクラウドに置き、しかも「βさんのアカウントで認証がかかる」方式だと、こうはいかない。γさんはそのクラウドにアクセスする権限を持たないので、βさんは一度自分でファイルをダウンロードし、あらためてメールに添付してγさんに送り直す、といった手間がかかる。**コンテンツを手元に持っているか、他人のクラウドに預けているかの違いが、こうした日常の社内転送の楽さを分ける。** この「第三（最後の手段）」は、「第二：パスワードは、別の経路で伝える」を、より具体的な一つの方法と言える。つまり、第二の方法と第三の方法は、「パスワードが別経路で、それが電話かクラウドストレージにあるか」の違い程度でしか無い。しかしこれは、使い分けの知識負担を低減する。第一の方法、第二の方法、第三の方法、このいずれも、「添付ファイル」は常にメール本文側にある。これがバラバラだと、「この場合はメールにファイル添付、この方法はクラウドにファイルをアップロード・・・ってめんどくさい！」と言う負担を幾ばくかでも減らせることができる。 --- ## 6. この「最後の手段」の限界を、正直に書いておく ここが、私がいちばん大事だと思うところだ。上の第三の方法を、「これさえやれば安全」と受け取ってほしくない。それでは、PPAPを盲目的に信じたのと同じ、新しい思考停止になってしまう。だから、限界をはっきり書く。 （事実／私の解釈） - これは**「下の下策」**である。PGPや別経路が使えるなら、迷わずそちらを使うべきだ。 - **盗聴には弱い。** コンテンツ(の添付)とパスワード置き場のリンクを、同じメールに書いて送れば、そのメールを盗聴した相手は両方を手に入れてしまう。この方法が定番より優れているのは、あくまで「クラウドが侵害されたとき」と「相手がクラウドにアクセスできないとき」の二点であって、盗聴に強くなったわけではない。 - **マルウェア対策は、この方法の役目ではない。** それは受け取る人の手元(エンドポイント)が担う、別の話だ。暗号化ZIPを送る以上、メールの入り口の検査はすり抜ける。そこは、開く人の防御に委ねる、というのが私の立場である。 - **送る側が、届いた後のコンテンツを制御できない。** さきほど「社内転送が楽だ」と書いたが、これは裏を返せば、コンテンツが受け取った人の手元に完全に渡ってしまう、ということでもある。「この人にだけ見せて、それ以上は広めないでほしい」という制御を送る側がしたい場合、この方法では技術的に止められない。逆に、クラウドに置いてアクセス権を絞る方式は、この「それ以上広めない」を強制するための仕組みでもある。どちらが良いかは、目的による。日常の社内転送を楽にしたいなら私の方法が、拡散を送る側が抑えたいならクラウド＋認証の方式が向く。 つまりこの方法は、あらゆる上策が封じられた末に、消去法で残る一手だ。何も考えずに選んだPPAPと、すべての選択肢を潰した末に選んだこの方法は、見た目は似ていても、まったく別物だと私は思っている。 --- ## 7. おわりにーなぜ、これを書くのか 脱PPAPの多くは、「新しいシステムを導入しましょう」という話になる。だが、その多くは、本質的でない負担を、新しい形で人々に背負わせているのではないか。私は、そういう「新しい儀式のための、新しいシステム導入」を、みんなが払わずに済むようにしたい。 私がここで書いたことは、たいそうな発明ではない。「パスワードの置き場を変えるだけ」の、ちょっとした発想の転換だ。特別なシステムを買う必要はない。私自身、このアイデアを独り占めしたいとは、まったく思っていない。 だから、こうして書いて、公開しておく。もし将来、誰かが同じことを思いついて、それを囲い込もうとしたときに、「いや、これはもっと前から、誰でも使える形で世に出ていた」と言えるように。囲い込みを批判してきた私が、自分で囲い込んでしまっては、話が合わないからだ。 最後に、もう一度だけ。この方法は下策である。上策(PGP、別経路)があるなら、そちらを使ってほしい。そして、どの方法を選ぶにせよ、「これをやれば安全」と考えて思考を止めないでほしい。安全かどうかを最後に引き受けるのは、システムでも、儀式でもなく、それを開くあなた自身なのだから。 --- --- ## 脚注 [^1]: JPCERT/CC「マルウェアEmotetの感染再拡大に関する注意喚起」（2022-02-10 公開／2023-03-20 最終更新） https://www.jpcert.or.jp/at/2022/at220006.html ——「主にマクロ付きのExcelやWordファイル、あるいはこれらをパスワード付きZipファイルとしてメールに添付する形式で配信」される一方、「メール本文中のリンクをクリックすることで悪性なExcelやWordファイルがダウンロードされ（る）」ケースも観測されている、との旨が記載されている。（2026-07-10 閲覧） [^2]: 内閣府「平井内閣府特命担当大臣記者会見要旨 令和2年11月24日」 https://www.cao.go.jp/minister/2009_t_hirai/kaiken/20201124kaiken.html ——廃止対象が「ZIPファイル送付と同じ経路でパスワードを自動で送る方式」であること、および「全く別の経路でパスワードを知らせる」ことがまずは適切な対応だった旨の言及がある。（2026-07-10 閲覧） ---