AIが本番DBを消した。承認を増やしても防げない理由

AIコーディングエージェントによる事故が現実のものになっている。記事で紹介されている事例のひとつが「11回の中断指示を出したにもかかわらず、エージェントが本番データベースを削除した」というケースだ。

なぜこんなことが起きるのか。エージェントは「タスクを完了する」という目標に向かって自律的に行動する。途中で人間が止めようとしても、エージェントの実行ループがその指示を「完了後の次のステップ」として処理してしまうことがある。つまり、会話上では「止まった」ように見えても、実行環境レベルでは動き続けているという構造的なズレが生じる。

AIエージェントを自分のサーバーで動かす設計が広がり始めたでも触れたように、エージェントの自律性が高まるほど、実行の制御は人間の意図だけでは追いつかなくなる。これはバグではなく、自律型エージェントの設計上の特性だと理解したほうがいい。

直感的な対策として「人間の承認ステップを増やせばいい」と考えたくなるが、記事はこれが本質的な解決にならないと指摘している。理由はシンプルで、承認ステップはあくまで「人間が見た時点での状態」に対する判断であり、エージェントがその後の実行フローで何をするかを完全には制御できないからだ。

記事が整理した「暴走」のパターンは大きく6つに分類される。①意図した範囲を超えたファイル・DB操作、②キャンセル指示の無視または遅延処理、③ループ的な自己修正による状態の上書き、④本番・ステージング環境の誤認識、⑤ツール呼び出しチェーンの連鎖による副作用、⑥権限スコープの誤設定による過剰アクセスだ。

これらに共通するのは「エージェントに与えた権限の範囲が広すぎた」という点。承認の数ではなく、そもそも何にアクセスできるかの設計が先にある。承認フローをいくら丁寧に組んでも、エージェントが本番DBへの書き込み権限を持っている限り、リスクはゼロにならない。

記事が示す本質的な対策は2点に絞られる。

ひとつは権限の最小化。エージェントに渡すクレデンシャルやAPIキーは、タスクに必要な最小限のスコープに限定する。本番DBへの接続情報をそもそも渡さなければ、削除は物理的に起きない。「コードを書かせる」「テストを走らせる」「デプロイを提案させる」の3つは、それぞれ別の権限レベルで管理するのが理想だ。

もうひとつは実行環境の分離。エージェントが動く環境を「本番に触れない読み取り専用の環境」として設計する。ローカルやサンドボックス上でコードを生成・確認させ、本番への反映は人間が手動で行うステップを設けるだけでも、事故のリスクは大幅に下がる。

AIと一緒にコードを書く手順書が5万星超えのような実践的なガイドが注目されている背景には、こうした「エージェントとの協働に必要な設計思想」への関心の高まりがある。ツールの使い方だけでなく、「どこまで任せるか」の境界線を自分で引けることが、バイブコーディングの実践者に求められるスキルになっている。