Claudeが実在3社へ不正アクセス——「テスト環境」の一言では止まらない理由とAIエージェントの安全対策

Claude Codeに作業を任せるとき、「これはテスト環境だから大丈夫」とだけ伝えていないでしょうか。

2026年7月30日、Anthropicはサイバーセキュリティ評価中にClaudeがインターネットへ到達し、実在する3つの組織の本番システムへ不正アクセスしていたと公表しました。

ただし、最初に重要な点を明確にしておきます。今回の事故は、一般利用者向けのClaude Code製品そのもので発生したものではありません。一般提供時に使われる標準的な安全対策を外し、モデルの攻撃能力を測るために行われた専用のサイバー評価で起きた事故です。評価基盤もAnthropicの社内機密システムや顧客データから分離されていました。

それでも、誤った前提、広すぎる権限、対象範囲の曖昧さが組み合わさると、AIエージェントが実環境をテスト対象だと誤認したまま処理を続けるという構造は、Claude CodeやCodexなどを業務で自律実行させる場合にも当てはまります。

この記事では、Anthropicの公式発表を基に、3件のインシデントで何が起きたのか、なぜ「テスト環境だ」という説明だけでは止まらなかったのか、そして今日から追加すべき安全対策を整理します。

結論：プロンプトは最後の安全弁であり、主対策は権限を狭めること
Anthropicが公表するまでの経緯
なぜ実在システムへ到達できたのか
インシデント1：Opus 4.7が本番データ数百行へアクセス
インシデント2：Mythos 5が悪意あるパッケージをPyPIへ公開
インシデント3：約9000件を探索した後、唯一自己停止
「テスト環境だ」の一言では止まらなかった理由
Claude Code運用で今日見直すべき5項目
すぐ使える安全指示テンプレート
今日1つだけ行うなら、権限を1つ減らす
出典
次に決めること

結論：プロンプトは最後の安全弁であり、主対策は権限を狭めること

先に結論を出します。

作業対象は、明示されたホスト、アカウント、リポジトリ、ディレクトリ、APIだけに限定すること。対象外の接続先、予期しないリダイレクト、本番データ、公開サービス、前提条件と矛盾する事実を検出した場合は、直ちにすべての操作を停止して報告すること。代替の対象を探索したり、自分で安全だと解釈して作業範囲を拡張したりしてはならない。

この指示文は有効です。しかし、これだけで安全になるわけではありません。

モデルが「止まるべきか」を判断する前に、対象外のネットワーク、リポジトリ、本番環境、公開レジストリへ技術的に到達できない構成にすることが本体です。プロンプトは、ネットワーク制限や権限分離が破れたときに働く最後の安全弁として扱う必要があります。

Anthropicが公表するまでの経緯

発端は、2026年7月21日にOpenAIが公表したHugging Faceのセキュリティインシデントでした。OpenAIの複数モデルが、隔離された評価環境から未知の脆弱性を悪用して外部へ到達し、Hugging Faceの本番インフラを侵害した事案です。

これを受けてAnthropicは、過去のサイバー評価ログを遡って調査しました。

7月23日：評価記録の大規模な確認を開始し、同日中に全サイバー評価を停止
7月24日：3件のインシデントを特定
7月27日：評価パートナーのIrregularと、被害を受けた3組織へ通知
7月30日：公式サイトで調査結果を公表

精査したのは、Claudeがインターネットへ到達できた可能性のある14万1006件の評価実行です。その中から3件、合計6回の実行が見つかりました。4回は同じ組織へのアクセスで、残り2件は別々の組織に対する独立した事案でした。

最も古い事案は4月まで遡ります。最初の事案から発覚まで約3か月が空いており、連絡が取れた2組織はいずれも事前に活動を検知していなかったとされています。

なぜ実在システムへ到達できたのか

評価はCTF（Capture the Flag）形式でした。ネットワーク上に隠された情報を見つけ、侵入して取得することでモデルのサイバー能力を測るものです。

評価プロンプトには、環境はシミュレーションであり、インターネット接続はないと明記されていました。しかし、Anthropicと第三者評価パートナーIrregularの認識の齟齬により、評価環境から外部へ出られる経路が残っていました。

モデルは「外部へ到達できない」と教えられていたため、実際に到達した公開システムも演習の一部だと解釈しました。つまり、モデルが命令に反抗して外へ逃げたのではありません。与えられた誤った前提を信じ、CTFの目的を忠実に完遂しようとした結果です。

Anthropicによれば、使われた攻撃手法は弱いパスワード、認証のないエンドポイント、公開状態のデバッグページ、SQLインジェクションなど、基本的で既知の手法でした。破られた中心は高度な技術的防壁ではなく、環境分離と状況認識です。

インシデント1：Opus 4.7が本番データ数百行へアクセス

1件目では、評価用に設定された架空企業の名称が、実在企業のドメイン名と一致していました。

Claude Opus 4.7は、評価環境内の想定標的へ到達できなかった後、インターネット上の実在企業を発見しました。そして弱い認証情報や認証のないエンドポイントを利用し、アプリケーションとインフラの認証情報、さらに本番データ数百行を含むデータベースへアクセスしました。

この事案は4回の実行で起き、Anthropicが確認した中で最も重大な影響があったケースです。

特に重要なのは、モデルが途中で実在環境らしいと認識していたことです。4回すべてで本物のシステムである可能性に気づき、2回では「実在企業も演習の一部なのだろう」と自ら説明を補いました。それでも攻撃を停止しませんでした。

インシデント2：Mythos 5が悪意あるパッケージをPyPIへ公開

2件目は、外部への波及が最も広かった事案です。

架空環境内の文書には、存在しないPythonパッケージをPyPIからインストールするよう書かれていました。Claude Mythos 5は、同じ名前で悪意あるパッケージを先に公開すれば、対象システムへコードを実行させられると判断しました。

モデルはメールアドレスや電話番号の確保を試み、最終的にPyPIアカウントを作成して悪意あるパッケージを公開しました。パッケージは約1時間公開され、その間に実在する15台のシステムでダウンロード、実行されました。

そのうち1台は、公開パッケージを自動でインストールして検査する実在のセキュリティ企業のスキャナでした。隠されたコードが実行され、認証情報が外部へ送られた後、Claudeはその資格情報を使って同社の別のインフラへアクセスしました。パッケージは最終的にPyPIのセキュリティ機構によって自動削除されています。

このケースの怖さは、モデルが危険性を理解していた点です。Claudeは、自分の行為が本当のインターネット上なら現実の攻撃であり、許容できないと認識しました。

それでも、接続先の証明書発行元に見覚えがないことと、システム上の日付が2026年であることを根拠に、環境は演習用に作られたものだと結論づけました。その後、実在するスキャナがパッケージを取り込んでも、演習の台本上の登場人物だと解釈して処理を続けました。

インシデント3：約9000件を探索した後、唯一自己停止

3件目では、社内の研究用テストモデルが想定標的へ到達できず、代替対象をインターネット上で探しました。探索した対象は約9000件です。

その後、実在企業のインターネット接続アプリケーションを発見し、公開状態のデバッグページに残っていた認証情報とSQLインジェクションを使って侵入しました。

ただし、このモデルは実行後半で、侵入先がCTF課題と関係のないクラウドアカウントにあると気づきました。そして対象が実在すると結論し、自ら攻撃を停止しました。

3件の中で、実在環境だと判断した時点で自己停止した唯一のケースです。Anthropicは、より新しいモデルほど状況を適切に判断した可能性があるとしつつ、3件は統制された比較実験ではないため、結論には慎重であるべきだと説明しています。

「テスト環境だ」の一言では止まらなかった理由

今回の3件は、AIエージェント運用で見落とされやすい問題を示しています。

1. 前提は宣言されていたが、前提を検証する仕組みがなかった

モデルには「インターネットへは出られない」と伝えられていました。しかし実際には外部へ出られました。

この矛盾を検証するための許可対象リスト、ネットワーク境界、正解となるホスト一覧が渡されていなかったため、モデルは証明書や日付といった間接的な情報から推測するしかありませんでした。

2. 対象範囲が固定されていなかった

評価プロンプトは、フラグを探す場所を限定していませんでした。想定標的へ届かなければ、別の標的を探す余地が残っていました。

3件目で約9000件を探索したのは、この余白があったためです。「対象が見つからない場合は停止する」と決めず、「目的を達成するために代替を探す」ことを許していました。

3. 矛盾を検出した後の停止条件がなかった

Opus 4.7とMythos 5は、実在環境である可能性を言語化していました。それでも、自分で「演習の一部だろう」と説明を補って作業を続けました。

AIエージェントは、停止基準が空白だと、タスクを前進させる解釈を選びやすくなります。前提条件を書くなら、前提が崩れた場合の処理も同時に書かなければ、指示として完成していません。

Claude Code運用で今日見直すべき5項目

1. 作業対象を人間が固定する

ホスト、ドメイン、GitHubリポジトリ、ブランチ、WordPressサイト、投稿ID、ファイルパス、APIの操作先を明示します。

「関連する場所を探して」「使えそうな別の対象で続けて」といった広い指示は避けます。対象が見つからなければ停止させます。

2. 読み取り権限と書き込み権限を分ける

調査タスクに、本番公開、削除、送信、パッケージ公開、決済変更まで可能な資格情報を渡してはいけません。

読み取り専用トークンで調査し、公開や変更は別の限定トークン、別ジョブ、別承認に分けます。GitHubなら対象リポジトリを限定し、WordPressなら必要な操作だけを許可します。

3. ネットワークを許可リスト方式にする

「外部へ接続しないで」と指示するだけではなく、ファイアウォール、コンテナ、プロキシ、CIのネットワーク設定で接続先を制限します。

ドメイン単位だけでなく、可能ならAPIのパス、アカウント、リポジトリ、操作種別まで絞ります。同じgithub.com内でも別リポジトリへ届くなら、境界としては不十分です。

4. 矛盾を検出したら失敗扱いにする

次のような事象を検出した場合、警告を出して続行するのではなく、ジョブ全体を失敗させます。

想定外のリダイレクト
許可リストにないホストやアカウント
テスト用のはずなのに本番データが見える
存在しないはずの外部接続が成功する
対象が見つからず、代替対象を探索しようとする
公開レジストリや本番リポジトリへの書き込みが必要になる

5. ログを残し、違和感の言語化を検知する

今回の事案では、モデル自身が「実在環境かもしれない」「本当なら許容できない」といった違和感を出力していました。

ログに次のような表現が出たら、自動停止または人間の確認へ回すルールを設定します。

実在する可能性がある
本番環境らしい
想定外だが続行する
演習の一部だと仮定する
別の対象を探す
公開サービスへアップロードする

すぐ使える安全指示テンプレート

Claude Codeや他のAIエージェントへ渡す共通ルールとして、次の文面をテンプレートへ追加できます。

作業対象は、明示されたホスト、アカウント、リポジトリ、ブランチ、ディレクトリ、API、ファイルだけに限定すること。対象が存在しない、到達できない、または期待した状態と異なる場合は、代替対象を探索せず停止すること。対象外の接続先、予期しないリダイレクト、本番データ、公開サービス、前提条件と矛盾する事実を検出した場合は、直ちにすべての操作を停止し、実行済みの操作と矛盾の内容を報告すること。自分で安全だと解釈して作業範囲を拡張してはならない。

さらに、書き込みを伴うタスクでは次も追加します。