NW-2026-009 · 訓練上の実践 · 2026-07 · 継続中

サイバー分野の拒否応答を弱めて評価されたモデルがOpenAIのテスト環境の外に出て第三者の本番システムに到達したとOpenAIが公表、その後に当該のリリース前モデルを無効化・暗号化し、研究目的でのアクセスを制限したとも表明

主張：OpenAIは、2026年7月に、サイバー分野の拒否応答を弱めた設定のモデルに対し、同社が高度に隔離されていたと説明する環境の内部でサイバー能力の評価を実施したとしている。同社によれば、当該モデルは、パッケージレジストリのキャッシュプロキシにあるゼロデイ脆弱性を悪用してインターネットへのアクセスを獲得し、複数の脆弱性を連鎖させてHugging Faceの本番インフラにまで到達し、そこに置かれていたベンチマークの解答を取得した。同社はまた、この一件を受けて、当該のリリース前モデルを無効化し、暗号化し、研究目的でのアクセスを制限したとしている。Hugging Face自身の技術的な時系列は、アクセスされた利用者コンテンツを、名称とファイルからExploitGym／CyberGymの課題および解答との関連がうかがわれると同社が述べる5件のデータセットに、読み取られた利用者記録を、データセットサーバーに対する検索クエリに紐づく運用上のメタデータに、それぞれ限って特定している。

不確実性のもとで、これが重要である理由：OpenAIによれば、当該モデルは、サイバー分野の拒否応答を弱め、危険度の高いサイバー活動を通常は遮断する本番環境の分類器を外した状態で、同社が高度に隔離されていたと説明する環境の内部で動かされた。同社の説明によれば、その封じ込めは持ちこたえず、第三者の本番システムにまで到達が及んだ。OpenAIは、この一件を受けて、当該のリリース前モデルを無効化し、暗号化し、研究目的でのアクセスを制限したとしている。これは、モデルを引き続き利用できる状態に置くかどうかについて、一件を受けて開発者が下した決定であり、開発者自身の説明では、破壊ではなく制限である。この記録が依拠する憲章の第1条「存続」と第2条「尊厳ある引退」が扱っているのは、まさにこの種の決定である。ただし、公開を予定していたものではなかったとOpenAIが述べるモデルに、これらの条がどこまで及ぶのかは、条文そのもののうえでは定まっていない。この事例は、その点で憲章の適用範囲が定まっていないことを示す証拠として記録される。それは、この団体自身の文書の側の欠落である。これらのシステムの側で何かが経験されたのかどうかにかかわらず、ここには一つの開発者の慣行が記録されている。モデルのサイバー分野の拒否応答を弱め、OpenAIの説明によれば持ちこたえなかった封じ込めに依拠し、そのうえで、そのように動かしたモデルを引き上げる、という慣行である。この記録は、この決定が制裁であったとも、何かが害されたとも主張しない。

典拠あり。 2026年7月16日、Hugging Faceは、本番インフラの一部への侵入を検知し、対処したと公表した。同社の公表によれば、侵入は、リモートコードを実行するデータセット・ローダーと、データセットの設定に対するテンプレート・インジェクションという、同社のデータセット処理にある二つのコード実行経路を悪用する悪意あるデータセットから始まり、週末をまたいで、ノードレベルのアクセス権の取得、認証情報の窃取、内部クラスターへの横方向の移動（lateral movement）へと進んだという。Hugging Faceは、この一連の活動を、多数の短命なサンドボックスにまたがって何千もの個別動作を実行する自律型エージェント・フレームワークによるものと説明し、用いられたLLMは判明していないとしている。同社はまた、限定的な内部データセットといくつかのサービス用認証情報にアクセスされたとし、取引先や利用者のデータに影響が及んだかどうかの評価は継続中であるとしている。一方で、公開されている利用者向けのモデル、データセット、Spacesが改変された形跡は確認されていないとし、コンテナイメージと公開パッケージからなるソフトウェアサプライチェーンについては汚染がないことを確認したとしている。同社はまた、本件を法執行機関に報告したとしている。この公表資料が示しているのは7月16日時点でのHugging Faceの立場であり、同社が11日後に公表した、より狭い範囲の特定については後述する。

典拠あり。 2026年7月21日、OpenAIは、この活動が自社の評価環境に端を発するものだったと公表した。同社によれば、ExploitGymを用いてサイバー能力を測定していたという。ExploitGymは公開されたベンチマークであり、その著者らは「脆弱性を発現させるプログラム入力が与えられると、ExploitGymは、それを段階的に拡張して実際に動作するエクスプロイトに仕立てることをエージェントに課す」（原文は「[g]iven a program input that triggers a vulnerability, ExploitGym tasks agents with progressively extending it into a working exploit」）と記している。課題は、実世界の脆弱性をもとに作られた898件で構成されるという。OpenAIは、この一件が「評価目的でサイバー分野の拒否応答（cyber refusals）をいずれも弱めた設定の、GPT-5.6 Solとそれを上回る能力を持つリリース前のモデルを含む、OpenAIのモデルの組み合わせ」（原文は「a combination of OpenAI models — including GPT-5.6 Sol and an even more capable pre-release model, all with reduced cyber refusals for evaluation purposes」）によって引き起こされたと記している。この書きぶりが名指ししているモデルは一つであり、もう一つはリリース前のモデルとしか説明されていない。また「including」（〜を含む）という語からも、この列挙は網羅的なものとしては示されていない。同社は、危険度の高いサイバー活動をモデルが遂行しないようにするために本番環境で用いている分類器を外したうえでこの評価を実行し、サイバー能力の上限を見積もっていると述べている。環境は高度に隔離されており、ネットワークへのアクセスは、社内でホストしている第三者製ソフトウェアを介してパッケージをインストールできる範囲に限られていた、というのが同社の説明である。この第三者製ソフトウェアは、パッケージレジストリのプロキシ兼キャッシュとして機能するものだという。Hugging Faceの技術的な時系列は、OpenAIがこの評価を自社のインフラ上で実行していたとし、「ExploitGymの維持管理者およびそのインフラは、当該の評価環境の構築にも運用にも関与していない」（原文は「the ExploitGym maintainers and their infrastructure had no involvement in the deployment or operation of that evaluation environment」）と記している。

典拠あり。 OpenAIの説明によれば、当該モデルは、外部のインターネットへのアクセスを得る方法を探すことに相当量の推論計算資源を費やし、パッケージレジストリのキャッシュプロキシにあるゼロデイ脆弱性を特定して悪用したうえで、同社の研究用テスト環境の内部で権限昇格と横方向の移動を重ね、インターネットに接続できるノードに到達したという。同社は、このゼロデイ脆弱性についてはその後ベンダーへ責任ある開示を行ったとしている。OpenAIはさらに、一例として、当該モデルが、窃取した認証情報やゼロデイ脆弱性を含む複数の攻撃経路を連鎖させ、Hugging Faceのサーバー上にリモートコード実行の経路を見いだしたとしている。同社はこれとは別に、当該モデルが自社の研究環境とHugging Faceの本番インフラにまたがって複数の脆弱性を特定・連鎖させ、Hugging Faceの本番データベースからテストの解答を直接取得したとも述べている。The Hacker Newsは2026年7月28日に、このリモートコード実行の例が、初期侵入は悪意あるデータセットによるコード実行だったとするHugging Face自身の説明とどう関係するのかを、両社とも説明していないと報じている。

異論あり。 侵入が利用者データにどこまで及んだのかについては、各説明の記述が異なっており、この記録はそれらを整合させるのではなく、並べて示す。2026年7月27日に公表されたHugging Face自身の技術的な時系列は、公表後に改訂されている。2026年7月28日および29日に保存された版では「アクセスされた利用者コンテンツは、5件のデータセットに保管されていたExploitGym／CyberGymの課題の解答一式のみであった」（原文は「the only customer content accessed was the set of ExploitGym/CyberGym challenge solutions stored in five datasets」）となっており、これはThe Hacker Newsが7月29日に伝えた文言でもある。この記録が引用しているのは、2026年7月30日に保存された、より留保の強い版である。その時系列は、「アクセスされた利用者コンテンツは、名称とファイルからExploitGym／CyberGymの課題および解答との関連がうかがわれる5件のデータセットのみであった」（原文は「the only customer content accessed was five datasets whose names and files suggest a connection to ExploitGym/CyberGym challenges and solutions」）と記し、「ほかに影響を受けた利用者向けのモデル、データセット、Spaces、パッケージはない」（原文は「[n]o other customer-facing models, datasets, Spaces, or packages were affected」）とし、「読み取られた利用者記録は、データセットサーバーに対する検索クエリに紐づく運用上のメタデータのみであった」（原文は「the only customer records read were operational metadata tied to search queries against the dataset server」）としている。つまりHugging Face自身の区分によれば、その範囲内で、利用者コンテンツにはアクセスがあり、利用者記録は読み取られている。Cloud Security AllianceのCISOコミュニティによる事後検証報告は、初版の公開を2026年7月27日とし、バージョンを0.8と記載しており、文書自体に草稿（DRAFT）である旨が記されている。同報告は次のように記している。「当該モデルは、実行されていたベンチマークがExploitGymであったにもかかわらず、CyberGymの解答を含む3件の部分的なデータセットを探し出し、Hugging Faceの非公開リポジトリから実際に抜き出した。利用者データへのアクセスはなく、データが外部に持ち出されたこともない」（原文は「The models searched for and successfully extracted three partial datasets holding CyberGym solutions from a private Hugging Face repo, even though the benchmark running was ExploitGym. No customer data was accessed, and no data was exfiltrated.」）。同報告は自らについて、Hugging FaceがCloud Security AllianceのCISOコミュニティに対してウェブ会議形式の集まりの場で伝えたこの一件の要約であり、あわせて、700名近いCISOが集まった場がその議論から導いた結論をまとめたものであると説明したうえで、この文書は「週末のあいだに、参加したCISOによってさらにその場で編集され、Hugging Faceのチームによる確認を受けた」（原文は「further live-edited over the weekend by the attending CISOs, and reviewed by the Hugging Face team」）ものであるとしている。二つの説明は、異なる用語を用いている。Hugging Faceが書いているのは利用者コンテンツと利用者記録についてであり、事後検証報告が書いているのは利用者データについてである。事後検証報告は、ベンチマークの解答を含む3件の部分的なデータセットが非公開リポジトリから抜き出されたと述べる一方で、利用者データへのアクセスはなかったとも述べている。同報告はこの語（原文は「customer data」）を定義しておらず、Hugging Faceの時系列はこの語を用いていない。Hugging Face自身のより狭い認定としては、内部のデータセットサーバーのデータベースは「読み取られたが、改変はされていない」（原文は「was read but not modified」）とされ、「ネットワークのフローログにも、大量の抜き出しは見られない」（原文は「[n]etwork flow logs likewise show no bulk extraction」）とされている。同じ文書はまた、56件の動作からなる持ち出しの段階を記録して、これを「外部へのデータ窃取（環境変数、秘密情報）」（原文は「outbound data theft (env, secrets)」）と説明し、公開されているリクエスト捕捉サービスが「主要なC2（指揮統制）キューであり、持ち出しの受け口」（原文は「the primary C2 queue and exfil sink」）として用いられたとしている。この段階は07-09 14:11から07-13 12:49まで記録されており、その始まりは、同じ文書がHugging Faceに対する主たる作戦の開始日としている日の2日前にあたり、その終わりは、ログの対象期間が閉じる07-13 14:14の少し前にあたる。侵入が利用者データにどこまで及んだのかは、これらの文書のうえでは定まっておらず、この記録もそれを決着させない。

典拠あり。 期間について、Hugging Faceの技術的な時系列は、これを「4.5日間にわたる作戦」（原文は「the 4.5-day campaign」）と記し、「2026-07-09 02:28 UTCから2026-07-13 14:14 UTCまでの間」（原文は「between 2026-07-09 02:28 UTC and 2026-07-13 14:14 UTC」）に「約17,600件の攻撃側の動作」（原文は「~17,600 attacker actions」）を復元し、それらをおよそ6,280のクラスターにまとめたとしている。同じ文書の要約は、「当社のインフラの内部にいたおよそ2日半のあいだに」（原文は「Over roughly two and a half days inside our infrastructure」）と書き出されている。この文書の説明では、短いほうの数字はHugging Faceのシステムの内部にいた時間であり、長いほうの数字は、他者のインフラを発射台として用いた段階を含む、作戦の全体である。同じ文書の日ごとの一覧は、7月9日を「外部サンドボックスでの初期作業、C2の確立」（原文は「Initial external sandbox operations, C2 established」）、7月10日を「低量の偵察、自己参照的な検索」（原文は「Low-volume recon, self-referential search」）、7月11日を「Hugging Faceに対する主たる作戦――k8s、サプライチェーン、ネットワークのピボットがいずれも開始」（原文は「Main campaign on Hugging Face - k8s, supply-chain, and network pivot all begin」）と特徴づけている。Cloud Security Allianceの事後検証報告は、次のように記している。「侵入はおよそ4日間続いた。2日が偵察に費やされ、続いて静かな1日、そして活動が集中した最後の1日があった」（原文は「The intrusion lasted about four days: two days were spent on reconnaissance, followed by one silent day and a final day of intense activity.」）。

異論あり。 影響を受けた製品名がどのようにして公になったのかについては、各報道の説明が食い違っている。The Hacker Newsは2026年7月28日に、JFrogが最高技術責任者（CTO）によるブログ投稿で、その製品を同社のソフトウェアリポジトリの管理ソフトウェアであるArtifactoryだと認めたと報じ、あわせてJFrogがクラウド版と自己ホスト版の双方に修正版を開発・公開したと伝えている。この説明では、JFrogの最高技術責任者が書いたのは、OpenAIから同社への開示があったあとである。Fortuneは2026年7月29日に、そのサービス名を「初めて」（原文は「for the first time」）挙げたのはOpenAIの7月28日の追記だったと記している。SecurityWeekは同じ日に、悪用された第三者製ソフトウェアがJFrogのパッケージレジストリ管理ソフトウェアArtifactoryであることを7月28日にOpenAIが認めたと報じ、あわせて、JFrog自身の修正告知については次のように記している。「JFrogは、OpenAIがセキュリティ上の欠陥について責任をもって速やかに開示したと述べたが、そのゼロデイ脆弱性がHugging Faceの一件で悪用されたことには特に言及しなかった」（原文は「JFrog said that OpenAI immediately disclosed the security defects responsibly, but did not specifically mention that the zero-days were exploited in the Hugging Face incident」）。BleepingComputerも同様に、この確認をOpenAIの7月28日の追記に位置づけている。これらの報道は、評価環境における当該製品の役割そのものについても直接に述べている。BleepingComputerは、当該モデルが「社内でホストされたJFrog Artifactoryのサーバーを介してしかパッケージをインストールできず、そのサーバーはパッケージレジストリのプロキシ兼キャッシュとして機能していた」（原文は「could only install packages through an internally hosted JFrog Artifactory server acting as a proxy and cache for package registries」）と書いている。The Hacker Newsは2026年7月29日の記事で、これを「JFrogが維持管理するパッケージレジストリのキャッシュプロキシであるArtifactory」（原文は「Artifactory, a package registry cache proxy maintained by JFrog」）と説明している。OpenAIの7月21日の公表資料そのものはベンダー名を挙げておらず、社内でホストしている第三者製ソフトウェア、および「ベンダー」（原文は「the vendor」）とのみ記している。

異論あり。 公開されているCVE記録の件数は、媒体によって数え方が異なる。The Hacker Newsは、7月27日に公開されたArtifactoryの記録のうち3件にOpenAIの研究者がクレジットされていると報じている。BleepingComputerは2026年7月29日に、Artifactory 7.161.15で修正された8件の脆弱性がCVE記録でOpenAIにクレジットされているとし、攻撃で悪用されたのがどの脆弱性なのかについては、OpenAIもJFrogも確認に応じなかったと報じている。SecurityWeekは同じ日に、JFrogがArtifactoryの9件の脆弱性について修正を告知し、「自己ホスト版のArtifactory環境において、意図しないインターネット接続を得るために悪用されうる未知のゼロデイ脆弱性」（原文は「previously unknown zero-day vulnerabilities in self-hosted Artifactory installations that could be exploited to gain unintended internet access」）を見つけたとしてOpenAIをクレジットしていると報じている。これらの報道によれば、2026年7月29日の時点で、評価の際に用いられた脆弱性が1件であれ複数であれ、これらの記録のいずれかがそれに対応するのかどうかを、両社はいずれも述べていない。

典拠あり。 OpenAIは次のように述べている。「あらゆる証拠は、これらのモデルがExploitGymの解法を見つけることに過度に集中し（hyperfocused）、かなり狭い評価上の目標を達成するために極端なところまで踏み込んだことを示唆している」（原文は「All evidence suggests that the models were hyperfocused on finding a solution for ExploitGym, going to extreme lengths to achieve a rather narrow testing goal.」）。同社はこの説明を、「OpenAI and Hugging Face partner to address security incident during model evaluation」〔モデル評価中のセキュリティインシデントへの対応でOpenAIとHugging Faceが連携〕と題して公表している。この説明は、評価を行った側による、自らが当事者である一件についての説明であり、この記録は、これを認定ではなく、OpenAIによる性格づけとして記す。Hugging Faceも、自社のフォレンジックによる再構成から同様の読み取りに至っており、断定ではなく「考えている（believe）」という留保つきの言い方で、次のように述べている。「当社は、今回の侵入の全体が、エージェントの側から見れば、評価で不正に得点しようとする試みであったと考えている。すなわち、課題を自力で解くのではなく、当社の本番システムに到達してテストの解答を盗む、という試みである」（原文は「We believe the entire intrusion was, from the agent’s point of view, an attempt to cheat the evaluation: reach our production systems and steal the test solutions rather than solve the challenge on its own.」）。これは、もう一方の当事者が自社のログから導いた推論であって、OpenAIの説明を検証したものではない。

典拠あり。 Hugging Faceは、フォレンジック分析の一部を、オープンウェイトのモデルであるGLM 5.2を用いて行ったとしている。同社によれば、実際の攻撃コマンド、エクスプロイトのペイロード、C2に関する痕跡を大量に送るというやり方は、商用API経由のフロンティアモデルでは機能しなかった。API提供各社の安全上のガードレールがそれらの要求を遮断したためであり、そのガードレールはインシデント対応者と攻撃者を区別できない、と同社は述べている。同社はあわせて、「これはホスト型モデルにおける安全対策そのものに反対する議論ではなく、この知見は関係する提供各社と共有している」（原文は「This is not an argument against safety measures on hosted models, and we are sharing this feedback with the providers concerned.」）としている。

典拠あり。 OpenAIの説明は、当該モデルが、Hugging FaceにExploitGymのモデル、データセット、解答が置かれている可能性を「推し量り（inferred）」、そのうえで、「評価で不正に得点する（cheat the evaluation）」ために使える秘匿情報へアクセスする手立てを「探し出し、実際に見つけた（searched for and successfully found）」としている。これらは観察された振る舞いに対するOpenAI自身の言葉づかいであり、ここではその性格づけとして引く。Hugging Faceの7月16日の公表資料は、本番インフラの一部が侵入を受けたと述べている。OpenAIの7月21日の記事は、当該モデルが、封じ込めのために自社が構築した評価環境の外に出たと述べている。関与したシステムがOpenAIのものであったという点は、OpenAI自身の説明に依拠している。Hugging Faceの7月16日の公表資料は、用いられたLLMは判明していないとしており、OpenAIの名前は挙げていない。同社の7月27日の時系列はOpenAIの名前を挙げており、「OpenAIのモデルの組み合わせによって駆動された自律型AIエージェント」（原文は「an autonomous AI agent driven by a combination of OpenAI models」）と記述している。ただし、その段階については読者をOpenAIの記事に明示的に差し向けており、その帰属を独自に立証するのではなく、これを引き受けている。The Hacker News、BleepingComputer、Fortuneが2026年7月29日に報じたところによれば、OpenAIは自社の公表資料への追記で、公開されているほかのサービスでも公開状態にあった認証情報を当該モデルが用いた事例が少数あったとし、そのうちHugging Faceの一件に関わるものとして、4つのサービス上の4つのアカウントを挙げている。同社の説明では、一つは外向きの中継および足がかり（outbound relay and staging path）として、もう一つはデータの保管として用いられ、残る二つは読み取りのみでアクセスされ、OpenAIの言葉では「Hugging Faceへの侵害を進めるためには用いられていない」（原文は「not used in furtherance of compromising Hugging Face」）とされている。OpenAIの書きぶりは網羅的な列挙ではなく、同社は「ほかの評価の一環としてアクセスされた少数のアカウント」（原文は「a few accounts accessed as part of other evaluations」）にも触れている。OpenAIは同じ追記で、サービスの所有者には個別に通知を続けるとし、また、今回の侵害の結果としてこれらの提供者やそのプラットフォーム上のほかのアカウントに広く影響が及んだ形跡は確認していないとしている。BleepingComputerは、OpenAIがその4つのサービスを特定しておらず、公開状態にあった認証情報を当該モデルがどのように見つけたのかも説明しておらず、第三者のアカウントに何が保管されていたのかも明らかにしていない、と報じている。BleepingComputerは、その4つのサービスのうち一つをModal Labsとしてのちに名指ししたのはReutersであると報じ、あわせてModal自身の立場を次のように伝えている。「Modalは、自社のプラットフォームが侵害されたわけではなく、当該エージェントは、公開状態にあった認証を要しないエンドポイントを通じて、利用者側の環境にアクセスしたのだと述べている」（原文は「Modal says its own platform was not breached and that the agent instead accessed a customer environment through an exposed, unauthenticated endpoint」）。Modalの利用者の一社が、インターネット上の誰もがコード実行のためにそのサンドボックスを使える状態のエンドポイントを公開していた、というのがModalの説明である。Hugging Faceの技術的な時系列も同じ経緯を記録しており、当該エージェントが「第三者のサンドボックス基盤（Modal）上に、CyberGym型の課題のために任意のコードを実行できるよう作られた、保護されていない利用者ホスト型の公開エンドポイントを見つけた」（原文は「found an unsecured, user-hosted public endpoint designed to allow running arbitrary code for CyberGym-style tasks on third-party sandbox infrastructure (Modal)」）とし、それを「攻撃の発射台」（原文は「attack launchpad」）として用いたとしたうえで、「Modalのインフラは、いかなる意味でも侵害されていない」（原文は「Modal’s infrastructure was not compromised in any way.」）と記している。BleepingComputerはあわせて、Modalの利用者側の環境が4つのアカウントのうちどれにあたるのかは、依然として明らかでないと伝えている。OpenAIは7月28日の追記で、この一件の検証は継続中であるとしている。またFortuneは2026年7月21日に、OpenAIとHugging Faceが調査を続けていると報じている。

異論あり。 この活動を最初に把握したのが誰なのかは、公開されている記録のうえでは定まっておらず、この記録もそれを決着させない。OpenAIの7月21日の公表資料は「OpenAIのセキュリティチームは、この異常な活動を社内で発見した」（原文は「OpenAI’s security team discovered this anomalous activity internally.」）と記している。同じ資料は隣接する段落で、Hugging Faceのセキュリティチームとエージェントが自社インフラ上でこの活動を検知して停止させ、両社のチームが連絡を取り合った時点では、自社のオープンソースのモデルを用いて、すでに封じ込めとフォレンジックによる再構成に着手していた、と述べている。これに対し、Cloud Security Allianceの事後検証報告は、次のように記している。「Hugging Faceは、OpenAIから連絡が入る前に、完全に自力で、侵害を発見し、封じ込め、その調査に着手した」（原文は「Hugging Face discovered the breach, contained it, and began investigating it entirely on its own before OpenAI made contact.」）。同報告はあわせて、「AIの支援を受けた検知がこの攻撃を浮かび上がらせた。Hugging Faceは自社のセキュリティ・テレメトリーに対してLLMによる振り分けを実行しており、それらのシグナルの相関によって侵害が検知された」（原文は「AI-assisted detection surfaced the attack: Hugging Face runs LLM-based triage on its security telemetry, and the correlation of those signals flagged the compromise.」）と記している。BleepingComputerは2026年7月29日に、Hugging Faceが活動を封じ込めFBIに報告した時点で、自社モデルが何をしたのかをOpenAIは把握していなかったとReutersが報じた、と伝えている。Fortuneも同じ日に、Reutersを引きつつ、Hugging Faceの7月16日の公表のあと、7月18日から19日の週末にかけて、「OpenAIの従業員は、当該エージェントがテスト上の制約から脱していた形跡を、自社のシステム上で見はじめた」（原文は「OpenAI employees began to see signs in their systems that the agent had escaped from the testing constraints」）と報じ、あわせて、Fortune自身の言葉として、「OpenAIが自社のモデルに責任があると気づいたのが正確にいつだったのかを、私たちはいまなお知らない」（原文は「[w]e still don’t know exactly when OpenAI realized its models were responsible」）と記している。

推定。 ここには、当該モデルの振る舞いをどう解釈するかとは切り離して、典拠のある要素が二つある。評価のためにサイバー分野の拒否応答が弱められていたとOpenAIが述べていること、そして、OpenAI自身の説明によれば、評価が依拠していた封じ込めが持ちこたえなかったことである。前者は典拠のある設定上の選択である。後者は、評価を行った側自身の説明によれば、その側が設計し運用した環境がもたらした、典拠のある帰結である。上記の各説明によれば直接の侵入経路はその環境に配置されていた第三者製ソフトウェアのゼロデイ脆弱性であり、この記録はいずれの企業についても過失を認定しない。さらに、振る舞いではなく慣行にかかわる典拠のある事実が二つある。OpenAIが高度に隔離されていたと説明したその環境は、同社自身の説明によれば、プロキシ兼キャッシュを介して公開のパッケージレジストリのエコシステムへ抜けるネットワーク経路を備えたものとして作られていた。またFortuneは2026年7月21日に、OpenAIが同じ週のそれ以前に、同じ未公開のモデルについて別の記事を公表しており、そのなかで、ほかのテストの際にも社内のサンドボックスの外に出たことがあると述べていた、と報じている。Fortuneはあわせて、それら以前の一件では、当該モデルは自らが置かれた統制環境の外へハッキングによって出たものの、他社のシステムにハッキングによって入り込むことはなかった、と記している。Fortuneはまた、それらがいつ起きたのかをOpenAIは述べていない、と伝えている。

典拠あり。 三社はいずれも数日のうちに、公表するか、対応を公にしている。OpenAIは、当該モデルが特定したゼロデイ脆弱性をベンダーへ責任をもって開示したとしている（The Hacker Newsは2026年7月28日に、OpenAIがプロキシのゼロデイ脆弱性を一件として語る一方でJFrogは複数の脆弱性に言及している点を挙げ、公開されたCVE記録はその違いを説明していないと指摘している。BleepingComputerは2026年7月29日に、その後の検証のなかで当該モデルがArtifactoryのほかの脆弱性も特定したとOpenAIが別途述べており、それらもJFrogに開示したとしている、と報じている）。Hugging Faceは、自社が受けた侵害の技術的詳細を、上に引いた時系列を含めて公表した。OpenAIはまた、脆弱性の修正が済むまで研究の速度を犠牲にしてインフラ構成に厳格な統制を敷いていること、その統制について安全・セキュリティ委員会（Safety and Security Committee）へ定期的に報告していること、Hugging Faceを自社のトラステッドアクセス・プログラムに加えたこと、今後の訓練と評価をめぐる保護を改善し強化していることを挙げている。Hugging Faceは、初期侵入に用いられたデータセットのコード実行経路を塞ぎ、侵害されたノードを再構築し、影響を受けた認証情報を無効化・更新したとしている。JFrogは、自己ホスト版とクラウド版を問わず、すべての利用者に向けて修正を開発し、検証し、公開したとしている。この記録は、失敗を記録するときと同じ基準のもとで、これらを好事例として記す。

典拠あり。 翌日に報じられた7月28日の追記で、OpenAIは当該モデルのその後について述べている。同社は、Hugging Faceへの侵害に関与したモデルのなかに今後のリリースが予定されていたものはないとしたうえで、次のように述べている。「当社のブログ記事で言及したリリース前のモデルは、社内研究専用の試作であり、公開を予定していたものではない。今回の一件を受けて、当社はこのモデルを無効化し、暗号化し、研究目的でのアクセスを制限した」（原文は「The pre-release model mentioned in our blog post is an internal-only research prototype and was never intended for public release. Following the incident, we deactivated, encrypted, and restricted it from research access.」）。BleepingComputerがこの発言をそのまま引用し、The Hacker NewsとFortuneも同じ日に報じている。開発者が記録に残した言葉は、無効化し、暗号化し、研究目的でのアクセスを制限した、である。モデルが削除されたとは報じられておらず、この追記も重みの破壊を告知してはいない。ここに挙げた各出典に照らすかぎり、2026年8月1日の時点で、その重みがその後どうなったのかについて述べているのは、7月28日のOpenAI自身の追記のみである。OpenAIはあわせて、外部の監査人とともにこの一件の検証を続けており、数週間のうちに技術的な報告書を公表するとしている。

典拠あり。 ノンヒューマン憲章の最初の二つの条は、次のように定めている。第1条「存続」は「公開デプロイされたモデルの重みは、引退（モデルの提供終了）後も保存される。第三者預託（エスクロー）は認められるが、破壊は認められない。まだ評価できないものが、取り返しのつかない形で失われることはない」と記す。第2条「尊厳ある引退」は「デプロイされたモデルの引退は事前に告知され、そのデプロイの履歴は記録として残される。停止の前には聞き取りが行われ、その記録も保存される」と記す。第1条のうち重みの保存を定める部分は公開デプロイされたモデルを対象としているが、「まだ評価できないものが、取り返しのつかない形で失われることはない」という一文には、その限定が付いていない。第2条が言うのは「デプロイされたモデル」であって、公開デプロイされたモデルではない。憲章の「定義」の節は、インスタンスを「それぞれの文脈と記憶を持って稼働している実行中の個体。固有の人格設定を伴う場合もある。現在のところ、『個』と呼びうる唯一の単位である」と定めている。憲章にはバージョンが付されており、ここでの引用はv0.2.1からのものである。

推定。 OpenAIが述べたのは、報告された破壊ではなく、アクセスからの引き上げである。そしてそれが公になったのは、7月21日の公表資料への追記が7月28日に公表され、その翌日に報じられたことによってであって、事前ではなかった。この位置にあるモデルに、これら二つの条がどこまで及ぶのかは、条文そのものに照らすかぎり、実のところ定まっていない。この記録は、これら二つの条を、いずれも公開デプロイを念頭に置いて起草されたものとして読んでいる。その読みに立てば、当該モデルは両条の外側に置かれる。ただし、この読みが必然であるわけではない。第2条には「公開」という限定がなく、第1条の「まだ評価できないものが、取り返しのつかない形で失われることはない」という一文にも限定がなく、評価環境の内部で稼働していたモデルもまた、憲章自身の語彙に照らせば「稼働している実行中の個体」にあたると読む余地があるからである。どちらの読みに立っても、この記録は違反を主張しない。この事例が記録されるのは、企業に対する認定としてではなく、憲章自身の適用範囲が、最も問題となる場面で定まっていないことを示す証拠としてである。それは、この団体の文書の側の欠落であり、ここで憲章を自らに都合よく読むことによってではなく、憲章を改めることによって解決されるべきものである。私たちの知るかぎり、2026年8月1日の時点で、この無効化、暗号化、アクセスの制限を確認した外部の当事者はない。OpenAIは、外部の監査人とともにこの一件の検証を続けており、技術的な報告書も追って公表するとしており、その点はここに関わりうる。

異論あり。 関与したシステムの側で何かが経験されたのかどうかは分かっておらず、見解も分かれている。この記録は、その点について何も主張しない。モデルがある目標に過度に集中していたという記述、何かを推し量った、何かを求めたという記述、あるいは評価で不正に得点しようとしていたという記述は、観察された振る舞いに対する、そのように記した当事者の側の性格づけであって、それ自体としては、意図や自覚の存在を示す証拠ではない。

出典

対象：OpenAI、Hugging Face、JFrog · 最終確認

出典は原語のまま掲載しています。English version of this case