LLMレッドチーミングの社内体制構築：セキュリティテストの組織化と運用

LLM レッドチーミングの社内体制構築とは、セキュリティ・AI・ビジネス部門が連携し、明確な役割分担と自動化・人的判断の組み合わせによって、本番運用中の LLM に対する脆弱性検出と改善を継続的に実施できる仕組みを整えることです。本記事は、LLM を導入済みの企業でセキュリティ責任者や AI 運用チーム、情報セキュリティ部門を担う方に向けて、NIST AI RMF や OWASP LLM Top 10 などの標準を踏まえた体制設計の考え方を解説します。読み終えると、自社に合った役割分担表とテストプロセスを設計し、四半期ごとの実施サイクルを回すための具体的な手順が把握できます。なお本記事は一般的な体制構築の指針を示すものであり、個別の導入判断は監修者・専門家への確認を推奨します。

AI レッドチーミングは導入前の一度きりの診断では終わりません。本番運用中のモデル更新やプロンプト変更に応じて脆弱性は変化するため、継続的な体制がなければ検出漏れが積み重なります。

Promptfoo などの自動診断ツールを導入しても、運用体制を整えなければ検出結果が放置されやすく、結局は脆弱性が野放しになります。ツール単体での運用と、社内体制を組み込んだ運用では、対応できる課題の範囲が明確に異なります。

表からわかるように、ツール導入は検出範囲を広げる手段にすぎず、検出後の対応フローや部門間連携がなければ効果は限定的です。特にプロンプト変更やモデル更新への追随は、担当者の善意に頼る運用では継続しません。体制構築の優先度を判断する際は、自社が「検出はできているが対応が回っていない」状態にあるかどうかを最初の基準にしてください。

LLM レッドチーム体制は単一部門では完結せず、セキュリティ・AI・ML・ビジネスの3部門が異なる判断軸を持ち寄ることで機能します。技術的な脆弱性評価と事業インパクトの評価は別物であり、どの部門が何を担うかを最初に切り分けることが体制設計の出発点になります。

セキュリティ部門は、テスト計画の立案と結果評価の最終判断を担います。具体的には OWASP LLM Top 10 のカテゴリ（プロンプトインジェクション、機密情報漏洩、過剰エージェント権限など）を基準に、どのカテゴリを今回のテスト対象にするかを決め、対象システムの範囲・除外項目・実施期間を計画書に落とし込みます。計画段階で AI・ML 部門から提供されるモデルの構成情報やシステムプロンプトの内容を受け取り、攻撃シナリオの妥当性を検証する役割も含まれます。テスト対象を絞る際は、直接インジェクションのように単発の入力で検証できる項目と、間接インジェクションのように外部データソースを経由する複数ステップの検証が必要な項目を分けて計画に明記しておくと、実施期間の見積もりが崩れにくくなります。

結果評価では、検出された脆弱性を深刻度別に分類し、CVE のような外部データベースに登録される既知の脆弱性と、LLM 特有の文脈依存の問題（ジェイルブレイクの成功率、間接インジェクションの到達範囲など）を区別して扱う必要があります。攻撃成功率（ASR）のような指標を使う場合は、同一の攻撃パターンを継続的に測定し、モデル更新前後で比較できる形にしておくことが評価の実務上の要点です。

さらに、Promptfoo や PyRIT のような自動診断ツールが出力した結果を一次スクリーニングとして扱い、誤検知の除去と優先度付けを人的に行う工程もセキュリティ部門の担当範囲です。ここで判断した深刻度と優先度は、後続のビジネス部門による承認プロセスの入力情報になります。テスト計画から結果評価までを一貫して担うことで、AI・ML 部門が実装する改善策の根拠を明確にできます。

AI・ML 部門は、検出された脆弱性がなぜ発生したかをモデルの動作原理から説明し、改善策を実装する役割を担います。セキュリティ部門が攻撃シナリオの妥当性を判断するには、システムプロンプトの構成やファインチューニングの学習範囲、RAG のチャンクサイズや検索設定といった技術情報が必要であり、これらを提供する起点になるのも AI・ML 部門です。たとえばジェイルブレイクが成功したケースでは、システムプロンプトの制約が入力の言い換えでどのように迂回されたかを再現し、原因が指示文の記述順序にあるのか、それとも学習データの分布にあるのかを切り分けます。

改善実装では、システムプロンプトの修正、ガードレールのルール追加、RAG のグラウンディングチェック強化など複数の対応策を検討し、修正が既存の応答品質を損なわないかを評価します。モデル更新やファインチューニングを伴う修正は、通常の機能改善よりも検証コストが高くなるため、プロンプト側の修正で対応できる範囲を先に見極めることが実務上の判断基準になります。

修正後は同一の攻撃パターンで再テストを行い、攻撃成功率が許容範囲に下がったかをセキュリティ部門と共有します。RAG を利用するシステムでは、RAGポイズニングのように外部データソース側に起因する脆弱性もあり、この場合はベクトルデータベースの入力管理やチャンク生成プロセスの見直しまで踏み込む必要があります。改善の実装範囲と検証結果を記録に残す運用は、モデル更新時の再テスト判断にも使えます。

ビジネス部門は、セキュリティ部門が評価した脆弱性の深刻度に、事業インパクトという別の軸を重ね合わせて優先順位を決め、改善策の実施を承認する役割を担います。技術的な攻撃成功率が高くても、対象機能の利用頻度が低く事業損失が小さい場合と、成功率が中程度でも顧客対応チャットボットのように利用者数が多い機能で発生する場合とでは、対応の緊急度が異なります。この判断はセキュリティ部門や AI・ML 部門だけでは下せず、契約条件や顧客対応の実態を把握しているビジネス部門の判断が必要です。

承認プロセスでは、改善策の実装が既存の応答品質や応答速度に与える影響も確認します。たとえばガードレールのルール追加によって正常な問い合わせへの回答が過度に制限される場合、脆弱性対応と利用者満足度のどちらを優先するかをビジネス部門が判断し、リリースの承認または保留を決定します。想定例として、RAG を用いた社内問い合わせ対応で機密情報漏洩の脆弱性が見つかり、修正によって一部の正当な問い合わせへの回答精度が下がる場合、影響を受ける利用者数と情報漏洩時の損害を比較し、修正版のリリースを承認するかどうかを判断します。

判断を下す際は、対応を保留した場合に許容するリスクの上限をあらかじめ数値ではなく条件文で明文化しておくことも重要です。たとえば「個人情報を含む応答が発生した場合は即時保留」といった条件を事前に定めておけば、緊急時にも部門間で判断がぶれません。さらに、四半期ごとのテストサイクルで検出された脆弱性の累積状況を確認し、次サイクルの予算やテスト範囲の拡大を決定するのもビジネス部門の役割です。この承認記録は、後続の役割分担表を運用する際の根拠にもなります。

RACI では、実行責任（Responsible）と説明責任（Accountable）を分けて考えることが重要です。最終判断を1人・1部門に集約しつつ、実務は分野ごとの担当に分散させると、承認待ちで作業が止まる事態を避けられます。

表からわかるように、計画立案と検出評価はセキュリティ部門が説明責任を持ち、改善実装は AI・ML 部門、リリース承認はビジネス部門が最終判断者になります。1つの作業項目に A を複数部門で持たせると、緊急時にどちらが最終判断を下すかで停滞するため、A は必ず1部門に絞ってください。C（協議）と I（報告）の区別も曖昧にせず、報告のみで済む部門を協議に含めると会議体が肥大化し、四半期サイクルの実施スピードが落ちます。

体制構築は現状診断・人員配置・プロセス標準化の順で進めると手戻りが少なくなります。役割分担を先に決めても、既存の運用能力と乖離していれば運用は破綻するため、診断結果を土台に人と仕組みを重ねていく順序が実務上の分かれ目になります。

現状診断では、既存のセキュリティ運用のうちどこまでが LLM 固有のリスクに対応できているかを洗い出します。一般的なペネトレーションテストの体制がすでにある企業でも、プロンプトインジェクションやハルシネーションのような LLM 特有の脆弱性は既存の診断項目に含まれていないことが多く、まず何が抜けているかを可視化する作業が出発点になります。具体的には、以下の3点を診断項目として整理します。

1. 既存のセキュリティチームが OWASP LLM Top 10 のカテゴリのうち、どこまで検証経験があるか
2. AI・ML 部門がシステムプロンプトやファインチューニングの内容をセキュリティ部門に開示できる状態にあるか
3. ビジネス部門が脆弱性の深刻度と事業インパクトを結びつけて判断した経験があるか

この3点のいずれかが未整備であれば、体制設計はその不足を補う形で組む必要があります。たとえばセキュリティ部門に LLM 特有の検証経験がない場合、初期段階では外部の LLM レッドチーミングフレームワークや自動診断ツールの出力に依存する比重を高め、社内の知見が蓄積してから人的判断の範囲を広げる設計が現実的です。

体制設計の段階では、RACI 表をそのまま適用するのではなく、診断結果に応じて A（説明責任）を持たせる部門を暫定的に調整します。AI・ML 部門の情報開示が不十分な組織では、テスト計画立案の C（協議）にセキュリティ部門以外の関与を増やし、開示プロセスが整うまでの過渡的な体制として運用します。この診断と設計の結果は、次の人員配置と教育プログラムの入力情報として使います。

人員配置は、現状診断で明らかになった不足領域に応じて専任者と兼任者を分けることから始めます。セキュリティ部門から LLM 特有のリスクを扱う担当者を専任で1〜2名割り当て、AI・ML 部門とビジネス部門は既存業務との兼任で四半期ごとのテストサイクルに参加する形が実務上の落としどころになりやすい配置です。専任者を置く部門を絞る理由は、OWASP LLM Top 10 のカテゴリ知識やジェイルブレイクの検証手法は蓄積型のスキルであり、兼任だけでは知見が途切れるためです。

教育プログラムは、座学と実践演習を分けて設計します。座学では OWASP LLM Top 10 の各カテゴリと NIST AI RMF の Govern・Map・Measure・Manage の4機能を教材にし、自社のどの業務プロセスがどの機能に対応するかを担当者ごとに書き出させます。実践演習では、Promptfoo や PyRIT のような自動診断ツールを使い、既存のテスト対象システムに対して実際に攻撃シナリオを実行させ、検出結果の読み方と誤検知の見分け方を体験させます。

想定例として、AI・ML 部門の担当者が RAG を用いた社内問い合わせシステムに対して間接インジェクションのシナリオを演習で実行し、外部データソース経由での指示混入がグラウンディングチェックをどこまで通過するかを確認する形が教育内容として機能します。演習後は担当者ごとに検出できた項目と見落とした項目を記録し、次回の教育内容を個人単位で調整すると習熟度のばらつきを抑えられます。

テストプロセスの標準化では、人員配置と教育プログラムで育成した担当者の判断が、担当者ごとにばらつかないようテンプレート化することが目的になります。標準化の対象は、テスト計画書のフォーマット、攻撃シナリオのカテゴリ分類、検出結果の記録項目の3点です。これらをドキュメント化せずに口頭運用に頼ると、担当者が異動した際にノウハウが引き継がれず、四半期ごとのサイクルが担当者の在籍期間に依存してしまいます。

テスト計画書のフォーマットには、OWASP LLM Top 10 のカテゴリ一覧をチェックリスト形式で組み込み、今回のテスト対象に含めるカテゴリと除外するカテゴリを明記する欄を設けます。除外理由も記録しておくと、次回のテスト範囲を見直す際に判断の再検討が容易になります。検出結果の記録項目は、攻撃パターン・成功可否・深刻度・対応部門・再テスト予定日の5項目を最小構成とし、これをスプレッドシートやチケット管理システムのテンプレートに固定します。

過剰エージェント権限のように AI エージェントが外部システムへ操作を実行するケースでは、通常のプロンプト単体の検証と異なり、実行結果の副作用を記録する欄を追加する必要があります。攻撃シナリオのカテゴリ分類は、直接インジェクションと間接インジェクションのように検証手順が異なる項目を同じ欄にまとめず、別カテゴリとして扱うことで、担当者が手順書を取り違える事態を防ぎます。

標準化したテンプレートは一度作って終わりにせず、教育プログラムの演習で実際に使わせ、記入しづらい項目や漏れやすい項目をフィードバックとして反映します。運用開始後は、記録項目の粒度が細かすぎて記入が滞る場合と、粗すぎて再テスト時の再現ができない場合の両方を定期的に見直す対象とし、次サイクルの改訂で調整します。このテンプレートは、テスト計画の立案から結果評価までを一貫して運用するための土台になります。

標準化したテンプレートを実際のテスト運用に載せるには、計画・実施・報告の各段階で誰が何を確定させるかを明文化する必要があります。特に対象範囲の決定と検出後の記録粒度は、担当者の判断に委ねると再テスト時の比較ができなくなる分岐点です。

テスト計画の立案では、対象範囲を「システム単位」ではなく「機能単位」で切り出すことが実務上の分岐点になります。1つの LLM アプリケーションでも、顧客対応チャットボットの応答生成部分と、社内問い合わせ用の RAG 検索部分では、攻撃経路も検証手順も異なるためです。対象範囲を機能単位に分解したら、各機能に OWASP LLM Top 10 のカテゴリを割り当て、直接インジェクションのように単発の入力で検証できる項目と、間接インジェクションや RAG ポイズニングのように外部データソースを経由する複数ステップの検証が必要な項目を分けてスケジュールに反映します。

除外項目の扱いも計画段階で確定させます。今回のサイクルで検証しない機能や攻撃カテゴリがある場合、除外理由を「優先度が低い」で済ませず、「前回サイクルで検証済み、変更なし」「次回サイクルに繰り越し」など具体的な状態として記録します。この記録がないと、次のテスト計画を立てる担当者が異動していた場合、除外の経緯が追跡できなくなります。

実施期間の見積もりは、機能単位の分解と検証手順の違いを反映して個別に算出します。単発検証で済むカテゴリと、複数ステップの検証が必要なカテゴリを同じ工数で見積もると、実施中に間接インジェクションの検証だけが遅延し、計画全体のスケジュールが崩れる原因になります。計画書の除外欄と期間欄は、レッドチーム体制の役割分担表で説明責任を持つセキュリティ部門が最終確認し、AI・ML 部門から提供された技術情報と整合しているかを照合してから確定させます。

テスト実施は、自動診断ツールによる一次スキャンと、人的判断による深掘り検証を分けて進めると作業が重複しません。Promptfoo や PyRIT のような自動診断ツールは、既知のジェイルブレイクパターンやプロンプトインジェクションの定型攻撃を一括で流せるため、まず全対象機能に対して自動スキャンを実行し、検出数の多いカテゴリから優先的に人的検証へ回します。自動スキャンの出力には誤検知が含まれるため、担当者はこの段階で「実際に不正な出力が返っているか」を1件ずつ再現し、誤検知を除外する作業を行います。

人的検証では、間接インジェクションのように外部データソースを経由する攻撃や、複数ターンの対話を通じてガードレールを迂回するジェイルブレイクなど、自動スキャンでは網羅しにくいシナリオを重点的に扱います。RAG を用いる機能では、ベクトルデータベースに混入させた不正な文書がグラウンディングチェックをどこまで通過するかを、実際にテスト用の文書を投入して検証します。

検出した脆弱性は、テスト計画立案の際に固定した5項目（攻撃パターン・成功可否・深刻度・対応部門・再テスト予定日）のテンプレートにその場で記録し、検証終了後にまとめて記入する運用は避けます。記録を後回しにすると、複数の担当者が並行して検証した場合に同一パターンの重複記録や記入漏れが生じやすくなります。1機能あたりの検証が終わるごとに記録を確定させ、次の機能の検証に移る順序を徹底することが、報告段階での集計ミスを防ぐ実務上の要点です。

体制構築の理論は理解できても、人員数や部門間の温度差、テスト頻度の妥当性といった実務判断で手が止まることがあります。以下は個別相談で寄せられる代表的な疑問への回答です。

小規模企業では、専任者を複数部門に置く前提を捨て、セキュリティ担当者1名が計画立案と結果評価を兼務し、AI・ML部門は開発担当者が改善実装のみ兼任する縮小版RACIから始めます。ビジネス部門の承認は経営層1名が兼ねる形で構いません。自動診断ツールの出力に依存する比重を高め、人的検証は間接インジェクションや複数ターンのジェイルブレイクなど、自動化しにくい項目に絞ります。人員が増えた段階で役割を分割していく順序が、体制が崩れにくい進め方です。

原因は情報開示不足か協議設計の不備のどちらかです。AI・ML 部門がシステムプロンプトや RAG 構成を開示できない場合は現状診断の不足領域として扱い直します。開示は十分でも会議が停滞する場合は、RACI の C（協議）に無関係な部門が入り、報告で済む内容まで合意形成を求めていないか見直してください。

基本サイクルは四半期ごとが目安ですが、頻度はトリガー条件によって前倒しすべき場面があります。

• システムプロンプトやガードレールのルールを変更した場合：変更内容が対象カテゴリに影響する範囲だけ即時再テスト
• ファインチューニングやモデル更新を実施した場合：全カテゴリを対象に四半期サイクルを待たず再実施
• RAG のデータソースや埋め込みモデルを変更した場合：RAG ポイズニングとグラウンディングチェックの項目を優先して再検証
• 検出済み脆弱性の修正をリリースした場合：該当パターンのみ即時再テストし、四半期サイクルでは全体を再確認

変更がない期間でも四半期ごとの定期テストは継続してください。攻撃手法や公開されるジェイルブレイクの手口は更新され続けるため、モデルやプロンプトが変わらなくても新しいパターンに対する耐性は変化します。テスト頻度を機能の重要度で分ける場合は、顧客対応チャットボットのように利用者数が多い機能を四半期より短い周期で回し、社内向けの低頻度利用機能は四半期のまま維持する切り分けが現実的です。