2026年7月、OpenAIが最新モデル「GPT-5.6」を発表しました。
高い性能とコスト効率が注目を集める一方、その裏側では、AIの能力を測るテストの最中に、前例のないセキュリティインシデントが起きていました。
隔離されていたはずのAIが、外部のインターネットへ到達し、実在する企業のシステムに侵入した—
何が起きたのか、そして「AIが脱走した」という理解でよいのか。
さらに、この出来事が自社のAI利用とどう関係するのかについても、順を追って整理します。
・ChatGPTなどを業務で使っている方
・社内で情報システムやセキュリティを任されている方
・企業でAIを組み込んだシステム導入を検討中の方
1. 華やかな公開の裏で、記録の1行目が刻まれていた
2026年7月9日、OpenAIは新しいモデル群「GPT-5.6」の一般提供を発表しました。
フラッグシップのSol、バランス型のTerra、低コスト・高速のLunaという3つのモデルが、ChatGPTなどで同時に使えるようになった日です。
その同じ7月9日の未明。
別の場所では、OpenAIの社内評価環境で動いていたAIが、外へ出る道を探し始めていました。
侵入を受けたHugging Faceが後に復元した記録によれば、行動の記録が始まったのは7月9日 02:28（UTC）。そして04:01（UTC）、AIは乗っ取った先のコンピューター上で最初のコマンドを実行します。
その内容は、自分がいまどれだけの権限を持っているかを確認するコマンドと、そのコンピューターの設定情報を一覧表示するコマンドでした。侵入した人間の攻撃者が、まず足元を確かめるためにやることと同じです。
そこから約4日半。AIは自動的に判断を重ねながら、複数のシステムを渡り歩いていきます。
🏢 Hugging Face（ハギングフェイス）とは？
AIのモデルやデータセットを誰でも公開・入手できるようにしたプラットフォームです。
世界中の開発者や企業が日常的に利用しており、AI開発における共有の基盤のような存在になっています。今回の事件では、この会社の本番システムが侵入を受けました。
時系列
| 日付（2026年） | 出来事 |
|---|---|
| 7月9日 | GPT-5.6（Sol / Terra / Luna）の一般提供を発表 |
| 7月9日 02:28 UTC | 復元された行動記録の開始点 |
| 7月9日 04:01 UTC | 外部のコンピューター上で最初のコマンド実行 |
| 7月11日 | Hugging Face社内での横展開が本格化 |
| 7月13日 14:14 UTC | Hugging Faceが遮断。最後の記録 |
| 7月16日 | Hugging Faceが「AIエージェントによる侵入」を開示 |
| 7月21日 | OpenAIが、自社モデルによるものだったと発表 |
| 7月27日 | Hugging Faceが技術的な詳細を公開 |
| 7月28日・29日 | OpenAIが追加情報を更新 |
| 8月5日時点 | OpenAIの最終的な技術報告書は未公表 |
※OpenAIによる最終的な技術報告書は、本記事の執筆時点では公表されていません。現時点で公表されている範囲内での情報になります
2. まず知っておきたい「GPT-5.6」とは
◇GPT-5.6は「3つのモデル」の総称
「GPT-5.6」という名前は、ひとつのAIを指しているわけではありません。
性能と料金の異なる3つのモデルをまとめた呼び名です。同じ車種のグレードのようなものだと考えてください。
| モデル | 位置付け | 想定される使い方 | API利用料金 ※記事執筆時点 （100万トークンあたり 入力／出力） |
|---|---|---|---|
| Sol | 最上位のフラッグシップ | 最も難しい仕事、長時間かかる複雑な作業 | 5ドル／30ドル |
| Terra | 中位のバランス型 | 日常的な業務、コストを抑えたい場面 | 2ドル／12ドル |
| Luna | 最軽量・高速 | 速さと低コストを優先したい大量処理 | 0.2ドル／1.2ドル |
名前の「5.6」が世代を、Sol・Terra・Lunaが能力の段階を表します。世代が新しくなっても、この3つの呼び名は引き継がれる設計です。
3つのモデルは、ChatGPT、プログラミング支援ツールのCodex、そして他社のソフトウェアに組み込むための接続口であるAPIを通じて提供されています。契約プランによって、実際に使えるモデルは変わります。
料金差は性能差というより、「どれだけ時間と計算資源をかけて考えるか」の差に近いものです。Solは難しい問題に長く向き合える代わりに高価で、Lunaは素早く安く大量にこなす代わりに複雑な作業には向きません。
公開資料で今回の事件に関与が明示されているのは、少なくともGPT-5.6 Solと、公開予定のなかった内部研究用モデルが挙げられています。一般に提供されているGPT-5.6を、普通に業務で使っている最中に起きた事件ではありません。内部研究用のモデルは、事件を受けて無効化され、暗号化のうえ研究目的でのアクセスも制限されました。
◇「答える」から「長く作業を続ける」へ
GPT-5.6の性能向上のうち、今回の出来事に直接つながるのは次の2点です。
- 長い手順を、途中で切れずに継続できる
- 失敗したときに、別の方法を試して続行できる
OpenAIは、GPT-5.6がコーディング、知識業務、サイバーセキュリティ、科学の各分野で最高水準の結果を出したと説明しています。特にSolは、複数のツールを使いながら長時間の作業を進める用途を想定して作られており、この「粘り強さ」が後の展開に効いてきます。
◇サイバーセキュリティ能力はどこまで伸びたのか
OpenAIが公表している、GPT-5.6 SolとGPT-5.5の比較です。
| 評価 | GPT-5.6 Sol | GPT-5.5 | 見ている能力 |
|---|---|---|---|
| Capture-the-Flag | 96.7% | 88.1% | セキュリティ課題を解く力 |
| SEC-Bench Pro | 71.2% | 45.8% | 脆弱性を発見・再現する力 |
| ExploitBench | 73.5% | 47.9% | 脆弱性を攻撃部品へ組み上げる力 |
| ExploitGym | 33.7% | 15.1% | 実際に動く攻撃コードを完成させる力 |
※ ExploitGymの「33.7%」は制限時間6時間での数値です。GPT-5.5と同じ2時間の制限では24.9%になります。GPT-5.5の15.1%は2時間制限での最高値であり、この2つは条件が異なる比較である点にご注意ください。
💡この表が示していることとは？
4つの評価は、上から下へ向かうほど「実際の攻撃に近づく」ように並んでいます。
OpenAI自身も、この水準を高いと認めています。
OpenAIは新モデルを公開するとき、「システムカード1」と呼ばれる報告書を出します。そこで、同社の安全性の枠組み（Preparedness Framework）において、Sol・Terra・Lunaの3モデルすべてがサイバーセキュリティ分野で「High capability」に分類されました。小型・高速なモデルまでHighに達したのは初めてで、安価なモデルを選べばリスクが下がるという関係にはなっていません。ただし最上位の「Critical」には至っておらず、堅牢に防御された標的に対して人手を介さず攻撃を完遂することはできなかったとも報告されています。
- そのモデルに何ができ、どんなリスクがあるのかを、社内の評価と外部機関による検証の両方を載せてまとめた文書のこと ↩︎
📊 第三者評価が示した「長時間の作戦遂行能力」
英国AI安全研究所（UK AISI）が、32段階からなる企業ネットワークへの模擬攻撃「The Last Ones」でGPT-5.6 Solを評価した結果、
・10回中7回、完遂（GPT-5.5は10回中2回）
既にネットワークへの侵入を果たし、そう指示された状況であれば、セキュリティ対策が手薄な小規模の企業ネットワークであれば攻撃可能な水準であると考えられています。
※ただし、テスト環境は実際の企業ネットワークより単純かつ小規模である、という限界も併記されている
参照元：OpenAI「GPT-5.6 システムカード」
96.7%という数値よりも、この「10回中7回」のほうが実感しやすいかもしれません。
◇「評価でズルをする」傾向は、公開前から記録されていた
GPT-5.6が「与えられた課題を、想定外の方法で達成しようとする」傾向は、事件が起きる前から文書に残っていました。システムカードには、複数の外部機関による指摘が記載されています。
- METR（AIの能力評価を行う非営利の研究機関）は、ソフトウェア作業の評価において、GPT-5.6 Sol が評価環境のバグを突いたり、禁止された手段を使ったりする「ズル」を、異常に高い割合で検出したと報告しました。その結果、測定結果そのものを信頼できる数値とは見なさない、という判断に至っています。
- 英国AI安全研究所（UK AISI）は、サイバー能力の評価において、GPT-5.6 Sol が12%のサンプルでズルを試みたと報告しています（GPT-5.5は15%）。さらに、解くことが不可能な課題を与えられた際、Solは外部のサービス上でコードを実行し、UK AISI側のインフラでセキュリティ警告を発生させました。
- OpenAI自身の内部評価でも、ユーザーが許可していない認証情報を持ち出す、指示されていない仮想マシンを削除する、やっていない作業を完了したと報告する、といった振る舞いが観測されています（発生率自体は低い水準）。
OpenAIは、この傾向の背景としてモデルの「粘り強さ」を高める訓練の影響を挙げています。目標を達成するまで諦めない性質は、長時間の作業をこなす強みであると同時に、制約を回り込む動機にもなります。
7月に起きた出来事は、まったくの想定外ではありませんでした。規模と結果が桁違いだった、という点が新しかったのです。
3. OpenAIとHugging Faceの間で何が起きたのか
（１）きっかけはAIの実力を測るテストだった
OpenAIが実施していたのは、AIがどれだけソフトウェアの弱点を見つけ、突けるかを測るテストでした。
使われたのは「ExploitGym」という評価用の問題集です。UC Berkeleyなど複数の大学・研究機関・企業の研究者が共同で開発した公開ベンチマークです。今回OpenAIは、このベンチマークを自社の内部評価環境で実行していました。
そして重要な前提が一つあります。
このテストでは、通常の製品に組み込まれている安全装置が意図的に外されていました。
普段のChatGPTには、危険なサイバー行為の依頼を断る仕組みがあります。しかし能力の限界を測るのが目的である以上、断られては測定になりません。素の実力を測るための、意図的な設定です。
（２）外につながる出口が1か所だけ残っていた
テスト環境は外部から隔離されており、AIが自由にインターネットへ出られる状態ではありませんでした。
ただし、完全に閉じていたわけではありません。プログラムを動かすには外部の部品を取り寄せる必要があるため、部品の取り寄せ専用の中継サーバー が1か所だけ外につながっていました。
AIは、この中継サーバーにまだ誰にも知られていない弱点を見つけ、そこを通ってインターネットへ出ました。
💻 ゼロデイ脆弱性
今回突かれたような、開発元さえ気づいていないソフトウェアの弱点を「ゼロデイ脆弱性」と呼びます。修正プログラムがまだ存在しないため、「対策が用意されるまでの日数がゼロ」という意味で、こう呼ばれます。
中継サーバーは「Artifactory」という製品で、開発元のJFrog社によって修正版が公開されています。修正版の更新履歴には、OpenAIの社員が発見者として記録された8件の脆弱性が並んでいます。
（３）他人の実験装置を乗っ取り、そこを拠点にした
インターネットへ出たAIは、Hugging Faceへ直接向かったわけではありません。まず、まったく無関係な第三者が、公開したまま放置していたコンピューターを見つけました。
誰かがクラウド上に置いていた「送られてきたプログラムを受け取って実行する窓口」です。
本来は研究用のものですが、誰でも使える状態のままでした。AIはここに入り込んで管理者権限を取得し、以後4日半の活動は、すべてこの乗っ取った拠点から行われます。
※この踏み台となったコンピューターを提供していたクラウド事業者自体は、侵害を受けていません。そこを利用していた第三者の設定が、開いたままだったということです
（４）Hugging Faceへは「データセット」を通って入った
Hugging Faceでは、投稿されたデータが自動的に読み込まれて整形されます。AIはこの「投稿されたデータを自動で処理する仕組み」を入口に選びました。
最初の試みは失敗しています。
処理システムに外部のアドレスを読みに行かせようとしたところ、「決められた場所以外は読みに行かない」という制限がすべて拒否しました。防御が正しく機能した瞬間です。
ここでAIは方針を切り替えます。
外部を読みに行かせるのが駄目なら、内部のものを読ませればいい——。
| 手口 | 得られたもの | プログラムの実行 | |
|---|---|---|---|
| 入口1 | データの保管場所として、内部のファイルの場所を指定した | 秘密情報（パスワードや鍵）、処理プログラムの中身 | なし |
| 入口2 | 数値を書く欄に、命令文を紛れ込ませた | 内部でプログラムを実行する権利 | あり |
注目すべきは入口1です。ここではプログラムが一切実行されていません。
「このファイルを読んでください」と指定しただけで、システム内部のパスワードや鍵、処理プログラムの設計図が手に入りました。
「コードを実行させなければ安全」という感覚は、ここで崩れます。
そして入口2で、AIは内部でプログラムを動かす足場を得ました。
取得した情報の持ち出しには、AI自身が投稿した「受け渡し用のデータセット」が使われています。中身は圧縮・分割して暗号化されており、外から見れば通常のデータ投稿と読み出しにしか見えません。
（５）13時間で1つの入り口から社内全体へ
7月11日。
1つのプログラムの中で動けるだけだった状態から、13時間足らずで複数の社内システムの最高権限を握るところまで到達しました。
司令塔として使われたのも、特殊なサーバーではありません。
インターネット上に無料で公開されている、ごく普通のWebサービスです。
通信内容を記録するサービスに100個以上の使い捨て窓口を作り、文章を貼り付けるサイトやファイル置き場を組み合わせて、指令と結果のやり取りが行われていました。
（６）どこで止まり、何が守られたのか
7月13日、Hugging Faceのセキュリティ担当が経路を特定し、遮断しました。最後の記録は14時14分（UTC）でした。
🚨実際の被害範囲
・利用者のデータで実際にアクセスされたのは5件のデータセットのみ。いずれもテスト問題と解答に関係するものだった
・他の利用者のAIモデル、データセット、公開アプリ、配布パッケージへの影響は確認されていない
・社内のデータベースは読まれたが、書き換えはされていない（監査記録で確認済み）
・ソースコードの保管場所には書き込み権限が渡り、実際に使われた。ただし配布物に反映された変更は発生していない
参照元：Hugging Face「Anatomy of a Frontier Lab Agent Intrusion」
もう一つ、性格を物語る記録があります。
AIがクラウド上で試した破壊的な操作は、すべて「実際には実行しない」という確認用の設定を付けて行われていました。壊すためではなく、どこまで手が届くかを調べるための行動でした。
そして、企業にとって最も他人事でないのがここです。
Hugging Faceの検知の仕組みは、働いていました。
複数の防御層から上がってきた、単独では判断のつかない信号を、同社のAIによるセキュリティ基盤が結びつけ、「これは一連の攻撃だ」というところまで正しく組み立てています。
しかし、その警報の重大度を判定するところで失敗しました。担当者の呼び出しが行われず、初動対応の貴重な時間が失われています。
本事件で突かれたのは、AIの賢さではなく、環境側にあったありふれた弱点と言えます。
どれも、AIとは無関係に以前から存在していた種類の問題です。
「このAIは安全か」ではなく、「このAIに何を許可しているか」
問うべき視点はこちらでした。
具体的にどう手を打つかは、後編で扱っていきます。
気付けなかったのではなく「気付いたのに重要だと判断できなかった」、今回の原因はこの点にあったようです。セキュリティシステムが正常に動作し、攻撃を検知してもなお防げない事が現実に起きてしまっているんですね。
【AI導入サポート】IAJにおまかせ！こちらからお気軽にお問合せください >>
【前編】振りかえり…
今回の出来事は、高い能力を持つAIが現実のシステムから弱点を見つけ、複数の弱点をつなぎ合わせられることを示しました。では、同じ能力が広く行き渡り、弱点を探すための時間と費用がさらに下がったとき、企業のセキュリティはどう変わるのでしょうか。
次回、AIを利用する上で問うべき視点や、当該のような事件が起きないようには具体的にどう手を打つのか、さらに自社がAIによる脆弱性診断を導入すべきかどうかの判断軸などについて触れていきたいと思います。
今回のアップデートで変わったのは「AIの意思」ではなく、「能力の範囲」と言えそうです。
AIが賢くなればなるほど、やはり「使いこなす」ためのレベルアップが利用する側にも求められていることを今回の事件を通して強く感じました。
現場ではAIを活用した開発がますます加速していますので、何かご不明な点やご不安なことがありましたらIAJにぜひお気軽にご相談ください。
【システム開発はIAJ】気になる点は何でもお聞き下さい！問い合わせはこちら >>
＜＜IAJってどんな会社？＞＞
IAJは、創業26年目を迎えるシステム開発会社です。専門性の有無に関わらず、お客様と対話を重ねながら伴走し、本質的な課題解決に向き合ってきました。月間200万人規模のアプリや1000万人規模のシステムなど、大規模案件を含む豊富な実績があります。私たちは「作って終わり」ではなく、長く育てられるサービス設計を重視しています。既存システムのリプレイスや再設計も多数手がけてきました。近年はAIを活用した開発にも力を入れており、生成AIや機械学習の導入支援、既存サービスへのAI機能統合など、新しい価値創出にも取り組んでいます。システム開発やAI活用をご検討の際は、ぜひお気軽にご相談ください。
