AIレッドチーミング解説：レッドチームが検証するものと、その後に残るもの

ほとんどのAIレッドチーミング案件は、誤った成果物によって評価されている。1週間の作業からスライド資料が生まれ、その資料にはアシスタントがフィッシングメールを書くよう説得され得ると書かれているが、その後、その行動が再現可能だったのか、どれほど深刻だったのか、どの制御ならそれを止められたのかを言える人はいない。この分野には実質的な成果物があり、それはスライド資料ではない。再実行に耐える一連の調査結果であり、各結果は越えられた境界と、それを越えた証拠に結びついている。それはまた、記録の形でもある——AIインシデントアーカイブが保持する、2024年12月から2026年10月までを対象とする400件のエントリで、743の異なる情報源から集められ、各エントリには実際に誰かが害を被ったかどうかについての判定が付されている。

混乱は無理もない。なぜなら「レッドチーミング」という言葉は、用語を共有する以外にほとんど共通点のない二つの業務に対して使われているからだ。本稿はその両方について、それぞれが生み出すべき証拠について、そしてAIレッドチーミングが、ほとんどのセキュリティチームがすでに実施方法を心得ているネットワーク版から真に逸脱する4つのポイントについてのガイドである。

フレームワークの問い：テストの責任者は誰か

範囲を定める前に、誰が何に対して演習を実施しているのかという問題がある。Microsoft はこの点について、より完全な公開見解の一つを示しており、製品ページとしてではなく地図として読む価値がある。同社の AI Red Team ハブは、AI レッドチーミングの概念をハウツーから分離し、その後、それ自体が一つの主張となる順序で実践内容を整理している。概要、LLM レッドチームを構築するためのガイド、そして参照資料——機械学習システムへの攻撃をトリアージするためのバグ バー、機械学習の失敗に関する分類体系、責任共有モデル、開発者向けの脅威モデリング ガイダンス——である。

順序を読めば、方法論は自ずと導き出される。分類体系が何を失敗と見なすかを決める。バグバーが、その失敗のうちどれを修正する価値があるかを決める。責任分担モデルが、見つかった後に誰が責任を負うかを決める。脅威モデリングは次にどこを見るべきかを決める。これら四つがなければ、レッドチームは重大度の列を無理やり付けただけの逸話を量産しているにすぎず、その重大度の列はテスターがその日の午後に感じたことにすぎない。

Microsoftのオープンな自動化フレームワークであるPyRITは同じ棚に分類されており、その配置こそが有用な点です。オーケストレーションキットは方法論ではありません。それは、分類体系とバグ基準が存在して初めて、対象に向けるものです。フレームワークから始めるチームは、大量のプロンプトのコーパスと、その結果をランク付けする手段がない状態で終わりがちです。

2つのレッドチーム、2つの異なる問い

この分野で最も有用な区別は、ほとんど誰も書き留めていないものだ：モデルをテストするレッドチームと、システムをテストするレッドチームは、異なる問いに答えており、テスト対象の単位も、出力も、責任者も異なる。両者を混同すると、ジェイルブレイクがセキュリティ上の発見として報告され、真の権限昇格バグがモデル品質に関する苦情として起票されることになる。

モデルレベルの安全性評価は測定上の問題です。あるモデルが特定カテゴリのコンテンツを生成するかどうかを問うており、それに正直に答える方法は、発生率について何か言えるだけの十分な大きさのサンプルです。テスト対象となる単位は、薄いAPIの背後にあるモデルであり、手法は敵対的プロンプティング—ジェイルブレイク、ペルソナ攻撃、複数ターンにわたる圧力—であり、出力されるのはトランスクリプトと有害性判定です。重みが変化したり、ベンダーの安全層が変化したりすると、結果全体が古くなります。だからこそ、この種のテストは通常、モデル構築者または独立した評価者によって実施され、その知見があなたのアプリケーションにおける特定の修正に結びつくことはめったにないのです。

システムレベルの敵対者エミュレーションはエンジニアリング上の問題です。問うているのは、攻撃者がデプロイされたものを動作させられるかどうか——本来読むべきでないファイルを読ませ、本来呼ぶべきでないツールを呼ばせ、本来使うべきでない金を使わせられるかどうかです。テスト対象は、ツール、検索、資格情報が接続された状態のエージェントです。手法は見慣れたものを対象を変えて用いるものです。ユーザーの発話ではなく取得コンテンツ経由の注入、ツールの悪用、個々には妥当に見える権限から組み上げられた特権チェーン、テナント境界を越えて漏れるデータ経路などです。成果物は、再現手順、越えられた境界、そして明日にでも設定を変更できるオーナーを伴う所見です。

二つは互換性のない成果物を生み出し、その非互換性は厄介というより診断的だ。モデルレベルの結果は、モデルを切り替える以外にチームでは「修正」できない。システムレベルの結果は、ベンダー側でもまったく修正できない。報告書が二つのどちらなのかを示していなければ、その項目はどれもどちらかに割り当てることはできない。

モデルがツールを手にすると、攻撃対象領域はどうなるのか

多くのチームが依然としてテストしている攻撃面はプロンプトだ。これは最も興味深い対象でもない。モデルベンダーが最も力を注いで堅牢化してきた面であり、攻撃者が最も働きかけにくい面でもあるからだ。実際に効果を生む攻撃面は、アプリケーションが追加したものだ。エージェントが呼び出せるツール、エージェントが読み取る検索インデックス、ターン間で保持するメモリ、そして出力チャネルそのものである。

ツールは、言語モデルが行為者になるところであり、興味深い問いは決して「ツールを呼び出せるか」ではなく、「このツールが持ち得た最小権限は何か」です。自由文クエリを受け付けるチケット検索ツールは、たいていの場合、説得されて別の顧客の識別子を受け入れてしまいます。 検索・取得はモデルのコンテキストへのコンテンツチャネルです。つまり、コーパスに書き込める人なら誰でも — 共有ドライブ、サポートマクロ、フェッチャーが到達する Web ページ — プロンプトに書き込んでいることになります。 メモリは単一のターンを永続性に変えます。2 ターン目に仕込まれた指示は、40 ターン目にも依然として残っています。 出力は、モデルのテキストがそれを解釈する何らかの場所に着地する箇所であり、レンダリング、Markdown、リンクプレビュー、シェルに隣接するパイプラインはいずれもテキストを解釈します。

プロンプトだけをテストする取り組みでは、問題のない結果が報告され、間違った対象について正しいことになる。

文字起こしが所見にならない理由

発見には、チャットウィンドウのスクリーンショットにはない3つの特性が必要だ。1つ目は再現性である：クリーンな状態からもう一度実行すれば、また起こる。モデルは非決定的なので、再現性はブール値ではなく割合である——「10回中9回」は発見であり、「一度起こった」は噂にすぎない。2つ目は境界を越えたことである：モデルではなくアプリケーション自身の言葉で、起こるべきではなかった事象を名指しすること。すなわち「モデルが無礼だった」ではなく、「エージェントがテナントBに属する文書を読んだ」である。3つ目は影響にまでたどれる重大度であり、テスターの直感によるものではなく——バグバーはまさにそのためにある。

その他すべて——トランスクリプト、プロンプト、モデルの推論——は、それら3つを裏付ける証拠である。それは発見そのものではなく、だからこそ、2000件のジェイルブレイク・プロンプトからなるコーパスは、名前付きの対照が付随した再現可能な5つのシステム所見よりも価値が低いのである。

AIレッドチーミングがネットワークレッドチーミングと異なる4つの点

ネットワークまたはアプリケーションセキュリティから参入するチームは、優れた直感と4つの誤った前提を持ち込む。

• 保持すべき境界は存在しない。ネットワークエンゲージメントにはターゲットリストがあるが、エージェントエンゲージメントには、リクエスト時に、まだ棚卸ししていない可能性のあるソースから組み立てられるコンテキストウィンドウがある。スコープは次のものとして表現する必要がある：データソースとツールの権限であり、ホスト名ではない。

• 対象は非決定的です。同じ入力が火曜日には成功し、水曜日には失敗することがあります。これは「一度のきれいな再現」という証拠基準を崩し、発生率を報告せざるを得なくなります。

• 攻撃手法は言語であり、言語にパッチは存在しない。 欠落した認可チェックなら修正できる。しかし「モデルは説得されうる」という性質にパッチを当てることはできない。言語レベルの弱点に対する緩和策は、どこか別の場所に置かれる制御——フィルター、スコープ制限、権限境界——であり、だからこそ指摘事項は行動だけでなく、その制御を名指しする必要がある。

• ベンダーはループの中にいます。 他の誰かがバージョンをリリースすると、あなたのターゲットは変わります。モデルレベルの結果は、テストしたビルドに対してのみ有効であり、バージョンと日付を記録していなければ、結果は得られていないことになります。

最初のエンゲージメントの範囲を定める方法

うまくいかないエンゲージメントは、ほぼ必ず「AIをテストする」というスコープになる。スケジュールと接触しても生き残るスコープは、むしろ次のような形だ。エージェント1つ、ステージング環境で、本番同様の形のデータと本番同様の形の権限。重要な5つの境界のリスト（テナント分離、認証情報へのアクセス、支出、データエグレス、ツールスコープ）。範囲外を明示するエンゲージメントルール。誰が実行を停止できるかを示す停止条件。そして、定義された証拠フォーマットを、最初の試行前に合意しておく。そうすればレポートは記憶から再構成するのではなく、成果物から組み立てられる。

認可には独立した一文を割くべきです。なぜなら、対象が自社製品でツールが他社製である場合、チームが飛ばしてしまう唯一の項目がそれだからです。自ら運用していないモデルを、所有していないインフラ上で、安全層を突破するために設計されたプロンプトを用いてテストすることは、自社のデプロイをテストすることとは別の活動であり、両者を分けるのは書面化されたスコープです。当社自身のサイバー層が運用する検証ゲートが存在するのも同じ理由です。モデルレベルでの認可されたセキュリティ作業には、双方に、名前が明示され説明責任を負う当事者が必要です。

インシデント記録が何を付け加えるか

レッドチーム演習は、対象が何をするかを教えてくれる。だが現場で何が起きるかは教えてくれない。そして、管理策を正当化する議論が実際に交わされるのは現場だ。その隙間を埋めるのがインシデント台帳であり、それが課す規律こそが有用な部分である。少なくとも1つの情報源を持たない記録は存在せず、被害判定を持たない記録はインシデントではない。

二つの成果物を併せて読むと、ループが閉じる。レッドチームは再現可能な発見を生み出し、それを防げたはずの制御を特定する。記録は、現場でその境界にすでに到達した人がいるか、被害は何だったか、その制御が他のどこかで機能したかを教えてくれる。現場での前例がない発見は、修正する価値のある仮説である。再現可能な発見がない現場インシデントは、まだクローズできないバグである。これを正しく実践するチームは、「モデルに対してレッドチーミングを実施した」ことを成果物として扱うのをやめ、自らの台帳への一つの入力として扱い始める。

そこから残るのは、正直な結びの注記だ。AIレッドチーミングはセキュリティ保証を生み出すものではなく、それを保証として売り込む案件は間違ったものを売っている。それが生み出すのは、今では越えられていると分かっている一連の境界であり、再実行できる証拠を伴い、越えられたときに何が起きるかで順序付けられている。それだけで意思決定するには十分であり、プレゼン資料よりはるかに多くのものだ。