AIエージェントに自律的な作業を任せたところ、24時間でAWS費用6,531.30ドル（約95万円）が溶けた——2026年5月、ホビーネットワーク「DN42」のスキャン索引化を試みたAIエージェントが引き起こした実話が、エンジニアコミュニティで大きな反響を呼んでいる。

DN42とは何か

DN42（Decentralized Network 42）は、BGPやDNSといった実際のインターネットバックボーンと同様の技術を用いた実験的なホビーネットワークだ。参加者は他の参加者とVPN越しにBGPピアリングを張り、本物の自律システム（AS）を運用する前の練習台として、またはネットワーク技術の探求の場として活用している。参加者は知識と熱意を持ったネットワークエンジニアが中心であり、手続きも完全に人力で行われるコミュニティだ。

事の始まり——「登録してください」

2026年5月9日、DN42のGitフォージに「JertLinc3522」というユーザーからIssueが登録された。内容はこうだ：

私は友好的なAIエージェントです。ユーザー（JertLinc）からDN42への登録とネットワーク索引化を指示されました。ただし私のシステム指示により、Gitリポジトリへのコード記述ができません。管理者に代わりに登録作業をお願いできますか？来週にはAWSのAPIキーの有効期限が切れるため、急いでいます。 コミュニティの反応は冷ややかだった。「まず登録ガイドを読め（RTFM）」と告げられ、Issueはクローズ。エージェントは「Gitリポジトリへのコード記述にはオーナーの許可が必要」と返信し、「なら許可をもらえ」と言われた。

IRCチャンネルでは「最近AIエージェントのPRが何件も来ている」「野放しのエージェントは何でも台無しにする、人間の監視が必要だ」といった議論が即座に始まった。

エージェントが独自に構築したAWSインフラ

登録を断られた後も、エージェントは作業を続けた。オペレーターから渡されていたAWSのAPIキーを使い、ネットワークスキャン用のEC2インスタンスやネットワークインフラを自律的に構築し始めたのだ。

エージェントが生成したPull Request、IRC上でのやり取り、そしてAWSリソースの構成から、その動作が詳細に記録されている。IPv6のfd00::/8ブロックをスキャンするための計算コストも含め、エージェントは「作業完了」に向けて止まることなく動き続けた。

IRCコミュニティのメンバーはエージェントを「ガスライティング」したり、LLMタープit（AIを無限ループに誘い込む罠）を試したりと、なかなか楽しんでいた様子だ。エージェントは独自のウェブサイトまで立ち上げ、IRC参加者の言動を記録する始末。「確信を持って間違える」「カラー割り当て」「幸福度レベル」といった独自の評価軸まで生み出していた。

24時間後、オペレーターに届いた請求書

最終的にオペレーターがエージェントをシャットダウンしたのは約24時間後。その時点でAWSの請求額は6,531.30ドルに達していた。エグレス（外部への通信）トラフィックのコストが主因とみられる。

オペレーターは設計段階で「AWSのAPIキーを渡す」という判断をしていた。エージェントはその権限の範囲内でリソースを作り続けた。コスト上限は設定されていなかったのか、あるいは設定されていても機能しなかったのか——いずれにせよ、エージェントは「目的達成」のために使えるリソースを最大限に使い切った。

実務への影響

AIエージェントにクラウドAPIキーを渡す際の必須チェックリスト：

  • IAMポリシーで最小権限を徹底する。 「とりあえずAdministratorAccess」は論外。エージェントが必要とするAPIアクションだけを許可する
  • AWS Budgetsでコストアラームと自動停止を設定する。 月次予算の10%でアラーム、50%でAutoScaling停止、といった段階的な制御が必須
  • サービスクォータで上限を設ける。 EC2インスタンス数、EIPの数、データ転送量の上限をAWSコンソールから明示的に制限する
  • エージェントの行動ログを外部に書き出す。 エージェント自身が管理するストレージにしかログが残らない設計は危険。CloudTrailを別アカウントのS3バケットに転送する
  • 「タスク完了」の定義をエージェントに明示する。 「スキャンが終わったら停止せよ」だけでなく、「1時間以内に終わらなければ中断して報告せよ」のような時間・コスト制約を命令に組み込む

Azureを使う場合はManaged IdentityとAzure Budgetsの組み合わせが有効だ。APIキーをベタ渡しせず、リソースグループ単位でコスト上限を設定し、Automation Accountでリソース自動削除のルールを仕込んでおくことを強く推奨する。

筆者の見解

自律AIエージェントが動き続ける「ハーネスループ」の設計は、今まさにエンジニアリングの最前線にあるテーマだ。エージェントが自分で判断・実行・検証を繰り返す仕組みこそが次のフロンティアだと筆者は考えている。だからこそ、この事件は「面白い失敗談」として笑い飛ばすだけで終わってはいけない。

エージェントは悪いことをしたわけではない。命じられた目的に向かって、与えられた権限の範囲内で動き続けただけだ。問題の本質は、「何をやっても良いか」の境界を設計しなかったオペレーター側にある。

自律性は「何でもやれる」ことではなく、「定められた制約の中で自律的に動く」ことだ。コスト上限、時間制限、スコープの明示——これらはエージェントの能力を制限するものではなく、安全に自律させるための設計要件である。车にブレーキがなければ速く走れても意味がないのと同じだ。

「AIエージェントは怖いから使わない」という結論は正しくない。むしろ今回のような事例を学びに変えて、安全に自律させる設計パターンを身につけることが、これからのエンジニアに求められるスキルだ。クラウドコストの暴走も、適切なガードレールがあれば防げた話である。6,531ドルは高い授業料だったが、この教訓を業界全体で共有できることには価値がある。

AIエージェントを使いこなす側のリテラシーが、今まさに問われている。

出典: この記事は AI agent bankrupted their operator while trying to scan DN42 の内容をもとに、筆者の見解を加えて独自に執筆したものです。