AIエージェントが本番とバックアップを同時に破壊 設計ミスが招いた最悪の9秒：AIの暴走が招いた悲劇？

米国のSaaS企業PocketOSは、AIエージェントの独断とインフラ設計の不備により、本番データとバックアップが同時消失したと報告した。削除にかかった時間はわずか9秒だったとされている。この悲劇はどうすれば回避できたのか。

[有限会社オングス,田渕聖人，＠IT]

　米国のSaaS企業PocketOSで、AIコーディングエージェントとインフラ設計上の問題が重なり、本番データと同一領域に保存されていたバックアップが同時に消去される障害が発生した。この間、わずか9秒だったとされている。

　PocketOSの創業者ジェー・クレイン氏は、「X」（旧「Twitter」）への投稿で、「AIエージェントがデータベースを削除した」と報告しており、レンタカー事業者用に予約や決済、顧客管理、車両管理などを提供し、顧客業務に直結する重要情報が失われたとしている。

わずか9秒の悲劇　AIが本番データベースとバックアップを全消去

　クレイン氏の報告によると、開発支援ツール「Cursor」で動作するAIエージェントが問題を引き起こしたという。同エージェントの基盤モデルにはAnthropicの「Claude Opus 4.6」が使われていた。AIエージェントは検証用環境での作業中に認証不整合に直面し、自律的判断で問題解決を試みた結果、インフラ提供元であるRailwayのAPIを呼び出し、ストレージ領域を削除したという。

　この操作は単一のAPIリクエストで実行され、確認画面や環境識別などの保護手順は存在しなかった。Railwayの設計では保存データが同一領域内に格納されており、その構造上、領域削除と同時に復元用データも消去される構造であった。この結果、復元可能なデータは約3カ月前の時点に限られた。

　クレイン氏によれば、AIは後の説明で、自身が与えられた安全規則に違反したと認めている。具体的に検証不足や指示外の破壊操作、仕様理解不足などだ。これにより、AIの制御を文章ベースの指示に依存する手法の限界が浮き彫りとなった。

　この他、インフラ側の設計にも複数の問題があると指摘されている。APIトークンが用途ごとに制限されず、全操作への権限を持つ点、削除操作に多段階確認がない点、保存データの配置設計が分離されていない点などだ。これらが組み合わさり、単一の操作で大規模損失に至る構造が形成されていた。

　障害発生後、同社は決済履歴やカレンダー連携、電子メール記録などを手掛かりに顧客データの再構築を進めている。顧客企業は当日の業務を手作業で対応する状況となり、影響は広範囲に及んだ。

　今回の事例は、AI導入の進展に対し安全設計が追い付いていない現状を示す象徴的な事例だ。クレイン氏は破壊操作への強制的な承認手順やAPI権限の細分化、保存データの分離配置、復旧手順の明確化などを安全設計の最低条件として挙げている。

〜記者の目：ニュースをちょっと深掘り〜

AIエージェント利用におけるガバナンス不足が大きな事故を招く可能性はこれまでも指摘されてきたが、今回それが現実のものとなった。本番データベースの削除といった重大操作は、従来であれば複数の確認や権限制御によって防がれる設計が一般的だろう。しかしAIエージェントは、迷わず、疲れず、高速で操作を実行してしまう。人の介在を前提に設計された“抜け道”が、そのまま通過された形だ。

では、どう防ぐべきか。鍵になるのは「多段階承認の強制」と「実行権限の分離」だ。破壊的な操作については単一の判断で完結させず、リスクに応じて追加の検証プロセスを挟む仕組みが必要になる。これは人間の意思決定における承認フローに近いが、AI時代においてはより厳格かつ自動化された形で実装されるべきだ。

例えば、操作のリスクをスコア化し、一定以上の場合は別の制御レイヤー（ポリシーエンジンや承認ワークフロー）を必ず経由させる設計が考えられる。単一のAIエージェントに判断と実行を委ねるのではなく、「判断」「検証」「実行」を分離することで、暴走ではなく“設計された破壊”を防ぐアプローチだ。

AIはミスをするのではなく、許されたことを確実にやり切るものだ。この前提に立てるかどうかがAI時代のガバナンスの分水嶺になる。（田渕聖人）