# AI生成コード（vibe coding）の脆弱性診断【2026年版】— 生成AIで増える脆弱性を、リリース前に潰す実践手順

> 生成AI（Copilot/Claude等）が書いたコードは、なぜ脆弱性が増えるのか。Stanford・NYUの研究データと『slopsquatting』を踏まえ、AI生成コードに特有のリスクと、リリース前に4層（SCA/シークレット/SAST/DAST）で潰す実践手順を実コードで解説。AIが原理的に作れない安全（認可・業務ロジック）と、人間の検証ゲートの設計までを示します。

- 公開日: 2026-06-28
- 著者: 友田 陽大
- タグ: セキュリティ, 脆弱性診断, AI駆動開発, OWASP
- URL: https://tomodahinata.com/blog/ai-generated-code-vulnerability-assessment-vibe-coding-security-guide
- カテゴリ: アプリ層セキュリティ
- 総合ガイド: https://tomodahinata.com/blog/nextjs-supabase-application-security-guide

## 要点

- 研究データ：AIアシスタント利用者はインジェクション等で脆弱なコードを書きやすく、しかも『自分は安全に書けた』と過信する（Stanford）。Copilot生成コードの約40%が脆弱だった（NYU）。AIの速さには、検証で相殺すべき負債がついてくる
- AI特有の新リスク『slopsquatting』：生成コードの19.7%が存在しないパッケージ名を含み、攻撃者がその名を先回り登録すると、AIの幻覚がそのままサプライチェーン攻撃（OWASP A03）になる。lockfile固定・存在検証・許可リストで防ぐ
- AIが量産しがちな脆弱性TOP5：①認可の欠落（IDOR/A01）②入力検証漏れ（A05）③秘密のハードコード ④古い/存在しない依存（A03）⑤安全でないデフォルト設定（A02）。各々、修正前後のコードで潰し方を示す
- AI生成コードはリリース前に4層で診る：SCA（slopsquatting/A03）→ シークレット → SAST（A05）→ DAST（A01/A05）。すべて無料の公式ツールでCIゲート化でき、生成の速さと本番品質を両立できる
- AIが原理的に作れない安全がある：認可・テナント分離・業務ロジックは『事業ルールの意味』に依存し、AIは文脈を知らない。AIに実装、人間に仕様決定と検証——この役割分担が、速さを安全にする

---

生成AIでコードを書く速度は、もう後戻りできないレベルに上がりました。私自身、一人 × 生成AI（Claude Code）で、経済産業大臣賞を受賞したB2B SaaSや本番二重課金0件の決済基盤を作ってきました。だからこそ、はっきり言えます——**AIは速いが、放っておくと脆弱性も同じ速さで量産します。**

これは感覚論ではなく、研究で裏付けられた事実です。

- **AIアシスタントを使った開発者は、使わない開発者より脆弱なコードを書きやすい。** しかも、**「自分は安全なコードを書けた」と過信する**傾向がある（Stanford大学、[Perryら 2022](https://arxiv.org/pdf/2211.03622)）。
- **GitHub Copilotが生成したコードの約40%**が、セキュリティ上重要な89シナリオで**悪用可能な脆弱性**を含んでいた（NYU、[Pearceら 2021「Asleep at the Keyboard?」](https://arxiv.org/abs/2108.09293)）。

しかし、**これは「AIを使うな」という話ではありません。** 私の結論はその逆です。**AIの速さは、リリース前の検証ゲートで負債を相殺すれば、本番品質と両立できます。** 鍵は「AIに実装を任せ、人間が仕様決定と検証を握る」という役割分担です。本記事は、その**検証＝AI生成コードの脆弱性診断**を、データ・新リスク・実コード・検証ゲート設計まで、一気通貫で示します。

---

## 1. なぜAIは脆弱性を生むのか — 3つの構造的理由

AIがバグを出すのは「賢くないから」ではありません。**構造的な理由**があり、それを理解すると診断の的が絞れます。

1. **訓練データの欠陥パターンを再生産する。** AIは世の中のコードを学習しています。そこには**安全でないコードも大量に含まれる**ため、確率的に「よくある書き方」＝「よくある脆弱なパターン」を出力します。SQLの文字列連結や`dangerouslySetInnerHTML`の直挿入は、その典型です。
2. **文脈（あなたの事業ルール）を知らない。** AIは「このAPIにアクセスしてよいのは誰か」を知りません。だから**認可チェックを平気で省略**します。これは後述するTOP5の第1位です。
3. **ハルシネーション（幻覚）を起こす。** 存在しない関数・存在しないパッケージを、自信満々に生成します。これが次節の新リスク「slopsquatting」の温床です。

つまりAIの弱点は、**「構造的欠陥の再生産」と「文脈の欠如」と「幻覚」**の3つ。診断は、この3つを狙い撃ちにします。

---

## 2. AI特有の新リスク「slopsquatting」— 幻覚がサプライチェーン攻撃になる

2025年に名付けられた、AI時代に固有の脆弱性が **slopsquatting** です。仕組みはこうです。

1. AIが、**実在しないパッケージ名**を「これをインストールせよ」と提案する。
2. 攻撃者が、その**幻覚パッケージ名を先回りしてnpm/PyPIに登録**し、悪意あるコードを仕込む。
3. 開発者がAIの言うままに `npm install` すると、**悪意あるコードが本番に取り込まれる**。

これは絵空事ではありません。研究によれば、**16の生成モデルで作った223万サンプルのうち19.7%が、存在しないパッケージ名を含んで**いました。さらに**同じ幻覚が再現しやすい**（同一プロンプトの再実行で43%が毎回同じ幻覚名を出した）ため、攻撃者は「どの名前を登録すれば刺さるか」を予測できます（[DevOps.com](https://devops.com/ai-generated-code-packages-can-lead-to-slopsquatting-threat-2/) ／ [Cloud Security Alliance](https://labs.cloudsecurityalliance.org/research/csa-research-note-slopsquatting-ai-supply-chain-20260419-csa/)）。

これは [OWASP Top 10:2025 で新設・拡大された **A03 Software Supply Chain Failures**](https://owasp.org/Top10/2025/) に直撃する、**AI時代の最新リスク**です。防御は次の3点です。

```bash
# ① 提案されたパッケージが「実在し、まともか」を install 前に検証する
npm view <package-name>   # 存在しない/極端に新しい/DL数が異常に少ないものは疑う

# ② lockfile を信頼の唯一の源にし、不意の解決を防ぐ（CIは必ず ci を使う）
npm ci                    # package-lock.json に完全一致させる（install ではなく ci）

# ③ 依存を毎回スキャン（slopsquattingは「見覚えのない依存の増加」として現れる）
npm audit --audit-level=moderate
npx osv-scanner scan --lockfile=package-lock.json
```

> **運用のコツ：** AIに依存追加を提案されたら、**「その名前は本当に実在するか」を人間が一度確認する**だけで、slopsquattingの大半は防げます。`package.json` の差分レビューで、**見覚えのないパッケージが増えていないか**を必ず見てください。

---

## 3. AIが量産しがちな脆弱性TOP5 と、その潰し方

実務でAI生成コードを診ると、繰り返し同じ穴が出ます。**頻出順のTOP5**と、修正前後のコードを示します。

### ① 認可の欠落（IDOR / OWASP A01）— 最頻出かつ最重大

AIは認証（ログイン済みか）は書きますが、**認可（その人がそのデータの持ち主か）を省略**します。

```ts
// ❌ AIがよく書く：ログインは確認するが「所有者か」を確認しない → 他人のデータが見える
export async function GET(_req: Request, { params }: { params: { id: string } }) {
  const order = await db.order.findUnique({ where: { id: params.id } });
  return Response.json(order); // 他人のIDを入れれば、他人の注文が返る（IDOR）
}
```

```ts
// ✅ 所有権でフィルタする（「誰が所有するか」は事業ルール＝人間が指定すべき不変条件）
export async function GET(req: Request, { params }: { params: { id: string } }) {
  const userId = await requireUserId(req);          // 認証
  const order = await db.order.findFirst({
    where: { id: params.id, ownerId: userId },      // 認可：所有権で絞る
  });
  if (!order) return Response.json({ error: "not found" }, { status: 404 });
  return Response.json(order);
}
```

### ② 入力検証の漏れ（OWASP A05）

AIは「ハッピーパス」を書きがちで、**境界での検証を飛ばす**ことがあります。外部入力は信頼境界で必ず検証します。

```ts
// ✅ システムの境界（外から来る値）でZod検証し、型を絞ってから使う
const Body = z.object({ email: z.string().email(), age: z.number().int().min(0).max(150) });
const parsed = Body.safeParse(await request.json());
if (!parsed.success) return Response.json({ error: "invalid" }, { status: 400 });
```

### ③ 秘密のハードコード（OWASP A02/A03）

AIはサンプルとして**APIキーをコードに直書き**することがあります。サーバー専用の秘密は`process.env`経由に限定し、`NEXT_PUBLIC_`との混在を型で防ぎます（[詳細](/blog/nextjs-env-secret-leak-prevention-public-vars-guide)）。Gitleaks＋GitHubのPush Protectionで物理的に止めます。

### ④ 古い / 存在しない依存（OWASP A03）

AIは訓練データ時点の古いバージョンや、前節の幻覚パッケージを提案します。`npm audit`・Dependabot・存在検証で潰します。

### ⑤ 安全でないデフォルト設定（OWASP A02）

CORSを`*`に開く、Cookieに`HttpOnly`/`Secure`を付け忘れる、エラーでスタックトレースを返す——AIは「動く最小構成」を優先するため、**安全側のデフォルト**を外しがちです。セキュリティヘッダー/CSPやCORSは[ミドルウェアで一括強化](/blog/nextjs-security-headers-csp-nonce-middleware-guide)します。

---

## 4. リリース前チェックリスト — AI生成コードを4層で診る

AI生成コードは、**マージ前に必ず4層の自動診断を通す**のが基本です。前述のTOP5は、この4層でほぼ捕捉できます（認可＝①を除く。①は第6節へ）。

| 層 | 狙うAIの弱点 | コマンド | 対応OWASP |
|---|---|---|---|
| **SCA** | 幻覚・古い依存（slopsquatting） | `npm ci` ＋ `npm audit` ＋ OSV-Scanner | **A03** |
| **シークレット** | 鍵のハードコード | `gitleaks` ＋ Push Protection | A02 |
| **SAST** | 構造的欠陥（注入・設定） | `semgrep scan --config=auto` | **A05** ほか |
| **DAST** | 実行時の挙動（反射XSS・ヘッダー） | ZAP `zap-baseline.py` | **A01/A05/A02** |

この4層を**GitHub ActionsでPRゲート化**すれば、AIがどれだけ速くコードを生んでも、**脆弱性はマージ前に自動でブロック**されます。具体的なCIワークフロー（SARIF集約まで）は[CI統合の手順記事](/blog/nextjs-supabase-security-ci-sarif-github-actions-guide)に、4層の実装詳細は[OWASP公式手法のハンズオン記事](/blog/web-application-vulnerability-assessment-owasp-zap-sast-dast-guide)にまとめています。**「AIで速く書く」と「ゲートで安全に止める」はセットにして初めて成立**します。

---

## 5. 人間の検証ゲートを設計する — 「AIに実装、人間に仕様と検証」

ツールゲートは必要条件ですが、十分ではありません。**生成の速さを本番品質に変える鍵は、人間が握るべき2点を手放さないこと**です。

1. **仕様の決定は人間が握る。** 「誰が何を所有し、どの操作を許されるか」「金額・数量・状態遷移の不変条件は何か」——これらは**AIに決めさせてはいけない**事業ルールです。AIには「この仕様を満たす実装」を任せます。
2. **受け入れ条件をテストに落とす。** 「他人のIDで他人の注文が見えないこと」をテストとして書けば、AIが認可を省略しても**テストが落ちて検出**できます。検証パスを先に用意するのが、AI時代の最大の品質レバーです。

```ts
// ✅ 認可の不変条件を「テスト」として固定する（AIが省略しても落ちる）
it("他人のリソースは取得できない（IDOR防止）", async () => {
  const res = await GET(reqAs(userA), { params: { id: orderOwnedByUserB.id } });
  expect(res.status).toBe(404); // 200で中身が返ったら認可バグ
});
```

これは私が一貫して使っているワークフローそのものです。**探索 → 計画 → 実装 → 検証**の4フェーズで、AIに速度を出させつつ、各ゲートで人間が仕様と安全を確認する。AI駆動開発の品質ゲート全体像は[AI駆動開発の品質ゲート記事](/blog/ai-driven-development-quality-gates-ci-type-safety-test-security)で扱っています。

---

## 6. AIが原理的に作れない安全 — 認可・業務ロジックは人間の領域

最後に、最も重要な一線です。**どれだけ優秀なAIでも、診断ツールでも、原理的に保証できない安全があります。** それが**認可（A01）・テナント分離・業務ロジック（OWASP WSTG 4.5 / 4.10）**です。

理由は、第1節で触れた「文脈の欠如」に行き着きます。「この請求書を見てよいのは誰か」「この割引は何回まで使えるか」は、**あなたの事業ルールの"意味"**であり、AIもスキャナもその意味を知りません。だから、認可の欠落を「欠落」だと判定できない。**SQLインジェクションが「どんなアプリでも同じ構造的欠陥」なのとは対照的**です。

| AI・ツールが守れる（水平） | 人間しか守れない（垂直） |
|---|---|
| 注入・設定ミス・既知CVE・秘密の混入 | **認可/IDOR・テナント分離** |
| 構造的・既知パターンの欠陥 | **業務ロジック**（数量・価格・状態遷移の悪用） |

ここから先は、ツールゲートではなく**手動の認可レビュー・監査**の領域です。とりわけ**「AIで大量にコードを生成した直後のリリース前」は、認可・業務ロジックの抜けが最も入りやすい**タイミング——監査を入れる最大の好機です。垂直リスクの検出と多層防御は[IDOR・認可欠陥の検出記事](/blog/nextjs-supabase-idor-broken-authorization-rls-detection-guide)、監査の範囲と費用感は[セキュリティ監査は何を見るのか](/blog/nextjs-supabase-security-audit-scope-when-needed-guide)を参照してください。

---

## まとめ — AIの速さを、検証で本番品質に変える

1. **AIは脆弱性を量産する**（Stanford：過信、NYU：約40%が脆弱）。だが速さは検証で相殺できる。
2. **AI時代の新リスク slopsquatting**（幻覚パッケージ＝A03）。lockfile固定・存在検証・依存スキャンで防ぐ。
3. **AIが量産するTOP5**（認可欠落・入力検証漏れ・秘密ハードコード・古い/存在しない依存・危険なデフォルト）を、修正前後のパターンで根治する。
4. **リリース前に4層で診る**（SCA→シークレット→SAST→DAST）。無料ツールでPRゲート化できる。
5. **人間は仕様決定と検証を握る**。認可・業務ロジックはAIに渡さない。AIが作れない安全＝監査の領域。

「AIで速く作る」ことと「安全に出荷する」ことは、対立しません。**速さの裏に生まれる負債を、リリース前の検証ゲートで毎回相殺する**——この設計さえあれば、生成AIは最強の武器になります。私自身が一人 × 生成AIで本番品質のプロダクトを作り続けている、まさにその方法です。AIで生成したアプリのリリース前診断や、認可・業務ロジックの監査が必要になったら、まずは無料OSS [Aegis](/aegis) で現状を可視化するところからご相談ください。