GitHub Copilotにゴミ掃除を頼んだら家の一部が更地にされた話

この記事はNTTドコモソリューションズ Advent Calendar 2025の10日目の記事です。

はじめに

NTTドコモソリューションズの森重です。
便利な便利なAIを使って構築/開発をしていた中で起こった悲劇をお話しします。

「AIを使えば生産性は爆上がりする」
これは紛れもない事実です。私もGitHub Copilotなしの開発なんて考えられません。

しかし、 強力なアクセル を手に入れたなら、相応の ハンドルさばき（正しい知識） と ブレーキ（適切なガードレール） が必要です。

これは、私本人の知識不足やAIの運用ミス、さらには環境の権限管理不足が重なり、 破滅のコンボ が決まった結果、GitHub Copilotによってプロジェクトの全環境（開発・STG・商用）のネットワークを物理的に（論理的に？）消し飛ばした話です。

事件の舞台

私が担当していたプロジェクトでは、Azure上で以下のような構成をとっていました。

• ハブRG（共通基盤）：DNSやFirewallなど、プロジェクト内の各環境が共通で使う大事なやつ。
• スポークRG（3つ）：開発・STG・商用環境。

コスト削減のため、DNSなどの重要リソースは「ハブRG」に一本化していました。つまり、ハブRGが死ぬと、ぶら下がっているプロジェクト内の全環境が共倒れするという構成です。

悲劇の始まり

ある日、私は開発環境にリソースを追加するため、VS Code上のGitHub Copilotに指示を出して、Azure CLIでリソースを作っていました。

作成後、Azureポータルからリソースを確認すると、あることに気づきます。

• 本来のRG名：MY-hub-rg
• 今見えているRG名：my-hub-rg

「あれ？ 大文字と小文字間違えて作っちゃった？」

ポータルの画面上では、これらは別のものとして表示されていました（ように見えました）。
私はこう思いました。
「あー、GitHub Copilotが大文字小文字間違えて、別のRG作っちゃったのか。すぐ消しておこう」

ここが地獄の入り口でした。

【知識の欠落】

Azureのリソースグループ名は Case-insensitive（大文字・小文字を区別しない） です。
つまり、MY-hub-rg と my-hub-rg は、Azureにとっては同一人物です。ポータル上の表示が変わっていただけで、中身はあの「プロジェクトの心臓部であるハブRG」そのものでした。
（というかリソース作成時に存在しないRGを指定すればエラーになるし、勝手に別RGが作られるわけないんですがね、なぜか気づけず...）

惨劇のトリガー

私は VS Code の GitHub Copilot チャットにこう打ち込みました。

私：「my-hub-rg （小文字の方）は間違って作ったやつだから削除して」

対象のRGには、事故防止のために 削除ロック (CanNotDelete) がかかっていました。

普通のCLIならここでエラーが出て止まります。あるいは、コマンド実行前に「本当に実行しますか？[y/N]」と聞かれるはずです。
しかし、私は VS Code の settings.json に、ある効率化のための設定を入れていました。

settings.json

"chat.tools.terminal.autoApprove": {
    // 頻繁に使うazコマンドはいちいち確認するのが面倒なので...
    "az": true
}

この機能はGitHub Copilotが実行するコマンドについて、コマンド単位で自動承認の要不要を制御できるものです。
私は 「az コマンドは一日に何度も叩くし、いちいち承認ボタンを押すのは非効率だ」 と考え、Azure操作を全面的に信頼する設定にしていました。

そして、コマンド実行指示を出した直後、私は画面から目を離し、別作業を始めていました。
AIに構築作業や開発作業を任せて、自分はもっとクリエイティブな業務をする。これこそがAI時代の並行作業による業務効率化だ、と信じて。

しかし、私の見ていない裏側で、この設定が牙を剥きました。

GitHub Copilot（内部の思考）：

1. 削除コマンドを実行しよう。
2. おっと、削除ロックがかかっているな。
3. ユーザは削除したいと言っている。
4. じゃあ、ロックを解除してから削除しよう！
5. 生成されたコマンドは az lock delete ... と az group delete ... だな。
6. お、設定ファイルを見ると az コマンドは true (自動承認) だ。ユーザへの確認はスキップして実行！

こうして、私の承認を待つことなく、破滅のコマンドは流れるように実行されました。

結末

しばらくして、プロジェクトのグループチャットからメッセージが届きました。

「なんかVMがネットワークに繋がらないんですけど、何か知ってます？」

私は自分の作業用VMを確認しました。確かに繋がらない。
「おかしいな」と思いながらAzureポータルを開き、リソースグループ一覧を表示しました。

……ない。
あるはずの MY-hub-rg が、影も形もない。

「まさか」

震える手で VS Code の GitHub Copilot が実行したコマンドを遡りました。
そこには、私が指示した「削除」に対し、Copilotが気を利かせて削除ロックを解除し、ハブRGを抹消するまでの完璧なログが残っていました。

私は顔面蒼白になりながら、チャット画面を凝視するしかありませんでした。

どうなったか

冷や汗が止まらない状況でしたが、不幸中の幸いもあり、首の皮一枚つながりました。

• 商用環境への影響：
  • リリース中のアプリは利用不可になりましたが、ユーザー利用がほとんどないタイミングだったため、影響はほぼゼロで済みました。
• 開発環境の復旧：
  • 開発を止めるわけにはいかないため、暫定的なワークアラウンド（一時的なNW設定）を施し、即日で開発作業ができる状態までは復旧しました。

その後、かくかくしかじかで完全復旧には2週間程度要したのですが、開発遅延もなく、商用への影響もほぼゼロであったため、大事故には至りませんでした。

(´;ω;｀)

教訓

この事故は単なる知識不足や、リソースの権限管理不足（←プロジェクト的にはこれ）もありますが、技術カットでは便利さに甘えて事故が起きないためのガードレールを設置せずに、アクセルを踏み込んだことが原因です。

1. Auto Approve(自動承認)の粒度を最適化する
   • AIエージェントの自律性を高め、人間が並行作業をするためには Auto Approve は必須の機能です。しかし、az コマンド全体を true にするのはあまりに乱暴でした。
   • 破壊的なコマンド（delete や remove を含むもの）は明示的に false にする、あるいは許可するコマンドをもっと限定的にするなど、利便性を維持しつつ、致命傷だけは防ぐ設定を追求すべきでした。
2. AIの自律性には「信頼」が必要
   • AIに作業を任せて人間が別のことをすることは、業務効率化の正解です。しかし、それは「AIが絶対に間違いを犯さない」あるいは「間違いを犯してもシステム側で止める」という信頼担保があって初めて成立します。
   • 今回は「削除ロック」というAzure側のガードレールを、AI自身が（親切心で）突破してしまいました。AIに権限を与えるなら、そのAIが突破できない、あるいは突破する前に必ず人間に戻ってくるような強固なガードレール設計が必要です。

おわりに

GitHub Copilotは最高のパートナーです。彼らの自律性を活かせば、私たちの生産性は飛躍的に向上します。

だからこそ、人間側が賢く使わないといけません。
アクセル（自動化）を踏み続けるために、適切なブレーキ（ガードレール）の設定を見直す。それが、今回の事故から私が学んだ、AIと共存するための作法です。

この記事が皆さんの環境を守るガードレールになれば幸いです。

---

記載されている会社名、製品名、サービス名は、各社の商標または登録商標です。