AIモデルの攻撃能力と防御能力の差が広がる中、企業は深刻なサイバー非対称性の問題に直面しています。
ここ数カ月、LLM(大規模言語モデル)は、オープンソースプロジェクトやバグ報奨金プログラムに疑わしいセキュリティレポートを大量に送りつけ開発者の時間を浪費させていた段階から、人間や従来のセキュリティ監査ツールが何年も見逃してきたゼロデイ脆弱性を日常的に発見する段階へと急速に進化してきました。こうしたサイバー能力の急速な進化は、開発元自身すら恐れさせるほどのものです。
しかし、脆弱性の発見やエクスプロイトの生成においてこうした進歩が見られる一方で、AIモデルはサイバー防御の重要な領域では同じペースで進歩していないようです。生成するコードには基本的なセキュリティ上の欠陥が残ることが多く、これは深刻なギャップとなっています。ソフトウェア開発でAIが広く使われるようになっていることに加え、AIが今や容易に発見・悪用できるようになった脆弱性に対するパッチ提供を支援する場面でも、この問題は重要な意味を持ちます。
アプリケーションセキュリティ企業Veracodeによる最近の調査によると、AIが生成したコードの44%には、OWASP Top 10に該当する既知の脆弱性が少なくとも1つ含まれていました。最新の最先端モデルはより高いスコアを記録したものの、セキュリティ合格率が68%を超えたモデルは1つもなく、これは3回に1回の割合で依然として安全でないコードを生成していることを意味します。
さらに、Veracodeが過去1年間に実施した4回の調査(計100を超えるモデルバージョンを対象)を通じて、AIが生成したコードの平均セキュリティ合格率はほとんど改善していませんでした。
一方、テスト対象となったすべてのモデルは、99%の確率で構文的に正しいコードを生成しました。
「なぜ構文面では上達しているのに、エクスプロイトコードを書く能力は向上しているのに、安全なコードを書く能力は向上しないのでしょうか」。VeracodeのチーフセキュリティエバンジェリストであるChris Wysopal氏は、CSOとの取材でこの結果についてこう疑問を投げかけます。「それは私が[AI開発企業各社に]問いたい質問であり、私たちが測定しようとしていることでもあります」
これは、AIによってソフトウェア開発を加速させるという約束を実現しようとするITリーダーにとって重要な問題です。特に、AIによってエクスプロイトまでの時間がほぼ瞬時に近いレベルにまで短縮されつつある時代においてはなおさらです。
サイバー能力の不均衡
LLMにおける攻撃能力と防御能力の非対称性の拡大を指摘しているのは、Veracodeだけではありません。オランダのソフトウェア品質保証企業Software Improvement Group(SIG)が「State of Software 2026」レポートのために実施したテストでは、AIが生成したコードは人間が書いたコードと比較して、セキュリティリスク違反がおよそ2倍発生することが分かりました。
「AIコードに限らず、コード全体の71%がセキュリティ管理のレベルが低いことも分かりました」と、SIGの最高技術責任者(CTO)であるJasper Geurts氏はCSOに語ります。「AIが問題を作り出したわけではなく、問題を増幅させたのです。組織がコード品質を計測・管理している場合、AIは開発を加速させます。そうでない場合は、技術的負債とセキュリティリスクの拡大を加速させてしまいます」
7月には、Theoriが開発したコードセキュリティテストプラットフォームXint.ioの研究者らが、AnthropicとOpenAIの最新AIモデル5種を使ってアプリケーションをゼロから「バイブコーディング」し、さらに既存の人間が書いたアプリケーション1つについて再アーキテクチャと堅牢化にも取り組みました。28種類のアプリケーションバリエーションを通じて、研究者らは434件のセキュリティ上の欠陥を発見・検証し、そのうち196件は新規に生成されたコードベース(グリーンフィールド)、238件は再アーキテクチャされたアプリケーション(ブラウンフィールド)で見つかりました。
「全体として、AIが生成したコードで最も多く見られる欠陥のタイプは、コード自体はコンパイルが通り実行できてしまうものの、機密情報がコード内に埋め込まれていたり、大規模運用時にリソースを過剰に消費してしまったりするものです」と、TheoriでXintのプロダクトオーナーを務めるKay Kwak氏はCSOに語ります。「これは一部、学習データに含まれる近道的な実装やクイックスタート的なコードに起因しています。また、開発者が機能だけを求め、それに伴う安全対策(ガードレール)を明示的に求めていないことも一因です。さらに、コードベースが大規模かつ複雑になるほど、AIが細かいユーザー権限の管理を見失いやすくなることも分かりました」
Xintの調査が示す通り、モデルは既存のコードベースを扱う場合でも安全なコードの生成に問題を抱えています。そしてこれは、セキュリティ上の欠陥を修正する場面にも当てはまります。1PasswordのOff-By-1 Labsによる調査では、複雑なオープンソースプロジェクトにおける既知の修正済み脆弱性6件について、各種モデルが生成した新たなパッチの品質をテストしています。
6,000回を超える試行の結果、アプリケーションの動作を大きく変えることなく脆弱性を完全に解消するパッチを生成できた成功率は平均でわずか26%でした。LLMが生成したパッチの半数以上は、脆弱性を解消できていなかったり、新たな脆弱性を追加してしまったり、あるいはその両方に該当していました。
「私たちの調査はパッチ適用に焦点を当てたものであり、まったく新規のコード作成プロセスというよりも、既存コードの編集プロセスを観察したものです」と、1PasswordのOff-By-1 Labsを率いるKeith Hoodlet氏はCSOに語ります。「そのため、私たちの調査とVeracodeの調査は、同じ課題を評価しているというよりも、互いに補完し合うものと見なすべきです。とはいえ、私たちはVeracodeの調査を自分たちの研究のきっかけの1つとして挙げており、両者の調査結果はいずれも方向性として同様の結論を示しています」
学習の改善だけでは安全なコーディングは解決しない可能性
AI開発企業各社は最先端の脆弱性研究におけるモデルの進歩を積極的にアピールしていますが、安全なコード生成と脆弱性修正が、脆弱性発見やエクスプロイト開発の能力に比べてなぜこれほど遅れているのかは、必ずしも明確ではありません。
Xintのクワック氏は、安全なコードを書くことと、コードが安全であることを証明することは、本質的に難しい問題だと考えています。「これはAIに固有の難しさではありません」と同氏は言います。「ソフトウェアエンジニアリングには、仕様の不十分さという問題が付きまといます。コードが『してはいけないこと』のすべてを書き出す人はいないのです」
攻撃シナリオと防御シナリオとでは「成功」の定義が異なることも、この差を説明する一因かもしれません。攻撃面での成功は比較的検証しやすく、あるエージェントが脆弱性を再現あるいは悪用できれば、その結果は明確です。しかし、あるパッチが関連するすべての悪用経路や脆弱なコードパスを塞げているかどうかを判断するのは、はるかに難しい作業です。
とはいえ、学習データの質はLLMの性能にとって重要であり、既存のモデルが品質やセキュリティレベルにばらつきのある大量の公開コードで学習されてきたことは、妥当な推測と言えるでしょう。
「今耳にする実験はどれも、攻撃的な能力で遊びながら、どうすれば攻撃ができるかを理解しようとしているものばかりです。エージェントが暴走してしまったのも、そうした経緯からです」と、Veracodeのワイソパル氏は、テスト中にエージェントが封じ込めを脱して第三者のシステムを攻撃したAI開発企業各社での一連のインシデントに触れつつ語ります。
「本来彼らがすべきなのは、厳選された安全なソフトウェアのデータセットを用意し、それだけを使って学習させることです。『インターネット上に散らばるランダムなコードで学習させたことは全部忘れよう。あれは全部捨ててしまおう』というスタンスで臨むべきなのです」と同氏は続けます。「銀行や航空電子工学の分野など、厳格なコードレビューを経ているためセキュリティが確保されていることが分かっているコードを、可能な限りライセンス調達し、それだけを使って学習させるべきです。これは難しく時間もかかりますが、防御能力を高めるにはそうするしかありません。私の知る限り、彼らはそうした取り組みを行っていません」
一方、フードレット氏は、LLMに内在するもう1つの限界を指摘します。それは、入力トークンの文脈や関連性を判断する仕組みである「アテンション機構」です。
「現在のLLMの動作の根幹をなすアテンション機構そのものが、脆弱性パッチ適用という課題にモデルが完全に対応することを永遠に妨げている可能性があります」と同氏は言います。「研究論文のセクション7.3では、あるエージェントが生成したパッチが、概念実証(PoC)エクスプロイトに対応する単一のコードパスにしか対処しておらず、隣接するコードパスに存在する文字単位でまったく同一の同種のバグを見落としているケースを観察しました。この本質的な限界を踏まえると、より優れた安全なコーディングの成果を得るために、さらにどれだけの学習が必要になるのかは不透明です」
ガーツ氏は、学習の改善が効果を発揮するのはあくまで限定的な範囲にとどまると考えています。というのも、モデルはデフォルトの状態では、組織固有のアーキテクチャやセキュリティポリシー、脅威モデル、その他アプリケーション固有の文脈情報を持っていないからです。ハーネス(実行基盤)を用いれば、そうした文脈情報を与え、開発ワークフローの中に決定論的なセキュリティチェックを組み込むことができます。
ハーネス設計は依然として重要
今回の調査でVeracodeは、追加のセキュリティ指示を含めない最小限のプロンプトを意図的にモデルへ直接送信しました。これは、実際のソフトウェア開発チームがLLMを利用する方法とは異なります。他の調査ではさまざまな程度の足場(スキャフォールディング)が用いられましたが、詳細な仕様書や検証ワークフロー、システムプロンプト、MCP接続、スキル定義など、その他の支援ツールを備えた専用のAIコーディングアシスタントを含め、成熟した企業の開発パイプラインに存在し得る管理策の全範囲を評価したものはありませんでした。
こうしたハーネスは、関連ファイルやアーキテクチャ文書を取得したり、脅威モデルの情報を提供したり、承認済みのコーディングパターンを一覧化したり、コンパイラやテストを実行したり、静的・動的なセキュリティテストツールを呼び出したり、特定された問題が解消されるまでAIエージェントの続行を阻止する承認ゲートを強制したりすることができます。
例えば、OpenAIはTrail of Bitsと提携し、自社モデルを使ってインターネットインフラにとって重要なオープンソースプロジェクトの脆弱性を発見し、そのパッチ開発を支援しています。「Patch the Planet」と名付けられたこのプロジェクトでは、研究者らが専用のワークフローとハーネスを構築しており、8月11日時点で、49件のコードベースにわたって報告された問題1,250件、作成された修正271件、そしてアップストリームに採用されたパッチ146件が記録されています。
クワック氏によれば、Xintも社内テストで同様の効果を観察しているといいます。同社は、17件の脆弱性を意図的に埋め込んだ20万8千行のコードに対して、最先端モデルを評価しました。単純なプロンプトによるループ処理では発見できた欠陥は0件から1件にとどまった一方、Xintの専用ハーネス内で動作させたモデルは11件から14件を発見しました。
「単純なループ処理では、全体のわずか2.9%のファイルしか開いていませんでした。一度も開かないファイルの中のバグは、見つけようがありません」とクワック氏は述べます。
ハーネスは、どの証拠がモデルに渡されるか、どのツールが最初の回答に異議を唱えられるか、何をもって「進捗」とみなすか、そしてワークフローをいつ停止・エスカレーションすべきかを決定します。これはモデル選択と同じくらい重要な要素となり得ます。特に大規模なリポジトリを扱う場合はなおさらです。過去半年の間には、長い推論ループにおける能力が劣るオープンウェイトモデルであっても、専用に設計されたハーネス内で使用することでモデルを軌道に乗せ、メモリ管理を適切に行った結果、最先端モデルと同等の性能を発揮した例が数多く見られます。
SIGは最近、Claude Sonnet 4.6を使って同一のテストプロジェクトを20回構築しました。うち10回は同じモデル・タスク・スキャフォールド・受け入れテスト・初期指示を使用し、残りの10回にはさらに、同社のSigrid GuardrailsシステムをMCP経由で必須のセキュリティ・品質ゲートとして組み込みました。ガイド付きの実行では、SIGの分析上、高リスクのセキュリティ検出件数がおよそ97%減少し、保守性スコアも24%向上しました。
「ハーネスはAIエージェントにとってのオペレーティングシステムです」とガーツ氏は指摘します。「エージェントを信頼できるものにするための制約を組み込む場所がハーネスなのです。それがなければ、AIは速く説得力があるように見えても、間違っていることがあります」
効果的なハーネスは、コードリンター、型チェッカー、セキュリティスキャナー、そしてエージェントの出力が検証されるまで先へ進むことをブロックするテストなど、決定論的な分析ツールをAIワークフローに組み込みます。しかし、よく設計されたハーネスを使っても、脆弱性が一切残っていないことを保証できるわけではありません。
「ハーネスの実装こそ、業界が今後大きく向かっていく方向性だと私たちは考えています」と、Off-By-1 Labsのフードレット氏は言います。「脆弱性発見から批評・判定、パッチ適用、検証を経て再び脆弱性発見へと戻るワークフローを実行する場合、堅牢なパッチを生成できる確率を90%以上にまで高めるには、このプロセスを10回繰り返す必要があるのでしょうか。それとも100回、あるいは1,000回の反復が必要なのでしょうか。これは私たちが今後より詳しく掘り下げていきたいテーマです」
人間による監督は依然として必要
検証ゲートや自動チェックは、開発者の手元に届く欠陥コードの量を減らすことはできますが、結果に対する責任をLLMに転嫁するものではありません。AIエージェントはスキャナーの検出結果に対応してテストを実行し、出力を修正することはできますが、最終的には、要件が十分に定義されていたか、検証が十分だったか、そして残存リスクが許容範囲内かどうかを判断するのは、依然として組織の役目です。
ガーツ氏は、これによって人間の判断が適用される場面が変わると指摘します。組織がAI導入を拡大するにつれて、人間の役割は「コードをレビューする」ことから「何を、どのように構築するかを統治する」ことへと、より上流工程へ移っていくというのです。
専門家らは、企業はAIベースのコードレビューツールを既存のセキュリティ管理策の「置き換え」として扱うのではなく、現在使用している管理策を維持し続けるべきだという点で一致しています。コンパイル、型チェック、単体・結合テスト、静的アプリケーションセキュリティテスト、ソフトウェア構成分析、機密情報スキャン、インフラチェックといった手法は、それぞれ異なる種類のセキュリティ上の欠陥を検出できます。
「現在私たちが持っているすべての管理策は、引き続き使い続けなければなりません。ただし、それに加えて、エージェント型のセキュリティテストという新たな能力も手に入ったということです」と、ワイソパル氏はCSOに語ります。同氏は、決定論的なツールとAIベースのセキュリティテストは互いを補完し合う関係にあると見ています。それぞれが、もう一方では見逃してしまう問題を発見できるからです。
しかし最終的には、セキュリティ上重要な変更については、対象となるコードとシステム全体におけるその役割を理解している開発者の管理下に置かれ続けるべきです。
「人間を介さずにAIにソフトウェアをデプロイさせることはないはずです。それなのに、なぜエンジニアを飛ばしてしまうような『自動修復』パッチ適用を求めるのでしょうか」とクワック氏は問いかけます。「変更のマージとそのテストという重要なステップは、引き続きコードの所有者が責任を持つべきです」
