オフェンシブセキュリティ企業Pentest-Tools.comの新たな調査研究により、AIツールがコードを生成するスピードと、セキュリティチームが本番環境に到達する前にそれを検証できる能力との間に、拡大しつつある断絶が数値化された。この状況は、企業リスクとコンプライアンスに重大な影響をもたらす。
本調査は2026年3月に英国、欧州、米国のAIコーディングツール利用者241名を対象に実施されたもので、脆弱性テストが開発スピードに完全に追いついていると考える開発者はわずか9%にとどまることが判明した。半数以上(51%)が、AIを活用して作成されたコードがすでにデプロイされた後にセキュリティ脆弱性を発見したと回答している。
検証の窓が縮小している
AIコーディングツールは、実験的な付加機能ではなく、今や組み込みインフラとなっている。回答者の4分の3(76%)が「常に」または「たいてい」使用しており、82%はその利用を積極的に奨励または義務付けている組織で働いている。調査が明確にしている課題は、ツール自体ではなく、コードが書かれるスピードと、それがいかに厳密にチェックされるかの間に広がるギャップだ。
回答者の30%が、デプロイ前にAI生成コードを十分にレビューする時間が確保できていないと回答した。さらに34%が、開発スピードによって脆弱性が十分に精査される前にコードがリリースされたことがあると認めた。
「大量のAI生成コードのレビューに疲弊し、デプロイ後にバグを引き起こすコードを一部見逃してしまっている。」– 調査回答者
脆弱性の性質が変化している
調査の定性的な回答は、AIを活用した開発から生じる脆弱性について、その頻度だけでなく性質の変化を示していた。実務担当者は一貫して、明らかな構文エラーの減少と、より微妙で発見しにくい問題——迅速なレビューをすり抜けるタイプの問題——の増加を報告した。
- AIが提案したパターンからコピーされた脆弱な認証チェック
- 安全でないデフォルト設定と安全でない入力処理
- 個々のコードコンポーネントはレビューを通過するものの、組み合わさると失敗するロジックの欠陥やアーキテクチャの設定ミス
- 個別の問題として現れるのではなく、複数のプルリクエストにわたって複合化する脆弱性
あるの回答者はこの変化をこう要約した。「脆弱性が、明らかなバグから発見しにくいレビューの見落としへと移行した。」
従来の静的解析ツールは、このクラスの問題を検出するのに適していない。報告書は、そのような欠陥はコードの検査時点ではなく、コードが実行されているとき、システムが相互作用するとき、または攻撃者がデプロイ済みのアプリケーションに到達したときにのみ表面化することが多いと指摘している。
コンプライアンスへの影響
報告書は、検証ギャップと監査対応の準備状況を直接結びつけている。SOC 2、ISO 27001、PCI DSS、DORA、HIPAAを含むフレームワークの下では、組織は脆弱性が存在したこと、修正されたこと、そしてテストが再現可能であったことを示す証拠を提示することが求められる。CIビルドの合格や生のスキャナー出力は、これらの要件を満たさない。
回答者の34%が認めているように、検証が完了する前にコードがリリースされると、監査に必要な文書の追跡記録が弱体化する。報告書は、証拠の取得を別途の監査準備作業としてではなく、テストプロセスの定常的な出力とする必要があると主張している。
より優れたパフォーマンスを発揮するチームが実践していること
- AI生成コードをデフォルトで信頼できないものとして扱い、サードパーティの依存関係に適用するのと同じ精度でレビューする
- セキュリティ検証をマージの境界に近づけ、デプロイ後ではなくプルリクエストに対して自動スキャンをゲートとして設定する
- AIツールを使用してAI生成コードの一次レビューを実施し、人によるレビューの前に問題となりそな箇所を表面化させる
- AIコード生成をコードベースのリスクの低い領域に限定し、認証フロー、決済経路、データアクセスについては厳格な人による開発を維持する
完全な報告書「縮小する検証の窓(The Shrinking Validation Window)」はこちらから入手できる。