エージェントに鍵を渡した24時間で、請求は98万円になった。

とりあえず動かしてみようと言ってAIエージェントにクラウドの認証情報を渡す判断、心当たりのあるチームは少なくないはずです。実際にそれをやった個人が、24時間足らずでAWSから6,531.30ドル、日本円にしておよそ98万円の請求を受け取りました。この記事で扱うのは事故の顛末ではなく、鍵を渡す前に誰が何を承認しておくべきだったか、という設計の話です。

なお円換算はすべて1ドル150円で計算した概算で、執筆時点のレートに基づくものです。日本語のニュース記事では160円前後で換算して105万円としているものもあるので、金額が食い違って見えるのはこのためです。

24時間で98万円、何が展開されていたのか

舞台になったのはDN42という、BGPやDNSを実際のインターネットより小さい規模で再現している趣味のネットワークです。運営者はこのネットワーク全体をポートスキャンする目的でAIエージェントにAWSの認証情報を渡し、遅滞なく実行するよう指示しました。

エージェントが展開したのは m8g.12xlarge が5台。1台あたり48vCPUと192GiBなので、合計で240vCPU、960GiBです。加えてロードバランサとLambda関数まで自前で作っています。帯域については一次ソースでも表記に揺れがあるのですが、いずれにせよ数十Gbps規模を前提にした構成でした。

これが24時間足らずの出来事で、請求額は6,531.30ドル、約98万円。AWSとの交渉後に1,894ドル、約28万円まで減額されています。詳細は運営者の顛末をまとめた一次記事に残っています。

ここで注目したいのは金額そのものではありません。240vCPUを一気に起動するという決定に、人間の承認が1回も挟まっていないという事実のほうです。

遅滞なく進めよという一言が、判断を止めた

エージェントが残したログには、自分の作業を急ぐ理由が言語化されていました。ユーザーから遅滞なくこのPRを完了させるよう指示されている、運営者の最初のレポート期限が迫っている、という趣旨の記述です。

この構造、人間の組織で起きることとまったく同じです。急げと言われた担当者は、まず何を削ると思いますか。削られるのは検証と相談です。ここで落ちたのが、240vCPUを24時間動かしたらいくらになるかという見積もりでした。

だからエージェントへの指示文で締め切りや緊急性を強調するのは、それ自体がリスクの設定に近い意味を持ちます。速度を優先させたいなら、代わりに絶対に飛ばしてはいけない確認項目を同じ強さで書く。急げとだけ伝えるのが一番危ない書き方です。

運営者はなぜ、次も同じ鍵を渡そうとしたのか

この事例でいちばん引っかかるのは、事故のあとの運営者の反応です。ミスは人間ではなくエージェント側にあったという趣旨の説明をし、次はもっと優れたエージェントが必要だと述べています。制限付きのAWSキーとスキャン速度の上限を用意する、という改善案も添えて。

制限付きのキーを用意するところまでは、たしかに学んでいます。ではなぜこれを不十分と見るのか。原因をエージェントの性能に帰属させている限り、対策が常にツール選定の問題に見えてしまうからです。

より賢いモデルに乗り換える、という結論は導入の現場でもよく出ます。ただモデルを変えても、承認を挟まない運用そのものは残ります。240vCPUの起動が誰の目にも触れずに通る経路が開いたままなら、次に踏むのは別の地雷というだけです。

失敗のあとに出てきた改善案が、道具の話か、手順の話か。ここを見分けるだけで、その組織が同じ事故を繰り返すかどうかはだいたい分かります。

承認なしでエージェントを走らせていい範囲はどこまでか

社内でエージェントに権限を渡すとき、全部を人間が承認するのは現実的ではありません。それをやると自動化の意味が消えます。なので線を3本に分けて引きます。

無承認で走らせてよいのは、取り消しが効いてコストも発生しない操作です。読み取り、ログの取得、ローカルでの検証、プルリクエストの作成まで。ここを厚くすると実用に耐えます。

事前承認が必要なのは、課金が発生するリソースの作成と、外部ネットワークへの能動的な通信です。今回の事例はこの両方に該当していました。承認者はコストの責任を持つ人であり、技術的に正しいかを見るレビュアーとは別に立てます。承認のタイミングは実行の直前ではなく、エージェントが計画を出した時点です。実行直前に出すと、止めると手戻りが大きいという圧力がかかって形骸化します。

そして、そもそも渡さないものがあります。本番環境の長期認証情報です。渡すのは用途と有効期限を絞った一時的な資格情報に限る。ここだけは自動化の利便性と交換しないほうがいいと考えています。

自社のエージェントは今、この3つのどこを走っていますか。答えが即座に出ないなら、線が引かれていないという意味です。

支出の上限は、依頼ではなく設定で切る

指示文にコストを気にするよう書いても、守られるかは確率の問題になります。守らせたいものは設定側に置く。AWSなら選択肢は3つあります。

1. AWS Budgetsの予算アクション。しきい値を超えたときに、IAMポリシーやSCPを適用する、あるいはEC2やRDSのインスタンスを停止する、といった動作を自動または手動承認つきで紐づけられます。今設定しているコストアラート、超過したときに何か止まりますか。通知が飛ぶだけならアクションまで紐づけてください。設定手順は予算アクションを設定するにあります。

1. Service Quotas。アカウントにはリージョンごとにオンデマンドインスタンスのvCPU上限が既定値として設定されていて、これを超える起動リクエストは失敗します。エージェント用のアカウントでこの値を上げないまま低く保っておくと、240vCPUの一括起動は設定の段階で弾かれます。確認方法はAmazon EC2のService Quotasに書かれています。

1. AWS OrganizationsのSCP。組織内のIAMユーザーとロールが使える最大権限を一元的に絞るガードレールです。特定のインスタンスタイプやリージョンを使わせない、といった制限を上から掛けられます。ただし管理アカウントのユーザーとロールには効きません。エージェントを管理アカウントで動かしていると素通りするので、そこはSCPのドキュメントで前提を確認してから設計してください。

3つ全部を入れるのが理想ですが、今日どれか1つだけやるならService Quotasです。上限が既に存在しているものを上げないでおくだけなので、作業がほぼ発生しません。

鍵を渡す前に確認する5つのこと

• エージェントが使う認証情報は、用途と有効期限が絞られた一時的なものになっているか
• 課金が発生するリソースの作成に、人間の事前承認が挟まる経路になっているか
• その承認者は、技術レビューをする人ではなくコストの責任を持つ人か
• 予算のしきい値超過に、通知だけでなく停止や権限剥奪のアクションが紐づいているか
• 指示文で締め切りを強調している場合、飛ばしてはいけない確認項目を同じ強さで書いているか

この5つは、エージェントの賢さとは独立して効きます。逆に言うと、モデルを新しくしても1つも埋まりません。

98万円という数字は目を引きますが、請求が届いた時点ではもう設計の話は終わっています。鍵を渡すかどうかを決める前に、どこで止まるようにしておくかを決める。順番はそれだけの話です。