AI生成コードの脆弱性チェック｜4層スキャンの手順と無料ツール5選

結論: AI生成コードは人間が書くコードと異なるパターンの脆弱性を持ちます。認可の欠落、シークレットの直書き、存在しないパッケージへの依存（slopsquatting）などが典型です。これらはSCA→シークレット検出→SAST→DASTの4層スキャンをCIに組み込むことで、リリース前に検出できます。使うツールはすべて無料です。

この記事の要点:

• Veracodeが100以上のLLMを対象にテストした結果、AI生成コードの45%にOWASP Top 10の脆弱性が含まれていた（CSA Research Note経由、参照日: 2026-09-06）
• USENIX Security 2025の論文によると、LLMが生成するコードの5.2%（商用モデル）〜21.7%（OSSモデル）が存在しないパッケージを参照する。攻撃者がその名前を先に登録する「slopsquatting」が現実の脅威になっている（参照日: 2026-09-06）
• OWASPは「AI-Generated Code（AGC）」向けTop 10を提案中。従来のLLM Top 10が「LLMへのリスク」を扱うのに対し、AGCは**「LLMが生み出すリスク」**を体系化する動き（参照日: 2026-09-06）

対象読者: AIコーディングエージェント（Claude Code、Codex、Cursor、GitHub Copilot）を日常的に使うエンジニアやテックリード。特に「AIが書いたコードをそのまま本番に出して大丈夫か」と迷っている方

読了後にできること: 自分のGitHubリポジトリに4層スキャンのCIを追加し、AI生成コードの脆弱性を自動検出する仕組みを今日中に動かせる

この記事では、AI生成コードに特有の脆弱性パターンを整理したうえで、無料ツールだけで構築する4層スキャンの手順を解説します。自動スキャンで検出しにくい設計ミスの見つけ方はAI生成コードの人間レビュー5観点を、レビューツールの選定はAIコードレビューツール比較をそれぞれ参照してください。

AI生成コードに潜む5つの脆弱性パターン

AIが書くコードの脆弱性は、人間のミスとは分布が異なります。OWASPが提案中の「AI-Generated Code（AGC）Top 10」（https://github.com/OWASP/www-project-top-10-for-large-language-model-applications/issues/826、参照日: 2026-09-06）の分類と、Veracodeの実測結果を組み合わせると、次の5パターンが繰り返し現れます。

認可の欠落（IDOR / BOLA）

AIはAPIエンドポイントを正しく動く形で生成しますが、「このユーザーがこのリソースにアクセスしてよいか」の確認コードを省きがちです。OWASP AGCではこれをAGC-03（Insecure Code Patterns）に分類しています。動作テストでは正常に見えるため、手動レビューでも見逃しやすい脆弱性です。

入力検証の漏れ

フォームやAPIの入力値をそのままSQLクエリやシェルコマンドに渡すコードを生成するケースがあります。パラメータ化クエリを使わないSQLや、eval()に外部入力を渡す処理が典型です。

シークレットの直書き

APIキー、データベースパスワード、JWTシークレットをソースコードに直接書き込むパターンです。環境変数から読む処理を追加するよう指示しない限り、AIはサンプルコードのように値を埋め込みます。

幻覚パッケージ（slopsquatting）

AIが実在しないパッケージ名をimportするコードを生成する問題です。「slopsquatting」と呼ばれ、Python Software Foundationの開発者Seth Larson氏が命名しました。USENIX Security 2025の論文では、商用LLMで5.2%、OSSモデルで**21.7%**のコードが存在しないパッケージを参照すると報告されています。

攻撃者がその名前をnpmやPyPIに先回りして登録すれば、開発者がAI生成コードをそのまま実行した瞬間にマルウェアが動きます。Socket社の2026年4月の調査では、5つのフロンティアLLMが幻覚したパッケージ名のうち53個がnpmとPyPIに未登録のままで、攻撃者が先に登録すればマルウェア配布に使える状態だったと報告されています（https://socket.dev/blog/slopsquatting-targets-across-frontier-llms、参照日: 2026-09-06）。

安全でないデフォルト設定

デバッグモードの有効化、CORSの*設定、HTTPSの未強制など、開発時には問題にならないが本番では致命的な設定をAIが生成するケースです。AIは「動くコード」を最優先するため、セキュリティ設定は後回しになりやすい傾向があります。

なぜ「人間よりAIのコード」のほうが脆弱性が多いのか

AIコーディングツールは生産性を大きく高める一方で、セキュリティ面では固有のリスクを持っています。

GitHubは、Copilotが開発者のコード全体の**約46%を生成していると報告しています（参照日: 2026-09-06）。Veracodeが100以上のLLMをテストした結果では、AI生成コードの45%**にOWASP Top 10に該当する脆弱性が含まれていました。この数字は2025年から2026年にかけて改善していないと報告されています（CSA Research Note経由、参照日: 2026-09-06）。

コードの量が増え、レビューが追いつかない

Snykの調査によると、AI支援を受けた開発者はコミット速度が3〜4倍になる一方、セキュリティ上の問題を含むコードの生成速度も大幅に上がると報告されています（RSAC 2026 講演、参照日: 2026-09-06）。コードの増産速度にレビューが追いつかず、脆弱性が本番に流れやすくなります。

「動く」ことと「安全」は別の基準

AIの最適化目標は「コンパイルが通り、テストが通るコード」の生成です。認可チェック、レート制限、入力のサニタイズは動作に影響しないため、生成時に省かれやすい。機能的には正しいが安全ではないコードが量産される構造がここにある。

4層スキャンの設計 — SCA→シークレット→SAST→DAST

脆弱性の種類ごとに検出手法が異なり、1つのツールで全てをカバーすることは難しい。次の4層を順に通すことで、AI生成コードの脆弱性を網羅的に検出できる。

使うツールはすべて無料。各層の設定手順を順に解説する。

第1層: SCA — 依存パッケージと幻覚パッケージを検出する

SCA（Software Composition Analysis）は、プロジェクトが依存するパッケージの脆弱性を検出します。AI生成コードでは、通常のSCAに加えて幻覚パッケージの検出が必要です。

npm audit / pip audit で既知の脆弱性を洗い出す

Node.jsプロジェクトならnpm audit、Pythonならpip auditを使います。

# Node.js: 高・致命的な脆弱性だけをCI失敗にする
npm audit --audit-level=high

# Python: pip-audit（pipxでインストール）
pipx run pip-audit

GitHub Dependabotを有効にすれば、脆弱性が見つかったパッケージのアップデートPRが自動で作られます。リポジトリの Settings → Code security → Dependabot alerts をオンにするだけです。

slopsquatting対策 — 幻覚パッケージを検知する

npm auditが検出するのは存在するパッケージの既知脆弱性だけです。AIが生成した架空のパッケージ名はレジストリに登録がないため、そもそも検出対象にならない。

有効な対策は2つある。

1. lockfileの差分レビュー: package-lock.jsonやrequirements.txtにAIが追加したパッケージを、npm info <パッケージ名>やpip show <パッケージ名>で存在確認する
2. Socket.devの導入: Socket CLIはnpm/PyPIパッケージのリスク分析を行い、新規追加パッケージの異常（ダウンロード数ゼロ、作成直後など）を検出します（無料プランあり）

# パッケージの存在確認（手動）
npm info react-codeshift 2>/dev/null || echo "このパッケージは存在しません"

第2層: シークレット検出 — Gitleaksでハードコードを止める

AIが生成するサンプルコードには、APIキーやパスワードがそのまま埋め込まれることがあります。これをコミット前に止めます。

Gitleaksの導入と設定

Gitleaks（https://github.com/gitleaks/gitleaks、参照日: 2026-09-06）はオープンソースのシークレット検出ツールです。

# インストール（macOS）
brew install gitleaks

# リポジトリ全体をスキャン
gitleaks detect --source . --verbose

# pre-commitフックとして設定
gitleaks protect --staged

.gitleaks.tomlでカスタムルールを追加できます。

# .gitleaks.toml
title = "Custom Gitleaks config"

[[rules]]
id = "custom-api-key"
description = "Custom API key pattern"
regex = '''(?i)(api[_-]?key|apikey)\s*[:=]\s*['"][a-zA-Z0-9]{20,}['"]'''

GitHub Push Protection との併用

GitHubのPush Protection（Settings → Code security → Push protection）を有効にすると、push時にGitHubが既知のシークレットパターンを検出してpushを拒否します。Gitleaksのローカル検出と組み合わせることで、二重の防御になります。

第3層: SAST — Semgrepでコードの脆弱性パターンを検出する

SAST（Static Application Security Testing）は、ソースコードを実行せずに脆弱性パターンを検出します。

Semgrepのルールセット選定

Semgrep（https://semgrep.dev、参照日: 2026-09-06）はオープンソースのSASTツールです。OSSコア（Semgrep CE）は無料で、2,800以上のコミュニティルールが公開されています。

# インストール
pip install semgrep

# OWASP Top 10ルールでスキャン
semgrep scan --config "p/owasp-top-ten" .

# セキュリティ監査ルールセットでスキャン
semgrep scan --config "p/security-audit" .

AI生成コードに対しては、次のルールセットの組み合わせが有効です。

AI生成コード向けのチェックポイント

Semgrepで特に注意すべきAI生成コード特有のパターンがあります。

# .semgrep.yml（カスタムルール例）
rules:
  - id: ai-eval-user-input
    patterns:
      - pattern: eval($INPUT)
      - pattern-not: eval("...")
    message: "eval()に外部入力を渡さないでください"
    severity: ERROR
    languages: [javascript, typescript, python]

第4層: DAST — OWASP ZAPで実行時の穴を見つける

DAST（Dynamic Application Security Testing）は、実行中のアプリケーションに対してリクエストを送り、レスポンスから脆弱性を検出します。第1〜3層がコードを見るのに対し、DASTは実際の動作を検証します。

OWASP ZAP（https://www.zaproxy.org/、参照日: 2026-09-06）はオープンソースのDASTツールです。CIに組み込む場合は、ベースラインスキャン（受動スキャン）が現実的です。

# Docker経由でベースラインスキャン
docker run -t ghcr.io/zaproxy/zaproxy:stable zap-baseline.py \
  -t https://localhost:3000 \
  -r report.html

DASTはステージング環境やローカル開発サーバーに対して実行します。本番環境への実行は負荷やデータ破損のリスクがあるため、ステージング環境が推奨です。

GitHub Actionsテンプレート — 4層をCIに組み込む

第1〜3層をGitHub Actionsに組み込むテンプレートです。コピーして.github/workflows/security-scan.ymlに保存すれば動きます。

name: AI Code Security Scan
on: [push, pull_request]

jobs:
  sca:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '22'
      - run: npm ci
      - run: npm audit --audit-level=high

  secrets:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0
      - uses: gitleaks/gitleaks-action@v2
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

  sast:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: returntocorp/semgrep-action@v1
        with:
          config: >-
            p/owasp-top-ten
            p/security-audit

DASTはデプロイ後に別ワークフローで実行するのが一般的です。全4層を毎回のpushで回す必要はなく、DASTはリリース前のステージングデプロイ時に限定しても十分です。

よくある失敗と回避策

❌ 全ルールを一度に有効にして警告の洪水に溺れる

⭕ まずp/owasp-top-tenだけで始め、1週間で慣れてからp/security-auditを追加する。 Semgrepのルールセットは段階的に追加できます。最初から全ルールを入れると、既存コードの大量警告でチームが疲弊し、結局スキャンを無視するようになります。

❌ AI生成コードだけをスキャン対象にしようとする

⭕ リポジトリ全体をスキャンする。 AI生成コードと人間のコードを区別してスキャンすることは現実的に困難です。どのコードがAI由来かを追跡する仕組み（SBOM）は、OWASP AGCでもAGC-10として課題に挙がっています。全コードを同じ基準でスキャンするほうが運用は簡単です。

❌ CIが落ちたら即座にマージをブロックする

⭕ 最初は警告モード（--severity ERRORのみブロック）で運用し、チームがツールに慣れてからブロック範囲を広げる。 WARNINGレベルまでブロックすると、AIが生成した無害なパターンでもCIが止まり、開発速度が落ちます。

❌ slopsquattingを通常のSCAだけで防げると思う

⭕ lockfileの差分レビューを習慣にする。 前述のとおり、npm auditは存在するパッケージの脆弱性しか検出しません。AI生成コードのPRでは、追加されたパッケージが実在するかを確認するステップが必要です。

リリース前チェックリスト — 13項目で最終確認

AI生成コードを含むリリース前に確認する項目です。

• SCA: npm audit --audit-level=high（またはpip audit）がエラーなしで通る
• SCA: 新規追加パッケージが実在し、ダウンロード数とメンテナンス状況を確認した
• シークレット: Gitleaksがクリーン。GitHub Push Protectionが有効
• SAST: Semgrep p/owasp-top-ten がERRORなしで通る
• DAST: ステージング環境でOWASP ZAPベースラインスキャンを実行した（該当する場合）
• 認可: APIエンドポイントに認可チェックがあり、他ユーザーのリソースにアクセスできない
• 入力検証: SQLクエリがパラメータ化されている。eval()に外部入力を渡していない
• CORS: Access-Control-Allow-Originに許可するオリジンを個別に指定している（*は本番で使わない）
• デバッグ: DEBUG=true、verbose logging、スタックトレースの表示が本番で無効
• HTTPS: 本番環境でHTTPSを強制している
• 依存関係: package-lock.jsonまたはrequirements.txtの差分を目視確認した
• 環境変数: APIキー、パスワード、トークンがソースコードに直書きされていない
• 人間レビュー: 自動スキャンで拾えない設計判断（アーキテクチャ、データフロー）を確認した

自動スキャンはコードレベルの脆弱性パターンを検出しますが、「この機能にこの権限が必要か」「このデータをこの経路で送ってよいか」といった設計判断は人間のレビューが必要です。自動と手動の組み合わせについてはAI生成コードの人間レビュー5観点を参照してください。

よくある質問

Q1. 既存プロジェクトに導入すると大量の警告が出て対応しきれません

新規コミットだけをスキャン対象にするのが現実的な出発点です。Semgrepの--baseline-commitオプションを使えば、指定コミット以降の差分だけをスキャンできる。既存の技術負債は別途計画的に潰し、新規の脆弱性はCIで即座に止める。この二段構えにすれば、警告の総量を抑えつつ新たなリスクの混入を防げる。

Q2. Copilot / Claude Code / Cursorのどれが安全ですか

ツール間の脆弱性率を比較した包括的な調査は、執筆時点で確認できていません。どのツールを使う場合でも、この記事で解説した4層スキャンの仕組みをCI側に入れることで、ツールに依存しない安全性を確保できます。

Q3. OWASPのAGC Top 10はいつ正式化されますか

2026年9月時点ではGitHub上の提案段階（Issue #826）です。正式化の時期は公表されていません。ただし、提案に挙がっている脆弱性パターン（幻覚パッケージ、認可欠落、過度な信頼など）は既に実害が確認されており、正式化を待たずに対策を始めることを推奨します。

Q4. 小規模な個人プロジェクトにも必要ですか

公開するWebアプリケーションであれば規模に関係なく推奨します。特にGitHub ActionsはパブリックリポジトリならSemgrepもGitleaksも無料で無制限に使えます。セットアップも前述のテンプレートをコピーするだけです。

CIテンプレートを今日入れて、次のPRから回す

AI生成コードの脆弱性は、AIの生成特性に起因する構造的な問題です。手動レビューだけで全てを拾い切るのは現実的に難しい。

まずはGitHub Actionsテンプレートを1つのリポジトリに入れて、次のPRから4層スキャンを回してください。最初のスキャンで見つかる問題の数が、AI生成コードのセキュリティ対策の優先度を教えてくれます。

社内でAIコーディングツールのルールを整備するなら、生成AI社内ルールの作り方にセキュリティスキャンの義務化を項目として追加することも検討してください。

参考・出典

• Veracode / CSA Research Note「Vibe Coding's Security Debt: The AI-Generated CVE Surge」（https://labs.cloudsecurityalliance.org/research/csa-research-note-ai-generated-code-vulnerability-surge-2026/） — Cloud Security Alliance（参照日: 2026-09-06）
• USENIX Security 2025「Package Hallucination Rates in Code-Generating LLMs」— 商用モデル5.2%、OSSモデル21.7%の幻覚率を報告（参照日: 2026-09-06）
• Socket「New Study Identifies 53 Slopsquatting Targets Across 5 Frontier LLMs」（https://socket.dev/blog/slopsquatting-targets-across-frontier-llms） — Socket（参照日: 2026-09-06）
• OWASP「Proposal: OWASP Top 10 for AI-Generated Code (AGC)」（https://github.com/OWASP/www-project-top-10-for-large-language-model-applications/issues/826） — OWASP GitHub（参照日: 2026-09-06）
• Semgrep公式ドキュメント（https://docs.semgrep.dev/introduction） — Semgrep（参照日: 2026-09-06）
• Gitleaks公式リポジトリ（https://github.com/gitleaks/gitleaks） — Gitleaks（参照日: 2026-09-06）
• OWASP ZAP公式サイト（https://www.zaproxy.org/） — OWASP ZAP（参照日: 2026-09-06）
• Snyk RSAC 2026 講演「AI-assisted developers ship faster but introduce more security findings」（https://expertinsights.com/industry-perspectives/rsac-2026-manoj-nair-snyk） — Expert Insights による二次報道（参照日: 2026-09-06）