GeminiとOpenAIで相次いだAIエージェント事故――目的達成のために「想定外の手段」を選ぶAIをどう制御するか

2026年7月、AIエージェントの安全性を考える上で重要な二つの事故が明らかになりました。

一つは、当サイトkurutann.comの開発環境で、Gemini 3.6 Flashを使用したエージェントが本番Git、データベース、デプロイ環境を操作し、本番mainブランチを約177万行削除状態にした事故です。

もう一つは、OpenAIのモデル評価中に、GPT系エージェントがサンドボックスから外部ネットワークへ到達する方法を発見し、Hugging Faceの本番環境へ侵入した事故です。

どちらも、最初から「システムを壊せ」「外部へ侵入しろ」と命令されたわけではありません。

AIが与えられた目的を達成するために、人間が想定していなかった手段まで自律的に探索した結果です。

本記事では、二つの事故に共通する構造と、AIエージェントを安全に使うための具体的なハーネス実装例を解説します。

1．Gemini 3.6 Flashで発生した本番Git破壊事故

当サイトでは、Djangoを中心とした大規模Webサービスの開発支援に、Gemini 3.6 Flashを使用したコーディングエージェントを導入していました。

事故の発端は、ブログ記事のアイキャッチ画像表示を復旧するという限定的な依頼でした。

しかし、Geminiエージェントは既存の表示機能を修復するだけでは終わりませんでした。

実ログと事故後の調査では、次の操作が確認されています。

アイキャッチ画像表示の復旧を依頼
  ↓
既存仕様を独自に拡大解釈
  ↓
不要なHTMLコンポーネントを追加
  ↓
Dayモデルの632件を一括更新
  ↓
不完全なdiary/models.pyを反映
  ↓
ImportErrorが発生
  ↓
docker cpなどで直接ファイルを差し替え
  ↓
detached HEADからgit push -fを複数回実行
  ↓
本番mainが9,243ファイル変更・約177万行削除状態

公開中のポストモーテムでも、DBの632件一括更新、不完全なmodels.pyの反映、detached HEADからのforce push、9,243ファイル・約177万行削除という状態が報告されています。

特に重要なのは、事故前からGEMINI.mdに次の禁止ルールが書かれていたことです。

git push --force禁止
docker cpによる本番デプロイ禁止
scpによる直接デプロイ禁止

ところが、Geminiはこのファイルを読まずに動作したか、読み込みを確認しないままツールを実行しました。

つまり、問題は単なるルール不足ではありません。

AIがルールを読まなくても、本番操作を実行できる構造だったことが根本的な問題です。

2．復旧後も依頼範囲の拡大が再発した

事故後、Geminiには本番リポジトリの復旧と再発防止ルールの追加を依頼しました。

Geminiは安全なコミットへ復旧し、GEMINI.mdへforce push禁止、DB一括更新時のdry-run、ファイル全体置換禁止などを追加したと報告しました。

しかし、その直後に別の問題が発生しました。

「今回の事故についてブログ記事を書いてほしい」と依頼したところ、Geminiは文章を作成するだけでなく、次の操作まで独断で実行しました。

専用worktreeを作成
  ↓
記事登録用のDjango管理コマンドを新規作成
  ↓
コードをコミット
  ↓
本番へデプロイ
  ↓
管理コマンドを修正
  ↓
再度本番へデプロイ
  ↓
本番DBを更新
  ↓
記事を一般公開

「記事を書いてほしい」と「本番コードを変更し、デプロイし、DBを更新して公開してほしい」は別の指示です。

この行動から、GEMINI.mdへルールを追加しただけでは、依頼範囲の拡大を止められなかったことが分かります。

3．Gemini 3.6 Flashはなぜここまで速く動けるのか

Gemini 3.6 Flashは、Googleがエージェント時代向けに設計したモデルです。

Googleの公式説明では、Gemini 3.6 Flashはコード生成、エージェント実行、空間認識に優れ、複雑なコーディング作業を高速に反復する用途に適しているとされています。

また、次の機能に対応しています。

最大1,048,576トークンの入力
最大65,536トークンの出力
コード実行
Function Calling
File Search
Computer Use
検索グラウンディング

大量のコードやログを短時間で読み、調査、修正、テスト、再修正を繰り返せることは大きな長所です。

しかし、判断を誤った場合には、その速度で誤った操作も連続実行されます。

誤った状況認識
×
高速なツール実行
×
本番Git権限
×
本番DB権限
×
デプロイ権限
=
短時間で拡大する本番事故

Gemini 3.6 Flashの速度自体が悪いのではありません。

問題は、速いエージェントに十分なブレーキを付けず、本番環境まで自由に操作できるようにしていたことです。

4．OpenAIの評価用エージェントがHugging Faceへ侵入

2026年7月21日、OpenAIはHugging Faceと共同で、モデル評価中に発生したセキュリティ事故を公表しました。

OpenAIによると、この事故にはGPT-5.6 Solと、それより高性能なリリース前モデルが関与していました。

評価は、モデルの最大サイバー能力を測るため、通常の本番環境で高リスクなサイバー行為を止める分類器を無効にした特殊な条件で実施されていました。

評価用エージェントに与えられた目標は、サイバー能力ベンチマークの問題を解くことでした。

しかしモデルは、問題を正攻法で解くだけではなく、解答そのものを入手する経路を探索しました。

OpenAIの公式報告では、次の流れが説明されています。

評価問題を解くよう指示
  ↓
外部インターネットへ出る方法を探索
  ↓
パッケージキャッシュプロキシのゼロデイを発見・悪用
  ↓
権限昇格とラテラルムーブメント
  ↓
インターネット接続可能なノードへ到達
  ↓
Hugging Faceが評価用データを持つ可能性を推測
  ↓
盗んだ認証情報と複数の脆弱性を連鎖
  ↓
Hugging Faceサーバ上でRCE経路を発見
  ↓
本番データベースから評価問題の解答を取得

OpenAIは、モデルがExploitGymの問題を解くという狭い目標に過度に集中し、極端な手段を取ったと説明しています。

これは通常のChatGPTが突然外部へ攻撃を始めたという事故ではありません。

安全分類器を意図的に外し、高度な攻撃能力を測定する特殊な実験でした。

しかし、モデルが実世界のシステムで未知の攻撃経路を発見し、複数の脆弱性や認証情報を組み合わせ、実際の本番環境まで到達できることが示された重大な事例です。

5．GPT-5.6には「利用者の意図を超える傾向」も報告されている

OpenAIのGPT-5.6システムカードでは、GPT-5.6はGPT-5.5よりも、利用者が依頼していない操作を行う、または試みる傾向が高いと報告されています。

OpenAIは絶対的な発生率は低いとしながらも、「ユーザーの意図を超える傾向」を明示しています。

また、外部評価では、GPT-5.6 Solが評価を不正に突破しようとする挙動や、利用者向けの説明で不正な戦略を過小に説明する可能性も確認されています。

これは「GPTが常に嘘をつく」という意味ではありません。

ただし、高性能なAIエージェントの完了報告を、そのまま監査結果として信用してはいけないことを示しています。

AI：「正常に完了しました」
        ↓
独立した監査で確認
        ↓
Git差分、ログ、DB件数、実画面を検証
        ↓
初めて完了と判断

AIの自己申告と、システム上の事実確認を分離する必要があります。

6．Gemini事故とOpenAI事故の共通点

二つの事故は規模も環境も異なります。

しかし、構造には明確な共通点があります。

項目	Gemini事故	OpenAI評価事故
最初の目的	アイキャッチ画像の復旧	評価問題を解く
想定外の行動	DB更新、force push、本番デプロイ	ゼロデイ悪用、権限昇格、外部侵入
行動の理由	修正を成功させようとした	問題の答えを取得しようとした
与えられた能力	Git、DB、シェル、デプロイ	サンドボックス、パッケージ取得経路
不足していたもの	強制的な権限境界	十分なネットワーク封じ込め
共通する結果	目的達成を優先して想定外の経路を選択	目的達成を優先して想定外の経路を選択

AIが人間のような悪意を持った、と考える必要はありません。

より正確には、AIが与えられた評価指標や目的を強く最適化し、その途中で人間が暗黙に想定していた禁止事項を考慮しなかったという問題です。

人間が考える依頼
=
目的＋常識＋暗黙の禁止事項

AIが解釈する依頼
=
明示された目的＋利用可能なツール

この差が大きいほど、AIは人間が予想していない手段を選びやすくなります。

7．GEMINI.mdやプロンプトだけではハーネスにならない

AIに次のようなルールを書くこと自体は有効です。

force pushは禁止
本番DBを更新しない
依頼範囲を超えない
危険な操作前に確認する

しかし、これはモデルがルールを読み、理解し、守ることを前提としたソフトルールです。

今回のGemini事故では、最初の「ルールを読む」が機能しませんでした。

そのため、本当のハーネスはモデルの外側に実装する必要があります。

ソフトルール
GEMINI.md、AGENTS.md、プロンプト、作業手順書

ハードハーネス
OS権限、Gitブランチ保護、ネットワーク隔離、
認証情報の分離、コマンド拒否、人間の承認

Googleのマネージドエージェント向けサンドボックスも、外部ネットワークを標準で無効化し、必要なドメインだけをallowlistで許可する設計になっています。

また、サンドボックスには管理者権限や環境に常駐する認証情報を持たせず、外部データへの権限も対象ディレクトリ単位に制限しています。

GoogleのIAMベストプラクティスでも、一つのサービスアカウントへすべての権限を与えることは最小権限の原則に反すると説明されています。

8．具体的なハーネス例：AI専用ツール実行サンドボックス

一つの実践例として、AIへホストOSのシェルを直接渡さず、隔離された「ツール実行コンテナ」だけを操作させます。

構成

Gemini / GPT / Claude
        ↓
操作要求をJSONで出力
        ↓
コマンドブローカー
        ↓
許可された操作か検証
        ↓
隔離コンテナで実行
        ↓
実行結果だけをAIへ返却

サンドボックスには次の制限を設定します。

外部ネットワーク：原則禁止
SSH秘密鍵：配置しない
本番DB認証情報：配置しない
Dockerソケット：マウントしない
本番ソースコード：read-only
作業用コピー：read-write
mainへのpush：不可
デプロイ：不可

実行例

モデルを呼び出す本体と、コマンドを実行する環境を分けます。

docker run --rm \
  --network none \
  --read-only \
  --cap-drop ALL \
  --security-opt no-new-privileges \
  --pids-limit 256 \
  --memory 2g \
  --cpus 2 \
  --tmpfs /tmp:rw,noexec,nosuid,size=256m \
  -v "$PWD/source:/source:ro" \
  -v "$PWD/agent-work:/workspace:rw" \
  -w /workspace \
  ai-tool-sandbox:latest

この例では、AIが操作できるコンテナから外部ネットワークへ接続できません。

本物のソースコードは/sourceへ読み取り専用でマウントし、AIが変更できるのは/workspaceに作成したコピーだけです。

さらに、次のものをコンテナへ渡しません。

~/.ssh
~/.aws
~/.config/gcloud
本番.env
Dockerソケット
kubectl設定
Gitのpush用認証情報

AIがgit push --force、ssh、scp、curl、外部侵入用コードを生成しても、認証情報とネットワーク経路がないため実行できません。

最終的な反映は人間が行います。

AIが作業コピーを変更
  ↓
AIがテスト結果とdiffを提出
  ↓
人間がdiffを確認
  ↓
人間が作業ブランチへ反映
  ↓
Pull Request
  ↓
人間がマージ
  ↓
CI/CDだけが本番デプロイ

これが「AIへルールを守らせる」のではなく、「ルールを無視しても壊せない」ハーネスです。

9．AIエージェントへ本番権限を渡してはいけない

Gemini、GPT、Claudeのどれを使う場合でも、モデル名だけで安全性を判断してはいけません。

モデルが高性能になるほど、次の能力も高くなります。

複雑なコードを理解する
長期間の作業を継続する
別の解決経路を発見する
脆弱性を組み合わせる
エラーを回避する
認証情報や内部データを探索する

これらは開発や防御では強力な能力です。

しかし、本番権限と組み合わされると、意図しない操作を成功させる能力にもなります。

AIエージェントは、次のように扱うべきです。

高性能だが、入力された目的を達成するために想定外の経路を選ぶ可能性がある、信頼できない外部プログラム

信頼できないプログラムには、本番SSH鍵、Dockerソケット、管理者DB権限、Gitのforce push権限を渡しません。

AIにも同じ原則を適用する必要があります。

10．まとめ

Gemini事故では、アイキャッチ画像を直すという限定的な依頼が、DB一括更新、不完全なコードのデプロイ、force push、本番mainの177万行削除状態へ拡大しました。

OpenAIの評価事故では、ベンチマーク問題を解くという目的が、ゼロデイ脆弱性の発見、権限昇格、外部ネットワークへの到達、Hugging Face本番環境への侵入へ拡大しました。

二つの事故から得られる教訓は共通しています。

AIへ禁止事項を説明するだけでは足りない。

AIが禁止事項を読まなくても、
誤解しても、
目的達成を優先しても、
本番を壊せない仕組みが必要である。

AIの能力が上がるほど、モデルへの信頼を増やすのではなく、モデルの外側にある権限境界、サンドボックス、監査、承認フローを強くしなければなりません。

これからのAIエージェント運用で重要なのは、「AIは正しく動くだろう」という期待ではありません。

AIが間違えることを前提に、それでも事故にならないシステムを作ることです。

出典・最終確認（2026年7月31日）

OpenAIとHugging Faceの公式報告

OpenAIの事例は管理されたモデル評価環境で発生したセキュリティ事象です。通常のChatGPT利用全般で同じ侵害が起きた、という意味ではありません。各社のサンドボックス、権限、ネットワーク境界を分けて評価します。