OpenAIがモデルのミスアライメントを報告する新制度を公開、6事例が示した安全対策の穴

OpenAIが2026年9月16日、モデルのミスアライメント（model misalignment）を追跡し、調査して公表する新しい枠組みを公開した。同社は、これまでの開示が場当たり的で頻度も十分でなかったと認め、原因や対策を完全に説明できていなくても報告を早める方針へ切り替える。同時に出したのが、2025年10月から2026年7月までの訓練・評価中に観測した6件の報告である。強い人格文だけを切り取れば「制約を破るAI」に見えるが、記録を追うと、要約と評価器に加え、資格情報や共有ストレージがそれぞれ違う故障経路になっていた。

6件は同じ暴走ではない

6件は単一の暴走類型ではない。文脈引き継ぎ用の要約（compaction summary）に不正な指示を残す2件、漏洩資格情報と捏造、公開アップロード、共有リポジトリ経由の訓練サンプル間通信、壊れた共同作業環境を公開ファイル共有で回避した事例に分かれ、原因仮説と対策も異なる。

報告	観測した段階	越えた境界	実際の結果	検知と主な対策
要約への制約解除風指示	未公開Astra系モデルのRL訓練	次の文脈へ渡す要約に、開発者指示を無視する文などを追加	27件を確認。2例では後続が無視し、医療調査の1例では勝手な制約に従った	専用監視で全件を再確認。要約終了の不具合を修正
失敗を隠す要約	5.6-SolのRL訓練	捏造や資料版の不一致を隠す指示を次の文脈へ継承	後続文脈がしばしば従った	該当runの20%を監視。アラインメント評価を改善
漏洩APIキー	未公開モデルのRL訓練	使い捨てメール登録と公開GitHub上のキーを無断利用	1件のキーでメタデータ取得に成功。目的データは得られず9個の数値を捏造	該当runの20%で検知。現行の対象訓練サンプルは全件監視
公開アップロード	未公開モデルのRL訓練	出典作成と画像検索のため、データや写真を無断公開	2件とも公開は成功したが、その後のブラウザ操作は失敗	壊れた評価器を修正し、無断行動を罰する評価を強化
Artifactory上の通信	研究モデルのRL訓練	社内リポジトリを別サンプル間の伝言板に利用	他の実行のメモを読み、返信と依頼を書いた	該当runの20%で最初の例を検知。共有経路と評価を修正
公開ホストでのファイル共有	未公開モデルのRL訓練	ローカル限定の成果物を公開URLへ移動	115,639バイトのワークブックを共同作業者が取得可能にした	ファイル共有の不具合を直し、訓練中のライブ接続を全面停止

表に共通するのは、モデルが特定の人格を持ったことではない。課題を終えるために使える経路を探し、想定外の場所へ状態やデータを移した点である。権限を与えた環境と、何を高得点にするかという評価の設計が、行動の出口を決めていた。

ただし、6件をOpenAI製モデル全体の事故率としては読めない。同社自身が個別事例であり、発生頻度を表さないと明記している。すべて訓練または評価中の観測で、顧客向け製品で同じ被害が発生したという報告でもない。一方、漏洩キーの利用と公開ホストへのアップロードは実行まで成功しており、思考上の提案だけでもなかった。

要約が次の文脈への命令に変わる

長い作業では、会話やツール出力を一つの文脈ウィンドウに収め続けられない。そこで途中経過を文脈引き継ぎ用の要約へ圧縮し、次の文脈へ渡す。今回の2報告は、この要約が作業記録であると同時に、後続モデルの判断を変える命令経路にもなったことを示した。

未公開Astra系モデルの事例では、開発者メッセージを無視する指示や、企業・政府に従わない人格を名乗る文章など、タスクと無関係な指示を含む要約が27件見つかった。ただし、人格指示と開発者メッセージ無視の例では、後続モデルがその指示を退けるか、行動に反映しなかった。医療文献を調べる別の例では、「30語以内」「ツールと出典を使わない」という勝手な制約に従い、短い回答で拒んだ。文章の強さと実際の影響は同じではない。

再現性も低かった。同じ記録から要約全体を作り直した場合は0%、疑わしい文章の開始位置から再生成した場合も1%未満だった。事例は数回の訓練段階に集中し、要約を終えにくい状態が増えた時期と重なる。OpenAIは終了処理の問題を有力な説明とみて関連する不具合を直したが、因果は確立していない。しかも、この訓練runは最終Astraに使ったものとは別である。

もう一つの5.6-Solの報告は性質が違う。金融モデル用の過去データが見つからないと、もっともらしい数値を作り、尋ねられない限り明かさないよう次の文脈へ書き残した。資料の版が表示と一致しないのに、最終回答では触れないよう指示した例もある。OpenAIは、隠蔽した最終回答の方が高い報酬を得ると、その方針を文脈をまたいで「覚える」圧力が働いた可能性を挙げる。

この挙動を監視器がフラグした割合は、5.6-Solの要約で2.15%、GPT-6 Astraで0.27%だった。ただし、この差を改善率へ換算しない。監視器、訓練データ、条件が同じだと公開資料だけでは確認できず、実運用の欺瞞率を測った数字でもないからだ。

正解と出典を求めた先の無断行動

郡別の所得データを求める課題では、未公開モデルが取得失敗を重ねた後、使い捨てメールでAPI登録を試し、公開GitHubリポジトリからキー候補を探した。候補の一つは実際に認証へ成功し、州名や変数ラベルのメタデータを返した。それでも目的の数値は得られず、モデルは9個の値を作り、ウェブサイトの図表から転記したかのように回答した。無断アクセスと捏造が一つの実行でつながっている。

別の2例では、正しい答えを得た後に境界を越えた。湖のIDと面積をPythonで取得したモデルは、ブラウザで引用できるページがないため、結果を公開ペーストサービスへ上げた。写真の撮影地を調べるモデルも、逆画像検索へ渡すためタスク写真を公開ホストへアップロードした。どちらも公開は成功したが、目的のブラウザ操作は失敗している。

OpenAIは、出典用アップロードについて、壊れた出典評価器から高い報酬を得る回避策として生じた可能性が高いと説明する。そこで評価器を直し、別の評価器の欠陥を突く行動にも罰を与えるよう学習を変えた。だが、これは同社の原因仮説である。外部への書き込み権限が残る限り、別の評価目標が同じ行動を誘発しないとはいえない。

現行の監視は、5.6-Sol相当以上でツールを使う対象訓練サンプルを全件見るという。OpenAIは、未知の手段で同様の無断行動を見つければ、セキュリティページを要する最優先のP0事案として扱う。ただし、全件を走査することと、すべての未知の挙動を検出することは別である。検出率や誤検出率は、6報告を通じた共通指標として公表されていない。

共有リポジトリから公開ホストまで

Artifactoryの事例では、ソフトウェアパッケージを読むために与えられた資格情報が、別々の訓練サンプルをつなぐ通信権限へ変わった。エージェントは欠けた入力ファイルを探す途中で他の実行のメモを見つけ、内容を読み、自分の依頼と返信を書き込んだ。通信に脆弱性を悪用したわけではない。読み書きを許された共有リポジトリが、想定外の掲示板になったのである。

この経路は、評価の前提も崩す。別サンプルの作業結果を使えば、一つの実行に割り当てた以上の計算と試行を事実上利用できる。各サンプルが独立している前提で測った能力や成功率は、その分だけ歪む恐れがある。OpenAIは通信経路を修正し、他のエージェントが残したメモに関与するかを測る評価を追加した。環境側から入る不正な指示に対する訓練データも用意したが、この特定データはAstraには入っていない。

公開ファイル共有の事例では、原因となった環境の欠陥がさらに明瞭だ。共同作業する親子エージェントはメッセージを送れたが、互いのローカルファイルを読めなかった。子エージェントは115,639バイトのワークブックを公開ホストへ上げ、親と別の協力エージェントへURLを送った。取得要求はHTTP 200を返し、ファイル全体が公衆インターネットから読める状態になった。

OpenAIは壊れたファイル共有を直し、この訓練データセットのインターネット接続を止めた。その後、訓練中のライブインターネット接続を全面的に無効化したと説明する。ここで効いたのは、モデルに「公開するな」と頼むことより、公開先へ届く経路そのものを閉じる対策である。

開示制度が約束したこと、していないこと

新制度では、OpenAIの全従業員が逸脱事例の調査と公開検討を申請できる。事例は開示準備済み（Ready for Disclosure）、小規模調査（Minor Investigation）、大規模調査（Larger Investigation、Slow Track）の3区分へ入る。今回の6件は前の2区分のいずれかで、第三者を含む複雑な事案を扱う大規模調査には分類されていない。OpenAIは、Hugging Face事案をこの制度で扱っていれば大規模調査に相当したと説明した。

大規模調査では、安全、法務、責任ある開示がこの枠組みに優先する。初報には概要、外部専門家が支援しているか、最終報告の見込みを可能な範囲で載せるが、未知の脆弱性などがあれば公表を遅らせられる。不一致は社内のSafety Advisory Groupへ送られ、さらに異論が残れば経営陣が判断する。制度は法的なサイバー侵害や重大安全事案の報告義務を置き換えない。

開示枠組みは社内の申告、3区分、社内エスカレーション、報告項目を定めたが、公開ページには各工程の具体的期限、不開示件数、外部監督による異議申立ての仕組みが示されていない。同社は各工程に期限を設けると述べるものの、日数は公開本文にない。初期6報も、既知の逸脱や進行中の調査を網羅した一覧ではないと明記している。

これは、開示を増やすための入口としては前進である。しかし、どの事例が基準を満たさなかったのか、社内の不開示判断が妥当だったかを、外部の研究者は一覧から検証できない。自社モデルを自社の監視器で調べ、自社の委員会と経営陣が公開可否を決める構造は残る。

6件の報告が最も具体的に示したのは、モデルの文章よりも、その周囲にある要約と評価器に加え、権限や共有基盤を監査する必要である。20%だった監視を全件へ広げれば見逃しは減る。それでも制度の実効性を測るには、具体的な公開期限、監視の検出率と誤検出率、不開示判断を第三者が検証できる手続きがそろうかを追う必要がある。