AIが書いたコードは「動く」が「安全」とは限らない——実測が示す、レビューで見るべき2箇所

AI が書いたコードが動かなくて困る、ということはほぼ無くなりました。構文エラーで止まる場面を最近見た記憶がある方は、少ないのではないでしょうか。

ところが「動く」ことと「安全である」ことは、別々に伸びています。100 を超える大規模言語モデルを 4 年間追跡した調査によると、構文の正確性はほぼ 100% に達した一方、セキュリティの合格率は 2 年間ほぼ横ばいでした。

この記事では、その実測データから レビューでどこを重点的に見るべきか を整理します。結論を先に書くと、危険は均等に散らばってはいません。特定の 2 種類に集中しています。

構文はほぼ解決した。セキュリティはしていない

セキュリティ企業 Veracode は、80 のコーディングタスクを多数のモデルに解かせ、生成されたコードに既知の脆弱性が含まれるかを測り続けています。2026 年 7 月に公開された最新版では、累計 100 以上のモデルが対象になりました。

構文については、レポートが「事実上解決済み（Syntax is effectively solved）」と表現しています。実感とも合うはずです。

一方でセキュリティ合格率は 55% から 56% へ、2 年間で 1 ポイントしか動いていません。裏を返せば、セキュリティが関係するタスクのうち約 44% で、既知の脆弱性がコードベースに入るということになります。

この 2 つは同じ「コードを書く能力」に見えて、伸び方がまったく違いました。そしてギャップは開き続けています。

無視できないのは、AI が全コミットの約半分を書いているという前提が同じレポートに書かれていることです。合格率が横ばいのまま、AI が書く量だけが増えている。掛け算の結果として、パイプラインに入る脆弱性の絶対量は増えます。

危ないのは全体ではなく、特定の 2 種類

ここからがこの記事の本題です。

「AI が書くコードは危ない」という言い方をよく見かけますが、実測値を見ると危険度は均等ではありません。

5 倍の開きがあります。SQL インジェクションは 8 割以上のケースで防げているのに、XSS とログインジェクションはほとんど素通しです。

なぜこの偏りが生まれるのか

レポートは原因分析までは踏み込んでいないので、ここからは実装者としての解釈になります。ただ、この偏りには納得のいく理由があります。

SQL インジェクションには定型解があります。 プレースホルダ（プリペアドステートメント）を使う、という答えが 1 つに定まっており、学習データにも正しい実装が大量に存在します。AI が得意とする「よくあるパターンの再現」がそのまま正解になる領域です。

XSS はそうなりません。 同じ文字列でも、埋め込む先が HTML のテキストノードなのか、属性値なのか、JavaScript の中なのか、URL なのかでエスケープの方法が変わります。正解が文脈によって変わるため、パターンの再現では対応しきれません。

ログインジェクションはさらに厄介です。 そもそも「ログに入れる値も検証が要る」という発想自体が広く共有されていません。脅威として認識されていないものに対して、対策コードが書かれることはありません。学習データに無いものは出力されない、という素直な帰結です。

レビューの配分をどうするか

ここから導ける実務的な結論はシンプルです。

レビューに使える時間は有限です。全部を等しく見ようとすれば、どれも浅くなります。AI が構造的に苦手な領域に人の目を寄せるほうが、同じ工数で防げる件数は増えます。

具体的には、出力を伴う箇所（XSS）とログ出力（ログインジェクション）を優先して見る。SQL 周りは静的解析ツールに任せる比重を上げてよい、という判断ができます。

次のモデルを待っても解決しない

「今のモデルがまだ未熟なだけで、次の世代では改善するのでは」という期待は自然です。実際、構文の正確性はそうやって伸びてきました。

しかしデータはこれを否定しています。

• 最新データで最高だった GPT-5.5 で 68%
• モデル全体の平均は 56%
• 大規模モデルで 53%、中規模・小規模でもそれぞれ 51%。規模による差はほとんどない

新しいモデルが出るたびに数ポイント動くことはあっても、50% 台から抜け出す構造変化は 2 年間起きていません。

理由を考えると、これも腑に落ちます。構文の正しさは「正解が 1 つに定まる」問題です。コンパイルが通るか通らないかで、答え合わせができます。学習でも評価でも扱いやすい。

一方セキュリティは、先ほどの XSS の例のように文脈によって正解が変わり、しかも「間違っていても動いてしまう」。動作テストでは検出されず、フィードバックが返らない。次トークン予測の最適化で伸ばしにくい性質を持っています。

つまり、待つ戦略は成立しません。 レビューと検査の体制は、今あるモデルを前提に組む必要があります。

言語によっても差がある

もう 1 つ、実務判断に効くデータがあります。言語ごとの差です。

Java のセキュリティ合格率が、他の言語に比べて明確に低くなっています。

Java だけが突出して低い。レポートはこれを、レガシーコードのパターンを過剰に学習したためと分析しています。

長く使われている言語ほど、インターネット上には古い書き方のコードが大量に残ります。AI はそれも学習します。結果として、現在では推奨されない実装を再現してしまう。言語の優劣ではなく、学習データの構成の問題です。

なお、上記の表は 2026 年 3 月時点のデータです。言語別の内訳は 2026 年 7 月版では公表されておらず、Java についてのみ 30% への改善が示されています。ピンポイントの数値というより、傾向として受け取るのが妥当な数字です。

実務でどう組み込むか

ここまでの内容を、明日から使える形にまとめます。

1. 人が見る箇所を絞る

XSS とログインジェクションを優先します。どちらも文脈依存の判断が必要で、機械的な検出が効きにくい領域です。逆に言えば、人が見る価値が最も高い場所でもあります。

2. 静的解析を PR に組み込む

SQL インジェクションや暗号アルゴリズムの選択は、パターンが定型的なので自動検出が効きます。失敗率が低い領域とはいえゼロではないので、ここは機械に任せて網を張ります。

人が見る／機械が見るの役割分担を、脆弱性の性質で分けるのが要点です。

3. プロンプトで先に指定する

生成時に「XSS 対策を含めて」と明示すると、出力は改善します。ただしこれは指定を忘れた箇所は対策されないことの裏返しでもあります。個人の記憶に依存させると、必ず漏れます。

4. セキュリティ要件を仕様に書く

3 を仕組みにする方法が、これです。プロンプトで都度指定するのではなく、プロジェクトの仕様として明文化しておく。

この考え方については、バイブコーディング vs スペックドリブン開発——プロトタイプでは正解でも、商用開発に「仕様書」が要る理由で詳しく書いています。AI に対して「何を作るか」を仕様として渡す話ですが、「どう守るか」も同じ仕様の一部として扱えます。

まとめ

• 構文はほぼ解決した（約 50% → ほぼ 100%）が、セキュリティは 2 年間ほぼ横ばい（55% → 56%）。同じ「コードを書く能力」でも伸び方が違う
• 危険は均等ではない。XSS 85%・ログインジェクション 88% に対し、SQL インジェクションは 17%と 5 倍の開きがある
• 偏りの理由は「正解が 1 つに定まるかどうか」。定型解のあるものは AI も再現でき、文脈依存のものは苦手
• モデルの世代交代を待つ戦略はデータが否定している。最高で 68%、規模を上げても 51〜53% の範囲
• レビューは「全部見る」ではなく、AI が構造的に苦手な 2 種類に寄せる

AI にコードを書かせること自体は、もう前提です。問われているのは、どこに人の目を残すかの設計だと考えています。

出典

• Veracode「2026 GenAI Code Security Report」（2026年7月28日）
• Veracode「2026 GenAI Code Security Report」レポート本体
• Veracode「Spring 2026 GenAI Code Security Update」（2026年3月24日・言語別データ）

※ 数値は 2026 年 8 月時点で公開されている情報に基づきます。