LLM を活用したソースコードのセキュリティ強化 — アンソロピックのエウジェン・ヤン氏

LLM はもう「発見」だけじゃない。セキュリティ強化の次なるボトルネックと、実装ロードマップ

モジラやアンソロピックの実績が示す通り、LLM（大規模言語モデル）による脆弱性発見能力は劇的に向上しました。しかし、今や最大の課題は「どこに穴があるかを見つけること」ではなく、「見つけた穴を本当に検証し、優先順位をつけて修正するか」という工程にあります。

アンソロピックのエウジェン・ヤン氏は、AI を単なるスキャンツールから自律的なセキュリティエンジニアへと進化させるための具体的な 6 段階アプローチと、組織が直面する非技術的ボトルネックへの対策を提唱しています。本記事では、動画の核心を整理し、明日から始められる実用的なロードマップをご紹介します。

ボトルネックは「発見」から「検証・修正」へシフトした

まず、現在の LLM のセキュリティ能力について確認しておきましょう。過去数年でモデルの性能は飛躍的に向上しており、複雑なサイバー攻撃タスクを人間よりも長く、正確に実行できるようになっています。

その実証として、モジラの Firefox における脆弱性修正数の推移が象徴的です。2025 年に入ってから修正数が急増し、4 月には前年の平均の約 20 倍に達しました。この劇的な増加は、LLM が防御側（デフェンダー）として大規模な脆弱性の発見と修正を担っていることを示しています。

しかし、ヤン氏はこう指摘します。

「脆弱性を見つけることは今や非常に簡単になりました。ボトルネックは『検証（真偽の判定）』、『優先順位付け（トライアージ）』、そして『パッチ適用』へとシフトしているのです。」

Log4Shell や Heartbleed といった歴史的な大規模インシデントを振り返れば、脆弱性の存在自体よりも、それをどう迅速に特定し、組織内で合意形成して修正するかの方が大きな課題だったことがわかります。AI が発見した数百件の候補のうち、実際にリスクがあるのは一部です。人間が一つずつ手動で検証していたら、リソースはすぐに枯渇してしまいます。

自律的なセキュリティエンジニア：エージェント型ハルネスの必要性

この問題を解決する鍵となるのが、「エージェント型ハルネス（Agentic Harness）」という概念です。単にコードをスキャンするだけでなく、AI が自律的に行動し、検証し、修正案を出すための環境を整える必要があります。

初期の実験では、LLM による検知結果の偽陽性率が高すぎて実用化が困難でした。しかし、モデルとハルネス（実行環境）を組み合わせたアプローチにより、現実的なバグを特定し、再現不可能な推測を排除することが可能になりました。

ヤン氏が推奨するシステムは、以下の 2 つの基盤の上に成り立っています。

1. 脅威モデル（Threat Model）の構築

AI はコードの文脈は理解できても、システムの設計意図や暗黙的なリスクまでは把握できません。そのため、人間が「このシステムで何が危険か」を定義した脅威モデルを AI に与える必要があります。

これは単なるドキュメントではありません。過去のコミット履歴やパッチ情報から AI が潜在的な脆弱性を推測させたり、システム設計者にインタビューする形で「想定外のリスク」や「すでに対策されている領域」を明文化したりするプロセスです。

「モデルはコードの文脈には優れていますが、システムの文脈には劣っています。設計者の意図や、オンコールで頻繁に修正された問題など、暗黙知をドキュメントとして残すことで、真陽性率を 90% 近くまで引き上げることができます。」

2. 隔離されたサンドボックス環境

AI が脆弱性を検証するためには、実際にコードを実行して攻撃を試みる必要があります。しかし、本番環境でこれを行えば大惨事になります。

そのため、ネットワーク分離（egress なし）、クラウド認証情報の排除、データ漏洩防止などの対策を施した隔離されたサンドボックスが不可欠です。ここでは、AI が意図的に脆弱性を悪用する「PoC（Proof of Concept）」を実行し、それが実際に機能するかを確認します。

例えば、注文処理サービス（Order Service）のテスト環境では、アプリケーション、データベース、キャッシュサーバーを Docker コンテナで構成し、その外側からセキュリティエージェントが HTTP 経由でプローブを行います。この環境下で AI が「SQL インジェクション」などの攻撃を試み、実際にデータが漏洩するかを検証することで、真偽を判定します。

6 段階の実装プロセス：AI をどう動かすか

ヤン氏が提唱する、自律的なセキュリティ強化のための具体的なワークフローは以下の 6 ステップで構成されます。このループを回すことで、AI は人間と協働し、効率的にセキュリティを強化します。

Step 1: 設定（脅威モデルの作成）

システム全体のリスクマップを作成します。どのデータが重要資産（PII など）なのか、エントリーポイントはどこか、どのような攻撃ベクトル（SQL インジェクション、認証绕过ぎなど）が想定されるかを定義します。

Step 2: 設定（サンドボックスの構築）

上記で定義したシステムを再現する隔離環境を整備します。AI が安全に攻撃コードを実行・検証できる基盤です。

Step 3: 発見（Discovery）

AI が脅威モデルとコード、そしてツール（API クエリ、ログ確認など）を活用して脆弱性を探索します。ここで重要なのは「コンテキストエンジニアリング」です。AI に与えるプロンプトは、モデルが賢くなるほど簡潔にするべきで、詳細な指示よりも「信頼境界を越える不審なデータフローを探す」といった高レベルの指示の方が効果的になることもあります。

Step 4: 検証（Verification）

発見された候補が実際に脆弱性かどうかを検証します。サンドボックス内で PoC を実行し、攻撃が成功するかを確認することで、偽陽性を排除します。

Step 5: 優先順位付け（Triage）

人間が対応できる数には限りがあります。AI は発見した数百件の候補を、リスク度や影響範囲に基づいてランク付けし、開発者がまず取り組むべきトップ 10〜20 の重要課題に絞り込みます。

Step 6: パッチ適用（Patching）

最終的に、修正コードの生成や提案を行います。AI が生成したパッチが安全であることを再度検証し、本番環境へ展開する準備を整えます。

技術以外の壁：組織内の合意形成と人的リソース

このプロセスを成功させる上で最大の障壁は、計算リソースやアルゴリズムの性能ではなく、「非技術的なボトルネック」です。ヤン氏は、組織内の合意形成や人的リソースの限界が課題になると指摘しています。

AI を導入しても、セキュリティチームと開発チームの間で「どのリスクを優先するか」「どのようなプロセスで修正を行うか」というルールが定まっていなければ、システムは機能しません。また、脅威モデルの作成やサンドボックスの維持には、専門知識を持つ人間の時間が必要です。

「計算リソースの問題ではなく、組織内の合意形成と人的リソースの限界が障壁となります。文書化とプロセスの標準化が不可欠です。」

そのため、即座に始められるオープンソースツールの活用や、AI と人間の役割分担を明確にしたドキュメント作成から着手することが推奨されます。

まとめ：DevSecOps の未来は「協働」にある

LLM を活用したセキュリティ強化は、もはや「ツールを導入するかどうか」の段階ではありません。重要なのは、AI を自律的なパートナーとして位置づけ、発見・検証・修正のプロセスをどう組織に組み込むかというアーキテクチャ設計です。

ヤン氏の提唱する 6 ステップのアプローチは、AI が単なるコード生成ツールから、自律的なセキュリティエンジニアへと進化するための具体的なロードマップです。技術的な課題だけでなく、組織文化やプロセスの再構築にも目を向け、明日からでも始められる一歩を踏み出すことが、これからのセキュリティ対策には不可欠でしょう。