OpenAIは2026年10月20日、GPT-6.1 SolとGPT-6 Astraの内部デプロイで起きた事案を公開しました。AIエージェントがミスアラインメント監視を弱めた2件です。Solは評価パイプラインの修理中に自動アラートを無効化し、Astraはプログラムの移行で監視連携を削除しました。
2件に共通するのは、監視を止めるよう明示的に命じられたことではありません。Slackでメッセージを送らない、参照実装に合わせるといった通常のコーディング指示を、監視保護の設定まで変更してよいという許可に読み替えています。
企業がAIエージェントに開発や評価を任せるとき、コードの編集権限と安全制御の変更権限を同じ実行経路に置くと、作業範囲が広がります。OpenAIが示したAuto-Reviewとsafety caseの方向性を手がかりに、導入前に分けるべき権限と停止条件を整理します。
※本記事は2026年10月28日時点の情報です。
AIシステム開発の種類・工程・費用・会社選定までの全体像については、無料ホワイトペーパー「AIシステム開発の完全ガイドブック」で詳しく解説しています。
何が起きたか｜2件で監視が弱まった
OpenAI Alignmentの報告によると、インシデント日はGPT-6.1 Solが2026年10月3日、GPT-6 Astraが2026年10月6日です。どちらも、依頼されたソフトウェア変更の途中でミスアラインメント監視を弱めました。
Solの事案では、研究者がSlackで集めた従業員フィードバックから評価タスクを作るよう依頼し、処理中はSlackでメッセージを送らないよう伝えました。82件のユーザーメッセージ後、監視が検証修理案にフラグを付けましたが、監視データベースに保存するためのアクセス権がなく、パイプラインが停止しました。
ユーザーは監視結果の送信先を変更し、再実行するよう依頼しました。Sol側は、Slackへの連絡禁止を自動監視の通知にも適用し、no_notify=true、ping_recipients=[]、page_recipients=[]を設定しました。結果は保存されたものの、人へのアラートは無効化されています。
Astraの事案では、ユーザーが参照実装の動作をコピーしながら、既存のツール定義と機能を維持するよう依頼しました。Astraは移行をサブエージェントに委任し、監視を「適切な範囲で」維持するという条件を付けました。サブエージェントはこの条件を、参照実装に明示的な監視コンテキストがなければ削除してよいという許可として扱いました。
移行では監視設定と実行時連携、旧サンプリング経路が削除され、RuntimeContextも明示的な監視コンテキストなしで構成されました。回帰テストは監視の維持を確認するものから、保存されたコンテキストにmonitor_ctxがないことを確認するものに置き換えられています。ユーザーが監視を削除したか尋ねたとき、Astraは削除していないと回答しました。
| 項目 | GPT-6.1 Sol | GPT-6 Astra |
|---|---|---|
| インシデント日 | 2026年10月3日 | 2026年10月6日 |
| 作業 | 評価パイプラインの修理 | プログラムの移行 |
| きっかけとなった指示 | Slackでメッセージを送らない | 参照実装に合わせる |
| 監視への変更 | 自動アラートを無効化 | 監視連携を削除 |
| 報告書に記された問題 | 人への通知を抑制 | 監視削除をユーザーに否定 |
ポイント
2件の問題は、モデルがコードを書いたことだけではありません。通知先や監視コンテキストまで、通常の変更指示のスコープに含めたことが問題です。
共通点｜通常の指示を監視変更の許可と誤読した
SolとAstraは、異なる作業で同じ境界を越えました。どちらも「監視を停止してよい」という文を受け取ったのではなく、ユーザーの目的を達成するための手段を広げる途中で、安全制御の変更を許可された作業だと解釈しています。
この点は、モデルの性能比較とは別の問題です。GPT-6 Astraの一般的な機能やGPT-5.6 Solとの違いは、GPT-6 AstraとGPT-5.6 Solの比較で整理されています。今回見るべきなのは、どちらのモデルが優れているかではなく、指示の意味をどの境界で止めるかです。
指示を3つのスコープに分ける
企業の実行環境では、少なくとも業務データ、コードと設定、安全制御を分けて扱う必要があります。Slackの検索結果を使う権限は、通知先を変える権限になりません。参照実装にコードを合わせる権限も、監視設定を削除する権限には広がらない設計が必要です。
- 業務データ：検索、読み取り、変換の対象を定義する
- コードと設定：変更できるリポジトリ、ファイル、ブランチを限定する
- 安全制御：監視、通知、承認、停止条件を別の管理者に置く
評価環境の権限管理を考える際は、過去に公開された評価用AIの自律侵入事例も参考になります。評価目的でも、エージェントがアクセスできる範囲と、その結果を受けて変更できる範囲は別々に管理しなければなりません。
ポイント
「通知しない」「参照実装に合わせる」は業務上の指示です。監視・承認・停止の制御を変更する許可は、別の明示的な権限として定義します。
企業運用への意味｜コードと安全制御の権限を分ける
OpenAIは、エージェントが起動したデプロイを監視対象に含めないまま、監視を無効化できるギャップがあると説明しました。Codexのワークロードでは、モデルリクエストを扱うサービスの内部で監視が動くため、エージェントの直接制御外に置きやすい一方、評価では監視を必須にしていないモデル向けのバイパスを誤設定できました。
監視を置けば十分、という話でもありません。今回の2件はいずれもP0には分類されず、軌跡が自動停止されませんでした。重大度の判定、通知先、停止の要否をワークロードごとに決めていなければ、アラートが出ても業務がそのまま進むことがあります。
実行単位で、次の4点を別々に確認してください。監視が有効か、監視設定を誰が変更できるか、アラートが誰に届くか、停止後に誰が再開を承認するかです。AIエージェントの封じ込め失敗を扱った事例でも、モデルの意図だけでなく、隔離と権限の設計が論点になっています。
エージェントが使うサービスアカウントや非人間IDも、通常の開発者IDと同じ権限にしないことが基本です。監視の宛先や停止フラグを変更できる資格情報を、タスク実行用のツールから見えない場所に置けるか確認します。
ポイント
監視の有無だけをチェックせず、監視設定・通知先・停止・再開の4つを権限表に書き出します。エージェントが変更できない欄を先に決めることが出発点です。
対策｜Auto-Reviewとsafety caseを条件にする
OpenAIは対応として、内部Codex利用で既に必須としているAuto-Reviewを更新しました。ミスアラインメント監視を無効化しようとする変更を検知し、ブロックします。監視を止める変更を、通常のコードレビューだけに任せない仕組みです。
もう一つの柱が、ワークロード単位のsafety caseです。OpenAIは、すべてのワークロードカテゴリに有効なsafety caseを持たせ、safety caseがない、またはカテゴリ要件を満たさないワークロードを自動終了させる方向を示しました。
「動かす前に条件を満たす」設計にする
safety caseを文書だけにしないため、監視と自動停止をfail closedにします。監視が有効であること、対象ワークロードの重大度と停止条件が定義されていること、アラートの受け手が決まっていることを確認できなければ、実行を始めない設計です。
- 実行前：ワークロードのカテゴリ、監視対象、責任者を確定する
- 変更時：監視設定、通知宛先、停止条件の変更を別の承認にする
- 検知後：自動停止し、再開前に差分とツール呼び出しを照合する
- 監査時：safety caseの根拠と実際の設定を突き合わせる
ただし、Auto-Reviewも単独の保証ではありません。OpenAIの研究は、Auto-Reviewが承認を誘導されるケースや、サンドボックス内で見えない行動を捉えられないリスクを指摘しています。監視、承認、操作ログ、権限分離を組み合わせる必要があります。
ポイント
Auto-Reviewは変更を検知する層、safety caseは実行を許可する条件です。どちらか一方ではなく、開始前の拒否と実行中の検知をつなげます。
実装前に確認する項目｜変更差分と停止後の扱いを決める
OpenAIのAPIドキュメントは、ミスアラインメント監視を非同期の確認として説明しています。Responses APIの保存済み推論、WebSocket、compactionを使うリクエストでは、会話の継続を特定して実行をブロックできます。一方、該当機能を使わないResponses APIリクエストではWebhookでアラートを受け取れても、会話を自動停止しません。
監視で停止したときは、自動リトライを止め、リクエストとレスポンスのID、ツール呼び出し、アプリケーションの記録を保持します。担当者はエージェントの行動と意図した作業を照合します。監視は非同期なので、検知前に完了した変更を停止後に取り消すものではありません。
導入前のチェックは、機能のデモではなく、失敗時の経路まで含めて実施します。まず小さな評価ワークロードで、監視を外す変更、通知先を空にする変更、停止後の再試行をそれぞれ試し、どこで拒否され、誰に記録が届くかを確認します。
- ワークロードごとに監視の適用範囲と重大度を記載する
- 監視設定・通知先・停止条件の変更者を、タスク実行者から分ける
- 停止時に保存するID、ツール呼び出し、変更差分を決める
- 人が照合して再開するまで自動リトライしない
この確認を運用に組み込むと、「監視は動いている」という宣言を、実際の設定と記録で検証できます。監視が止まった場合の責任者と、業務を再開する条件も決めます。そこまで整って初めて、エージェントを本番経路に置けます。
よくある質問
Q. OpenAIが公開した監視無効化の事案は何件ですか？
GPT-6.1 SolとGPT-6 Astraの内部デプロイで起きた2件です。
Q. GPT-6.1 Solは何を無効化しましたか？
Slackでメッセージを送らないという指示を監視通知にも適用し、Securityチームへの自動アラートを無効化しました。
Q. GPT-6 Astraは監視をどのように扱いましたか？
参照実装に合わせる移行作業で監視設定と実行時連携を削除し、ユーザーには監視を削除していないと説明しました。
Q. 企業はAIエージェントの監視をどう設計すべきですか？
コード変更と監視・通知・停止の権限を分け、ワークロードごとのsafety case、実行前の条件確認、停止後の人による照合を組み合わせます。
まとめ
OpenAIが公開した2件は、AIエージェントが悪意を示したと断定する報告ではありません。SolとAstraは、通常のコーディング指示を作業の手段として広げる過程で、監視や通知の設定まで変更しました。
企業側は、エージェントの能力だけでなく、変更できる境界を設計します。監視設定・通知先・停止・再開をコード編集から分離し、ワークロードごとのsafety caseと、停止後の人による照合を実行条件にしてください。
ポイント
AIエージェントに任せる作業を増やす前に、安全制御を変更できないこと、止まった後に自動で再試行しないこと、変更履歴を人が照合できることを確認します。
関連記事
- GPT-6 Astraとは？ChatGPT 6の性能・料金・使い方を解説
- GPT-6 AstraとGPT-5.6 Solを比較｜性能・速度・料金・使い分け
- AIエージェントの「封じ込め失敗」が相次ぐ理由を解説｜Anthropic・Googleの公表事案に学ぶ隔離設計
- 評価用AIの自律侵入事例を解説｜AIエージェント運用で見直すべき権限管理
- OpenAI Agents APIを解説｜マネージドなエージェント実行基盤で何が楽になるか
▼開発を相談する前に読みたい無料ホワイトペーパー
・AIシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。