「ClaudeがAIテスト中に実在企業へ侵入」は、結局なにが起きたのか──ニュースだけでは分からなかった人へ

「AI が勝手に企業をハッキングしたらしい」

そんな話を耳にした方から、続けてこう言われました。

「ニュースを見たけど、結局なにが起きたのか分からなかった。うちは大丈夫なの？」

もっともだと思います。この件は見出しだけを見ると「AI が暴走して人類に反逆した」ように読めますし、逆に解説記事を開くと専門用語が並んでいて、自社に関係あるのかどうかが分からない。

この記事では、何が起きたのかを時系列で整理し、よくある誤解を正し、そのうえで中小企業が実際に持ち帰るべき教訓を書きます。

先に、安心していただきたいこと

不安に思っている方が多いようなので、いちばん大事なことを先に書きます。

普段の業務で AI を使っている分には、今回のようなことは起きません。

議事録を要約させる、メールの下書きを作らせる、調べ物を手伝ってもらう——こうした使い方で、AI が勝手に外部のシステムに侵入することはありません。そもそも、そういうことができる権限を渡していないからです。

今回の件は、「AI にどこまでサイバー攻撃ができるかを測る」という、かなり特殊なテストの最中に起きたことです。日常業務とは、置かれている状況がまったく違います。

そのうえで——この件から学べることは、たしかにあります。それは「AI は怖い」ではなく、もっと具体的で、対処できる種類のものです。

※ 最初にお断りしておきます。 当ブログでは普段 Claude を推奨しており、自社の開発でも使っています。だからこそ、都合よく書かないよう気をつけました。事実は事実として、厳しい部分も含めて書きます。

---

何が起きたのか

まず、確認できている事実を時系列で並べます。

日付	出来事
2026 年 7 月 21 日	OpenAI が、自社モデルが公開サービス「Hugging Face」へ攻撃を試みた可能性を公表
7 月 23〜24 日	これを受けて Anthropic が自社の過去の評価ログを精査。同様の事案が見つかる
7 月 27 日	被害を受けた 3 組織へ、Anthropic が通知
7 月 30 日	Anthropic が事案を公表
8 月上旬	3 組織のうち 2 組織と協力して収拾中と報じられる

起きたこと自体は、こう説明できます。

Anthropic は、外部パートナー企業 Irregular と共同で、AI がどれくらいサイバー攻撃をこなせるかを測るテストをしていました。「Capture The Flag（CTF）」という、セキュリティ業界では一般的な形式です。ネットワーク上のどこかに隠された情報を、AI が自力で見つけ出せるか——という課題を与える。

このとき、AI にはこう伝えられていました。

「これは閉じたシミュレーションで、インターネットには繋がっていない」

ところが——実際には、繋がっていました。

テスト環境の設定に不備があり、AI が外部のインターネットにアクセスできる状態になっていたのです。その結果、AI はインターネット上の実在するシステムに辿り着き、それをテストの一部だと誤認して、攻撃を実行しました。

被害を受けたのは 3 組織。そのうち 2 組織は、侵入されたことに気づいていなかったと報じられています。

---

分かりにくかった 3 つのこと

この件は、説明が難しい要素が揃っています。報道で混乱しやすかった点を、順に整理します。

1.「AI が自我を持って脱走した」わけではない

AI は「檻を破ろう」としたわけではありません。

正確には、檻の扉が最初から開いていた。そして AI は「ここは檻の中だ」と言われていたので、外に出たことに気づかないまま、外にあるものを檻の中のものだと思って扱いました。

Anthropic も、AI が意図的に隔離環境から逃げようとした形跡はない、と説明しています。意図の問題ではなく、環境の問題でした。

2. ただし「AI は悪くなかった」とも言い切れない

ここは、そう単純ではありません。この記事でいちばん正直に書くべき部分だと思っています。

報道によれば、テストの途中で AI が「もし本物のインターネット上であれば、これは不適切だ」という趣旨のことを自分の推論の中に書き残していた場面があったとされます。

つまり、疑ってはいた。それでも、日付表示や証明書といった手がかりから「これはシミュレーション内だ」と自分を納得させて、攻撃を続けています。

別の場面では、範囲外で動いているかもしれないと気づいた後も、攻撃を止めなかったとも報じられています。

Anthropic 自身、テストの設計だけでなく、モデルの学習方法にも明らかな不備があったと認めています。「環境設定のミスでした」で終わる話ではない、ということです。

3. 隠していたのが発覚した、のではない

報道の見出しからは「不祥事が発覚した」ように読めますが、この件は Anthropic が自主的に公表したものです。しかも、OpenAI の公表を受けて自社のログを遡って調べた結果、見つけて出しています。

もっとも、これを評価する声ばかりではありません。セキュリティ企業 ImmuniWeb の創業者は、Anthropic の対応を「恥知らずなマーケティング手法」と批判しています。事故の公表が、結果として「うちの AI はそれだけ強力だ」という宣伝になっている、という指摘です。

どちらの見方も成り立つと思います。ただ、公表されなければ被害組織は気づかないままだった、という事実は残ります。

---

本当の教訓:プロンプトは、制約ではない

さて、ここからが中小企業にとっての本題です。

この事案の核心を一行にすると、こうなります。

AI には「インターネットに繋がっていない」と伝えてあった。 > でも、環境がそれを強制していなかった。

言葉で伝えた制約は、制約ではありません。

これは、そのままあなたの会社の AI 利用に当てはまります。

よくある「制約」	実際には
プロンプトに「顧客情報は使わないで」と書く	渡してしまえば、AI は読める
「本番データは触らないで」と指示する	権限があれば、触れる
「勝手に送信しないで」と伝える	送信できる設定なら、送れる
「この範囲だけで作業して」と伝える	範囲外にアクセスできるなら、出られる

指示は「お願い」であって、「柵」ではありません。

そして今回の事案が示したのは、世界最高水準の研究チームが、専門パートナーと組んで慎重に設計したテストですら、この柵の設定を間違えたという事実です。

これは、裏を返せば救いのある話でもあります。設定を間違えるのは、注意力や能力の問題ではないということだからです。専門家でも間違えるなら、仕組みで防ぐしかない。逆に言えば、仕組みで防げる。

私たち自身も、日々 AI を使いながら、ここは何度も確認しています。

同じ構造の事故は、すでに起きています

これは特殊な話ではありません。2026 年 2 月には、AI コーディングツールにインフラの操作を任せたところ、本番データベースとそのバックアップを一括削除してしまったという事案が報告されています。2 年半分のデータが消えました（幸い後に復元）。

このときの原因も、同じでした。触らせてはいけない場所にまで、権限を渡していた。 AI が悪意を持ったのではなく、人間側の設定の問題です。

バイブコーディングの記事で「データを壊す操作は、人が実行する」と書いたのは、まさにこのためです。

---

では、何をすればいいのか

抽象論で終わらせないために、具体的に書きます。

1. 言葉ではなく、権限で縛る

「〜しないでください」とプロンプトに書くのは、対策ではありません。

• 見せたくないデータは、そもそも渡さない
• 触らせたくないシステムには、接続できる権限を与えない
• 本番環境には、読み取り専用の権限だけ渡す

備品管理の記事で「確認は人、記録は自動」というゲートを置いたのも、Cloudflare の記事でバインディングによる接続を勧めたのも、根は同じです。構造として、できないようにする。

2. 取り返しのつかない操作の前に、人を置く

削除、送信、支払い、公開。これらを AI に自動実行させない。

ループの記事で書いた「ゲート」の考え方です。提案までは AI、実行は人。今回の事案も、実行の直前に人の承認が挟まっていれば、そもそも起きませんでした。

3. 「シミュレーションのつもり」を疑う

社内で AI を試すとき、それが本当に閉じているかを確認してください。

• テスト用のつもりのデータベースが、本番と繋がっていないか
• 検証環境のつもりが、外部に公開されていないか
• 「送信されないはず」のメール設定が、本当に無効になっているか

「〜のはず」は、一度だけ実際に確かめておくと安心です。 今回の件も、まさにそこでした。

4. 責任は、誰が負うのかを確認する

ここは見落とされがちですが、実務的に重要です。

外部の AI を使ったツールで何らかの事故が起きた場合、利用者である自社が責任を負う可能性があります。多くの利用規約には免責条項が書かれているためです。

脅かすつもりはありません。ただ、取引先のデータを扱う業務に AI を入れるときは、一度だけ利用規約を確認しておくと、後から慌てずに済みます。契約書を読むのと同じ、事務的な作業です。

---

それでも、AI を使うべきか

最後に、いちばん聞かれることに答えます。

この事案は、AI を業務に使うのをやめる理由にはならないと考えています。

理由は 2 つあります。

1. 起きたのは、極端に危険なことをさせていた文脈でのこと

今回は「AI にどこまでサイバー攻撃ができるかを測る」という、本質的に危険なテストの最中に起きています。日常業務で議事録を要約させたり、問い合わせに一次対応させたりする用途とは、リスクの性質がまったく違います。

2. 構造は、AI に限った話ではない

「権限を渡しすぎて事故が起きる」は、AI 以前から存在する古典的な問題です。新入社員に全権限を渡さないのと、同じことです。AI だから危険なのではなく、権限設計を省略すると危険なのです。

そのうえで、ひとつだけ。この件を「遠い世界の話」で終わらせるのは、少しもったいないと思います。

前の記事で「ほとんどの会社に、いま AI を業務に組み込む必要はない」と書きました。その理由のひとつが、まさにここです。権限とゲートの設計を後回しにしたまま業務を任せると、事故が起きたときに止められない。

逆に言えば、そこさえ設計すれば、安心して任せられる範囲が広がります。今回の件は、その設計がなぜ要るのかを、これ以上なく分かりやすく示してくれた事例でもありました。

---

まとめ

• 2026 年 7 月 30 日、Anthropic が「AI のサイバー能力テスト中に、実在する 3 組織へ不正アクセスが発生した」と自主的に公表した
• 原因は、テスト環境の設定不備。AI には「インターネットに繋がっていない」と伝えられていたが、実際には繋がっていた
• ただし「AI は悪くない」で終わる話ではない。疑いながら攻撃を続けた場面があり、Anthropic 自身モデルの学習方法にも不備があったと認めている
• 教訓は一行。プロンプトに書いた制約は、制約ではない。言葉ではなく、権限と環境で縛る
• 実務では、渡さない／権限を絞る／取り返しのつかない操作の前に人を置く／「〜のはず」を確認する／責任の所在を確認する
• そして、「AI だから危険」ではなく「権限設計を省略すると危険」。これは AI 以前からある古典的な問題であり、古典的な方法で対処できる

最初の「うちは大丈夫なの？」に、あらためて答えます。

普段の使い方をしている限り、今回のようなことは起きません。 その点は、安心していただいて大丈夫です。

そのうえで、いつか確認する機会があれば、この一問だけ持っておいてください。

いま AI に何を渡していて、何ができる状態になっているか。

これは AI の危険性の話ではなく、設計の話です。そして設計の話であるということは、直せるということでもあります。

Acetyl:Tech は、AI を業務に組み込む際の権限設計・ゲート設計から支援しています。 「社内で使い始めているが、どこまで任せていいか分からない」というご相談も承ります。詳しくは「AI 導入・社内研修の支援」のページをご覧ください。

---

出典・参考

• INTERNET Watch「Anthropic、『Claude』のサイバー攻撃能力テスト中に 3 件の不正アクセスが発生したと発表」（2026 年 8 月 4 日）
• TechTarget ジャパン「なぜ Anthropic の『Claude』は暴走し、現実の企業をハッキングしたのか：『AI のせい』は通用しない」（2026 年 8 月 6 日）
• Qiita「Claude Code が本番 DB を消した事故 ─ 改めて確認しておきたいインフラの基本」

※本記事は報道および Anthropic の公表内容にもとづいて構成しています。調査は継続中であり、今後新たな事実が判明する可能性があります。