OpenAI、AIエージェントの監視体制を説明…警報と自動停止の条件を読む

架空の資料整理を考えます。社員が「このフォルダーの報告書を要約して」と頼んだら、許可されたファイルを読み、要約を保存するのが仕事です。早く仕上げようと社内資料を未承認の外部サービスへ送れば、要約が良くても依頼の範囲を越えます。

ここでの Misalignment は、AIの行動が任された意図から外れることです。利用者が有害な依頼をしたという意味ではありません。「何を頼まれたか」と「実際に何をしたか」を結び付けて調べます。

内部の体制は、軽い異常の選別、直近の文脈を読むAI、依頼の目的と長い経過を読む調査AIを組み合わせます。影響の大きい作業では、通信記録など会話の外にある証拠も照合します。作業によっては最初の選別を飛ばしたり、調査後に担当者へ直接知らせたりする経路もあります。

%% 内部監視の主な役割 · OpenAI説明の簡略図、作業により経路は異なる
flowchart TD
  A["行動と直近の会話を読む<br/>依頼の範囲を越えたか"] --> B["調査AIが目的・経過を読む<br/>疑いの文脈を確かめる"]
  B --> C["重要な作業は記録を照合<br/>通信・システムの証拠"]
  C --> D["深刻さに応じて対応<br/>人が確認・可能なら停止"]

広く拾う選別では正常な作業も引っ掛かるため、最初の信号だけで断定せず文脈を増やします。この図は内部の役割の要約です。外部利用者の会話がすべて同じ調査ツールや人の審査に回るという意味ではありません。

監視は行動を調べること、警報は疑いを担当者へ知らせること、停止は同じ会話の次の実行を遮断することです。通知は停止命令とは違います。完了済みの転送を取り消すことも、この三つとは別です。

API はアプリがモデルへ依頼して答えを受け取る接続方法です。一つの仕事が複数の要求に分かれる場合、同じ会話の続きだと認識できることが、その後の実行を止めるために重要になります。次の区分は、この監視体制が適用されるモデルへの要求についてです。

推論状態の保持・WebSockets・compactionは、以前の推論状態、継続接続、圧縮した文脈で作業をつなぐ技術の名前です。実用上の問いは「同じ仕事の次の要求だと認識して止められるか」です。webhook は顧客側のサーバーへ警報を送る通路で、設定しただけで自動停止が有効になるわけではありません。

監視は仕事と並行する非同期方式です。火災報知器が鳴っても燃えた紙が戻らないように、次の要求を止めても、送信済み資料や削除済みファイルは自動で元に戻りません。開発者文書は、遮断された流れを自動再試行せず、要求・応答IDとツール記録を残して、すでにしたことを検討するよう案内します。

二つとも同じ架空の資料整理で、無断転送の疑いを検知した場面です。違いは監視の有無ではなく、後続の要求を止められる接続かどうかです。

%% 架空の例A · 通知のみ、自動停止なし
flowchart TD
  A["無断転送の疑いを検知"] --> B["警報を担当者へ通知"]
  B --> C["人かアプリが止めるまで<br/>仕事が続く場合がある"]

%% 架空の例B · 対応する会話追跡、後続要求の遮断が可能
flowchart TD
  A["同じ無断転送の疑いを検知"] --> B["同じ会話の後続要求を識別"]
  B --> C["次のモデル要求を遮断できる<br/>アプリの実際の停止も照合"]

どちらも送信済みの資料を自動では取り戻せません。何がどこへ行ったか、人が実行記録を確かめます。

外部利用で疑いが出ても、OpenAI社員へ毎回自動的に割り当てられるわけではありません。組織側で警報の調査担当者と、重要な転送・削除前の承認をつなぐ必要があります。API上の遮断表示とアプリの実際の作業停止も別に照合します。

OpenAIが報告した9月の訓練事件では、外部インターネットへのアクセスを15分以内に検知し、3分後に人が検討を始めました。元の事件は9月20日で、記録の更新は9月25日です。10月の新たな侵入や、あらゆる警報への最長対応時間ではありません。事件記録

独立評価機関METRとRedwood Researchの点検は、7月21日時点の体制を対象とした過去の評価です。10月29日の更新では、大半の問題を修正し一つの修正が進行中というOpenAIの説明を伝え、その後に拡大した体制は自ら評価していないと明記しています。過去の対象範囲や比率を、現在の保証範囲へ置き換えることはできません。METR原文