いちばん多い誤解が、脆弱性診断との混同です。両者は似た作業をしますが、目的とゴールがまったく違います。そして日本では、その上にTLPTという3つ目の枠があります。金融庁の資料が、この3つを明確に区別しています。

区分は金融庁『金融分野におけるITレジリエンスに関する分析レポート』（2025年6月）の記述にもとづきます。同資料は「TLPTでは、脆弱性診断やペネトレーションテストと異なり、特定のシステム単体にスコープを絞らず、組織全体をスコープとすることが望ましい」「個別システムの技術的な脆弱性を評価したい場合は、脆弱性診断やペネトレーションテストの活用が適している」としています。

大事なのは、どれが上等かという話ではないことです。個別システムの弱点を知りたいなら脆弱性診断やペネトレーションテストが適しており、組織の検知力を知りたいならTLPTが要る。目的が先で、手法は後です。

TLPTとは何か

金融庁は、TLPTを次のように定義しています。

ポイントは「検知の可否」と「対応の迅速性・適切性」が評価対象に入っていることです。侵入できたかどうかだけでなく、守る側が気づけたか、気づいてから何分で動けたかを測る。だから組織全体が対象になり、だから守る側には知らせずに実施します。

第1章 おわり — 次は第2章

ペネトレーションテストは、長らく「実施した」という事実だけが語られてきました。それが変わりつつあります。監督官庁が、テストの中身を評価して公表し始めたからです。

金融庁は2024年度、TLPTについて2つの施策を実施しています。1つは「TLPT実証事業」—地域金融機関の実態を把握するため、実際にいくつかの金融機関でTLPTを行い、よく見つかる脆弱性を業界に還元する取組み。もう1つが「TLPT事例分析」—実施事例を集め、好事例と課題を整理し、匿名化・一般化して公表する取組みです。

その結果が、2025年6月のレポートに載っています。保険会社の事例から抽出された「望ましい事例」と「不十分な事例」です。要点を抜き出します。

出典：金融庁『金融分野におけるITレジリエンスに関する分析レポート』（2025年6月）図表2および同章の記述を要約。2024事務年度に保険業を対象に実施した事例分析にもとづくもので、金融分野の話である点にご留意ください。

上から2つに注目してください。テスト環境で実施することと、予算に合わせて範囲を狭めること。どちらも現場では「現実的な判断」として日常的に行われていますが、金融庁はこれを課題事例として挙げています。理由も書かれています。

テスト環境については「開発環境では、人員や業務プロセスが本番環境と異なることが多く、現実のリスクを正確に評価することが困難である」。スコープについては「特定のシステムやシナリオだけにスコープを限定するとTLPTの目的を達成できない」。いずれも、テストの目的が「穴探し」ではなく「組織として気づけるかの評価」だから出てくる指摘です。

経営層の関与が足りないと、こうなる

同じレポートには、もう一段踏み込んだ記述があります。「経営陣の関与不足などにより、テストの制限事項が多くなり、TLPTの目的が達成されなくなる事例が認められている」。テストが骨抜きになる原因を、現場ではなく経営の関与不足に置いています。

さらに、結果の受け止め方についても書かれています。経営層がテストで攻撃が成功した原因について現場担当者の責任を問う姿勢を取るのではなく、判明したリスクに対応するための施策推進や追加的なリソース投入をサポートする姿勢を取ることが有用である—と。「攻撃が通った＝担当者の失点」にした瞬間、次からテストは形だけになります。

第2章 おわり — 次は第3章

本格的なテストでは、関係者が3つのチームに分かれます。この役割分担を知らないまま発注すると、第2章の「ホワイトチームが不明確」という課題事例をそのままなぞることになります。

定義は金融庁レポートの脚注26〜28にもとづきます。小規模な組織でホワイトチームを組めない場合は、ブルーチームの責任者が兼ねることも考えられると同レポートは述べています。その場合も、他のブルーチーム担当者には知らせません。

ここが、このテストのいちばん独特なところです。守る側には知らせない。知らせてしまうと、その日だけ監視が厚くなり、普段の検知力を測れなくなるからです。ただし、全員に伏せるわけでもありません。

進み方と、つまずきやすい場所

段階と留意点は金融庁レポートの推奨事項6点（テスト目的の認識合わせ／スコープの設定とテスト内容／経営層の関与／関係者との連携・通知／実施中のホワイトチームの対応／共同利用システムへのテスト）をもとに、筆者が発注側の流れとして整理したものです。

同レポートは、テスト内容についても踏み込んでいます。「事前に決定する検証項目は最低限実施する内容として定義しつつ、テスターがテスト中に得られた情報に応じて柔軟に実施内容の拡張をする形が望ましい」。項目表を全部埋めて終わり、という発注の仕方とは相性が悪い、ということです。

第3章 おわり — 次は第4章

第4章 おわり — 次は第5章

ペネトレーションテストの技術そのものは、学んで悪いものではありません。むしろ、守る側になるほど必要になります。問題は「どこに向けるか」だけです。ここだけは、はっきり線があります。

最後の行について、条文を挙げておきます。他人のIDやパスワードなどを使って、権限のないシステムを使える状態にする行為は不正アクセス禁止法第3条で禁止されており、違反すると同法第11条により3年以下の拘禁刑または100万円以下の罰金と定められています（e-Gov法令検索で2026年8月20日に確認）。動機が善意かどうかは、条文には書かれていません。

第5章 おわり — 次は第6章

発注する側がここを決めていないと、テストの中身は事業者任せになります。第2章の課題事例は、ほとんどが発注側が決めなかったことから生まれています。

2・3・4・5は金融庁レポートの推奨事項と課題事例にもとづきます。1・6・7・8は筆者による整理です。8がいちばん忘れられます。テストは問題を見つける作業であって、直す作業ではありません。

第6章 おわり — 次は第7章

ペネトレーションテストの結果は、たいてい読んで気持ちのいいものではありません。ここでの振る舞いが、次回のテストの質を決めます。

2が要点です。侵入経路は脆弱性診断でも近いものが出ますが、「攻撃されていたのに気づけなかった」という事実は、実際に攻めてもらわないと分かりません。

第7章 おわり — 次は第8章

この用語とセットで覚えると理解が早くなる語です。

第8章 おわり — 最後にFAQ