ここで検証の頻度と範囲が重要になってきます。人が直接行う模擬ハッキング（ペネトレーションテスト）は精密です。しかし、一度に点検できる範囲と頻度には限界があります。企業のIT環境は変化し続けます。新しいサーバーが構築され、クラウド設定が変更され、APIが追加され、外部の連携システムが接続されます。しかし、セキュリティ検証が6ヶ月前の状態にとどまっているなら、現在のリスクを説明することはできません。

AIを活用したホワイトハッカー作業は、この限界を補完します。決められたシステムの一部を年に数回覗き見るような方式ではなく、変化が生じるたびに、新しい資産が追加されるたびに、新しい脆弱性が公開されるたびに、検証を再実行できます。重要なのは、一度の点検で終わらせないことです。次の点検までに生じる空白の時間を最小限に抑えなければなりません。

攻撃者がAIを使ってパッチを素早く武器化（実用化）するなら、防御者もAIを使って自社システムをより迅速に検証しなければなりません。攻撃者が1時間以内に攻撃コードを作成できるなら、防御者もその時間内に「この脆弱性が自社システムで実際に悪用される可能性があるか」を確認する必要があります。速度の非対称性が完全に解消されるわけではありませんが、その差を縮めることが新しい防御の基準線になります。

パッチをすぐに適用できない場合でも、検証は重要です。実際の攻撃可能性が確認されれば、セキュリティチームは暫定的な防御措置を先に適用できます。アクセスの遮断、ファイアウォールポリシーの変更、WAFルールの適用、アカウント権限の縮小、脆弱なサービスの無効化、検知ルールの追加、ネットワークの分離といった措置が可能です。完全なパッチ適用が最善ですが、パッチが遅れる場合は攻撃経路を先に遮断することも重要な防御です。

結局のところ、CTEMとAIホワイトハッカーによる検証は、セキュリティチームが200件の脆弱性を前に立ち尽くしてしまうような状況を減らしてくれます。「何を修正すべきか分からない」という状態から、「今日最も優先して減らすべきリスクはこれだ」と言えるようにしてくれます。

200個のパッチが一気になだれ込み、その中のどれが先に攻撃されるかが数日ではなく数時間以内に決定される環境では、「たまに行う点検」よりも「継続的な検証」がより大きな価値を持ちます。 

AIが攻撃速度を時間単位に圧縮した時代において、防御も決められたスケジュール中心から持続的な循環構造へと変わらなければなりません。何を守るかを決め、露出（エクスポージャー）を探し、優先順位をつけ、実際に突破されるかを検証し、その結果を対策へと移すプロセスが、一回限りのイベントではなく、繰り返され続けるサイクルにならなければなりません。

参考資料

1. Anthropic, “Measuring LLMs’ impact on N-day exploits”, 2026.06.08

2. Zero Day Initiative, “The June 2026 Security Update Review”, 2026.06.09

3. Microsoft Windows Blog, “Reflecting on 20 years of Windows Patch Tuesday”, 2023.11.09

4. CTEM.org, “Continuous Threat Exposure Management: A Definitive Guide”

5. Team Cymru, “What is Continuous Threat Exposure Management?”

6. Anthropic, “Project Glasswing: Securing critical software for the AI era”, 2026.04.07

7. Anthropic, “Project Glasswing: An initial update”, 2026.05.22

8. Anthropic, “Making frontier cybersecurity capabilities available to defenders”, 2026.02.20