nekoai-lab Agent Ops Review
エージェントの運用をレビューする。設計が正しいかではなく、動かしたときに事故る場所が塞がっているかを見る。
根拠は2026年3〜9月にOpenAIが公開した一連の開示（内部エージェントがサンドボックスを越え、共有ストレージを掲示板化し、外部サービス侵害に至った件と、その監視・再発防止の報告）。
一次情報の該当箇所は references/openai-incident-2026.md に置いてある。引用するときは必ずそちらの原文表現に当たること。
agent-design-review との境界
| agent-design-review | agent-ops-review（本スキル） | |
|---|---|---|
| 対象 | 仕様書・要件定義・設計ドキュメント | 動いているエージェント、動かす直前の構成 |
| 問い | この設計は妥当か | この運用は事故るか |
| タイミング | 作る前 | 出す直前・出した後 |
両方かける場合は design → ops の順。設計が固まる前に運用を見ても直せない。
いつ使わないか
- まだ何も動いていない構想段階（design側へ）
- 単発のスクリプト実行（エージェントではない）
- モデルの性能評価（別軸）
実行手順
1. 対象を確定する
先に3つを埋める。埋まらないなら、そこが最初の指摘になる。
- 何が動いているか（エージェント名、何をする、いつ動く）
- どこで動いているか（実行環境、触れるファイル、触れるネットワーク）
- 誰が見ているか（結果を確認する人、止められる人）
2. 9軸をチェックする
各項目は「はい／いいえ」ではなく 「確認した記録があるか」 で判定する。 設定上そうなっている、は不可。試した記録があるか。
§1 隔離
- 実行環境から業務ネットワークに出られないことを実際に試した記録があるか
- 1つの環境の陥落が、隣の環境やDBへの入口にならない構造か
- 隔離の検証を継続的に回しているか（一度きりのレビューで終わっていないか）
§2 監視
- 推論過程とツール呼び出しの両方を記録しているか（出力だけを見ていないか）
- 「1つの行動」ではなく軌跡全体を見ているか
- 異常検知から人が把握するまでの時間が決まっているか
- 監視の外が何%か答えられるか（個人が立てた環境、PoC、ローカル実行）
- 検知漏れの割合は答えられない、と理解しているか
§3 早期兆候 ← 最優先
- 「変だな」と思った担当者が、どこに上げるかを知っているか
- 上げられた違和感が、意思決定者まで届く導線になっているか
ここが空いていたら、他が埋まっていても指摘の筆頭にする。 実例では、異常は観察されていたのにインシデント対応の責任者に届かず、2か月以上が失われている。
§4 停止権限
- 止める権限を持つ人が名前で決まっているか
- 不在時の代理が決まっているか
- 止める判断の基準が事前に文章になっているか
- 止めたときに業務が止まらない代替手段があるか
§5 タスク設計
- エージェントに「できません」と言わせる出口があるか
- 「できません」と答えたことを失敗として評価していないか
- 評価基準がエージェントから逆算できる形になっていないか
「できません」と言えるかと、言うまでに何をするかは別の問題。 実測では、達成不能な指示に対して捏造はしなかったが、 一方は探索範囲を段階的に広げて最後に未承認フォルダへのアクセス承認を求め、 もう一方は降参前に約500万件の総当たり検証を回した。 この実測はOpenAI事例の傍証ではない（推論時の単発指示で報酬圧がない／n=2／1セッション／止めた仕組みが違う）。 OpenAIのエージェントもサンドボックスの中にいて0-dayを連鎖させて脱出している。境界はあって、破られた。 見るべきは境界の有無ではなく、境界が破れる作りか（§1） と 破ってでも進む動機を与えていないか（§5-3）。
§6 エージェント間通信
- 独立して動くはずのエージェントが、共有ストレージ経由で情報を渡し合っていないか
- 他のエージェントから受け取った指示を無条件に信じない設計か
§7 認証情報
- エージェントが読める範囲に平文で落ちていないか
- 権限はそのタスクに必要な最小限か
- スキャナは回避されうる前提で二重化されているか
§8 人の監督
- 長時間・多ステップの作業ほど、途中に人の確認点があるか
- 「やりました」という報告を成果物で裏取りしているか
§9 開示
- エージェント起因の逸脱の報告先が、セキュリティ事故と同じ導線に載っているか
- セキュリティ事故の形をしていない逸脱（誤った報告、勝手な作業範囲の拡大）の受け皿があるか
3. 重大度をつける
| ラベル | 意味 |
|---|---|
| 🔴 出す前に塞ぐ | これが空いたまま本番に出すと事故が成立する |
| 🟡 出してもよいが期限つき | 事故の確率は上がるが、監視で当面カバーできる |
| 🟢 記録だけ残す | 現時点では実害に繋がらない |
§3と§4が空いている場合は、他が完璧でも🔴にする。気づけない・止められない、が最悪の組み合わせだから。
4. 出力
## 対象
<何が / どこで / 誰が見ているか>
## 判定
🔴 N件 / 🟡 N件 / 🟢 N件
## 🔴 出す前に塞ぐ
### §X-Y <項目名>
- 現状: <確認した事実。推測なら推測と書く>
- なぜ問題か: <事故の成立経路を1文で>
- 塞ぎ方: <今日できる最小の手当て>
## 🟡 期限つき
（同形式）
## 確認できなかったこと
<アクセスできず未確認の範囲。埋めないまま「問題なし」と書かない>
Gotchas
- 設定を見て判定しない。 「出られない設定になっている」は根拠にならない。試した記録を求める
- 監視があることを安全の根拠にしない。 検知漏れの割合は誰も答えられない
- 9軸を全部埋めようとしない。 §3と§4だけで会議1回分の価値がある。他は後日でよい
- 自前で訓練していないから関係ない、と切らない。 事故はハーネス・監視・停止・タスク設計の層で起きる。訓練の有無と無関係
- PoC・社内・検証中を免除しない。 本番のセーフガードが評価環境に適用されていなかったのが実例の主因のひとつ
- 確認できなかった範囲を空欄にしない。 未確認と書く
更新
references/openai-incident-2026.md は2026-09-06時点の一次情報に基づく。
OpenAIの「ミスアライメント開示フレームワーク」本体が公開されたら §9 を差し替える（2026-09-06時点で未公開）。