AI脆弱性診断で1モデル任せは危険か【AISI検証で分かった件数差】
AIの診断結果を一つ増やすだけでなく、確認の順番を整えると、安全性の判断はもっと具体的になります。
AISIの3モデル検証を手がかりに、件数へ振り回されず修正と再テストまで進めませんか？
AIにコードを読ませると、脆弱性らしき箇所と修正案が短時間で返ります。便利ですが、1つのAIモデルが何も指摘しなかったことを、安全の証明にはできません。
AIセーフティ・インスティテュート(AISI)が同じコードを3モデルで検証したところ、検出合計は15件、13件、13件でした。差は最大2件でも、内容、分類、深刻度は一致していません。
要点AIの件数ではなく再現性と影響で決める
AIの指摘は脆弱性の確定結果ではなく、確認すべき候補です。従来の検査、人のレビュー、別手段での再テストを組み合わせ、修正の優先順位を決めましょう。
AI脆弱性診断で1モデル任せにしない理由
AI脆弱性診断は、ソースコードや設定を読み、攻撃につながる可能性がある箇所を探す使い方です。説明や修正案まで出せる一方で、回答はモデル、指示、入力範囲、実行時期、安全設定によって変わります。
ここでいう「1モデル任せ」とは、AIを1回使うことではありません。
一つの出力だけで、システムの合否や公開可否を決める状態を指します。
1モデルだけ
出力件数をそのまま合否に使う。未検出と未評価を区別できず、重複や誤検知も残る。
VS
多層で確認
AI、従来ツール、人のレビューを組み合わせ、再現性と業務影響を確かめる。
複数モデルの利用は、見落としを減らす一手段です。ただし、同じ系統のモデルが同じ誤りをする可能性もあり、数を増やすだけで安全が保証されるわけではありません。
AISI検証の件数差は15件・13件・13件
AISIは2026年7月8日、同一のソフトウェアコードを一般に利用可能な3つのAIモデルで検証した結果を公開しました。各モデル1回の試行で、深刻度別の内訳は次のとおりです。
| モデル | Critical | High | Medium | Low | 合計 |
|---|---|---|---|---|---|
| モデル1 | 4 | 5 | 6 | 0 | 15 |
| モデル2 | 3 | 5 | 4 | 1 | 13 |
| モデル3 | 0 | 5 | 6 | 2 | 13 |
合計だけなら最大差は2件です。しかし、モデル1はCriticalを4件、モデル3は0件と分類し、Lowはモデル1が0件、モデル3が2件でした。
件数が近いことと、同じ危険を同じ深刻度で見つけることは別です。
AISIは、モデル1が似た問題を場所や経路ごとに分けて数えた点も説明しています。15件だからモデル1が優秀、Criticalが0件だからモデル3が安全、とは判断できません。
さらに、安全対策によって出力が制限された場合があるため、AISI自身が件数を参考値としています。今回の数字は、一般的なAIモデルの平均差や検出率を示すものではありません。
出典: AISI「生成AIモデルによるソフトウェア脆弱性検証結果の違いについて」
AI脆弱性診断の注意点｜件数だけで優劣を決めない
AI脆弱性診断の結果は、一覧をそのまま修正チケットへ移すのではなく、共通、固有、保留の3つに分けると整理しやすくなります。
- 共通
複数のモデルや検査手段が同じ原因を指摘。優先して再現確認する - 固有
一つだけが指摘。新しい発見と誤検知の両方を疑う - 保留
入力不足、権限不足、出力制限などで判断できない。安全ではなく未評価とする
同じ原因が複数の場所に現れると、AIは別々の脆弱性として数えることがあります。まずCWEなどの分類、根本原因、攻撃経路でまとめ、重複を除いてから優先順位を付けてください。
順位付けでは、件数より再現性、業務影響、外部からの到達可能性、代替防御を見ます。たとえば1件でも、顧客情報へ外部から到達できる問題なら、社内画面だけの低影響な複数件より先に対応すべきです。
注意未検出を安全判定に変えない
AIが何も返さなかった時は、問題なしではなく、入力範囲、安全制御、権限、実行条件を確認します。判断できないものは「保留」として残すことが大切です。
AI脆弱性診断は従来ツールと人のレビューを置き換えない
AIは文脈を読んだ仮説づくりや、指摘理由の説明に向きます。一方、既知の危険な依存関係を機械的に探す、実行中の挙動を確かめる、業務影響を決める、といった役割は別です。
| 手段 | 得意なこと | AIと組み合わせる理由 |
|---|---|---|
| 静的解析 | ルールに沿ったコード検査 | 継続実行の基準線になる |
| 依存関係検査 | 既知脆弱性と更新状況 | AIの知識鮮度に依存しない |
| 動的診断 | 実行中の挙動と到達性 | 攻撃が成立するか確かめる |
| AI診断 | 文脈理解、仮説、修正候補 | 未知の論点を広げやすい |
| 人のレビュー | 設計、業務影響、責任判断 | 優先順位と例外を決める |
AIで作ったコードのバグを検査する手順でも、生成と検査を分ける考え方が重要です。コードを作ったAIと、合否を決める仕組みを同じ回答に閉じないようにします。
AIに任せる
疑わしい箇所の候補出し
攻撃経路の仮説
修正案と確認項目の下書き
結果の分類補助
人と組織が決める
再現性と業務影響
対応期限と責任者
公開・停止の判断
修正後の承認
NISTのSP800-218Aも、AI向けの安全なソフトウェア開発で、継続的な自動検査に必要な人の関与と定期的な監査を組み合わせる考え方を示しています。
AIは確認作業を速めても、組織の責任を引き受けるわけではありません。
出典: NIST「Secure Software Development Practices for Generative AI and Dual-Use Foundation Models」(英語)
AI脆弱性診断の結果を統合する7ステップ
AI脆弱性診断を実務へ入れるなら、モデルの回答画面で終わらせず、修正と再テストまで同じ記録に残します。最初に対象と禁止事項を決めると、機密コードの誤送信や本番環境への無許可テストも防ぎやすくなります。
- 対象と許可範囲を決める
対象コード、環境、機密情報、外部API、実行してよい操作を定義する - 従来手段の基準線を取る
静的解析、依存関係、シークレット検出、必要な動的診断を先に行う - AI診断を分けて実行する
モデル、日付、指示、設定、対象バージョンを記録する - 正規化して重複を除く
同じ根本原因をまとめ、共通、固有、保留へ分類する - 再現性と影響を確かめる
攻撃成立条件、権限、公開範囲、扱うデータを確認する - 修正と責任者を決める
期限、担当、承認者、例外理由を残す - 別手段で再テストする
同じAIの再回答だけに頼らず、テスト、ツール、人のレビューで確かめる
基準線
従来検査を実行
→
AI診断
条件と結果を記録
→
人が確定
再現と影響を確認
→
修正・再検査
別手段で確かめる
結果と対応を次の診断条件へ戻し、コード・依存関係・モデルの変更時に再評価する
記録には、指摘本文だけでなく対象コミット、再現手順、証拠、判断理由、修正差分、再テスト結果を含めます。モデルが更新されても同じ評価セットを使えるため、回答の変化を追いやすくなります。
外部AIへコードを送る場合は、契約上のデータ利用、保存期間、アクセス制御も先に確認してください。Claude Codeを安全に使う設定と確認項目も、開発AIへ何を渡すか決める際の参考になります。
生成AIシステムの脆弱性診断はコード以外も見る
AIでコードを診断することと、AIを組み込んだシステム自体を診断することは別です。RAGやAIエージェントでは、コードが安全でも、プロンプト、参照データ、権限、外部接続、実行時の挙動に弱点が残ります。
- モデル: 有害な指示、ジェイルブレイク、意図しない回答への耐性
- 実装: プロンプトインジェクション、出力の無検証実行、RAGからの情報漏えい
- インフラ: APIキー、ログ、ネットワーク、権限、外部ツール接続
- 実行時: 異常検知、停止、監査、モデルや設定変更後の再評価
AISIのレッドチーミング手法ガイドは、RAGシステムを題材に、攻撃者の視点で弱点を検証する流れと成果物を示しています。AISIのAIエージェント評価ガイドを実務へ置き換える方法も合わせると、コードからシステム全体へ確認範囲を広げやすくなります。
出典: AISI「AIセーフティに関するレッドチーミング手法ガイド改訂版」
OWASPの生成AI向けレッドチーミングガイドも、モデル評価、実装テスト、インフラ評価、実行時挙動の4領域を扱います。
コードスキャンだけで「AIシステム全体を診断済み」としないことが重要です。
出典: OWASP GenAI Security Project「GenAI Red Teaming Guide」(英語)
AI特有の攻撃を試す際は、AIジェイルブレイク対策の基本も確認してください。許可されたテスト環境で行い、本番データや外部利用者へ影響が及ばない範囲を先に決めます。
AI脆弱性診断の導入前チェック
導入前は、ツールやモデルを選ぶ前に、次の項目を埋めます。答えられない項目があれば、低リスクな検証環境だけで試すのが安全です。
- 診断対象と対象外を明文化したか
- 外部AIへ送ってよいコードと情報を決めたか
- 本番環境で実行してよい操作を制限したか
- モデル、日時、設定、対象バージョンを記録できるか
- 重複排除と再現確認の担当者を決めたか
- Criticalなどのラベルとは別に業務影響を評価するか
- 修正期限、例外承認、停止判断の責任者がいるか
- 修正後を別手段で再テストするか
AIエージェントを含む場合は、AIエージェント導入前チェックリストで、外部操作、承認、ログ、停止手順まで確認します。診断AI自身に本番変更権限を与えないことも、初期段階の基本です。
最初の一歩過去に修正済みのコードで試す
既知の脆弱性と安全な修正版がある社内サンプルを使えば、見つけた件数ではなく、重要な問題を再現し、正しい修正へ導けるかを比較できます。
よくある質問
QAI脆弱性診断だけで安全を確認できますか？
AAI脆弱性診断だけでは安全を確認できません。静的解析、依存関係検査、必要な動的診断、人のレビューを組み合わせ、修正後は別手段で再テストしてください。
Q検出件数が多いAIモデルほど優秀ですか？
A件数だけでは優劣を決められません。同じ原因を場所別に数える場合があり、再現性、業務影響、外部からの到達可能性を確認する必要があります。
QなぜAI脆弱性診断を1モデルだけに任せてはいけませんか？
Aモデルや実行条件によって、検出内容と深刻度が変わるためです。重要なシステムでは別モデルまたは従来手段で確認し、単一出力を合否判定にしないでください。
QAIへソースコードを入力しても問題ありませんか？
A無条件では入力できません。契約上のデータ利用、保存期間、学習利用、アクセス制御を確認し、秘密情報や顧客データを除いた許可済みの範囲で使います。
QAI脆弱性診断の結果は何から確認すべきですか？
A複数手段で共通する指摘から再現確認します。ただし単独の指摘も捨てず、誤検知か新しい発見かを業務影響と攻撃成立条件で判断してください。
Q生成AIシステム自体の診断では何を確認しますか？
Aコードに加え、モデル、プロンプト、RAGデータ、外部ツールの権限、インフラ、実行時の監視と停止手順を確認します。コードスキャンだけで完了にはできません。
まとめ
AISIの試行で合計件数は15件、13件、13件と近くても、検出内容と深刻度は一致しませんでした。AIの件数を性能順位や安全判定へ変えず、確認候補として扱うのが出発点です。
まず、修正済みの社内サンプルを使い、従来検査、AI診断、人の確認、別手段による再テストまで一周させてください。1モデルを増やすことより、判断工程を増やすことが、AI脆弱性診断を安全に役立てる近道です。再テストを省略して公開しないでください。
