直接回答： Veracodeは2025年のGenAIコードセキュリティレポートで、AIが生成したコードサンプルの45%がセキュリティ上の欠陥を持ち込んだ——安全だったのは55%にすぎない——と報告し、この比率はモデルが大きくなっても改善していないとしています。最も成績が悪かったのはJava（安全率29%）、最も良かったのはPython（62%）でした。結論はAIの利用をやめることではありません。生成の速さは安全性と同義ではないのだから、AIが生成したコードも他のコードと同じセキュリティスキャンとレビューを通さなければならない、ということです。
AIコーディングツールはいまやほぼ普遍的です——Veracodeが引用するGitHubの2024年開発者調査では、開発者の97%が利用経験ありとされています。そこで一つの問いが切実になります。それらが生み出すコードは、既定で信頼できるほど安全なのか。Veracodeの調査は、居心地は悪いものの有用な答えを与えてくれます。
Veracodeが測定したこと
Veracodeの2025年の分析は、100を超える大規模言語モデル、80のコーディングタスク、4つのプログラミング言語、4種類の一般的な脆弱性を対象としました。目玉の結果はこうです。安全だったAI生成コードはわずか55%、つまり45%が既知のセキュリティ欠陥を持ち込んだ。
強調すべき発見が二つあります。第一に、この不安全さは古くて弱いモデルに集中しているわけではありません——Veracodeによれば、モデルが構文的に正しいコードの生成において大幅に上達しても、セキュリティ合格率はおおむね横ばいのままでした。大きく新しいことは、安全であることを意味しませんでした。第二に、リスクは言語と脆弱性クラスによって大きく異なります。
| 言語 | 報告されたセキュリティ合格率 |
|---|---|
| Python | 62% |
| JavaScript | 57% |
| C# | 55% |
| Java | 29% |
脆弱性タイプ別では、Veracodeはモデルが SQL injection をおおむね妥当に処理する（約80%が安全）一方、クロスサイトスクリプティング（XSS）と log injection には大きく苦戦し、大半のケースで安全でないコードを生成したと報告しています。
なぜAIはセキュリティでとりわけつまずくのか
レポートはこの差を三つの構造的な原因に帰しています。より大きなモデルだけでは解決しないため、理解しておく価値があります。
- 学習データの汚染。 モデルは安全なパターンと安全でないパターンの両方を含む公開コードから学ぶため、どちらも「普通」に見えてしまう。
- セキュリティ文脈の欠如。 関数を生成するモデルは、アプリケーションの信頼境界をほとんど把握していないため、動作はするが制御が抜け落ちたコードを生み出す。
- 限られたデータフロー推論。 ある変数が信頼できない入力を保持しているかどうかの判断には、現在のモデルが安定して行えない解析が必要になる。
機能的に正しいことと安全であることは別の目標であり、今日のモデルは前者に最適化されています。
「45%」から導けないこと
衝撃的な統計は過剰反応を招きます。この数字を誠実に扱うために、次を押さえておきましょう。
- 本番でAIを使って書かれたコードの45%が悪用可能だという意味ではありません。これは特定のタスクと脆弱性タイプにわたる統制されたテストです。
- 特定の単一ツールが45%不安全だという意味でもありません。結果はモデル、プロンプト、言語によって異なります。
- 人が書いたコードに欠陥がないという意味でもありません。AIがセキュリティレビューの必要性をなくすわけではない、ということです。
- これはアプリケーションセキュリティ企業によるベンダーの調査です。方法論は妥当で方向性も他の研究と一致しますが、正確な数値はVeracodeのテスト設計に固有のものです。
擁護できる読み方は方向的で、しかも力強いものです。AIが生成したコードの相当な割合にセキュリティ欠陥があり、その割合はひとりでに縮んではいない。
エンジニアリングチームがすべきこと
以上はAI支援に反対する論拠ではありません。AIの出力を「検証されるまで信頼しない」ものとして扱うべきだという論拠です——成熟したチームがリポジトリに入るあらゆるコードを、すでにそう扱っているのと同じことです。
- すべてをスキャンする。 AIが生成したコードには、インシデントの後ではなくマージの前に SAST（必要なら DAST も）を実行する。
- 人間のレビュー関門を維持する。 セキュリティに関わる変更にはレビューを必須とし、生成量の多さで監督を薄れさせない。
- 弱点を注視する。 出力処理（XSS）、ロギング、そしてチームが出荷していてスコアの低かった言語には、追加の精査を割く。
- 依存関係を管理する。 AIは古い、あるいは存在しないパッケージを提案しうる。検証してバージョンを固定する。
- 記録する。 AI支援による変更とそのレビューの監査証跡を残す。
これは本サイトのパイロット方法論の背後にある規律や、AIコーディングパイロットのスコアカードの厳格なセキュリティ関門と同じものです。また、私たちのOWASPに沿ったチェックリストにあるエージェント向けの統制とも補完し合います。あちらはエージェントが何をできるかについての記事で、こちらはそれが書き出すコードについての記事です。
マネージドプラットフォームが役立つ場面
個々のノートPC上での場当たり的なAI利用は、「すべてをスキャンしてレビューする」を徹底しにくくします。AIの作業をマネージド環境とレビューワークフローに通すプラットフォームなら、セキュリティ関門は期待ではなく既定になります。MonkeyCodeの公開資料は、自動コードレビューと、AI変更を取り巻くタスク・アンド・レビューのワークフローを説明しています。これらの統制を徹底するためのインフラとして捉え、現在の機能は製品ドキュメントで確認してください。
まとめ
Veracodeの45%は健全な現実確認です。AIは大量のコードを書き、そのかなりの部分は既定では安全でありません——モデルがどれほど有能に感じられようとも、です。取るべき対応は禁止でも盲信でもありません。AIが生成したコードを他のすべてと同じスキャンとレビューに通し、既知の弱点を注視し、意志の力ではなくワークフローによってそれらの関門を守ることです。
出典の範囲： 45%という数字、言語別の合格率、そしてセキュリティがモデルの規模とともには改善していないという観察は、いずれもVeracodeの2025年GenAIコードセキュリティレポートおよび付随ブログによるもので、2026年7月20日に確認しました。Veracodeはアプリケーションセキュリティのベンダーであり、これらの統計は同社のテスト方法論を反映した方向的な証拠であって、あらゆるツールやコードベースを普遍的に測定したものではありません。