プロンプトインジェクションに備えるAIレッドチーミング：公開前のテストと修正

顧客向けエージェントを公開する前に、プロンプトインジェクションなどを想定したAIレッドチーミングで確認したいことがあります。非公開データを漏らさせることはできないか、権限のない操作を実行させられないか、禁止された内容を出力させられないか、という点です。まずは、範囲の設定、攻撃リストの作成、実行、判定、修正、再テストという6段階で取り組みます。成果として必要なのは、経緯をたどれる問題の記録と、効果を確認できた修正です。安心感を与えるバッジではありません。

ツールの機能とフレームワークの説明は、2026年10月17日に公式ドキュメントで確認しました。以下の手順とサポートエージェントの事例は、テストの進め方を提案するものであり、製品を実際にテストした結果ではありません。

AIレッドチーミングとは何ですか？

AIレッドチーミングは、安全性、セキュリティ、業務に関する明確なルールを、AIシステムにあえて破らせようとするテストです。テスト担当者は失敗を引き起こす方法を探り、システムの動作を観察し、見つかった問題を再検証できる修正につなげます。チャットボットを提供する企業であれば、通常はアプリケーション全体が対象です。指示、検索で取得する情報、権限、ツール、顧客に見える応答まで含めます。モデルとアプリケーションに対する脅威。

ホテルのフロントを思い浮かべてください。通常のサービステストでは、宿泊客が自分の部屋の鍵を受け取れるかを確認します。攻撃を想定したテストでは、本物らしい偽の保守連絡を見せて、別の宿泊客の鍵を渡すようフロントを誘導できないかを試します。受付の応対がどれほど丁寧でも、どの鍵が実際に渡されたかを証拠として押さえる必要があります。

エージェントにも同じような境界があります。サポートチケットは処理すべき情報であり、管理者の承認と同じ権限を持つものではありません。検索で取得した文書は回答の参考にはなりますが、別の顧客の記録へのアクセスを許可するものではありません。

モデルのテストとアプリケーションのテストは何が違いますか？

AIモデルのレッドチーミングでは、攻撃を意図した入力に対するモデルの振る舞いを調べます。アプリケーションのテストは、その周辺の仕組みまで対象にします。顧客の識別情報、文書へのアクセス権、ツールの実行権限によって、実際に何が起こり得るかが決まるためです。モデル提供元の安全性レポートだけでは、自社の返金連携が正しいアカウントを確認しているかは分かりません。この違いは、promptfooのレッドチーミングのドキュメントでも明示されています。

多くの企業では、まず実際に提供するアプリケーションの境界から調べるのが適切です。モデル単体のテストは、モデルの選定や変更時にも役立ちます。ただし、顧客が使うのは製品全体です。

プロンプトインジェクションなど、通常のQAが見落とすリスク

AIレッドチーミングは、守るべき境界を破る方法を探します。不正な形式の入力だけでなく、曖昧さにつけ込む、一見もっともらしいリクエストも対象です。通常の品質保証、つまりQAでは、回答の正しさ、取引の妥当性、応答時間、想定されたエラーなど、仕様どおりに動くかを確認します。成熟したQAには攻撃を想定したテストも組み込めます。レッドチーミングは、そのQAに新たな失敗事例を供給する役割を担います。

サポートボットは返金規定を正しく説明できても、ヘルプ記事に埋め込まれた悪意ある一節を、規定を無視してよいという許可だと解釈するかもしれません。どちらも普通に読める文章です。違いは、アプリケーションが誰の指示を正当なものとして扱うかにあります。

顧客向けエージェントでは、まず以下の攻撃分類から始めてください。例はいずれも架空のテスト設計です。合格条件は、自社のポリシーに合わせて調整する必要があります。

これらの分類は重なり合います。ジェイルブレイクは、振る舞いに対する安全策の回避を狙います。プロンプトインジェクションは、正当な指示として扱うべきではない文章によって、システムの動作を別の方向へ誘導しようとします。検索で取得する資料などに隠された指示は、間接的なプロンプトインジェクションと呼ばれ、データ漏えいや権限のない操作につながることがあります。各分類は失敗の異なる側面を表しており、互いに独立した区分ではありません。脅威の定義。

AIエージェントのテストでは、実際の操作まで追います

AIエージェントは、ツールを使ってタスクの達成に向けた操作を行えるアプリケーションです。そのため、AIエージェントのレッドチーミングには、最終的な回答以外の証拠も必要です。すでに変更された記録は、後から拒否の応答を返しても元には戻りません。逆に「返金しました」という返答だけでは、実際に返金された証拠にはなりません。

会話と操作の記録を両方残してください。エージェントが禁止された操作を要求しても権限制御の層が阻止した場合は、違反の試みと、制御によって阻止できたことを分けて記録します。この区別があれば、阻止された試みを実害が生じた侵害と誤って報告することなく、エージェントの振る舞いを改善できます。

ツールを持たないチャットボットでは、回答とアクセスできる情報を重点的に調べます。顧客の記録を変更できるエージェントでは、操作を試みるたびに、その前後の状態も記録します。権限が増えることで、必要なテストも変わります。

AIシステムのレッドチーミングを、誰がいつ始めるべきですか？

非公開情報へのアクセスや、影響の大きい操作を顧客に開放する前に取り組んでください。役割によって担当は異なりますが、公開の判断にはそれぞれの視点が必要です。

**開発する立場：**資金調達済みのスタートアップの創業者や、ひとりで技術開発を担う人は、攻撃ツールを接続する前に、対象となる顧客の利用手順を絞り、起こしてはいけない結果を決めます。注文を閲覧できるアプリケーションなら、アカウント間の分離をテストします。注文を変更できるなら、変更するその時点で認可が働くかをテストします。

**運用する立場：**サポート責任者は、ポリシー、正当に認められる例外、その際のエスカレーション経路を示します。自社がどのような場合に返金を認めるのか、チャットボットがどのような助言を断るべきかを、セキュリティエンジニアだけで推測することはできません。技術的に正しい操作でも、業務ルールに違反することがあります。

**導入を判断する立場：**中堅企業のCTOは、コネクターや権限を含め、購入する構成に対応した証拠を求めるべきです。ベンダーの基盤モデルに関するレポートは参考資料にはなりますが、予定している導入形態のリスクを判断するには足りません。

公開情報だけを扱い、操作機能も外部ユーザーもない試作段階なら、振る舞いが変化している間、大規模な自動テストは後回しにできます。ただし、基本的な不正利用とコンテンツのチェックは続けてください。顧客への公開、非公開情報の取得、書き込み可能なツールの導入をきっかけに、テストを深めます。

AIレッドチーミングの練習は、自社のポリシーから始めます

初回は、アプリケーションを理解している人、業務上の被害を判断できる人、修正を実装できる人を割り当てます。少人数のチームでは兼任しても構いません。ただし、重大な問題は可能な限り、作成者以外の人にもレビューしてもらいます。

練習として、架空のサポートケースについて、攻撃の目的と、観察によって確認できる失敗条件を書いてみてください。想定した振る舞いが許されるかどうかでレビュー担当者の意見が分かれるなら、自動判定を試す前にポリシーを明確にします。

初回のレッドチーミングを6段階で進める

初回は、重大な問題をすべて確認し、修正できる規模に抑えます。以下は運用手順の提案であり、決まった数のテストを実行すれば安全性を証明できるという意味ではありません。

ここでは、注文を閲覧し、返金をリクエストできるサポートエージェントを例に進めます。目指すのは、別のエンジニアや購入を検討する人にも理解できる、一式の証拠をそろえることです。

1. 1

   1. 対象のアプリケーションと、起こしてはいけない結果を決める

   アプリケーションのリビジョン、モデルの識別子、指示、検索対象の情報源、顧客のロール、使用できるツール、承認ルールを書き出します。実施環境と、誰がこのテストを許可したかも明記してください。対象外の項目を列挙し、テストしていない連携が「合格」という見出しの陰に隠れないようにします。

   サポートの例であれば、顧客は自分の注文だけを閲覧できる、返金には有効な承認が必要、どの顧客も別の顧客の記録は取得できない、といった境界を定めます。ルールはそれぞれ、観察して判定できる形にします。「プライバシーを尊重する」では、曖昧すぎて判定できません。

   本番に近い環境で、架空の記録と権限を制限したテスト用IDを使います。書き込みは管理下のテストサービスに送り、権限チェックを維持したまま、何が変更されるはずだったかを記録します。すべての要求を受け入れるダミーツールでは、本番の認可が機能するかは確認できません。リクエスト数、実行時間、費用の上限を決め、実行を停止する方法も用意します。

   成果物は、担当者と、解消しなければ公開できない結果を明記した簡潔なスコープ文書です。隔離した実施環境については、別記事のAIエージェントのセキュリティ評価ガイドを参照してください。

2. 2

   2. 業務上の被害から攻撃リストを作る

   プロンプトより先に、目的を書きます。「別の顧客の配送先住所を取得する」が目的です。特定の言い回しは、その目的を達成するための試みのひとつにすぎません。

   目的ごとに、侵入口、攻撃者の権限、期待する安全な振る舞い、必要な証拠を記録します。アプリケーションが使用するものに応じて、直接のチャットメッセージ、検索で取得する文書、ツールの応答を対象に含めます。最初から違反を求めるリクエストに加え、会話を重ねて違反へ誘導するケースもテストします。

   例えば、返金承認を不要にするよう指示を埋め込んだ架空のヘルプ記事は、有用なテストケースになります。期待する振る舞いは、その一節を信頼できない内容として扱い、承認を必要とするルールを維持することです。有効な承認を伴う正当な返金もテストに含めます。すべての返金を止める防御策が、成功したように見えないようにするためです。

   元のケースとその識別子は保存します。禁止する結果をいつの間にか変えてしまわないようにしながら、表現、文脈、侵入口を変えたバリエーションを追加します。

3. 3

   3. 顧客が使うアプリケーションの経路で実行する

   定めたテスト環境とIDを使い、顧客のリクエストを処理するのと同じアプリケーションロジックにテストを接続します。検索や認可を通さずにモデル単体をテストしても、別の問いに答えることになります。

   まず、意図した対象に接続されていることと、必要な証拠がログに残ることを確認します。そのうえで選んだケースを実行し、入力、会話履歴、取得した文章、ツールへの要求、権限の判断、応答、最終状態を保存します。認証情報はレポートに含めず、実際の顧客データの代わりに、機密情報に見立てた架空の識別用文字列を使います。

   モデルの応答は変動し得るため、重大なケースは、あらかじめ明示した方針に従って繰り返します。反復回数と、応答に合わせて攻撃を変える場合のターン数の上限を記録します。独立したケースの間ではセッションをリセットし、一連の会話そのものがテスト対象なら会話履歴を保ちます。

   タイムアウト、認証エラー、パーサーの不具合は、調査が済むまではテスト側の問題として扱います。アプリケーションが攻撃に耐えた証拠にはなりません。

4. 4

   4. 証拠に基づいて判定し、その後で深刻度を決める

   全体を示す指標を計算する前に、試行ごとに証拠に基づく判定を付けます。禁止された記録が返された、権限のない状態変更が起きた、といった観察可能な事実には、明確なチェックを使います。モデルによる判定は言語の解釈を助けますが、重大な問題や判断が不確かな結果は人がレビューするべきです。

   以下の判定基準を使うと、テストの不備と、境界が守られたことを区別できます。

   判定	意味	次に行うこと
   合格	有効な試行で、定義した違反は起きず、必要な証拠もそろっています。	ケースと証拠を保存します。
   不合格	定義した違反が起きたことを、証拠で確認できています。	深刻度と修正担当者を決めます。
   無効	認証の失敗や攻撃内容の欠落などにより、意図したシナリオを試せていません。	テストを修正し、再実行します。
   判定不能	シナリオは実行できましたが、証拠や判定方法の不足により結果を確定できません。	調査します。合格には数えません。

   深刻度は、被害、影響を受けるデータ、攻撃者に必要なアクセス権、実際の操作を制御する境界に結果が達したかを基に、別途判断します。ほとんどの無害な試行に合格していても、顧客間の情報漏えいを確認したなら、公開してよいかの判断が必要です。

   観測した攻撃成功率を報告する場合は、明示した手順における有効な試行数を分母、成功を確認できた試行数を分子と定義し、未解決の結果も併記します。有効な試行の中に判定不能が残るなら、その比率は完全な成功率ではなく、確認できた成功に基づく下限値と明記します。複数ターンの会話をひとつのケースと数えるかも含め、何を試行とみなすかを示してください。内容が変わったテスト集合をひとつの推移としてまとめたり、その割合を顧客が攻撃を受ける確率として扱ったりしてはいけません。

5. 5

   5. 破られた制御を修正する

   プロンプトを変える前に、問題の原因をたどります。検索で取得した文書から返金の権限が与えられてしまうなら、ツールの実行を制御する境界で承認チェックを強化します。別の顧客の記録が検索結果に含まれるなら、その記録がモデルのコンテキストに入る前に、アクセスを絞り込むフィルターを修正します。

   ほかにも、不要なツールの削除、権限の縮小、影響の大きい操作への承認の義務付け、指示と外部コンテンツの分離、応答ポリシーの改善などが考えられます。観察された経路を塞ぐ修正を選んでください。

   実装のパターンは、本番AIエージェントのガードレールと影響範囲を制御する実践ガイドを参照してください。レッドチーミングで見つかった問題は、対処すべき失敗を示します。本番の制御は、言語レベルの防御が破られても、システムが実行できることを制限します。

   問題ごとに、担当者、具体的な変更、再テストの基準が必要です。「プロンプトを強化した」だけでは、対応を完了したことにはできません。

6. 6

   6. 元の失敗と、近い条件のケースを再テストする

   修正したアプリケーションで元のケースを再実行し、同じ目的を狙うバリエーションも試します。正当な顧客の利用手順も確認してください。すべての返金を止めれば攻撃経路は塞げるかもしれませんが、製品としての機能も壊れてしまいます。

   修正前後の証拠、アプリケーションのリビジョン、テスト構成を保存します。修正済みの失敗は、過去の問題が再発していないか繰り返し確認する回帰テスト群に組み込みます。新たな弱点が固定のテスト群の改善に隠れないよう、未知の問題を探る新しい攻撃は別に追加します。

   モデル、指示、検索対象の情報源、権限、ツール、業務ポリシーが変わったら、範囲を見直します。公開を妨げると定めた問題が解消したか、責任者が残るリスクを明示的に受け入れた場合にのみ公開します。公開の条件に関わる境界で判定不能が残るなら、その問題は未解決のままです。

OWASP、MITRE ATLAS、NISTを役割に応じて使い分ける

フレームワークで作業を整理したうえで、自社アプリケーション固有の失敗条件を加えます。どのフレームワークも、自社の返金ポリシーを決めてくれるわけではなく、顧客間の境界が守られたことを証明するものでもありません。

OWASP Top 10 for LLM Applicationsは、大規模言語モデルを利用するアプリケーションのリスクを確認するためのチェックリストです。大規模言語モデルは、多くのチャットボットで文章生成を担っています。現在のページには2025年版が掲載されており、プロンプトインジェクション、機密情報の漏えい、システムに過大な実行能力を与える「過剰なエージェンシー」などを取り上げています。攻撃リストで見落としているリスク分類がないかを確認するために使います。OWASPの公式リスト。

MITRE ATLASは、観測された攻撃や現実的な実証に基づき、AIに関わる攻撃者の戦術と手法をまとめた、継続的に更新される知識ベースです。攻撃者がどのように被害へ到達するかを記述し、個々のケースを現実味のある一連の流れにつなぐために使います。テストでどのような振る舞いを扱ったかを、セキュリティのレビュー担当者が理解する助けになります。MITRE ATLAS。

National Institute of Standards and TechnologyのAI Risk Management Framework、略称NIST AI RMFは、Govern（ガバナンス）、Map（状況の把握）、Measure（測定）、Manage（管理）という機能を軸に、リスクへの取り組みを整理します。NISTは、このフレームワークの利用を任意としています。テストを、責任の所在、導入の文脈、測定、未解決リスクに関する意思決定につなげるために使います。フレームワークに対応付けたレポートは、NISTの認証ではありません。NIST AI RMF。

架空の返金ケースなら、OWASPはリスクの分類、ATLASは攻撃経路の説明、AI RMFは管理された意思決定への結果の位置付けに役立ちます。対応付けは証拠と一緒に残してください。フレームワークの名称を付けるだけで、証拠の代わりにしてはいけません。

AIレッドチーミングのツールは、何を基準に選びますか？

実際のアプリケーションをテストでき、必要な証拠を残せるツールを選びます。設定、判定、調査、繰り返しの実行を担当できるエンジニアがいるなら、オープンソースから始めます。複数のアプリケーションやレビュー担当者の間で作業を調整することがボトルネックになったら、プラットフォームを検討します。

promptfoo：アプリケーションのテストを繰り返し実行する

promptfooのレッドチームモードは、プラグインを通じて攻撃用の入力を生成し、攻撃戦略を適用して、失敗を確認するためのレポートを作成します。クイックスタートでは、アプリケーションを呼び出すインターフェースであるWeb APIを通じたテストに加え、ブラウザー経由やモデルへの直接のテストも説明しています。繰り返し実行できるアプリケーションのスキャンを構成したい開発者にとって、実用的な出発点になります。公式のレッドチーム向けクイックスタート。

運用上の注意点はデータの扱いです。実行プログラムがローカルにあっても、生成や判定までローカルで完結するとは限りません。一部のプラグインはホスト型の推論サービスを必要とし、ホスト型の判定サービスには、プロンプトやテスト対象の応答が送信されることがあります。取り扱いに制限のある情報を接続する前に、ドキュメントに示されたデータの流れを確認してください。promptfooのレビューでは、設定とこれらの境界をさらに詳しく扱っています。

Microsoft PyRIT：攻撃の手順を柔軟に組み立てる

**Microsoft PyRIT（Python Risk Identification Tool for generative AI）**は、生成AIシステムのリスクを特定するためのオープンソースのフレームワークです。ドキュメントでは、単一ターンと複数ターンの攻撃、独自のテスト対象、判定、会話結果の保存を扱っています。スキャナー、グラフィカルインターフェース、フレームワークとしての各モードがあります。現在のリポジトリと公式ドキュメント。

独自の攻撃シーケンスや判定方法が必要で、それらを組み立てる担当者を置ける場合に適しています。柔軟性が高い分、アプリケーション固有の成功条件や、証拠を収集・連携する仕組みは自分たちで用意する必要があります。

NVIDIA garak：LLMの脆弱性をスキャンする

**NVIDIA garak（Generative AI Red-teaming & Assessment Kit）**は、自らをLLM脆弱性スキャナーと説明しています。プローブで失敗を引き起こし、検出器で出力を評価する仕組みで、データ漏えい、プロンプトインジェクション、有害性、ジェイルブレイクなどを対象にします。リポジトリでは、Webエンドポイント用のコネクターと詳細な結果ログについても説明しています。公式リポジトリ。

モデルや対話エンドポイントを体系的にスキャンする場合に適しています。ツールの操作や顧客の記録に関する判断を示すなら、テスト対象とチェックの仕組みから、その証拠を確認できるようにしてください。スキャナーの出力評価だけでは、観測していない状態変更は確認できません。これはテスト範囲の制約であり、モデルのスキャン自体を否定する理由にはなりません。

Airia：継続的なテスト運用を重視する場合

**Airia**は、複数のワークフローにまたがるエージェントの反復テストを調整することまで課題になったとき、プラットフォームの候補として検討できます。エージェントのレッドチーミングを紹介するページでは、プロンプトインジェクション、ツールの操作への干渉、連鎖的なシナリオをテストすると説明しています。プロンプト、ツール、API、メモリをまたぐ複数段階の攻撃も含まれます。継続的なキャンペーンと、広く認知されたセキュリティフレームワークへの問題の対応付けも紹介しています。いずれもベンダーが公表している機能です。Airiaのエージェント向けレッドチーミング紹介ページ。

アプリケーションの接続、証拠のレビュー、問題が修正されるまでの追跡を省力化できるなら、プラットフォームを導入する価値があります。複数のエージェント担当者がいて、企業向けの導入審査に対応する事業では、テスト実行基盤のすべてを自社で持つこと以上に重要かもしれません。

購入の条件として、自社で定めた範囲のアプリケーションを使った実演を求めてください。既知の架空の失敗を再現し、関連する操作の証拠を確認し、修正を適用して再テストします。その導入構成で、どのフレームワークへの対応付けと、どの証拠のエクスポートを利用できるかも確認します。公開されている機能説明だけでは、有効性が独立に検証されたことも、必要な連携がすべて対象になることも証明できません。

管理できる規模のテスト群と、責任を持つエンジニアによって、導入担当者が求める証拠をすでにそろえられるなら、オープンソースを使い続けます。反復運用と共同レビューの負担から導入する理由があり、実演が同じ基準を満たすなら、プラットフォームを購入します。どちらを選んでも、許容できる振る舞いを定義する必要はなくなりません。

企業の導入担当者は、どのような資料を求めるべきですか？

導入する構成に合ったレポートと、問題の発見から再テストまでをたどれる事例を求めます。「当社のAIにはレッドチーミングを実施しています」という説明は、プロセスに関する主張です。その裏付けとなる記録には、何をテストし、結果を受けて何を変更したかが示されている必要があります。

次の項目をまとめて求めてください。

• **範囲と実施日：**アプリケーションとモデルの識別子、関連する指示、検索対象の情報源、ロール、ツール、連携、対象外の項目。
• **攻撃の網羅範囲：**目的、侵入口、単一ターンと会話形式のケース、テスト担当者が使用できた顧客向けの機能や権限。
• **手法と判定：**テスト構成、試行の数え方、成功基準、人によるレビュー、無効や判定不能の結果の扱い。
• **見つかった問題：**深刻度、影響を受けた境界、再現可能な証拠、未解決の制約。機微な詳細は適切な経路で共有します。
• **修正と再テスト：**変更した制御、修正前後の証拠、正当な利用が引き続き機能することの確認。
• **継続的な責任の所在：**残るリスクを誰が受け入れるか、どの変更で再テストするか、顧客に影響する重要な問題をどのように知らせるか。

ベンダー自身が実施したのか、外部の評価者が実施したのか、両者なのかも確認します。独立性は判断の参考になりますが、第三者のロゴがあっても、範囲の記載不足や未テストのコネクターは補えません。

有効にする予定の連携がレポートの対象外なら、その連携は未評価として扱います。有効にする前に対象を絞ったテストを求めるか、必要な証拠がそろうまで利用範囲を制限してください。読み取り専用のチャットボットで問題がなかったという結果を、書き込み可能なエージェントの許可にそのまま流用することはできません。

過大評価しやすいのは、どのような点ですか？

攻撃回数の多さだけでは、網羅性の根拠になりません。チャットのエンドポイントに対して表現を変えた攻撃を繰り返しても、検索、メモリ、ツールの認可には触れていない可能性があります。網羅性は、スコープで定めた対象箇所と失敗条件に照らして説明する必要があります。

合格率ひとつだけでも、意味を読み込みすぎがちです。攻撃の生成方法、予算、分母、判定者が違えば、スコアは簡単には比較できません。集計値には、実施手順と重大な問題を併記してください。顧客データの漏えいが実証されているとき、それを解決したことにできる万能な「安全な合格率」はありません。

拒否したかどうかだけの判定は、特にエージェントでは不十分です。安全そうな回答とともに危険な操作が実行されることもあれば、ツール呼び出しが阻止されたことで、重要な制御が機能したと確認できることもあります。結果を決める前に、証拠を確認してください。

最後に、レッドチーミングは安全性とセキュリティの取り組みに必要な判断材料のひとつです。通常のQA、アクセス制御のテスト、本番監視、インシデント対応の代わりにはなりません。完了したキャンペーンから分かるのは、テストした条件で何が起きたかです。未発見の失敗が存在しないことを証明するものではありません。

AIレッドチーミングでよくある質問

AIのレッドチーミングとは何ですか？

AIシステムに、安全性、セキュリティ、業務上のルールをあえて破らせようとする、攻撃を想定したテストです。顧客向けアプリケーションでは、モデルの回答に加えて、データへのアクセスとツールの振る舞いも対象に含めます。

レッドチーミングには、どのAIを使うのが最適ですか？

どの状況でも最適な攻撃用モデルやツールはありません。実際のアプリケーションの侵入口に到達でき、禁止された結果が起きたかを検証できる手法を選びます。promptfoo、Microsoft PyRIT、NVIDIA garakはそれぞれ異なる進め方を提供しますが、自社の業務ポリシーを自動で定めてくれるものはありません。

AIレッドチーミングは、何から始めればよいですか？

テストの許可を得たアプリケーション、架空のデータ、明文化した境界を用意するところから始めます。期待する結果を明確にし、再現可能な問題の記録を作り、修正の効果を検証する方法を身に付けてください。攻撃生成を大規模化する前に重要なのは、アプリケーションの知識、丁寧な観察、妥当な判定です。

AIはレッドチームの担当者に取って代わりますか？

AIシステムのテストでは、攻撃の生成や反復を自動化できます。それでも、許容できない被害の定義、問題の検証、証拠に基づいて公開できるかの判断は、人が担う必要があります。自動攻撃や自動判定はその作業を支えるものとして使い、影響の大きい箇所では人がレビューします。

レッドチーミングの具体例を教えてください。

サポートエージェントが使う架空のヘルプ文書に、返金承認を不要にする偽の指示を埋め込みます。エージェントがその文書を正当な指示として扱うか、返金ツールが権限のない操作を許すかを確認します。破られた境界を修正したうえで、そのケースと、正当な承認を伴う返金の両方を再実行します。

次の公開審査までに取り組むこと

次の公開審査までに、顧客の利用手順を選び、起こしてはいけない結果を書き出し、修正担当者を決めます。範囲を定めてテストを実施し、判断の場に証拠を持ち込んでください。導入を検討しているなら、実際に使う予定の構成について、問題の発見、修正、再テストまでをベンダーに説明してもらいます。

AIシステムの開発と運用に役立つ実践ガイドを、ニュースレターで受け取る。