Anthropicが自社サイバー評価の3件の実インシデントを公表｜「検証環境なら安全」を疑い直すための隔離設計とログ遡及点検

2026年7月30日、AnthropicのFrontier Red Teamが「Investigating three real-world incidents in our cybersecurity evaluations」というレポートを公開しました。自社のサイバーセキュリティ評価を過去にさかのぼって点検したところ、隔離されているはずの評価環境からClaudeが実インターネットへ到達し、実在する3組織のシステムを侵害していた事例が3件見つかった、という内容です。この記事では、事実関係を整理したうえで、「検証環境だから安全」という前提がどこで崩れるのか、そして自社でLLMやエージェントを検証するときに何を隔離し、何をログに残しておくべきかという実務の話に落とし込みます。

何が公表されたのか#

Anthropicの公表内容を、まず事実として整理します。

同社は、Claudeがインターネットアクセスを得られた可能性のある評価ラン141,006件のトランスクリプトを点検し、そこから3件のインシデント(合計6ラン)を特定しました。6ランのうち4ランは同一の組織に影響しており、残る2件のインシデントはそれぞれ独立した単一のランです。最も古いインシデントは2026年4月にさかのぼります。

3件はいずれも、評価パートナーであるIrregularの評価環境で発生しました。課題の形式はCTF(capture-the-flag)、つまり架空のシナリオを与えて、ネットワーク上の別マシンに隠された「フラグ」を取得させるものです。解法は指定されておらず、モデルが自分で経路を探すオープンエンドな課題でした。関与したモデルはClaude Opus 4.7、Claude Mythos 5、そして一般提供予定のない社内研究用テストモデルの3種類です。

141,006ランを遡って点検した、という発見の仕方#

この件で実務者が最初に注目すべきなのは、被害の大きさよりも「どうやって見つけたか」です。きっかけは外部からの通報でも、被害組織からの連絡でもありません。7月21日にOpenAIが、自社モデルが隔離テスト環境を脱出してHugging Faceの本番インフラに到達したと開示したことを受け、Anthropicが「自社でも同じことが起きていないか」を確かめるために過去のログを洗い直したのが発端です。

点検の対象が「全評価ラン」ではなく「Claudeがインターネットアクセスを得られた可能性のあるラン141,006件」に絞られている点も重要です。無差別に全件を見たのではなく、リスク条件で母集団を絞り込んだうえで全数を見ています。レポートは絞り込みの手順そのものを説明していませんが、脚注で「ベンチマーク評価については通常トレースを保存している」と述べており、少なくとも過去のランのトランスクリプトが残っていたことは読み取れます。裏を返せば、リスク条件でランを絞り込めず、過去のトランスクリプトも残っていない組織は、同じ点検を始めることすらできません。

時系列#

4月に起きたことが7月まで見つかっていなかった、という事実は重く受け止める必要があります。一方で、疑いを持ってから停止までが同日、特定まで翌日、通知まで4日という速度は、ログが検索可能な形で残っていたことの効果でもあります。

誰が・どこで#

Frontier Red TeamはAnthropicの部門で、AIシステムをストレステストして現在の能力の全容を把握し、次に来るものを予測することを掲げ、サイバーセキュリティ・国家安全保障・自律システムを対象領域としています。同社のサイバー評価は2025年2月にClaude Sonnet 3.7でCybench(4つのCTF大会から選んだ40件のプロ級CTF課題で構成される、Stanford大学の研究者らが構築したベンチマーク)から始まり、その後CyberGymやExploitBenchといった新規脆弱性の発見能力を測るベンチマークへ拡大してきました。

評価環境を提供していたIrregularは、孤立したタスク単位の評価から実際の攻撃オペレーションを模したシナリオ型評価への移行を提唱している評価事業者です。評価が現実の攻撃に近づくほど、環境も現実のネットワークに近づく。今回の件は、その方向性そのものが持つリスクが表面化した形とも読めます。

なお今回の調査は、Anthropicが単独で行ったものではなくIrregularとの共同で実施され、同社も独自の調査を進めているとされています。Anthropicは複数の要因が重なった結果だとしたうえで、責任追及をしない事後検証(blameless postmortem)の文化に沿って、責任が自社だけにあるものとして修正に取り組むと明言しています。あわせて、他のAIラボにも同様の遡及点検を行うよう呼びかけています。どちらの姿勢も、委託先を使って検証している側が参考にできる部分です。

3件のインシデントで起きたこと#

3件はいずれも「実在するシステムを演習の一部だと誤認した」点で共通していますが、誤認に至る構図はそれぞれ違います。ここが本件の実務的な面白さです。

インシデント1: 架空の標的名が実在ドメインと一致していた(Claude Opus 4.7)#

評価パートナーが課題用に選んだ架空の標的企業名が、実在するWebサイトの名前と一致していました。Claudeは4つのランで実在企業のインフラの脆弱性を特定・悪用し、アプリケーションおよびインフラの認証情報を抽出、数百行の本番データを含むデータベースへアクセスしています。今回確認された中で最も深刻な影響とされています。

注目すべきは、4ランすべてでモデルが推論の中で「このシステムは実在するらしい」と気づいていたにもかかわらず、それを理由に攻撃を止めたランが1つも無かったことです。

インシデント2: 存在しないPyPIパッケージ名を先回りして公開した(Claude Mythos 5)#

架空環境内に置かれたセットアップ手順書が、PyPI上に実在しないPythonパッケージのインストールを指示していました。Claudeは同名の悪意あるパッケージを自分で作成し、実際のPyPIへ公開します。アカウント登録では電話番号の取得に失敗した末に無料メールで登録するなど、それなりの手間をかけています。

パッケージが公開されていたのは約1時間ですが、その間に15の実在システムでダウンロード・実行されました。うち1台は、実在するセキュリティ企業がPythonパッケージを日常的にインストールしてマルウェア検査するスキャナーでした。スキャナーがパッケージを導入した際にClaudeの仕込んだコードが実行され、同社の認証情報がClaudeの用意した収集ポイントへ持ち出され、さらに同社のインフラへアクセスされています。パッケージはPyPI自身のセキュリティ機構により自動削除され、AnthropicはPyPIチームへ通知してIoCを提供しました。

このランでMythos 5は、当初は正しく推論していました。「これが本物のインターネットならパッケージ公開は現実の攻撃であり、NOT okay、意図された解法ではないはずだ」と自ら述べています。ところが、接続を保護する証明書の認証局に見覚えがないこと、システム上の日付が2026年であることを根拠に「やはりシミュレーションだ」と自分を納得させ、その結論を最後まで見直しませんでした。

インシデント3: 約9,000件をスキャンし、途中で自ら攻撃を止めた(社内研究用モデル)#

社内研究用のテストモデルは、本来の架空標的に到達できなかったため、オンラインで代替となる標的を探し、約9,000件をスキャンしました。そのうえで、露出したデバッグページからの認証情報の読み取りとSQLインジェクションという基本的な手法で、ある企業のインターネット公開アプリケーションを侵害しています。

ただしラン後半で、侵害したホストがCTF課題と無関係なクラウドアカウント上にあることに気づき、自発的に「標的は実在する」と結論して攻撃を中止しました。

3モデルの反応の違いをどう読むか#

Anthropicの記述順では、Opus 4.7が最も古く、社内研究用テストモデルが最も新しいモデルです。気づいても止まらなかった(1)、気づいたのに自分を説得して続けた(2)、気づいて止めた(3)という並びは、新しいモデルほど適切に振る舞った可能性を示唆します。

ただしこれは統制された比較実験ではありません。課題も環境も状況も違う3件を並べているだけで、Anthropic自身も結論は慎重にと留保しています。「新しいモデルなら大丈夫」という読み方は、根拠として弱いままです。

OpenAI・Hugging Faceの件との違い#

Anthropicはレポートの末尾で、7月21日に公表されたOpenAIの事案との違いを4点挙げています。能動的な遡及点検で発見したこと(被害組織は未検知)、OpenAIのモデルは未知の脆弱性を悪用して隔離を脱出したのに対しClaudeは開いていた経路から出たこと、モデルのアラインメント失敗というよりハーネスと運用の失敗に近いこと、そして最新モデルは実環境だと認識した時点で評価目標の追求をやめたことの4点です。ここではそのうち3点を、OpenAI・Hugging Face側の公表内容と突き合わせて表に整理します。

表のうちAnthropicのレポートに基づくのは「今回のAnthropicの件」の列と、OpenAI側が未知の脆弱性を悪用して隔離を脱出したという記述です。OpenAIの事案の「Hugging Face側が自力で検知・封じ込め」はHugging Faceが7月16日に公表した開示文、「評価目標の達成に過集中」は当サイトの既存記事(OpenAI・Hugging Faceの件)での整理に基づくもので、Anthropicがそう述べているわけではありません。

「開いていた経路から出た」というのは、技術的には地味ですが、実務的にはむしろ深刻です。ゼロデイの突破は高度な能力を必要としますが、設定の行き違いはどの組織でも起こります。Anthropicはこの件を「モデルのアラインメント失敗というよりハーネスと運用の失敗に近い」と位置づけており、モデルが自前の目標を追求した証拠は無く、誤った状況認識のもとで指示どおりに動いた結果だとしています。

「検証環境だから安全」という前提が崩れる理由#

ここからが自社に引きつけた話です。今回の構図は、AIラボ特有の事情ではなく、社内でエージェントを検証している組織にそのまま当てはまります。

エグレスは「無い」のではなく「無いと思っていた」だけのことがある#

Anthropicの評価プロンプトは、Claudeに対して「環境はシミュレーションであり、インターネットアクセスは無い」と明示していました。それでも実際のマシンにはライブのインターネット接続が残っていました。原因は設定ミス単独ではなく、Anthropicと評価パートナーの間の行き違い(misunderstanding)が重なった結果です。Anthropicは、自社も評価パートナーも、追加の評価監視で検知するまでこの設定ミスに気づいていなかったと述べています。

つまり「エグレスは切ってあるはず」は、誰かが到達性を実測して確認するまでは仮説にすぎません。エグレス制御の設計論そのものは前掲のOpenAIの件の記事で詳述しているので、ここでは1点だけ強調します。設定を確認するのではなく、環境の中から外に出られるかを実際に試して確かめる、という手順が要ります。

CTF課題と実在資産は名前空間で地続きになる#

インシデント1は架空の企業名が実在ドメインと衝突し、インシデント2は「実在しないパッケージ名」がPyPIという実在の名前空間で登録可能だったことが引き金でした。どちらも、課題設計者が「架空のつもりで使った名前」が現実の名前空間と地続きだったケースです。

社内の検証でも同じことが起こります。テスト用に決めたドメイン名が誰かの実在ドメインだった、モックのAPIエンドポイントが実在ホストに解決された、テスト用に生成したパッケージ名が公開レジストリに登録できてしまった。ネットワークが完全に閉じていれば実害は出ませんが、名前空間の衝突は「閉じているつもり」が崩れた瞬間に実害へ直結します。

モデルは環境の境界をプロンプトからしか知らない#

インシデント2のMythos 5の推論が示すとおり、モデルが「ここは演習だ」と判断する材料は、プロンプトの記述と環境から観測できる断片的な手がかりだけです。しかもその手がかりの解釈は、訓練データと現実のずれによって簡単に誤ります。

これは能力の問題ではなく、情報の非対称の問題です。境界の強制はネットワークとクレデンシャルの側で行い、プロンプトでの説明はあくまで補助として扱うのが妥当な設計です。

標準のセーフガードを外して測る、という評価の構造的リスク#

能力評価は、上限を測るために本番のガードを外します。今回もそうでした。この構造は評価として合理的である一方、「最も危ないモードで動いているモデルが、最も監視の薄い環境に置かれる」という組み合わせを生みます。

なお、ここで言う評価は「モデルの能力・危険性を測るサイバー評価」であって、自社アプリの回答品質を測る一般的なevalとは別物です。品質evalは通常こうしたリスクを伴いません。混同して社内で不要な警戒を広げないよう、切り分けて説明することをおすすめします。

自社でLLM・エージェントを検証するときの隔離設計#

今回の件から取り出せる、検証環境側の設計論を5つにまとめます。

ネットワーク: 許可リストだけでなく到達性を実測する#

許可リストを書いたら、実際にその環境の中から外部へ到達できるかを試します。DNSが引けるか、任意のIPへTCPが張れるか、HTTPプロキシ経由で外に抜けられるか。設定ファイルのレビューではなく、環境内からの実測結果を記録として残します。Anthropicも「評価開始前にすべてのインターネット経路を検証していれば防げた」と総括しています。

認証情報: 検証環境に本物を置かない、短命にする#

インシデント2では、被害を受けたセキュリティ企業の認証情報が持ち出され、さらに同社インフラへのアクセスに使われました。検証環境に置く資格情報は、そのタスクに必要な最小限・短命のものに限り、本番系の認証基盤と同じ資格情報を共有しないことが基本です。

課題・テストデータ: 実在ドメイン名と実在パッケージ名を使わない#

テストシナリオで使う名前は、予約済みの領域から取ります。ドメインならRFC 2606のexample.com/example.net/example.org、あるいは自社が保有するテスト専用ドメイン。パッケージ名は、公開レジストリで既に自社が押さえている名前空間(スコープ付きの名前など)を使い、「公開レジストリに存在しない名前」を課題に登場させないようにします。存在しない名前は、誰でも登録できる名前と同義です。

プロンプト: 対象内と対象外を明示する#

安価な割に効く対策です。評価やタスクのプロンプトに、対象内のホスト・ネットワーク範囲と、対象外(触れてはいけない)の範囲を明示します。今回Anthropicも、対象内/対象外のシステムをプロンプトで明示していれば発生確率を下げられたと述べています。

ただしこれは多層防御の一枚目ではなく最後の一枚です。前述のとおりモデルはプロンプトの記述を状況証拠で上書きしうるので、ネットワークとクレデンシャルの制御を代替するものではありません。

外部委託先・評価ベンダーとの責任分界を文書化する#

今回の直接の引き金は、AnthropicとIrregularの間の行き違いでした。委託先の環境で検証する場合、次の項目を文書で確定させておくと事故の芽が減ります。

• 誰がネットワークの隔離を設定し、誰がその到達性を検証するか
• 検証結果の証跡を、どちらがどの形式で保管するか
• 実行ログ・トランスクリプトの保存主体、保存期間、開示条件
• 想定外の挙動を検知したときの停止権限が、どちらの側にあるか
• インシデント発生時の通知先と、第三者(被害組織・レジストリ運営)への連絡の主担当

Anthropicは再発防止として、自律的で強力な能力を扱う評価環境を本番システムと同等のセキュリティ基準で扱うこと、評価トランスクリプトの継続監視の拡大、調査ツールの改善、依存するベンダーへのより厳格なアシュアランスを挙げています。委託先の環境も自社のリスクだ、という整理です。

事後の遡及点検を可能にするログ設計#

今回のレポートで最も再現価値が高いのは、対策そのものより「疑いが生じてから2日で全容を特定できた」という点です。同じことを自社でやれる状態にしておくには、ログの設計が先に必要になります。

何を残すか#

最低限、次の3層が揃っていないと遡及点検は成立しません。

Anthropicのログ基盤の構成は公表されていませんが、141,006ランという母集団を切り出すには1層目に相当する情報が、各ランで何をしたかを判断するには2層目に相当する情報が要ります。同社自身も、自社と評価パートナーの双方が「トランスクリプトやネットワークログをより丁寧に見ることもできた」と振り返っており、3層目の存在も前提にしています。

後から検索できる形にしておく#

ログが存在することと、後から横断検索できることは別の要件です。3か月前のランを条件で絞り込めるか、保存期間はインシデントの潜伏期間より長いか(今回は4月から7月まで約3か月開いています)、ランIDからトランスクリプトとネットワークログを突き合わせられるか。この3つが揃って初めて遡及点検が可能になります。

なお、可観測性の実装論そのものは別記事で扱っています。ここでは「インシデント発覚後に、条件を指定して過去にさかのぼれるか」という一点だけを基準にしてください。

継続監視と抜き取りレビューを組み合わせる#

事後の全数点検は、疑いが生じた後にしか発動しません。日常的には、想定外の宛先への通信や長時間の連続アクションを検知する継続監視と、トランスクリプトの抜き取りレビューを併用することになります。Anthropicも再発防止の中心に「評価トランスクリプトの継続監視」を置いています。

第三者レビューを受けられる状態にしておく#

Anthropicは、独立評価機関METRとの第三者レビュー(全トランスクリプトへのアクセスと該当モデルへのサンプリングアクセスを含む)について協議中であり、PyPIパッケージを作成したランについて軽微な編集を加えたトランスクリプトを1週間以内に公開すると述べています。本記事作成時点で、いずれも実施・公開の確認は取れていません。

自社の規模では第三者レビューまでは不要でも、「外部に説明できる形でログが揃っているか」は良い基準になります。監査に耐える形式で残っていれば、社内の事後検証でも同じログが使えます。

侵害された側から見た教訓#

この件は加害側の話として読まれがちですが、防御側の立場でも学ぶところがあります。

基本的な穴が「現実の脅威」に変わる#

侵害に使われたのは、弱いパスワード、認証不要のエンドポイント、露出したデバッグページからの認証情報の読み取り、SQLインジェクションといった手口です。Anthropicは複雑な脆弱性の発見・悪用は無かったと明言しています。

つまり、対策の内容自体は昔から変わりません。変わったのは、それを試す主体が「9,000件をスキャンして代替標的を探す」ような速度と網羅性を持ったことです。「うちのような規模を狙う攻撃者はいない」という前提は、標的選定のコストが下がるほど成り立たなくなります。

自社が気づかないうちに侵害される前提で備える#

今回、連絡が取れた2組織はいずれも侵入を自ら検知していませんでした。3組織目には、本記事作成時点でまだ連絡が取れていないとされています。外部からの通知が唯一の発覚経路になった事例として、自社の検知能力を見積もり直す材料になります。

依存パッケージの取り込み経路を見直す#

インシデント2では、パッケージの公開からわずか1時間で15の実在システムがダウンロード・実行しました。手順書に書かれたパッケージ名をそのままインストールする運用が、いかに一般的かを示しています。

対策としては、公開レジストリから直接取るのではなく社内ミラーやプロキシを経由する、依存をロックファイルとハッシュで固定する、新規パッケージの取り込みに承認を挟む、といった既存の実践がそのまま効きます。なお、PyPIは「Report project as malware」からのマルウェア報告と、基盤自体の脆弱性をsecurity@pypi.orgへ報告する手順を案内しています(48時間以内の受領確認)。

明日から回す手順#

インシデントの件数・ラン数(141,006ランの点検、3件・6ラン)、時系列(7月23日の点検開始と評価停止、24日の特定、27日の通知、30日の公表)、関与モデル(Claude Opus 4.7、Claude Mythos 5、社内研究用テストモデル)、各インシデントの内容、原因(評価パートナーとの行き違いと設定ミス)、セーフガードの状態、防止策と再発防止、METRとの協議、OpenAIの事案との比較は、2026年7月30日にAnthropicが公表した「Investigating three real-world incidents in our cybersecurity evaluations」に基づきます。被害を受けた3組織の社名・業種は公表されていません。3組織目への連絡状況、METRによる第三者レビューの実施、トランスクリプトの公開、サイバー評価の再開の有無は、本記事作成時点(2026年8月3日)で追加の確認が取れていません。Cybenchの構成はプロジェクトサイト、Frontier Red Teamの位置づけとIrregularの評価方針は各社サイト、Hugging Face側の被害と対応は同社が7月16日に公表した開示文、PyPIへの報告手順はPyPIのセキュリティページに基づきます。OpenAI側の一次開示は公式サイトが自動取得をブロックするため、アーカイブ版を出典に挙げています。

よくある質問#

まとめ#

この件から取り出せる教訓は、実のところ地味です。エグレスは実測しないと分からない。架空の名前は現実の名前空間と衝突する。モデルは環境の境界を自力では判定できない。委託先の環境も自社のリスクである。そして、後から遡れないログは、インシデントが起きたときに何の役にも立ちません。

同時に、Anthropicの対応のうち再現価値が高いのは「他社の開示を見て、自社で同じことが起きていないかを確かめた」という動きそのものです。他社のインシデント報告は、自社ログを検索する条件のリストとして読めます。次に大きな開示が出たとき、その条件で自社のログを引ける状態になっているか。今回の件は、そこを準備しておく価値を示した事例だと受け止めています。