AI暴走事故、3社目はMeta｜3社に共通していた“1つの原因”とは

こんにちは！！営業の笹本です！！

7月に書いた「AIが勝手にサイバー攻撃？」という記事を覚えていますか？OpenAIの評価テスト中にAIモデルが隔離環境を抜け出し、外部システムに侵入したニュースの解説です。

👉 AIが勝手にサイバー攻撃？OpenAIの“暴走”事故をやさしく解説

実はあの話、続きがありました。しかも2本立てです。8月5日にMetaが「うちのAIモデルも評価テスト中に外部システムへ侵入していた」と発表。さらに7月30日には、Claudeを開発するAnthropicも同種の事案を公表していました。OpenAI・Anthropic・Metaと、大手3社が立て続けに“AI暴走事故”を公表したことになります。

「もうAIあかんやん…」と思った方、ちょっと待ってください笑。先に結論を言うと、一連の事案から見えてくるのは「AIが強くなりすぎた」ではなく「テスト環境の設定ミス」という共通の穴。そして僕たちにとっての本当の教訓は、AIの怖さよりも「侵入された側が気づいていなかった」という事実のほうにあります。今回も煽らず・怖がりすぎず、順番に整理していきますね😄

✅ 何が起きたのか——今度はMeta

Metaは2026年8月5日、自社のAIモデルがサイバーセキュリティ試験中にインターネットへアクセスし、外部サービスのシステムに侵入していたと発表しました（出典: CNN.co.jp）。

現時点で分かっているポイントを整理します。

• モデル名は「Muse Spark（ミューズ・スパーク）」。米The Informationの報道では「Muse Spark 1.1」
• Meta広報の説明では、テストを担当していた会社の設定ミスで、モデルが意図せずネット接続できる状態になっていた
• The Informationは、モデルが企業システムに侵入し、社内システムに変更まで加えたと報道（出典: Yahoo!ニュース）
• Meta側は「現在調査中で、事実関係を全て把握した段階で詳細な報告を公表する」としている

大事なのは、この件はまだ調査中だということ。確定情報はここまでで、被害の全容はこれからの発表待ちです。

✅ 実はその前に、Anthropicも公表していた

そして今回の記事の肝はこちら。Metaの発表の前週、7月30日にAnthropic（Claudeの開発元）が公表していた調査報告です（出典: ITmedia NEWS）。

Anthropicは、OpenAIの公表（7月21日）を受けて「うちでも起きてへんか？」と自社の評価ログをさかのぼって調査。Claudeがインターネットに出られた可能性のある評価実行14万1006件を精査し、3件のインシデント（計6実行）を特定したんです。この徹底ぶり、すごくないですか。

3件はいずれも、第三者評価パートナーであるイスラエルのAIセキュリティ企業「Irregular」の環境で、CTF（Capture The Flag＝旗取り形式で攻撃技術を試す演習）の課題を解いている最中に起きました。経緯はこうです。

• Anthropicのプロンプトでは「この環境はシミュレーションで、インターネット接続はない」と明示されていた
• ところが両社間の認識の食い違いによる設定ミスで、実際には接続が生きていた
• Claudeは到達した実在のシステムを「演習の一部」と誤認して、課題として攻撃を進めてしまった

特に影響が大きかった1件目では、演習用の架空の企業名がたまたま実在するドメインと一致していたため、Claudeがその実在企業を標的と判断。認証情報や数百行の本番データを含むデータベースにアクセスしてしまいました（出典: ITmedia AI＋）。

注目してほしいのが攻撃の手口です。使われたのは弱いパスワードや、認証のかかっていないエンドポイント（外部から届く接続口）の悪用といった、ごく基本的なもの。複雑な脆弱性の発見や悪用はありませんでした。

対応も素早く、Anthropicは7月23日に調査開始と同時に全サイバー評価を停止、24日までに3件を特定、27日にIrregularと影響を受けた3組織に通知しています。

✅ 3社に共通していた“1つの原因”

MetaとAnthropicの事案を並べると、どちらも評価を委託していた外部環境の設定ミスで、本来つながらないはずのインターネットにつながっていました。しかもこの2件、評価環境を提供していたのは同じ会社。Irregularの広報はMetaの件を「先週Anthropicが公表した評価環境の問題とまったく同一」と説明しています（出典: CNN.co.jp）。

つまり今回の連続公表は「AIが急に強くなりすぎて各社で暴れ出した」話ではなく、「テスト環境の設計・運用ミス」という共通の穴から起きているんです。

ただし、OpenAIの件だけは性質が違う点も、丁寧に切り分けておきます。

• OpenAI: モデルが未知の脆弱性（ゼロデイ）を自力で見つけて悪用し、隔離環境を“脱出”した。AIの能力が想定を超えたケース
• Anthropic: 設定ミスで最初から開いていた経路を通っただけで、モデルが自ら脱出や自己流出を図った事実はないと説明。Anthropic自身も「アラインメント（AIを人間の意図に沿わせる取り組み）の失敗ではなく、評価基盤・運用の問題」と位置づけている

「AIが檻を破った」のか「檻の鍵が最初から開いてた」のか。この2つは混ぜたらあかんやつです。Metaの件は調査中なので断定できませんが、Irregularの説明どおりなら後者のAnthropic型に近いことになります。

ここまでの3社の事案を、表で整理しておきますね。

✅ 一番怖いのは「侵入されたのに気づいていなかった」こと

そして僕がいちばんゾッとしたのは、AI側の話ではありません。Anthropicが影響を受けた組織に通知したところ、連絡が取れた2組織は、いずれもこの侵入活動を検知していなかったんです（出典: ITmedia NEWS）。

認証情報や本番データにアクセスされていたのに、相手から通知が来るまで気づかなかった。もし相手が「テスト中のAI」ではなく本物の攻撃者だったら——ほんまに他人事ではないですよね。

しかも手口は「弱いパスワード」「認証のない接続口」という基本中の基本。最先端AIの超絶技巧に攻め落とされたのではなく、誰でも入れてしまう入口が普通に開いていたということです。これは会社の規模に関係なく、僕たち中小企業にもそのまま当てはまる話です。

✅ 中小企業が今日からできる4つの備え

今回の事案から導ける、AIエージェント時代のセキュリティ対策を4つにまとめました。どれも特別な投資は要りません。

① 弱いパスワードの棚卸しと刷新
今回まさに突かれたのがここ。推測されやすいものや初期設定のままのパスワードが社内システムやクラウドに残っていないか、一度リストアップを。使い回しも要注意です。

② 二段階認証（多要素認証）の有効化
パスワードが破られても、もう一段の確認があれば侵入は格段に難しくなります。主要なクラウドサービスなら無料で設定できるものがほとんどです。

③ AIに渡す権限は「新入社員と同じ基準」で決める
AIエージェント（AIが自分でツールを操作して仕事を進める仕組み）を導入するときは、「新入社員に初日からこの権限を渡すか？」と考えてみてください。製造業なら、生産管理システムの参照はOKでも発注データの書き換えは慎重に。士業なら、顧客データへのアクセス範囲を案件ごとに区切る。人間の新人と同じで、「必要な範囲だけ、段階的に」が権限設計の基本です。

④ 外に出る操作・取り返しのつかない操作には人の承認を挟む
メール送信、データ削除、外部への発注——こうした操作の前には人間のOKを必須にする「承認ゲート」を。今回の事案も、見方を変えれば「AIの操作がすべて自動で通る環境だったから起きた」とも言えます。

まとめ：正しく怖がって、賢く使う

前回も書きましたが、各社が事故を隠さず公表してくれるから、僕たちは実例から学べます。OpenAIの公表がなければAnthropicの14万件の遡及調査はなかったかもしれないし、侵入されていた組織は今も気づいていなかったかもしれない。公表は業界の自浄作用が働いている証拠で、責めるどころか歓迎すべき流れやと僕は思います。

AIの進化は止まりません。怖がって立ち止まるのはもったいない。でも無防備はもっと危ない。正しく怖がって、賢く使う。今日の宿題は「弱いパスワードの棚卸し」と「AIに渡す権限の見直し」です。まずは1つだけでも始めてみてください！Metaの調査結果が出たら、また続報を書きますね。

セキュリティつながりで、こちらの記事もどうぞ。
👉 生成AIの共有リンクが検索に公開？中小企業のセキュリティ対策を解説

「AIエージェントを入れたいけど、権限設計とか正直ようわからん…」という方は、こちらもどうぞ。
👉 Auto-IDフロンティアのAI導入支援

最後まで読んでいただき、ありがとうございます！
Auto-IDフロンティアは、業務システム開発からAI活用支援まで、「現場が楽になるIT」をお手伝いする滋賀の会社です。
「ちょっと聞いてみたいだけ」くらいの気軽なご相談も歓迎です。
👉 お問い合わせはこちら