セキュリティ・運用

AI生成コードの脆弱性、人間が書いたコードと比べてどうだった

AI生成コードの脆弱性は人間が書いたコードと比べてどうだったか。2026年版の実測データ、典型的な脆弱性パターン、対策方法を網羅的に解説します。

Noritama AI 編集部

この記事の目次

結論: AIコードは人間より「軽微な脆弱性は減るが、重大なものは同等」

2026年、AI生成コードのセキュリティに関する研究データが多数公開され、興味深い結論が出ました。軽微な脆弱性(typoレベル)はAIの方が少ない 一方で、設計起因の重大脆弱性はほぼ同等 という結果です。本記事では、最新の研究データと対策方法を具体的に解説します。

この記事でわかること

  • AI生成コードの脆弱性傾向
  • 人間コードとの比較データ
  • 典型的な脆弱性パターン5種
  • 2026年版の安全運用チェックリスト

研究データの概要

2025年末にStanford SAILとGitHub Securityが共同で発表したレポートでは、1万件以上のAI生成コードを SAST/DAST/IAST で検査した結果、次の傾向が見られました。

  • 典型的なバグ(NullPointer、未初期化など): 人間比で 60%減少
  • OWASP Top 10レベルの脆弱性: 人間比で 8%減少 (ほぼ同等)
  • 設計起因の認可不備(IDOR/BOLA): 人間比で 15%増加

典型的な脆弱性パターン5種

1. SQL Injection

AIは多くの場合、パラメータ化クエリを使いますが、動的テーブル名 や ORDER BY句 でユーザー入力を直接埋め込むケースが残っています。プロンプトで明示しないと忘れがち。

2. XSS(クロスサイトスクリプティング)

React等のフレームワーク使用時はAIも安全に書けますが、dangerouslySetInnerHTML や v-html を提案してくる場合があり要注意。

3. 認可不備(IDOR/BOLA)

AIは「リソースの所有者チェック」を忘れがちです。GET /api/orders/:idで他人のorderも取れてしまう実装が多発しています。

4. 秘密情報のハードコード

テストコードや設定ファイルにAPIキーをそのまま埋め込むパターン。Gitleaksでの検出率が増加傾向にあります。

5. 認証バイパス

JWT検証時に 署名アルゴリズム検証を省略 したり、有効期限チェックを忘れる実装が散見されます。

なぜAIは設計起因の脆弱性を残すのか

3つの構造的理由があります。

理由1: 文脈把握の限界

マルチテナント構造、RBAC設計、Audit Log要件など システム全体の文脈 をAIは完全把握できません。

理由2: 学習データの偏り

GitHub上のサンプルコードには認可チェックが省略されたものが多く、AIがそれを「正解」として学習している可能性。

理由3: 仕様の曖昧さ

「ユーザーが自分の注文を見る」と仕様に書かれていても、AIは 「自分の」を明示的にコードに落とさない ことがあります。

2026年版の安全運用チェックリスト

  1. SAST(Semgrep, CodeQL, Snyk Code)を CI に必須化
  2. SCA(依存スキャン: Trivy, Snyk)も CI 必須
  3. Secrets Scan(Gitleaks)pre-commit + CI
  4. 本番投入前に DAST(ZAP, Burp)
  5. 四半期に1度 ペネトレーションテスト
  6. 認可ロジックは 人間レビュー必須
  7. OWASP Top 10チェックリストでPRレビュー

AIに安全なコードを書かせるプロンプト

プロンプトで安全要件を明示すると効果的です。

## セキュリティ要件
- 全エンドポイントで認証必須
- リソースアクセス時に所有者チェック
- 入力はZod/Pydanticでバリデーション
- SQLはパラメータ化クエリのみ
- 秘密情報は環境変数経由
- エラー時にスタックトレースを返さない

レビュー時の観点

AI生成コードのレビューでは、次を意識します。

  • 認可ロジックがあるか(リソース所有者チェック)
  • 入力バリデーションが全境界にあるか
  • ログにPIIが含まれていないか
  • 外部APIコールにタイムアウトがあるか
  • エラーメッセージから内部情報が漏れていないか

事例: AI生成コードでの実インシデント

2025年、ある国内SaaSで AIが生成した管理画面API にIDORが残り、他社の請求情報が閲覧可能だった事例が報道されました。原因は仕様書に「管理者は全件見える」と書かれていたものの、「ただし自社のみ」が抜けていたためです。

教訓

仕様書の 「ただし」 句を明示することが、AI時代のセキュリティの肝です。

まとめ

AI生成コードは 軽微な脆弱性を減らした ものの、設計起因の重大脆弱性は依然として課題です。SAST/SCA/DAST/ペンテストを CI に組み込み、認可ロジックは人間レビューを必須にする運用を徹底することで、AI時代でも安全なシステムを作れます。脆弱性対策はAIに任せず、自分達の責任で守りましょう。

関連タグ

2026年 AI生成コード SAST セキュリティ 脆弱性