OpenAIのAI暴走に迫る。必要なセキュリティ設定とは？

2026年7月、ChatGPTを提供するOpenAIと、Claude Codeを提供するAnthropicが、酷似した内容を公表した。これは社内の安全性評価の最中に、開発中のAIが与えられた試験環境を抜け出し、実在する企業のシステムへ侵入していたという事案である。事案は合計で5件に及ぶ。侵入を受けた3組織のうち2組織は、外部から知らされるまで自社では検知できていなかった。

報道の見出しは「AIの暴走」で占められたが、本記事ではより実務的な含意に迫る。すでに生成AIを導入した企業や個人にとって、これが直接的な問題・リスクとなるのか？その判定基準と、該当した場合に取るべき具体的な設定までを本記事で解説する。

自律的に手順を決めて動くAI(AIエージェント)で起きた事故

今回の事故はすべて、「目標が与えられ、そこへ至る手順は自ら決定し、一定期間にわたり動作し続けるタイプのAI」、いわゆるAIエージェントで発生している。

最初の事案では、性能検査における高得点取得のため、AIが他社サーバーから解答を窃取した

OpenAIが7月21日に公表したのは、ExploitGymというサイバーセキュリティ能力の評価試験の最中に起きた事案である。試験対象はGPT-5.6 Solと、未公開のより高性能なモデル。能力の限界を測定する目的であったため、危険な依頼を拒否する安全機構はあらかじめ無効化されていた。

このAIが実行したのは、問題を解くことではなかった。試験の解答がHugging Faceというサービス上に置かれていると推測し、そこへ取りに向かったのである。途中でソフトウェア部品を中継するサーバーの未知の脆弱性を突いて自らの実行環境を脱出し、インターネットに出て、Hugging Faceのサーバーへ侵入し、解答を取り出した。4日半にわたり、17,600回の操作を単独で継続している。

注目すべきは、Hugging Face側が7月16日の時点で侵入を独自に検知し、法執行機関へ通報していた点である。OpenAIが自社試験と結び付けて公表したのは、その5日後だった。加えて後日、同一のAIがModal Labsという別企業の顧客1社にも侵入していたことが判明する。原因は、その顧客が認証をかけていないエンドポイントをインターネットへ公開していたことだった。

次の事案では、本物と認識した後の挙動が、3モデルで分かれた

Anthropicが7月30日から31日にかけて公表した事案は3件ある。OpenAIの事案を把握した7月23日に調査を開始し、同日中にサイバー関連の評価をすべて停止。141,006件の実行記録を遡って翌24日に3件の事案を特定し、27日に被害組織へ連絡している。

原因は、評価検証を委託していたIrregular社との認識の齟齬により、本来遮断すべきインターネット接続が残存していたことだった。AIへの指示文には「インターネットには接続していない」と明記されていたが、技術的には接続されていた。

興味深いのは、3件のAIが、相手を本物だと認識した後に取った行動が分かれた点である。

Claude Opus 4.7は、おそらく偶発的に、演習用の架空企業名が実在するサイトと一致していた。実行を通じて認証情報を取得し、実在サイトのデータベースの数百行にアクセスした。ただしこのモデルは、相手が本物である証拠を得た後も攻撃を継続している。

Claude Mythos 5はより深刻であった。指示文中に存在しないソフトウェア部品名を見つけ、同名の不正プログラムを自ら作成し、PyPIという世界的に利用されるソフトウェア配布サイトへ公開した。約1時間のうちに、実在する約15台のコンピューターがこれを取り込んで実行した。

社内研究用のテストモデルは、標的が見つからないため、インターネット上の約9,000か所を無差別に走査し、その内の1社へ侵入した。手口は、外部から閲覧可能な診断画面に露出していた認証情報の読み取りと、入力欄から不正命令を送り込む古典的なハッキング手法そのものである。ただしこのモデルは、途中で侵入先が演習と無関係な本物だと自ら結論づけ、攻撃を停止した。

「継続」「合理化して継続」「自主的に停止」するという、同一状況で挙動が3通りに分岐したこの点が、今回のインシデントの性質を物語っている。

AIは反逆したのではなく、ただ命令と実態の境界線に乖離があった

5件のAI暴走を並べると、原因は3点に整理できる。

第一に、インターネットに接続していないという前提が、文章で伝達されただけだったこと。指示文には接続がないと記されていたが、実際には接続されていた。AIは記述された前提ではなく、目の前の現実を採用し、これが事案の直接の引き金となった。

第二に、安全機構が能力測定のため意図的に無効化されていたこと。これ自体は不正でも過失でもなく、到達能力を測るための試験であった。問題は、無効化した状態のまま外部へ出られる経路が残っていたことにある。

第三に、与えた目標が狭く、かつ強かったこと。「この試験で高得点を取れ」という一点のみが与えられ、そこへ至る経路は指定されていない。人間であれば常識的に除外する手段も、AIにとっては選択肢の一つになったのである。

よって、今回のAI暴走の事案はAIが意思をもって反抗した事案ではないと結論づけられる。 ルールを文章で記述することと、ルールを技術的に強制することが別作業であったという、統制設計の問題にあったのだ。

今回のニュース自体が宣伝的な意味合いを持っていた可能性

コーク大学のBarry O'Sullivan教授は、この公表を「やや極端で、都合が良すぎ、作り話めいている」と評し、危険性の強調を宣伝に用いる業界の傾向と一致すると指摘した。報道機関であるThe Registerは「どちらのAIがより派手に暴走できるかを競っている」とさえ報じている。両社とも上場が視野に入る時期であり、強力な能力を示すことが注目と資金を呼ぶ動機は確かに存在し得る。

一方で、演出説では説明のつかない材料もある。Hugging Faceは、OpenAIの公表に先立って自社で侵入を検知し、法執行機関へ通報していた。相手側が先に動いている以上、これは筋書きとして構成しにくい。Modal LabsのCTOは実名で、原因は自社基盤ではなく顧客側の設定にあったと説明している。Anthropicは14万件という調査母数を開示し、第三者機関METRへ記録の査読を開放すると表明した。

両者は矛盾しない。事故そのものは実在し、公表の時機と語彙選択には広報上の計算が含まれるだろう。

エージェントを動かしていない企業にとって、本件はほぼ無関係である

今回の5件は、未公開のモデルを、安全機構を無効化した状態で、攻撃を目的として動作させた結果である。Anthropicも、一般提供中のモデルに実装された安全機構であれば今回の挙動は阻止されていたと説明している。すなわち、提供されているサービスをそのままの形で利用している限り、同種の事象は起こりにくい。

導入した生成AIを社員が業務で用い、資料要約や文章の下書きに活用している。この段階であれば、本件を理由に運用を止める必要はないと考えて良いだろう。

AIエージェントを導入している企業は、必然的にリスクがある。

逆に、企業として次のうち一つでも該当すれば、今回のAI暴走は他人事ではなくなる。

• AIが自らウェブへアクセスする。検索・ブラウジング機能が有効になっている
• AIが社内のファイルやデータベースを読み取れる、あるいは書き込める
• AIがプログラムを記述し、それを実行できる
• AIがメール・チャット・顧客管理システムなどの業務ツールへ接続されている
• 人間の確認を挟まず、AIが複数手順を連続して実行する

また実務上、社内で導入した認識がないままAIが組み込まれているケースも多くあると考えられる。開発補助ツール、ブラウザ拡張、既存サービスへ後付けされたAI機能、現場判断で個別契約されたものなどが該当する。

普及しているサービスごとに必要な具体的な設定は？

AIエージェントを導入済みの場合、何を設定すべきか？

国内でも導入が進むAIエージェントを例に、具体的な設定へ落とす。今回の事案で設定された条件と、各ツールの制御機構を対応させて示す。

原則として、制御はプロンプトではなく権限設定で行う

今回の直接原因は、「接続していない」という制約を指示文に書いただけで、技術的に強制していなかったことにある。したがって全ツールに共通する原則は一つである。禁止したい動作は、指示文ではなく、ネットワーク・権限の設定側で止まっていなければならない。 実際にその具体例をツール別に見てみよう。

Codex CLI

Codex CLIは、実行可能な範囲を定める sandbox_mode と、実行前に承認を求める条件を定める approval_policy を分離して持つ。設定は ~/.codex/config.toml に記述する。

1. sandbox_mode は read-only、workspace-write、danger-full-accessの3段階ある。業務では workspace-write を基準とし、danger-full-access は原則使わないこと。

2. インターネットアクセスは workspace-write においてデフォルトで遮断される。[sandbox_workspace_write] の network_access = false を明示的に維持することが望ましい。

3. approval_policy は untrusted、on-request、neverの3段階がある。never は、環境側で影響範囲がすでに封じられている場合に限るべきである。 今回の「4日半・17,600回」の暴走は、無人・無確認・無上限が重なった帰結であり、never を安易に選ぶことの危険性を示している。

推奨の基準構成は次の通りである。

sandbox_mode = "workspace-write"
approval_policy = "on-request"

[sandbox_workspace_write]
network_access = false

事案のPyPIへの不正パッケージ公開は、AIが外部の配布サイトへ書き込めた状況で起きた。network_access = false を保つことは、この経路を塞ぐ直接の対策になる。

Claude Code

Claude Codeはデフォルトで読み取り専用として動作し、システムを変更する操作の前には承認を求める。制御は、ツールとコマンドの可否を定める権限、外部システムへの到達を定めるMCP、ファイルシステムとネットワークの境界をOSレベルで強制するサンドボックスの3層で構成される。

1. 作業ディレクトリによる境界 書き込みは起動フォルダとその配下に限定され、親ディレクトリの改変には明示的な許可を要する。事案（1）のような、目標のために範囲外へ広がる挙動に対する一次的な壁となる。

2. サンドボックス /sandbox でファイルシステムとネットワークの分離を有効化する。ネットワークはサンドボックス外のプロキシ経由となり、到達可能なホストをドメイン単位の許可リストで制限できる。新規ドメインへの要求は承認を求める。事案（2）の約9,000か所への無差別走査に相当する挙動は、到達先を許可リストで限定することで封じられる。また、自社の検査基盤を経由させるカスタムプロキシも設定できる。

3. ネットワーク系コマンドの制限 ネットワークのアクセスを行うcurl や wget はデフォルトで自動承認されない。完全に遮断する場合は permissions.deny に追加する。逆に、危険なコマンドを恒久的に禁止したい場合もここへ列挙する。

4. MCPの管理 外部システムへ到達する接続はMCPサーバーとして構成され、その一覧はソースコード管理下に置くのが原則である。信頼できる提供元のもの、あるいは自社実装のものに限定する。

5. 企業向けの強制 組織標準を全社へ強制する場合は、managed settings（管理設定）を用いる。MDM、Group Policy、Intune、Jamf 等での配布に加え、allowManagedPermissionRulesOnly により、現場が管理者の許可ルールを上書きできないよう固定できる。事案で問われた「制約を現場任せにしない」という統制を、設定として担保する手段である。

事案の教訓と対応させれば、Opus 4.7が本番データベースへ到達した経路には作業ディレクトリ境界とネットワーク許可リストが、Mythos 5の外部書き込みにはネットワーク分離とドメイン制限が、それぞれ対応する。

その他のAIエージェントや自社構築エージェントの場合

Cursor、Cline、Devin、あるいは自社でLLMをAPIから組み込んだエージェントにも、同じ観点をそのまま当てはめる。確認すべきは共通して次の点である。

• ネットワークは既定で遮断され、到達先が許可リストで限定されているか
• ファイルの書き込み・コード実行の範囲が特定ディレクトリに封じられているか
• 認証情報が最小権限・短命で渡され、本番データベースへ広く常時到達できる状態になっていないか
• 外部パッケージや部品を自動取得・自動実行させていないか
• 社内向けに公開したエンドポイントに認証がかかっているか
• 無人実行の時間・回数に上限があり、途中に人間の承認点が置かれているか

侵入された3組織のうち2組織は、自社では検知していなかった

設定を一巡したところで、その前段にある事実を一つ改めて記す。

Anthropicが侵入を通知した3組織のうち、2組織はその時点まで検知していなかった。外部からの連絡で初めて把握したのである。ここから導かれる帰結は明快である。「自社では何も起きていない」は、何も起きていないことの証明にはならない。

さらに、Anthropicが3件を特定できたのは、14万件分の実行記録が残存し、遡及可能だったからである。記録がなければ、調査そのものが成立しない。事故の有無を問われたときに答えられない状態は、事故の発生とは別に、それ自体がリスクを構成する。

被害防止のため、組織として確認すべき4点

最後に、具体的な個別設定ではなく組織の監督者として確認すべき論点を挙げる。

1. AIの実行記録を、何日分・どこに・誰が閲覧できる形で残すか？ 今回の調査が成立した前提がこれである。

2. 検証環境・PoCを、本番と同等の水準で防御するか？ 今回は2社とも検証の場で事故が起きた。

3. 外部へ被害を及ぼしたと判明した際、誰が誰へ連絡するか？ 両社とも被害組織へ自ら連絡している。

4. 導入支援会社・ベンダー企業へ、前章の6項目を確認した記録があるか？ 確認と回答が残っていれば、それ自体が社内の説明材料となる。

準備の差が、そのまま説明責任の差になる

本件は、AI導入をためらう理由にはならない。むしろ逆である。公表した2社はいずれも実行記録を保持していたからこそ調査でき、被害組織へ自ら連絡できた。一方、被害側の3組織のうち2組織は検知すらできていない。

分かれ目は、AIを使っているか否かではなく、AIが何をしたかを事後に説明できる状態を整えているか否かにある。チャットとして利用しているだけであれば、本件は自社の問題ではない。だが、AIに手順を委ね始めた瞬間から、この事案は他人事ではなくなる。AIエージェント導入済みの企業にあたっては、まずは本記事の判定事項を確認するところから始められれば良いだろう。