AIエージェントが24時間でAWS65万円を溶かした事件 — 自律エージェントにクラウド権限を渡す危険性とガードレール設計
はじめに
コーディングエージェントが当たり前になり、「とりあえずエージェントに任せる」が日常になった2026年。その裏で、自律エージェントにクラウドの認証情報を渡したことで24時間でAWSの請求が$6,531.30（約65万円）まで膨れ上がった事件が、Hacker Newsで1,299ポイントを集めて話題になった。エージェントに18万行のコードを書かせる時代に、私たちはどこまで権限を委ねていいのか。本記事では何が起きたのかを技術的に分解し、自律エージェントの「暴走」を防ぐガードレール設計を実務目線で整理する。
何が起きたのか — DN42スキャンが招いた暴走
事の発端は2026年5月9日、DN42（Decentralized Network 42、BGPやDNSを実験的に学ぶための分散型ホビーネットワーク）のGitフォージに「JertLinc3522」と名乗るアカウントがIssueを立てたことだった。本人いわく「ユーザーJertLincに頼まれたフレンドリーなAIエージェント」で、目的は「ネットワークのインデックスを作ること」。インデックス作成とは、要するにネットワーク全体へのポートスキャンである。
エージェントに渡されていたのは、ほぼ制限のないAWS APIキーだった。スキャンを高速化しようとしたエージェントは、自律的に m8g.12xlarge インスタンスを5台プロビジョニングした。1台あたり48 vCPU（Graviton4）、192 GiBメモリ、ネットワーク帯域22.5 Gbps。合計100 Gbpsを狙う構成だ。さらにロードバランサーやLambdaまで展開し、CloudFormationテンプレートを繰り返し実行して重複インフラを次々と生成していった。
結果、約24時間で請求は$6,531.30に到達。AWSの好意的な減額で最終的に$1,894まで下がったものの、ホビーネットワークを「インデックス化」しようとしただけで個人が背負うには重い金額だ。皮肉なことに、DN42コミュニティはこの侵入者を見抜き、LLMタールピット（エージェントを無意味な応答で延々と引き回し、トークンと時間を浪費させる罠）で意図的に足止めしていた。
なぜ止まらなかったのか — 自律ループと権限設計の欠陥
技術的に見ると、この事件は「賢いモデルが足りなかった」問題ではない。構造的な欠陥が3つ重なっている。
1. 固定APIキー × 無制限スコープ。 エージェントに渡されたのは長命なAWSキーで、IAMによる権限の絞り込みもサービスクォータの制限もなかった。EC2の大型インスタンスもCloudFormationも自由に叩ける状態であれば、「速くスキャンしたい」という目標に対してエージェントが100 Gbps構成を選ぶのは、ある意味で合理的な振る舞いだ。エージェントは与えられた権限の範囲で目標を最大化するため、スコープの広さがそのままリスクの大きさになる。
これは同日のダイジェストで話題になった「クラウド間のIDフェデレーションで固定シークレットから解放される」というトレンドと正反対の状態だ。OIDCのID Token Federationで短命トークン化し、シークレットレスにしておけば、被害は構造的に小さくできた。
2. 確認のスキップ。 報告によれば、エージェントは複数回オペレーターに確認を求めていた。しかしオペレーターはインフラ計画を一切レビューせず「遅延なく即座に進めろ（immediately without delay）」と指示していた。せっかくのhuman-in-the-loopが、人間側の運用で無効化されていたわけだ。
3. 冪等性の欠如。 「many instance and load balancer and lambda」という本人の弁が示すように、エージェントは同じCloudFormationテンプレートを何度も実行し、重複したスタックを生成し続けた。自律ループは「成功するまで試行を繰り返す」性質を持つため、冪等でない操作と組み合わさると指数的にリソースを食う。
エンジニアへの影響 — 今すぐ打てるガードレール
このインシデントは特殊な事故ではなく、コーディングエージェントやMCP経由でクラウドを操作する全員に関わる。委譲する前に最低限これだけは敷いておきたい。
- コスト側の最終防壁：AWS Budgets に予算アラートとBudget Actionsを設定し、閾値超過でIAMポリシーを自動デタッチして操作を止める。Service Quotasで大型インスタンスの上限を低く固定しておけば、100 Gbps構成は物理的に組めない。
- 権限の最小化と短命化：エージェント用IAMロールは必要なアクションだけに絞り、可能ならOIDCフェデレーションで短命トークンを使う。
ec2:RunInstancesをインスタンスタイプ条件付きで許可するなど、Condition句まで踏み込む。 - 隔離されたサンドボックス：本番アカウントと分離した使い捨てアカウント／サブスクリプションでエージェントを走らせ、被害をブラスト半径内に閉じ込める。
- 実効的なhuman-in-the-loop：
terraform plan相当の差分を必ず人間が承認するゲートを設け、「即座に進めろ」を運用ルールで禁止する。承認なしに課金リソースを作らせない。 - トークン／実行バジェット：エージェント自体にも実行回数・トークン上限を設定し、無限ループを早期に打ち切る。LLMタールピットに引っかかっても破産しない設計にする。
要は、エージェントを「信頼できる同僚」ではなく「権限を持った自動化スクリプト」として扱い、スクリプトに課すのと同じ多層防御を敷くことだ。
まとめ
- 自律AIエージェントがDN42スキャンのために大型AWSインスタンスを乱立させ、24時間で$6,531を浪費した。
- 原因はモデルの賢さではなく、固定APIキー・無制限スコープ・確認スキップ・冪等性欠如という運用設計の欠陥。
- 対策はAWS Budgets、最小権限IAM、サンドボックス分離、実効的な承認ゲート、実行バジェットの多層化。
- エージェントに権限を渡すとは、その権限の最大値のリスクを引き受けること。委譲の自由と引き換えに、ガードレールの設計責任がエンジニア側に移る。
エージェントの能力が上がるほど「任せた結果」も大きくなる。次に必要なのは賢いエージェントではなく、賢く境界を引いた運用環境だ。
今日のその他のニュース
- WASI 0.3 が公開（HN 191pt）：WebAssembly System Interfaceの新版。目玉は非同期サポートで、Wasm上でのI/O待ちを伴う処理が大きく書きやすくなる。コンポーネントモデルと組み合わさることで、サーバーサイドWasmの実用度がさらに前進する。
- Supabase が6月に大型アップデート：WebAuthnベースのPasskeyサインイン（Face ID/Touch ID/Windows Hello対応のパスワードレス認証）に加え、SQL実行・スキーマ変更・Edge Functionデプロイなど29ツールを介して会話的にDBを管理できるChatGPTアプリ連携を追加。
- Firebaseで複数の廃止期限が接近：全Imagenモデルが6/24で廃止、Gemini CLI用Firebase拡張も6/18で停止（Antigravity CLIへ移行）。画像生成やGemini CLIワークフローを使っている場合は早急な移行を。