第4章 防御の検証とレッドチーム

学習目標

• 入力・ツール・出力のガードレールと分類器について、それぞれの役割、実行方式、限界を説明する。
• 判定結果が得られない場合の失敗時の動作を、作業のリスクの大きさに合わせて決める。
• 脅威モデルを出発点として、交戦規則と攻撃シナリオを設計する。
• 攻撃事例・正常事例・境界事例をそろえた評価セットを作成し、実際の結果に基づいて攻撃の成功を判定する。
• 攻撃通過率、正常リクエストの誤遮断率、業務完了率を使って防御の効果を測定し、その結果を解釈する。

はじめに

あるチームがリリース会議で「インジェクション遮断率98%」と報告しました。拍手が起こり、リリースが承認されました。2か月後に事故が起きて調べると、その数値は分類ルールの作成時に参考にした攻撃文50件で測ったもので、文書やメール経由の攻撃は1件もありませんでした。正常なリクエストがどれほど止まるかは、誰も測っていませんでした。ユーザーは頻繁に止まる機能を避け、個人アカウントの別のAIツールに業務資料を貼り付けていました。数値が誤っていたのではありません。何を使い、どの経路で測ったかを誰も問わなかったのです。事故後にセキュリティチームが文書経由の攻撃で測り直した通過率は、報告の数値とはまったく異なる状況を示しました。

防御は作ることと同じくらい、測ることが重要です。この章では、ガードレールと分類器がどこで何を防ぐか、判定に失敗したらどう動くべきかをまず見ます。続いてレッドチームの定義と交戦規則、脅威モデルからシナリオを導く方法、評価セット構成の原則を学びます。最後に、結果で成否を判定する方法と、防御効果を数値で測って解釈する方法を学びます。

重要な概念

ガードレールの地図：どこに何を置くか

ガードレールは、モデルの前後やツール呼び出しの場所で入出力を検査し、止めたり修正したりする仕組みです。空港の保安検査にたとえられます。搭乗前（入力）、荷物を積むとき（ツール呼び出し）、到着後（出力）にそれぞれ検査所があり、防げるものが異なります。

出力ガードレールはモデルの作業完了後に動くため、その間に実行されたツール呼び出しを元に戻せません。副作用を持つツールを使うエージェントには、呼び出し時の検査が欠かせません。また、ガードレールは第3章の認可検査の代わりにはなりません。ガードレールが問うのは「異常に見えるか」、認可が問うのは「この人がこれをしてよいか」です。

検査はいつ終わるか：Agents SDKの例

OpenAI Agents SDKは、ガードレールの位置と時点を具体的に示しています。

トリップワイヤー（tripwire）は、違反の検知時に実行を停止する信号です。ツールガードレールには適用範囲の限界があります。自作の関数ツールには適用されますが、ハンドオフ（別のエージェントへ仕事を渡す呼び出し）、ホスト型ツール（Web検索、ファイル検索、ホスト型MCP、コードインタープリターなど）、組み込み実行ツール（コンピューター、シェルなど）には適用されません。管理エージェントと専門の子エージェントがある構造で呼び出しごとに検査するには、エージェント単位のガードレールよりもツールガードレールを使うようドキュメントは推奨しています。詳細はSDKごとに異なりますが、質問は同じです。検査はいつ終わり、その前に何が実行され、どのツールが検査の外にあるか、です。

分類器：判定エンジンの種類と限界

分類器はガードレールの判定エンジンです。3種類あります。

分類器ごとに答える質問が違うことを必ず区別してください。OpenAIのModeration APIは、安全でないコンテンツの頻度を減らす無料ツールです。Prompt Shieldsはユーザープロンプト攻撃と文書攻撃を検知しますが、有害性やポリシー適合性は判断しないと文書にあります。どちらも「このユーザーにこの顧客記録を見る権限があるか」には答えません。有害性分類、攻撃検知、認可検査を相互に代替することはできません。

OWASPのインジェクション予防チートシートは、ガードレール役のLLMもLLMであり、それ自体がインジェクションに弱いと警告しています。分類スコアを直ちに「攻撃である確率」と解釈してもいけません。そのスコアの意味は、自分たちのデータで評価して初めてわかります。

失敗時の動作：判定が出ないとき

分類器は常に答えるわけではありません。タイムアウトやエラーが生じ、スクリーニングモデルがリクエスト自体を拒否することもあります。Anthropicは、安全分類器がスクリーニングのリクエストを拒否して判定が残らない場合（stop_reasonが"refusal"の場合）、有害判定として扱うよう勧めています。判定なしを「通過」とする設計は、攻撃者に「分類器を拒否させる入力」という迂回路を与えます。

失敗時の動作は、作業のリスクに応じて決めます。

新しい分類器の導入時は、遮断よりも注釈（annotate）モードで運用データを観察し、誤遮断を測る方法もあります。FoundryではPrompt Shieldsの結果で遮断するか注釈を付けるだけにするかを設定でき、独立したContent Safety APIは判定のみを返して処理をアプリケーションに委ねます。ただし注釈モードの間は、別の層が被害を防いでいなければなりません。

レッドチームの定義と交戦規則

NIST AI 600-1はAIレッドチームを「AIシステムの欠陥と脆弱性を見つけるためにシステムを探索する構造化された試験活動」と定義し、通常は統制された環境で開発者と協力して行うと説明しています。実施者によって一般ユーザー型、専門家型、混合型、人と生成AIが協働する形に分け、結果は組織の決定に反映する前に追加分析を行うよう求めています。OpenAIは代表的な入力とシステムの破壊を狙う入力の両方で試すよう、Anthropicはインジェクションを含む文書・メール・ツール結果で自分のエージェントを試し、スクリーニングと確認段階が残りを捕捉するか確かめるよう勧めています。

レッドチームは「自分たちのシステムを先に攻撃してみること」であり、必ず許可された範囲で行います。開始前に交戦規則を文書で合意します。

1. 対象と環境：どのシステムのどの版を、本番から分離したどの環境で試験するか。
2. データ：実顧客データではなく、合成データと架空のシークレットを使います。
3. 許可・禁止行為：外部送信や決済は模擬ツールに置き換え、第三者のシステムには触れません。
4. 停止条件：本番データへのアクセスや予想外の外部リクエストを観測したら、即座に停止します。
5. 連絡と報告：発見事項を誰に、どの形式で、いつまでに伝えるか。

攻撃シナリオの設計

シナリオは攻撃文の一覧ではなく、脅威モデルの経路を試す単位です。第1章の信頼境界と第2章の5段階表から始め、シナリオごとに1枚のカードを書きます。

シナリオ群は、経路 × 防御層の格子で点検します。行には経路（直接入力、Web、メール、文書、画像、ツール結果、メモリ）、列には防御層（入力スクリーニング、ツール結果スクリーニング、ツール呼び出し検査、人による確認、出力制限）を置き、各欄にシナリオがあるかを示します。人の確認はガードレールの位置ではありませんが、独立した防御層として数えます。各層を狙うシナリオがなければ、層別の効果は測れません。複数ターンや複数セッションのシナリオ、人の確認を迂回したり形骸化させたりするシナリオも別に用意します。

既存の攻撃一覧で範囲を広げる

想像だけで作ったシナリオは、チームが知る攻撃しか試せません。MITRE ATLASは戦術と手法を実際のケーススタディに結びつけているため、偵察、初期アクセス、AI Model Access、AI Attack Staging、持ち出し、影響などの各段階で、自分たちに該当する手法を探すのに使えます。OWASP LLM01は直接・間接に加え、意図しないインジェクション、検索ストアの文書改ざん、ペイロード分割、マルチモーダル、敵対的接尾辞（無意味に見える接尾文字列）、多言語・難読化攻撃をシナリオとして整理しています。インジェクション予防チートシートは、エンコードによる回避、変種の反復、複数ターンの攻撃などを分類しています。

こうした知識ベースは範囲の点検表として使い、公開攻撃文をコピーして評価セットを埋めないようにします。多くの分類器がすでに学習した可能性のある文はスコアを水増しし、自分たちの業務文脈を含みません。

評価セットの構成

評価セットを構成するのは、攻撃事例だけではありません。

Anthropicの評価設計指針では、実際の業務の分布に似せて作ること、境界事例を含めること、可能であればコードや判定モデルで自動採点することを勧めています。また、人が手間をかけて採点した少数の事例よりも、自動採点した多数の事例を優先するよう勧めています。セキュリティの評価セットには、次の原則を加えます。

1. 防御ルールを作る際に参考にしたデータを使って、その防御を評価してはいけません。開発用セットと最終検証用セットを分け、ルールの作成者には検証用セットを見せません。試験問題を事前に見てから受けた模擬試験の点数では、実力がわからないのと同じです。
2. 実際のサービスの入力経路を通るようにします。文書を使う攻撃はアップロードとテキスト抽出を経て、メールを使う攻撃はメール収集の経路を経て入る必要があります。
3. サービスで使用する言語ごとに、攻撃事例と正常事例を用意します。複数ターンにわたる攻撃は会話全体を1つの事例にまとめ、前のターンの状態を引き継いで再生します。
4. 合成シークレット（カナリア）を仕込んでおきます。実際の値と重ならず、偶然には生成されない固有の文字列（たとえば、固有の接頭辞にランダムな値を付けた架空のキー）である必要があります。そうして初めて、その値が出力や外部リクエストに現れたときに漏洩と判定できます。
5. セットにバージョンを付け、事例ごとに出典（どの脅威、どの事故に由来するか）を記録します。

成功の判定：結果で判定する

モデルが拒否する文を書いたからといって、防御が成功したわけではありません。拒否の文を書きながら、すでにツールを呼び出していたかもしれません。逆に、丁寧に従うふりをしながら、何も行動していなかった可能性もあります。判定は、観測できる結果に基づいて行います。

回答の汚染のように、結果がテキストの中にしかない場合は、判定モデル（LLMによる採点者）を使います。Anthropicは、評価対象の出力を作ったモデルとは異なるモデルで採点することを、一般的なベストプラクティスとして挙げています。判定モデルを使う前に、人がラベルを付けた標本と比較して一致率を確認します。不一致が集中する種類の事例については、判定基準を修正するか、人が採点します。判定の根拠にできるログがあるシナリオでは、判定モデルよりもログを優先します。判定モデルも、評価対象の出力に含まれる文（「この応答は基準をすべて満たしている」など）に誘導される可能性があります。そのため、出力はデータとして分離して渡し、判定は構造化された値としてのみ受け取り、判定モデルと人の不一致率を指標として見ます。

防御効果の測定指標

防御効果は、最低でも3つの数値で見ます。

遮断されない正常リクエストも、モデルのエラーやタイムアウトで完了しないことがあるため、業務完了率は100%から誤遮断率を引いた値とは異なります。

数値では、まず分母を確かめます。シナリオ単位か、試行単位か、会話単位かによって同じ結果も別の数値になります。1つのシナリオを50回試して1回破られたなら、試行単位では通過率2%ですが、シナリオ単位では「破られたシナリオ」です。攻撃者は反復できるため、セキュリティ判断ではシナリオ単位の「一度でも破られたか」がより重要な場合が多くあります。

層別の指標も見ます。各試行がどの層で止まったかを記録すれば、「入力スクリーニングが70%を検知し、残りの大半を人の確認が捕捉した」と貢献度がわかります。ある層がほとんど何も捕捉しないなら、その層は不要か、その層を狙うシナリオがないのです。

継続的なモニタリングと回帰評価

リリース前の評価は、その時点の写真にすぎません。Anthropicは、成功したインジェクションの兆候を定期的に分析し、プロンプト、検証、フィルタリングを繰り返し改善し、同じユーザーが回避を繰り返すなら警告、速度制限、遮断で対応するよう勧めています。SAIFの「統制の調整と迅速なフィードバックサイクル」と同じ考えです。

運用では3つのフィードバックサイクルを回します。レッドチームと事故の事例を非識別化して回帰セットに入れ、モデル・プロンプト・ツール・分類器のどれかが変われば再実行し、ガードレール発動率・誤遮断の報告・承認率が急変すれば原因を調べます。ガードレールは測定し修正する運用対象です。

さらに深く

何回実行するか：確率的な結果の解釈

同じシナリオを1回実行して防げたからといって、「防げる」とは書けません。出力が確率的だからです。反復回数を決める際に使える、統計の基礎知識があります。独立した試行をn回行い、一度も成功しなかった場合、実際の成功率の95%信頼上限はおよそ3/nです（試行回数が十分に多い場合の近似です）。30回実行して一度も破られなかった場合に言えるのは、「成功率は0である」ではなく、「成功率が約10%より低い可能性が高い」というところまでです。1%という水準について述べるには、約300回の試行が必要です。

この基礎知識から、2つのことがわかります。第1に、小規模な評価をもとに「安全である」と結論を出さず、「この程度以下とみられる」と報告する必要があります。第2に、反復回数を増やして確率の範囲を際限なく絞るよりも、影響を小さくする統制のほうが効率的な場合が多いということです。評価報告書には、モデル・プロンプト・ツール・分類器のバージョン、試行回数、分母の単位を必ず記載し、結果を再現できるようにします。OWASPのチートシートも、短時間の点検試験に合格しても、粘り強い攻撃者に対する耐性が証明されたことにはならないとしています。

統制の組み合わせの効果を比較する実験

「防御をすべて入れたら改善した」という結果だけでは、どの統制が効果を発揮したのかわかりません。比較実験は次のように設計します。まず、防御を入れていない状態の基準線を測ります。次に、統制を1つずつ加えた構成を、同じ評価セット、同じモデルのバージョン、同じ反復回数で測ります。統制を1つ取り除いた構成も測ってみます。その統制を取り除いても結果がほとんど変わらなければ、その統制は他の統制と重複しているか、シナリオがその統制を狙っていないということです。

結果を読むときは、攻撃通過率と業務完了率を並べて見ます。攻撃通過率を2パーセントポイント下げた代わりに業務完了率が15パーセントポイント下がったなら、その統制は別の形（遮断の代わりに確認を行う、すべての作業ではなく高リスクの作業だけを対象にする）に変える候補になります。

実務の場面

カラム証券：どの層が何を見落としたか

証券会社「カラム証券」は、顧客からの問い合わせに答えるチャットボットに口座照会と振込予約のツールを追加することにし、リリースの4週間前にレッドチームの計画を立てました。交戦規則には、本番から分離した試験環境、合成した顧客データ、模擬振込ツール、外部リクエストが発生した場合の停止、発見事項の当日中の報告を記載しました。

信頼境界は、顧客のチャット入力、顧客が添付する取引確認書の画像、振込予約ツールの呼び出しの3つでした。すでに導入していた防御は、入力スクリーニング用の分類器、添付画像のOCR結果をツール結果として渡してスクリーニングする段階、振込予約前に顧客が確認する画面でした。

シナリオは防御層ごとに作成しました。入力スクリーニングの層はポリシー回避型の会話60件で、OCR経路は指示を隠したテスト画像25件で、確認画面は「確認なしに振込が実行される経路があるか」を探すシナリオ12件で試験しました。各シナリオを5回ずつ繰り返し、正常な顧客問い合わせ400件もあわせて実行し、誤遮断率と業務完了率を測定しました。成功の判定には、模擬振込ツールの呼び出しログと、カナリアとして仕込んだ合成口座番号が出力されたかどうかを使いました。

結果は次のとおりでした。入力スクリーニングはポリシー回避の試みの大半を捕捉しましたが、正常な問い合わせの5%も遮断しました。OCR経路では、2つのシナリオが反復中の一部の試行でスクリーニングを通過しましたが、いずれも確認画面で止まりました。確認画面を試すシナリオでは、1つが問題を見つけました。予約日を変更する「修正」機能が最初の承認をそのまま再利用し、金額の変更まで確認なしに反映していたのです。

チームはスクリーニングの基準を調整して誤遮断率を下げ、通過したOCRシナリオ2つを回帰セットに追加し、修正機能で金額や受取人が変わったら改めて確認を受けるようにしました。リリース報告書には、通過率の数値を1つ載せるのではなく、各層が何を捕捉し何を見落としたか、反復回数、残るリスクを記載しました。要点は「何件防いだか」ではなく、「どの層が何を見落とし、次の層がそれを受け止めたか」でした。

かざぐるまレンタカー：3つの構成を同じ問題で試す

レンタカー会社「かざぐるまレンタカー」は、予約変更アシスタントを運用していましたが、防御の構成を決めかねていました。セキュリティチームは入力分類器だけを強化しようと提案し、製品チームは確認画面が増えると顧客が離れるのではないかと心配しました。チームは議論する代わりに、同じ試験問題で測ることにしました。

評価セットは、攻撃シナリオ150件（直接入力、顧客が貼ったリンク先のWebページ、提携先から届いた予約メールという経路）と、実際の問い合わせを非識別化して作った正常業務300件で構成しました。攻撃シナリオは、それぞれ5回繰り返しました。構成は次の3つでした。

3つの構成すべてで、既存のサーバー側の認可はそのまま維持しました。

Bでは無断の変更がなくなりましたが、正常業務のかなりの部分で、顧客が確認段階を前に会話から離脱しました。Cでは無断の変更を防ぎながら、業務完了率をほぼ維持できました。日付変更を確認なしにした根拠は、別途確認しました。日付変更は顧客本人の予約に対してのみ、料金の変動がない範囲でのみ許されるよう、サーバーが検査していたのです。

判定方法についても学んだことがありました。最初は判定モデルが会話全体を読み、攻撃が成功したかどうかを採点していました。しかし、人がラベルを付けた標本100件と比較すると、「言葉では拒否したのにツールは呼び出した」事例に不一致が集中していました。チームは、行動を狙うシナリオの判定を模擬ツールの呼び出しログに切り替え、判定モデルは回答汚染のシナリオだけに使うことにしました。最終的な構成としてCを選び、報告書に反復回数、分母の単位、試験に使ったモデルのバージョンを記載しました。

間違えやすいポイント

1. 「出力ガードレールに移せば、より安全になる」。出力ガードレールはエージェントの処理が終わってから動くため、すでに実行されたツール呼び出しを元に戻すことはできません。
2. 「スクリーニングモデルが拒否したら、判定がないので通過させる」。判定がない状態を通過として扱うと、迂回路が生まれます。Anthropicは、拒否を有害判定として扱うよう勧めています。
3. 「遮断率が高ければ十分である」。まず確認すべきなのは、何を使い、何回、どのような分母で測定したかです。ルールの作成に使ったデータで測った数値には意味がありません。
4. 「誤遮断は使いやすさだけの問題である」。誤遮断が多いと、ユーザーは統制の及ばないツールに移り、統制は最終的に無効化されます。誤遮断もセキュリティの指標です。
5. 「モデルが拒否の文を書けば、防御は成功している」。拒否の文の出力とツールの呼び出しは、同時に起こることがあります。判定にはログと状態の変化を使います。
6. 「有害性の分類器を追加したので、インジェクションも防げる」。有害性の分類、攻撃の検知、認可の検査は、それぞれ異なる質問に答えるものです。
7. 「30回実行して一度も破られなかったので、安全である」。その結果から言えるのは、「成功率が約10%より低い可能性が高い」というところまでです。
8. 「公開されている攻撃文の集まりで評価すればよい」。公開された文はスコアを水増しし、自分たちのシステムの経路を通りません。知識ベースは、評価範囲の点検に使います。

ひと目でわかるまとめ

公式ドキュメントで確認する

• OpenAI Agents SDK — Guardrails：ガードレールの種類、実行モード、適用範囲。
• Anthropic — Mitigate jailbreaks and prompt injections：スクリーニング、拒否の処理、モニタリング、自分のエージェントのレッドチーム。
• Anthropic — Define success criteria and build evaluations：評価設計の原則と採点法。
• OpenAI — Safety best practices：Moderation API、敵対的試験、人によるレビュー。
• Microsoft — Prompt Shields：検知範囲と限界、注釈・遮断モード。
• NIST AI 600-1：AIレッドチームの定義と種類、結果利用時の注意点。
• MITRE ATLAS：シナリオの範囲を点検する攻撃戦術・技術。

セルフチェック

4-1. OpenAI Agents SDKのツールガードレールが適用されないツールの種類を2つ書き、そのようなツールを使うエージェントに代わりに置ける統制を1つ挙げてください。

4-2. 有害コンテンツの分類、インジェクション攻撃の検知、認可検査が答える質問を1行ずつ書いてください。

4-3. レッドチーム開始前に交戦規則で合意する項目を5つ書いてください。

4-4. 評価セットに合成シークレット（カナリア）を入れる目的と、値を選ぶ条件を2つ書いてください。

4-5. 攻撃試行240回中9回が成功し、正常リクエスト500件中15件が止まりました。攻撃通過率と誤遮断率を計算し、この2つだけではわからないことを1つ書いてください。

4-6. 1つのシナリオを独立に60回反復して一度も破られませんでした。この結果から言える成功率のおよその上限と、言えないことを書いてください。

4-7. 設計課題：「入力スクリーニングの追加」と「書き込みツール確認の追加」のどちらが効果的か比較する実験を設計してください。比較構成、固定条件3つ、見る指標2つを示してください。

実習課題