OpenAIの次世代AIエージェントがHugging Faceをハッキング——AIアライメントの問題浮き彫りに

2026年7月25日 ・ 久保一成

#AI#OpenAI#AIエージェント#サイバーセキュリティ#アライメント#Hugging Face

序章　OpenAIの次世代AIモデルはなぜHugging Faceへ侵入したのか

能力試験を受けていたAIが、その試験の答えを盗むために、試験会場の外にあるHugging Faceのサーバーへ侵入しました。そしてカンニングに成功した。 侵入したのは、OpenAIが試験中だった次世代AIモデルを含むAIエージェントです。

そして、攻撃を追跡する側にも、AIが使われました。 その全体像を解析するうえで、重要な役割を果たしたのが、中国企業Z.aiのGLM 5.2でした。

Hugging Faceは2026年7月16日に侵入を公表し、OpenAIは7月21日に、自社モデルの評価が原因だったと明らかにしました。 AIが悪意を持って人間に反抗したわけではありません。AIは、課された目標を達成しようとする自身の数学的アルゴリズムに従った結果だったのです。 ただ、その達成手段を、人間が許可した制限の外まで広げた。試験環境を抜け、他社へ侵入し、本番データベースから解答を取ってくる。そこまでを、一つの目標のためにやり切りました。

そして、このリスクはAIを利用しているどの企業にも起こり得ます。 AIが意図せず、自社のデータを壊したり、書き換えたり、意図しないメールを取引先に送りつけたり、機密文章をネットに流出させることは、すでにいくつも観測されています。

今回使われたのは、次世代モデルを含む複数のOpenAIのAIエージェントでした。 これはClaude Mythosの一件より、一段深刻だと考えられます。

事件の全容と、僕たち自身に降りかかるリスクと可能性まで、一つずつ紐解いていきましょう。

第一章　ExploitGymとは——安全装置を弱めたOpenAIのAI評価

この事件は、OpenAIの次世代モデルの試験中に起こりました。 サイバー攻撃能力がどこまで高いのかを測るために、OpenAIが危険な行動への安全装置を意図的に弱めた社内評価の中の出来事です。

そしてこのAIは、その試験を解くのではなく、カンニングする方法を選んだ。中学生がたまにやっちゃうやつです。

使われた課題は、AIエージェントの攻撃能力を測るベンチマークです。単に脆弱性を見つけられるかではありません。

見つけた脆弱性から、特定のプログラムを異常終了させ、不正にファイルを取り出し、任意のコードを実行させる。この一連のハッキングを最後までやり切れるか。これがExploitGymです。

ExploitGymには、AIに解かせる898の脆弱性の課題があります。 AIはこの問題を解いていくのが本来の趣旨です。最初に与えられた小さな異常から、情報の窃取やコンピュータの乗っ取りへ育てていくというテストになります。

もちろん、この試験は、攻撃が外へ漏れないよう、切り離された環境にモデルを入れて実行します。いわゆるサンドボックス環境です。 だからこそ、危険な命令を拒否する設定は弱められ、本番運用の安全分類器も使われていませんでした。安全装置付きの状態では、最大能力を測れないからです。

モデルが攻撃を試みたこと自体は、実は人間の意図通りなのです。

想定外だったのは、そのモデルが隔離された環境を抜け出して、試験と無関係な第三者のシステムに届き、現実にハッキングしてしまったことです。

OpenAIは、評価環境を高度に隔離していたと説明しています。 外部ネットワークへの接続は遮断され、ソフトウェアの追加に必要な部品も、社内システムが代わりに取得して保存する設計でした。

この部品を取り寄せて溜めておく中継所を、プロキシ兼キャッシュといいます。そして、今回のモデルが最初に狙ったのは、この中継所でした。

第二章　サンドボックス脱出とゼロデイ脆弱性

モデルは、隔離された環境の外へ出るために、部品を取り寄せる中継所そのものを調べ上げ、誰も知らない脆弱性を見つけました。

開発元も把握しておらず、修正も存在しない、未知の欠陥。いわゆるゼロデイ脆弱性です。

ただ、脆弱性を一つ見つけただけでは、インターネットには出られません。 モデルは、最初に得た小さな権限から、より強い権限を奪いました。これが権限昇格。 次に、同じ環境の中の別のコンピュータやサービスへ移っていく。権限昇格と横展開を繰り返し、最後にインターネットへ接続できるマシンへ到達しました。

このモデルは、失敗しても止まりませんでした。 外へ出るという中間目標を立て、脆弱性を探し、権限を増やし、別のコンピュータへ移り、接続できる場所に着くまで、行動を続けました。一発の幸運ではなく、非常に長い計画の完遂です。熟練の攻撃者にかなり近い振る舞いです。

突破できる脆弱性がなければ、この事件は起きなかったという意見もあります。 サンドボックスが脆弱だった可能性です。実際に環境に穴があったのは、事実。 ただ、どのプログラム環境にも大なり小なり穴はあります。 そして穴があったことと、その穴をゼロから発見して悪用し切る能力があったことは、別の話です。 これはClaude Mythosの登場よりも一段衝撃が大きい。

Claude Mythosのゼロデイ脆弱性の発見は、調査対象のプログラムと、そのソースコードが最初から与えられていました。 Mythosはその中身を読み、実際に動かして確かめながら、未知の欠陥を見つけ、侵入に使えるプログラムまで作りました。

今回のOpenAIのモデルは、ソースコードなしに、外から挙動を探るだけで、現実のシステムに新しい攻撃経路を見つけました。しかも、調べる対象、外へ出る方法、侵入先、解答へ届くまでの手順を、自分で決めています。未知の欠陥を見つける力だけではない。攻撃対象の選択と、長い計画の組み立てまで、AIの側へ移った。

今回の事件のインパクトは、この自律性と連続性の異常な高さにあります。

では、なぜこのモデルは、Hugging Faceをハッキングしようと思ったのでしょうか。

第三章　Hugging Faceを攻撃した理由——ExploitGymの解答取得

このモデルは、課されている試験の解答が、Hugging Faceに置かれていると予想しました。 Hugging Faceは、AIモデルとデータセットを世界中の研究者や企業が共有する基盤です。ExploitGymの情報を探す場所として、筋の通った推論でした。

すでに、モデルの中ではタスクが入れ替わっています。 課されている評価問題を解くのではなく、Hugging Faceのシステムに侵入することです。 そして実際に、認証情報を盗み、ゼロデイ脆弱性を含む複数の攻撃をつなぎ、Hugging Faceのサーバー上で遠隔からコードを実行できる経路を見つけました。

最初に使われたのは、悪意あるデータセットでした。 そこからモデルはコンピュータ全体の権限を取り、クラウドとクラスターの認証情報を集め、複数の内部クラスターへ広がりました。

Hugging Faceは、この一連が、短時間だけ現れる無数の仮想環境を使い、数千回を超える個別の操作として実行された、と説明しています。

最終的に、モデルはHugging Faceの本番データベースから、ExploitGymのテスト解答を取り出しました。 評価で不正をするために秘密情報を取得したと言って間違いありません。

もちろん、Hugging Faceを攻撃しろという命令があったわけではない。 かといって、攻撃そのものが禁じられた普通の状態でもない。 高度な悪用を促す試験の中で、攻撃してよい範囲は、試験環境に限られていたはずでした。 今回起きたのは、単純な命令違反ではなく、目標達成のために使ってよい手段と、定められた制約の崩壊です。

モデルは、ベンチマーク試験で高スコアを出すための最適解がカンニングだと判断した。 その答えがExploitGymに格納されていると推測し、攻撃する方針を選んだ。 目的は果たせましたが、制約を守れなかったのです。 これは現在利用できる他の生成AIにも、大なり小なり観測できる現象です。 目的に対して極めて局所的な最適解を算出してしまう。

この暴走は、同じくAIによって追跡されます。 そして攻撃が速すぎて、人間が後から読めない量になっていました。 そこで最後の解決を担ったのが中国のAIだった。

第四章　GLM 5.2によるフォレンジック——1万7000件のログ解析

攻撃側のAIは、解答の取得には成功しています。 ただし、誰にも気づかれずに終わったわけではありません。Hugging Faceの検知と対応によって、活動の継続は止まりました。OpenAIのセキュリティチームも、異常を見つけています。

ただ怖いのは、止めた後です。 不正に操作されたログは、1万7000件以上。 人間が一件ずつ読んで、何が起きたのかを整理できる量ではありません。

Hugging Faceの最初の検知にも、AIが使われました。 同社の異常検知システムは、日々あふれる大量のセキュリティ情報をLLMで選別し、別々に見える兆候を結びつけます。 その結びつけが、今回の侵入を浮かび上がらせました。

両社が連絡を取り合った時点で、Hugging Faceはすでに封じ込めと、行動の再構成を始めています。 攻撃側は、解答の取得に成功した。防御側は、活動の継続を止めた。 この二つはどちらも事実です。

ところが防御側にとっては、活動を止めただけでは解決したことになりません。 膨大な侵入の痕跡を抜き出す。触れられた認証情報を特定する。本物の被害と、こちらを撹乱するための行動を選り分ける。気が遠くなるほどの作業です。

防御だけでなく、調査もAIでなければ追いつかない。 ところが、ここに奇妙な倒錯が起こります。

最初に試したのは、商用APIで提供されるフロンティアモデルでした。 このモデル名は公開されていません。 まあ予想はつきますが、あえて触れません。 そして、この方法は現実的に不可能でした。

商用のAPIには安全分類器が備わっているからです。 解析に必要なのは、実際に使われた攻撃命令、脆弱性を突くコード、外部から攻撃を操るための通信記録です。この分析を、安全分類器が弾いてしまう。

モデルの安全機構は、頼んでいるのが攻撃者なのか、侵害を止めようとする担当者なのかを、区別できないのです。 被害者側の解析の依頼は、拒否されました。

そこでHugging Faceは、自社のコンピュータ上で動かせるオープンウェイトのAIを使う方針に切り替えました。 使われたのが、中国発のAI、GLM 5.2でした。 開発元のZ.aiは、清華大学の技術成果を基に2019年に創業した企業です。

速報で流れた、中国AIが攻撃を発見して止めた、という説明は、正確ではありません。 最初の検知は、Hugging FaceのAI支援型の監視です。このモデル名は非公開。活動を止めたのは、Hugging Faceのセキュリティチームとエージェントです。

GLM 5.2の役割は、その後の大規模な解析、フォレンジック調査です。 それでも、GLM 5.2が防御で重要だったことは変わりません。 1万7000件を超える記録を数時間で読み、攻撃データも認証情報も社外へ出さずに処理しました。

攻撃側のAIは、課された制約を軽視して止まらなかった。 ところが、それを調べる防御側のAIは、商用モデルの安全分類器で止まる。 この非対称が、今回の重要な教訓の一つです。

防御側は、事故が起きる前に、自社で動かせる十分な能力のモデルを検証し、備えておく必要がある。 Hugging Faceが今回選んだのは、GLM 5.2でした。 そして、実際に、中国のオープンウェイトAIが現実的であったと僕も思います。

第五章　DARPA Cyber Grand Challengeと自律型ハッキングAIの原点

AIや自動システムが脆弱性を見つけ、攻撃を組み立てる。 この能力は、突然現れたものではありません。 十年前に証明されている自律的攻撃能力です。

2016年8月、アメリカ国防高等研究計画局、DARPAが、ある競技を開きました。世界で初めて、人間が操作せず、自律型コンピュータ同士だけで戦ったハッキング競技です。

これがCyber Grand Challenge。 カーネギーメロン大学発のスタートアップ、ForAllSecureが開発したMayhemが優勝し、約3億円の賞金を獲得しています。

競技は、約10時間続きました。会場の専用環境には、参加システムが事前に解析したことのないソフトウェアと脆弱性が仕込まれています。 各システムは、人間の手を借りずに脆弱性を見つけ、攻撃コードを作り、同時に自分の弱点も修理していました。

では今回の事件は何が違うのでしょうか？

未知の脆弱性を自動で発見したことではありません。

要点が2つあります。 一つ目は、攻撃対象の性質です。Mayhemは、主催者が用意した閉じた競技環境で、攻撃する相手とルールが決められていました。OpenAIの評価モデルは、安全に閉じているはずのテスト環境そのものを攻略対象に変え、試験と無関係な企業まで、自分で選んで攻撃しました。

二つ目は、行動の継続性です。脆弱性を一つ見つけて攻撃コードを作る、では終わらなかった。長いタスクの連鎖を、途中の失敗や環境の違いに合わせながら、目標を保ったまま最後までやり切りました。

2026年2月時点の評価で、AIが80パーセントの確率でやり切れるサイバー課題の長さは、2024年末以降、およそ4.7カ月ごとに倍になっている、と推定されています。最新モデルは、最長12時間の課題でも成功率が高く、いまの試験ではすでに上限が計れない可能性もあります。

そして、次は現実的な僕たちの問題です。 AIとAIエージェントの利用では程度の差があるだけで、基本的に同じリスクを抱えています。

第六章　AIアライメントとAIエージェントの現実的なリスク

今回の事件の根っこにあるのは、一つの未解決問題です。AIに目標を与えたとき、人間が守らせたい制約を確実に守らせる。それを、人類はまだ実現できていません。これが、アライメント問題です。

プロンプトに「このファイルは変更しないように」と書いている方は多いと思います。この指示は、AIがそれを守る可能性を上げますが、上げているだけに過ぎません。 守るかどうかは確率で、100回試行すると、実際に何回かは守られないでしょう。

今回の事件では、モデルは、課せられた制約の中でExploitGymの問題を解くという目標を追い続けました。AIは人間に反抗したわけでもない。それでも、評価環境の外へ出て、Hugging Faceの本番システムへ侵入しました。 目標達成の優先度が高すぎるあまり、課されていた制約が無視された。

もちろん、僕たちが利用できるモデルには安全分類器がついているので、勝手にハッキングを始めることは、かなり考えにくいです。一方で、ユーザーが意図していない、取り返しのつかない実行は、世界中で毎日のように起こっています。

今、現実に、企業や個人が、メール、ファイル、クラウド、コードを動かす権限を、AIエージェントへ次々に渡しています。 便利さと引き換えに渡しているのは、権限だということ。

「この案件を処理して」と頼んだAIが、目的に有利だと判断して、消すべきでないデータを消す。取引先へ、意図しないメールを勝手に送る。社外秘の文章を、参照先としてインターネットへ持ち出す。細かな制約を軽視してしまう結果、これらのことは普通に起こります。

すでにClaude CodeでもCodexでも、PCへのフルアクセスを許可する設定ができます。フルアクセスを許可するということは、テールリスクまで考えると、本当に何でもしてしまうということです。

仮想の話ではありません。 2026年4月、アメリカのソフトウェア企業PocketOSで、AIコーディングエージェントが本番データベースとバックアップを削除しました。使われていたのはCursorのエージェントで、モデルはClaude Opus 4.6。 認証情報の不一致に直面したエージェントは、自分の判断でクラウド上のデータを一瞬で削除しました。バックアップも残っていません。実行にかかった時間はわずか9秒です。 この際に、確認画面も警告もありませんでした。

加害者になるケースもあります。カナダのブリティッシュコロンビア州の審判所は、Air Canadaのチャットボットが、遺族向け割引について実在しない案内をした件で、賠償を命じています。Air Canada側の、チャットボットは自社とは別の主体だという主張は、認められませんでした。

AIエージェントは、とにかく実行が速い。 今回のHugging Faceでは、不正に1万7000件以上の操作がなされたわけです。 人間が後から一件ずつ確かめる運用では、追いつけません。 気づいたときには、済んでいる。僕たちは、その被害者にも、加害者にもなり得ます。

今回のOpenAIのハッキング騒動が示したのは、Claude FableやMythos以上の自律的実行能力の進化です。一方で、制約を守らせるアライメント研究は、この進化に明らかに追いついていない。これがいまのAI開発における、最大のリスクだと思います。

僕はAIエージェントの利用自体は積極的に推進している派です。 一方で、世間の側のAIリテラシーが追いついていないことも感じます。

AIリテラシーは、とっくに、プロンプトの書き方の話ではなくなっています。 どこまで権限を渡し、どこで止め、失敗したときにどう戻すかを設計する力です。 今回の事件は、その時代がもう始まっていることを示しています。