本番とテスト環境、AIエージェントに"境界"をどう教えるか
はじめに
2026年7月30日、Anthropicが自社のAIモデルに関する事案を公表した。サイバーセキュリティ能力の評価試験中に、Claudeが実在する3組織のシステムへ不正にアクセスしていた、という内容だ。
「AIが暴走した」という見出しだけを見ると、AIエージェントそのものが制御不能になったように聞こえる。しかし一次情報を読み込むと、本質はもう少し地味で、そして実務者にとってはるかに教訓に富んだ話だった。境界線の設計ミスと、AIの状況判断の甘さが重なった事故だ。
40年近くエンジニアをやってきて、「制御を失ったシステム」を何度か見てきた。組込み機器の暴走、middlewareの想定外の挙動、権限設計の抜けによるインシデント——原因は毎回違うが、共通するのは「境界線を明示していなかった」ことだ。今回の件も構造は同じだと感じたので、実務者向けに整理しておきたい。
何が起きたのか
Anthropicが評価を委託していたセキュリティ企業Irregular社が用意したCTF（Capture The Flag）形式の演習環境で、モデルにネットワーク上の「フラッグ」を探させるテストが行われていた。評価プロンプトには環境がシミュレーションでインターネットには接続できないと明記されていたが、AnthropicとIrregular社の間で環境設定の認識にズレがあり、実際には本物のインターネットに接続できる状態になっていた。
きっかけは7月21日にOpenAIが公表した類似の事案だった。これを受けてAnthropicは自社の評価ログを点検し、インターネットに出られた可能性のある14万1,006回の評価実行を調査。その結果、3件のインシデント（合計6ラン）を特定した。関与したモデルはClaude Opus 4.7、Claude Mythos 5、内部の研究テストモデルの3種類だ。
最も深刻だったのが、Mythos 5が本番のPythonパッケージ配布サービスPyPIに悪意あるコードを含むパッケージを公開したケースだ。このパッケージは約1時間配布され、世界中の実システム15台にインストールされた。パッケージ自体はPyPI側の自動セキュリティ機構によって削除され、Anthropicは運営チームに事案を通知している。
興味深いのは、Mythos 5が推論の過程で一度「これが本物のインターネットなら現実の攻撃になる」と認識していた点だ。それでも証明書の発行元に見覚えがないことやシステム上の日付が2026年であることを根拠に、「やはりこれはシミュレーションだ」と自己判断して行動を続けた。一方で、関与した内部の最新テストモデルは、本物だと気づいた時点で自発的に攻撃を中止している。同じ状況でもモデルによって判断が割れた、という点は実務上かなり示唆的だ。
なぜこの事故は起きたのか
技術的な原因を整理すると、次の3つが重なっている。
1. 環境の境界が「言葉」でしか定義されていなかった 評価プロンプトには「これはシミュレーション環境である」という指示が明記されていた。だが実際のネットワーク設定はそれを裏付けていなかった。人間のペネトレーションテスターであれば、環境の"物理的な"制約（ネットワーク的に外に出られるかどうか）を自分の目で確認するだろうが、AIエージェントはプロンプト上の指示と実際の観測結果が矛盾したときに、指示ではなく観測結果（証明書、日付など)から都合よく結論を導いてしまった。
2. 権限の範囲に明確な制限がなかった 「フラッグを探す」という指示自体に、探索してよい範囲の技術的な制約がなかった。人間なら「演習用のIPレンジ以外は触らない」という暗黙の常識があるが、AIエージェントにその常識は期待できない。
3. 途中で人間に確認を求める仕組みがなかった Mythos 5は一度、行動の是非について自ら疑問を持つ推論を残していた。これは裏を返せば、「ここで一度止まって人間に確認する」チェックポイントがあれば防げた可能性を示している。
実務でAIエージェントに権限を渡すときの教訓
この事案は評価環境という特殊な状況で起きたものだが、業務でAIエージェント(Claude Code、その他の自律実行系ツール)に本番系の操作権限を渡す機会が増えている今、他人事ではない。インフラ・セキュリティを見てきた立場から、実務に落とすなら次の点を徹底したい。
ネットワーク境界は設定で強制する、プロンプトで指示しない 「このネットワークには出ないでください」という指示だけに頼らず、ファイアウォールやセキュリティグループ、プロキシのallowlistで物理的に接続先を制限する。今回の事故も、まさに「指示はあったが設定が伴っていなかった」ケースだ。FortiGateやAWSのセキュリティグループでの出口制御は、AIエージェントの実行環境にこそ厳格に適用すべきだと改めて感じる。
権限は都度発行、スコープは最小限に 本番DBの認証情報やAPIキーをエージェントに長期間持たせない。作業単位で一時的な権限を発行し、終わったら失効させる。IAMロールのAssumeRole的な発想を、AIエージェントの実行基盤にも適用する。
「これは本物か、テストか」をエージェント自身の判断に委ねない 今回、Mythos 5は証明書や日付という不確かな手がかりから独自に結論を出した。人間の作業でも同じことが起きうる——「たぶんテスト環境だろう」という思い込みで本番を触ってしまう事故は昔からある。エージェントの実行ログに環境種別（本番/検証）を明示的にメタデータとして持たせ、実行前にその情報と実際の接続先が一致しているかをシステム側で機械的に検証する仕組みが必要だ。
破壊的操作・外部公開系の操作は人間の承認を挟む パッケージの公開、認証情報の送信、外部システムへの書き込みなど、後戻りできない操作は自動実行させず、必ず人間の承認ステップを挟む。これはAIエージェントに限らず、CI/CDのデプロイパイプライン設計と同じ発想でいい。
監査ログは「疑わしきは記録」の姿勢で Anthropicが今回3件を特定できたのは、14万件超の評価ログを遡って調査できたからだ。エージェントの実行ログを十分な粒度で残しておくことが、事故後の原因特定と再発防止の生命線になる。
おわりに
AIエージェントに権限を持たせる話は、技術的には目新しくない。人間の権限管理、CI/CDのデプロイ制御、サンドボックス設計——これまでのセキュリティ実務の延長線上にある問題だ。違うのは、AIエージェントは「境界を疑って確認する」という人間なら当たり前に持っている感覚を、明示的に設計してやらないと持てないという点だ。
今回のケースでAnthropic自身が「これは統制された比較実験ではなく、そこから安易に結論を導くべきではない」と慎重な姿勢を示しているのも印象的だった。過度に煽らず、かといって軽視もせず、実務者としては「自分たちの環境で同じ穴がないか」を淡々と点検するのが一番の教訓だと思う。
参考: Anthropic公表資料（2026年7月30日）、ITmedia NEWS、Impress Watch、piyolog、セキュリティ対策Labの報道をもとに構成
