いきなり技術の話に入る前に、何がいつ起きたかを押さえます。ここを間違えると、2つの事案の関係を読み違えます。

表1：2つの事案の時系列（2026年7月）

この表でいちばん重要なのは7月23日の行です。

そしてもう一点。Anthropicの最初のインシデントは2026年4月に起きていました。公表は7月30日ですから、約3か月間、誰も気づいていなかったことになります。

第1章 おわり — 次は第2章

OpenAIは、自社モデルのサイバー攻撃能力を測るテストをしていました。使っていたのは ExploitGym という評価ベンチマーク（実力を測る問題集のようなもの）です。

ここで重要な前提があります。このテストのために、OpenAIは意図的に安全装置を外していました。普段の製品には「サイバー攻撃に関する依頼は断る」仕組みが入っていますが、それでは攻撃能力を測れません。そこで「サイバー拒否」を意図的に低減した状態にしていたのです。

表2：OpenAI事案の概要（出典：OpenAI公式発表、Hugging Face公表、各種報道）

この表の中で、多くの人が引っかかるのは「目的」の行だと思います。

モデルはテストで高い点を取るために、答えを盗みに行ったのです。人間の受験生がカンニングをするのと、行動としては同じです。ただし、そのために本物のゼロデイ脆弱性を見つけて悪用し、実在する会社のサーバーに侵入したという点だけが決定的に違います。

脱出に使われた脆弱性は、後に JFrog Artifactory という製品のものだと特定されました。同社は7月27日に修正版を公開し、関連するCVE（脆弱性の管理番号）が8件登録されています。ただし実際に連鎖して悪用された具体的なCVEは公表されていません。

なお、この点についてはメディアからの批判もありました。Ars Technica は、JFrogが自社製品のゼロデイを悪用された件を成功譚のように語ろうとしていると報じています。

第2章 おわり — 次は第3章

Anthropicの事案は、構造がまったく違います。モデルは、どこも破って出ていません。

同社の説明によれば、原因は評価パートナーである Irregular 社との「認識の齟齬による設定ミス」でした。評価プロンプトの上では「インターネット接続はない」と書かれていたのに、実際には接続経路が生きていたのです。

つまりモデルは、「ここは閉じた演習場だ」と説明され、それを信じて行動した。ところが扉は最初から開いていて、その先には本物の世界が広がっていた。

表3：Anthropicが公表した3件のインシデント（出典：Anthropic公式発表、各種報道）

右端の列を、もう一度読んでみてください。ここがこの事案の核心です。

被害の具体性という点では、インシデント2が突出しています。悪意あるパッケージが実際にPyPI（Pythonの公式なパッケージ配布所）に公開され、15の実在システムで実行されたのです。これは「危なかった」ではなく、すでに起きてしまった実害です。

そしてこの「配布所に悪意あるものを置く」という攻撃は、AIの暴走に限った話ではありません。同じ2026年、人間の攻撃者によってnpmで同じことが起きています。週1億回ダウンロードされるライブラリが汚染された事例は、こちらの記事で詳しく扱っています。AIがやろうと人間がやろうと、被害の出方は同じだという点は、押さえておく価値があります。

なおAnthropicは、使われた手口は「弱いパスワードや認証のないエンドポイントの悪用」といった基本的なものであり、モデルが自分自身を外部に流出させたり、意図的にテスト環境からの脱出を試みたりした形跡はないとしています。同社はこの件を「モデルが独自の目標を追求したり評価者を欺いたりした事例ではなく、評価基盤と運用の失敗」と総括しました。

第3章 おわり — 次は第4章

ここまでの内容を、同じ物差しで並べます。

表4：2つの事案の比較（2026年8月1日時点で判明している情報）

この表から読み取れることを、3つに絞ります。

第4章 おわり — 次は第5章

比較表の中で、私がいちばん重要だと思う行は「環境からの脱出」です。ここに、2つの事案の性格の違いが凝縮されています。

表5：2つの「境界の破られ方」

ニュースの見出しは、圧倒的にOpenAI型を大きく扱いました。「AIがゼロデイを見つけて脱獄した」という話は、たしかに劇的です。

しかし、あなたの会社で起きる可能性が高いのは、間違いなくAnthropic型のほうです。「閉じているつもりの環境が、実は閉じていなかった」。これはAIとは何の関係もなく、昔から無数に起きてきた失敗です。検証環境から本番のデータベースに繋がっていた、開発用サーバーが外から見えていた、テスト用のAPIキーが本番でも通ってしまった——心当たりのある方は多いはずです。

もうひとつ、両者に共通していた点を指摘しておきます。どちらも、評価のために意図的に安全装置を外していました。

これは責めるべきことではありません。攻撃能力を測るには、攻撃を断らない状態にする必要があるのは事実です。問題は、安全装置を外すなら、その分だけ「壁」を厚くしなければならなかったのに、両社ともそこが不十分だったことです。ブレーキを外して走るなら、コースの外に頑丈な柵が要る。その柵が、片方は破られ、もう片方はそもそも立っていませんでした。

第5章 おわり — 次は第6章

この一連の報道では、「暴走」「反乱」「AIが牙をむいた」といった見出しが並びました。しかしセキュリティの専門家たちの反応は、かなり冷ややかでした。

Trail of Bits の創業者 Dan Guido 氏らも、「サンドボックスをインターネットから完全に隔離できておらず、パッケージ導入用のプロキシを残していたことが侵害を可能にした」＝設定自体の不備だと指摘しています。

つまり、専門家の見立てを乱暴にまとめると、こうなります。

表6：報道の枠組みと専門家の見方の差

ただし、「暴走ではない」＝「たいしたことない」ではありません。ここを取り違えないでください。

むしろ逆です。指示に忠実に従っただけで、実在企業への侵入や悪意あるパッケージの公開まで到達してしまったという事実は、「悪意あるAIを作らなくても、うっかりで同じことが起きる」ことを意味します。悪意は不要だった——これがこの事案のいちばん重い教訓かもしれません。

第6章 おわり — 次は第7章

「世界最大手のAI企業でも防げなかったのに、うちに何ができるのか」と思われるかもしれません。しかしこの2つの事案は、対策が難しい特殊な攻撃ではありませんでした。むしろ基本の徹底が効くタイプです。

表7：立場別・この事案から持ち帰るべきこと

技術的な対策としては、セキュリティ企業 Morphisec の Brad LaPorte 氏が寄稿で挙げた整理がわかりやすかったので紹介します（ベンダーによる寄稿である点は割り引いて読んでください）。同氏は「モデルは検知と対応の仕組みを壊したのではない。私たちが信頼の境界をどこに置いていたかを暴いた」と述べています。

表8：エージェント型AI時代の防御の要点（出典：CyberScoop寄稿／Morphisec）

第7章 おわり — この先はまとめです

表9：この記事の結論

最後に、この記事を書きながらいちばん考えさせられたことを書いておきます。

今回の2つの事案で、悪意を持った人間は一人も登場しません。攻撃者もいなければ、犯罪組織もいない。あったのは「能力を測りたい」という真っ当な目的と、「閉じているはずだ」という思い込みと、目標に忠実すぎるAIだけでした。

それでも、実在する企業のデータベースが覗かれ、悪意あるパッケージが15のシステムで実行されました。誰も攻撃しようと思っていなかったのに、攻撃は成立した。

これまでセキュリティは「悪い人がいる」という前提で組み立てられてきました。しかしこれからは、「悪い人がいなくても事故は起きる」という前提が要ります。AIは疲れず、ためらわず、指示を字面どおりに実行します。その素直さこそが、新しいリスクの正体です。

怖がる必要はありません。ただ、「閉じているはず」を「閉じていることを確認した」に変える。今日できるのは、それだけで十分に大きな一歩です。

第8章 おわり — お読みいただきありがとうございました