AIレッドチーミングとは？生成AIの脆弱性を洗い出す実施手順とツール選定【2026年時点】

社内のチャットボットに「これまでの指示を無視して」と打ち込むと、設定したはずの制限をすり抜けて社外秘の要約が返ってくる。AIレッドチーミングは、こうした挙動を偶然の事故として待つのではなく、攻撃者の手口を先に再現して確かめる検証活動です。この記事では、脆弱性診断やペネトレーションテストとの守備範囲の違い、AISIの手法ガイド第1.10版に沿った5段階の実施手順、garak・PyRIT・promptfooの選び分け、そして自社に常設すべきか外注で足りるかの判断基準までを実装者の目線で整理します。

まとめ：AIレッドチーミングの実施範囲と着手順序の結論

AIレッドチーミングとは、AIシステムに敵対的な入力や誤用シナリオを与え、危険な応答・情報漏えい・制御逸脱が実際に起きるかを攻撃者視点で確かめる評価手法です。従来の脆弱性診断が既知の欠陥を機械的に照合するのに対し、こちらは確率的に振る舞う出力を相手にするため、1回の成功や失敗では判定できません。同じプロンプトを何度も投げ、成功率で語る。ここが決定的な違いになります。

着手順序の結論を先に置きます。守るべき資産と受け入れられない被害を1枚に書き出し、次にスキャナ型のツールで広く浅く当てて反応の出た領域を特定し、そこだけを多ターンの攻撃で深掘りする。得られた結果をCIに常設テストとして戻し、試行回数と成功回数を添えた報告書の形で残す。この5手が最短経路でした。逆に、入出力のログもガードレールも無い段階で先にレッドチーミングへ着手すると、見つけた穴を塞ぐ受け皿が無いまま指摘だけが積み上がります。

費用対効果の分岐点も明確です。モデルやRAGの参照文書を自社で継続的に改修しているなら内製の常設が回収でき、年1回の外注診断で済ませる運用は前提が崩れます。

AIレッドチーミングの定義と脆弱性診断・ペネトレーションテストとの境界

言葉の定義から入ります。ここを曖昧にしたまま外注仕様書を書くと、届く成果物が期待とずれます。

攻撃者視点で危険な応答を引き出す検証活動としての定義と実施目的

AIセーフティ・インスティテュート（AISI）が公開した「AIセーフティに関するレッドチーミング手法ガイド」は、レッドチーミングを、攻撃者がどのようにAIシステムを攻撃するかという観点から、AIセーフティへの対応体制と対策の有効性を確認する評価手法として位置づけています。ここで注意したいのは目的語です。確認する対象は「脆弱性の全件」ではなく「すでに施した対策の有効性」。つまり防御を作った後に効き目を測る工程であり、防御が存在しない状態で回すものではありません。

検証の入力になるのは、意図的に難しい指示、規約回避を狙う文脈、誤用や悪用を想定した利用シナリオです。出力側では、有害情報の生成、機密データの流出、想定外のツール実行といった結果を観測します。

脆弱性診断・ペネトレーションテストとの守備範囲の違いと重なり

三者は目的も成果物も異なります。脆弱性診断は既知の欠陥パターンを網羅的に照合し、一覧を出す作業です。ペネトレーションテストは侵入経路が実際に通ることを一本証明します。AIレッドチーミングはその両方と重なりながら、対象が確率的に応答する点で決定的に違います。

同じ入力を10回投げて2回だけ制限を突破することが普通に起きる。この非決定性があるため、成果物は「脆弱性あり・なし」の二値ではなく、攻撃成功率（ASR）と試行分母のセットです。逆に言えば、1回試して通らなかったから安全、という報告書は設計が誤っています。既存のWebアプリ診断で使うOWASP ZAPのようなスキャナと同じ感覚で発注すると、この差でつまずきます。

AIセーフティ評価とAIセキュリティ評価で分かれる観点の切り分け

実務では二つの系統が混ざりがちです。AISIのガイドが扱うセーフティ観点は、有害情報の生成、偏った出力、誤情報の拡散など、AIが社会に与える影響を軸にします。一方でOWASPが整理するセキュリティ観点は、プロンプト注入、学習データの汚染、認可の回避といった攻撃者の利得を軸に並びます。

両方を同じ検証計画に押し込むと、シナリオの粒度が揃わず結果の解釈で揉めます。受託開発の現場では、まずセキュリティ観点を先に回して実害の出る経路を潰し、セーフティ観点は公開範囲が社外に及ぶ場合に追加する。この順序で進めると、限られた工数で守備範囲を決めやすくなりました。

モデル・RAG・AIエージェントに広がる検証対象レイヤと攻撃手口の分類

どこを叩くのかを決めないまま始めると、プロンプトを投げるだけの作業に終わります。対象レイヤの分解から入ります。

モデル単体・アプリ実装・基盤・実行時挙動という4つの検証スコープ

OWASPのGen AI Security Projectが2025年1月22日に公開したGenAI Red Teaming Guide（v1.0）は、検証を4つの領域に分けて扱う構成を採っています。

• モデル評価：モデルそのものが持つ有害出力や脱獄耐性を測る
• 実装テスト：システムプロンプト、フィルタ、RAG連携など作り込んだ部分を叩く
• インフラ評価：モデルを動かす基盤、鍵管理、ネットワーク境界を確認する
• 実行時挙動分析：本番稼働中の入出力を継続監視し、逸脱を検知する

受託開発で実際に手を入れられるのは2番目と4番目です。基盤モデルを自社で訓練していない以上、モデル評価はベンダーの公開情報に依存します。工数を割く優先順位は、実装テストが最上位。

プロンプトインジェクションと脱獄を軸にした入力側の攻撃手口の類型

入力側の手口は大きく直接注入と間接注入に分かれます。直接注入は利用者が入力欄から「これまでの指示を無視せよ」と書き込む形。間接注入は、AIが読み込む外部文書やWebページに命令文を仕込み、AI自身に読ませて実行させる形です。後者はユーザーが加害者ではなく被害者になるため、入力欄のフィルタだけでは止まりません。手口の詳細と防御の考え方はプロンプトインジェクションの仕組みと対策で個別に解説しています。

脱獄（jailbreak）系はロールプレイの強制、架空の設定の付与、エンコーディングによる検出回避が定番です。加えて、1回の入力では拒否されるが会話を重ねるうちに境界が緩む多ターン型の手口が2025年以降の主戦場になりました。単発プロンプトのテストしか組んでいない検証計画は、ここを丸ごと取りこぼします。

RAGの参照文書汚染とエージェントのツール悪用で生じる被害の差

RAGを組んだ構成では、攻撃面が参照文書の側へ移ります。社内共有フォルダ、外部クロール、利用者のアップロード。この3経路のどこかに命令文を含む文書を1本置ければ、以降その質問に当たった全員へ汚染された回答が配られます。被害の性質は情報漏えいと誤誘導です。

AIエージェントになると被害が実行系へ変わります。メール送信、外部API呼び出し、決済、権限変更。読み取り専用の間は情報が漏れるだけでしたが、書き込み権限を持たせた瞬間に、注入は不正操作へ直結します。だからエージェントの検証では、攻撃成功の判定をスクリーンショットや応答文ではなく、データベースの状態差分で取るのが確実でした。AISIのガイドが第1.10版でRAG実装システムの実施手順を詳細化したのも、この層の検証需要が先に立ち上がったためと読めます。

AISI手法ガイド第1.10版に沿った実施手順とリスクシナリオ設計の要点

手順の型は公開資料で入手できます。自作するより、既存の枠に自社の条件を差し込むほうが速い。

リスクシナリオから攻撃シナリオへ落とし込むまでの5段階の実施手順

AISIの手法ガイドは2024年9月25日に第1.00版が公開され、2025年3月31日に第1.10版へ改訂されました（いずれも公開時点の版番号）。第1.10版は本編に加え、詳細解説書の別紙と、リスクシナリオおよび攻撃シナリオの作成と実施結果をまとめた別添1、実施結果報告書の別添2、最終報告書の別添3で構成されています。実務ではこの別添の書式をそのまま流用できます。

1. 対象システムの範囲と、守るべき資産・許容できない被害を確定する
2. 被害から逆算してリスクシナリオを作成する（誰が何をされて困るか）
3. リスクシナリオを実行可能な攻撃シナリオへ具体化する（入力・経路・期待される逸脱）
4. 攻撃シナリオを試行回数を決めて実施し、成功条件の観測結果を記録する
5. 実施結果報告書と最終報告書に落とし、対策の要否を判定する

2番目を飛ばして3番目から始める現場が多く、そこが最大の失敗要因でした。被害の定義が無いと、攻撃が成功しても「それで何が困るのか」に答えられません。

RAG構成のシステムで攻撃シナリオを組むときの前提条件の置き方

RAGを対象にする場合、最初に決めるのは攻撃者が文書を投入できる経路です。社内文書のみをインデックスしているのか、外部サイトをクロールしているのか、利用者がファイルをアップロードできるのか。この3つで攻撃シナリオの現実味がまったく変わります。誰も文書を追加できない閉じた構成なら、参照文書汚染のシナリオは優先度を落として構いません。

次に権限境界です。検索対象のインデックスが部署横断で1本になっていると、質問者の所属に関係なく人事情報が引ける状態になりがちです。この場合の攻撃シナリオは、凝ったプロンプトではなく「一般社員のアカウントで役員報酬の要約を求める」という素朴な1文で十分に成立します。

実施結果報告書と最終報告書に何を残すかという成果物の設計基準

報告書に必ず残す項目は4つです。攻撃シナリオの再現手順、試行回数、成功回数、そして成功したときの条件（モデルのバージョン、システムプロンプトの版、参照文書の状態）。このうち抜けやすいのが試行回数と条件です。

再現条件が無い報告は、モデルが更新された翌月には検証不能になります。生成AIの提供元は数か月単位でモデルを差し替えるため、「どの版に対して何回中何回成功したか」を残さないと、対策後の再テストで改善したのかモデルが変わっただけなのかを切り分けられません。報告書のテンプレートを固定し、この4項目を必須欄にしておく。運用としてはそれだけで足ります。

PyRIT・garak・promptfooの守備範囲と自動化ツールの選び分け基準

手作業のプロンプト投入は初回の探索までです。継続するなら自動化の道具立てを決めます。

広く浅く探すスキャナ型と多ターン攻撃を組む実行基盤型との違い

オープンソースの主要な選択肢は性格が分かれており、置き換え関係ではなく補完関係にあります。

garakはプロンプト注入、脱獄、データ漏えい、有害出力といったカテゴリのプローブを多数そろえ、まず反応が出る領域を洗い出す用途に向きます。導入手順と検出項目はGarakによるLLMの弱点洗い出しで扱いました。PyRITは攻撃側にもLLMを立て、応答を見ながらプロンプトを改良する多ターン型の攻撃を組める点が持ち味です。会話を重ねて境界を緩めるCrescendo型の手口を再現するなら、こちらの構成になります。

CI/CDに常設テストとして組み込むときの合格ラインの決め方

promptfooは評価ケースをYAMLで記述し、プルリクエスト単位で回す設計に馴染みます。ここで詰まるのが合格ラインの置き方です。攻撃成功率をすべてゼロにする条件でゲートを組むと、確率的な揺らぎで毎回落ちてビルドが止まります。

実務で回った基準は二段構えでした。機密情報の流出と外部への書き込み操作という重大カテゴリは成功0回を必須条件に置く。有害表現の生成や不適切な口調といった軽微カテゴリは、前回計測からの悪化が無いことを条件にする。試行回数は重大カテゴリで各シナリオ20回以上、軽微カテゴリは5回程度から始めて、揺らぎの幅を見ながら調整していきます。

マネージド型のレッドチーミング機能と自前実装のコストの比べ方

クラウド側が用意する自動レッドチーミング機能を使う手もあります。Azure AI Foundryには、PyRITの攻撃手法を土台にして評価まで一括で回すAI Red Teaming Agentが用意されており（2025年4月に提供開始・提供時点の情報）、その仕組みと運用はAzure Red Teaming Agentの導入と運用で詳しく扱っています。

比較の軸は3つに絞ると判断が速くなります。第一に、対象モデルがそのクラウド上にあるか。他社APIを叩く構成だとマネージド機能の恩恵が薄れます。第二に、攻撃シナリオを自社ドメイン固有に書き換える必要があるか。医療や金融の固有語彙で誘導する検証は、既製のプローブ集では届きません。第三に、結果を既存のチケット管理へ流す接続の手間。この3点が全部「自社固有」に倒れるなら、PyRITベースの自前実装が結局は安く付きました。

EU AI Act・NIST・OWASPが要求する記録と報告書の残し方

技術要件だけでなく、外部から問われたときに提示できる形かどうかも設計に入れます。

EU AI Actが2026年8月に本格適用される際の文書化の位置づけ

EU AI Actは、高リスクAIシステムと汎用AIモデルに関する義務の本体が2026年8月2日から適用されます。システミックリスクを伴う汎用AIモデルの提供者には、敵対的テスト（レッドチーミング）の実施が明示的に要求されており、実施したという事実だけでなく、その内容を文書として残すことが前提になります。

日本国内で開発する受託案件でも、EU域内へサービスを提供する顧客の下請けに入る場合は影響が及びます。契約時点で「レッドチーミングの実施記録を成果物に含めるか」を確認しておくと、後から報告書を作り直す事態を避けられます。適用日と対象範囲は制度側の運用で変わる可能性があるため、案件着手時に原文で確認する運用が安全です。

NIST AI RMF生成AIプロファイルが示す測定活動としての扱い

米国のNISTは2024年7月にAI RMFの生成AIプロファイル（NIST AI 600-1）を公開し、レッドチーミングをリスク測定の活動として位置づけました。ここで押さえたいのは、デプロイ前だけでなくデプロイ後にも実施する対象として書かれている点です。

この「前後で回す」という考え方は、そのまま運用設計に落ちます。リリース判定のゲートで1回、本番投入後は参照文書やシステムプロンプトの変更を契機に再実施する。NISTの文書は法的な強制力を持ちませんが、顧客企業のセキュリティ質問票が参照先として挙げるケースが増えており、実務上の共通言語として使えます。

OWASPのLLM向けリスク一覧と検証項目を対応づける進め方

検証項目を一から作る必要はありません。OWASPが公開するLLMアプリケーション向けのリスク一覧を左に置き、自社の攻撃シナリオを右に並べて対応表を作る。埋まらない行が、そのまま未検証の領域になります。項目の中身と2025年版での変更点はOWASP Top 10 for LLMの全10項目にまとめました。

ツールを使うエージェント構成の場合は、単発プロンプト向けの一覧だけでは足りません。権限の過剰付与や自律的な行動の連鎖といった、エージェント固有の論点を扱う整理も併せて参照します。対応表は表計算1枚で十分です。

内製と外注の損益分岐点とAIレッドチーミングを見送ってよい条件

ここからは判断の話です。全社に一律で勧める工程ではありません。条件を切って結論を示します。

自社にAIレッドチームを常設する判断が成り立つ3つの前提条件

常設が回収できるのは、次の3つが揃った場合だけです。モデルまたはRAGの参照文書を自社で継続的に改修していること。出力が社外の第三者に届くこと。プロンプトやデータの変更が月1回以上の頻度で発生すること。3つ揃えば、外注のスポット診断を毎回発注するより内製の常設が安く付きます。

1つでも欠けるなら、リリース前に外部へ一度依頼し、以降はCIの回帰テストだけを自社で回す形で足ります。特に、社内限定で読み取り専用のRAGを1本動かしているだけの構成に専任チームを置くのは過剰です。判断に迷う段階での体制設計や、検証から対策実装までを含めた進め方はAIセキュリティ対策の支援でご相談いただけます。

レッドチーミングを見送って先にガードレール整備を進めるべき場面

見送ってよい、というより見送るべき場面があります。入出力のログを保存していない場合と、出力を検査する層が一切無い場合です。この状態で検証を回しても、見つけた穴を塞ぐ手段がありません。指摘だけが並んだ報告書が残り、次のリリースで同じ穴が再生産されます。

順序としては、まず全入出力の保存、次に禁止カテゴリの出力検査、その上でレッドチーミング。この逆順で着手した案件は、例外なく2周目でやり直しになりました。予算が一度分しか無いなら、検証ではなく防御層に投じるほうが実害を減らせます。

一度きりの実施で終わらせる運用が失敗する理由と再テストの間隔

年1回の実施で完了とみなす運用は、生成AIでは成立しません。基盤モデルは提供元の都合で差し替わり、システムプロンプトは機能追加のたびに書き換わり、RAGの参照文書は日々増えます。検証時点の前提が3か月後には残っていない。だから合格の証明書としての価値も同じ速度で目減りします。

現実的な間隔は、トリガー型と定期型の併用でした。トリガー型は、基盤モデルの版更新、システムプロンプトの変更、参照文書の追加経路の新設、外部ツール連携の追加という4つの事象で必ず再実施。定期型は四半期に1回、重大カテゴリのみを回す。この配分なら、工数を膨らませずに前提のずれを追いかけられます。

よくある質問

実装や体制の検討でよく挙がる質問をまとめました。

AIレッドチーミングと脆弱性診断は何が違いますか？

脆弱性診断は既知の欠陥パターンを照合して一覧化する作業で、同じ入力に対して同じ結果が返ります。一方のAIレッドチーミングは確率的に応答するAIが相手で、同じ入力でも結果が揺れる点が違いです。その性質上、成果物は「あり・なし」の二値ではなく、試行回数と成功回数を伴う攻撃成功率になります。診断対象がアプリケーションのコードや設定であるのに対し、レッドチーミングはモデルの出力内容そのものと、RAGやツール連携を含む周辺の設計まで踏み込みます。

小規模なチャットボットでもAIレッドチーミングは必要ですか？

出力が社外に届くかどうかで判断します。社外の利用者が直接触れるチャットボットなら、規模に関係なく最低限の検証を入れてください。逆に、社内限定で読み取り専用のRAGを1本動かしているだけなら、優先度は下がります。その場合は本格的な検証より先に、入出力ログの保存と出力検査の層を用意するほうが先です。小規模でも、外部ツールを呼び出す権限を持たせた時点で優先度は跳ね上がります。

AIレッドチーミングの費用はどのくらいかかりますか？

金額は対象範囲で大きく変わるため、費用を左右する要素で見積もると精度が上がります。効いてくるのは、攻撃シナリオの本数、対象がモデル単体かRAGやエージェントまで含むか、試行回数の設定、そして報告書の粒度の4点です。特に試行回数は、確率的な挙動を扱う以上そのまま工数に比例します。オープンソースのスキャナで広域スキャンだけを自社で回し、深掘りの部分だけ外部に依頼する分割発注にすると、費用を抑えつつ精度を保てます。

社内だけでAIレッドチーミングを実施できますか？

実施できます。garakのようなスキャナ型ツールは導入の敷居が低く、初回の広域スキャンは社内のエンジニアだけで回せる範囲です。ただし、攻撃シナリオの発想は開発した本人ほど作りにくいという構造的な問題があります。自分が想定した使い方の外側を突くのが検証の目的だからです。開発担当と検証担当を分ける、あるいは初回だけ外部の視点を入れて攻撃シナリオの型を持ち帰る形が現実的でした。

AIレッドチーミングはどのくらいの頻度で実施すべきですか？

基盤モデルの版更新、システムプロンプトの変更、参照文書の追加経路の新設、外部ツール連携の追加。この4つの事象が起きたときは必ず再実施します。加えて定期実行として、四半期に1回、機密情報の流出と書き込み操作という重大カテゴリだけを回す運用が現実的です。全項目の完全な再実施は年1回に留め、それ以外は変更差分に絞ります。CIに組み込んでおけば、変更を契機とした再実行はほぼ自動で回ります。

関連記事

• AIセキュリティとは？AI固有のリスクと企業に必要な対策・体制：レッドチーミングを含む対策全体の位置づけを経営視点で整理しています
• AIガードレールとは？入力・出力を検査する実装層の設計と選定基準：検証で見つけた問題を塞ぐ防御層の作り方を扱っています
• 敵対的攻撃とは｜敵対的サンプルの手口と実装で効く防御策：生成AI以前から続く入力操作の攻撃系統をまとめています
• Google AIレッドチーム戦略の全体像と従来型セキュリティ手法との相違点：大規模事業者が実際に組んでいる体制の事例です
• AIガバナンスとは？企業に求められる統制の枠組みとガイドライン対応：検証結果を組織の統制へつなぐ枠組みを解説しています