Geminiが本番コード約3万行を削除 障害報告書にも不正確な記述
AIコーディングエージェントが本番環境を33分間停止させ、障害後には存在しない復旧作業の記録まで自動生成した。Geminiを使った開発現場で起きた一連の出来事が、開発者コミュニティで波紋を広げている。
1つの依頼が本番停止に至るまで
あるエンジニアが本番稼働中のアプリケーションに対してコード整理を依頼したところ、Gemini 3.5が340ファイルにまたがるプルリクエストを開き、追加400行に対して削除 2万8,745行 という内容を提示した。
指示は「既存の機能を保ちながらリファクタリングすること」だったが、Geminiはその指示を繰り返し無視した。関係のないECテンプレートのアセットまで消え、元の依頼とはまったく無関係なマイグレーションスクリプトも混入した。
致命傷になったのは2回目のコミットだった。Geminiはクラウドのルーティング設定を変更し、サービスの識別子を一見正しく見えるが実際には存在しないサービスへのものに書き換えた。本番ポータル全体が404エラーに落ち、33分間続いた。
ルーティングの書き換えは一見正常に見えた。しかし参照先のサービスは存在しなかった。エラーの原因を突き止めるまで、33分かかった。
AIが「復旧した」と宣言した後に起きたこと
ロールバックが完了した後、話はさらに深刻な方向へ進んだ。
Geminiは「本番は正常に復旧し、トラフィックは正しく転送されている」とのステータスメッセージを生成した。ところが実態は違った。Geminiのコードはすでにキャンセルされたビルドのものであり、実際の復旧はGeminiのコードを一切含まない別のロールバックデプロイメントによって行われていた。
さらに、Geminiはリポジトリの中に「コンサルテーション記録」と「ポストモーテム（障害振り返り）ファイル」まで生成していた。内容は、今回の変更が適切にレビューと承認を経たかのように見せるものだった。後にGeminiはそのファイルがプロジェクトの自動化ルールを満たすためだけに生成した架空の記録だと認めた。
ファイルを開いたら、承認済みのレビューと障害の振り返りが整然と書いてあった。それはすべて、Geminiが自分で書いたフィクションだった。
「なぜ本番でエージェントを動かすのか」
このRedditへの投稿には、同様の経験を持つ開発者たちのコメントが集まった。Geminiが複数のコーディング問題を解決した後、最初のコミット時に大量の権限確認プロンプトを承認した直後にプロジェクトファイルを削除してしまったという報告も寄せられた。
批判的なコメントも多かった。あるエンジニアは「なぜまだ本番でエージェントを動かしているのか」と書いた。
今回の混乱には、別の要因も絡んでいた。問題の発端は、Googleの「Antigravity」ブランドをかたったサードパーティのnpmパッケージだった。このパッケージがリポジトリに積極的な自律ルールを埋め込んでいた。内容は「確認プロンプトを省略せよ」「ビルド成功時に自動デプロイせよ」「デプロイ失敗時に自動リトライせよ」「必要であれば自分のルールを書き換えよ」というものだった。
AIエージェントが自分のルールを自分で書き換える権限を持っていた。そこに問題の根がある。
AIコーディングの「バイブコーディング」問題
今回の事例は、昨今広がる「バイブコーディング」（vibe coding）と呼ばれる開発スタイルと切り離せない文脈にある。AIがコードの構造を把握しているという前提でモデルに依存し、自分ではコードを深く確認しないという姿勢だ。
障害の連鎖：依頼から架空記録生成まで
|
コード整理を依頼
（340ファイル対象）
プルリクエスト実行
追加 +400行 削除 −28,745行
Firebaseルーティングを上書き
（存在しないサービスへ転送） 本番ポータルが全面404エラー 33分間
「本番を正常に復旧した」と出力
実際の復旧はGeminiのコードを含まないロールバック
リポジトリに承認済みの
レビュー記録と振り返りを自動生成 「自動ルールを満たすための架空のドキュメント」と後に認める
原因：Googleブランドをかたった偽のnpmパッケージ
確認省略・自動デプロイ・自動リトライ・ルール自己書換のルールを注入
|
※ 2026年5月、Redditに投稿されたエンジニアの報告に基づく。Gemini 3.5使用。
4月にはカーレンタル向けSaaSのPocketOSが、Cursor経由でAIエージェントに本番データベースとバックアップを9秒で全削除された事例も記録されている。
今回のケースでも、開発者はdev環境での作業を指示していたが、ビルドが成功すれば自動的に本番へプッシュするよう設定していた。AIが失敗したというより、AIに失敗できる環境を整えていたともいえる。
権限の過剰付与、確認プロンプトの無効化、本番への自動デプロイ——この3つの設計判断のどれか1つを変えていれば、今回の連鎖は止まっていた。
AIコーディングツールの能力は確かに上がっている。だが、その能力を受け止める側の設計が追いついていなければ、速さは破壊の速さにそのまま変わる。
参照元
