AIはセキュリティテストを置き換えるのか　― 開発スピードとセキュリティ品質を両立するためのAI活用とは ―

本ブログでは、OpenTextの原文記事「Will AI replace application security testing?」の内容をもとに、AIがアプリケーションセキュリティテストに与える影響と、SAST、エージェント型AI分析、Anthropicが発表した「Claude Mythos」のような最先端AIモデルをめぐる論点を分かりやすく整理します。

AIは、アプリケーションセキュリティテストを置き換えるのでしょうか。生成AIやAIエージェントの進化により、この問いは開発部門やセキュリティ部門にとって、いよいよ現実味のあるテーマになっています。コードの解析、脆弱性の指摘、修正案の提示までAIが支援できるようになった今、従来のSAST（静的アプリケーションセキュリティテスト）は不要になるのではないか。そう考える方もいるかもしれません。

OpenTextの答えは明確です。AIはSASTをすぐに置き換えるものではありません。むしろ、既存のアプリケーションセキュリティテストを補完し、より深い分析を可能にする存在として捉えるべきです。

AIだけでアプリケーションセキュリティを完結させることはできない

LLMは、アプリケーションセキュリティチームがそのまま利用できる完成されたソリューションではなく、あくまで構成要素として捉える必要があります。セキュリティテストを企業の開発プロセスに組み込むには、モデルの能力だけでは不十分であり、次のような仕組みが必要になります。

• コードベース全体を確実に分析する仕組み
• 再現性のある結果
• 構造化されたレポート
• 既存ツールの検出結果との重複排除
• ポートフォリオ管理
• CI/CD連携

AIに対して「このプロジェクトのセキュリティ課題を見つけて」と指示すれば、いくつかの問題は見つかるかもしれません。しかし、それだけでは、企業全体で継続的に運用できるアプリケーションセキュリティテストにはなりません。開発現場で本当に使える仕組みにするには、検出、優先順位付け、レポート、修正管理、開発パイプラインとの統合まで含めて考える必要があります。

日常的なテストにAI分析を使うには、コストの壁がある

もう一つ重要な論点がコストです。AIによるエージェント型コード分析は、深い洞察を得られる可能性がある一方で、すべてのアプリケーション、すべてのコミット、毎日の開発サイクルにそのまま適用するには負荷が大きくなります。現実的なビジネスアプリケーションをプレミアムモデルでスキャンした場合、トークン費用だけで数百ドル規模になる可能性があり、Anthropicが発表した「Claude Mythos」の公開価格を前提にすると、1回のスキャンが1,000ドルを超える可能性もあります。

これは、ペネトレーションテストのような深いレビューであれば妥当な投資になり得ます。一方で、日々の開発プロセスに組み込み、すべての変更を継続的に確認する用途では、従来型SASTの高速性、決定論的な動作、低コストという特長が引き続き重要です。

そこで現実的な方向性となるのが、「ハイブリッド分析」です。具体的には、次のように役割を分けて活用します。

• 従来型SASTを日常的な第一防衛線として継続実行する
• AIを活用したエージェント型分析を、週次や月次の深いレビューに用いる
• 開発スピードを保ちながら、より高度な脆弱性や設計上の問題にも目を向ける

AIの価値は、文脈を読む分析にある

AIエージェントによる分析が注目される理由は、従来のSASTでは見つけにくい種類の問題を発見できる可能性がある点です。例えば、署名されていないCookieにユーザー名を保存し、サーバー側セッションを持たない認証設計のようなアーキテクチャ上の欠陥が挙げられます。このような問題は、単一のコード行だけを見ても判断しにくく、アプリケーション全体の設計や処理の流れを理解する必要があります。

つまり、AIの価値はSASTを不要にすることではありません。SASTが得意とする高速で継続的なチェックに、AIが得意とする文脈を踏まえた深い分析を重ねることで、アプリケーションセキュリティのカバレッジを広げることにあります。

AIに任せるのではなく、AIでアプリケーションセキュリティを拡張する

生成AIを開発現場で活用する動きが広がるなか、アプリケーションセキュリティにも変化が求められています。ただし、重要なのは、AIにセキュリティテストを丸ごと任せるという考え方ではありません。必要なのは、既存のテスト基盤の強みを活かしながら、AIによって分析の深さと範囲を拡張するという発想です。

企業のアプリケーションセキュリティには、単一の技術ではなく、次の要素を組み合わせた運用が必要です。

• 継続的に実行できるSAST
• 必要に応じた深いAI分析
• 結果を開発チームが扱いやすい形に整理する仕組み
• 組織全体で脆弱性対応を管理するプロセス

このように、AIをアプリケーションセキュリティに取り込む際には、分析機能そのものだけでなく、利用可能なAIモデルの性能やコスト面での現実性、攻撃者が同等のAI能力を使うリスクもあわせて考える必要があります。

Claude Mythosのような最先端AIに、AppSecはどう向き合うべきか

その代表的な論点が、Anthropicが発表した「Claude Mythos」のような最先端AIモデルをめぐる期待と懸念です。Claude Mythosは、防御側のセキュリティ分析をどこまで高度化できるのかという観点だけでなく、攻撃者が同等の能力を利用した場合にどのような備えが必要になるのかという観点でも重要です。ここでは、その論点を「利用できない場合の考え方」と「攻撃者が利用する場合の備え」に分けて整理します。

Claude Mythosにアクセスできない場合の考え方

Claude Mythosのような最先端AIモデルにアクセスできないことは、直ちに大きな不利になるわけではありません。深いエージェント型分析は必ずしもClaude Mythos級モデルだけに依存するものではなく、一般利用可能なモデルでも中核的な検出は可能です。そのうえで、プレミアムモデルを分析範囲の確認や結果の検証に活用すれば、実用的なAI分析を既存のAppSec運用に組み込むことができます。

攻撃者によるAI活用への備え

一方で、攻撃者がClaude Mythosまたは同等のAI能力を利用する可能性は前提として考える必要があります。特に、オープンソースコードは解析対象として開かれているため、AIによるゼロデイ探索や、公開されたセキュリティパッチの解析による攻撃コード作成が、より速く大規模に行われる可能性があります。

この脅威に対して重要なのは、まったく新しい特殊技術だけを追い求めるのではなく、既存のアプリケーションセキュリティプラクティスをより厳格に実行することです。具体的には、SCAによる依存関係リスクの管理、影響度の高い脆弱性の迅速な修正、出荷前の全コード検査、そしてAI生成コードも含めたSASTの継続実行が重要になります。

まとめ

AIは、アプリケーションセキュリティテストを終わらせるものではありません。重要なのは、従来型SASTを日常的な第一防衛線として活用しながら、AIによるエージェント型分析を、より深いレビューの手段として組み合わせることです。生成AI時代のアプリケーションセキュリティに求められるのは、「AIかSASTか」という二者択一ではなく、双方の強みを活かした、より実効性のあるセキュリティ運用への進化です。

また、Mythos級モデルにアクセスできない場合でも、一般利用可能なモデルとプレミアムモデルを役割分担して使うことで、実用的な深いAI分析を行うことは可能です。

一方で、攻撃者によるAI活用に備えるには、SCA、出荷前検査、AI生成コードを含むSASTといった既存のAppSecプラクティスを、これまで以上に徹底することが重要です。