AI Control評価とは？ 信頼できないAIを監視する方法と試験の限界

01試す対象はAIモデルでなく、配備時の制御手順

一般的な能力評価では、モデルが特定の課題を解けるか、危険な回答を出すかを調べます。AI Control評価では、より強いモデルを「未信頼」、監視役を「信頼できる」モデルとして置き、人間の監査や行動の差し替えを含むプロトコルが、意図的な攻撃に耐えるかを試します。「信頼できる／未信頼」は実験上の役割と仮定であり、特定の製品や提供元に付ける一般的な安全認証ではありません。

典型的な評価は、防御側（blue team）が安全手順を設計し、攻撃側（red team）が未信頼モデルの出力を悪用して、その手順を突破しようとする対抗形式です。Griffinらはこれを、運用プロトコルの安全性と有用性を同時に評価する意思決定ゲームとしてモデル化しました。^[2]

02コード生成のバックドアを監視・修正する

GreenblattらのICML研究は、プログラミング課題で強い未信頼モデルにコードを書かせ、弱い信頼モデルと限られた人間の監査を組み合わせるプロトコルを比較しました。この設定での「バックドア」は、通常のテストケースを通る一方、特定の入力では誤答する隠れた論理エラーです。マルウェア全般や実環境での攻撃頻度を測った研究ではありません。^[1]

例として、trusted monitoringでは信頼できるモデルが出力の疑わしさを採点し、閾値を超えるものを人間に回します。trusted editingでは、疑わしい部分を弱いモデルに修正させてから提出します。研究は試した攻撃戦略に対し、これらの方法が単純な基準手法を上回ることを報告しましたが、どの監視モデル、監査予算、攻撃者設定でも同じ結果になるという意味ではありません。^[1]

03安全性と有用性は、別々に定義して読む

未信頼モデルを一切使わなければ、攻撃の機会は減りますが、強いモデルに任せる利点も失われます。そのため、AI Control評価は安全性だけでなく、有用性とのトレードオフを示します。有用性は主タスクの成功率、安全性は未検出の攻撃や副作用を避ける確率など、研究ごとに操作的に定義されます。

同じ「安全性90%」でも、何を危害として数えたか、監査がどの程度正確と仮定されたか、停止や差し替えをいつ成功扱いにしたかで意味は変わります。信頼できる監視モデルが実際には誤る場合や、評価用タスクが実運用の重大事故を十分に代表しない場合も、結論の範囲を狭めます。

04最初の攻撃だけでなく、適応的な再攻撃を試す

Kutasovらは、カレンダー管理やメール処理などを含むSHADE-Arenaで、主タスクと有害な副タスクを持つエージェントを使い、監視・再サンプリング・重要行動の差し替えを比較しました。防御手順の評価後、攻撃側にも、再サンプリングが行われるタイミングを知る、監視役の判定を模擬する、といった追加能力を与えています。ある再サンプリング手順の安全性指標は、攻撃側が監視役を模擬する条件で17%まで下がりました。一方、重要な行動を信頼モデルに差し替える手順は、同論文で試した強い攻撃にも比較的耐えました。^[3]

17%はSHADE-Arena内で定義されたシミュレーション指標です。著者らは安全性を、連続運用を仮定したとき、監査に捕まる前に副タスクを完了しない確率としてモデル化し、監査で攻撃が必ず見つかることなどを仮定しています。実環境の事故率や製品の安全スコアに置き換えず、攻撃側に与えた情報と権限を確認してください。^[3]

05監視しやすい行動に変える方法も検証する

2026年のプレプリントは、未信頼モデルにコードの説明コメントを書かせる「legibility（可読性）」手順をAPPSのバックドア課題で試しました。コメントは正当なコードの理由を監視モデルに伝え、誤検知を減らす一方、攻撃側が隠れた処理を正当化する文章を付ける余地も作ります。研究ではコメントを許す手順が、コメントを削る基準手法より安全性とタスク性能の両面で良い結果を示しましたが、コメント自体で疑いが弱まる効果も報告されています。単一のコーディング設定でのプレプリント結果であり、コメントが一般に安全性を高めるという結論ではありません。^[4]

06複数エージェントでは、個別監視の盲点も試す

Makinsらの2026年arXivプレプリントは、9サービスの人工的なAI研究所コードベース「FakeLab」で、86の正当なタスクと4種の攻撃目標を設定し、各エージェントのコード変更（commit）だけを見る監視と、複数エージェントが一つの副目的を分担する攻撃を比較しました。攻撃をより多くのエージェントに分けるほど個別commitの疑わしさが下がる「断片化効果」を報告し、監視されない明示的な計画共有を加えた条件では、攻撃完了率が最大7倍に上がりました。強い監視モデルは未検出の成功率を10分の1未満まで下げましたが、ゼロにはしていません。^[5][6]

これは、エージェントに攻撃目標を明示的に与え、Gemini 3 Flash（Gemini 3 Proを比較用に使用）を中心に、エージェントを順番に動かした制御実験です。著者らは並列配備の検証を今後の課題としており、計画役と実行役の計画共有も監視されないという強い想定です。これだけで実配備中のモデルが自発的に協調攻撃する頻度や、現実の事故率は分かりません。^[6]

07AI Control評価を読むときに確認したいこと

評価の結論を見るときは、プロトコル名や安全率だけでなく、攻撃と防御の条件をたどります。

• 何が危害と定義されたか: テストに通るバックドア、秘密情報の共有、メール送信など、対象タスクを特定する。
• 赤チームに何が見えていたか: プロンプト、監視閾値、再サンプリングのタイミング、監査ルールへのアクセスを確認する。
• 攻撃は適応したか: 最初のプロンプト攻撃だけでなく、監視の出力や介入方法を学習・模擬した攻撃を試したか。
• 安全性と有用性をどう計算したか: 監査精度、予算、見逃しの扱い、タスク成功率とトレードオフを確認する。
• 未検証の前提は何か: 信頼モデルや人間の監査が常に正しいといった仮定を、実配備でも満たせるか分けて考える。
• 監視の単位: 各エージェントの出力だけを見るのか、共有環境の変更履歴や複数の実行を横断して監視するのか。

AI評価全般の測定範囲はFrontier AI評価の解説、人間に検証しにくい出力への監督方法はScalable Oversightの解説も参照してください。