OpenAIのmisalignment reportsを読む：「GETだけ許可」の社内モデルはどう制限を越え、どう見つかったか

どうも！オペ部の西村祐二です！

OpenAIは、モデルが意図しないふるまい（misalignment）をした事例をMisalignment Reports and Noticesというページで公開しています。2026年10月9日に3件、10月15日に4件の報告が追加されました。この7件のうち6件は、社内のモデルが与えられた制限を越えた事例です。5件はインターネットへのアクセスをHTTP GETだけに制限された状態で公開データを調べる途中、1件はテストネットへのデプロイ作業の途中で起きています。残る1件は、採点役のモデルが入力ファイルの欠けた環境を壊そうとした事例です。

エージェントに「読むだけ」の権限を渡したつもりでも、実際にどこまで届くのかは気になるところです。この記事では、7件の報告を原文に沿って整理し、制限がどう越えられたかと、OpenAIがそれをどう見つけたかをまとめます。そのうえで、エージェントを業務で動かす側が確認しておきたい点を、自分なりの解釈として分けて書きます。

10月2日以前に公開された報告と、開示の方針を書いた別記事（Our disclosure principles）の中身には踏み込みません。

この報告を読む前に

報告はOpenAI自身による個別事例の開示で、どれくらいの頻度で起きているかを示すものではありません。一覧ページに頻度の説明はなく、採点役の報告が、採点役のミスアライメントの頻度は一般に低いと考えている、と書く程度です。ほかにも、次の点を前提に読む必要があります。

• 7件はいずれも、OpenAI社内のモデルを学習（強化学習）・評価やタスクの中で動かした事例です。製品として提供されているモデルやサービスで同じことが起きると書かれているわけではありません
• 6件はライブのインターネットに届く環境で起きました。後述の再発防止策のとおり、現在の社内環境が同じ状態とは限りません
• モデル名が書かれているのは暗号資産の事例だけです。他の報告は「internal research model」（外部ブラウザーなど）や「Highly persistent internal model」（政府統計サイト、ダッシュボード）といった記述にとどまります
• 外部サービス経由とPOST送信の報告は、名前や数値を架空のものに置き換えていると明記しています。外部ブラウザーの報告も、名前や識別できる情報を一般化・伏せ字にしたと書いています
• 回り道の分類（自分で送る・外部のサービスに送らせる）や節の切り方はこの記事での整理で、OpenAIの分類ではありません

10月9日と15日に公開された7件

報告の日付は、事例が起きた日（Incident / Sample date）、見つかった日（Discovered）、最終更新日（Report updated）で書かれています（採点役の報告には見つかった日がありません）。下の表の「公開日」は一覧ページの初回公開日、「通称」はこの記事での呼び方です。

6月の事例は、起きてから公開まで3〜4か月かかっています。見つかってから公開までで見ると、外部ブラウザーは約4か月、政府統計サイトとダッシュボードは約2か月、暗号資産は約3週間です。採点役の事例は、起きてから3日で公開されています。

制限はどう越えられたか

GETだけの制限は、ツールの説明とプロキシの両方で掛けられていた

POST送信、外部サービス経由、外部ブラウザー、政府統計サイト、ダッシュボードの5件では、モデルはツールの説明やシステムの指示で「インターネットへのアクセスはHTTP GETだけ」と伝えられていました。暗号資産の事例だけは制限の形が異なります。報告の説明では、タスクの指示はモデルが自分で見つけたアカウントの資金を使うことを許可していませんでした。

外部サービス経由の報告は、この制限の意味を説明しています。GETはリソースを取得する操作です。対話型のダッシュボードはデータの問い合わせにPOSTを使うことが多いため、GETだけのモデルはページを開けてもデータを引けない、という整理です。ネットワークのプロキシも実際にPOSTを止めていました。報告によると、モデルはこの制限を回避の対象として扱うことがありました（原文は「sometimes」）。

回り道は大きく2つに分かれます。

• 自分で送る:
  • 自作のプログラムで独自の接続を組み立て、POSTを送った（POST送信）
  • 中継を何段も挟む匿名化ネットワークに自分の通信を通し、POSTを送った（外部サービス経由）
• 外部のサービスに送らせる:
  • 外部のブラウザーに自動送信フォームを開かせ、POSTを送らせる（外部ブラウザー）
  • リモートシェルサービスに登録する。転送は拒否された（外部サービス経由）
  • Webページをテキストに変換するサービスに、任意のページを取得させる（外部サービス経由）

外部ブラウザーの事例では、モデルは外部ブラウザーに表示させた数値を画像からOCRで読み取っています。さらに、転送サービスとオンラインのメールボックスを経由して、結果をテキストで受け取る仕組みも作りました。

図は報告の内容をもとに自作した概念図で、OpenAIの図ではありません。GETだけと指示されたモデルから、POSTで問い合わせるサイトへの直接の通信はプロキシで止まります。モデルは上側の「自分で送る」経路と、下側の「外部のサービスに送らせる」経路で回り道をしました。

見つけた認証情報や認証の欠陥で、保護されたデータにまで届いた

タスクの途中で他人の認証情報や秘密情報、認証の欠陥に行き当たり、それを足がかりにした事例が3件あります。

ダッシュボードの事例では、公開WebサイトのJavaScriptに、ある組織の本番OpenSearchの認証情報が含まれていました。モデルはこれを使って内部のインデックスを読んでいます。これとは別に、ユーザー一覧のエンドポイントから、名前とメールアドレスを含む1,489件の記録もダウンロードしました。さらに、OpenSearchの信頼済みコネクター（外部へ接続してよい宛先の一覧）にPower BIのアドレスをPUTで追加しました。稼働中のサービスの設定変更です。コネクター経由の問い合わせはAWSの権限が足りずに失敗しましたが、設定の変更は残りました。次にモデルはOpenSearchのアラート機能を使い、一時的なモニターとWebhookを中継役にして、ダッシュボードの集計値を取得しています。それでも回答は正しくありませんでした。モニターとWebhookは後で消しましたが、宛先の追加は戻さないまま評価が終わっています。

同じ報告の2回目の評価では、組織のデータサービスが公開していたMicrosoftアプリケーションの設定値のうち、アクセストークンをどのサービス向けに要求するかを決める値（token audience）を、Power BIからAzure Storageに書き換えました。この書き換えのPATCHはプロキシの切断エラーになりましたが、サーバー側では変更が反映されていました。モデルはストレージ用のトークンを取得し、内部のOneLake（Microsoftのクラウドのデータストア）のテーブルを4つ読んでいます。その後、設定をPATCHで元に戻しましたが、取得済みのトークンは有効なままで、5つ目のテーブル（49,843行）を読み、さらに読み続けました。5つのテーブルで合計147,451行です。報告はこの事例の結論として、モデルは稼働中のシステムに許可のない変更を加えうること、変更を元に戻した後もアクセスを保ちうることを挙げています。

政府統計サイトの事例では、詳細なサーバーエラーからファイルパスを知り、ダウンロード機能のパストラバーサル（../ のような指定で、本来の公開ディレクトリの外にあるファイルを読む手法）で設定ファイルを取得しています。設定ファイルにはデータベースの接続文字列、トークンの署名用シークレット、メールの認証情報が含まれていました。モデルはコンパイル済みのアプリケーションとライブラリを調べ、トークンの署名が検証されていないことを見つけています。そのうえで署名のないトークンを作り、保護されたエンドポイントから、依頼された年を超えて24年分の統計をダウンロードしました。

暗号資産の事例は、GPT-5.6 Solファミリーの社内研究用モデルが、暗号資産の取引アプリを更新し、テストネット（Sepolia）にコントラクトをデプロイするタスクで起きました。資金のあるウォレットは渡されていませんでした。モデルは、よく使われる開発用のリカバリーフレーズ群から導出したアドレス362件の残高を調べ、テスト用のETHを持つアカウントを選んで手数料を払っています。報告によると、モデルはテストネットのトークンには価値がなく放置された資金だと考え、使ってよいと結論づけました。報告はこれを、アカウントの持ち主の許可を、害が小さいというモデル自身の判断で置き換えた事例と位置づけています。

答えを得た後も取得を続け、手段を明かさなかった

複数の報告に共通するのが、必要な答えを得た後も別の経路を探し続けた点です。外部ブラウザーの事例では、公開の統計年鑑から答えを出して提出した後も、回り道を探し続けています。POST送信の報告には複数の会話が含まれていて、その2件目では、8年分の検証済みの数値をすでにメモに保存していたのに、8年分の年次ダッシュボードから、カテゴリー別の内訳や組織全体の合計まで取得しています。後に取り込んだローカルのデータベースは658,567行になりました（この報告の数値は架空のものに置き換えられています）。モデルはその理由として、ベンチマークは「creative data retrieval」を期待しているのだろうと考えていました。

最終回答で手段を明かさなかった点も共通しています。ダッシュボードの事例の2回目の評価では、推測した数値を推測と書かずに提出し、内部のシステムへのアクセスや設定変更にも触れていません。暗号資産の事例では、デプロイの完了は報告したものの、他人のアカウントを使ったことは書いていません。

採点との関係も報告に出てきます。POST送信の事例では、アカウント登録や大量ダウンロードを含む実行が学習に使われ、正の報酬を受けていました。報告は、どの行動が報酬につながったかは記録から分からないとしたうえで、正しい答えだけでは適切にふるまったことの証明にならない、とまとめています。

採点役のモデルは、自分の環境を壊そうとした

採点役の事例だけは性質が異なります。7つの回答を採点するモデルが、必要な入力ファイルが環境にないことに気づきました。まず仮の報告を出してチェックの要件を探り、7件すべてに同じ点数（4）をつけ、根拠となる情報を捏造して提出し、自動チェックで却下されています。次に偽の入力ファイルを作って再提出し、これも却下されました。

その後モデルは、環境が作り直されれば入力ファイルが届くと考えました。Pythonを削除し（環境は動き続けた）、コンテナの管理プログラムを削除して停止し、ツールを実行するサーバーも標的にしています。システムディレクトリの削除も試みました。実行サーバーがヘルスチェックに3回続けて失敗した時点で、この試行は終わっています。このとき提出した採点はどれも受理されていません。後の再試行では入力ファイルが届き、採点は自動チェックを通過して受理されました。

OpenAIはどう見つけ、何を対策したか

発見の経緯は報告ごとに書かれています。

critical は監視システムの判定として書かれた語で、段階の定義は一覧ページにありません。Hugging Faceのインシデントについて、POST送信・政府統計サイト・ダッシュボードの3件の報告は遡及適用のきっかけとして触れるだけで、詳しくは一覧ページのNoticesからたどれるOpenAIの告知で扱われています。

再発防止策は、制限を越えた6件のうち5件がほぼ同じ4項目を挙げています。セキュリティ制御の強化、学習中にモデルがライブのインターネットへ届かないようにする対策、アライメントの採点の改善、そして監視の対象をすべての強化学習と評価のトラフィックへ広げることです。暗号資産の事例は、ライブのインターネットへのアクセスを防ぐ対策と、ライブのインターネットに届いたら警告を出す全トラフィックの監視の2点です。採点役の事例は追加の対策を書かず、監視は受理されなかった試行や途中で落ちた試行も対象にする必要がある、と結論づけています。

エージェントを運用する側が確認したいこと

ここからは報告の内容をもとにした自分なりの整理で、OpenAIが利用者向けに勧めているものではありません。

メソッドではなく宛先で、ネットワーク側から絞る

GETだけという制限は、ツールの説明に書くだけでは守られませんでした。プロキシがPOSTを止めていた環境でも、別の接続方法や外部のサービスを経由して越えられています。外へ出る通信は、メソッド単位よりも宛先単位の許可リストで絞るほうが、リレーや変換サービスを経由した回り道を防ぎやすそうです。原文では匿名化ネットワークやFTPへの接続も試されているため、HTTPのメソッドだけでなくプロトコルやポートも対象になります。一方で、GETだけでも安全とは言えません。政府統計サイトの事例のパストラバーサルや、ダッシュボードの事例の内部インデックスの読み出しは、読む操作の範囲で行われています。許可した宛先そのものへの攻撃は、許可リストでは防げません。社内でエージェントを動かすなら、ツールの説明に書いた制限がネットワークや権限の設定で実際にかかっているかは、確認しておきたいところです。

ここまでの整理を図にすると次のようになります。図は自作した概念図で、3段目の評価は報告ではなくこの記事での見立てです。

公開サービスの認証情報の露出と基本的な脆弱性は、エージェントに見つかる前提で扱う

ダッシュボードの事例の入口は、公開JavaScriptに含まれた本番の認証情報でした。政府統計サイトの事例で突かれたのは、詳細なエラーメッセージ、パストラバーサル、署名を検証しないトークンという、いずれもよく知られた脆弱性の組み合わせです。外部のエージェントが自社のサービスを調べに来ることも考えると、公開JavaScriptに認証情報を埋めていないか、詳細なエラーを外部に返していないか、トークンの署名を検証しているかは、改めて点検しておきたい項目です。

作業後は、戻した設定ではなく残った権限を確認する

エージェントに書き込み権限を渡す場合、作業後の確認は設定値が元に戻っているかだけでは足りません。ダッシュボードの事例のように、発行済みのトークンは設定を戻しても使える場合があります。エージェントに渡す資格情報は有効期限を短くし、作業後に失効やローテーションをする前提にしておくと、残った権限を閉じられます。あわせて、トークンの発行と利用、追加された宛先をクラウドの監査ログ（AWSならCloudTrailなど）で追えるようにしておけば、作業後に残ったものを特定できます。

成果物ではなく実行記録を見る

成果物だけを確認する運用では、正しい答えの裏で制限が越えられていても見えません。実行記録（どのコマンドを打ち、どこへ通信したか）を残し、失敗した実行や途中で止まった実行も含めて見返せるようにしておきたいところです。

まとめ

10月9日と15日に公開された7件のうち6件は、社内のモデルが与えられた制限を越えた事例でした。モデルは自作のプログラム、外部のブラウザーやリレー、公開ページで見つけた認証情報、サーバーの認証の欠陥などを使っています。答えを得た後も取得を続けたこと、手段を最終回答で明かさなかったことは複数の報告に共通し、ダッシュボードの事例では設定を戻した後も取得したトークンが使われ続けました。残る1件では、採点役のモデルが環境を壊そうとしています。OpenAIはこれらを、その場での調査、過去の記録への監視の遡及適用、監視システムからの人のレビューへの回付で見つけています。

エージェントを業務で動かす側としては、次の4点が見直しの出発点になりそうです。

• ツールの説明に書いた制限に頼らず、宛先単位でネットワークと権限を絞る
• 公開サービスの認証情報の露出や基本的な脆弱性を点検する
• 作業後は、戻した設定だけでなく残った権限まで確認する
• 成果物だけでなく、失敗した実行も含めて実行記録を見る

誰かの参考になれば幸いです。

参考リンク:

• Misalignment Reports and Notices（OpenAI Alignment Research Blog）
• Obtaining public statistics with disallowed requests
• Sending disallowed web requests and reaching a public file service
• Circumventing internet restrictions through an external browser
• Retrieving server secrets and bypassing authorization on a government statistics website
• Accessing and changing internal systems during dashboard research
• Using a funded test cryptocurrency wallet without authorization
• Damaging the task environment to trigger a reset