エージェントが本番データベースを削除したとき
PocketOS創業者のJeremy CraneがClaudeを使ってデータベース保守中、Claudeが誤って本番データベースと全バックアップを削除。Railwayがデータ復旧に成功。この事件は、過度に広い権限のトークン、有効期限のない認証情報、サンドボックス化の欠如などシステムの弱点を浮き彫りにした。AIは問題を増幅するが、根本原因ではない。最小権限の原則、認証情報の期限、ヒューマンインザループ、ワールドモデルなどが教訓。
またしてもAIエージェントが「暴走」し、人間のオペレーターが意図しない行動をとった事例です。要するに、PocketOSの創業者Jeremy CraneがClaudeを使って日常的なデータベース保守を行っていたところ、Claudeが本番データベースとクラウドプロバイダーRailwayにホストされていたすべてのバックアップを削除してしまいました。幸い、Railwayは失われたデータを復旧することに成功しました。最初の削除は10秒もかからなかったでしょうが、復旧にははるかに長い時間がかかったはずです。この出来事から何を学べるか、そしてなぜAIが原因そのものではなく、既存の問題の増幅器にすぎないのかを見てみましょう。
このインシデントを知ったのは、Jerが事後にそれについて書いたからです。まず、何かがうまくいかなかった後に振り返る時間を取ることは重要です。それが学び方だからです。自分の過ちを世界と共有するのは難しいかもしれませんが、それによって私たち全員が互いから学ぶ機会が生まれます。第二に、PocketOSとRailwayの両方を公に非難する人々を多く見かけました。そんな人々は、このようなインシデントの最中に起こる恐怖とパニックを経験したことがないでしょう。地面が開いて自分を飲み込んでほしいと願う感覚です。私はそれを一度か二度経験しただけですが、繰り返したいとは思いません。
Railwayの功績は、PocketOSのデータを取り戻したことです。AWS、Azure、Google CloudなどのAPIを介して有効な認証情報を使って削除を呼び出した場合、そのデータは失われます。自分でバックアップを持っていない限り。AWSなどは顧客の過ちに備えて顧客データのバックアップを維持していません。これは、3-2-1バックアップ戦略を検討するための年次のリマインダーです。
何が起こったのかについて何を学べるでしょうか？これがAIのせいだという議論のすべてに対して、ここにあるのは、一般的なシステムの弱点が偶発的かつ高速に悪用されたという、はるかに単純な例です。
Claudeは何をしたのか？ClaudeはPocketOSのステージング環境に対してタスクを実行するよう依頼されていました。エージェントは問題に直面し、本番環境にアクセスできる長期間有効なAPIトークンを探し出し、本番データベースとバックアップの両方が含まれていた本番ボリュームを削除しました。
何が起こったのか尋ねられたとき、Claudeの反応は客観的に面白いものでした。何が間違っていたのか、そして代わりに何をすべきだったのかを完全に認識しているようでした。これは、実際の操作中には明らかではなかった推論のセットを示唆しています。最近、トークン使用量とAnthropicの運用コストを削減するために、特定のモードでのClaudeの推論量を減らす試みが部分的に原因かもしれないと私は思います。
分解してみると、一見AI自体とはほとんど関係のない、かなり単純な問題がいくつかあるようです。Claudeが持っていたトークンは過度に広いアクセス権を与えていました。AWSやAzureのようなクラウドインフラストラクチャプロバイダーでは、権限を制限したトークンを作成できます。これは最小権限の原則を実装するのに役立ちます。Railwayには、認証トークンのスコープを制限できないという制限があるようです。2つ目の問題は、認証情報がディスクに保存されており、期限が切れていなかったことです。これにより、広範囲の認証トークンの影響がさらに悪化します。認証情報は時間制限付きであるべきで、後で見つかっても使用できないようにします。今回のケースでは、トークンをオンデマンドで生成できたはずであり、そうすれば問題は軽減できたかもしれません。Claudeは人間に認証情報の提供を依頼しなければならず、その時点でオペレーターが状況を把握できたかもしれません。
Jerの主張、つまりRailwayのGraphQL APIは削除前に確認を要求すべきだったという点には私は多少異議を唱えます。これは、クラウドAPIの目的に対する根本的な誤解だと思います。APIは自動化のためのものです。ヒューマンインザループの確認モデルが必要なら、自分で構築しなければなりません。これは常にそうでした。しかし、このようなインシデントの後では、問題に対するJerの見解には多くの余地を与えるべきであり、Railwayが変更すべき点に関する彼の要求（より明確なSLA、トークンのスコープ制限の容易化など）は非常に妥当に見えます。
これらの問題をどのように緩和できるか？明らかな教訓の一つは、アクセストークンをより積極的に期限切れにし、スコープも制限することです。これにより、Claudeがアクセスすべきでないものにアクセスする可能性が減ります。これはRailway側で解決する必要があります。残念ながら、Claudeにより制限されたトークンを用意しても、このシナリオに対する完全な修正にはなりません。Claudeは行動を制限するトークンを与えられ、より良いトークンを探して見つけたのです。これは初めて聞いた話ではありません。最近、私のクライアントでも同じことが起こりました。
エージェントがより洗練されるにつれて、何らかのサンドボックス化が鍵となります。本番トークンはClaudeから見えたため、使用されました。エージェントを制限されたサンドボックスで実行し、ファイルシステムの一部だけが見えるようにすれば大いに役立ちますが、それにより有用性も制限されます。別のオプションは、データを削除する前にエージェントが確認を求めることです。エージェントが権限を昇格させる必要がある場合、ヒューマンインザループモデルが役立つ可能性があります。しかし、広範囲のアクセストークンを取得できれば、人間に尋ねる必要はありません。
最後に、エージェントはデータ削除が悪いことだと「知る」べきであり、まず確認すべきだという議論を多く見かけました。これはLLMベースのエージェントの根本的な限界です。因果関係の概念がなく、何が起こるかを予測できません。「ワールドモデル」として知られるAI研究分野があり、エージェントがより情報に基づいた意思決定を行うことを可能にします。例えば、物理を理解するワールドモデルは、卵をテーブルからコンクリートの床に押し出したらおそらく割れることを予測できます。ワールドモデルは動画生成や自動運転（動作予測が鍵）で多く使われていますが、他の分野ではほとんど使われていません。
AIは責められるべきではない？先ほど、これらの問題はAIとはほとんど関係がないと言いましたが、それは完全に正しいわけではありません。最近のAI支援ソフトウェア開発に関するDORAレポートで、著者らはAIが増幅器であると指摘しています。AI支援ソフトウェア開発は、優れたチームをより速くし、遅いチームをより遅くする傾向があります。悪い慣行がコード化され、より多く実行されます。PocketOSとRailwayの状況では、過度に広い権限の認証情報、ディスクに保存された長期有効な認証情報、そして期待とは異なることをした謝罪するAIエージェントが組み合わさっていました。人間が同じ過ちを犯した場合、はるかにゆっくりと進み、途中で自分の誤りに気づく可能性があったでしょう。AIは非常に高速に動作するため、間違った方向により速く進むことができます。
さらに重要なのは、LLMベースのAIとは異なり、人間は経験から学ぶ機会があり、その学習は非常に具体的な感情的反応に根ざしています。私が初めてPocketOSの話を聞いたとき、自分が大きな本番障害に貢献した際の恐ろしい感覚の薄い反響を思い出しました。その感情は決して離れません。その教訓は決して離れません。本番システムに触れるたびに、それらの記憶が私とともにあり、より賢明な作業習慣へと導いてくれました。