AI 生成コードのセキュリティリスクと対策

AI にコードを書かせる時代こそ、脅威モデル・権限・検証・修正フローが重要になる。

この記事の結論


「AI に書かせたコードを本番に出していいですか」

ここ最近、CTO や情報システム部門の方からよく受ける質問です。答えは 「レビュー体制があれば、人間が書いたコードと同等以上に安全にできる」、しかし 「レビュー体制がなければ、人間が書いたコードより危険」 です。

AI 生成コードの危険は、AI 自体が悪いものを書くからではなく、速く生成されるからレビューが追いつかない ことに由来します。この記事では、AI 生成コードを本番利用するときに見るべきセキュリティ観点と、AI を活用したレビュー方法、リリース前の最低ラインを整理します。

AI 生成コードで起きやすいリスク

実際に AI 生成コードのレビューで頻繁に見るリスクを整理します。

カテゴリよくあるリスク
認証テナント境界が抜ける、JWT 検証の漏れ、セッション固定
権限画面の if 文だけで判定、API レベルで素通り、role escalation
入力検証バリデーション漏れ、SQL インジェクション、コマンドインジェクション
秘密情報API キーがハードコーディング、.env がコミットされる、ログに出力
依存関係既知の脆弱性があるライブラリの導入、不要なライブラリ
ログ個人情報やトークンがログに出る、保存期間が長すぎる

これらは「AI が書いたから」ではなく「速く書いた結果、目視レビューが追いつかなかった」が原因です。人間も同じミスをします。AI ではミスが速く生成されるので、可視化が遅れます。

特に多いのが 「権限の素通り」と「秘密情報のハードコーディング」 です。AI に「ここで〜の処理を追加して」と頼んだ結果、認証チェックを通らずに直接 DB にアクセスする実装が混入していた、というケースは何度も見ます。

まず脅威モデルを作る

セキュリティレビューの前に、「何を守るのか」「誰から守るのか」 を整理します。これが脅威モデルです。

1 枚で書ける脅威モデルテンプレ

最低限以下を 1 枚で整理します。

項目内容
資産顧客データ、決済情報、社内データ、業務ログ、認証情報
攻撃者外部攻撃者、悪意ある内部利用者、認証された一般ユーザー、内部からの誤操作
入口Web フォーム、API、メール、Webhook、外部 SaaS 連携、ファイルアップロード
信頼境界認証前 / 認証後、テナント境界、社内 / 社外、管理画面 / 一般画面
影響範囲1 ユーザー / 1 テナント / 全顧客 / 事業全体
既知のリスク過去のインシデント、業界の典型的な攻撃、依存ライブラリの脆弱性

これが揃っていれば、AI 生成コードを「どの観点でレビューすべきか」が決まります。逆に脅威モデルなしのレビューは、「何となく見る」になりがちで、見落としが増えます。

業務システムでの脅威モデル例

業務 SaaS の場合、典型的な脅威モデルは以下のようになります。

これを書くだけで、「どこを最優先で見るべきか」が明確になります。

6 領域の確認ポイント

1. 認証

よくある AI 生成の問題: 「ユーザー認証」の実装は AI が出すが、テナント識別がアプリ層の if 文だけで処理されていて、API レベルで素通りする。

2. 権限

よくある AI 生成の問題: GET /api/orders/:id が、リクエストしたユーザーがその注文の所有者かを確認せずに返す。

3. 入力検証

よくある AI 生成の問題: フロント側で zod の schema を組んでバリデーションするが、サーバー側 API では同じ検証が抜けている。

4. 秘密情報

よくある AI 生成の問題: ローカルでテストするときに .env に書いた値を AI がコメントで参考として出力し、それがコミットされる。

5. 依存ライブラリ

検証コマンド例:

pnpm audit           # pnpm の脆弱性スキャン
npm audit            # npm の脆弱性スキャン
pip-audit            # Python の脆弱性スキャン

CI に組み込むなら GitHub の Dependabot、または Snyk / Renovate を使うと、自動 PR で更新の提案が来ます。

よくある AI 生成の問題: AI が古いバージョンの例を学習しているので、提案するライブラリ指定が古い、または非推奨パッケージを引っ張ってくる。

6. ログとアクセス記録

よくある AI 生成の問題: console.log(req.body) のような全データダンプが、リクエスト内のパスワードやトークンを含めてログに残る。

AI を使ったセキュリティレビューの流れ

AI を活用するなら、以下の流れがおすすめです。

  1. 脅威モデルを AI に共有する (CLAUDE.md / AGENTS.md に書く)
  2. AI に「このリポジトリの認証・権限・入力検証の脆弱性を列挙して」と依頼
  3. AI が出した候補を、人間が検証・トリアージ (重要度判定、誤検知の除外)
  4. 修正方針を決めて、AI に修正案を出させる
  5. 修正後のコードを、別の AI 視点で再レビュー

Anthropic のセキュリティ解説では、AI を使った脆弱性管理のボトルネックは 発見ではなく「検証・トリアージ・修正」 に移っていると整理されています (Using LLMs to Secure Source Code / Anthropic)。AI が見つけたものを、人間が判断する工程が時間のかかる部分です。

また、独立した検証エージェント を発見エージェントとは別の文脈で動かすと、誤検知が減ることが報告されています。「発見と検証は別の AI セッションでやる」という運用が現実的です。

具体的な指示パターン

これらは個別に AI に依頼します。一度に全部やらせると、見落としが増えるためです。

エンタープライズ導入で必要な観点

エンタープライズで AI を本番利用するには、既存のセキュリティ・ガバナンス・運用フローと整合させる必要があります。OpenAI が AWS と提携で強調しているのも、エンタープライズ AI 導入では既存のセキュリティ・コンプライアンス・調達・課金・ガバナンスのワークフローに乗ることが鍵だ、というポイントです (OpenAI frontier models and Codex on AWS / OpenAI)。

OpenAI のワークスペースエージェントの設計でも、「組織が定めた権限の範囲内で動作する」「監視・統制が可能」という前提が組み込まれています (Introducing workspace agents in ChatGPT / OpenAI)。AI で動くシステムを業務に組み込む場合も、同じ原則を業務システムに適用します。

具体的な観点:


ここまでで「自社の AI 生成コードのセキュリティを確認したい」と感じたら、診断フェーズだけのスポット依頼が可能です。

AI 生成コードのセキュリティ診断を相談する →

本番投入前チェックリスト

リリース前に最低限確認するチェックリストです。

項目確認すること
認証標準的な認証ライブラリで実装されているか
テナント境界データ取得時に強制されているか
権限API レベルで判定されているか
バリデーションサーバー側にも入っているか
SQL / XSS / CSRF防御が入っているか
秘密情報環境変数管理、リポジトリに含まれていないか
依存ライブラリpnpm audit / pip-audit で脆弱性なしか
ログ個人情報・トークンが含まれていないか
監査ログ主要操作の履歴が残るか
HTTPS全エンドポイントで強制されているか
CORS必要な origin だけ許可されているか
Rate limit主要 API でレート制限が入っているか

スキャンを自動化する

CI に組み込むスキャン項目の最小セット:

# 例: GitHub Actions
- name: Dependency audit
  run: pnpm audit --audit-level=high
- name: Secret scan
  uses: trufflesecurity/trufflehog@main
- name: Static security
  uses: github/codeql-action/analyze@v3

これだけで「秘密情報のコミット」「既知の脆弱性ライブラリ」「典型的な脆弱性パターン」を機械的に検出できます。

min's のセキュリティ支援スタイル

min's では、AI 生成コードのセキュリティレビューを以下の形で提供しています。

特に 「リリース前の最終チェック」 だけのスポット依頼が多くあります。費用感は、リポジトリ規模に応じて 50〜200 万円のレンジが典型的です。

業界別の追加観点

業界によって、特に気をつけるべき観点が変わります。

業界固有の規制がある場合は、技術レビューと並行して、コンプライアンス観点のチェックも進めます。


AI 生成コードのセキュリティに不安がある方へ

min's では、AI で書いたコードのセキュリティレビュー、脅威モデリング、本番化前診断を支援しています。

以下のような状態であれば、ご相談ください。

次に読む記事

参考

動くデモで終わらせず
本番まで持っていく開発

AI で作りかけたもの、止まりかけている開発、新しいプロダクトの構想。 まずは現状を整理するところから、ご相談ください。