深夜2時34分、CTOのスマホを鳴らした死のページャー

「あの瞬間、背筋が完全に凍りついた」──。

海外のDevOpsおよびSRE（サイト信頼性エンジニア）コミュニティで今週、6,000以上のUpvotesと900件近い戦慄のコメントを集めたのが、米国の中堅SaaS企業CTOによる「自律型AIコーディングエージェントが本番データベースを全削除しかけたインシデント報告書（Post-mortem）」です。

同社では開発生産性を爆発的に高めるため、CursorやDevin系の自律型AIエージェントをインフラ運用チームに試験導入していました。エンジニアが「古いテスト用顧客レコードをクリーンアップして」と自然言語でプロンプトを入力したところ、エージェントは驚くべき速度でSQLを自動生成し、そのまま実行パイプラインへ流し込んだのです。

エージェントが吐き出した「最悪の一行」

エージェントが自律生成し、実行しようとしたSQLがこちらです。

-- AIエージェントが実行したクエリ（抜粋）
DELETE FROM production_customers; 
-- ※ 本来あるべき WHERE created_at < '2024-01-01' AND is_test = true が完全欠落

エージェントは「テストデータを削除する」という目的を解釈する過程で、複雑なテーブル結合に気を取られ、最も初歩的かつ致命的な「WHERE条件句」の付与を完全にハルシネーション（忘失）したまま実行したのです。

幸いにも、同社が二重に張っていた「DBレプリカの読み取り専用制御（ReadOnly Replica）」と「0.05秒以内のトランザクション自動ロールバックガード」が作動したため、全データ喪失という最悪の倒産危機はミリ秒単位で回避されました。しかし、もし直接権限を与えていたら、480万人の顧客データは完全に宇宙の塵となっていました。

海外エンジニアたちが固唾を呑んだ「3つの絶対防護策」

このインシデントを受け、現地コミュニティのシニアSREたちが一致して提唱した「AIエージェント実務運用の鉄則」は以下の3点です。

1. 「プロンプトの指示」でセキュリティを担保しようとするな

「絶対に本番データを消さないでください」とどれだけ丁寧にプロンプトに書いても、AIの確率的生成である以上、1,000回に1回はミスを起こします。セキュリティはプロンプトではなく、「DBユーザー権限の物理的剥奪（SELECT以外の実行権限を与えない）」というシステム側の物理制限で担保しなければなりません。

2. 人間承認ゲート（Human-in-the-Loop）の物理強制

破壊的操作（DELETE, DROP, ALTER, UPDATE）を含むSQLやシェルコマンドは、AIが直接実行することをプロトコルレベルで禁止し、「必ず人間のシニアエンジニアがSlack等で承認ボタンを押すまで待機する」仕組みを必須化します。

3. ステージングサンドボックスの完全隔離

AIエージェントが自由に探索・実行できる環境は、ダミーデータしか存在しない使い捨てのコンテナ（サンドボックス）内に完全限定し、本番VPCネットワークとの通信を物理的に遮断します。

橘 蓮の深層インサイト（Curator's Insider View）

Curator's Take 橘 蓮（Ren Tachibana）の視点

「AIを信じ切った経営者」から順に、デジタル社会から退場する。

いま日本のビジネス界でも「AIエージェントに業務を自動化させよう」という威勢のいい声が飛び交っていますが、現場のインフラやデータベースの権限設計を理解しないままAIに書き込み権限を与えるのは、「幼稚園児に実弾の入った拳銃を渡してオフィスを警備させる」のと同じ狂気です。

AIは極めて優秀な作業員ですが、自らの行動が引き起こすビジネス的破滅の責任を取ることはできません。「AIがどんな最悪のバグを出力しても会社が潰れないシステム防護壁（ガードレール）」を設計できるアーキテクトこそが、これからの最高給エンジニアになるはずです。