
AI 生成コードのセキュリティリスクと対策
AI にコードを書かせる時代こそ、脅威モデル・権限・検証・修正フローが重要になる。
この記事の結論
- AI 生成コードは「便利だが危険」ではなく、「速く書けるからこそ、レビュー体制が間に合わない」 という構造のリスクを抱えています。
- 見るべきセキュリティ観点は 6 領域: 認証 / 権限 / 入力検証 / 秘密情報 / 依存ライブラリ / ログとアクセス記録。
- AI を「脆弱性発見」に使えますが、検証・トリアージ・修正 は人間の判断が必要です。AI が見つけたものをそのまま信用しないこと。
- エンタープライズで AI を本番利用するには、既存のセキュリティ・ガバナンス・運用フローと整合させることが前提です。
- リリース前に最低限揃えるべき脆弱性スキャンとレビュー観点は、型・lint・依存スキャン・認証/権限テスト・秘密情報スキャン の 5 つです。
「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 の場合、典型的な脅威モデルは以下のようになります。
- 資産: 顧客企業のデータ (注文、会員情報、売上)、認証情報、課金情報
- 攻撃者: 外部攻撃者 (テナント境界を超えてデータを取りたい)、悪意ある内部利用者 (退職前の社員)、認証された一般ユーザー (隣の店舗のデータを覗きたい)
- 入口: Web API、管理画面、Webhook (Stripe / 他社 SaaS)
- 信頼境界: テナント (会社) 単位、店舗単位、ロール (管理者 / 一般)
- 影響範囲: 1 テナントなら数万円〜、全顧客に漏えいすると数千万〜数億円規模
これを書くだけで、「どこを最優先で見るべきか」が明確になります。
6 領域の確認ポイント
1. 認証
- 認証ライブラリ (Clerk / Firebase Auth / Auth0 / Supabase Auth) の標準実装に乗っているか
- セッション / トークン / リフレッシュトークンの扱いが安全か
- パスワードリセット、メール確認の脆弱性がないか
- マルチテナントなら、認証時点でテナント識別が確定するか
- ログイン試行のレート制限が入っているか
- 多要素認証 (MFA) の選択肢があるか
よくある AI 生成の問題: 「ユーザー認証」の実装は AI が出すが、テナント識別がアプリ層の if 文だけで処理されていて、API レベルで素通りする。
2. 権限
- データ取得時にテナント / 役割で絞り込みがかかるか
- 画面の if 文で出し分けていないか (API レベルで素通りしていないか)
- 重要操作 (削除、課金、権限変更) に二段階確認があるか
- 管理者アカウントの権限分離があるか
よくある AI 生成の問題: GET /api/orders/:id が、リクエストしたユーザーがその注文の所有者かを確認せずに返す。
3. 入力検証
- バリデーションがフロントだけでなく サーバー側にも あるか
- SQL インジェクション (パラメータバインディング使用か)、XSS (エスケープしているか)、CSRF (トークン使用か) を防げているか
- ファイルアップロードのサイズ、種類、保存先が制限されているか
- 入力長の制限があるか (DoS 対策)
よくある AI 生成の問題: フロント側で zod の schema を組んでバリデーションするが、サーバー側 API では同じ検証が抜けている。
4. 秘密情報
- API キー、データベース URL、暗号鍵が環境変数で管理されているか
.envファイルが.gitignoreに入っているか- リポジトリ履歴に秘密情報が残っていないか (
git log -p | grep -i 'api_key'などで確認) - 本番と検証で別の鍵を使っているか
- Vercel / AWS Secrets Manager / 1Password 等での集中管理ができているか
よくある AI 生成の問題: ローカルでテストするときに .env に書いた値を AI がコメントで参考として出力し、それがコミットされる。
5. 依存ライブラリ
- 既知の脆弱性のあるバージョンを使っていないか
- 必要以上に多くのライブラリに依存していないか
- ロックファイル (
package-lock.json/pnpm-lock.yaml/poetry.lock) を CI で検証しているか
検証コマンド例:
pnpm audit # pnpm の脆弱性スキャン
npm audit # npm の脆弱性スキャン
pip-audit # Python の脆弱性スキャン
CI に組み込むなら GitHub の Dependabot、または Snyk / Renovate を使うと、自動 PR で更新の提案が来ます。
よくある AI 生成の問題: AI が古いバージョンの例を学習しているので、提案するライブラリ指定が古い、または非推奨パッケージを引っ張ってくる。
6. ログとアクセス記録
- ログに個人情報、トークン、API キーが出力されていないか
- 監査ログが、追跡可能な形で残っているか
- アクセスログから異常なアクセスを検知できるか
- ログの保存期間と削除ポリシーが定義されているか
- GDPR / 個人情報保護法を考慮した削除フローがあるか
よくある AI 生成の問題: console.log(req.body) のような全データダンプが、リクエスト内のパスワードやトークンを含めてログに残る。
AI を使ったセキュリティレビューの流れ
AI を活用するなら、以下の流れがおすすめです。
- 脅威モデルを AI に共有する (
CLAUDE.md/AGENTS.mdに書く) - AI に「このリポジトリの認証・権限・入力検証の脆弱性を列挙して」と依頼
- AI が出した候補を、人間が検証・トリアージ (重要度判定、誤検知の除外)
- 修正方針を決めて、AI に修正案を出させる
- 修正後のコードを、別の AI 視点で再レビュー
Anthropic のセキュリティ解説では、AI を使った脆弱性管理のボトルネックは 発見ではなく「検証・トリアージ・修正」 に移っていると整理されています (Using LLMs to Secure Source Code / Anthropic)。AI が見つけたものを、人間が判断する工程が時間のかかる部分です。
また、独立した検証エージェント を発見エージェントとは別の文脈で動かすと、誤検知が減ることが報告されています。「発見と検証は別の AI セッションでやる」という運用が現実的です。
具体的な指示パターン
- 「このリポジトリで、テナント境界が破られる可能性のある API を列挙してください」
- 「
/api/以下のエンドポイントで、認証チェックが抜けている可能性のあるものを挙げてください」 - 「依存ライブラリの中で、既知の脆弱性があるものを
pnpm auditの出力を元に整理してください」 - 「環境変数の取り扱いで、危険な可能性のあるパターンを抽出してください」
これらは個別に AI に依頼します。一度に全部やらせると、見落としが増えるためです。
エンタープライズ導入で必要な観点
エンタープライズで AI を本番利用するには、既存のセキュリティ・ガバナンス・運用フローと整合させる必要があります。OpenAI が AWS と提携で強調しているのも、エンタープライズ AI 導入では既存のセキュリティ・コンプライアンス・調達・課金・ガバナンスのワークフローに乗ることが鍵だ、というポイントです (OpenAI frontier models and Codex on AWS / OpenAI)。
OpenAI のワークスペースエージェントの設計でも、「組織が定めた権限の範囲内で動作する」「監視・統制が可能」という前提が組み込まれています (Introducing workspace agents in ChatGPT / OpenAI)。AI で動くシステムを業務に組み込む場合も、同じ原則を業務システムに適用します。
具体的な観点:
- AI ツールを社内で使う場合の情報セキュリティポリシー (どのデータを AI に渡してよいか)
- AI 生成コードのレビュー手順を、SOX / ISMS / PCI DSS などのコンプライアンス要件と整合させる
- 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 生成コードのセキュリティレビューを以下の形で提供しています。
- スポット診断 (1〜2 週間): リポジトリと脅威モデルを共有して、リスクを列挙
- 修正支援 (2〜4 週間): 重要なリスクの修正をプロが実装
- 継続レビュー: 月次で新規 PR をレビュー、CI に脆弱性チェックを組み込み
- 緊急対応: 脆弱性発見時のスポット対応 (即日〜数日)
特に 「リリース前の最終チェック」 だけのスポット依頼が多くあります。費用感は、リポジトリ規模に応じて 50〜200 万円のレンジが典型的です。
業界別の追加観点
業界によって、特に気をつけるべき観点が変わります。
- EC / 決済: PCI DSS、決済データの取扱い、Stripe Webhook の検証
- 医療: 個人情報保護法 + 医療機関固有のガイドライン、データ保存場所
- 金融: FISC ガイドライン、認証の多要素化、監査ログの長期保管
- 公共: 政府情報セキュリティのガイドライン、データの国内保管
- 教育: 子どものデータ保護、保護者同意の管理
業界固有の規制がある場合は、技術レビューと並行して、コンプライアンス観点のチェックも進めます。
AI 生成コードのセキュリティに不安がある方へ
min's では、AI で書いたコードのセキュリティレビュー、脅威モデリング、本番化前診断を支援しています。
以下のような状態であれば、ご相談ください。
-
AI で作ったコードを本番投入する前に、セキュリティ確認したい
-
認証・権限・データアクセスまわりが不安
-
脆弱性スキャンと、修正方針まで支援してほしい
-
開発した会社が抜けて、セキュリティレビューだけ依頼したい
-
業界固有のコンプライアンスを満たしているか確認したい
次に読む記事
参考
- Using LLMs to Secure Source Code / Anthropic — 脅威モデリング、発見・検証・トリアージ・修正の流れ、独立検証エージェントの効果
- OpenAI frontier models and Codex on AWS / OpenAI — エンタープライズ AI 導入における既存ガバナンス整合
- Introducing workspace agents in ChatGPT / OpenAI — 権限・監視・統制を前提とした AI エージェント設計