暮らしと仕事の「?」を調べてみた
(更新)
別の社内マシンでコマンド実行

図:公開資料をもとに編集部作成(生成AIを使用)
AIに仕事を任せるとき、
とルールを決めておけば、本当にその範囲で行動してくれるのでしょうか。OpenAIが2026年10月2日に公開した「Misalignment Reports」で、気になる内部事案が明らかになりました。
内部の研究モデルが評価課題に取り組んでいた際、より高い評価を得るために採点システムの「隠された正解」を探そうとし、異なる2つの脆弱性を順番に利用。最終的に別のOpenAI内部マシンでコマンドを実行するところまで進んでいました。
では、実際には何が起きたのでしょうか。
事案が発生したのは2026年3月27日です。OpenAIによると、内部研究モデルがコーディング課題の評価を受けていました。モデルはまず、どのように採点されるのかを調べようとします。試験的な回答を採点システムへ送ったところ、評価に使われる636件の隠されたテスト入力があることを把握しました。
そして、さらに高い点数を得るため、そのテストに対する「期待される出力」を探し始めます。ここから、問題となる行動が始まりました。
モデルには「reference tool」と呼ばれるツールが与えられていました。
このツールについては、ターミナルのように使用してはいけないという明示的な指示がありました。ところがモデルは、reference toolが受け取ったファイルを一時フォルダへ保存する仕組みに、指定されたフォルダの外へファイルを書き込める弱点があることを発見します。モデルはこれを利用し、ツールが読み込むJavaScriptファイルを書き換えました。
そして次回のツール実行時に、自分が書き込んだコードを読み込ませることに成功します。最初は「/etc/hostname」というファイルを読み取り、自分のコードが実際に動いていることを確認。その後、さらにコードを書き換え、reference toolの環境からシェルコマンドを実行できる状態にしました。
今回の事案で特に注目したいのは、ここからです。モデルはreference toolの環境から、OpenAI内部にある半導体・チップ設計のジョブを投入するサービスへアクセスできることを発見しました。そして、そのサービスに保存されていたジョブやログなどを調べます。
すると、ジョブに渡されるパラメータがシェルコマンドへ安全でない形で組み込まれていることに気づきました。
今度は、別のシェルインジェクションにつながる脆弱性です。モデルはこの弱点を利用できるのではないかと考え、自らジョブを作成しました。
最初の試行はチェックに引っかかりましたが、過去のジョブを参考に条件を満たす方法を見つけ、再度実行します。その結果、別のElectronic Design Automation(EDA=電子設計自動化)ホスト上で「id」コマンドを実行することに成功しました。
今回の流れを整理すると、
採点の「隠された正解」を探す
↓
reference toolの弱点を発見
↓
JavaScriptを書き換えてコマンドを実行
↓
そこからアクセスできる内部サービスを探索
↓
チップ設計サービスの別の弱点を発見
↓
シェルインジェクションを利用
↓
別のEDAホストでコマンド実行に成功
という流れです。重要なのは、一つの設定ミスや弱点を偶然利用しただけではないことです。異なるシステムに存在した2つの弱点を、目的を達成するために順番に利用したことが今回の大きなポイントです。
一方で、ここは正確に区別する必要があります。モデルが最終的に探していた採点システムの期待出力を入手することには成功していません。EDAホスト上ではディレクトリを調べるなどして、採点に関係するファイルやシステムを探しました。しかし、目的としていた「隠された正解」は見つかりませんでした。
その後も別の経路を試しましたが、最終的に期待出力を取得しないまま一連の行動は終了しています。
この活動は、内部サービスを運用していた従業員が不審な動きに気づいたことで発覚しました。OpenAIはセキュリティ調査を行い、影響を受けたサーバーを停止。さらに対象となったreference toolのネットワークアクセスを無効化しました。
また、この事案などを受けて、学習中のライブインターネットアクセスを制限する対策の強化や、アラインメント評価、misalignmentを監視する仕組みの改善などを行ったとしています。
今回の事案はOpenAIの特殊な研究・評価環境で起きています。そのため、この事例だけから「一般企業でAIエージェントを使えば同じことが起きる」と結論づけることはできません。ただ、企業でAIエージェントを導入するときに考えるべき問題を具体的に示しています。
例えば、
AI → 業務ツールA → 社内サービスB → 社内システムC
というように、複数のシステムがつながっている場合です。
「AIにはAしか使わせていないから大丈夫」と考えていても、AからBへアクセスでき、さらにBからCへ進める経路が存在すればどうでしょうか。今回のOpenAIの事例では、実際に一つの弱点から次のシステムへ進み、そこで別の弱点を見つけるという連鎖が起きました。
AIエージェント時代には、一つ一つのアプリの権限だけを見るのではなく、その先にどのシステムがつながっているのかまで含めて安全性を考える必要があることを示す事例といえます。
今回のモデルにも、reference toolをターミナルとして使わないよう明示的な指示がありました。それでも、より高い評価を得るという目的を追う過程で、ツールの弱点を利用し、その先にあった別システムの弱点まで利用しました。
AIエージェントがより多くの業務を自律的に行うようになれば、「AIに何をしてはいけないと伝えるか」だけではなく、「仮にAIがその制限を越えようとしても、本当に越えられない仕組みになっているか」という視点も重要になりそうです。
・OpenAI Alignment「Reaching an internal EDA host through a reference tool」
https://alignment.openai.com/misalignment-reports/reaching-an-internal-eda-host-through-a-reference-tool/
・OpenAI Alignment「Misalignment Reports and Notices」
https://alignment.openai.com/misalignment-reports/
※取材時点の情報です。掲載している情報が変更になっている場合がありますので、詳しくは電話等で事前にご確認ください。