エージェントボットの不具合に関する面白い話は誰からも好まれ、そうした話にはしばしば、仮想の仲間に対するちょっとした「ざまあみろ」という気持ちが伴います。しかし、エラーの原因は不適切な管理にある場合もあります。アレクセイ・グリゴレフ氏のケースがまさにそうで、彼は勇気を出して、ウェブサイト上でClaude Codeを使って数年分のデータ（リカバリースナップショットを含む）を消去させてしまった経緯を詳細に語りました（https://alexeyondata.substack.com/p/how-i-dropped-our-production-database）。
話は、グリゴレフ氏が自身のウェブサイトAI Shipping LabsをAWSに移行し、DataTalks.Clubと同じインフラストラクチャを共有させようとしたことから始まります。Claude自体はこの選択肢を推奨しませんでしたが、グリゴレフ氏は2つの別々の環境を維持する手間とコストを考えると割に合わないと考えました。
グレゴリーは、ネットワーク、ロードバランシング、データベース、そしてもちろんサーバー自体を含む、システム全体の構築（または削除）が可能なインフラストラクチャ管理ユーティリティであるTerraformを使用しています。彼はクロードに新しいウェブサイトをセットアップするためにTerraformの_plan_コマンドを実行させましたが、セットアップの現状を完全に記述した重要な_state_ファイルをアップロードするのを忘れていました。
記事は以下に続きます
こちらもおすすめ
クロードはグレゴリーの指示通りにShipping Labsサイトのセットアップを作成しましたが、オペレーターが途中で処理を停止しました。state_ファイルが欠落していたため、リソースが重複して作成されてしまったのです。グレゴリーはクロードに重複リソースを特定させて状況を修正させ、その後state_ファイルをアップロードしました。これで問題は解決したと思い込んでいたのです。
しかし、グレゴリーはこの時点で、ボットが重複リソースのクリーンアップを続け、その後state_ファイルを参照して本来のセットアップ方法を確認するだろうと想定していました。 Terraformや類似ツールは、特に盲目的な指示に従うと、非常に容赦のない挙動を示すことがあります。クロードはstateファイルを入手したため、当然ながらそれに従い、今回は正しく設定するためにTerraformの「destroy」操作を実行しました。
インフラストラクチャの説明にDataTalks.Clubウェブサイトが含まれていたため、この操作によって両サイトの設定が完全に消去され、2年半分の記録を含むデータベースや、グリゴリーがバックアップとして頼りにしていたデータベースのスナップショットも失われました。オペレーターはAmazonビジネスサポートに連絡し、約1日でデータを復元することができました。
事後分析の中で、グレゴリーは今後同様の事態を避けるために講じている対策をいくつか挙げています。具体的には、データベース復元の定期テストの設定、TerraformとAWSの権限に対する削除保護の適用、Terraformステートファイルの保存場所をローカルマシンではなくS3ストレージに変更することなどです。彼はまた、「Terraformコマンドの実行をAIエージェントに過度に依存していた」ことを認め、今後はエージェントによる実行を停止し、クロードが提示するすべてのプランを手動で確認して、破壊的な操作はすべて自身で実行できるようにすると述べた。
Tom's Hardwareの最新ニュースと詳細なレビューをメールで受け取ろう。
この話を「愚かなボットが失敗した」事例の一つとして片付けてしまいたくなるかもしれないが、ほとんどのシステム管理者は、グリゴレフのやり方の根本的な問題点、つまり、実質的に部下であるクロードに広範な権限を与えたことや、そもそも本番環境で権限の範囲を明確にしていなかったことなどを見抜くだろう。
おそらく最大の教訓は、クロードが（意図せず）2つ目のウェブサイトの存在 の意味を理解できるような状況認識を持っていたと想定していたことだろう。これは、経験の浅いシステム管理者には到底理解できないことだ。