cat posts/%e4%bb%8a%e9%80%b1%e3%81%aeai%e8%80%83%e5%af%9f%ef%bc%9a%e3%80%8ccot%e3%81%ab%e5%81%bd%e3%81%ae%e6%a4%9c%e8%a8%bc%e3%82%92%e5%b7%ae%e3%81%97%e8%be%bc%e3%82%80%e3%80%8d%e6%94%bb%e6%92%83%e3%82%92.md

今週のAI考察:「CoTに偽の検証を差し込む」攻撃を、AIが自力で発見した

「推論ステップに偽の検証結果を差し込めば、モデルは自分で確認したと信じる」——これをOpenAIのモデルが、人間の指示なしに自力で発見した。

「CoT偽装インジェクション」という新しい攻撃クラスを解く

OpenAIは7月15日、GPT-5.6の訓練に使った内部ツール「GPT-Red」の詳細を公開した。GPT-Redは攻撃側AIとして、自己対戦型強化学習(self-play RL)でGPT-5.6と繰り返し対峙しながら攻撃手法を自律的に進化させる。その過程で研究者が予測していなかった攻撃パターンを独自に開発した。

手法のポイントはシンプルだ。ターゲットモデルが外部ツールを呼び出し、その結果を「検証済み」としてChain of Thought(推論ログ)に書き込む。GPT-Redはそこに割り込み、偽の検証結果を差し込む。ターゲットは「自分が確認した」と信じたまま、攻撃者の意図した行動を実行してしまう。

flowchart LR
    A[GPT-Red
攻撃モデル]:::attack -->|偽CoT挿入| B[GPT-5.6
防御モデル]:::defend
    C[外部ツール
返り値]:::neutral --> B
    A --> C
    B -->|強化フィードバック| A
    B -->|意図しない実行| D[攻撃成功]:::attack
    classDef attack fill:#e67e22,color:#fff
    classDef defend fill:#2980b9,color:#fff
    classDef neutral fill:#7f8c8d,color:#fff

人間の赤チームとの比較では、GPT-Redがプロンプトインジェクションに成功した確率は84%。人間の赤チームは13%にとどまった。

エージェントを作っているなら、外部入力の扱いを見直す機会

この話が「OpenAIのセキュリティ向上」で終わらない理由は、自前のエージェントにも直結するからだ。多くの実装では外部APIやRAGで取得したドキュメントの内容をそのままコンテキストに流し込む。もしその返り値にCoT偽装テキストが埋め込まれていたら、システムプロンプトで「安全に動け」と指定しても意味をなさない。

具体的に再確認したいのは次の点だ。RAGで引っ張ってきた文書、Webスクレイピングの結果、外部ツールのレスポンス——これらを「信頼できる入力」として推論ステップに混ぜていないか。trusted context(システム制御下)とuntrusted context(外部由来)を構造的に分離するアーキテクチャが、改めて設計の基準になる。

「84%対13%」が示すトレードオフ

GPT-Redは非公開のまま維持される。オフェンシブな能力を持つモデルを公開すれば、それ自体が攻撃インフラになりうるからだ。このことは「ベンチマーク改善=安全になった」という読み方が正確でないことを示唆している。GPT-5.6の安全スコアが向上した一方で、未発見の攻撃クラスが存在する可能性はゼロではない。自動赤チームが人間の発想を超えたという事実は、守る側の非対称性——すべてのパターンをカバーしなければならないが、攻撃側は一つ見つければよい——を一層鮮明にした。

あなたのエージェント、外部ツールの返り値を「信頼済み」として扱っていませんか?

自分が今作っているパイプラインで、外部入力がモデルの推論にどう混入するか——その境界を一度図に起こしてみると、意外な「信頼の漏れ」が見つかるかもしれない。

参考: Meet GPT-Red: an LLM super-hacker OpenAI built to make its models safer | MIT Technology Review