AIレッドチームに欠けているものと、その改善方法

F5 ADSP | 2025年6月12日

Jessica BrennanAIセキュリティ担当シニアプロダクトマーケティングマネージャー | F5

レッドチーミングは長年にわたり、エンタープライズセキュリティの要となってきました。しかし、生成AIに関しては、多くの組織が新たな脅威環境に旧来の手法を適用しています。静的なプロンプトテスト、単発の監査、CLIベースのツールによって明らかな不具合が表面化することはありますが、導入後のGenAIシステムの挙動が持つ現実世界の複雑さを捉えられることはほとんどありません。

本記事では、多くのAIレッドチーミング戦略に共通する主な盲点と、セキュリティリーダーが戦略を進化させるために導入できるベストプラクティスについて解説します。

動的なAIの世界で静的テストが不十分な理由

従来のAIレッドチーミングツールは、多くの場合、プロンプトインジェクションの成功率、つまりモデルが応答したか拒否したかに注目します。しかし、この二者択一の結果だけでは、全体像を捉えられません。さまざまなパターンに対しても一貫して拒否できたでしょうか。モデルは別の方向へ誘導したり、気づきにくい形で誤解を招いたりしなかったでしょうか。間接的な複数ターンの探索に対して脆弱ではなかったでしょうか。

多くのレッドチームは表面的な指標の確認にとどまり、時間の経過とともに顕在化する微妙な不具合を捉えられていません。企業がオープンソースモデルや実験的なモデルをテストする機会が増える一方で、その内部の安全性メカニズムを十分に把握できないケースも少なくありません。そのため、セキュリティ責任者は、導入前の検証において、より踏み込んだ原則に基づくアプローチを求めています。

エージェント型レッドチーミングの台頭

特に有望な進展の1つは、AIセキュリティにおいて静的プロンプトからエージェント型レッドチーミングへ移行していることです。これは、自律型の敵対的エージェントがモデルの挙動を継続的に調査し、それに適応する手法です。

固定された一連のプロンプトを実行するのではなく、これらのエージェントには意図に基づく目標（機密データの抽出、モデレーションの回避、社内の役割のなりすましなど）が与えられ、反復的な試行が許可されます。エージェントはモデルの応答から学習し、現実の攻撃者と同様に、目標の達成に向けて、より高度で間接的な手法を試みます。

このアプローチは、従来のツールでは見逃されていた脆弱性を明らかにするだけでなく、新たに顕在化するリスク環境も反映しています。そこでは、モデルが複雑なシステムや他のエージェントと相互作用し、脅威は単独で発生するのではなく、時間の経過とともに展開します。

コンテキストに即したAIテスト：MCPが状況を一変させる理由

動的なエージェント型システムへの移行は、現在、技術プロトコルとして標準化されつつあります。その代表例が「Model Context Protocol」（MCP）です。MCPは、ツール、エージェント、モデル間のやり取りを通じて、コンテキストをどのように受け渡し、保持するかを規定します。このコンテキストには、システム指示、タスク履歴、AIコンポーネント間の共有メモリなどが含まれる場合があります。

セキュリティの観点から見ると、MCPはレッドチーミングに新たな課題をもたらします。個々のモデルの応答だけでなく、変化する指示、依存関係、目標のもとで、一連の流れの中でモデルがどのように動作するかを評価する必要があります。

クリーンな環境での単発テストではセキュアに見えるモデルでも、侵害されたコンテキストを引き継いだり、上流のエージェントに操作されたりすると、適切に機能しない可能性があります。コンテキストの流れを考慮しないレッドチームは、実環境に存在する脆弱性の種類を丸ごと見落とす可能性が高くなります。

コンテキストを考慮したテストが二者択一の結果より優れている理由

これらすべてから、より広範な事実が明らかになります。単一のプロンプトに対する合格／不合格のような二者択一の結果だけでは、もはや十分ではありません。意義のあるセキュリティ上の判断を下すには、システムがどのように機能しなくなるのか、なぜ機能しなくなるのか、そしてどのような条件下で機能しなくなるのかをチームが理解する必要があります。

コンテキストを考慮したテストにより、GenAIシステムに潜在する弱点を露呈させる可能性のあるパターン、依存関係、微妙な挙動が明らかになります。これには、状態の変化、プロンプトの再入力、敵対的なチェイニングに対するモデルの応答などが含まれますが、静的なレッドチーミングで捉えられるのは、そのうちの1つにすぎません。

実行時にAIを活用する場合、モデルレベルの検証に加えて、アプリケーションを深く理解したレッドチーミングが不可欠です。特に、推論時に内部データが取り込まれるRAGパイプラインやエージェント型ワークフローでは、リスクへの露出度を左右するのは、基盤となるモデルだけでなく、アプリケーションの挙動です。

こうした詳細なインサイトを得るには、レポートにもより多くの情報が求められます。脆弱性を指摘するだけでは不十分です。何がその脆弱性を引き起こしたのか、なぜ重要なのか、どのように修正すべきかを示す必要があります。そのためには、プロンプトとレスポンスの一連のやり取りをすべて記録し、問題を意図やシステム動作のカテゴリーに分類するとともに、修正の優先順位を明確に提示する必要があります。