PPAPはなぜ20年続いたのか——チェックリストが「形」になるとき

パスワード付きのZIPファイルをメールに添付して送り、その解凍パスワードを直後に別のメールで送る。あの運用です。

航空とは何の関係もない話に見えると思いますが、少しお付き合いください。「対策そのもの」より「対策をしている形」が独り歩きし、点検項目として固定化され、実効性を検証されないまま何年も続く——この構造を、これほどきれいに見せてくれる事例はなかなかありません。そして航空のチェックリストは、放っておくと同じ病気にかかります。

PPAPとは何だったか #

「PPAP」は正式な技術用語ではありません。2016年、当時ピコ太郎の同名楽曲が流行していた頃、JIPDEC（日本情報経済社会推進協会）に所属していた大泰司章氏が、その響きが「プロトコルの名前みたいだ」という雑談から命名したものです。

Password付きZIPファイルを送ります
Passwordを送ります
Angouka（暗号化）
Protocol

名前が皮肉であることは一目瞭然で、この命名を境に「これ、意味あるのか？」という議論が一気に表面化しました。ただし運用そのものは2000年代前半から存在していて、名前がついた時点ですでに10年以上の歴史がありました。

生まれた当時は、筋が通っていた #

ここが大事なところです。PPAPは最初から無意味だったわけではありません。

きっかけは個人情報保護法（2003年成立、2005年全面施行）です。企業が一斉に「漏えい対策をやっている」ことを示す必要に迫られた時期でした。そして当時の技術的な前提は、今とはまるで違います。

メールはSMTPで平文のまま流れるのが当たり前だった（通信路のTLS常時使用はまだ普及していない）
クラウドストレージが存在しない。あっても「社外サービスに業務データを置くなど論外」という空気
大きなファイルを社外に渡す手段が、実質メール添付しかなかった

この条件下で「せめて添付ファイルだけでも暗号化しよう」という発想は、決しておかしくありません。少なくとも丸裸で流すよりはマシでした。当時の前提に対しては、合理的な対策だったのです。

広がった理由は、技術的妥当性ではなかった #

問題はここからです。2000年代後半、メールセキュリティ製品のベンダーが「送信時に添付を自動でZIP暗号化し、パスワードを自動で別送する」機能を実装して売り出しました。これが決定打になります。

導入すれば、現場が何も意識しなくても全社の送信メールが「対策済み」になる。しかもログが残るので、監査で示せる。プライバシーマークやISMSの審査にある「添付ファイルの暗号化」というチェック項目を、最も安く、最も形式的に満たせる手段だったわけです。

そして大手企業が採用すると、取引先に「弊社のセキュリティ基準に従ってください」と要求します。要求された側は、自分の取引先にまた要求する。技術的妥当性の検討ではなく、商流に沿って広がっていきました。

こうなると、誰も「これ効果あるんですか」と問い直せません。問い直す立場にある人（現場）には決定権がなく、決定権のある人（発注側・審査側）にはチェック項目しか見えていないからです。

前提が変わり、そして逆効果になった #

20年のあいだに、前提のほうが動きました。

まず、メールの通信路は暗号化されるのが標準になりました。すると「経路上の盗聴対策」という当初の目的が薄れます。そもそも本体とパスワードが同じ経路を通っているので、覗ける立場の人間は両方読めます。金庫の上に鍵を置いているのと変わりません。

誤送信対策としても機能しません。多くの実装ではパスワードメールが自動で即送信されるので、間違いに気づく前に鍵も届きます。

ZIPの暗号強度そのものも問題です。旧来のZipCrypto方式は解析ツールで容易に破られますし、AES対応でも自動生成される8桁程度の英数字なら総当たりで現実的な時間内に開きます。

そして最も深刻なのが、これです。

暗号化されたZIPは、ゲートウェイのウイルス検査を通り抜ける。

中身を見られないのだから当然です。マルウェアの側から見れば、これほど都合のいい慣行はありません。2020年9月、IPAはパスワード付きZIPを使うEmotetの攻撃メールを確認したと注意喚起しています。しかもこのとき、暗号化方式がZipCryptoからAES 256-bitへ「強化」されていた——攻撃側が、検知回避のために暗号を強くしていたわけです。

セキュリティ対策のつもりでやっていたことが、攻撃者に検査回避の口実を与えていた。対策が無意味になったのではなく、符号が反転したのです。

2020年11月24日、平井卓也デジタル改革担当大臣が記者会見で、内閣府と内閣官房において11月26日からPPAPを廃止すると表明しました。民間では2021年10月8日に日立製作所（日立グループ）が公表し、同年12月13日以降は送受信そのものを止めるという踏み込んだ措置をとっています。以降、廃止の流れが一気に進みました。名前がついてから、決着まで5年かかったことになります。

ここからが本題——航空のチェックリストの話 #

さて、航空です。

チェックリストは航空安全の根幹にある道具です。1935年、ボーイング299（後のB-17）の墜落事故——テスト飛行で昇降舵のロックを外し忘れたまま離陸した——をきっかけに制度化された、という有名な由来があります。「熟練者の記憶に頼るのをやめる」という思想です。

ところが、チェックリストは形骸化します。しかも、形骸化のパターンはPPAPと驚くほどよく似ています。

パターン1：省略される #

最も直接的な失敗です。1987年8月16日のノースウエスト255便（デトロイト、MD-82）は、タキシー中のチェックリストが実施されず、フラップとスラットが出ないまま離陸を試みて墜落しました。156名が死亡しています。

NTSBが推定原因として挙げたのは、まさに「TAXIチェックリストを規定どおりに実施しなかったこと」でした。そして報告書は重要な指摘をしています——離陸前の3つのチェックリストのうち、フラップとスラットを出す項目が入っていたのはTAXIチェックリストだけだった。そこを飛ばせば、二重の網はなかったのです。しかも離陸形態警報装置に電源が来ておらず、警報も鳴りませんでした。

2008年8月20日のスパンエア5022便（マドリード、MD-82）は、ほぼ同じ経過をたどっています。フラップ0°のまま離陸し、154名が死亡。離陸形態警報も鳴っていません。21年経って、同型機で、同じ月に、同じ抜け方をしたわけです。

なぜ省略されるのか。多くの場合、「いつもやっていて、いつも問題なかったから」です。問題が起きないことが、項目の必要性を疑わせるという逆説がここにあります。

パターン2：唱えるだけになる #

読み上げてはいる。応答もしている。しかし計器を見ていない。指差し確認が指の動きだけになる。

抽象論ではありません。スパンエア5022便のCVRには、その両方が記録されていました。始動後のチェックリストで「フラップ／スラットのレバーとライトを設定・確認する」項目が省略され、さらに離陸直前の確認では、副操縦士が正しい数値をそのまま復唱していた——実際には見ていないのに、です。

パターン1とパターン2が、同じ機体の同じ離陸で同時に起きた。これが154名の死につながりました。

これはPPAPの「ログは残っている」と同じ構造です。やったという記録は完璧に残るが、意図した機能は果たしていない。そして記録が残っているぶん、外からは正常に見えます。監査を通るのはむしろこちらです。

パターン3：前提が変わったのに残る #

これが一番やっかいです。ある項目が、ある機体の、ある不具合の、ある時代の対策として追加される。機体が変わり、装備が変わり、運航形態が変わる。しかし項目は残る。

なぜ残るかというと、消す理由を誰も説明できないからです。追加するのは簡単ですが、削除するには「これはもう不要である」という積極的な立証が要ります。事故が起きたら「なぜ消したのか」と問われる。だから誰も消さない。項目は単調増加します。

そして項目が増えるほど、パターン1と2が起きやすくなる。形骸化は自己増殖します。

教訓は2つ #

手順ではなく「前提」が古くなる #

PPAPは、平文のメールしかなかった時代には合理的でした。おかしくなったのは手順ではなく、手順が守ろうとしていた前提のほうです。

だとすると、手順書に残すべきは手順だけではありません。「これは何を、どういう条件下で守るための項目か」を一緒に残す必要があります。目的が書かれていない項目は、前提が変わったことに誰も気づけません。書かれていれば、「その前提、まだ生きてますか」と問うことができます。

これは新人教育でも同じです。「そう決まっているから」としか説明できない項目は、教える側が目的を失っている証拠です。そして目的を知らずに覚えた人が、次の世代にまた「そう決まっているから」と教えます。

チェックリストは実効性を保証しない。むしろ検証を止める #

PPAPの本当の害は、暗号が弱かったことではありません。「対策済み」という状態を作ってしまい、それ以上考えなくてよくしたことです。項目を満たしているという事実が、実効性の検証を打ち切らせました。

安全管理システムでいえば、点検項目を埋めることと、リスクが下がっていることは別の話です。前者は測りやすく、後者は測りにくい。測りやすいほうだけを見ていると、いつのまにか測りやすいものを最適化する組織になります。

自分の職場に置き換えてみる #

問いは単純です。

この項目は、何を防ぐためにあるか、説明できるか
その「防ぎたいこと」は、今の機体・装備・運航形態でも起こりうるか
やった記録は残るが、実際の効果は誰も確認していない項目はないか
誰かの要求で始まり、目的を引き継がないまま続いている手順はないか

最後の項目は特に注意が要ります。組織間の要求で始まった手順は、要求した側でも理由が失われていることがあります。PPAPで起きたのは、まさにそれでした。

言うまでもなく、「意味がなさそうだからやめる」は危険です。目的が見えないのは、目的がないからではなく、記録されていないからかもしれません。やるべきは廃止ではなく、まず目的を復元して記録すること。復元できなければ、そこで初めて廃止を議論する。順番が逆になると、それはそれで事故になります。

パスワード付きZIPの話から入りましたが、結局のところ「なぜこれをやっているのか説明できる状態を維持する」という、ごく当たり前の話に行き着きます。当たり前ですが、20年放っておくと当たり前でなくなる、という実例が目の前にあるわけです。

自分の隊の様式や点検表に、目的を説明しにくいものが混ざっていないか。次に手順書を開いたときに、ひとつ確かめてみてもいいかもしれません。

まとめ #

PPAP（パスワード付きZIP＋パスワード別送）は、2016年に大泰司章氏（当時JIPDEC）が皮肉を込めて命名。運用自体は2000年代前半からで、名付けの時点で10年以上の歴史があった。
最初は合理的だった。個人情報保護法（2003年成立/2005年全面施行）を背景に、メールが平文・クラウド無し・添付以外の手段が無いという前提では筋が通っていた。
広がった理由は技術的妥当性ではなく、製品化＋監査項目を安く満たせること＋商流での要求。問い直す人に決定権がなく、決定権を持つ人はチェック項目しか見ていなかった。
20年で前提が動き、符号が反転。TLS常時化で目的が薄れ、鍵と本体が同経路、誤送信にも無力。そして決定的なのが暗号化ZIPがウイルス検査を通り抜けること。2020年9月、IPAがパスワード付きZIPを使うEmotetを確認（しかも検知回避のため暗号がAES 256-bitに「強化」されていた）。
2020年11月24日に平井デジタル改革担当相が内閣府・内閣官房での廃止（11月26日から）を表明、2021年10月8日に日立グループが公表し12月13日以降は送受信を停止。名付けから決着まで5年。
航空のチェックリスト形骸化も同じ3パターン。①省略（ノースウエスト255便・1987、156名死亡。フラップ／スラット項目はTAXIチェックリストにしかなかった）②唱えるだけ（スパンエア5022便・2008、154名死亡。副操縦士が見ずに正しい数値を復唱していた）③前提が変わっても消せない（消す側に立証責任があるため項目は単調増加）。
教訓は2つ。古くなるのは手順ではなく前提——だから手順書には目的を併記する。そしてチェックリストは実効性を保証せず、むしろ検証を打ち切らせる——点検項目を埋めることと、リスクが下がることは別物。
ただし「意味がなさそうだからやめる」は危険。まず目的を復元して記録し、復元できなければそこで廃止を議論する、という順番を守る。