AI が書いたコードのレビューが、だんだんつらくなっていませんか。
量が増えたぶん、1 件あたりに割ける時間は減ります。「一応ざっと見た」で通してしまう回数も増えているはずです。
100 以上の LLM を 4 年間追跡した Veracode の調査を読むと、この状況で全部を均等に見るのは筋が悪いことが分かります。危険は均等に散らばっていないからです。
データそのものと背景は本家記事にまとめました。
AIが書いたコードは「動く」が「安全」とは限らない。実測が示す、レビューで見るべき2箇所
この記事では、そのデータを受けてレビューをどう組み直すかを書きます。
前提：セキュリティだけ伸びていない
まず出発点になる事実です。
構文の正確性はほぼ 100%（レポートの表現では「事実上解決済み」）に達しました。一方でセキュリティ合格率は 55% → 56% と、2 年間ほぼ横ばいです。
しかも同じレポートに、AI が全コミットの約半分を書いていると書かれています。合格率が変わらないまま量だけ増えるので、混入する脆弱性の絶対量は増えます。
「レビューがつらい」のは気のせいではなく、構造的にそうなっています。
危険は偏っている
ここが本題です。脆弱性の種類ごとに失敗率を見ると、はっきり差が出ます。
| 脆弱性 | 失敗率 |
|---|---|
| 不適切な暗号アルゴリズム | 13% |
| SQL インジェクション | 17% |
| XSS | 85% |
| ログインジェクション | 88% |
5 倍の開きです。
レポートは原因分析までは書いていないので、ここからは実装者としての解釈です。ただ、この偏りには理由があると思います。
SQL インジェクションには定型解があります。 プレースホルダを使う、という答えが 1 つに定まっていて、学習データにも正しい実装が大量にあります。AI が得意な「よくあるパターンの再現」がそのまま正解になります。
XSS はそうなりません。 同じ値でも、埋め込む先で必要なエスケープが変わります。
// 同じ userInput でも、必要な処理が違う
element.textContent = userInput; // テキストノード → エスケープ不要
element.setAttribute("title", userInput); // 属性値 → 属性用のエスケープ
element.innerHTML = `<a href="${userInput}">`; // URL 文脈 → javascript: の除外も要る
正解が文脈で変わるので、パターンの再現では対応しきれません。
ログインジェクションはもっと厄介です。 そもそも「ログに入れる値も検証が要る」という前提自体が共有されていません。脅威として認識されていないものに、対策コードが書かれることはありません。
// AI が普通に書いてくるコード
logger.info(`login failed: ${username}`);
// username に改行を仕込まれると、ログに偽の行を作れる
// → 監査ログの汚染、SIEM の誤検知、調査の妨害
レビューをどう組み直すか
失敗率の差を、そのまま人と機械の分担に反映させます。
1. 機械に任せる領域を決める
SQL インジェクションと暗号アルゴリズムはパターンが定型的なので静的解析が効きます。失敗率も 13〜17% と低い。ここは SAST を PR に組み込んで、人は見ない前提にします。
CI に入れる分には既存のツールで足ります。重要なのは「低リスクだから外す」のではなく「機械で網を張るから人は外す」という組み方です。
2. 人が見る箇所を絞る
XSS とログインジェクションに寄せます。どちらも文脈依存の判断が必要で、機械では判定しにくい領域です。
レビュー観点を具体化するなら、こうなります。
- 出力の埋め込み先：テキストノードか、属性値か、URL か、JavaScript の中か
- ログに入る値の出所：ユーザー入力が直接入っていないか、改行や制御文字を落としているか
「セキュリティ観点でレビューする」だと漠然としますが、この 2 つに絞れば具体的な差分の話になります。
3. 言語で警戒度を変える
同じ調査の言語別データです（2026 年 3 月時点）。
| 言語 | セキュリティ合格率 |
|---|---|
| Python | 62% |
| C# | 58% |
| JavaScript | 57% |
| Java | 29% |
Java だけが突出して低い。レポートはこれをレガシーコードのパターンを過剰に学習したためと分析しています。
長く使われている言語ほど、ネット上には古い書き方が大量に残ります。AI はそれも学習します。言語の優劣ではなく、学習データの構成の問題です。
Java のコードを AI に書かせているなら、レビューの重みを上げる根拠になります。
4. プロンプトではなく仕様に書く
生成時に「XSS 対策を含めて」と書けば出力は改善します。ただしこれは書き忘れた箇所は対策されないということでもあります。個人の記憶に依存させると必ず漏れます。
プロジェクトの規約やルールファイルに、セキュリティ要件を仕様として書いておくほうが確実です。CLAUDE.md でも、社内のコーディング規約でも、AI が毎回読む場所であれば形式は問いません。
待っていても解決しない
「次のモデルで改善するのでは」という期待は自然です。構文の正確性はそうやって伸びました。
しかしデータは否定しています。
- 最高だった GPT-5.5 で 68%
- モデル全体の平均は 56%
- 大規模モデルで 53%、中規模・小規模でもそれぞれ 51%
規模を上げても変わっていません。
理由を考えると腑に落ちます。構文の正しさは正解が 1 つに定まり、コンパイルで答え合わせができる問題です。学習でも評価でも扱いやすい。
一方セキュリティは、文脈で正解が変わるうえに、間違っていても動いてしまう。動作テストでは検出されず、フィードバックが返りません。次トークン予測の最適化で伸ばしにくい性質です。
つまり、今あるモデルを前提にレビュー体制を組むしかありません。
まとめ
- 構文はほぼ解決したが、セキュリティ合格率は 2 年間ほぼ横ばい（55% → 56%）
- 危険は均等ではない。XSS 85%・ログインジェクション 88% に対し、SQLi は 17%
- 定型解があるものは機械に、文脈依存のものは人に割り振る
- Java は合格率 29% と低い。言語で警戒度を変える根拠になる
- モデルの世代交代を待つ戦略は、データが否定している
AI にコードを書かせること自体は、もう前提です。決めるべきはどこに人の目を残すかだと思います。
元記事
出典
- Veracode「2026 GenAI Code Security Report」（2026年7月28日）
- Veracode「Spring 2026 GenAI Code Security Update」（2026年3月24日・言語別データ）
※ 数値は 2026 年 8 月時点で公開されている情報に基づきます。