AI生成コードが、もはや周縁ではなくなった。本番コードに占める比率が上がるほど、AppSecの前提も変わる。問題は「生成AIが間違う」ことではない。見た目は正しいが、制御フローや前提条件が壊れているコードが、レビューとテストをすり抜けやすい点にある。

2025年10月23日、TechRadarはAikido Securityの調査結果として、AI生成コードが本番コードの24%を占め、69%の組織がAI生成コード由来の脆弱性を経験し、深刻インシデント（重大な侵害）に結び付いたケースが「5社に1社」であると報じた。さらにCycodeは2026年2月5日更新の解説で、最新モデルを用いても62%のAI生成コードに設計欠陥または既知の脆弱性が含まれる可能性を指摘し、言語別ではJavaが72%の失敗率、脆弱性タイプ別ではXSSが86%という高い失敗率を挙げている。

本稿は、CycodeおよびAikido Securityの調査（および両者が参照するVeracode等の評価）を手掛かりに、「正しさの幻想（illusion of correctness）」が生まれるメカニズムと、組織として取るべき可視化・ガードレール戦略を整理する。

1. 数字で見る「AI生成コード24%時代」のAppSec負債

まず前提として、各調査は母集団や測定方法が異なる。したがって単純比較ではなく、リスクがどこに集中するかを見るべきである。それでも、方向性は揃っている。

論点 示唆 数字の例（出典）
普及（量の問題） AI生成コードが「例外」ではなく、レビューと運用の前提に入る。 本番コードの24%（Aikido調査として報道, 2025-10-23）
検出（質の問題） 脆弱性が統計的に観測される水準に達している。 69%がAI生成コード由来の脆弱性を経験（Aikido, 2026 / 報道）
安全性（設計の問題） 最新モデルでも「設計欠陥・既知の脆弱性」混入が高率で残る。 62%が設計欠陥または既知の脆弱性を含む（Cycode, 2026-02-05）
言語差（工程の問題） 言語・フレームワークにより、安全に書ける確率が大きく変わる。 Javaは72%がセキュリティテスト不合格（Veracode, 2025 / Cycode, 2026）
脆弱性タイプ差（レビューの問題） 「見た目が整った」Webコードほど、注入系が残りやすい。 XSS 86%・ログ注入88%（Cycode, 2026-02-05）

重要なのは、AI生成コードが増えるほど、AppSecが抱えるリスクが「脆弱性の個別検出」から「生成物の出自と前提条件の管理」へ移る点である。従来のSAST/DASTは、コードと実行結果の断面を捉える。しかしAI生成コードでは、断面が「整って見える」確率が高い。ここにブラインドスポットが生まれる。

2. AppSecブラインドスポットは「脆弱性」ではなく「制御フローの欠落」から始まる

AI生成コードが危険なのは、単にインジェクションが混ざるからではない。最大の特徴は、コードの表層（命名、コメント、例外処理、ユニットテストの体裁）が整いやすく、仕様と脅威モデルが暗黙に抜け落ちる点である。これが「正しさの幻想」を強化する。

典型的な失敗は次の形を取る。

  • 前提条件の未表明: 「この関数は管理者のみが呼ぶ」「この入力は正規化済み」といった前提がコードに刻まれず、境界が破れる。
  • 制御フローの希薄化: 認可チェックが主要経路にしかなく、例外系・リトライ系・バックドア的経路に抜け道が残る。
  • データフローの誤同定: どの値が信頼境界を跨ぐかの把握が甘く、エンコードやサニタイズの位置がずれる。
  • 状態機械の破綻: ワークフロー（支払い、承認、解約など）の「順序制約」が欠け、ビジネスロジックのバイパスが生まれる。

これらは「脆弱性スキャンで検出できる」場合もあるが、設計欠陥として現れることも多い。Cycodeが示す62%という数字は、まさにこの層の問題が残ることを示唆している。

3. 「見た目が正しい」AI生成コードのリスクパターン（レビュー観点）

AppSecが対処すべきは、AI生成コードの一般的な欠陥を列挙することではなく、人間レビューが誤判定しやすい形を特定し、検査を工程に埋め込むことである。実務上のパターンを4つに整理する。

パターンA: “認可の抜け”が例外系に潜む

主要経路では認可チェックがある一方、エラーリカバリ、デバッグ用分岐、レガシー互換の分岐にチェックがない。ユニットテストは主要経路を通るため通過するが、攻撃者は例外系を叩く。

パターンB: エンコードの位置ズレ（XSS/ログ注入が残る）

入力サニタイズの意図はあっても、出力コンテキスト（HTML/属性/URL/JS文字列）に適合していない。ログも同様で、改行・制御文字・構造化ログのフィールド境界が守られず、ログ注入が成立する。Cycodeが引用する評価では、XSS 86%・ログ注入88%という高い失敗率が報告されている。

パターンC: “安全なデフォルト”の欠落（設定と依存関係）

AI生成コードは「動く」ことを優先し、TLS検証の無効化、CORSの過剰許可、デバッグフラグの残存など、環境依存の設定を安易に許容しがちである。SASTが見逃す場合、運用で初めて露呈する。

パターンD: 仕様の言い換えによる設計崩壊（品質問題がセキュリティに波及）

要件が曖昧なとき、AIは「それっぽい実装」を埋める。結果として、入力の境界条件、並行性、トランザクション境界が崩れる。これはコード品質（正しさ、保守性）問題として発生し、後からパッチで直しづらい。

4. 組織的対策: 可視化とガードレールを“AI前提”で組み直す

対策の要点は3つである。可視化（どこがAI生成か）、ガードレール（生成の出口を狭める）、監査可能性（誰が何を承認したか）である。個々のツール導入より、運用設計が支配的になる。

4.1 可視化: 「AI生成」をデータとして扱う

  • コミットメタデータ: AI支援の有無、使用ツール、プロンプト要約をPRテンプレートに必須項目として追加する。
  • 差分ベースの検知: 大きな差分、未知の依存追加、認可/入力処理周辺の変更にフラグを立てる。
  • リスクラベル: 「認証・認可」「入力/出力」「暗号」「権限境界」「外部I/O」など、攻撃面に直結するモジュールへ優先的にラベルを付ける。

Cycodeの2025年11月5日付プレスリリースは、AIコードの可視性不足（81%が可視化できていない）を“Shadow AI”問題として位置付ける。可視化は、検出精度の議論以前の前提である。

4.2 ガードレール: 「自由入力」から「制約付き生成」へ

  • セキュア・テンプレート: 認可、入力検証、監査ログを組み込んだテンプレート/スキャフォールドを提供し、生成AIには“穴のない骨格”を埋めさせる。
  • 禁止パターンの自動ブロック: TLS検証無効化、危険なデシリアライズ、`eval`相当、広すぎるCORSなどをPRゲートで拒否する。
  • 言語別の重点: Javaのように失敗率が高い領域は、手動レビューの最低要件（セキュリティ設計レビュー、認可経路の網羅確認）を引き上げる。

4.3 監査可能性: 「誰が承認したか」を残す

AI生成コードの事故は、責任の押し付け合いになりやすい。Aikidoの調査報道でも、インシデント時に「誰の責任か」が曖昧になり得る点が強調されている。したがって、PRでの承認者、セキュリティ例外の承認者、例外期限を明確にし、後追い可能にする必要がある。

5. 実行計画: 30/60/90日で作る“AI時代のAppSec運用”

ツール追加は最後でよい。まず運用の観測可能性を作り、その上でガードレールを狭める。

30日: 可視化の最小実装

  • PRテンプレートに「AI支援の有無」「生成範囲（ファイル/関数）」「レビュー観点（認可/入出力/暗号/外部I/O）」を追加する。
  • 変更検知ルール（認可/入力/外部I/O/依存追加）に対し、必ずセキュリティレビューを要求するCODEOWNERSを設定する。

60日: ガードレールをコード化

  • 禁止パターン（TLS無効化、危険API、過剰CORS等）の静的ルールをCIに組み込み、ブロッキング運用に移行する。
  • XSS/ログ注入を意識し、出力コンテキストごとのエンコード方針をフレームワーク標準に寄せる（独自実装を減らす）。

90日: メトリクスと責任境界の固定

  • AI支援コード比率、AI支援コード由来の指摘件数、修正リードタイム、例外承認件数をKPI化する。
  • 重要系（認証/認可/決済/権限境界）に「設計レビュー必須」を適用し、生成AIの自由度を制約する。

AI生成コードの増加は不可逆である。したがって問うべきは「使うか/禁止するか」ではなく、生成物の出自を観測し、前提条件をコードと運用で固定できるかである。正しさの幻想を壊すのは、個人の注意力ではなく、工程に埋め込まれたガードレールである。

FAQ

AI生成コードは原則禁止すべきか

禁止は現実的でない場合が多い。重要なのは「どこまでをAIに任せ、どこからを人間が設計責任として引き取るか」を明文化し、認証・認可・境界処理など高リスク領域では制約付き生成へ移行することである。

62%や86%といった数字は、そのまま自社に当てはまるのか

母集団・課題設定・評価方法に依存するため、そのままの適用は危険である。ただし、AI生成コードが「動くのに安全ではない」傾向を持つこと、注入系や設計欠陥が残りやすいことは複数ソースで整合している。自社では、可視化とメトリクス整備により実測へ落とすべきである。

SAST/DASTを強化すれば解決するか

一部は改善するが、設計欠陥やワークフロー破綻は検出しにくい。AI生成コードでは「仕様と境界条件の欠落」が根にあるため、テンプレート化、レビュー観点の固定、承認フローの監査可能性といった運用設計が必要である。

可視化は具体的にどう実装すべきか

最小構成は、PRテンプレートでの自己申告と、差分ベースのフラグ付け（認可・入出力・外部I/O・依存追加）である。そこから、AI支援の範囲をラベルとして蓄積し、事故時に追跡できる状態にすることが第一歩となる。

参考文献