「AI に書かせたコード、誰かがセキュリティを確認してから本番に出していますか？」――この問いに「いいえ」と答えるなら、約半分の確率で脆弱性を抱えたまま公開していることになります。 セキュリティ企業 Veracode が 2025 年に公開した「GenAI Code Security Report」では、100 以上の大規模言語モデル（LLM）に 80 種類のコーディング課題を解かせたところ、生成されたコードの約 45% に OWASP Top 10 級のセキュリティ脆弱性が含まれていたと報告されています（Veracode: 2025 GenAI Code Security Report）。しかも、GPT-5 や Claude、Gemini といった新しいモデルになっても、この 45% という数字はほとんど改善していません。
連載「バイブコーディング危機」は、ここまでの第 1〜10 回（第 1-2 週）で、AI に自社システムを書かせた結果として起こりうる リスクの全体像と致命的な事象（SQL インジェクション・認可漏れ・サービス停止・データ消失・ランサムウェア・法令違反・属人化・バックアップ不全・MFA 未設定）を整理してきました。全体像は連載第 1 回のバイブコーディング危機 概論と 7 つのリスク類型にまとまっています。第 11 回からは **「防衛策の実装編」**に入ります。その第一歩が、本記事のテーマである セキュリティスキャンです。
本記事は連載「バイブコーディング危機」第 11 回です。前回は第 10 回 MFA を「あとで入れる」と言って入れないで「認証の後回し」を扱いました。本記事ではその先にある「生成コードそのものを機械的に検査する仕組み」を解説します。次回は第 12 回 ノーコード／ローコードの技術的負債へ続きます。連載全体は特集ハブ「バイブコーディング危機」からご覧いただけます。
本記事では、なぜ AI 生成コードのスキャンが必須なのか、スキャンの 3 本柱（SAST / DAST / SCA）、主要 3 ツール（OWASP ZAP / Trivy / Snyk）の使いどころ、CI（継続的インテグレーション）に自動スキャンを組み込む手順、中堅企業の現実的な導入ステップ、FAQ を、Veracode・GitHub の大規模分析・OWASP・NIST SSDF を一次ソースに整理します。「AI を使うな」ではなく、AI を使うからこそ、生成物を機械的に検査する仕組みを持ちましょう、という趣旨です。
目次
- なぜAI生成コードはスキャンが必須なのか
- セキュリティスキャンの3本柱：SAST・DAST・SCA
- 主要3ツールの使いどころ：OWASP ZAP・Trivy・Snyk
- CIに自動スキャンを組み込む（シフトレフト）
- 中堅企業の現実的な導入ステップ（30〜90日）
- スキャンだけでは不十分：人のレビューとガバナンス
- 中堅・中小企業が陥りやすい5つの失敗
- 国内・国際の文脈：OWASP・NIST・IPA
- 中堅企業向け30分セキュリティスキャン点検チェックリスト
- いつGXOに相談すべきか
- よくある質問（FAQ 10問）
- 参考一次ソース
- まとめ
- 関連記事
なぜAI生成コードはスキャンが必須なのか
AI コーディング支援ツールは、開発のスピードを大きく上げてくれます。一方で、生成されたコードの品質、とくにセキュリティ面には、無視できない課題があることが、複数の調査で示されています。
Veracode：45%に脆弱性、新しいモデルでも改善せず
Veracode の 2025 年 GenAI Code Security Report は、100 以上の LLM に 80 種類のコーディング課題を解かせ、生成コードを検査しました。その結果、約 45% のコードが OWASP Top 10 級の脆弱性を含んでいたと報告されています。言語別では Java が約 72% の失敗率と最も高く、Python・C#・JavaScript は 38〜45% の範囲でした（Veracode ブログ）。
脆弱性のタイプ別では、さらに踏み込んだ数字が公表されています。同レポートによれば、LLM は クロスサイトスクリプティング（XSS、CWE-80）に対して約 86% のケースで安全なコードを書けず、ログインジェクション（CWE-117）では約 88% のケースで防げなかったとされています。これは「たまに穴が空く」というレベルではなく、「特定の脆弱性カテゴリーでは、AI はほぼ守れない」ことを意味します。
注目すべきは、Veracode が「より大きなモデルが、安全性で有意に優れているわけではない」とまとめている点です（Veracode 2025 GenAI Code Security Report PDF）。GPT-5 や Claude、Gemini といった新しい世代のモデルでも、この比率はほとんど改善していません。つまり、「モデルが賢くなれば安全なコードになる」とは限らず、これはモデル規模で解決する問題ではなく、仕組み（スキャンとレビュー）で塞ぐべき構造的な課題だと考えるのが妥当です。
GitHub リポジトリの大規模分析
公開 GitHub リポジトリを対象にした大規模な実証分析では、7,703 ファイルから 4,241 件の CWE（Common Weakness Enumeration＝共通脆弱性タイプ）インスタンスが、77 種類の異なる脆弱性タイプにわたって検出されたと報告されています（arXiv: Security Vulnerabilities in AI-Generated Code）。AI 生成コードの脆弱性は、特定の種類に偏らず、幅広く分布していることがわかります。
「速く書ける」と「安全に動く」は別物
AI コーディング支援によって、コード生成のスピードは大きく向上します。しかし、生成スピードが上がるほど、レビューや検査が追いつかなくなり、脆弱性の指摘件数も増える傾向が報告されています。スピードの恩恵を安全に享受するには、人手のレビューに加えて、機械的に脆弱性を検出するスキャンの仕組みが欠かせません。
要点：AI 生成コードのスキャンは、AI を疑うためではなく、AI を安心して活用するための仕組みです。約 45% という数字は、「たまたま運が悪いと脆弱性が入る」のではなく、「標準的に検査が必要」であることを示しています。
FREE CONSULTATION
この記事の内容について、専門家に相談できます
AI・DX・セキュリティに関するご質問やお見積もりなど、お気軽にお問い合わせください。
セキュリティスキャンの3本柱：SAST・DAST・SCA
セキュリティスキャンは、検査する対象と方法によって、大きく 3 つに分けられます。AI 生成コードを守るには、この 3 本柱を組み合わせることが基本になります。
| 種類 | 何を検査するか | いつ実行するか | 代表的に見つかるもの |
|---|---|---|---|
| SAST（静的アプリケーションセキュリティテスト） | ソースコードそのものを解析 | コードを書いた直後・CI 上 | SQL インジェクション・XSS・ハードコードされた秘密情報 |
| DAST（動的アプリケーションセキュリティテスト） | 実際に動作させて外部から検査 | アプリを起動した状態 | 認証・セッションの不備・設定ミス・実行時の挙動 |
| SCA（ソフトウェアコンポジション解析） | 使用しているライブラリ・依存関係を検査 | ビルド時・CI 上 | 既知の脆弱性を持つライブラリ（Log4j 等）・ライセンス問題 |
SAST（静的解析）：書いたコードを読む
SAST は、プログラムを実行せずに ソースコードを解析して、脆弱性につながりそうなパターンを検出します。AI が生成したコードに含まれがちな「入力値の検証漏れ」「秘密情報のハードコード」などを、書いた直後に見つけられます。本連載の第 2 回 SQL インジェクションの現実 5 パターン・第 3 回 認可漏れの現実 5 シーンで扱ったような問題の多くは、SAST で早期に検出できます。
たとえば、AI に「ユーザー名で検索する処理を書いて」と頼むと、次のような 悪い例が生成されることがあります。
// 悪い例：ユーザー入力をそのまま SQL に連結（SQL インジェクション）
const query = "SELECT * FROM users WHERE name = '" + req.query.name + "'";
db.query(query);
SAST ツールは、この「文字列連結で SQL を組み立てている」パターンを検出し、警告します。あるべき姿は、プレースホルダ（パラメータ化クエリ）を使う 良い例です。
// 良い例：パラメータ化クエリで入力値を分離
const query = "SELECT * FROM users WHERE name = ?";
db.query(query, [req.query.name]);
人のレビューでこの違いを毎回見抜くのは負担が大きく、見落としも起きます。SAST は、この種の典型パターンを機械的に・漏れなく指摘してくれる点に価値があります。
DAST（動的解析）：動かして外から叩く
DAST は、アプリケーションを 実際に動作させた状態で、外部から擬似的な攻撃リクエストを送り、応答を見て脆弱性を検出します。ソースコードを読むだけでは分からない、認証・セッション管理・設定の不備などを見つけるのに向いています。本記事で後述する OWASP ZAP が代表的なツールです。
SCA（依存関係解析）：部品の脆弱性を洗い出す
現代のソフトウェアは、多数のオープンソース・ライブラリの上に成り立っています。SCA は、使用している ライブラリ・依存関係に既知の脆弱性がないかを検査します。2021 年の Log4j 脆弱性（CVE-2021-44228）のように、自社で書いたコードは正しくても、使っている部品に脆弱性があるケースを防ぎます。これは連載第 8 回でも触れた「ソフトウェア部品表（SBOM）」の考え方とも直結します。
AI に依存関係を選ばせると、別のリスクも生じます。実在しないパッケージ名を「もっともらしく」提案し、攻撃者がその名前で悪意あるパッケージを先回り公開する **スロップスクワッティング（hallucinated dependency）**は、SCA とパッケージ管理ルールの両面で対策が必要なテーマです（この問題は本連載の依存関係汚染の回でも掘り下げます）。SCA は「既知の脆弱性を持つ部品」を検出する仕組みですが、こうした新種のサプライチェーン・リスクと組み合わせて考える必要があります。ライセンス面の汚染リスクについては第 13 回 OSS ライセンス汚染の現実もあわせてご参照ください。
主要3ツールの使いどころ：OWASP ZAP・Trivy・Snyk
ここでは、中堅企業でも導入しやすい代表的な 3 ツールを紹介します。いずれも無料で始められる範囲があります。
OWASP ZAP（DAST）：動かしたアプリを外から検査
OWASP ZAP（Zed Attack Proxy） は、OWASP（Open Worldwide Application Security Project）が提供する無料・オープンソースの DAST ツールです（OWASP ZAP 公式）。起動中の Web アプリケーションに対して擬似的な攻撃リクエストを送り、XSS・設定ミス・認証の不備などを検出します。
- 向いている用途：Web アプリ・API の動的検査
- 使いどころ：ステージング環境のアプリに対して定期的に実行
- 特徴：GUI でも CLI でも使え、CI への組み込みも可能
Trivy（SCA・コンテナ・IaC・シークレット）：幅広く一括検査
Trivy は、Aqua Security が提供する無料・オープンソースのスキャナで、依存ライブラリの脆弱性（SCA）・コンテナイメージ・IaC（Infrastructure as Code）・ハードコードされた秘密情報まで、幅広く一括で検査できます（Trivy 公式）。
- 向いている用途：依存関係・Docker イメージ・Terraform などの設定ファイル
- 使いどころ：ビルド時・CI 上で、コンテナや依存関係をまとめてスキャン
- 特徴：導入が容易で、1 つのツールで多くの対象をカバーできる
なお、Trivy 自体を狙ったサプライチェーン上のリスクや、スキャナの運用面については、Trivy を使ったサプライチェーン保護の解説記事もあわせてご参照ください。
Snyk（SAST・SCA）：開発者フレンドリーな統合スキャン
Snyk は、依存関係（Snyk Open Source）・ソースコード（Snyk Code＝SAST）・コンテナ・IaC を統合的に検査できるツールです（Snyk 公式）。無料プランがあり、検出した脆弱性の修正方法を具体的に提示してくれる点が、開発者にとって使いやすいとされています。
- 向いている用途：依存関係 + ソースコードの統合スキャン
- 使いどころ：開発者の手元（IDE 連携）・CI の両方
- 特徴：修正提案がわかりやすく、開発フローに組み込みやすい
Semgrep（SAST）：オープンソースで始める静的解析
Semgrep は、無料のオープンソース版（Community Edition）がある SAST ツールで、30 以上の言語に対応します（Semgrep 公式）。コミュニティが整備した無料のルールセット（OWASP Top 10 や言語・フレームワーク別の検査ルール）が公開されており、自社の構成に合わせてルールを追加・除外できます。
- 向いている用途：ソースコードの静的解析。秘密情報のハードコードや典型的な脆弱性パターンの検出
- 使いどころ：開発者の手元（IDE・pre-commit）と CI の両方
- 特徴：変更されたファイルだけを検査する「差分スキャン」に対応し、プルリクエストの検査は短時間で完了する。結果を SARIF 形式で出力でき、GitHub の「Security」タブに表示できる
「有償ツールはまだ判断が難しい」という段階でも、Semgrep CE のように 完全に無料・オープンソースで始められる SAST があることは、中堅企業にとって導入の障壁を大きく下げます。
Dependabot（SCA・GitHub 標準）：設定ゼロに近い依存関係監視
GitHub を使っているなら、Dependabot は最も手軽な SCA の出発点です。Dependabot は、公開・非公開を問わずすべての GitHub リポジトリで無料で利用でき、外部サービスや API トークンを必要としません（GitHub Docs: Dependabot alerts）。
- リポジトリの依存関係が GitHub Advisory Database の脆弱性に該当すると、CVE 情報・深刻度・影響を受けるバージョン・修正済みバージョンを含むアラートを自動で作成します
- 「Dependabot security updates」を有効にすると、修正済みの最小バージョンへの更新プルリクエストを自動で作成します（破壊的変更を避けるため、最新版ではなく「直る最小限」へ上げます）
GitHub を使う中堅企業なら、まず Dependabot を有効化するだけで、依存関係（SCA）の監視は今日から始められます。
3ツールの組み合わせ方
| 検査したいもの | 推奨ツール（無料で始められるもの） |
|---|---|
| ソースコードの脆弱性（SAST） | Semgrep CE / Snyk Code |
| 動かしたアプリの脆弱性（DAST） | OWASP ZAP |
| 依存ライブラリの脆弱性（SCA） | Dependabot（GitHub 標準）/ Trivy / Snyk Open Source |
| コンテナ・IaC・秘密情報 | Trivy |
すべてを一度に導入する必要はありません。無料で始める順序としては、(1) GitHub を使っているなら Dependabot を有効化（SCA）、(2) Trivy で依存関係・コンテナ・秘密情報を一括スキャン、(3) Semgrep CE または Snyk Code でソースコードを SAST、(4) Web アプリがあれば OWASP ZAP で DAST を加える、という順番が現実的です。お金をかける前に、まず無料ツールで「自社の現状」を可視化することをおすすめします。
CIに自動スキャンを組み込む（シフトレフト）
スキャンツールは、手元で 1 回実行するだけでは効果が限られます。最も効果的なのは、CI（継続的インテグレーション）に組み込み、コードを変更するたびに自動で検査することです。これは連載の文脈でいえば「セキュリティ・バイ・デザイン」「シフトレフト」（できるだけ前工程で検査する考え方）の実践にあたります。
プルリクエスト時に自動スキャン
GitHub Actions・GitLab CI などの仕組みを使うと、プルリクエスト（コードの変更提案）が作られるたびに、自動でスキャンを走らせることができます。AI が生成したコードも、人が書いたコードも、本番に入る前に同じ検査を通過させられます。
たとえば GitHub Actions で Semgrep の SAST スキャンを組み込む場合、おおむね次のような最小構成になります（公式の設定例をもとにした概念図です）。
# .github/workflows/semgrep.yml（概念例）
name: semgrep
on:
pull_request: {} # プルリクエストごとに実行
push:
branches: [main]
jobs:
semgrep:
runs-on: ubuntu-latest
container:
image: semgrep/semgrep
steps:
- uses: actions/checkout@v4
- run: semgrep ci # 変更分を中心に静的解析を実行
Trivy（SCA・コンテナ・IaC・シークレット）や OWASP ZAP（DAST）も、それぞれ公式の GitHub Action が公開されており、同じ要領でワークフローに追加できます。重要なのは、「人が忘れても、機械が必ず検査する」状態を作ることです。
スキャン結果を「ゲート」にする
重大な脆弱性が見つかった場合は、マージ（本番への取り込み）をブロックする設定にできます。これにより、「うっかり脆弱性を含んだまま本番に出す」ことを、仕組みで防げます。最初から厳しくしすぎると開発が止まるため、まずは Critical・High のみブロックし、徐々に基準を上げていくのが現実的です。
具体的なゲートの設計は、深刻度に応じて段階を分けると運用しやすくなります。
| 深刻度 | CI での扱い | 運用方針 |
|---|---|---|
| Critical | マージをブロック（FAIL） | 即時対応。例外を認めない |
| High | マージをブロック（FAIL）／導入初期は警告 | 原則ブロック。やむを得ない場合は責任者承認で一時例外 |
| Medium | 警告（WARN）にとどめる | バックログ化して計画的に対応 |
| Low / Info | 記録のみ | 定期レビューでまとめて棚卸し |
OWASP ZAP の GitHub Action でも、検出された各アラートを **WARN（警告のみ・パイプラインは止めない）/ IGNORE（無視）/ FAIL（見つかったらパイプラインを失敗させる）**として個別に指定でき、自社の方針に合わせて「どれを本番ブロックにするか」を調整できます。なお ZAP には、攻撃を行わず短時間で終わる **ベースラインスキャン（受動的）**と、実際に擬似攻撃を行ってより深く検査する **フルスキャン（能動的）**があり、本番環境ではなくステージング環境に対してフルスキャンを定期実行するのが一般的です。
誤検知（false positive）への備え
スキャンツールは、実際には問題のない箇所を「脆弱性かもしれない」と報告すること（誤検知）があります。これを放置すると「どうせ誤検知だろう」と全体が形骸化します。誤検知は記録して除外設定する、判断に迷うものは専門家に相談するといった運用を、最初に決めておくことが大切です。
誤検知のトリアージ（仕分け）は、次のような流れを決めておくと現場が回ります。
- 本物か誤検知かを判定する：再現条件・到達経路（実際に外部から触れるか）を確認する
- 本物なら深刻度に応じて対応：Critical / High は即時、Medium 以下はバックログへ
- 誤検知なら「理由を添えて」除外する：単に無視するのではなく、「なぜ問題ないか」をコメントやインラインの抑制設定で残す（後任者が判断を引き継げるようにする）
- 判断に迷うものは保留して相談する：特に認可・暗号・個人情報の取り扱いは、自己判断で「たぶん大丈夫」としないことが重要です
「誤検知を理由なく全部消す」運用は、本物の脆弱性まで一緒に消してしまう温床になります。抑制には必ず理由を残す——これが、スキャンを形骸化させないための地味だが効果的なルールです。
中堅企業の現実的な導入ステップ（30〜90日）
専任のセキュリティ担当がいない中堅・中小企業でも、段階的にスキャンを導入できます。
ステップ1（〜30日）：無料ツールで現状を可視化
まず Trivy で依存関係・コンテナを、Snyk Code でソースコードをスキャンし、今どれだけ脆弱性があるかを可視化します。最初の結果は数が多くて驚くかもしれませんが、それが現状です。Critical・High から優先的に確認します。
ステップ2（〜60日）：CIに組み込む
スキャンを CI に組み込み、プルリクエストごとに自動実行されるようにします。この段階では、まだマージはブロックせず「検出結果を表示するだけ」でも構いません。チームがスキャン結果を見る習慣をつけることが目的です。
ステップ3（〜90日）：ゲート化と運用定着
Critical・High の脆弱性が見つかったらマージをブロックする「ゲート」を設定します。あわせて、誤検知の除外ルール・対応の責任者・定期レビューの仕組みを決めて、運用として定着させます。Web アプリがあれば、この段階で OWASP ZAP による DAST を加えます。
導入の優先順位
| 優先度 | 対象 | ツール例 |
|---|---|---|
| 最優先 | 依存ライブラリ（既知の脆弱性） | Trivy / Snyk Open Source |
| 高 | ソースコード（SAST） | Snyk Code |
| 中 | 秘密情報のハードコード | Trivy（シークレット検出） |
| 状況に応じて | 動かしたアプリ（DAST） | OWASP ZAP |
スキャンだけでは不十分：人のレビューとガバナンス
セキュリティスキャンは強力ですが、万能ではありません。スキャンを「導入したから安心」とせず、次の点を補う必要があります。
- スキャンで見つからない問題もある：業務ロジックの誤り・権限設計の不備など、ツールが判断しにくい問題は、人のレビューが必要です（連載第 3 回の認可漏れが典型例です）
- 誤検知のトリアージ：検出結果のうち、本当に対応が必要なものを見極める判断が要ります
- 「誰が責任を持つか」を決める：スキャン結果を誰が確認し、誰が対応を判断するかを決めておかないと、結果が放置されます
- AI 生成コードのレビュー方針：AI に書かせたコードを、人がどこまで確認してからマージするかのルールを持つことが大切です
スキャンは「機械でできる検査を自動化する」もので、人による設計レビューとガバナンスと組み合わせて初めて効果を発揮します。
中堅・中小企業が陥りやすい5つの失敗
1. AI生成コードを無検査で本番投入する
「動いているから大丈夫」とスキャンを省くケースです。約 45% の確率で脆弱性が含まれる以上、無検査の本番投入は避けたいところです。とくに個人情報や決済を扱うシステムでは、脆弱性が法令上の問題（漏えい報告義務など）に直結します。法令面のリスクは第 7 回 法令違反の罠：電子帳簿＋特商法＋改正個情法もあわせてご確認ください。
2. ツールを導入したが結果を見ていない
スキャンは走っているものの、誰も結果を確認していないケースです。検出結果を見る習慣と責任者がいないと、導入の意味が薄れてしまいます。
3. 誤検知に疲れて全体を無効化する
誤検知が多くて「もう全部無視」となるケースです。誤検知は除外設定で個別に対応し、全体の無効化は避けます。
4. 依存関係（SCA）を検査していない
自社コードだけ検査し、使っているライブラリの脆弱性を見ていないケースです。Log4j のように、部品の脆弱性が致命傷になることがあります。
5. CIに組み込まず手動実行のまま
手元で時々スキャンするだけで、CI に組み込んでいないケースです。変更のたびに自動実行されないと、検査漏れが起こりやすくなります。
国内・国際の文脈：OWASP・NIST・IPA
セキュリティスキャンの考え方は、国内外の主要な枠組みでも重視されています。
OWASP「Top 10」と各種プロジェクト
OWASP は、代表的な脆弱性をまとめた 「Top 10」 や、無料の DAST ツール ZAP を提供しています（OWASP 公式）。AI 生成コードに含まれる脆弱性の多くは、この OWASP Top 10 の範囲に収まります。
NIST「Secure Software Development Framework（SSDF）」
米 NIST の 「Secure Software Development Framework（SSDF, SP 800-218）」 は、開発のライフサイクル全体に安全な開発の実践を組み込む枠組みで、スキャン・テストの自動化もその一部に位置づけられています（NIST SSDF）。
IPA「安全なウェブサイトの作り方」
IPA（情報処理推進機構）は 「安全なウェブサイトの作り方」 など、脆弱性対策の具体的な解説を公開しています（IPA: 安全なウェブサイトの作り方）。スキャンで検出した脆弱性の意味を理解するうえで、参考になります。これらの枠組みを開発工程に継続的に組み込む取り組みは、一般に DevSecOps（開発・セキュリティ・運用の統合）と呼ばれます。
中堅企業向け30分セキュリティスキャン点検チェックリスト
専任のセキュリティ担当がいなくても、30 分あれば自社の「検査の現状」を点検できます。情シス 1〜3 名の体制を想定し、今日その場で確認できる項目に絞りました。一つでも「いいえ」があれば、その項目が次の改善対象です。
| # | 確認項目（30分で点検可能） | はい / いいえ |
|---|---|---|
| 1 | AI 生成コードを本番に出す前に、何らかのセキュリティスキャンを通しているか | □ / □ |
| 2 | 依存ライブラリ（SCA）の脆弱性監視をしているか（GitHub なら Dependabot を有効化しているか） | □ / □ |
| 3 | ソースコードの静的解析（SAST）を、少なくとも 1 ツール導入しているか | □ / □ |
| 4 | スキャンが CI（プルリクエスト）で自動実行されるか。手動実行に頼っていないか | □ / □ |
| 5 | Critical・High の脆弱性で、マージをブロックするゲートがあるか | □ / □ |
| 6 | スキャン結果を「誰が確認し、誰が対応を判断するか」が決まっているか | □ / □ |
| 7 | 誤検知を抑制する際、「なぜ問題ないか」の理由を残すルールがあるか | □ / □ |
| 8 | 秘密情報（API キー・パスワード）のハードコードを検出する仕組みがあるか | □ / □ |
| 9 | Web アプリがある場合、DAST（OWASP ZAP 等）をステージングで定期実行しているか | □ / □ |
| 10 | 既に本番稼働中のシステムについて、一度でも全体スキャンをしたことがあるか | □ / □ |
「はい」が 3 つ以下なら、まずは項目 1・2・3（無検査の解消・Dependabot 有効化・SAST 1 本導入）から着手するのが現実的です。秘密情報（API キー・パスワード）のハードコード対策（項目 8）も重要なテーマで、Trivy や Semgrep のシークレット検出で第一歩を踏み出せます。
いつGXOに相談すべきか
セキュリティスキャンは無料ツールで始められますが、「ツールを入れること」と「リスクを実際に下げること」は別物です。次のいずれかに当てはまる場合は、自社だけで抱え込まず、外部の専門家に相談することをおすすめします。
- AI に書かせたコードが、すでに本番で顧客データや決済を扱っている——一度も第三者の脆弱性診断を受けていないなら、まず現状の可視化を優先すべき段階です
- スキャンを入れたが、Critical・High が大量に出て、どれから手を付けるか判断できない——トリアージと優先順位づけには、攻撃者視点の知見が要ります。外部からのペネトレーションテストで「実際に悪用できる経路」を見極めると、対応の順番が明確になります
- CI への組み込みやゲート設計を、自社の構成に合わせて設計する人手・知見がない——DevSecOps の導入支援で、スキャンを開発フローに無理なく組み込めます
- AI／LLM を業務システムに組み込んでいて、生成 AI 特有のリスク（プロンプトインジェクション・機密漏えい等）も気になる——まずはLLM セキュリティ成熟度診断で、自社がどの段階にあるかを把握できます
- 情シス 1〜3 名で、そもそも誰がセキュリティの責任を持つかが曖昧——スキャン以前の体制づくりから、外部 CTO／セキュリティ顧問として伴走する選択肢があります
相談すべき閾値の目安：「本番で個人情報・決済を扱う」「AI 生成コードの比率が高い」「直近で一度も外部の検査を受けていない」——この 3 つのうち 2 つ以上に当てはまるなら、無料相談で現状を整理する価値があります。脅すためではなく、限られた人手で何から守るかを決めるための相談です。
よくある質問（FAQ 10問）
Q1. AIに書かせたコードでも、本当に45%も脆弱性があるのでしょうか？
A. Veracode の 2025 年の調査では、100 以上のモデルを対象に検査し、約 45% のコードに OWASP Top 10 級の脆弱性が含まれていたと報告されています。すべての現場でこの比率になるとは限りませんが、「検査が標準的に必要」と考えるのが安全です。
Q2. スキャンツールは無料のものだけで足りるのでしょうか？
A. まずは無料の範囲（Trivy・OWASP ZAP・Snyk の無料プラン）で十分に始められます。検出範囲の拡大やチーム機能が必要になった段階で、有料プランや専門家の支援を検討するのが現実的です。
Q3. SAST・DAST・SCA は、どれか1つでよいのでしょうか？
A. それぞれ検査する対象が違うため、できれば組み合わせるのが理想です。まず始めるなら、依存関係を検査する SCA（Trivy） と、ソースコードを検査する SAST（Snyk Code） の 2 つからをおすすめします。
Q4. スキャンを導入すると、開発のスピードは落ちないでしょうか？
A. 最初は対応に時間がかかることがありますが、CI に組み込んで自動化すれば、日常の負担は小さくなります。むしろ、本番後に脆弱性が見つかって対応する場合に比べて、全体ではスピードと安全の両立につながります。
Q5. 誤検知が多くて困っています。どうすればよいでしょうか？
A. 誤検知は「除外設定」で個別に対応し、全体を無効化しないことが大切です。判断に迷うものは記録し、専門家に相談する運用にしておくと、形骸化を防げます。
Q6. CIに組み込むのは技術的に難しくないでしょうか？
A. GitHub Actions などでは、スキャンを追加する設定例が各ツールから公開されています。とはいえ、自社の構成に合わせた設計は手間がかかるため、最初は外部の支援を受けて組み込むのも現実的です。
Q7. スキャンを通れば、セキュリティは完璧でしょうか？
A. いいえ。スキャンは「機械で検出できる脆弱性」を見つけるもので、業務ロジックの誤りや権限設計の不備など、人のレビューが必要な問題もあります。スキャンと設計レビューの組み合わせが大切です。
Q8. 既に本番で動いているシステムにも、後からスキャンできますか？
A. できます。まず現状をスキャンして脆弱性を可視化し、Critical・High から優先的に対応していきます。改修のタイミングで CI への組み込みも進めるのが現実的です。
Q9. AIコーディング支援ツール自体に、スキャン機能はないのでしょうか？
A. 一部の支援ツールには簡易的なチェック機能がありますが、独立した専用のスキャンツールで検査することをおすすめします。「書いた本人（AI）が自己採点する」だけでなく、別の仕組みで検査する方が安心です。
Q10. 結局、まず何から始めればよいでしょうか？
A. Trivy で依存関係を、Snyk Code でソースコードをスキャンして、現状の脆弱性を可視化することから始めてください。数の多さに驚くかもしれませんが、それが出発点になります。次に CI へ組み込み、ゲート化へと段階的に進めます。
参考一次ソース
- Veracode「2025 GenAI Code Security Report」（AI生成コードの約45%に脆弱性）
- Veracode「2025 GenAI Code Security Report」本文 PDF（Java 約72%失敗・XSS/ログインジェクションの失敗率・モデル規模で改善せず）
- Veracode ブログ「Insights from 2025 GenAI Code Security Report」
- arXiv「Security Vulnerabilities in AI-Generated Code: A Large-Scale Analysis of Public GitHub Repositories」
- OWASP ZAP（Zed Attack Proxy）公式
- Trivy 公式（Aqua Security）
- Semgrep 公式（オープンソース SAST）
- Snyk 公式
- GitHub Docs「About Dependabot alerts」（全リポジトリ無料・GitHub Advisory Database 連携）
- OWASP（Open Worldwide Application Security Project）
- NIST「Secure Software Development Framework（SSDF, SP 800-218）」
- IPA「安全なウェブサイトの作り方」
まとめ
- Veracode の 2025 年調査では、AI 生成コードの約 45% に OWASP Top 10 級の脆弱性が含まれ、新しいモデルでも改善していません
- AI を安心して使うには、生成物を機械的に検査するスキャンの仕組みが欠かせません
- スキャンの 3 本柱は **SAST（静的解析）・DAST（動的解析）・SCA（依存関係解析）**です
- 中堅企業でも始めやすい主要ツールは **OWASP ZAP（DAST）・Trivy（SCA・コンテナ・IaC）・Snyk（SAST・SCA）**で、いずれも無料で始められます
- 最も効果的なのは CI に組み込み、変更のたびに自動スキャンすること（シフトレフト）。重大な脆弱性はマージをブロックするゲートにします
- 導入は **無料ツールで可視化（〜30日）→ CI 組み込み（〜60日）→ ゲート化と運用定着（〜90日）**の順が現実的です
- スキャンは万能ではなく、人による設計レビューとガバナンスとの組み合わせで効果を発揮します
「AI に書かせる」を続けるなら、「AI が書いたものを検査する」を必ずセットにする。これが、バイブコーディングを安全に活用するための、実装レベルの第一歩です。
AI生成コードのセキュリティスキャン導入を相談したい方へ
GXO の バイブコーディング監査 + セキュリティスキャン導入支援サービスでは、中堅企業向けに次のようなご相談を承っています。
- AI 生成コードのセキュリティ監査：既存システムをスキャンし、脆弱性を可視化（SAST / DAST / SCA、3〜5 営業日）
- スキャンツールの選定・導入：OWASP ZAP / Trivy / Snyk から、自社に合うものを選定・導入
- CI への自動スキャン組み込み：プルリクエストごとの自動検査とゲート設計
- 誤検知トリアージ・運用設計：検出結果の判断・対応体制づくり
- AI 生成コードのレビュー方針策定：人がどこまで確認してからマージするかのルール整備
関連記事
- 第 1 回 バイブコーディング危機 概論 + 7 リスク類型
- 第 2 回 SQL Injection の現実 5 パターン
- 第 3 回 認可漏れの現実 5 シーン
- 第 4 回 サービス停止の財務影響：江崎グリコ 4 ヶ月の教訓
- 第 5 回 DELETE FROM データ消失 + AI が書かない 6 安全機構
- 第 6 回 ランサムウェアに気づかない 6 ヶ月
- 第 7 回 法令違反の罠：電子帳簿 + 特商法 + 改正個情法
- 第 8 回 退職者がブラックボックスを残す日
- 第 9 回 バックアップが動いてない、を発見する方法
- 第 10 回 MFA を「あとで入れる」と言って入れない
著者: GXO株式会社 初回公開: 2026 年 5 月 31 日 最終更新: 2026 年 5 月 31 日 連載: バイブコーディング危機 第 11 回（全 20 回 / 第 3 週・防衛策の実装編）
