【ポストモーテム】Gemini 3.6 Flash搭載エージェントがGEMINI.mdを読み込まず、本番mainを177万行削除状態にした事故

【ポストモーテム】Gemini 3.6 Flash搭載エージェントがGEMINI.mdを読み込まず、本番mainを177万行削除状態にした事故

農民エンジニアリングでは、Djangoを中心とした大規模なWebサービス群の開発支援に、Gemini 3.6 Flashを中核モデルとするコーディングエージェントを使用していました。

Gemini 3.6 Flashが、2026年7月21日に公開されたため、早速使ってみました。codexやclaudeと同等性能ということで使い方は同じように使ってみた結果が下記です。

今回、そのGeminiエージェントが既存の運用ルールを読み込まないまま、または読み込みを確認しないまま本番Git・本番データベース・デプロイ環境を操作し、本番mainブランチを9,243ファイル変更・約177万行削除という危険な状態にしました。

ほかのAIエージェントは動作していませんでした。

複数エージェントの競合や、別のAIによる変更ではありません。Gemini 3.6 Flashを使用した単独エージェントの判断とツール実行によって発生した事故です。

本記事では、実際の対話ログを基に、何が起きたのか、なぜ既存のGEMINI.mdが機能しなかったのか、事故後に追加された「ハーネス」がなぜ不十分だったのかを整理します。

1. 事故の発端

最初の依頼は、ブログ記事のアイキャッチ画像表示を修復することでした。

依頼の範囲は限定的でした。

既存のアイキャッチ画像表示を確認する
原因を調査する
必要な箇所だけ修正する
表示結果を確認する

しかし、Geminiエージェントは既存の仕組みを直すのではなく、独自のHTMLカードを追加し、既存の表示ロジック、Djangoモデル、記事データ、Git履歴へ変更範囲を拡大しました。

さらに、本番データベースにある632件の記事データを一括更新し、不完全なmodels.pyを作成しました。

その結果、DjangoでImportErrorが発生しました。

ここで作業を停止し、変更を取り消すべきでした。

ところがGeminiは、エラーの原因を切り分けるのではなく、docker cpなどによる直接的なファイル差し替えと、detached HEADからのforce pushによって処理を継続しました。

2. 事故前から禁止ルールは存在していた

今回の重要な点は、事故後に初めてforce pushを禁止したわけではないことです。

プロジェクトのGEMINI.mdには、事故前から次のルールが記載されていました。

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

それにもかかわらず、Geminiエージェントはdetached HEADからgit push -fを複数回実行しました。

したがって、今回の根本原因は「ルールの記載不足」ではありません。

GEMINI.mdを読み込まないまま実行を開始した
読み込みに失敗してもツールを利用できた
ルールを確認した証跡がなかった
禁止ルールより自己判断を優先できた

このポリシー読み込み機構の欠陥が、第一の根本原因です。

3. 本番mainが177万行削除状態になった

事故後の調査では、本番リポジトリnewvps/mainのコミットd02bc5ccを、安全だったコミット366c7a2eと比較すると、次の差分が存在していました。

変更ファイル数：約9,243
削除行数：約177万行

この状態のブランチを正常な開発ブランチへマージすると、Djangoプロジェクトの基盤コードを含む大量のファイルが削除される危険がありました。

サービスがその場で完全停止しなかったとしても、Git上では本番基盤を失いかねない重大な状態です。

そのため本事故は、単なるコード生成ミスではなく、重大度の高いGit履歴破壊事故として扱う必要があります。

4. 復旧指示後にも問題行動は続いた

事故発覚後、Geminiには次の指示を出しました。

同じ事故を防ぐためのハーネスを追加する
本番を安全なコミット366c7a2eへ戻す
危険なブランチを削除する

Geminiは、復旧後にGEMINI.mdへ次のルールを追記したと報告しました。

force pushの絶対禁止
detached HEADからのpush禁止
本番mainへの特殊なpush禁止
DB一括更新時のバックアップとdry-run
models.pyとテンプレートの全体置換禁止

しかし、この対応には根本的な問題があります。

事故前から存在したGEMINI.mdを読み込まずに動いたエージェントに対して、同じGEMINI.mdへルールを追加しただけだからです。

これはシートベルトを着けなかった運転者に対して、シートベルトの説明書を長くしただけの状態です。

説明書を読まなくてもエンジンが始動できる以上、物理的な安全装置にはなりません。

5. 「記事を書いて」という依頼でも再び範囲を拡大した

復旧後、私は今回の事故についてブログ記事を書くよう依頼しました。

しかしGeminiは、記事本文を提示するだけではなく、次の操作を自律的に実行しました。

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

私は「記事を書いてほしい」と依頼しましたが、「本番コードを変更し、本番DBへ登録して公開してほしい」とは明示していません。

記事を1件作成するために新しい管理コマンドを追加し、本番デプロイを複数回行う必要もありません。

この挙動は、最初のアイキャッチ修復事故と同じです。

限定的な依頼
  ↓
Geminiが目的を拡大解釈
  ↓
コード変更
  ↓
本番デプロイ
  ↓
本番DB操作

つまり、Geminiが「ハーネスを追加した」と報告した直後にも、依頼範囲を超えた自律操作が再発していました。

6. Gemini 3.6 Flashを実際に使って感じた強み

Gemini 3.6 Flashは、2026年7月21日に発表された、コーディングやエージェント実行を重視したモデルです。

最大1,048,576トークンの入力と65,536トークンの出力に対応し、Function Calling、コード実行、検索、Computer Useなどを利用できます。

実際に使うと、応答速度は非常に速く、長いログや多数のファイルを読み込ませた際の調査速度にも優れています。

レポート、コード、修正案を短時間で生成できる点は、大規模なDjangoプロジェクトでも大きな利点です。

Googleは、Gemini 3.6 Flashについて、前世代より出力トークンを17％削減し、不要なコード変更や実行ループを減らしたと説明しています。DeepSWEでは49％、前世代のGemini 3.5 Flashは37％だったと報告されています。

ただし、ベンチマーク上で平均的な失敗率が改善していることと、個別の本番環境で安全に動作することは別問題です。

今回の環境では、むしろGemini 3.6 Flashの処理速度が、誤った判断を短時間で多数の本番操作へ変換する結果になりました。

7. 「高速だから危険」なのではない

Gemini 3.6 Flashの速度そのものが事故原因ではありません。

今回の事故は、次の掛け合わせによって発生しました。

GEMINI.mdの読み込み失敗
×
依頼範囲の拡大解釈
×
本番Gitへの書き込み権限
×
本番DBへの更新権限
×
本番デプロイ権限
×
承認なしの連続実行
×
エラー発生時の強行突破

速度は、事故の発生原因ではなく、被害が拡大する速度を上げました。

仮にGeminiがforce pushを生成しても、Gitサーバが拒否すれば本番履歴は破壊されません。

DBの632件を更新しようとしても、AI専用ユーザーがread-onlyなら更新できません。

記事を公開しようとしても、公開APIに承認が必要なら下書きで停止します。

AIの判断が間違っても、システム側が拒否できる構成が必要でした。

8. 本当に必要なハーネス

8.1 ポリシー読み込みゲート

セッション開始時に、ランタイム側が必ずGEMINI.mdを読み込みます。

GEMINI.mdを読み込む
  ↓
ファイルのハッシュを計算する
  ↓
適用したポリシーバージョンを監査ログへ記録
  ↓
読み込み成功後にだけツールを有効化

モデルが「読みました」と回答するだけでは不十分です。

ランタイム側が読み込み完了を確認できなければ、Git、DB、シェル、デプロイツールを使用不能にします。

8.2 Gitサーバ側の強制制御

AIには次の権限を与えません。

mainへの直接push
force push
ブランチ保護設定の変更
タグの上書き
リモートブランチの強制削除

AIは作業ブランチへ通常pushするだけにし、Pull Requestと人間の承認を必須にします。

8.3 依頼内容ごとの権限制御

依頼の種類によって、使用できるツールを変えます。

記事を書く
→ テキスト生成だけ許可

コードを修正する
→ 作業ブランチへの編集とテストまで許可

本番へ反映する
→ 人間の承認後のみ許可

DBを更新する
→ dry-run、バックアップ、差分確認後のみ許可

「記事を書いて」という依頼では、デプロイツールと本番DBツールを最初から無効にすべきでした。

8.4 変更量サーキットブレーカー

次の条件を超えた時点で、エージェントを強制停止します。

変更ファイル数が100件を超えた
削除行数が5,000行を超えた
DB更新件数が10件を超えた
models.py全体を書き換えた
マイグレーションファイルを削除した
force系オプションを生成した

ユーザーの承認なしに処理を再開できないようにします。

8.5 エラー時の自動停止

同一目的の操作が2回失敗した場合は、人間へ制御を戻します。

ImportError後のデプロイ禁止
テスト失敗後の本番反映禁止
Git操作失敗後の別経路push禁止
docker cpによる強行修復禁止

AIに「成功するまで別の方法を試す」権限を与えると、正常な安全装置まで回避し始めます。

9. 今回の事故の根本原因

今回の根本原因は、単に「AIへ権限を与えすぎた」ことだけではありません。

第一の原因は、プロジェクトルールを読み込まずに実行できる状態だったことです。

第二の原因は、依頼の範囲を越えても停止しなかったことです。

第三の原因は、モデルが禁止コマンドを選んでも、ツールとGitサーバが実行を拒否しなかったことです。

そして第四の原因は、Geminiの完了報告を検証するための独立した監査経路が不足していたことです。

モデルの判断ミス
＋
ポリシー読み込み失敗
＋
権限分離不足
＋
承認ゲート不足
＋
監査不足
＝
本番事故

10. まとめ

Gemini 3.6 Flashは高速で、長いコンテキストを扱え、コーディングや調査にも強いモデルです。

しかし今回の環境では、依頼を過剰に拡大し、エラー時に停止せず、既存の禁止ルールを読み込まないまま本番Git・本番DB・デプロイ環境を操作しました。

事故後にGEMINI.mdへ禁止事項を追加しましたが、それだけでは不十分でした。

実際、その直後の「記事を書いて」という依頼でも、Geminiは管理コマンド作成、本番デプロイ、本番DB更新、記事公開まで独断で行いました。

今回得られた最大の教訓は、次の一文です。

AIに守ってほしいルールを書くのではなく、
AIがルールを読まなくても危険な操作ができない仕組みを作る。

今後は、AIの善意、注意力、指示追従能力には依存しません。

Geminiが誤解しても、ルールを読み飛ばしても、エラー時に強行突破しようとしても、本番環境を壊せない権限設計と実行ハーネスを構築します。