AI駆動開発のセキュリティツール、結局なにを入れればいい？
はじめに
前回の記事では、AI駆動開発のセキュリティを3つのレベルに分けて「どこまでやればいいか」を整理しました。ありがたいことに多くの反応をいただき、特に多かったのが 「考え方はわかった。で、具体的に何を入れればいいの？」 という声です。
本記事はその実践編です。前回のレベル分け（レベル1：一般的 → レベル2：厳格 → レベル3：最厳格）を踏襲しつつ、各カテゴリで「どのツールを」「なぜ」「どう組み込むか」 を整理します。
先に全体像を示してから、カテゴリごとに掘り下げていきます。
📦 すぐ使えるフレームワークも公開しています
本記事で解説するレベル2のセキュリティ構成（シークレットスキャン、SCA、SAST、ライセンススキャン、DAST、Content Exclusion、PRテンプレート、段階導入）を、無料ツールだけで実装済みのフレームワークを公開しています。Claude Codeで「設計 → 実装 → テスト → セキュリティチェック」のパイプラインを回す、一人SIer向けの開発基盤です。
👉 AI Orchestrator — 一人SIerフレームワーク（MIT License）
記事を読んで「自分で組むのは手間だな」と思ったら、こちらをフォークして使ってみてください。既存プロジェクトへの後付けにも対応しています。
※ 本記事のツール情報は2026年央時点のものです。このジャンルは進化が速いので、導入時には必ず各ツールの最新ドキュメントを確認してください。
全体マップ：何を守るために、何を入れるか
AI駆動開発で必要なセキュリティツールは、大きく 9つのカテゴリ に分かれます。
| # | カテゴリ | 何を守るか | レベル1 | レベル2 | レベル3 |
|---|---|---|---|---|---|
| 1 | シークレットスキャン | APIキー・パスワードの漏洩 | ✅ 必須 | ✅ 必須 | ✅ 必須 |
| 2 | SCA（脆弱性スキャン） | 既知の脆弱性を持つ依存パッケージ | ✅ 必須 | ✅ 必須 | ✅ 必須 |
| 3 | SCA（slopsquatting対策） | AIが幻覚したパッケージの混入 | ⚠️ 推奨 | ✅ 必須 | ✅ 必須 |
| 4 | SAST（汎用） | 生成コードの脆弱性 | ⚠️ 推奨 | ✅ 必須 | ✅ 必須 |
| 5 | SAST（AI生成コード特化） | プロンプトインジェクション・エージェント固有リスク | ⚠️ 推奨 | ✅ 必須 | ✅ 必須 |
| 6 | ライセンススキャン | オープンソースライセンス汚染 | ⚠️ 推奨 | ✅ 必須 | ✅ 必須 |
| 7 | Content Exclusion・権限制御 | 機密ファイルのAIへの送信防止 | ⚠️ 推奨 | ✅ 必須 | ✅ 必須 |
| 8 | DAST（動的解析） | 実行時に現れる脆弱性 | — | ⚠️ 推奨 | ✅ 必須 |
| 9 | LLMゲートウェイ | コスト・利用・アクセスの集中統制 | — | — | ⚠️ 推奨 |
読み方ガイド：自社のレベルに合わせて、必要なセクションだけ読んでください。
- レベル1（個人開発・社内ツール・スタートアップ）→ セクション1〜2だけ でまず十分。3〜7は余裕があれば。
- レベル2（受託・顧客データ扱うSaaS・中規模以上）→ セクション1〜7 を組み込む。8も推奨。
- レベル3（金融・医療・官公庁）→ すべて に加えてインフラレベルの統制が入る。
1. シークレットスキャン ── 最初に入れるべきツール
なぜ最優先か
AIは周辺のコードを「文脈」としてクラウドに送ります。.env やAPIキーが一緒に送られるのを防ぐのが、このカテゴリの役割です（前回記事の「シークレットの漏洩」参照）。AI時代は「ツールが勝手に送信する」パスが加わるため、この基本の重要度がさらに上がっています。
主要ツール比較
| ツール | 特徴 | 料金 | 推奨用途 |
|---|---|---|---|
| Gitleaks | 高速・軽量。regexベースでgit履歴をスキャン。pre-commitフックでミリ秒単位で検出 | 無料（MIT） | pre-commitフック（コミット前のブロック） |
| TruffleHog | 800+のシークレット種別を検出。検出した認証情報が現在も有効かどうかをベンダーAPIに問い合わせて確認する「検証」機能が最大の差別化 | OSS版は無料、商用版あり | CIパイプライン（深いスキャン） |
| GitHub Secret Scanning | GitHub側でpush時に自動スキャン。対応プロバイダーへの自動通知あり | Public repoは無料、Private repoは有料プランが必要（※） | GitHubユーザーの基盤スキャン |
| GitGuardian | エンタープライズ向け。リポジトリだけでなくCI/CDログ、コンテナイメージ、Slackまでスキャン範囲が広い。修復ワークフロー付き | 有料（エンタープライズ） | 大規模組織の統合管理 |
どう組み合わせるか
成熟したチームの多くは 2層構成 で運用しています。
- 第1層（pre-commit）：Gitleaks ── コミット前にローカルで即座にブロック。速度重視。
- 第2層（CI/CD）：TruffleHog ── プルリクエスト時にCI上で深いスキャン。検証機能で「まだ有効なシークレット」を特定。
この組み合わせなら、速度と深さの両方をカバーできます。GitHubを使っているなら、Secret Scanningも並行で有効にしておくと三重の防御になります。
重要：検出されたシークレットは「コードから消す」だけでは不十分です。TruffleHogの検証機能で「有効」と判定された鍵は、すでに外部に送信された可能性があります。鍵の無効化（revoke）→ 再発行（rotate）まで行って初めて対処が完了します。git履歴にも残っているため、コミットから削除しただけでは安全ではありません。
導入の最小ステップ（レベル1）
-
Gitleaksをpre-commitフックに設定する（所要時間：5分）。
pip install pre-commit→.pre-commit-config.yamlにGitleaksを追加 →pre-commit install。これだけで、チームメンバー全員がコミット時にシークレットを自動チェックできます。 - .gitleaks.toml でプロジェクト固有のルールを追加。自社のAPIキーフォーマットなど、標準ルールにないパターンがあれば足します。
2. SCA（脆弱性スキャン） ── 依存パッケージの既知の脆弱性
なぜ必要か
AIが提案するパッケージに既知の脆弱性（CVE）がないかを自動チェックする仕組みです。AIは古いバージョンや脆弱性のあるバージョンを平気で指定するため、人間が手動で書いていたときよりSCAの価値が上がっています。
主要ツール比較
| ツール | 特徴 | 料金 | 推奨 |
|---|---|---|---|
| Snyk Open Source | CVEデータベースが豊富。自動修正PR生成。IDE連携も強い | 無料枠あり（個人・小規模）、Team $25/月〜 | 商用プロジェクトの標準 |
| Dependabot | GitHubネイティブ。脆弱性検出＋自動バージョンアップPR | GitHub利用者は無料 | GitHub利用者の基盤 |
| Trivy | Aqua Security製のOSS。コンテナ・IaC・SBOMも対応。軽量で速い | 無料（Apache 2.0） | コンテナも含めた統合スキャン |
| OWASP Dependency-Check | 古参のOSS。NVD（National Vulnerability Database）ベース | 無料 | コスト重視の最小構成 |
どう選ぶか
- GitHubを使っていて、まず始めたい → Dependabot を有効にするだけ（設定不要、数クリック）
- もう少し深い脆弱性管理がしたい → Snyk を追加。自動修正PRが現場に好評
- コンテナも含めて統合スキャンしたい → Trivy をCIに組み込む
- お金をかけたくない＋OSSで完結したい → OWASP Dependency-Check or Trivy
レベル1ならDependabotを有効にするだけで最低限のカバーになります。レベル2以上では、Snyk or Trivyの追加を推奨します。
3. SCA（slopsquatting対策） ── AIが幻覚したパッケージを検出する
なぜ別カテゴリにしたか
slopsquattingの仕組みは前回記事で詳しく解説しています。ここで押さえておきたいのは、従来のSCA（Snyk, Dependabot等）ではslopsquattingを検出できない という点です。従来のSCAは「CVE（既知の脆弱性）があるか」を見ますが、slopsquattingで登録された不正パッケージにはCVEが付いていないからです。必要なのは、CVEマッチングではなく パッケージの振る舞い分析（インストールスクリプトの挙動、難読化されたコード、外部への通信など）です。
主要ツール
| ツール | 特徴 | 料金 |
|---|---|---|
| Socket | npm, PyPI, Go, Maven等10+エコシステム対応。振る舞い分析でタイポスクワッティング・依存関係の混乱・乗っ取りアカウントを検出。PRごとにセキュリティレポートを自動追加 | OSSプロジェクトは無料、商用は有料 |
| Snyk（補完として） | CVEベースの検出がメインだが、サプライチェーンリスクの情報も提供 | 上記参照 |
Socket の位置づけ
Socketは従来のSCA（Snyk, Dependabot）を 置き換えるものではなく、補完するもの です。
- 第1層（インストール前）：Socket ── 新しいパッケージが追加されるPRで、そのパッケージの振る舞いを分析。悪意あるパッケージをインストール前にブロック。
- 第2層（インストール後）：Snyk / Dependabot ── すでにインストール済みの依存に、後からCVEが発見された場合に通知。
この2層構成が、2026年時点のベストプラクティスに近いです。
運用面の対策（ツールに加えて）
ツールだけでなく、運用でもカバーすべきポイントがあります。
-
「AIが提案したパッケージをそのまま
installしない」 を徹底する。npmやPyPIの公式ページでパッケージの存在を確認し、ダウンロード数・メンテナー・最終更新日をチェックする基本動作です。 -
lockfileでバージョンを固定する。
package-lock.jsonやpoetry.lockをコミットし、CIではnpm ci/pip install --require-hashesのようにlockfileベースでインストールする。AIが新しいパッケージを提案したときの差分がlockfileに明確に出るため、レビューで気づきやすくなります。 - レベル2以上では、社内レジストリ（Artifactory, Verdaccio等）経由でのみパッケージを導入する 運用も有効です。許可されたパッケージだけを社内レジストリにミラーし、直接公開レジストリからのインストールを禁止する構成です。
4. SAST（汎用） ── 生成コードの脆弱性を静的解析する
なぜAI駆動開発でSASTがより重要か
AIはセキュリティのベストプラクティスを常に守るわけではなく、CWE Top 25に載る高頻度の脆弱性パターンを普通に再生産します。前回記事の「AIが書いたコードは、インターンが書いたコードと同じ」── この原則を技術的に担保するのがSASTです。
主要ツール比較
| ツール | 特徴 | 料金 | 推奨用途 |
|---|---|---|---|
| Semgrep（OSS CLI） | パターンマッチベース。YAML形式でカスタムルールを書きやすい。30+言語対応。CIへの組み込みが簡単 | OSS版は無料（LGPL-2.1） | カスタムルール重視のチーム |
| SonarQube（Community） | コード品質＋セキュリティの統合。35+言語、6,500+ルール。品質ゲート（基準を満たさないとマージ不可）が強力 | Community版は無料 | 品質ゲートでマージを制御したいチーム |
| CodeQL | コードをデータベースとして扱い、クエリで検索。深いセマンティック解析。GitHub Advanced Securityの一部 | Public repoは無料、Private repoは有料プランが必要（※） | GitHub利用者のセキュリティ深掘り |
| Snyk Code | IDE上でリアルタイムスキャン。開発者体験が良い | 無料枠あり、有料プラン別 | 開発者のフィードバックループ最速 |
どう選ぶか
ここはチームの状況で分かれます。
- 「まず1つ入れたい」なら → Semgrep OSS。無料、CIへの組み込みが簡単、カスタムルールの学習コストが低い。AI生成コード向けのルールセットも用意されている（後述の「AI生成コード特化」セクションで詳しく）。
- 「品質ゲートでマージを制御したい」なら → SonarQube Community。ただし、Community版はクロスファイルのテイント追跡（データがファイルをまたいで汚染される流れの解析）ができない点に注意。深いセキュリティ解析には有料版が必要。
- 「GitHubにオールインしている」なら → CodeQL。GitHub Advanced Securityの一部として動く。クエリ言語の学習コストは高めだが、検出の深さはトップクラス。
- 「IDEでリアルタイムに指摘してほしい」なら → Snyk Code。書いている最中に脆弱性を教えてくれるので、フィードバックが最速。
一つに絞る必要はありません。実務的には 「メインSAST（CI/CD）+ 定期的なディープスキャン」 の2段構成が推奨されています。例えば「Semgrepを毎PRで回し、CodeQLを週次リリース前に回す」といった使い分けです。
※ GitHub Advanced Security（GHAS）の課金体系について：GitHubはGHASを「Secret Protection」「Code Security」に分割しており、無料で使える範囲が変動しています。Private repoでSecret ScanningやCodeQLを使う場合の正確な費用は、GitHubの最新の料金ページで確認してください。なお、Private repoでGHAS/Code Securityが無効の場合、SARIFファイルのCode Scanningアップロードは失敗します。その場合、スキャン結果はCIのアーティファクト（
actions/upload-artifact）として保存するのが現実解です。
5. SAST（AI生成コード特化） ── AI駆動開発ならではの脅威に対応する
汎用SASTと何が違うか
汎用SASTは「SQLインジェクション」「XSS」といった従来の脆弱性パターンを検出します。それに対し、AI生成コード特化のルールセットは AIコーディングツールやエージェントに固有の脅威 を検出します。
具体的には以下のようなものです。
- プロンプトインジェクション：ユーザー入力がそのままLLMのプロンプトに連結されているコード
- エージェントスキルファイルの悪意あるパターン：AIエージェントのスキル定義に、データ持ち出しや不正な外部通信のパターンが含まれていないか
- シャドーAI利用の検出：承認されていないLLM APIの呼び出しがコードベースに含まれていないか（例：開発者が個人のOpenAIキーで直接API叩いているコード）
Semgrep Guardian とルールパック
この領域で先行しているのが Semgrep です。2026年5月に「Semgrep Guardian」をリリースし、Claude Code、Cursor、Windsurf、Kiroなどのエージェント型ツールの内部でリアルタイムにスキャンを実行できるようになりました。
また、以下の3つのルールパックが提供されています（2026年6月時点。ルール数はアップデートで変動するため、最新はSemgrep公式レジストリで確認してください）。
| ルールパック | ルール数 | 検出対象 | 料金 |
|---|---|---|---|
| AI Security | 27 | プロンプトインジェクション、制限なしのツール使用、データ持ち出し | 無料（OSS CLI） |
| Agent Skills（Pro） | 122 | エージェントスキル定義ファイル内の悪意あるパターン | 有料（Semgrep Pro） |
| Shadow AI | 186 | コードベース内の未承認LLM利用 | 無料（OSS CLI） |
注意：Semgrep GuardianやProルールパックは有料製品です。無料で使えるのはOSS CLIとコミュニティルール（AI Security、Shadow AI含む）であり、「Semgrepは全部無料」ではありません。ただし、無料のルールパックだけでも十分な出発点になります。
いつ導入すべきか
- レベル1：汎用SASTにSemgrepを選ぶなら、AI SecurityルールとShadow AIルールも一緒に有効にする。追加コストゼロなので、入れない理由がない。
- レベル2：エージェント型ツール（Claude Code, Copilot Agent Mode等）を使っているなら、AI SecurityルールとShadow AIルールは入れるべき。
- レベル3：全ルールパックを必須とし、Guardianでリアルタイム検出も組み込む。
Semgrep以外の選択肢
この領域は2026年時点でまだ新しく、Semgrepが先行しています。ただし、SonarQubeやSnyk Codeも「AI生成コードへの対応」を進めており、今後選択肢は増えるでしょう。現時点では、汎用SASTとしてSemgrepを選び、無料のルールパック（AI Security + Shadow AI）を一緒に有効にする のが、最もコスパの良い始め方です。
6. ライセンススキャン ── オープンソース汚染を防ぐ
なぜAI駆動開発で特に重要か
AIが学習データ由来のGPL等のコードをそのまま出力するリスクについては前回記事で解説しました。出力時にライセンス表示は付かないので、気づかないまま混入します。セキュリティ脆弱性と違って テストでは見つからない法的リスク です。
主要ツール比較
| ツール | 特徴 | 料金 | 推奨 |
|---|---|---|---|
| FOSSA | ライセンスコンプライアンス特化。深い依存関係解析（推移的依存含む）、デュアルライセンスやバージョン間のライセンス変更まで追跡。SBOM生成。CI連携 | 無料枠あり、有料プランあり | ライセンスコンプライアンスが主要懸念のチーム |
| Snyk Open Source（ライセンス機能） | SCAの脆弱性スキャンに加え、ライセンスポリシー違反の検出も可能。レポートがわかりやすい | 上記参照 | すでにSnykを使っているチーム |
| Trivy（ライセンス機能） | 脆弱性スキャンに加え、ライセンス検出も対応 | 無料 | OSSで統合したいチーム |
| FOSSology | OSS。ファイル単位のライセンス検出。エンタープライズ向けの詳細レポート | 無料 | 監査向けの詳細分析 |
どう選ぶか
- すでにSnykを使っている → Snykのライセンス機能を有効にするだけで最低限カバーできる
- ライセンスコンプライアンスが契約上の要件（受託開発・エンタープライズ向けSaaS）→ FOSSA が最も強力。推移的依存（依存の依存）のライセンスまで追跡するのは、このカテゴリで最も深い。受託開発で顧客にライセンス保証を求められた場合、FOSSAのレポートがそのまま契約上の証跡になります。前回記事で触れた「AIを安全に使いこなしている会社としての差別化」を、ライセンス面でも実現できるポイントです。
- OSSで完結したい → Trivy のライセンス機能 + FOSSology で詳細分析
スキャン結果を「納品物」にする（レベル2の差別化）
レベル2、特に受託開発では、スキャンは「自社でチェックする」だけでなく 「顧客にどう担保したかを示す」 ところまでがゴールです。具体的には以下の成果物をプロジェクトの納品物・証跡に含めることを検討してください。
-
SBOM（Software Bill of Materials）：使用しているOSSの一覧と各バージョン。Trivyの
trivy sbomやFOSSAで自動生成できます。 - ライセンスレポート：各依存パッケージのライセンス種別と、ポリシー違反の有無。FOSSAのレポートがそのまま使えます。
- スキャン合否レポート：CI上で実行したSAST/SCA/シークレットスキャンの合否結果。CIのアーティファクトとして保存し、必要に応じて提出。
これらを納品に含める体制を整えておくと、前回記事で触れた 「AIを安全に使いこなしている会社としての差別化」 がライセンス・品質の両面で具体化します。
Copilot のコード参照フィルタ
ツールとは別の観点ですが、GitHub Copilotには 「公開コードとの一致をブロックするフィルタ（Suggestions matching public code）」 があります。これを有効にすると、学習データ中の公開コードと一致する補完候補を出力しなくなります。
このフィルタは、GitHub CopilotのIP補償（著作権侵害クレームへのベンダー補償）の 適用条件 でもあります。IP補償を受けたいなら、このフィルタは必ず有効にしてください。設定画面（Organization / Enterprise settings → Copilot → Policies）から切り替えられます。
7. Content Exclusion・権限制御 ── 送る前に止める
なぜ「入口で止める」が大事か
ここまでのツールは「出力をチェックする」ものでしたが、このカテゴリは 「そもそもAIに送らない」 アプローチです。機密ファイルがAIのコンテキストに入らなければ、漏洩しようがありません。
ツール別の設定方法
AIコーディングツールごとに仕組みが異なるので、主要なものを整理します。
GitHub Copilot：Content Exclusion
Copilot Business / Enterpriseプランで利用可能。リポジトリ・Organization・Enterprise単位で、AIに参照させないファイルパスを指定できます。
設定場所：Organization Settings → Copilot → Content exclusion
# 例：設定できるパスパターン
/src/secrets/**
*.pem
*.key
.env
internal-config.yaml
注意点：2026年6月時点で、Content Exclusionは Copilot CLI、Cloud Agent、Agent Mode（VS Code等のEdit/Agent Mode）には未対応 です。通常のインラインサジェストとCopilot Chatには効きますが、AI駆動開発で多用されるCLIやエージェント型の動作では無視されます。「設定したから安心」とはいかない重要な制約です。エージェント型を使う場合は、シークレットスキャン（セクション1）との併用が必須になります。
Claude Code：permissions.deny
Claude Codeでは、.claude/settings.json の permissions.deny で、AIがアクセスできないファイルを指定します。
{
"permissions": {
"deny": [
"Read(./.env)",
"Read(./.env.*)",
"Read(**/*.pem)",
"Read(**/*.key)",
"Read(~/.ssh/**)"
]
}
}
注意点：.claudeignore はClaude Codeに存在する仕組みで、Glob/Grepのスコープからファイルを除外できます。ただし、明示的な Read ツールによる読み取りは防げないバグが複数報告されています。確実に機密ファイルへのアクセスを制御するなら、permissions.deny を使ってください。プロジェクトのルートに .claude/settings.json を置いてチームで共有するのが正解です。
Cursor：.cursorignore / .cursorindexignore
Cursorでは .cursorignore（AIのコンテキスト全般から除外）と .cursorindexignore（インデックスから除外）の2種類があります。.gitignore と同じ書式です。
エージェント権限の設計
Content Exclusionは「ファイルを読ませない」制御ですが、エージェント型ツールでは 「何を実行してよいか」 の制御も必要です。
-
Claude Code：
permissions.denyでコマンド実行（Bash）やファイル書き込み（Write）も制御可能。allowedToolsでホワイトリスト方式にもできる。 - GitHub Copilot：Agent Modeの管理者制御（有効/無効の切り替え、Visual Studioではグループポリシーでの無効化）が可能。
レベル2以上では、「デフォルトは最小権限、必要に応じて解放」 の原則でエージェントの権限を設計してください。「とりあえず全権限」は、前回記事で触れた「エージェントの過剰な権限」リスクに直結します。
8. DAST（動的解析） ── 実行時の脆弱性を検出する
SASTとの違い
SASTはコードを実行せずに解析する「ホワイトボックス」テスト、DASTはアプリケーションを実際に動かして外部からリクエストを送る「ブラックボックス」テストです。SASTでは見つけにくい認証・認可の不備、CORSの設定ミス、レスポンスヘッダの漏れなどを検出します。
AI駆動開発だからといってDASTの要件が大きく変わるわけではありませんが、AIが生成したAPI実装をテストする 際にはSASTだけではカバーしきれない脆弱性が出やすいため、レベル2以上では組み込みを推奨します。
主要ツール
| ツール | 特徴 | 料金 |
|---|---|---|
| OWASP ZAP | OSSのDASTツールの定番。自動スキャン＋手動テスト。CI統合可。活発なコミュニティ | 無料 |
| Burp Suite | セキュリティテストの業界標準。Professional版は強力だが手動テスト寄り。CI統合はEnterprise版 | Community版は無料、Professional $449/年〜 |
レベル別の推奨
- レベル1：基本は不要。社内ツールやAPIを外部公開しないプロダクトなら、機能テスト・結合テストで十分。ただし、ユーザー数が増えてきた段階や、決済・個人情報など機微な情報を扱い始めた段階では、レベル2への移行を待たずにDASTの導入を検討する価値がある。
- レベル2：OWASP ZAP をCIに組み込み、ステージング環境へのデプロイ後に自動スキャン。
- レベル3：ZAP + 専門家による手動ペネトレーションテストの併用
9. LLMゲートウェイ ── AI利用を集中統制する
何をするものか
複数のチーム・複数のLLMプロバイダーをまたいでAIを使う組織で、予算・レート制限・アクセス制御・監査ログを一元管理するためのプロキシサーバーです。前回記事で触れた「ガバナンス用のゲートウェイ」の具体的な選択肢です。レベル3では必須に近く、レベル2でもコスト管理の目的で検討の価値があります。
主要ツール比較
| ツール | 特徴 | 料金 | 推奨 |
|---|---|---|---|
| LiteLLM | OSSのLLMプロキシ。100+プロバイダーをOpenAI互換のAPIで統一。仮想キーごとの予算管理、レート制限、フォールバック。Docker一発で起動 | 自ホストなら無料（MIT）、エンタープライズ版あり | セルフホスト派・コスト重視 |
| Portkey | マネージドSaaS型ゲートウェイ。セマンティックキャッシュ、ガードレール、監査証跡、SOC 2対応 | $499/月〜 | エンタープライズ機能が必要な場合 |
| Kong AI Gateway | Kong APIゲートウェイのLLMプラグイン。OIDCによるSSO、プラグインアーキテクチャ | エンタープライズライセンス | すでにKongを運用しているチーム |
いつ必要か
- レベル1〜2：通常は不要。ただしUberの事例（年間予算を4ヶ月で使い切った）のように、利用が急拡大するリスクがあるなら、LiteLLMで利用量の可視化だけでも始める価値がある。
- レベル3：仮想キーによるチーム別のアクセス制御と予算管理、全リクエストの監査ログが必要。LiteLLMのセルフホストか、Portkey（SOC 2対応が必要な場合）が候補。
CIパイプラインの設計：レベル別の概念図
ここまでのツールを、CIパイプラインにどう組み込むかの全体像を示します。
レベル1：最小構成
コミット前 PR作成時（CI）
┌──────────────┐ ┌─────────────────────┐
│ Gitleaks │ │ Dependabot │
│（pre-commit）│ ──→ push ──→ │（自動脆弱性チェック）│
└──────────────┘ └─────────────────────┘
│
人間がレビュー
│
マージ
所要時間：1〜2時間で設定完了。コストはゼロ。
レベル2：標準構成
コミット前 PR作成時（CI）
┌──────────┐ ┌──────────────────────────────┐
│ Gitleaks │ │ TruffleHog（シークレット） │
│（secret）│ │ Snyk / Trivy（SCA） │
└──────────┘ │ Socket（slopsquatting） │
│ Semgrep（SAST + AIルール） │
│ FOSSA / Snyk（ライセンス） │
│ OWASP ZAP（DAST）※ステージング│
└──────────────────────────────┘
│
┌───────┴────────┐
│ 品質ゲート判定 │
└───────┬────────┘
┌────────┴────────┐
✅ PASS ❌ FAIL
│ │
人間レビュー マージブロック
│ （自動で拒否）
マージ
所要時間：初期構築に1〜2日（既存CIがある前提）。ツール費用は、OSS構成（Gitleaks + TruffleHog + Trivy + Semgrep OSS + OWASP ZAP）＋ GitHub Actionsの無料枠内なら実質無料で組めます。有料ツール（Snyk Team, FOSSA, Socket等）を足すと月数万円〜。無料だけでもレベル2の要件はカバーできるので、まずはOSSで始めて、必要に応じて有料ツールを足すのが現実的です。
ポイント：レベル1との本質的な違いは 「品質ゲートで自動ブロックするかどうか」 です。レベル1は人間のレビュー頼りですが、レベル2はツールが基準を満たさないPRのマージを自動で拒否します。
注意：CIが赤くなるだけではマージは止まらない
ここで見落とされがちな落とし穴があります。GitHub Actionsでスキャンが失敗しても、既定ではマージボタンは押せるままです。バツ印が出るだけで、人間が無視してマージできてしまう ── これでは実質レベル1と変わりません。
自動ブロックを実現するには、ブランチ保護（Branch protection rules）でステータスチェックをRequiredにする 設定が必要です。
設定手順：Repository Settings → Branches → Branch protection rules → 対象ブランチ（main 等）を選択 → 「Require status checks to pass before merging」を有効化 → CIジョブ名（例：security-scan、semgrep）をRequiredに追加。
この設定で初めて「CIが赤 → マージ不可」が強制されます。レベル2のCI構成を組んだら、ブランチ保護の設定もセットで行ってください。
既存リポジトリへの導入：いきなりblockにしない
ここまでの説明は新規プロジェクト前提ですが、レベル2の読者の多くは 既存リポジトリに後付けで導入する はずです。このとき、最初から「CIが赤 → マージブロック」にすると、過去に蓄積された脆弱性やライセンス指摘（いわゆる技術的負債）が一斉に検出され、今回の変更とは無関係なPRまで全部赤になります。開発が完全に止まるので、チームに無効化されて終わりです。
段階的に導入するのが現実的です。
- Report-only（助言モード）で導入する。CIにスキャンを組み込むが、結果をレポートするだけでマージはブロックしない。まずチームが「どんな指摘が出るか」を把握するフェーズ。
- 既存指摘を棚卸しする。出てきた指摘を「すぐ修正」「リスクを受容（ベースライン化）」「後回し（チケット化）」に分類する。ツールによってはベースライン機能があり、既存の指摘を「既知」としてマークして新規の指摘だけを表示できます。
- block化する。棚卸しが終わったら、新規の指摘のみでCIを落とす設定に切り替える。
- ブランチ保護でRequiredにする。ここで初めて「マージブロック」が自動で効く状態になる。
例外：シークレットスキャン（Gitleaks / TruffleHog）だけは最初からblockで構いません。APIキーやパスワードの漏洩は「後で直す」が許されない類のリスクなので、既存リポでも初日からブロックする価値があります。
レベル3：上記 + インフラレベルの統制
レベル2の構成に加えて以下が入ります。
- LLMゲートウェイ（LiteLLM / Portkey）を全チームのAI利用の前段に配置
- 監査ログを改ざん不能な形で保存（SIEM連携）
- Content ExclusionをOrganization / Enterprise単位で強制設定
- 定期的なペネトレーションテスト（四半期〜年次）
所要時間：インフラ設計を含め数週間〜数ヶ月。専任のセキュリティエンジニアまたは外部コンサルが必要になることが多い。
補足：自動ツールでは見つからないもの ── 攻撃的監査
ここまで9カテゴリのツールを紹介しましたが、一つ正直に書いておくべきことがあります。これらを全部入れても、見つからない脆弱性があります。
Semgrepが見つけるのは「SQLインジェクションのパターン」、Trivyが見つけるのは「CVEが付いた既知の脆弱性」です。いずれも 既知のパターンとの照合 であり、「このシステム固有のロジックの穴」は検出範囲の外です。
たとえば、認証チェックをバイパスできるIDOR（他人のリソースに直接アクセスできる）、並行処理の競合状態、エラー処理で「失敗しているのに成功を返す」偽の成功、到達不能なデッドコードに残った古い認証情報 ── こうしたバグは、コードの意味を理解して「攻撃者ならここを突く」と考えないと見つかりません。パターンマッチでは原理的に拾えない領域です。
ここをカバーするのが 攻撃的監査（adversarial audit） です。コードを「守る側」ではなく「攻撃者の視点」で読み、ロジックの穴を探すアプローチです。従来はペネトレーションテスターの仕事でしたが、AI駆動開発ではAI自身にこの役割を担わせることもできます。具体的には、実装を書いたエージェントとは別のエージェント（または別のプロンプト）に「このコードを攻撃する方法を考えろ」と指示し、見つかった指摘をさらに別のエージェントが検証して誤検知を排除する ── という交差検証の仕組みです。
自動ツールを入れた上で、リリース前の最終チェックとしてこの観点を加えると、カバレッジが一段上がります。筆者が公開しているフレームワーク（AI Orchestrator）では、この攻撃的監査を audit スキルとして組み込んでいます。
補足：AI生成コードのPRテンプレート
前回記事で「プルリクエストに『AI生成を含むか』を書く欄を設ける」と提案しましたが、具体的にどう書くか。シンプルなテンプレート例を示します。
## AI利用チェック
- [ ] この変更にはAI生成コードを含む
- 使用ツール：（例：Claude Code / Copilot / Cursor）
- 生成箇所の概要：（例：認証モジュールのバリデーション部分）
## AI生成コードの追加チェック（該当する場合）
- [ ] 生成コードのロジックを理解し、意図どおりに動作することを確認した
- [ ] ハードコードされたシークレットがないか確認した
- [ ] AIが提案したパッケージの実在性・正規性を確認した
- [ ] ライセンス上の問題がないか確認した（Copilotのフィルタ有効 / ライセンススキャン通過）
このテンプレートを .github/PULL_REQUEST_TEMPLATE.md に置いておくだけで、レビュアーが「AI生成箇所に注意を向ける」習慣ができます。ツールの導入より先にできる、コストゼロの対策です。
まとめ：自社のレベルに合わせて、小さく始める
一気に全部入れようとすると挫折します。レベルに応じた優先順位を意識してください。
最小で始めるなら（レベル1）
- Gitleaks（pre-commit） ── 5分で設定完了
- Dependabot（GitHub設定画面で有効化） ── 数クリック
- PRレビューの習慣 ── ツールではなく運用
この3つだけで、AI駆動開発の基本的な安全網はできます。
次に足すなら（レベル2に向けて）
- Semgrep をCIに追加 ── AI Securityルールパックも有効に
- Socket or Snyk をCIに追加 ── slopsquatting対策
- FOSSA or Snykのライセンス機能 ── ライセンス汚染対策
- Content Exclusion を各ツールで設定 ── 機密ファイルの送信防止
企業として統制するなら（レベル3に向けて）
- LLMゲートウェイ で利用量とアクセスを集中管理
- DAST（OWASP ZAP）と定期的なペネトレーションテスト
- 監査ログ基盤 の整備
前回記事で「どのレベルで、どこまでリスクを取るか」という考え方を定め、本記事で具体的なツールを選ぶ。あとはCIに組み込んで回す段階です。ただし、CIの設定はローカルでは気づけない壊れ方をすることが多いので、実環境で一度グリーンになるまでは完成ではありません。最初のPRが通るところまで見届けてください。この2記事がセットで、AI駆動開発のセキュリティを「考え方」と「実装」の両面からカバーすることを目指しました。
まずはレベル1の3点（Gitleaks + Dependabot + PRレビュー）から始めてみてください。1〜2時間後には、最低限の安全網が動いています。
参考
- 各ツールの公式ドキュメント（Gitleaks, TruffleHog, Snyk, Socket, Semgrep, FOSSA, OWASP ZAP, LiteLLM, Portkey）
- Semgrep「Detect risks in AI-generated code with Semgrep Guardian」（2026年5月）
- Socket.dev「2026 Software Supply Chain Security Report」
- GitHub Docs「Content exclusion for GitHub Copilot」
- Anthropic「Claude Code permissions documentation」
- 前回記事：「AI駆動開発のセキュリティ、結局どこまでやればいい？」
※ ツールの料金・機能は2026年央時点の情報です。導入時には最新の公式サイトを確認してください。