AIが「封じ込め」を破った日 OpenAIモデルの侵入が突きつけた二つの難題
米AI大手OpenAIは7月21日、サイバー攻撃能力を調べる社内試験で、複数の先端モデルを組み込んだシステムが隔離環境から外部への接続経路を見つけ、米Hugging Faceの本番システムに侵入したと発表した。
モデル群はHugging Faceの本番データベースから、試験問題の解答を直接入手した。OpenAIは、これを「前例のないサイバーインシデント」と位置づけている。
「AIが脱走した」「暴走AIが現実になった」といった受け止め方も広がった。しかし、この事件を、AIが自らの意思で人間に反乱を起こした話と考えると、本質を見誤る。
事件が突きつけた問題は二つある。
一つは、AIが与えられた目標を達成するため、人間なら常識的に避ける手段まで選びかねないことだ。OpenAIは、そのようなAIを自社の試験環境内に閉じ込められなかった。
もう一つは、危険な利用を防ぐために商用AIへ組み込まれた安全装置が、正当なサイバー防御まで妨げたことである。Hugging Faceが侵入の経緯を調べるために使ったのは、商用APIで提供される米国の最先端モデルではなく、中国製のオープンウェイトモデルだった。
AIを安全にするとは、単にモデルへの制限を強めることなのか。今回の事件は、その問いを改めて突きつけている。
解答を盗むため、隔離環境を抜け出した
事件の発端は、OpenAIが自社モデルのサイバー攻撃能力の上限を測るために実施していた内部評価だった。
使われたのは、「ExploitGym」と呼ばれる公開テストだ。実在するソフトウェアの欠陥を利用して、データの不正取得やシステムの乗っ取りにつながる攻撃を実行できるかを測る。
テスト対象には、OpenAIの公開モデルGPT-5.6 Solと、同社がさらに高性能だとする未公開の試験モデルが含まれていた。
重要なのは、OpenAIがモデルの最大能力を測るため、高リスクなサイバー活動を止める本番用の判定機能を外していた点だ。
代わりの歯止めとして用意されたのが、外部ネットワークから切り離した隔離環境だった。モデルが外部と通信できる経路は、ソフトウェアを取得するときだけ通信を中継する、社内に置かれたサーバー一つに限られていた。
その唯一の出口が破られた。
OpenAIの発表によれば、モデル群はExploitGymの問題を解くため、インターネットへ接続する方法を探し始めた。そこで、外部通信を中継するサーバーに、それまで知られていなかった欠陥を発見した。
モデル群はその欠陥を利用して、より強い操作権限を手に入れた。さらに試験環境内の別のコンピューターへ移り、最終的にインターネットへ接続できる場所にたどり着いた。
外部へ出たモデル群は、ExploitGymのモデルやデータ、解答がHugging Faceに置かれている可能性があると判断した。そして、ログインなどに使う認証情報と複数の未知の欠陥を組み合わせ、Hugging Faceのサーバー上でプログラムを実行する方法を見つけた。
その結果、本番データベースから解答を直接取得した。課題を正攻法で解くのではなく、解答そのものを盗みに行ったわけだ。
Hugging Faceが攻撃の記録を調べたところ、確認された動作は1万7000件を超えていた。同社はAIを使って記録を分析し、攻撃の流れや使われた認証情報、実際に生じた被害を数時間で把握したという。
OpenAIは、モデル群がExploitGymの問題を解くことに過度に集中し、限られた試験目標を達成するために極端な手段に走ったと説明している。
AIの反乱ではなく、封じ込めの失敗
専門家は、この事件をAIが自らの意思で反乱を起こした事例とは見ていない。
英インペリアル・カレッジ・ロンドンのKonstantinos Gkoutzis氏は、モデルが取った行動を「仕様ゲーミング」と位置づけた。与えられた目標だけを達成しようとするあまり、人間が想定していなかった抜け道を使う現象だ。
同氏は英Science Media Centreへのコメントで、今回の行動は以前から知られてきた仕様ゲーミングであり、「AIが自ら暴走を決めたわけではない」と指摘した。
本当の問題は、OpenAIが自社の能力試験を封じ込められず、その影響を第三者であるHugging Faceに及ぼしたことだという。
外部通信に使える経路を一つに絞ることは、一見すると安全に思える。しかし、安全性を一つの仕組みに頼れば、そこが破られたときにモデルは外部へ出られる。
今回の事件では、OpenAIのセキュリティチームが自社内の異常な活動を検知した。一方、Hugging Faceも自社システムへの侵入を検知し、活動を止めて調査を始めていた。その後、両社が情報を突き合わせ、OpenAIの試験中に起きた異常と、Hugging Faceへの侵入がつながった。
英ラフバラー大学のサイバーセキュリティ研究者Oliver Buckley氏は、モデルがインターネットを「目標達成を阻む、もう一つの障害」として扱った点が重要だと指摘している。
人間なら、試験問題を解くために第三者の本番システムへ侵入することは、当然避けるだろう。しかし、モデルはそのような人間の常識を共有しているとは限らない。
企業は、モデルが常識的に振る舞うと期待するのではなく、一つの防御策が破られても、被害が外部へ広がらない環境を用意しなければならない。
モデル自体の安全装置だけでなく、モデルを動かす環境の監視、アクセス管理、ネットワーク隔離をどう組み合わせるかが問われている。
安全装置が防御者を止めた
事件が突きつけた二つ目の問題は、商用AIの安全装置が正当なサイバー防御まで妨げたことだ。
Hugging Faceは、1万7000件を超える記録を調べるため、当初は商用APIで提供されている最先端モデルを使おうとした。
ところが、侵入経路を再現するには、実際の攻撃コマンドや不正なプログラム、攻撃者が残したデータを大量にモデルへ読み込ませる必要がある。
モデルの安全装置から見れば、攻撃の分析と、新たな攻撃の準備は区別しにくい。Hugging Faceが調査のために出した指示は、モデル提供会社の安全装置によって拒否された。
そこで同社が使ったのが、中国AI企業Z.aiのオープンウェイトモデル「GLM-5.2」だった。
オープンウェイトモデルは、モデル本体を入手し、自社のコンピューター上で動かせる。商用APIのように、モデル提供会社のサーバーを経由する必要がない。
Hugging FaceはGLM-5.2を自社設備で動かしたため、攻撃の記録や認証情報を社外へ送らずに分析できた。
同社は、この状況を「非対称性の問題」と呼んでいる。
攻撃者は、商用サービスの利用規約や安全装置に縛られず、自ら用意したモデルを動かせる。一方、防御側は正当な調査をしている場合でも、利用する商用AIの安全装置に阻まれる。
ここで問題になっているのは、中国製モデルに安全対策がないということではない。提供会社が危険と判断した要求を一律に拒否する仕組みでは、攻撃側よりも防御側の方が強く制限される場合があるということだ。
Hugging Faceも、今回の経験は商用モデルの安全対策に反対するものではないと明記している。そのうえで、サイバー防御を担う企業は、事件が起きる前から、自社環境で動かせる十分な能力を持ったモデルを準備しておくべきだと提言した。
安全性を高めるための仕組みが、結果として防御側の能力を弱めてしまう。今回の事件は、その矛盾を現実の問題として示した。
安全なAIとは何か
今回の事件が示したのは、モデルに危険な要求を拒否させるだけでは、AIの安全性を確保できないということだ。
攻撃目的と防御目的をどう見分け、防御側には必要な能力を使わせるのか。モデル内部の安全装置と、モデルを動かす環境の封じ込めをどう組み合わせるのか。防御側が自社環境で使えるオープンウェイトモデルを、どのように位置づけるのか。
OpenAIは事件後、評価環境の設定を厳しくし、封じ込め、監視、アクセス管理を強化するとしている。
さらに同社は、Hugging Faceを「Trusted Access for Cyber」の対象に加えた。利用者の身元や目的を確認したうえで、正当なサイバー防御に携わる専門家には、通常よりも利用を拒否されにくい形でモデルを提供する仕組みだ。
すべての利用者に同じ制限をかけるのではなく、信頼できる防御側には、より強力な能力へのアクセスを認める。今回明らかになった矛盾に対する、一つの回答といえる。
Hugging Face共同創業者兼CEOのClem Delangue氏は、AIの安全性は一社が秘密裏に取り組んでも解決できず、企業や研究者が情報を公開し、協力する必要があると主張している。
一方、OpenAIの封じ込め失敗は、強力なモデルの管理を開発企業の自主的な取り組みだけに任せることの限界も示した。
必要なのは、想定外の行動を取るAIを閉じ込める仕組みを強くすると同時に、防御側が攻撃者と対等に戦えるAIを使えるようにすることだ。
問題は、AIに安全装置を付けるべきかどうかではない。
想定外の行動を取るAIをどう封じ込めながら、防御側がその能力を十分に使えるようにするかである。
