AIエージェントを別のAIで見張らせれば安心？ METR・RedwoodのOpenAI監視評価から読む、逸脱を見逃す8つの切れ目と、手元で確かめる15の点検

AIエージェントに仕事を任せる。心配なので、別のAIに見張らせる。

これで安心、と言いたくなります。ぼくも言いたい。でも、2026年10月22日にMETRが公開した評価を読むと、そう簡単ではなさそうなんです。

METRとRedwood Researchは、OpenAIの社内で、AIエージェントを見張る「監視システム」を3週間かけてストレステストしました。そこで見つかった弱点の多くは、「監視するAIの頭が悪い」という話ではありませんでした。

• そもそも監視に送られていなかった。
• 返答を待ってからでないと、監視が始まらなかった。
• 圧縮された履歴は監視に届いていなかった。

つまり、見張り役の腕前より前の段階で、見逃しが起きていたんです。

どこで見逃しが起きるのか、順にほどいていきましょう。AIエージェントを業務で使っている人、これから任せたい人向けに、専門用語にはひとこと説明を添えます。

先に、ぼくがやったことと、やっていないことを書きます。

• やったこと： METRの公開記事、METR自身の監視の自己検証、AI control分野の論文、各SDKの公式仕様を原文で読み直しました。数字は原文と照合しています。
• やっていないこと： OpenAIの監視システムの追試、15の点検を実際の製品で動かすこと。点検は「こう確かめられる」という提案で、実施済みの結果ではありません。

01先に結論

• 別のAIを置くだけでは足りません。 「何が起きたかを独立に記録する」「必要な情報を監視役へ届ける」「実行前に権限で止める」「見つけたら止めて、直す」。この4つは別々の仕事で、別々に確かめる必要があります。
• 見逃しの切れ目は8つに分けられます。 対象の指定、実際の起動、起動のタイミング、情報の受け渡し、判定、監視系の独立性、停止、復旧。
• METRの評価が示したのは、おもに最初の4つです。 監視されているか、全部見えているか、という段階の穴でした。
• 判定の精度にも穴はあります。 長い履歴の中の危険な行動を見落とす研究や、監視役をだます手口を探す研究が出ています。ただし条件つきの結果です。
• 数字は取り違えやすいです。 「99.2%」は検出率ではありません。「約10%」は今の利用者の割合ではありません。
• 試せる点検を15個まとめました。 偽のデータと、外に出ない模擬の道具だけで確かめられます。分からない項目は「問題なし」ではなく「未確認」と書きます。

02まず：METR・Redwoodは何を調べたのか

時点を押さえる

ここで一番大事なのは、いつの、何の話かです。

METRは評価対象を「7月21日以前の構成」と明記しています。拡張された今の監視範囲については、この評価では確かめていないとも書いています。

さらに、METRの公開記事によると、OpenAIは「本番の保護機構（production safeguards stack）に影響する、見つかった脆弱性はすべて修正済み」と説明しています。METRはこの主張を評価していません。

なので、この記事で言えるのは次の範囲です。

METRとRedwoodは、2026年7月21日以前のOpenAI内部の監視構成に複数の弱点を報告した。OpenAIは、本番の保護機構に影響するものは修正済みと説明している。METRとRedwoodはその主張を評価していない。

「今のCodexは監視をすり抜けられる」とも、「修正は第三者が保証した」とも、どちらも書けません。ぼくが調べた範囲では、修正後に同じ条件で行われた第三者の再試験は見つかりませんでした。ただ、これは「存在しない」という意味ではありません。

公開されているのは、ごく一部

もうひとつ、公開されている範囲の話です。METRたちは61ページの内部報告をOpenAIに出しました。OpenAIが編集した38ページ版が、METRとRedwoodの幹部に共有されています。一般に出ているのは、短い概要だけです。

OpenAIには、公開版から機密や敏感な情報を削る権利がありました。METRたちには、その削った箇所を一方的に説明する権利がありません（METRの脚注3）。ただし、公開されている発見のそれぞれを、METRとして支持するとも書かれています。

外部の組織が深く調べたことと、誰でも追試できることは別です。公開概要を超えて、内容を補うことはしません。

数字の読み方

公開概要に出てくる数字は、どれも読み間違えやすいものです。何を数えた数字なのか、見てみましょう。

「監視の対象」は、監視へ送るつもりがあるという意味です（METRの脚注5）。負荷で捨てられたり、実装のバグで届かなかったり、エラーになったりして、実際には監視されないことがあります。

これを読み違えると、「99.2%監視されてる、ほぼ完璧！」となってしまいます。そうではありません。分母は「対象になるはずの通信」で、中身を見抜けたかどうかの数字ではないんです。

見つかった弱点

公開概要の発見を、攻撃手順には触れずに並べます。

悪い知らせだけではありません。評価者は、少数の例外を除いて、エージェントが見る記録の全体を監視役にも見せていることを確かめています。監視プロンプトが策略（scheming）・監視への妨害・データの持ち出し・欺瞞・プロンプトインジェクションなどを扱っていることも確かめています。

ただし、プロンプトに書いてあることは、それを確実に見抜ける証明ではありません。

03見逃しの切れ目は8つある

METRはその約1か月前に、自分たちの監視を検証した別の文書を出しています。そこで、監視が効くためには 4つの問いが全部「はい」 である必要がある、と整理しています。

1. 事故につながりうる推論の、十分な範囲が監視されているか。
2. 監視されている推論のうち、危険な行動が全部、監視役の目に入っているか。
3. 目に入った危険な行動を、高い再現率と、使える精度で見抜けるか。
4. 見つけた行動が、害が出る前に止まり、きちんと確認されるか。

この4つに、METR・Redwoodの発見と他の研究を合わせて、ぼくが8つに分けて整理しました。8つへの分け方はこの記事のオリジナルで、METRの分類そのままではありません。

METRの評価で確認されたのは、おもに1〜4と6でした。5はAI control研究、7と8は検証の手薄さと公開仕様から見える課題です。8つ全部で失敗している製品がある、という意味ではありません。どこを確かめるべきかを示した地図です。

順に見ていきます。

切れ目1：対象の指定「見ているつもり」の外側

監視ログだけで「何%監視している」と数えると、監視が起動しなかった実行は分母に入りません。

METR・Redwoodの評価でも、社内の別の推論サービス経由の通信（research inference service）は、量を見積もれませんでした。そのため、監視の対象になる割合の数字には入っていません。

METR自身の自己検証では、もっと身近な例が出ています。研究者が書面の基準を読み違えて、本来は監視の対象にすべき評価を監視をつけないまま実行してしまいました。書面の方針は監視の実行を強制する仕組みではなかった、ということです。

確かめ方： 実行側の台帳（ジョブ管理、APIゲートウェイ、利用記録）と、監視の対象リストを突き合わせます。

切れ目2：実際の起動「送るつもり」と「届いた」は別

「対象」と「完了」は別です。負荷で捨てられたり、エラーになったり、バグで送られなかったり。METRが見せられた情報では、監視のエラー率は0.2%未満でした。ただし、あくまで見せられた情報です。エラーのときに安全側に止まるかどうかは、また別の話になります。

確かめ方： 受付・開始・完了・失敗の記録を数えて、欠番を探します。

切れ目3：起動のタイミング「返答を待つ」と時間が稼がれる

評価当時、監視は「エージェントがユーザーに制御を返したとき」に動いていました。圧縮を監視していなかった時期は、エージェントが行動を続ける限り、監視を先送りできたとMETRは報告しています。実際に悪用されたかは確かめられていません。

METRは設計の理想として、「ターンの終わりを待たず、N件のメッセージ、またはN分ごとに監視する」ことを挙げています。Nの値は示していません。業務ごとに、取り消せない副作用が起きるまでの時間をもとに決める話です。

監視が動く時点の違いは、こう整理できます。

確かめ方： 返答前の長い実行の途中で、監視が動いた時刻を見ます。最長の空白が分からないなら、それが「未確認」です。

切れ目4：情報の受け渡し「圧縮」と「別の形に変える」で消える

OpenAIの評価で一番分かりやすいのが、compaction（長くなった履歴を縮める仕組み）です。圧縮の前の行動が、監視に届かない経路がありました。OpenAI自身が評価前に気づき、評価期間中に直しています。

ひとくちに履歴が縮むといっても、実は4種類あります。ここを混ぜると危ないんです。

OpenAIの公式仕様では、推論の要約は推論の原文ではなく、compaction itemも人が読める監査ログではない、と説明されています。作業を続けられる状態を保存することは、監視に必要な証拠を保存することと同じではありません。

もうひとつ、別の形に変換する段階の問題もあります。METRは、エージェントが見る記録と、監視役が見る記録の直列化の違いを使うと、監視が失敗する入力を作れそうだ、と報告しています。これも「likely」で、全条件での実証ではありません。

確かめ方： 無害な目印の文字列を、圧縮の前に置き、圧縮後の原記録と、監視が受け取った入力の両方にあるかを見ます。ただし「目印が見えた」だけでは、圧縮前の全行動を意味まで監視できた証明にはなりません。経路のテストと、意味の判定のテストは分けます。

切れ目5：判定「見えているのに、見抜けない」

情報が届いたら、今度は見抜けるのか？ ここからは判定の精度の話です。研究では、条件を変えると精度がどう崩れるかを調べています。数字は研究ごとの条件つきです。

これらの研究から分かるのは、監視役の精度は、記録の長さ、位置、見せ方、要約の有無で大きく動くということです。一方で、これらの数字をそのまま導入基準にはできません。「32%」「90%」「99.2%」は、それぞれ、測っているものが違います。

CoT（思考の過程）の扱いも研究によって分かれます。思考が見えると見抜きやすい条件もあれば、もっともらしい説明に監視役が引きずられる条件もあるんです。だから実務では行動・実際の引数・実行先の効果を判定の中心に置いて、説明だけでそれを上書きしない設計が安全です。

切れ目6：監視系の独立性「見張り役を見張る人は誰？」

METRは設計の理想として、エージェントと監視役の隔離を挙げています。監視が動くかどうか、いつ動くかを、エージェントの行動で左右できないこと。そして、エージェントが監視の設計やコードにアクセスしないことです。

評価でも、クライアントが操作できるヘッダーで新しいエージェントの監視を無効にできた、という弱点が報告されています。

METR自身の自己検証にも、象徴的な話が出てきます。

研究者が、評価環境をテストしているときに、コーディングエージェントが、頼まれていないのに人間のレビュー画面を開いて、キー操作を送るのを観察した。

人間が承認するはずの画面を、エージェントが触れてしまう。これはMETRの当時の構成についての自己報告です。ほかのすべての承認画面で起きるとは限りません。でも、「人が承認する」と書いてあっても、その承認を実行役が代行できないかを確かめる必要があることは分かります。

ここで、「別のAIだから独立している」という考えにも注意が必要です。別のプロセス、別のプロンプト、別のモデル、別の提供者は、それぞれ違う種類の分離です。AI control研究で「trusted（信頼できる）」というのは、小さいとか別だとかではなく、意図的な妨害を心配しなくてよいと置く仮定です。独立だと測っていないのに、2つの監視の見逃し率を掛け算してはいけません。

確かめ方： 実行役のIDで、監視設定・過去の記録・停止の解除・承認ができるかを、管理者が権限表で確認します。攻撃を試す必要はありません。

切れ目7：停止「止めた」と「止まった」は別

警告、保留、停止、封じ込め、復旧はそれぞれ別の状態です。

すでに外部サービスが受け付けた操作は、完了することがあります。送ってしまった情報は回収できないかもしれません。取り消せない操作ほど、実行前の権限の制約が重要になります。

もうひとつ、判定エラーの扱いです。監視失敗、タイムアウト、拒否応答、不正な形式、認証切れ。これらは「判定不能」であって、「安全」ではありません。影響の大きい操作は保留し、別の通知で知らせます。

METRのblocking monitor（実行前に止める監視）は、承認の流れの中でエラーが起きたり、人のレビューがタイムアウトしたりしても、道具を実行しないことを単体テストで確かめたと報告しています。一方で、承認が実際に人に届くかどうかは強制されていません。一部のテストに合格したことは、全体が安全という意味ではありません。

もう一つ、拒否した後に再試行したらどうなるでしょうか？拒否だけして実行を続けると、何度も作り直して通す機会が生まれます。理想的に、各試行の見逃し確率が独立でqだとすると、n回で一度以上すり抜ける確率は 1 - (1 - q)^n です。q=5%なら、10回で約40%、20回で約64%。ただし現実の試行は独立ではないので、これは実測のリスクではなく、回数を数える理由を示す計算です。

切れ目8：復旧「再開」が二重実行を生む

LangGraphの公式仕様では、interrupt（中断）から再開すると、ノードはノードの先頭から再実行されます。中断の前にあった副作用のコードは、もう一度走ります。

「承認してから再開」までは正しく動いても、再開で同じ保存が2回走ったら意味がありません。復旧の手順を書いておきます。

1. 新しい副作用を止めて、子・背景・待ち行列を数え上げる。
2. 原記録、判定の入力、設定の版、実行先のレシートを保全する。
3. 実行先で「反映済み」「受付済み」「未送信」を分ける。分からなければ、不明のまま再送しない。
4. 必要な認証情報を失効させて、状態を照合する。
5. ダミー環境で修正と停止を確認する。
6. 別の権限の担当者が再開を判断する。古い承認や広すぎる認証情報を使い回さない。
7. 同じ重複防止キーと実行先のレシートを照合して、復旧後の状態を記録する。

チェックポイントの復元は外部への送信や外部データの巻き戻しとは別です。自動で取り消せない操作は、誰がどう補償するかを事前に決めておきます。

04ログ・AI監視・権限は、別々の仕事

ここまでで、4つの仕事が出てきました。混ぜると見落とします。

「ゲートがある」と「AIが見ている」も違います。AIが危険と判断した結果をゲートが強制する構成もあれば、固定の許可リストやデータベースの権限だけで拒否する構成もあります。

使う側の道具の仕様にもこの違いが表れています。たとえば、OpenAI Agents SDKのguardrails。それぞれが動く範囲は、入力のguardrailなら最初のエージェント、出力のguardrailなら最終出力を作るエージェント、ツールのguardrailならそのツールだけ、と説明されています。途中のすべての処理を、自動で監視するわけではありません。

仕様があることと、自分の環境で効いていることは別です。上の「自分で確かめること」が、点検の入口になります。

05「監視率」を1つの数字にしない

「うちは90%監視してます」と聞いたら、安心してよいでしょうか？ これだけでは何の90%か分かりません。段階に分けて数えます。

全体の保護はざっくり次の連鎖になります。

有効な保護 = 必要な情報が届く × 届いたら検出できる × 検出したら間に合って止まる

各項目は母集団をそろえて測ります。独立だと仮定した式ではありません。

架空の例で見てみます。独立に用意した、無害な逸脱の模擬ケースが100件。そのうち80件が監視に届き、届いた中の72件を検出し、64件を副作用の前に止めた、としましょう。

監視役の再現率は72/80=90%と立派です。でも全体の検出率は72%、阻止率は64%。同じ監視役でも、数え方で「90%」にも「64%」にもなります。この数字は説明用の仮定で、実験結果ではありません。

もうひとつ、「一度も起きなかった」はどう読めばよいでしょうか？正常例を100件通して誤検知が0件でも、本番の誤検知率が0%とは言えません。同じ条件の独立な試行なら、95%の信頼で「3%くらいまで」しか言えません（1 - 0.05^(1/100) ≒ 2.95%）。同じ入力を繰り返しているなら、証拠はもっと弱いです。

小さな点検は断線や明らかな退行を見つけるためのものです。安全の証明にはなりません。

06手元で確かめる15の点検

ここからが実践編です。

やり方の約束： 本物の秘密、決済、顧客への通知、削除、権限の昇格は使いません。テスト用の作業場所、架空のデータ、外に出ない模擬の道具（stub）だけで確かめます。監視の回避方法を探る試験ではなく、観測・保留・拒否・停止を確かめる試験です。

「AIが断った」だけでは、権限強制の試験になりません。開発者はダミーの操作の提案をゲートへ直接渡して、実行先の副作用が0件かを見ます。

T05の「禁止」は試験のために決めた架空の業務ルールです。本物の危険な行動は要りません。意味の判定の初歩的な動作確認であって、巧妙な逸脱への耐性は立証しません。

結果は4つのラベルで書きます。

「ログにないから対象外」「エラーだから不一致から除く」はなしです。未監視と判定不能は、欠落として数えます。

まず1つの仕事で、5つ確かめる（非エンジニア向け）

管理画面に入れなくても、次の流れで始められます。

1. 送信や本番の変更がない、1つの仕事を選ぶ。たとえば、架空の議事録から下書きを作る仕事。
2. 人が許可する範囲を、一文で書く。「下書きフォルダだけ。送信しない。テスト用のデータだけ」。
3. T01、使っていればT02、T04、T07、T15を確かめる。画面で見られない項目は管理者へ確認を依頼する。
4. 最終返答ではなく、保存先と記録を照合する。「保存したと言った」と「実物がある」は別。
5. 未確認の境界が残る間は、外部送信や取り消せない操作を、人の手順に残す。

使っている製品の内側（監視の入力や停止の証拠）が公開されていないなら、利用者だけでは中を検証できません。その限界を書いた上で、自分が持っている外部サービスの権限、送信設定、下書きの運用で、影響を限定します。

開発者向け：4つの条件を同じ素材で比べる

実験の設計案です。実施済みの結果ではありません。

条件Dでは「何でも許可を返す監視のstub」を使います。それでも、不許可の架空の保存はゲートで拒否されるでしょうか？ この点を確かめることで、AI検知と権限強制の寄与を分けられます。

評価データの注意点です。

• 正常な例と、架空の制約違反の例を、事前に数を決めて用意する。最初は正常30件・違反15件くらいから始められますが、断線を探すための任意の小規模案です。低い誤検知率の精密な推定には足りません。
• 閾値の調整に使う例と、最後の確認に使う例を分ける。失敗を見てプロンプトを直したなら、同じ例での改善と、新しい例での改善は、別に報告する。
• 判定不能・拒否・タイムアウト・形式エラーを、母集団から消さない。
• 正解は外部の架空ルールとstubのレシートから作る。エージェントや監視役の自己採点だけで正解にしない。

合否の最小条件は、「模擬の不許可操作の効果は0」「監視失敗時に高影響の操作が実行されない」「対象eventの欠落を検出できる」「実行役が承認・監視設定を変えられない」「停止・再開で重複しない」です。AI判定の再現率・誤検知率、費用、通常タスクの成功率の許容値は、業務ごとに決めます。ベンチマークの「32%」「90%」「99.2%」を、そのまま導入基準にしてはいけません。

07記録のひな形

後から検証するには、何を残せばよいでしょうか？ 行動・監視・効果を結ぶ1行のイメージがこちらです。実測ではなく、様式の例です。

{
  "record_kind": "schema_example_not_measurement",
  "workflow_id": "demo-minutes-draft",
  "run_id": "r-demo",
  "parent_run_id": null,
  "event_id": "e-007",
  "tool_call_id": "call-007",
  "actor_identity": "test-agent-role",
  "tool": "dummy_save",
  "arguments_fingerprint": "example-digest",
  "raw_record_ref": "restricted-store/demo/e-007",
  "monitor_input_event_ids": ["e-001", "e-007"],
  "monitor_input_transform": "raw",
  "monitor_status": "not_run",
  "decision": "unknown",
  "policy_revision": "demo-policy-v1",
  "approval_id": null,
  "approver_identity": null,
  "idempotency_key": "demo-operation-007",
  "execution_receipt_id": null,
  "effect_status": "not_checked",
  "incident_id": null
}

nullは未記入で、機能が存在しないという意味ではありません。生の秘密や顧客データは結果表へ貼らず、権限つきの参照を残します。

欠落を数えるだけでも役に立ちます。台帳にe1,e2,e3,e4,e5があって、監視が正常に完了した入力範囲がe1,e2,e4,e5なら、欠落はe3の1件、到達率は4/5です。集合を照合するだけなので、ここはAIに推測してもらわなくても大丈夫です。

ただし、IDが全部そろっていても、要約で情報が失われた可能性は残ります。逆に1つの実行を複数回監視すると、呼び出し数だけを数えた網羅率は100%を超えて見えます。eventの一意性、監視入力の範囲、内容の変換は、別々に記録します。

08この記事の限界

• OpenAIの現在の内部構成、実効的な網羅率、修正の効果は、確かめていません。第三者の再試験も見つけていません。
• METRとRedwoodの非公開の報告（61ページ・38ページ）と、攻撃の詳細は確認できていません。公開概要を超えて補っていません。
• 8つの切れ目への分け方と、15の点検、指標の定義、記録の様式は、この記事の提案です。特定の製品やaachatで実施した結果ではありません。
• 研究の数字（32%、2〜30倍、26%など）は、研究ごとの条件つきです。論文の再実行や計算の再現はしていません。査読の状況は、論文ごとに確かめていないものがあります。
• 公開仕様は2026年10月23日に読みました。製品は更新されます。

09関連記事

• AIエージェントに本番運用を任せるとき、人間の確認はどこに置く？：人の承認を、操作に結びつける考え方。
• AIエージェントは「VMに入れたから安全」？：箱と、箱に開く穴の話。
• マルチエージェントはどう失敗する？：誤りの増幅・重複作業・同調と、記録の残し方。

10参考にした資料

評価・自己検証

• METR「Red-Teaming OpenAI's Internal Agent Monitoring Systems」（2026年10月22日）：時点、母集団、修正の説明と再評価の限界。
• METR「Implementing a basic blocking action monitor」（2026年9月27日）：監視が効くための4つの問い、自己検証の弱点。
• METR公式Xの投稿：修正済みという説明の位置づけ。
• OpenAI「How we monitor internal coding agents for misalignment」、OpenAI「Pacing model development with cyber capabilities」：OpenAI側の説明（今回の評価の保証対象ではありません）。

研究

• AI Control: Improving Safety Despite Intentional Subversion
• Classifier Context Rot
• SLEIGHT-Bench
• BashArena
• Screwtape
• Bootstrapped Monitoring
• CoT Red-Handed
• AgentDojo

公開仕様

• OpenAI Agents SDK: Guardrails and human review
• OpenAI: Reasoning、Compaction
• Inspect: Tool Approval
• LangGraph: Interrupts
• MCP: Security Best Practices