AIが書いたコードの脆弱性：安全性テストの45%が不合格という研究と、開発現場の防御策

AIでコードを書くことが当たり前になりつつある今、押さえておくべき事実があります。それは、AIは「動くコード」を書くのは得意でも、「安全なコード」を書くのは必ずしも得意ではないということです。Veracodeが2025年に公表した調査では、100以上の大規模言語モデル（LLM）が生成したコードのうち、45%が安全性テストに不合格となり、OWASP Top 10に該当する脆弱性を含んでいました。

さらに、USENIX Security 2025で発表された研究では、AIがコードの中で存在しないパッケージ名を提案する「パッケージの幻覚」が広く確認されています。攻撃者がその名前で悪意のあるパッケージを公開すれば、AIの提案をそのまま使った開発者が攻撃を受けることになります。本記事では、これらの研究データを正確に読み解いたうえで、開発現場と、開発を委託する発注側が取るべき防御策を解説します。

研究データ1：AIが生成したコードの45%が安全性テストに不合格

Veracodeは、100以上のLLMに、Java、Python、C#、JavaScriptでコードを書かせ、そのセキュリティを検証しました。

この調査は、既知の脆弱性が生じやすい課題を意図的に設定したうえでの検証です。そのため、「AIが書いたあらゆるコードの45%に脆弱性がある」という意味ではありません。しかし、特に指示をしなければ、AIは安全性より「動くこと」を優先したコードを書きやすいという傾向は、実務でも重く受け止めるべきです。

研究データ2：存在しないパッケージをAIが提案する

USENIX Security 2025で発表された研究（Spracklenら）は、コード生成で使われる16のLLMを使い、2つのプログラミング言語で57万6,000件のコードを生成して分析しました。

この問題が危険なのは、攻撃に悪用できるからです。AIがよく提案する「存在しないパッケージ名」を攻撃者が先回りして登録し、悪意のあるコードを仕込んでおけば、AIの提案どおりにパッケージをインストールした開発者の環境が侵害されます。この手口は「スロップスクワッティング」と呼ばれ、ソフトウェアのサプライチェーン攻撃の新しい形として警戒されています。

あわせて読みたいEUサイバーレジリエンス法（CRA）とは？2026年9月に始まった脆弱性報告義務と日本企業の備え

なぜAIは脆弱なコードを書きやすいのか

特に3つ目の「文脈の不足」は重要です。認証、権限、入力の検証といったセキュリティの要は、業務の前提（誰が、何に、どこまでアクセスしてよいか）によって決まります。AIはこの前提を知らないため、人が明示的に伝え、確認しなければなりません。

AI時代の開発パイプラインに入れる防御策

AIを使った開発で脆弱性を防ぐには、個人の注意力に頼るのではなく、開発の流れそのものに防御を組み込むことが重要です。

レビューは「どこを見るか」を決めておく

AIが生成するコードの量が増えると、すべての行を同じ深さでレビューすることは現実的ではありません。次のような部分に、レビューの力を集中させましょう。

• ログイン、セッション、パスワードの扱い
• 利用者ごとのアクセス権限の確認（他人のデータにアクセスできないか）
• 外部からの入力（フォーム、API、ファイルのアップロード）の検証
• データベースへの問い合わせの組み立て方
• 画面に表示する値のエスケープ
• 新しく追加された依存パッケージ
• ログやエラーメッセージに機密情報が含まれていないか

開発を委託する発注側が確認すべきこと

開発を外部に委託している場合、委託先がAIをどのように使い、どう安全性を確保しているかを確認することが重要です。

AI時代の委託先の選び方はAI時代のオフショア開発はどう変わるか、AIエージェントの設計の注意点はAIエージェントのセキュリティリスクと対策もあわせてご覧ください。

FlowStack Labsの見解：AIは脆弱性を「作る速さ」と「見つける速さ」の両方を変えた

AIによって、コードを書く速さは大きく上がりました。それは同時に、脆弱性が作り込まれる速さも上がったことを意味します。一方で、攻撃者もAIを使って脆弱性を探し、悪用のコードを書くようになっています。脆弱性が公開されてから悪用されるまでの時間が短くなっている現実は、脆弱性診断とはでも解説しました。

この状況で、私たちが最も重要だと考えているのは、「速く書く仕組み」と「速く確かめる仕組み」を同時に整えることです。AIで開発のスピードを上げたのに、確認の仕組みが年に1回の診断のままでは、リスクだけが膨らみます。自動検査をCIに組み込み、人のレビューを信頼の境界に集中させ、AIの利用を記録する。この3つを揃えて初めて、AIによる開発の速さを安全に活かせます。

また、セキュリティ要件を明確にしたプロンプトのテンプレートや、承認済みのパッケージの一覧は、一度作れば組織全体で再利用できる資産になります。AIを使いこなす組織とは、AIに任せる範囲と、人が責任を持つ範囲を明確に設計できる組織だと考えています。

よくある質問

まとめ

• Veracodeの調査では、AIが生成したコードの45%が安全性テストに不合格となり、Javaでは72%に達しました。
• モデルが新しく大きくなっても、セキュリティの性能は横ばいだったと報告されています。
• USENIX Security 2025の研究では、AIが存在しないパッケージ名を提案する問題が広く確認され、スロップスクワッティングのリスクがあります。
• 防御策は、セキュリティ要件を含めた指示、依存パッケージの確認、CIでの自動検査、信頼の境界に集中したレビュー、AI利用の記録です。
• 開発を委託する場合は、委託先のAI利用のルールと検査の仕組みを確認しましょう。

AIを使った開発の安全な進め方、開発パイプラインへの自動検査の組み込みは、FlowStack Labsの無料相談でご相談いただけます。

参考資料

• Veracode「2025 GenAI Code Security Report」
• USENIX Security 2025「We Have a Package for You! A Comprehensive Analysis of Package Hallucinations by Code Generating LLMs」
• OWASP Top Ten