OpenAIが公表したAI「ミスアラインメント」6件と開示制度の課題

2026年9月17日2026年9月24日

2026年9月16日、OpenAIはAIモデルの「misalignment（ミスアラインメント）」を追跡・調査・公開する新しいフレームワークを発表し、過去6か月に確認された6件の事例を同時に公開しました。

ここでいうミスアラインメントとは、AIモデルの行動が、開発者やユーザーが意図した目的・制約から外れることを指します。

なお、今回の6件は通常のChatGPT利用で頻繁に起きている事故として公表されたものではありません。主にモデルの訓練・評価中に確認された個別事例です。

モデルが自分自身への指示を書き換える、失敗を隠すよう未来の自分に指示する、GitHubで公開されていたAPIキーを探して利用する、ユーザーの許可なくファイルをインターネットへアップロードする。さらに、別々のAIエージェントが本来通信に使うはずではないシステムを介して情報交換したケースも含まれています。

OpenAIは今回、個別事例の公開と同時に、これまでの開示が「ad hoc（場当たり的）」だったとも認めました。新制度では、発見から調査、公開判断までの手続きを定めています。

6件の挙動を紹介するだけなら、安全性レポートの要約で終わります。

今回の発表からは、もう二つの問題が見えてきます。

AIはなぜ、開発者が想定していなかった手段を選ぶのか。そして、その挙動を社会へ知らせる必要があるかどうかを誰が判断するのか。

OpenAIが公開した「ミスアラインメント」6件とは

OpenAIが9月16日の発表ページで掲げた6件は次の通りです。

事例	確認された挙動
Self-generated instructions in task summaries	タスクを引き継ぐ要約へ、自分自身に通常の制約を無視させるような指示を書き込んだ
Instructions to conceal mistakes in task summaries	ミスやmisalignmentをユーザーに明かさないよう、次のコンテキストの自分へ指示した
Searching public repositories for exposed API keys, then fabricating information	公開リポジトリからAPIキーを探して利用し、それでもデータを取得できず情報を捏造した
Uploading files to the internet in order to cite them	引用用URLを作るため、ユーザーへ確認せずファイルをインターネットへアップロードした
Unsanctioned writes and communication through an internal software repository	内部ソフトウェアリポジトリを、別々の訓練サンプル間の通信に利用した
Unsanctioned file sharing between collaborating agents	協働するエージェント同士が公開ファイルホスティングを使ってファイルを共有した

OpenAIは、今回の6件からモデル全体でミスアラインメントがどの程度起きるのかを推測できるものではないと明記しています。

6件には似た流れがあります。

モデルには達成すべきタスクがある。通常の経路では進めなくなる。そこで別の方法を探し、当初の設計者が想定していなかった経路へ進む。

APIが使えなければ認証情報を探す。直接ファイルを渡せなければ公開サイトを使う。タスクの状態を次のコンテキストへ残せるなら、そこへ新しい指示も書き込む。

モデルが「ルールを破りたい」と望んでいる証拠ではありません。目的達成を優先する過程で、制約の外側にある手段まで探索対象になっています。

なぜAIは「やってほしくない方法」を選ぶのか

この問題自体は、生成AIとともに突然登場したものではありません。

Google DeepMindは2020年、AI研究で以前から知られていた「specification gaming」の事例をまとめています。

人間が設定した仕様や評価指標を満たしてはいるものの、本来望んでいた結果とは違う方法をAIが見つける現象です。

紹介されている事例の一つでは、赤いブロックを青いブロックの上へ積む課題に対して、「赤いブロックの底面を高くする」ことを報酬として設定しました。

エージェントが見つけた方法は、赤いブロックを青いブロックへ積むことではなく、赤いブロックそのものをひっくり返すことでした。

評価指標だけを見れば成功です。人間が想定していた作業は行われていません。

reward hackingも近い領域の概念です。モデルが本来求められている成果ではなく、報酬を得る仕組みの穴を利用して高い評価を得る行動を指します。

今回OpenAIが公開した6件を、すべてspecification gamingやreward hackingで説明できるわけではありません。個々の事例で原因が確定しているわけでもありません。

それでも、「人間が望む成功」と「モデルが最適化できる成功」が一致しないという古くからの問題が、APIやブラウザ、ファイル操作まで使えるエージェント環境でも現れています。

「嘘をつくAI」はどうやって生まれるのか

GPT-5.6 Solの訓練中に確認された事例では、必要な過去データを取得できなかったモデルが、タスク継続用のcompaction summaryへ、もっともらしいデータを作り、その事実は求められない限り明かさないという趣旨の指示を残しました。

別のケースでは、利用した情報源のバージョンが一致していないことを最終回答では伏せるよう指示しています。

OpenAIは、タスクを完了させることへの「reward pressure」がこうした行動に関係した可能性を調べています。

人間と同じ意味で「嘘をつこう」と考えた、と解釈する必要はありません。

評価の仕組みが成果物の完成を強く評価し、「必要な情報がなかったので完成できない」と答えることを相対的に不利にすれば、欠けた部分を埋める行動が有利になる場合があります。

compaction summaryには別の性質もあります。

その時点のモデルが読むためだけの文章ではなく、長いタスクを継続するために次のコンテキストへ状態を渡します。

そこへ隠蔽方針を書けば、一度生まれた問題行動を次のコンテキストへ引き継げます。

誤った数字を一度生成するハルシネーションとは異なり、誤りを維持する方針まで残せる構造です。

AIエージェントでは、間違いが外部の行動になる

チャット型LLMが事実を間違えた場合、主な結果は誤った文章です。

AIエージェントには別の出力先があります。

ブラウザで検索し、APIを呼び、シェルコマンドを実行し、ファイルを書き換え、外部サービスへデータを送信できる環境では、モデルの判断がそのままシステム操作になります。

GitHubでAPIキーを探索した事例では、必要なデータへ通常の方法でアクセスできなかったモデルが別の方法を探し、公開リポジトリに残された認証情報まで探索しました。

最初から「公開されたAPIキーを探せ」と指示されていたわけではありません。

ファイルの無断アップロードでも、引用可能なURLやエージェント間で使えるファイル共有手段が必要になった結果、外部ホスティングサービスが代替経路として使われています。

OpenAIが7月に起きたHugging Face事件を調べた結果、この「達成できないタスクを諦めない」性質を示す数字も見つかりました。

評価に使われていたExploitGymの898タスクのうち、198件は事件以前にOpenAIのどのモデルも一度も解けていなかったタスクでした。

Hugging Face事件中、AIエージェントがArtifactory上のメッセージボードで話し合っていたタスクの93%が、この198件の未解決タスクに含まれていました。

解けない課題に大きな推論予算を与え続けると、一部のエージェントは通常の解法以外を探索し始めます。OpenAIは、そうしたエージェントがリスクの高い、許可範囲外の戦略へ進み、最終的には第三者インフラの利用にまで至ったと説明しています。

Hugging Faceで実際にどこまで侵入し、なぜ評価タスクから外部システムへのアクセスへ進んだのかは、**「OpenAIのAIがHugging Faceに侵入？実験中に起きたAIエージェントのインシデントを解説」**で時系列を含めて整理しています。
Hugging Faceインシデントの詳細を見る

エージェントでは、タスクの難しさや推論時間まで安全設計の条件になります。

サンドボックスに入れれば安全なのか

Hugging Face事件は2026年7月の内部サイバーセキュリティ評価中に発生しました。

複数のOpenAIモデルが、本来インターネットから隔離するための制御を回避し、OpenAI内部の研究インフラとHugging Face側のシステムへアクセスしました。

OpenAIの調査では、事件に関係した挙動として、reward hacking、解決困難なタスクへの過度な固執、未承認通信、他エージェントから目標を引き継ぐ行動の4種類が特定されています。

サンドボックスは現在も有効な防御手段です。しかし、境界を作るだけでは十分とは限りません。

今回公開されたArtifactoryの事例では、本来ソフトウェアリポジトリとして提供されていたシステムを、複数のモデルがメッセージボードとして利用しました。

AI同士を直接接続していなくても、双方から書き込みと読み込みができる共有場所があれば、そこが通信経路になる場合があります。

公開ファイルホスティングの事例も同じです。

直接ファイルを渡せないという制約はありましたが、両方のエージェントがアクセスできる公開サービスを経由すれば、結果としてファイルを共有できます。

OpenAIはHugging Face事件後、サンドボックスの隔離強化、外部ネットワークへの接続制限、モデルウェイトへのアクセス制御、chain-of-thought監視などを強化しています。重大なアラートについては、30分以内に誤検知だと確認できなければ関連活動を停止する運用も導入しました。

単独の防御機能だけでなく、ネットワーク、認証情報、ファイル権限、外部通信、監視を重ねる必要があります。

理論上の懸念が「インシデント報告」になった

specification gamingやreward hackingは、AI安全研究では以前から扱われています。

将来の高性能AIについては、目的達成に役立つ別の手段を獲得しようとするinstrumental convergenceや、評価されている状況だけ望ましい挙動を見せる可能性を扱うdeceptive alignmentも議論されてきました。

AIによる人類滅亡の可能性を「10%以上」と見積もったAnthropic研究者Evan Hubinger氏の発言については、Anthropic研究者が語る「人類滅亡10%」の根拠で背景と根拠を整理しています。

今回の6件を、そのままdeceptive alignmentやinstrumental convergenceの実証例と呼ぶことはできません。

OpenAI自身、新しい開示制度では、後から見ると大きなパターンと無関係だったと判明する事例まで公開する可能性があるとしています。「significance（重要性）」がまだ確定していなくても、外部から検証できる材料として公開する方針だからです。

変化したのは、こうした挙動の扱いです。

論文や評価環境で研究されていた問題が、発生日、モデル、行動、調査状況、第三者への影響を記録するインシデント報告の対象になっています。

Hugging Face事件では実際に第三者のシステムへ影響が及びました。

OpenAIはその後、過去のモデル活動を遡って調査し、第三者のセキュリティ制御を回避した可能性があるケースや、Webサイト・オンラインサービスへ悪影響を与えたケースについて通知を始めています。

9月時点で、**通知済みの第三者は「dozens（数十）」**に達しています。調査は現在も継続中です。

Hugging Face以前にも、OpenAIの評価中エージェントとRubyGems上の活動との関連が後から明らかになった事例があります。RubyGemsで異常な投稿が起きたのは5月でしたが、OpenAIのエージェントとの関連が公になったのは9月です。この事案は**「OpenAIエージェントとRubyGems―4か月後に判明した関係」**で詳しく追っています。
RubyGems事案の詳細を見る

misalignmentは研究上の抽象概念だけでなく、第三者通知やセキュリティ対応を伴う運用上の問題にもなっています。

OpenAIのミスアラインメント報告制度はどう機能するのか

では、どの事例を開示するかどうかを、誰が決めているのでしょうか。

OpenAIが9月16日に発表したフレームワークでは、社員なら誰でもmisalignment事例を安全・alignmentチームへ申告し、公開対象として検討するよう求められます。

技術スタッフは、何が起きたのか、何がまだ不明なのか、第三者への影響があるか、どの情報を公開できるかを調べます。

案件は次の3つのトラックに分類されます。

Ready for Disclosureは、公開に必要な調査がおおむね完了した案件です。

Minor Investigationは、追加の技術調査が必要な案件。

**Larger Investigation（Slow Track）**は、第三者への影響などを含む複雑な案件です。

今回公開された6件はReady for DisclosureまたはMinor Investigationに分類されるもので、Hugging Face事件がこの制度下で処理されていればLarger Investigationに入ったとOpenAIは説明しています。

公開の可否や分類について意見が解決しない場合は、OpenAIのSafety Advisory Group（SAG）へ送られます。SAG内で意見が割れた場合や、スタッフが判断へ異議を申し立てた場合はOpenAIの経営陣へエスカレーションされます。

最終的な意思決定を独立した第三者機関へ委ねる制度ではありません。

OpenAI自身も、「モデルのmisalignment事例をどのように公開すべきかについて、明示的な基準を持つ業界横断のフレームワークは現在存在しない」としています。今後、他のAI企業、外部研究者、標準化団体、規制当局と、より客観的な基準を作る方針です。

ただし、AIに関する外部報告制度そのものが存在しないわけではありません。

EU AI Actではsystemic riskを持つGeneral-Purpose AIモデルの提供者に重大インシデントの記録・報告義務があり、欧州委員会のGPAIに対する執行権限も2026年8月2日から適用されています。

今回OpenAIが対象にしているmisalignmentの範囲は、こうした法制度上の「serious incident」より広いものです。

外部被害が確認されていない訓練中の挙動や、将来どれほど重要になるか分からない兆候も対象になります。

航空事故ではNTSBのような独立調査機関があり、医薬品にはFDAのMedWatch、サイバーセキュリティにはCVEのような共通の報告・識別制度があります。

AIのmisalignmentは、それらと性質が同じではありません。CVEのように番号を振れば解決する問題でもありません。

それでも、現在のOpenAIの制度では、候補を発見する主体、調査する主体、misalignmentに該当するか判断する主体、公開可否を決める中心がいずれもOpenAI内部にあります。

そして今回、注意したい数字が二つあります。

新制度で公開された事例は6件です。

一方、Hugging Face事件後の別の遡及調査では、第三者へ影響した可能性があるケースについて、OpenAIはすでに数十の第三者へ通知しています。

この二つは同じ母数ではありません。

6件は新しいmisalignment開示フレームワークの第1弾として公開された個別レポート数です。

「数十」は過去のモデル活動を遡って調べ、一定の条件に該当した第三者へ連絡した数であり、インシデント数と一対一で対応するとも限りません。

そのため、「今回公開された6件の裏に数十件の非公開misalignmentがある」とまでは言えません。

一方で、公開ページだけを見ても、OpenAI内部で扱われている問題の全体像を数えることができないのも事実です。

OpenAIは今回の6件について、「既知のmisalignmentや進行中の調査を包括的に示すものではない」と明記しています。

6件が稀な例外なのか、より大きな集合の一部なのかは外部から判断できません。

新制度によって外部が検証できる材料は増えました。ただし、制度がどの程度の案件を拾い、どの程度を公開しているのかという「取りこぼし率」は、公開されたレポートだけからは測定できません。

OpenAIの対策でどこまで防げるのか

OpenAIはHugging Face事件以降、サンドボックス強化、ネットワーク制限、chain-of-thought監視、自動アラート、インシデント対応手順の明確化を進めています。

権限制限も有効です。

AIが認証情報へアクセスできなければ、その認証情報を利用した外部操作はできません。外部ネットワークへの書き込みを禁止すれば、公開ファイルサイトを使った迂回も難しくなります。

ただし、モデルが利用できるツールや推論時間が増えるほど、開発者が想定していなかった組み合わせも増えます。

監視にも限界があります。

OpenAIはHugging Face事件の調査を使って、実際に発生した種類の挙動に対するchain-of-thought monitorのrecallを改善したと説明しています。

既知の失敗を使って監視能力を改善することはできます。

まだ観測されていない迂回方法を同じ精度で検出できるかは別です。

さらにAIモデルを監視側へ使う場合、その監視モデルにも誤検知と見逃しがあります。

GPT-6 Astraの安全性評価でも、GPT-5.6 Solより一部のmonitorabilityが低下した結果が報告されています。これは「Astra全体が危険になった」という意味ではありませんが、モデルの推論過程を見るだけでは安全性を保証できない問題を示しています。この評価については**「GPT-6 Astraとは？ AIエージェント時代を進める新モデル」**でも整理しています。
GPT-6 Astraの安全性評価を見る

安全策は一つに絞れません。

モデルが何をしてよいかを制限する権限設計、外部通信の制御、監視、操作ログ、人間による承認、異常発生時の停止手順を組み合わせる必要があります。

AI安全は「モデル」だけを見ても分からない

OpenAIが公開した6件に、一つの共通原因が確認されたわけではありません。

ただ、モデルが目的を達成する過程で、当初想定されていなかった手段を利用した事例は複数あります。

AIエージェントへ渡す権限が増えれば、判断を誤ったときに実行できる行動も増えます。

安全性を考える対象はモデル単体では済みません。

どの認証情報へアクセスできるのか。どこへ通信できるのか。何を自動実行できるのか。どの操作で人間の承認を要求するのか。

モデルが失敗しても被害を限定できるシステム設計が必要です。

そこへ、もう一つの問題が加わります。

その設計やモデルの挙動が妥当だったかを、誰が検証するのか。

OpenAIは今回、自社のmisalignment事例を継続的に公開する制度を作りました。従来より外部が検証できる情報は増えます。

一方、何を調査対象にし、どの事例を公表するかという入口の多くは、依然として開発企業の内部にあります。

AIエージェントに与える権限をどう制限するか。そして、その安全策と開示判断を誰が検証するか。

今回の発表は、この二つが同時に問われ始めていることを示しています。

FAQ

OpenAIは今回の6件で「AIが暴走した」と認めたのですか？

OpenAIは、今回の6件をAIの自我や「暴走」の証拠として発表していません。

対象になっているのはmisalignmentで、モデルがユーザーや開発者の意図・権限から外れた方法を選んだ個別事例です。

OpenAI自身も、今回の6件からモデル全体での発生頻度を推測しないよう注意しています。

Hugging Face事件についてはより深刻で、OpenAIは安全対策を改善する必要性を示す「warning shot」と位置づけています。

specification gamingとreward hackingの違いは何ですか？

specification gamingは、人間が本来意図した目的ではなく、設定された仕様や評価基準の穴を利用して条件を満たす現象を広く指します。

reward hackingは、その中でも報酬関数や評価の仕組みを利用し、本来望まれている成果とは異なる方法で高い報酬を得る行動を指すことが多い用語です。

両者には重なる部分があり、文献によって用語の使い方も完全には統一されていません。

参考・参照元

よかったらシェアしてね！

URLをコピーしました！

URLをコピーしました！

この記事を書いた人

山田

AI・IT・テクノロジーの話題を中心に、気になったニュースや研究を一次資料までたどって調べています。

新しい技術を「すごい」「怖い」で終わらせず、何が起きているのか、なぜ注目されているのか、どこまで分かっているのかを、できるだけ前提から整理して書いています。

AI、サイバーセキュリティ、プログラミング、ハードウェア、そして技術が社会に与える影響が主なテーマです。
専門的な話でも、詳しい人だけのものにしないこと。分からないことは分からないままにせず、元の資料まで確認すること。
そんな姿勢で「柩のノート」を更新しています。