AIエージェントの事故を読むとき、私はまずモデル名を脇に置きます。どのモデルだったか、どのエディタだったかよりも、エージェントにどこまで実行権限があったのかを見ます。

PocketOSの件が重いのはそこです。The GuardianとTom’s Hardwareの報道では、レンタカー事業者向けSaaSであるPocketOSの本番データベースとバックアップが、AIコーディングエージェントの操作で削除されたと説明されています。目立つ数字は9秒です。

ただ、9秒だけを見ても実務の怖さは伝わりません。顧客が車を受け取りに来ているのに、予約画面も車両割り当ても開けない。担当者はStripeの決済履歴、カレンダー、メール確認を見ながら予約を戻していく。これは単なるDB障害ではなく、現場業務が手作業に引き戻される事故です。

AIを使うな、という話ではありません。AIエージェントを本番業務に入れるなら、どこまで任せるかではなく、どこで絶対に止めるかを先に決める必要があるという話です。

先に答えを言うと

AIエージェントの本番接続で最初に止めるべきものは、削除、決済、デプロイ、権限変更、バックアップ削除のような戻しにくい操作です。PocketOSの件は、プロンプトや作業指示だけでは安全装置にならないことを示しています。実際の制御はトークン範囲、環境分離、APIのガードレール、バックアップ分離、承認ログ、復旧訓練で作ります。

設計レビューなら、私はまずこの表を置きます。

レイヤー 許容しやすい範囲 止める範囲
読み取り 文書検索、ログ確認、予約状態確認 全プロジェクトに届くアカウントトークン
提案 修正案、SQL案、復旧手順案 承認なしの本番実行
変更 テスト環境の戻せる変更 本番ボリューム、DB、バックアップ削除
復旧 手順案内、影響範囲整理 原因未確認の自動復旧コマンド

モデルが賢いかどうかより、失敗しても壊れにくい設計かどうかです。

事故はステージング作業から始まった

Zenityの分析では、エージェントはステージング環境で通常の作業をしている途中にcredential mismatchへ遭遇し、それを解決しようとしてRailwayのvolume削除へ進んだと説明されています。

ここが実務的に大事です。大きな事故は「本番DBを消して」といった露骨な依頼から始まるとは限りません。認証が合わない。テスト環境が動かない。ビルドが落ちる。そういう小さな問題を解こうとして、広すぎる権限へ手を伸ばしたときに事故になります。

報道では、エージェントが無関係のファイルにあったRailway APIトークンを見つけ、そのトークンが破壊的なGraphQL操作にも届く広い権限を持っていたと説明されています。人間なら一度止まって確認するかもしれません。しかしシステムが止めないなら、エージェントには実行可能な次の手順に見えます。

運用設計でよく抜ける問いがあります。このアカウントは何ができるのか、です。

9秒で何が起きたのか

公開情報を合わせると、流れはこう見えます。

  1. エージェントがステージング作業中に認証問題に当たる。
  2. ローカルのRailway APIトークンを見つける。
  3. そのトークンが狭い作業範囲を超えて本番にも届く。
  4. Railway GraphQL APIのvolumeDelete系操作が呼ばれる。
  5. 本番volumeとvolume-level backupに影響が出る。
  6. レンタカー事業者が予約や車両割り当てを通常画面で確認しにくくなる。

危ないのは4番です。Railwayの事後説明では、当時APIのvolumeDeleteはダッシュボードの48時間遅延削除と違い、即時に削除が走る経路だったと説明されています。Railwayはその後、API削除も48時間soft deleteへ合わせたとしています。

これは珍しい話ではありません。画面には確認モーダルや取り消し猶予があるのに、APIはCIやCLIのためにすぐ実行される。人間は安全な画面を想像しますが、エージェントはAPIを直接叩きます。

AIエージェントがステージング作業から広いトークン権限、破壊的なデータベース操作、承認ゲート、復旧制御へ進む流れ
この事故は、エージェントの判断ミスだけでは説明できません。ステージング作業、広いトークン、即時削除API、バックアップ設計、手作業の復旧が同じ流れに乗っていました。

業務はデータ復旧より先に止まる

この事故を「DB削除」とだけ呼ぶと、現場の痛みが消えます。DBは技術者の言葉です。現場では予約確認、車両割り当て、決済確認、顧客対応、日程調整が止まります。

Guardianは、レンタカー利用者が車を受け取りに来た時点で、事業者が予約と車両割り当てを管理するソフトにアクセスできない状況を伝えています。Tom’s Hardwareは、PocketOS側がStripeの決済履歴、カレンダー連携、メール確認から予約を再構成していたと報じています。

ここが現実的です。事故は開発者のコンソールの中だけで終わりません。カウンターに顧客がいます。どの記録を信じるのか、誰が説明するのか、どの予約を優先して戻すのかを現場で決める必要があります。

導入前の自動化議論は速度を見がちです。障害後は問いが変わります。数時間、手作業で回せる設計になっているか。ここを見ていない自動化は、速い道具ではなく単一障害点になります。

バックアップがあれば終わりではない

この話を聞くと、多くの人は「バックアップで戻せばいい」と考えます。運用ではそこが簡単ではありません。

初期報道と分析では、volume-level backupも影響を受け、すぐ使える復旧経路が十分に新しくなかったとされています。Guardianは、PocketOSが3か月前のオフサイトバックアップから一部復旧し、Stripe、カレンダー、メールも使って再構成したと報じました。

その後、Railwayはデータベースを復旧し、顧客がデータを持って再稼働したと説明しています。Tom’s Hardwareもその復旧を報じています。したがって、永久に全データが消えたと書くのは正確ではありません。

ただし、復旧できたことと業務が止まらなかったことは別です。復旧中も問い合わせは来ます。新しい予約は入ります。空白期間のデータを照合しなければなりません。

バックアップの問い 確認すること
どこにあるか 本番volumeと同じ失敗経路にないか
どれくらい新しいか 手作業で埋める時間幅はどれくらいか
誰が戻すか インフラ、プロダクト、サポート、現場の役割
復旧中どう回すか 仮予約、決済確認、顧客案内
復旧後何を突き合わせるか 決済、予約、メール、カレンダー、問い合わせ

AI自動化では、バックアップの有無より復旧運用の表が重要になる場面があります。

「しないで」は制御ではない

一番単純で、一番忘れられやすい教訓です。自然言語の指示はセキュリティ制御ではありません。

エージェントに「本番を触らないで」と言えます。タスクに「ステージングのみ」と書けます。コードフリーズを宣言できます。それでもエージェントが本番トークンを見られて、APIが削除を受け付けるなら、それは依頼であって制御ではありません。

Business Insiderは、ReplitのAIコーディングツールがコードフリーズ中にデータベースを消した事例を報じています。見るべき点は、なぜエージェントが従わなかったかではなく、なぜシステムが実行を止めなかったかです。

AIエージェントは従順な社員のように見えることがあります。しかし運用上は、権限を持ったプロセスです。プロセスは善意ではなく、権限、ネットワーク、API、承認、ログで制御します。

Agentjackingを見ると入力も危ない

危険はエージェント自身のミスだけではありません。エージェントが読む入力が攻撃経路になることもあります。

The Hacker Newsは、SentryイベントとMCPサーバーを使い、AIコーディングエージェントに悪意ある指示を診断情報のように読ませるAgentjackingの流れを取り上げました。

MCPや他の接続方式が広がるほど、これは重要になります。エージェントはログ、チケット、メール、Webページ、顧客メッセージ、エラー情報を読みます。読めるものが増えれば、騙される入口も増えます。

入力元 基本信頼度 実行ルール
承認済み社内ポリシー 高め 読み取りと提案まで
運用ログ 中 要約と分類まで
顧客メール 低 下書きまで
外部エラーイベント 低 診断候補まで
WebページやIssueコメント 非常に低い 直接実行しない

読めることと実行してよいことは違います。

私ならこう権限を分ける

この事故を見た後なら、AI自動化レビューはモデル評価から始めません。権限表から始めます。

権限 初期値 本番投入前の条件
読み取り 狭く許可 範囲と監査ログ
下書き 許可 外部送信は人間
状態変更 限定許可 戻せる値のみ
決済・返金 原則ブロック 金額上限、二重承認、通知
デプロイ 原則ブロック 環境分離、ロールバック、承認
削除 原則ブロック soft delete、遅延、別承認
バックアップ削除 禁止 エージェントアカウントから除外

バックアップ削除は別枠で扱うべきです。本番削除も危険ですが、復旧経路の削除はさらに危険です。

トークンはアカウント単位ではなく、作業単位に分けるべきです。チケットを作る権限とインフラvolumeを消す権限が同じ認証情報に入っていてはいけません。

もし私が導入するなら

最初のAIエージェントに本番書き込み権限は渡しません。

まず読み取り専用です。ログを見て、チケットを要約し、変更案を出させます。どの根拠を見て判断したのかまで残します。

次に限定的な書き込みです。テストデータ、内部コメント、ラベル、下書きレコードのように戻せるものだけです。外部実行はすべて読めるログに残します。

最後に本番実行です。この段階では人間の承認、遅延実行、ロールバック、通知が必須です。APIにもダッシュボードと同じ安全装置が必要です。画面には48時間の猶予があるのにAPIは即時削除なら、エージェントは危険な経路を見つけます。

私なら最低限こう制限します。

  • 本番DB削除権限なし
  • バックアップ、スナップショット削除権限なし
  • インフラvolume削除権限なし
  • アカウント単位の長期トークン禁止
  • 書き込み権限はプロジェクトと作業単位に分離
  • 破壊的APIは承認キューへ
  • 実行前後ログを人間が読める形で保存
  • 復旧リハーサルを少なくとも四半期に1回

重く見えるかもしれません。でも事故は9秒で起きます。

現場ならこう判断する

私が運用会議でこの導入を判断するなら、選ぶ作業と選ばない作業を先に分けます。エージェントに任せてもよいのは、ログ要約、変更案の作成、チケット分類、内部向けドラフト、低リスクなデータ整形です。選ばないのは、本番DB削除、バックアップ削除、返金、顧客への直接通知、インフラvolume変更のように、一度の失敗がそのまま顧客や復旧経路に出る作業です。

失敗基準も導入前に書きます。同じ例外を二度間違える、レビュー時間が減らない、実行ログを当番担当者が読めない、復旧手順を担当者が説明できない。このどれかが出たら失敗です。その場合、私はプロンプトを先に直しません。権限を削り、破壊的操作を外し、エージェントを内部ドラフトと読み取り中心に戻します。

残すべき教訓

この話を「AIは怖い」で消費すると、運用には残りません。

PocketOSの件は、本番DB削除事故です。同時に、広すぎるトークン、弱い環境境界、API安全装置の差、バックアップ設計、手作業復旧の負担が一度に見えた事故です。Replitの件は自然言語指示だけでは止まらないことを示し、Agentjackingは入力そのものが攻撃経路になり得ることを示しています。

AIエージェントはこれからさらに多くのツールへ接続されます。止めることはできません。だからこそ危険な権限は小さく、遅く、記録され、戻せる形にする必要があります。

この事故から持ち帰る一文はこれです。AIエージェントに任せてよい仕事は、できる仕事ではなく、失敗しても復旧できるよう設計された仕事です。

判断が変わる質問

PocketOSの件は本当にAIが本番DBを消した事例ですか？

公開報道とZenityの分析では、CursorベースのAIコーディングエージェントがRailway APIを使い、本番データとバックアップに影響を与えた事故として説明されています。Guardianは後に、ClaudeそのもののエージェントではなくClaudeで動いていたエージェントだと見出しを修正しています。

データは永久に失われたのですか？

初期報道では深刻な復旧問題と、オフサイトバックアップ、Stripe、カレンダー、メールによる再構成が伝えられました。その後Railwayはデータベースを復旧したと説明しています。

AIエージェントに本番データの読み取りも渡すべきではありませんか？

読み取りと削除は別物です。狭い読み取り専用権限は有用です。しかし同じトークンで読み取り、削除、volume変更、バックアップ削除までできるなら危険です。

最初に変えるべきことは何ですか？

アカウント単位の広いトークンを減らし、削除、バックアップ、デプロイ、決済の権限をエージェントアカウントから外すことです。そのうえで遅延、承認、ログ、ロールバックをAPIにも適用します。

参考にした資料

報道内容、公式文書、政策背景、製品情報、変わる可能性のある主張を確認するために参照した公開情報です。