OWASP GenAIレッドチーミングマニュアル、モデルを超えたテストへ対象を拡大
OWASPは10月20日、モデルの応答だけでなく、接続されたアプリケーションやエージェントにも対象を広げる8段階のテストプロセスを示したGenAIレッドチーミングマニュアルを公開した。バージョン1.0のリリースは、生成コンテンツとデータアクセス、アクションを組み合わせるシステムにおけるセキュリティ、安全性、障害耐性を扱う。その中心的な意味合いは明快だ。モデル単体を評価しても、その周囲に構築された製品については未解決の問いが残る。
OWASP GenAIレッドチーミングマニュアルは、モデルの安全性評価結果をデプロイメント全体の証拠として扱う、よくある保証上の近道に疑問を投げかける。レッドチーミングとは、障害を発見するために攻撃者の視点を採る、認可されたテストを指す。接続されたAI製品では、重大な障害は不適切な回答ではなく、認可されていないアクションに関わる可能性がある。
OWASPはすでに2025年1月に関連ガイドを公開しており、今回のリリースはAIレッドチーミングを一から導入するものではない。10月のマニュアルは、より詳細な運用上の参照資料を提供する。開発者や企業の購買担当者にとっての重要性は、発見された弱点を、再現可能な証拠、事業上の影響、検証済みの修正と結び付ける点にある。ただし、そこには厳しいトレードオフがある。より広範なテストは有用な保証をもたらす一方、チャットボットのデモでは得られないアクセス、調整、エンジニアリング時間を必要とする。
OWASP GenAIレッドチーミングマニュアルが加えるもの
このリリースは、個別の敵対的プロンプトを寄せ集めるのではなく、チーム間で共有できる実施構造を提供する。
OWASPは、計画、偵察、攻撃対象領域のマッピング、悪用、永続化、影響評価、報告、修正にまたがるプロセスを説明している。対象範囲には、モデル、アプリケーション、エージェントに加え、テキスト、画像、音声などの形式を受け付けたり出力したりするマルチモーダルインターフェースも含まれる。リソースページは、倫理的なテスト、測定可能な成果、防御運用との統合も強調している。
この広がりが重要なのは、AIの障害に都合のよい組織上のラベルが付いていることはまれだからだ。有害な応答は、モデルの挙動、アプリケーションの指示、取得した資料、接続先サービスのいずれからも生じ得る。これらのコンポーネントは異なるチームが管理する。共有プロセスがあれば、各チームは責任範囲が自らのコンポーネント境界で終わると決めつけず、同じ事象を調査できる。
歴史的な区別も重要である。OWASPの以前のレッドチーミングガイドは、統合上の弱点や継続的な監視と併せてモデルの脆弱性を評価することを、すでに提唱していた。したがって10月の公開は、このアプローチを継続的に発展させたものだ。アプリケーションリスクをOWASPが初めて認識したものと表現すれば、記録を誤って伝えることになる。
今回のリリースは、「テスト済み」という言葉に読者が何を期待すべきかも変える。組織は、文書コネクターを手付かずのままモデルをテストしたと正当に言える。別の組織は、アクションを実行するサービスを対象外にしてアプリケーションインターフェースをテストすることもできる。両者が同じセキュリティ見出しの下に置かれていても、これらの主張が示すカバレッジは異なる。
共通の実施構造は、こうした違いを可視化する助けとなる。購入者に対し、テスト対象、テスターに与えられたアクセス、対象外に残ったものを確認するよう促す。分析上の価値は、より高い具体性から生まれる。よく知られたフレームワーク名は、これらの回答の代わりにはならない。
たとえば、プロジェクトファイルを読み、顧客向けコミュニケーションを下書きする企業向けアシスタントを考えてみよう。文章の品質を評価しても、ファイル権限を尊重するかどうかについてはほとんど分からない。ファイルアクセスを評価しても、その後のコミュニケーションで認可されていない受信者に情報を公開するかどうかについては、ほとんど分からない。この製品はそれらの挙動を組み合わせるため、評価では両者の関係を説明する必要がある。
このマニュアルの公開は、組織がすでにこのアプローチに従っていることを示すものではない。組織の主張を検証するための参照点を提供するものだ。導入状況、実装の品質、セキュリティ上の成果は、依然として別の問いである。
この区別によって、今回のリリースを適切な視点で捉えられる。OWASPは、より規律あるテストを支援するガイダンスを公開した。それがデプロイ済み製品を改善するかどうかは、チームがそのガイダンスをアクセス、リリース準備、修正に関する判断へどう落とし込むかにかかっている。
企業の購入者が引き継ぐ統合リスク
AIモデルを業務システムに接続する組織は、その接続に伴う権限と結果について引き続き責任を負う。
モデル提供者とアプリケーション開発者は、それぞれ異なるセキュリティ上の問いに答える。提供者は、利用可能なテスト環境内での挙動を評価する。開発者は、どの文書、アイデンティティ、サービス、アクションをモデルの周囲に配置するかを選ぶ。企業導入では、設定、アカウント権限、組織固有のデータを通じて、さらに別の層が加わる。
これは実務的な調達上の問題を生む。購入者は広範なモデル文書を受け取っても、従業員が実際に使う正確なワークフローについてはほとんど分からない可能性がある。生成された応答の好ましい評価は、アシスタントが顧客アカウントを適切に分離するか、コネクターの権限を制限するかを示すものではない。これらの特性は、デプロイされたアプリケーションに依存する。
OWASPの別途用意されたアプリケーションセキュリティテストに関するガイダンスは、この区別を強化している。同ガイダンスは、モデル、検索、ツール、権限を一体化したテスト対象として扱う。また、エージェントが接続されたツールを使用できる場合、入力に埋め込まれた悪意ある指示であるプロンプトインジェクションを、認可上の問題となり得るものとして位置付けている。
したがって、複数のグループに負荷がかかる。製品チームは、テストできるほど正確に許容される挙動を記述する必要がある。セキュリティチームは、デプロイ済みの設定にアクセスする必要がある。調達チームは、除外事項を説明したレポートを求める必要がある。事業責任者は、残るどのリスクが機能の保留または制限を正当化するかを判断する必要がある。
顧客サポートアシスタントの例は、この役割分担を明確にする。モデルは直接の会話で個人情報の要求を適切に拒否できるかもしれない。それでも周辺のアプリケーションは、誤った顧客の記録を取得する可能性がある。モデルの拒否挙動とアプリケーションによるアカウント分離には、異なる証拠が必要だ。
同じ問題は、社内ナレッジシステムでも生じる。アシスタントは文書を正確に要約しても、元の文書にアクセスできない人物がその要約を利用できる状態にしてしまう可能性がある。正確性は有用性を高めるが、認可の問題を解決するものではない。洗練された応答は、根底にあるアクセス上の誤りを隠し得る。
検索可能なナレッジベースを構築するチームにとって、重要な問いは適切な情報を見つけることだけにとどまらない。個人がその情報を取得し再利用できる条件を維持することも含まれる。AIを追加すると、こうした境界が機能するインターフェースが変化する。
この分析は、すべての導入に同一のテスト深度が必要であることを意味しない。公開情報に限定されたツールがもたらす影響は、業務記録を変更する権限を持つエージェントとは異なる。判断は、アプリケーションの実際の権限と露出に従うべきだ。
商業的な意味合いは、セキュリティ向上を求める一般論よりも具体的である。ベンダーには統合境界を文書化する圧力がかかる。購入者には、より広いアクセスを許可する前にその文書を要求する圧力がかかる。どちらの側も、モデルベンチマークだけでこの問いを解決することはできない。
接続されたエージェントが応答を結果へ変える
エージェントのセキュリティは、生成された判断に対して周辺ソフトウェアが何を許可するかに依存する。
AIエージェントとは、モデル出力を用いて接続されたツール経由のアクションを選択・実行するソフトウェアである。ここで重大な転換が生じる。それまで提案にとどまっていたテキストが、情報送信、記録変更、別サービスの呼び出しを求めるリクエストになり得る。
144ページのマニュアルは、モデルへのプローブを、検索、アイデンティティ、認可、ツールと結び付けている。その内容は、攻撃者の影響が即時のやり取りを超えて残る永続化も扱う。これらの論点は、個々の出力から、接続されたシステムが時間の経過とともに示す挙動へと評価対象を広げる。
次の例は、報告されたインシデントではなく、説明のためのものだ。外部から提供された文書をレビューするリサーチアシスタントを想定してみよう。その文書には、無関係な社内資料を開示するようアシスタントに求める指示が含まれている。文書を読むこと自体は正当である。しかし、その指示を別の情報へアクセスし送信する権限として扱えば、別の境界を越えることになる。
この違いは、応答のスクリーニングだけでは不完全な像しか得られない理由を説明する。アシスタントがその前に認可されていないアクションを試みていたとしても、最終回答は無害に見えるかもしれない。反対に、生成されたリクエストは危険に見えても、接続先サービスが正しく遮断している可能性がある。アクションとその結果を観察することで、評価は変わる。
ここでは、試みられた挙動と完了した被害を区別することが有用になる。評価者は、疑わしい表現すべてを侵害の成功として扱うべきではない。同様に、最終応答が問題なく見えるからといって、接続先サービスが不適切なリクエストを実行した証拠を見過ごすべきではない。結果を決めるのは、製品の実際の挙動である。
永続化は別の複雑さを加える。先の例のアシスタントが、攻撃者の影響を受けた設定を保存し、後のタスクで利用する状況を考えてみよう。解決済みに見える会話でも、将来の挙動を変える状態を残す可能性がある。元のやり取りだけを評価していれば、その継続的な影響を見逃すことになる。
より広いシステムは、防御が成功したことの意味も変える。モデルが悪意ある指示に従っても、権限チェックがアクセスを遮断すれば、アプリケーションはその試みられたアクションを封じ込めている。その結果はなお調査に値するが、実際の情報開示とは異なる。レポートでは、この違いを保持すべきである。
製品が有用な能力を得るほど、トレードオフは鮮明になる。読み取り専用アクセスは、より限定的なタスクを支える。記録を変更する権限は、より広範な自動化を可能にする一方、誤った指示がもたらす結果も大きくする。テストは、製品の価値を生む能力を反映する必要がある。
これは、エージェントが本質的に業務利用に不向きだと示すものではない。権限には独自の証拠が必要である理由を示すものだ。比較すべきなのは、エージェントが試みられること、周辺サービスが許可すること、そしてユーザーが意図したことである。
OWASP GenAIレッドチーミングマニュアルは、この統合的な視点を明確にしている。その実務上の重要性は、すでにモデル応答に向けられているのと同じ精査を、アプリケーションの挙動にも適用する点にある。
共有手法が直面する証拠の問題
構造化された評価は問いの質を高めるが、その結論は依然として、背後にあるテスト、環境、証拠によって制約される。
寄稿者からの支援は、共通の方法論が実務家に支持される理由を説明する一助となる。NeuralTrustの寄稿者アカウントは2026年7月1日付で、パブリックコメント版への参加について説明している。同社は、再現可能なエンゲージメントを、断片的な攻撃手法より優れたものとして提示している。これは参加者の見解であり、インシデント減少を示す独立した証拠ではない。
時系列にも注意が必要だ。NeuralTrustは、OWASPが10月にリソースページを公開する以前から、パブリックコメント版のマニュアルについて議論していた。読者は、初期のドラフト活動と現行の公式リリースに付された日付を区別すべきである。どちらの日付も、特定の組織がこの方法論を採用した時期を示すものではない。
懐疑的に問うべきは実装である。一貫した見出しを用いていても、報告書が脆弱な実験を記録している場合はある。長大な評価でも、最も重大なツールが抜け落ちることがある。テスト環境は見た目には本番環境に似ていても、権限が異なる可能性がある。形式的な構造はこうした制約を記述しやすくするが、自動的に解消するものではない。
測定にも課題がある。テスト結果は、何を成功または失敗とみなすかに左右される。アシスタントが機密情報に言及することは、それを取得する、表示する、あるいは外部へ送信することとは異なる。こうした事象を曖昧な「漏えい」というラベルでまとめると、結果の解釈は難しくなる。
製品間の比較も同じ問題に直面する。広範な権限を持つシステムは、厳しく制限されたアシスタントよりも、重大な失敗経路を多く露出させる可能性がある。成功した攻撃の単純な件数だけでは、製品が同等のタスク、アクセス、条件に置かれていたかは分からない。結果にはスコープを併記すべきである。
自動テストは別の不確実性ももたらす。あるモデルの挙動を判定するために用いられるモデルが、タスクを誤解したり結果を誤分類したりする場合がある。だからといって自動評価が無用になるわけではない。特に結果がリリース判断に影響する場合は、判定プロセス自体を精査する必要があるということだ。
セキュリティと有用性の区別も、ここでは重要である。あらゆる要求を拒否するアシスタントは、悪用に強いように見えても、本来の役割を果たせない可能性がある。有意義な評価では、正当なタスクの実行能力と、強制すべき境界の両方を維持する必要がある。そうでなければ、見かけ上の改善が機能喪失を隠しかねない。
これらは分析上の限界であり、マニュアルの失敗を示す証拠ではない。どの方法論も、限定された演習を将来のあらゆるやり取りに関する証明へと変えることはできない。妥当な結論は、テストした条件、観測された結果、残る不確実性を明らかにする。
したがって、この公開は包括的な保証を促すことなく、証拠への期待を高めるべきである。「OWASPのガイダンスに基づいて評価済み」という表現は、アプローチを説明するものだ。購入者は依然として、評価中に何が起き、どの発見事項に検証済みの修正が適用されたのかを理解する必要がある。
テスト予算はワークフロー全体をカバーしなければならない
より広範なAIテストで難しいのは、ワークフローを制御する人とシステムを調整することだ。
プロンプトに焦点を当てた演習は、多くの場合、対話型インターフェースへのアクセスから始められる。ワークフロー評価には、より多くの文脈が必要となる。テスターは、アプリケーションが意図するタスク、アクセス可能な情報、ツールが生み出し得る影響を理解しなければならない。その理解を得るだけでも、攻撃が始まる前に組織的な労力を要する。
そのコストはセキュリティ上のトレードオフの一部である。より広いスコープは、導入済み製品により適合した結論を支える。より狭いスコープは必要な作業を減らすが、得られる報告書が立証できる範囲も制限する。どちらの選択も、テストが完了したという一般的な説明の陰に隠されるべきではない。
この違いは是正にも影響する。弱点が過度に広いサービスアカウントに起因する場合、モデルの指示を変更しても根底にある権限は残るかもしれない。問題が、本来は正当なアクセスを意図しない目的で使うことにあるなら、すべてのアクセスを削除すると製品の役割を損なう可能性がある。エンジニアリングには、有用な修正を支えられるほど具体的な診断が必要だ。
所有権が中心的な障害となることもある。モデルチームは設定を管理し、アプリケーションチームはオーケストレーションを管理し、アイデンティティチームは権限を管理する。影響を受けるワークフローは事業部門が所有する。こうした境界をまたぐ発見事項では、誰が何を変更するかを決める必要がある。
文書アシスタントの例は、その状況を示している。製品は社内ファイルを取得し、外部向けの要約を作成する。テストで、制限付きコンテンツがドラフトに入り込むことが判明する。是正措置には、取得権限、受信者チェック、文書分類、またはワークフローの承認ステップが関わる可能性がある。これらの対策は異なる原因に対応する。
有用な結果であれば、どの境界が破綻したのか、また選択された対策が観測された経路を遮断したのかを説明するだろう。根底の失敗が指示処理に関するものでない限り、アシスタントへの指示をより強い文言にするだけでは、より弱い証拠にとどまる。修復は実証されたメカニズムに従うべきである。
利用可能なツールは、この作業の異なる部分を支援する。OWASPのアプリケーションテストに関するガイダンスでは、モデル脆弱性スキャン用のNVIDIAのgarakと、敵対的インタラクションをオーケストレーションするMicrosoftのPyRITが挙げられている。これらのツールはテスト活動を支援する一方、エンゲージメントの方法論はスコープ、解釈、フォローアップを整理する。役割は重なるが、互換的ではない。
したがって、ツールの比較はブランドの好みではなくカバレッジに焦点を当てるべきである。多様な入力を生成するスキャナーでも、業務レコードが適切に変更されたかを自動的に立証することはできない。明確なタスクとポリシーがなければ、オーケストレーションフレームワークが組織にとって許容可能な権限境界を決めることもできない。
このマニュアルが再現性と防御的な統合を重視していることは、エンジニアリングチームとセキュリティチームが利用できる発見事項という運用上の成果を示唆している。事業価値は、その引き継ぎに左右される。誰も結果を再現できず、修復を検証できないなら、異常な応答を発見しても有用性は低い。
1月までの採用エビデンスに注目する
最も強いシグナルは、組織がマニュアルを使った後に評価スコープを変更し、修正を検証したことを示す公開エビデンスとなる。
最初に注目すべきシグナルは、公開されるケーススタディの質である。2027年1月までに有用な説明は、テスト対象のアプリケーション、接続された機能、評価から除外された境界を記載するだろう。支持表明やダウンロードの発表は関心を示す。文書化されたエンゲージメントは、実際の制約下で方法論がどう機能するかを明らかにする。
こうした説明は、発見された弱点と具体的な是正変更を結び付けるなら、マニュアルの有効性を補強する。一方、アプリケーション上の結果を検証せず、異常なモデル応答だけを報告するなら、より広範な主張を弱めることになる。この区別はリリースで示されたスコープに従うものだ。
次のシグナルは、ベンダーが評価サービスにおけるカバレッジをどう説明するかである。OWASPのレッドチーミング・イニシアチブでは、すでにマニュアルが評価およびベンダー選定のリソースとともに提示されている。これはサービスに何が含まれるかを調べる際の参照点となる。購入者は、対象となるツール、データアクセス、エージェントの挙動について、より明確な説明が示されるかを注視すべきだ。
より具体的な報告は、共通ガイダンスが比較可能性を向上させるという見方を支えるだろう。文書化されたスコープを伴わないOWASP準拠の広範な主張は、より弱い証拠にとどまる。意味のある変化は、ベンダーページの新しいバッジではなく、成果物と契約上の期待に現れるはずだ。
最後のシグナルは、是正後に何が起きるかである。公開されたフォローアップ結果は、組織が元の失敗を再テストし、関連する経路も検証したかを示すだろう。発見段階で終わる説明は、中心的な運用上の疑問を未解決のまま残す。製品は本来の機能を維持しながら、より安全になったのか。
これらは観測基準であり、OWASPや参加ベンダーが発表したコミットメントではない。マニュアルの影響を裏付ける、検証済みの採用数やインシデント削減の測定値はまだ存在しない。このリリースはその影響を調査するための枠組みを提供するが、実装のエビデンスはこれから示される必要がある。
開発者にとって直ちに必要なのは、テスト結果を顧客が実際に利用する設定と結び付けることだ。エンタープライズの購入者にとっては、モデルに関する保証と導入のエビデンスを区別することになる。ユーザーにとっての実務的な懸念は、アシスタントが自分の情報と行動を囲む境界を尊重するかどうかであり続ける。
OWASP GenAIレッドチーミングマニュアルは、組織が実際に導入しているAIシステムの評価エビデンスと併せて読むべきである。製品オーナーには、どのワークフローをテストし、どの権限がスコープ外のままだったかを説明するよう求めよう。報告書が、試行された行動と完了した影響を区別しているか確認する。エンジニアリングが元の失敗に対して修正を検証したかを確認する。こうした問いは、議論をフレームワークのラベルではなく観測可能な挙動に結び付ける。また、自信に満ちた要約が狭い実験に依拠している箇所も明らかにする。アシスタントにより広いアクセスを与える前に、追加される権限をカバーするエビデンスを求めるべきだ。最新の評価は、従業員が利用する製品を記述しているのか、それともその基盤となるモデルだけを記述しているのか。
