AIコーディングツール（Claude CodeやGitHub Copilotなど、コード生成を支援するAIエージェント）を導入したチームで、SAST（静的アプリケーションセキュリティテスト、コードを実行せずに脆弱性を検出する仕組み）の警告が急増するケースが増えています。CIパイプラインを止めるほどのアラート洪水が起き、開発者がツールを無視し始める現象です。
セキュリティ担当者やDevOpsエンジニアで、AIツール導入後にSASTの誤検知率が上がったと感じているなら、原因と対処法を整理しておく価値があります。
何が起きるか
AIコーディングツールは短時間で大量のコードを生成します。人間が1日に書く量の何倍もの差分がPRに積まれることも珍しくありません。
この差分をSASTスキャナーが全件チェックすると、警告数が従来の比ではなく増えます。開発者が100件のアラートを受け取り、80件が誤検知だった場合、ツールへの信頼はすぐに失われます。
結果として起きるのは、警告を全部無視する運用への逆行です。せっかく導入したSASTが「うるさい通知」としてミュートされ、本当に危険な検出も埋もれてしまいます。
なぜ起きるか
原因は段階的に分解すると見えてきます。
1つ目は、AIが生成するコードのパターンの偏りです。AIツールは学習データに基づいて似た構文・似たライブラリ呼び出しを繰り返す傾向があります。SASTルールがそのパターンを「疑わしい」と機械的に判定しやすくなります。
2つ目は、コンテキストの欠落です。AIが生成した関数は、呼び出し元の権限チェックやサニタイズ処理を前提にしていないことがあります。スキャナーは静的解析なので、実行時の安全性を保証する周辺コードまで追えません。
3つ目は、レビュー速度とスキャン頻度のミスマッチです。AIによってPRの生成速度が上がった一方、SASTのチューニング（誤検知を除外するルール整備）が追いついていないチームが多く見られます。
CVE（共通脆弱性識別子）の公開数自体も年々増加しており、2026年には新規CVEが6万6千件を超えると見込まれています。人手でひとつずつ精査する運用は、AI活用時代にはさらに現実的ではなくなっています。
自分のプロジェクトが該当するか確認する
まず確認すべきは、CIパイプラインでのSAST実行モードです。
# CIの設定ファイルでSASTジョブの動作モードを確認する例（GitHub Actions）
grep -A 5 "sast" .github/workflows/*.ymlこのジョブがfailやblockのような設定でパイプラインを止める動作になっているか確認します。ブロッキング設定のまま誤検知が多い場合、開発速度への影響が大きくなります。
次に、直近のPRでAI生成コードの比率を確認します。GitHub Copilotの提案受け入れ状況や、Claude Codeのコミットログに残るメタデータを見ると、どの範囲がAI主導で書かれたか把握できます。
さらに、誤検知率のログが残っているか確認します。SASTツール（Semgrep、CodeQL、SonarQubeなど）の管理画面には、クローズ済みfindingsの「false positive」ラベル件数が集計されている場合があります。この比率が全体の20%を超えているなら、チューニング不足のサインです。
対策の手順
ステップ1: レポートオンリー期間を設ける
AIツール導入直後、または新しいSASTルールセット導入直後は、2週間程度ブロッキングを止めてreport-onlyモードで運用します。この期間に誤検知パターンをカタログ化します。
# Semgrepでブロッキングせずレポートのみ出力する例
semgrep scan --config auto --output report.json --no-errorステップ2: 抑制ルールをリポジトリにバージョン管理する
誤検知と判断したfindingは、口頭やSlackで共有するだけでなく、抑制ルールとしてコードにコミットします。.semgrepignoreやsonar-project.propertiesのような設定ファイルに記録し、レビュー履歴を残します。
ステップ3: 段階的にゲートを有効化する
チューニング後は、確信度が高く影響が重大な検出のみブロッキング対象にします。それ以外はチケット化してレビューキューに回す運用にします。AIが生成した差分だからといって全件を同じ厳格さで扱う必要はありません。
ステップ4: 重複検出を正規化する
複数のSASTツールを併用している場合、共通の脆弱性分類（CWEなど）でfindingsを正規化し、重複アラートを統合します。同じ脆弱性が3つのツールから3件として報告されると、開発者の疲弊が加速します。
ステップ5: 露出度で優先順位をつける
すべてのCVEやfindingに同じ緊急度で対応するのは非現実的です。インターネット公開システムか内部限定か、個人情報や決済情報を扱うか、WAFなど既存の防御があるか、実際に悪用されている脆弱性かどうかの4軸で優先度を判断します。インターネット公開かつ実際に悪用が確認されているケースは7日以内、内部限定でCVSSスコアが9.0未満のケースはバックログでも構わないといった目安を作ると、チーム内の判断基準が揃います。
導入前後に確認すること
AIコーディングツールの生産性はコード生成速度に表れますが、その速度に比例してセキュリティレビューの負荷も増えます。
次にAIツールを本格導入する前、あるいは既に導入していて警告疲れを感じているなら、以下を確認してみてください。
- CIのSASTジョブがブロッキングかレポートオンリーか
- 誤検知率が20%を超えていないか、ラベル集計で確認する
- 抑制ルールがリポジトリにバージョン管理されているか
- 優先度マトリクスが露出度・データ種別・悪用実績を反映しているか
これらを定期的に見直す運用を組み込むことで、AIが生成する差分量に振り回されず、本当に危険な脆弱性だけに集中できる体制が作れます。