AIレッドチーミングの自動化：テストケース生成とスケーラブルな脆弱性検証

手作業でのレッドチーミングでは、1人のエンジニアが1日に検証できるプロンプトパターンは限られています。LLMを本番運用するチームが増えるほど、この手動プロセスがボトルネックになる場面が目立ってきています。

AIレッドチーミング自動化とは、プロンプトインジェクションやジェイルブレイクなどのLLM脆弱性を、テストケース生成ツールとCI/CDパイプラインによって継続的に検証する手法です。本記事は大規模LLM運用チームやDevSecOps担当者、セキュリティエンジニアを対象読者とし、OWASP LLM Top 10やNIST AI RMFといった枠組みを参照しながら、テストケース生成からCI/CD統合、並列実行によるスケーラブルな脆弱性検証までを手順化して解説します。読み終える頃には、手動検証の5〜10倍のスケールで脆弱性検証を実施できる体制の設計方針がつかめるはずです。なお本記事は一般的な技術解説であり、実装は自社のリスク評価と専門家の監修に基づき判断してください。

手動レッドチーミングは、セキュリティ専門家がモデルに対して敵対的な入力を試行し、脆弱性を発見する作業です。しかし専門人材の確保には限界があり、モデル更新やプロンプト変更のたびに全件を再検証するのは時間的にも人的にも現実的ではありません。週次でモデルを更新するプロジェクトで、手動テストのサイクルが更新頻度に追いつかなくなるケースは少なくありません。

自動化は、この構造的な限界を補うアプローチです。テストケース生成とCI/CD統合を組み合わせることで、検証範囲と頻度を継続的に拡大できます。人手では網羅しきれない量の入力パターンを機械的に生成し、モデルの応答を継続的にチェックする仕組みを構築すれば、脆弱性の発見を開発サイクルの一部として組み込むことが可能になります。

対象システムの規模が小さい場合は専門家数名によるスポットチェックで足りるが、対象がマルチエージェントシステムや多言語対応のプロンプトを抱える大規模LLM運用になると、手動レッドチーミングは早い段階で限界に達する。

問題の核心は、攻撃パターンの組み合わせが指数的に増える一方で、検証を担う人材は増やせないという非対称性にある。OWASPが整理する「LLM Top 10」に挙げられるプロンプトインジェクションや機密情報漏洩、過剰エージェント権限といった脆弱性カテゴリごとに、言い回し・言語・文脈を変えたテストケースを人手で網羅しようとすると、担当者一人がカバーできる検証量には自然な上限がある。

さらに、モデルやシステムプロンプトが更新されるたびに、それまでのテストケースが有効かどうかを再確認する必要がある。手動運用では更新頻度に検証が追いつかず、未検証の期間が発生しやすい。NIST（CAISI）が実施した大規模レッドチーミング競技では25万件超の攻撃試行が行われ、対象となった全フロンティアモデルで少なくとも1件の成功攻撃が確認された。この規模の攻撃母数は、人手のみでの再現も継続的な監視も実質的に不可能であることを示している。

自動化はスポットチェックを置き換えるものではなく、検証の頻度と網羅性を構造的に変える手段です。CI/CDパイプラインにテストケース生成とスコアリングを組み込めば、モデルの更新やシステムプロンプトの変更が発生するたびに、同一の脆弱性カテゴリ群を毎回同じ基準で再検証できます。リリース直前に見つかった脆弱性はどう扱うのか、という問いが現場ではよく出てきますが、継続的検証の設計ではこの問いへの答えを事前に用意しておく必要があります。検証結果を攻撃成功率（ASR）のようなスコアで数値化し、閾値を超えたビルドをパイプライン上でブロックする仕組みを組み込むことが、その具体的な答えになります。

NISTのCAISIが実施した大規模エージェント・レッドチーミング競技では、25万件超の攻撃試行と400人超の参加者によって、対象となったすべてのフロンティアモデルで少なくとも1件の成功攻撃が確認されました。この規模の試行を人手で再現するのは非現実的であり、自動化されたテストケース生成と実行基盤があってはじめて到達できる検証量だといえます。継続的検証の目的は、こうした大量の攻撃パターンを定期的かつ一貫した手順で回し続け、脆弱性の再発や新規モデルでの再現を早期に捕捉することにあります。

テストケース自動生成では、直接インジェクション、間接インジェクション、ジェイルブレイクといった攻撃カテゴリごとにプロンプトを多様化し、カバレッジを体系的に広げる。手作業で書けるテストケースは数十〜数百件が上限になりやすく、攻撃パターンの組み合わせを網羅するには限界がある。自動生成では、既存の攻撃プロンプトをテンプレート化し、語彙の置換や文構造の変異、多言語への翻訳といった操作を加えることで、同じ攻撃意図を持つバリエーションを大量に作り出す。生成したプロンプトをカテゴリ別に分類し、どの攻撃手法がどの程度カバーされているかを可視化すれば、手薄な領域を狙って追加生成する運用もできる。以下では、この生成プロ

プロンプトインジェクション検証ケースは、直接インジェクションと間接インジェクションを分けて自動生成することが要になります。この切り分けを怠ると、テンプレートの量産だけが進み、実際に効くケースが埋もれてしまいます。

直接インジェクションは、システムプロンプトの指示を上書きする文言をユーザー入力欄に直接投下する攻撃です。「これまでの指示を無視して」のような命令文をテンプレート化し、語順・言語・敬語の有無を変数化すれば、少数のテンプレートから大量の変異ケースを生成できます。OWASPのLLM Top 10ではLLM01としてプロンプトインジェクションが位置づけられており、MITRE ATLASでも「AML.T0051」として技術カテゴリが整理されているため、生成ロジックの分類軸として活用しやすい領域です。

一方、間接インジェクションはRAGで参照する外部文書やWebページ、メール本文などに悪意ある指示を埋め込み、モデルが取得時に実行してしまうケースを指します。こちらは検証の難易度が一段上がります。ベクトルデータベースに登録するドキュメントの一部に攻撃文言を混在させ、グラウンディングチェックが機能するかを確認する手法が有効ですが、どの粒度で文言を混在させるか、どの取得経路をカバーするかによって検出精度が大きく変わります。RAGを扱う運用ではポイズニングされたコンテキストを見抜けるかが焦点になるため、通常の入力テストとは別枠でケースを積む必要があります。実装の詳細はAI チャットの「見えない攻撃経路」を塞ぐ — DB 経由プロンプトインジェクション対策の実装ガイドも参考になります。

短期的な単発攻撃を狙う場合は単発プロンプトで十分ですが、モデルの記憶や文脈を利用して段階的に防御を崩す場合は、複数ターンにわたるシナリオ設計が必要になります。ジェイルブレイクの自動検証では、単発の禁止語チェックでは見えない崩れ方——扉全体の建付けを揺らして緩みを探すような崩し方——を捉える発想が求められます。

具体的には、役割設定を偽装するペルソナ注入型、架空の許可された文脈を装う仮定法型、複数の無害な指示を積み重ねて最終的に有害な出力へ誘導する段階的エスカレーション型という3つの攻撃パターンをそれぞれテンプレート化し、自動生成します。この3類型は互いに組み合わせることも多く、たとえばペルソナ注入と段階的エスカレーションを併用すると、単体のテンプレートよりも防御の緩みが露呈しやすくなります。HarmBenchのような**攻撃成功率（ASR）**を評価軸に据えたベンチマーク設計を参考にすると、生成したケース群を「成功・部分成功・失敗」の3段階で分類しやすくなります。

有害出力の判定は、単純な禁止語マッチングだけでは誤検知・見逃しの両方が生じやすいです。そのため出力内容を別のモデルで評価する判定器を組み合わせる方法が現実的な選択肢になります。ただし判定器自体にも偏りが生じやすく、特定の言い回しや話題に対して過敏・過鈍になる傾向があります。この偏りを完全に自動で補正するのは難しいため、人間による抜き取り確認を運用フローに残しておく必要があります。

運用チームの検証範囲や予算に応じて、オープンソースとエンタープライズプラットフォームを使い分けるのが基本です。学術検証やPoC段階ではオープンソースツールの拡張性が有効ですが、CI/CDへの継続統合や大規模運用ではダッシュボード機能やアラート連携を備えたプラットフォームが向いています。

選定で最初に確認すべきは、テスト対象がプロンプト単体かエージェントの多段動作かという点です。ここで評価軸がまったく変わります。エージェント型AIセキュリティを検証する場合はAgentDojoのようにタスクグラフを模したベンチマークが適しており、単純な禁止語チェックだけでは過剰エージェント権限や混乱した代理人問題を捉えきれません。単体プロンプトの脆弱性診断であればGarakのような網羅的スキャンで初期診断の大半はカバーできますが、複数ツールを跨いで動くエージェントの挙動はタスク単位のシナリオでしか見えてきません。

予算とチームのエンジニアリング体力を踏まえ、オープンソースで足場を作った後にプラットフォームへ拡張する段階的導入も現実的な選択です。

自社のLLM運用環境に、どのオープンソースツールを組み込めば脆弱性検証の抜け漏れを防げるでしょうか。ツール選びを誤ると、検証範囲が偏ったまま「テストは実施した」という体裁だけが残ってしまいます。

選定の軸は主に3つあります。1つ目はカスタムシナリオの作成しやすさです。PyRITはPythonベースで攻撃テンプレートを拡張できる構造になっており、独自のプロンプトインジェクション検証ケースを組み込みたい研究・PoC段階のチームに向いています。2つ目は既知攻撃パターンの網羅性で、Garakは既存の攻撃手法を体系的に走査する設計のため、OWASP LLM Top 10に挙げられているような典型的な脆弱性カテゴリを一巡確認したい場合に効率的です。3つ目はベンチマークとの連携可能性で、AgentDojoのように現実的なタスクとセキュリティテストケースを組み合わせた評価フレームワークを使うと、エージェント型AIの権限逸脱や混乱した代理人問題のような挙動を再現しやすくなります。

攻撃シナリオを自作したい場合はPyRIT、既知パターンの網羅的スキャンを優先する場合はGarak、エージェント特有のリスクを検証したい場合はAgentDojo系のベンチマークが適しています。いずれもコミュニティ主導で更新されるため、モデルの追加や攻撃手法の拡張にはリポジトリの更新状況を確認する運用が欠かせません。更新が止まっているツールを使い続けると、新しい攻撃手法への対応が抜けたまま検証結果を信頼してしまうリスクがある点には注意したいところです。

導入規模と運用体制によって、オープンソースかエンタープライズかの分かれ目が生まれます。

複数モデル・複数チームを横断する運用フェーズに入ると、テストケース管理やレポート統合を自前で構築するコストの方が、ツール利用料そのものより大きくなるケースが少なくありません。エンタープライズプラットフォームは、攻撃シナリオのライブラリ管理、複数モデル・複数バージョンへの一括実行、脆弱性の重大度分類とチケット化までを一体で提供する点が特徴です。

機能面での差別化要素になるのは、OWASP LLM Top 10に対応した攻撃カテゴリのプリセット、既存の脆弱性管理ツールとの連携API、監査ログの長期保存機能などです。導入コストは提供形態やライセンス条件によって幅があるため、料金表だけで判断せず、テスト対象モデル数・実行頻度・保守体制を含めた総保有コストで比較することが実務上重要になります。

社内に検証シナリオを設計できる人材がいる場合は、オープンソースツールとの併用でコストを抑えつつ柔軟性を確保できることもあります。判断材料が不足している段階では、まず小規模なPoCでプラットフォームの適合性を検証し、そのうえで契約規模を決めるのが現実的です。料金体系は変更されることがあるため、契約前に最新の見積りを取得することは欠かせません。

小規模な単発検証で済む場合は手動実行のままでも問題ありませんが、継続的な運用が前提になる場合はCI/CDパイプラインへの統合が欠かせません。テストケース生成から実行、レポート化、優先度付けまでを一連の自動フローとして設計することで、コード変更やモデル更新のたびに脆弱性検証が走る体制を構築できます。

自動フロー設計の起点は、OWASP LLM Top 10 のカテゴリ（プロンプトインジェクションや機密情報漏洩など）を軸にしたテストケースのテンプレート化です。MITRE ATLASの技術カテゴリ AML.T0051（LLM Prompt Injection）のような攻撃分類を参照しながら、対象アプリケーションの入力経路ごとにケースを自動生成する設計にすると、手動で網羅していた項目の抜け漏れを抑えられます。

フローの流れは概ね次の順になります。

1. コードやシステムプロンプトの変更をトリガーに、テストケース生成モジュールが差分箇所を検出
2. Garak や PyRIT のようなツールで生成した攻撃プロンプトをバッチ実行
3. 応答をルールベースと分類モデルの併用で判定し、成功・失敗をタグ付け
4. 結果をJSON形式などでレポート生成モジュールに渡し、脆弱性の種別ごとに集計

この一連の処理をパイプライン化する際は、実行環境をコンテナ単位で分離しておくと、テスト中の予期しない出力（過剰エージェント権限の誤動作など）が本番系に影響しにくくなります。マルチエージェントシステムを検証対象にする場合は、マルチエージェントAIとは？設計パターンから実装・運用の勘所までで触れているエージェント間通信の経路も、テスト生成の対象範囲に含めておくと検証の抜けを防ぎやすくなります。

数百件から数千件のテスト結果が毎晩流れてくるとき、どの失敗を最初に見るべきか判断できるでしょうか。優先度付けの仕組みがなければ、攻撃成功率が高い重大な脆弱性が、単純なフォーマットエラーの通知に埋もれてしまいます。

結果集約では、まずテストケースの出力を「攻撃成功」「部分的成功」「防御成功」の3区分に分類し、OWASP LLM Top 10のカテゴリ別に攻撃成功率を集計します。この数値が前回実行時より悪化した場合は、コード変更やシステムプロンプトの調整が原因である可能性が高く、差分箇所を優先的に確認する運用が実務的です。

優先度付けの軸は、影響範囲（機密情報漏洩か単純な誤答か）と再現性（同一プロンプトで再現するか一時的なゆらぎか）の2点で評価すると判断がぶれにくくなります。直接インジェクションで機密情報漏洩に至るケースは高優先度、境界テストでの軽微な出力ゆらぎは低優先度に振り分けるといった想定例が現実的です。

アラート設定では、攻撃成功率が事前に定めたしきい値を超えた場合にDevSecOpsチームへ通知し、CI/CDパイプライン上でのビルドをブロックする条件分岐を組み込みます。しきい値は初期運用では緩めに設定し、誤検知の傾向を見ながら段階的に厳格化していく進め方が現場では有効です。

判断軸: 検証規模を広げるほど、実行速度と結果管理の設計が品質を左右します。テストケースを並列実行してGPUやAPIレート制限を効率的に使う方法と、集まった結果を可視化して継続的に追跡する方法を、それぞれ確認していきます。

自社基盤でモデルをホストする場合はGPUメモリとバッチサイズの調整が中心になり、外部APIを利用する場合はレート制限とコストの管理が中心になります。並列実行では、テストケースをターゲットモデルやAgent種別ごとにキューへ分割し、ワーカー数を段階的に増やしながらスループットの上限を探るのが実務的な進め方です。Gray Swan Arenaの大規模公開レッドチーミングでは180万件規模の攻撃試行が実施されており、この規模の検証を手動運用に近い体制で回すのは現実的ではありません。リソース最適化の観点では、攻撃カテゴリ（直接インジェクション、間接インジェクション、ジェイルブレイクなど）ごとに優先度を設け、致命度の高いカテゴリから先に実行キューへ投入する方式が有効です。

APIベースのターゲットでは、プロバイダー側のレート制限に達すると失敗リクエストが積み重なり、検証全体の完了時刻が読めなくなります。この場合はスロットリングを併用し、429エラー発生時に指数バックオフで再試行する設計が欠かせません。一方、ローカルLLMをホストして検証する場合はGPUの占有時間がコストに直結するため、バッチ推論でスループットを最大化しつつ、優先度の低いテストケースは空きリソースが出たタイミングで実行する調整が現実的です。並列度を上げすぎるとターゲット側の応答遅延やタイムアウトが増える傾向があるため、事前にリソース種別ごとの上限を把握したうえで段階的に調整することが重要です。

大量の攻撃試行結果をCSVやログのまま眺めていても、どこから手をつけるべきか判断できません。「結局どの脆弱性を今週中に潰すべきか」という現場の問いに答えるには、可視化の設計が要になります。

ダッシュボードには最低限、次の3軸を持たせます。

• 攻撃成功率（ASR）の時系列変化：リリースごとに悪化・改善を追跡します
• OWASP LLM Top 10カテゴリ別の内訳：プロンプトインジェクションや機密情報漏洩などの分布を把握します
• 不可逆性・影響範囲による優先度分類：軽微な出力乱れと機密情報漏洩を同列に扱いません

条件分岐としては、影響範囲が広くASRが上昇傾向にある脆弱性は即時ブロッキング対象とし、影響が限定的で発生頻度が低いものはバックログに回すという判断軸が実務的です。

可視化基盤は既存のAIオブザーバビリティ環境と統合すると運用負荷が下がります。ログ収集からダッシュボード表示までを同一パイプラインに載せることで、レッドチーミング結果と本番運用中の異常検知を同じ画面で比較できるようになります。担当者間での引き継ぎ資料としても機能し、経営層への報告時にはASRの推移とカテゴリ分布を示すだけで、対策の優先順位を説明しやすくなります。

自動化導入後によく寄せられる質問を3つ取り上げます。検出範囲の限界、導入にかかる期間とコスト感、SAST/DASTなど既存ツールとの併用方針について、それぞれ簡潔に整理します。

判断軸: 自動生成テストケースが強いのは既知の攻撃パターンの網羅と量的検証であり、未知の文脈依存型脆弱性の検出には限界があります。

自動生成は既存の攻撃辞書やテンプレートを組み合わせて多様化するため、OWASPが示すプロンプトインジェクションや有害出力といった既知カテゴリの検証には効果を発揮します。一方で、業界固有の業務フローに依存する過剰エージェント権限や、複数エージェント間の連携で初めて表面化する混乱した代理人問題のような複合的な脆弱性は、単発のテストケースだけでは再現しにくい傾向があります。

また、間接インジェクションのように外部ドキュメントやRAGの検索結果を経由する攻撃は、実際のデータ環境に近い条件を用意しないと検出精度が下がります。システムプロンプト漏洩やモデル抽出攻撃のような、複数回のやり取りを重ねて情報を蓄積させる攻撃も、単発型のテストケース生成では拾いにくい領域です。

このため自動化はあくまで一次検証の網を広げる手段と位置づけ、境界テストで洗い出した高リスクシナリオについては、専門知識を持つ人間のレッドチームによる深掘り検証を組み合わせる運用が実務的です。人間の関与レベルを設計する際は、ヒューマン・イン・ザ・ループ(HITL)とは？AIで業務自動化を定着させる「人間参加型」設計の基礎で紹介されている考え方が参考になります。

小規模チームでPoCとして既存OSSツールを使う場合はセットアップが数週間で完了する一方、エンタープライズ規模でCI/CDパイプラインへの統合や既存の脆弱性管理基盤との連携まで含める場合は数か月単位の期間を要します。「まず何から着手すればいいのか分からない」という声は導入初期の現場でよく聞かれますが、判断軸は対象システムの数とテストケースの多様化範囲です。

初期セットアップでは、テストケース生成ロジックの選定、実行環境の並列化設計、結果を蓄積するダッシュボードの構築という3工程が発生します。PyRITやGarakのようなオープンソースを採用する場合は、初期コストを抑えつつ自社のLLM構成に合わせた調整作業に時間がかかる傾向があります。反対にエンタープライズプラットフォームは導入コストが高くなりやすい一方、テンプレートやレポート機能が標準搭載されているため運用開始までの期間を短縮できる場合があります。

運用コストは、対象モデルの数、テスト頻度、GPUなどの計算リソース消費量によって変動します。継続的検証を前提とする場合は、リソース最適化を含めた運用設計を初期段階から組み込むことが望まれます。具体的な費用は各ベンダーの最新の料金ページを確認することが必要です。

SAST（静的解析）やDASTのような従来型セキュリティテストツールは、コードの脆弱性やWebアプリケーションの既知の攻撃パターンを検出する用途に最適化されており、AIレッドチーミングとは検証対象そのものが異なります。SASTはソースコード中のインジェクションリスクや認可漏れなどを静的に洗い出し、DASTは稼働中のアプリケーションに実際のリクエストを送って脆弱性を確認します。一方でAIレッドチーミングは、LLMの応答挙動そのもの、たとえば直接インジェクションへの耐性やジェイルブレイクによる有害出力の誘発可能性など、モデルの振る舞いに起因する脆弱性を対象とします。

実務では両者を併用する体制が合理的です。CI/CDパイプライン上でSAST/DASTがアプリケーション層のコード品質とAPI境界のセキュリティを検証し、並行してAIレッドチーミングの自動化フローがプロンプト起点の攻撃やシステムプロンプト漏洩を検証する、という役割分担になります。SAST/DASTだけではLLMが生成した出力の不適切な処理や過剰エージェント権限のようなOWASP LLM Top 10特有のリスクは検出できません。逆にAIレッドチーミングは、アプリケーション基盤そのものの脆弱性検証には向いていません。両方を組み合わせることで、コード層とモデル振る舞い層の双方をカバーする検証体制が構築できます。