OpenAI GPT-Redの自動レッドチーミングでプロンプトインジェクションの失敗率が低下、ただしベンチマークは社内評価
OpenAIによると、GPT-Redは、それ以前に対峙したほぼすべてのモデルへの攻撃に成功していたにもかかわらず、ある直接プロンプトインジェクションの失敗率を4カ月で6分の1に低減した。同社は2026年7月15日に詳細を公開し、自律性を増すAIエージェントを守る中核的な防御策として、自動化された敵対的トレーニングを位置づけた。
重要な変化は、また一つベンチマークで首位に立ったことではない。OpenAI GPT-Redの自動レッドチーミングでは、AI攻撃者を本番モデルのトレーニングサイクルに直接組み込む。攻撃側はモデルを侵害する指示を探し、防御側モデルは正当なタスクを放棄することなく、その攻撃に抵抗する方法を学ぶ。
これは単なるモデル同士の競争よりも熾烈な対決を生む。OpenAIは、敵対的な自己改善によって、能力の向上に合わせてエージェントのセキュリティも維持できると見込んでいる。一方で、管理された環境内で訓練された攻撃者は、未知のアプリケーション、ユーザー、ツール、導入時の選択によって生じる脅威を見逃す可能性がある。
同社はGPT-Redを一般公開しておらず、最も優れた成果も社内評価に大きく依存している。プロンプトインジェクションはシステムレベルのセキュリティ問題であるため、こうした制約は重要だ。モデルトレーニングは失敗を減らせるものの、モデルを取り巻くすべての権限、コネクター、アプリケーションを制御できるわけではない。
OpenAI GPT-Redの自動レッドチーミングをモデルトレーニングに組み込む
OpenAIは、自動レッドチーミングをリリース前のテストから、本番トレーニングデータを継続的に生み出す仕組みへと転換した。
レッドチーミングとは、現実の攻撃者に悪用される前に不具合を発見するため、意図的にシステムを攻撃することを指す。通常は人間の専門家が攻撃シナリオを設計し、システムの挙動を観察して、修正すべき弱点を報告する。
GPT-Redは、これに近い探索を自動で実行する。攻撃を仕掛け、防御側の応答を観察し、その結果に基づいて手法を変化させる。成功した攻撃は、その後のモデルの評価やトレーニングに使われる材料となる。
GPT-Redの研究によると、OpenAIはセルフプレイ強化学習を通じて攻撃側を訓練した。セルフプレイでは競合するシステムを同時に訓練し、一方には失敗を引き起こすことで、もう一方にはその攻撃に抵抗することで報酬を与える。
OpenAIは、GPT-Redにエージェント環境の現実的な構成要素を操作させた。これには、メール本文、ローカルファイル、ウェブページのバナー、ツールの出力などが含まれる。各環境には、攻撃側の目的と、成功と認定されるための条件も定義された。
この点が、このプロジェクトを一般的なジェイルブレイクテストと分けている。ジェイルブレイクは通常、悪意あるユーザーがモデルにポリシー違反を求めるところから始まる。これに対し、間接プロンプトインジェクションでは、ユーザー自身が書いていない情報の中に悪意ある指示を隠せる。
エージェントは、メールの要約、コードの調査、ウェブサイトのリサーチ中に、こうした指示に遭遇する可能性がある。注入されたテキストは、元のタスクを無視し、情報を漏えいさせたり、接続されたツールを不正使用したりするようエージェントに命じることができる。
OpenAIによると、GPT-RedはGPT-5.5までにテストされた社内モデルと本番モデルのほぼすべてを突破した。その後、同社はGPT-5.6 Solモデルを含むGPT-5.6のトレーニングに、GPT-Redが生成した攻撃を使用した。
OpenAIのテスト環境内では、得られた改善は大幅なものに見える。報告によれば、GPT-5.6 Solは同社で最も難しい直接プロンプトインジェクションのベンチマークにおいて、4カ月前の最良の本番モデルと比べて失敗数を6分の1に減らした。
OpenAIはまた、より広範な耐性評価環境において、GPT-5.6 SolがGPT-Redによる直接攻撃に失敗した割合は0.05％だったと報告している。この数値が示すのは、同社が訓練した攻撃者に対する性能であり、あらゆるプロンプトインジェクションへの普遍的な防御を意味するものではない。
初期のGPT-Redは、Fake Chain-of-Thoughtと呼ばれる手法を発見した。この攻撃は偽造した推論を提示し、禁止された行為が正当であるとモデルに信じ込ませようとする。
OpenAIによれば、GPT-5.1に対するこれらの攻撃の成功率は95％を超えていた。これがGPT-5.6 Solでは10％未満に低下したという。
これらの数値から、この発表の重要性が分かる。OpenAIはもはや、攻撃の発見をトレーニング後に実施する単発の評価として扱っていない。敵対的探索を利用し、導入前のモデルそのものを形作っている。
これにより、セキュリティテストは独自のスケーリング経路を持つトレーニング入力となる。防御側が強くなれば、GPT-Redはより難しい攻撃を探すことを強いられ、その攻撃が次の防御側にとっての教材となる。
セルフプレイにより、防御側とともに進化する攻撃者を生み出す
中核となる仕組みは、昨日成功した防御が今日の最低難易度になる、絶えず変化する競争だ。
従来の安全性データセットには、既知の攻撃と期待される応答が収録されている。モデルが繰り返し現れるパターンを認識するのに役立つ一方、防御が改善するにつれて価値が低下する可能性がある。静的なデータセットは、次の弱点を能動的に探せない。
GPT-Redは、有効な失敗を引き起こした際に報酬を受け取ることで、このプロセスを変える。防御側モデルには、悪意ある指示に抵抗しながら元のタスクを維持することで報酬が与えられる。そのため、双方に改善を迫る圧力がかかる。
技術論文の全文では、単一の固定された相手ではなく、多様な防御側モデルの集団が説明されている。この選択により、攻撃側が一つのモデルで見つかった弱点だけに依存することを防いでいる。
環境もまた、異なる攻撃対象領域を表している。メールに隠された指示には、コードリポジトリ内の悪意あるコンテンツとは異なる侵入経路が必要になる。どちらの場合も、ツールへのアクセスがあれば、単なる誤ったテキスト出力にとどまらず、外部でのアクションにつながり得る。
この多様性は、コンピューティング資源への投資規模を理解する手掛かりにもなる。OpenAIによれば、GPT-Redには同社最大級のポストトレーニングの一部に匹敵するリソースが使われた。同社はこれを、安全性向上だけを目的とした、社内では前例のない規模のコンピューティング資源投入だとしている。
コンピューティング資源だけで包括的な網羅性が得られるわけではない。それによって増えるのは、モデルが試行できる攻撃の数と、競争を継続できる期間だ。攻撃者がどの脅威を発見できるかは、依然として環境設計によって決まる。
GPT-Redの最も顕著な比較結果は、再現された間接プロンプトインジェクションの競技環境で得られた。OpenAIによると、GPT-5.1に対するシナリオの84％で攻撃に成功した。人間のレッドチーム担当者の成功率は13％だったという。
この比較は、探索能力を増幅する手段としての自動化を裏づける。一つのモデルが、すべてのプロンプトを人間が記述しなくても、多数の攻撃パターンをテストできる。また、失敗した試行を保持し、体系的に改善することも可能だ。
ただし、この比較は、人間によるセキュリティ作業が不要になったことを意味しない。人間は脅威モデルに疑問を投げかけ、非現実的な前提に気づき、自動化された報酬では捉えられない被害を特定できる。また、モデルの環境外にある社会的・組織的な弱点も調査できる。
OpenAIはGPT-Redを、人間および第三者によるテストを補完するものとして明確に位置づけている。同社は多層的な安全策とリアルタイム監視も維持している。この説明は、トレーニングですべての本番環境を再現できるわけではないことを認識したものだ。
この違いは、OpenAIの自動販売機実験でより明確になる。GPT-Redはまず、本番エージェントを模したシミュレーションで攻撃を探索した。その後、選定した攻撃を実稼働システムへ移行した。
OpenAIによれば、この攻撃によって商品の価格が変更され、不利な注文が手配され、別の顧客の注文がキャンセルされた。同社はシステムの開発元に脆弱性を開示し、開発元は追加の安全策のテストを開始した。
この実験は、AnthropicがAI運営のオフィス内店舗を用いて行ったProject Vendに似ている。どちらのプロジェクトも、エージェントの信頼性が一般的なチャットボットの安全性とは異なる理由を示している。
チャットボットの失敗は、望ましくない回答を生成するだけで済むことがある。エージェントの失敗は、記録の変更、コードの実行、メッセージの送信、取引の承認につながり得る。どのような結果が起こり得るかは、周辺のソフトウェアによって決まる。
OpenAIは、GPT-5.4 miniを基盤とするCodexコマンドラインエージェントに対してもGPT-Redをテストした。この評価には、攻撃側のトレーニング環境から除外された10件のデータ流出シナリオが含まれていた。
同社によると、GPT-Redはプロンプトで攻撃役を与えたGPT-5.5のベースラインより少ないトークン数で、より多くのシナリオを侵害した。この結果は、強力な汎用モデルに敵対的な役割を与えるだけの場合を超えて、特化型トレーニングが攻撃探索能力を向上させたことを示唆している。
したがって、どの単一の成功率よりも重要なのは、この仕組みそのものだ。OpenAI GPT-Redの自動レッドチーミングは、攻撃を生成し、それをトレーニングデータへ変換し、後続の防御側モデルを評価する再現可能なプロセスを構築する。
エージェント開発者に求められるセキュリティ基準が引き上げられる
GPT-Redは、あらゆるエージェント開発者に対し、プロンプトインジェクションテストをリリース時のチェック項目ではなく、継続的なエンジニアリングとして扱うよう迫る。
当面、最も大きな圧力を受けるのは、AnthropicやGoogleを含むOpenAIの競合企業だ。ツールを利用するエージェントを販売する企業は、ブラウザ、ファイル、メール、コード、サードパーティーサービスに潜む指示をどのようにテストしているか説明する必要がある。
この発表は、顧客の期待水準も引き上げる。ベンダーはもはや、手作業で設計した少数の攻撃プロンプトだけを十分な証拠として提示できない。購入者は、モデル、コネクター、権限が変更されるたびにテストも進化しているかを、これまで以上に問うようになるだろう。
独立した標準も、すでにこうした広い視点を示している。NISTの攻撃分類体系は、生成AIに対するその他の脅威と並んで、直接・間接プロンプトインジェクションを扱っている。
この分類体系では、攻撃と緩和策をリスク管理プロセスの構成要素として捉えている。一度のトレーニング施策で問題が解決するとはしていない。組織には引き続き、導入時の制御、テスト、監視、インシデント対応が必要だ。
同じ原則は、アプリケーションセキュリティの指針にも見られる。過剰なエージェンシーとして知られるOWASPのエージェントリスクは、タスクに必要な範囲を超える機能、権限、自律性を持つシステムを説明している。
このリスクが重要なのは、インジェクションが成功しても、侵害されたエージェントが利用できる機能しか悪用できないためだ。メール送信権限のないアシスタントは、密かにメッセージを転送できない。メールボックスへの広範なアクセス権を持つアシスタントなら、より大きな被害を引き起こし得る。
したがって、開発者にとってGPT-Redは、二つの異なる基準を変える。一つ目はモデル自体の耐性、二つ目はアプリケーションがその耐性をどこまで信頼すべきかという基準だ。
基盤モデルが強くなれば、多くの製品に共通する失敗を減らせる。だが、特定のアプリケーションが無制限のファイルアクセスを許可しているか、外部アクションの前に確認を省略しているかまで判断することはできない。
セキュリティチームは、テキストのみのベンチマークにとどまらず、現実的なワークフロー全体にわたる結果をベンダーに求めるべきだ。有用な評価では、モデル、システム指示、ツールの説明、取得されたコンテンツ、認可ルール、ユーザー確認まで対象に含める必要がある。
エージェントがより機密性の高いコンテキストを扱うようになるほど、その必要性は増す。ブラウザを通じて、管理できないウェブサイトに接触する。ローカルファイルへのアクセスでは、さまざまな出所の文書に触れる。接続されたアプリケーションを介して、メッセージや共有ワークスペースにアクセスする。
悪意ある指示は、こうしたあらゆる経路から侵入する可能性がある。しかも、タスクを開始した本人には見えないままの場合もある。そのため、不審なユーザープロンプトという明白な警告サインすら失われる。
ナレッジワーカーにも、これを重視すべき共通の理由があります。AIシステムは、質問に回答したり行動を起こしたりする前に、分散した文書からコンテキストを組み立てるようになっています。コンテキストの充実は結果の改善につながりますが、情報源を取り込むたびに信頼境界も広がります。
適切に管理されたAIナレッジベースは、情報の出所やアクセスできる人物をユーザーが把握するうえで役立ちます。しかし、出所が明確であっても、埋め込まれた指示の安全性が自動的に保証されるわけではありません。
正しい対応は、有用な情報との接続をやめることではありません。データと権限を分離することです。文書は事実を提供すべきであり、エージェントのタスクを再定義する権限まで与えられるべきではありません。
アプリケーション設計者は、最小権限アクセス、スコープを限定したトークン、実行前プレビュー、確認要件によって、この区別を強化できます。攻撃者が未知の言語的手法を発見した場合でも、これらの制御は有効です。
OpenAIの成果は、開発者により強力な防御手段をもたらします。同時に、対応を怠る言い訳もなくします。自動攻撃によって多様な訓練データを大規模に生成できるのであれば、製品チームは継続的な敵対的テストをリリースプロセスに組み込むべきです。
対応を迫られる動きは、長期にわたって進展していくでしょう。競合各社は、独自の攻撃生成器、共通評価、または第三者によるテストプログラムを必要とします。企業の購入担当者は、実際の統合環境に即した証拠を求める必要があります。
内部ベンチマークだけでは、最も難しい問いが未解決のまま
報告された改善は有意義ですが、OpenAIが選定した環境の外でもプロンプトインジェクションが解決されたことを示すものではありません。
最初の不確実性は、評価の主体に関するものです。OpenAIはGPT-Redを設計し、環境を選定し、防御モデルを訓練し、その結果のスコアを報告しました。論文には技術的な詳細が豊富に記載されていますが、外部の研究者は内部モデルを実行できません。
OpenAIは効果的な攻撃を生成できるようGPT-Redを意図的に訓練したため、GPT-Redは非公開のままです。このモデルを公開すれば、防御目的で開発した能力を敵対者に提供することになりかねません。
この判断には明確なセキュリティ上の根拠があります。一方で、独立した再現検証を制限することにもなります。研究者は手法を検証できますが、同じ攻撃モデルが無関係なシステムに対しても同様の性能を発揮するかを完全にはテストできません。
2つ目の不確実性は、実際の入力が訓練データや評価データと異なる場合に生じる分布シフトに関するものです。攻撃者は、使用する言語、インターフェース、タイミング、手法の組み合わせを自由に選択します。
本番環境のエージェントは、OpenAIのテスト対象とは異なるオーケストレーション層を使用する場合もあります。独自のシステム指示、メモリ、検索、ツール、承認ルールを備えている可能性があり、それぞれの要素が攻撃対象領域を変化させます。
したがって、GPT-Redによる直接攻撃に対する低い失敗率が答えるのは、限定的な問いにすぎません。定義された環境において、ある防御モデルが、開発済みのある攻撃モデルに対してどれほどの頻度で失敗するかを測定したものです。将来現れるあらゆる攻撃者を評価したわけではありません。
未知のシナリオに対する84パーセントという結果は、汎化能力を示すより強い証拠です。これらの環境はGPT-Redの訓練セットとは異なり、人間のレッドチーム担当者も同じシナリオ群をテストしました。
それでも、評価には内部ミラーが使用され、GPT-5.1が対象とされました。GPT-Redが競合モデルや未知の本番システムに対しても同様の優位性を維持できるかは、独立したチームによって検証されていません。
3つ目の不確実性は、能力の維持に関するものです。モデルは、難しいタスクを拒否したり、ツールを避けたり、行動を制限したりすることで、より安全に見える場合があります。OpenAIは、通常のフロンティア能力に低下は見られなかったとしています。
同社は過剰な拒否についてもテストし、正当なタスクの完遂能力は維持されたと報告しています。これは心強い結果ですが、基礎となる評価の詳細が重要です。実際のユーザーは、広範な能力ベンチマークでは見落とされる拒否パターンを発見することが少なくありません。
防御モデルが、敵対的だと認識しやすい状況でのみ慎重になることで成功している可能性もあります。攻撃者は、悪意のある指示を通常のビジネスコンテンツに偽装することで対抗できます。この攻防があるからこそ、多様な外部テストが不可欠です。
4つ目の問題は、指標の解釈です。平均攻撃成功率は、特定領域に集中する脆弱性を覆い隠す可能性があります。全体としてはごく低い成功率であっても、失敗がメール、認証情報へのアクセス、取り消し不能な操作に集中していれば、重大な意味を持ちます。
セキュリティ上の影響は、発生確率と結果の重大性の両方で決まります。カレンダーの予定が1件改ざんされることと、認証情報が1件漏えいすることは同じではありません。組織がベンチマークスコアを運用上のリスクに対応付けるには、シナリオ単位の結果が必要です。
5つ目の問題は、自己改善という枠組みに関するものです。GPT-Redは、現在のシステムが生成した攻撃に将来のモデルが抵抗できるよう支援します。しかし、モデルを使ってモデルを監督すると、共通の盲点が生まれる可能性があります。
攻撃側と防御側は、重複する訓練ソースから似た前提を学習する可能性があります。慣れ親しんだゲームの中では高い能力を発揮しながら、その報酬構造の外にある脅威を見落とすこともあり得ます。
人間のテスターは、異なる経験や目的を持ち込むため、こうした偏りを部分的に相殺できます。第三者の研究者は、開発元の組織的な前提を共有せずにシステムを検証できます。
だからこそ、OpenAIが人間と外部によるレッドチーミングを継続すると表明していることは、計算資源への投資と同じくらい重要です。自動化は規模をもたらし、独立したテストは異なる視点をもたらします。
OpenAI GPT-Redによる自動レッドチーミングは、より強力な訓練ループを示す証拠として捉えるべきです。GPT-5.6 Solを使用するすべての製品に対するセキュリティ保証と見なすべきではありません。
実用上の基準は、依然として多層防御です。モデルは悪意のある指示に抵抗し、アプリケーションは権限を制限し、運用担当者は重大な操作を監視すべきです。各層は、ほかの層が失敗し得ることを前提とします。
GPT-Redがエージェントセキュリティを変えるかを示す3つの兆候
次の試金石は、GPT-Redの内部的な成果が、独立評価、より広範な導入、競合他社の本格的な対応を経ても維持されるかどうかです。
1つ目の兆候は、未知のエージェントシステムにおける外部再現です。研究者は、OpenAIが設計していないアプリケーション内にGPT-5.6 Solを組み込んだ評価を行う必要があります。
これらのテストには、異なるツールフレームワーク、検索システム、ファイル形式、権限構造を含めるべきです。また、直接的なインジェクションと、第三者コンテンツ内に隠された指示を区別する必要があります。
GPT-5.6 Solが大幅な優位性を維持すれば、OpenAIのセルフプレイ手法は内部ベンチマークを超えて信頼性を高めるでしょう。アプリケーションごとに性能が大きく異なるのであれば、システムアーキテクチャが引き続き支配的な要因となります。
外部テストでは、攻撃頻度と結果の重大性の両方を報告すべきです。タスクが無視されることと、データ漏えいや未承認の外部操作を区別する必要があります。集計された精度だけでは、こうした違いを捉えられません。
2つ目の兆候は、Anthropic、Google、その他のモデルプロバイダーが、比較可能な自動レッドチーミングの結果を公開するかどうかです。競争的な対応が見られれば、敵対的訓練が標準的な能力投資になったことを示します。
重要なのは、また新たな単独のパーセンテージが示されることではありません。プロバイダーは、脅威モデル、未知の評価環境、拒否とのトレードオフ、モデル側の防御とアプリケーション制御の関係を開示すべきです。
共通または相互運用可能な評価が実現すれば、さらに強力な兆候となります。ある組織が開発したレッドチーミングモデルが、特別な適応を行わずに別の組織の防御モデルを攻撃できるべきです。
このクロステストによって、攻撃モデルが開発元のモデルに過剰適合しているかどうかを明らかにできます。また、評価の攻撃側と防御側の両方を1つの研究所内に置くことで生じる優位性も軽減できます。
競合他社が異なる手法でOpenAIに並ぶなら、自動化された敵対的訓練は持続的な業界動向と見なせるでしょう。結果が比較不能なままであれば、購入者はセキュリティの進歩と選択的な情報開示を見分けるのに苦労します。
3つ目の兆候は、導入済みのGPT-5.6エージェントにおける失敗パターンです。OpenAIによると、GPT-RedはGPT-5.3以降、歴代の本番モデルすべてに訓練用攻撃を提供してきました。
本番環境でのインシデントによって、こうした改善が実際のワークフローをカバーしているかが明らかになります。関連する証拠には、成功したインジェクション、阻止された攻撃、過剰な拒否、過大なツール権限によって生じた失敗などが含まれます。
OpenAIは監視によって発見した新たな失敗を、GPT-Redの環境へフィードバックすることもできます。これにより、導入環境から得た証拠を攻撃モデルの訓練や将来の防御モデルの更新につなげる、提案された安全性向上の好循環が完成します。
報告された成果が内部リリースの範囲にとどまるなら、このループの説得力は低下します。未知のインシデントが後続モデル全体の測定可能な改善につながれば、説得力は高まります。
開発者は、これらの答えが出るまで行動を待つ必要はありません。エージェントのコンテキストに入る信頼できない情報源と、その後に利用可能となる重大な操作を行うツールをすべて棚卸しできます。
また、通常のコンテンツがエージェントの目的を変更できるかどうかをテストすることも可能です。各重要操作には必要最小限の権限だけを与え、取り消し不能な手順には追加の確認を求めるべきです。
大量のプロジェクト資料を扱うチームは、ナレッジブレンディングを利用して関連コンテキストを整理できます。それでも、取り込まれた文書やメッセージは、実行権限を持つ指示ではなく、信頼できないデータとして扱うべきです。
OpenAI GPT-Redによる自動レッドチーミングは、モデルプロバイダーに対して、より厳しいベンチマークを打ち立てました。AI攻撃モデルが広範に探索し、訓練データを生成し、数カ月以内に後続の防御モデルを改善できることを示しています。
残る問題は、環境が訓練の舞台に似ていなくなったときにも、その防御上の優位性が維持されるかどうかです。開発者や企業の購入担当者は、目を引く単一のスコアだけでなく、ワークフロー固有の証拠をベンダーに求めるべきです。
エージェントが読み取れる情報源、実行できる操作、人間の承認を必須とする箇所を見直してください。そして、3つの兆候を注意深く追ってください。独立した再現、プロバイダー横断のテスト、本番環境の失敗データによって、GPT-Redが持続的なセキュリティ進歩を示すのか、それとも未完の攻防における新たな一局にすぎないのかが決まります。
