AIエージェントに必要なのは警告メールではなく支出の遮断装置だ

Simon Willisonは、従量課金サービスが予算到達時に実際に停止する仕組みを標準にすべきだと訴えた。エージェントが夜間もAPIを呼び出し、インフラを立ち上げられる今、hard capは請求機能ではなく安全境界になる。

予算超過時に必要なのはメールではなくエラーだ

Willisonは、警告を送るだけのsoft capと、その後のリクエストを拒否するhard capを区別する。提案は単純だ。月額Xドルに達したらサービスを止め、エラーを返す。個人も企業も、1万ドルを超える予想外の請求より、一時停止を選ぶはずだという。

大手事業者も動き始めている。AWSは9月16日、上限に達したプロジェクトを月末まで停止する月間spend limitを発表した。ただし、現在は限られた顧客への提供にとどまる。Google Cloudも7月、1つのプロジェクト内の対象サービスに使えるSpend Capsを導入した。発動後は新規利用が止まるが、利用額の集計遅延によって追加料金が生じる場合がある。

予算はエージェントの権限セットに組み込まれる

有料APIへアクセスできるcoding agentは、役立つアプリをデプロイできる一方、制御不能な消費も生み出せる。金額上限は、アクセス権、ネットワーク規則、監査ログと並ぶ管理項目になる。人間の追加承認なしに自動化が許される損害の範囲を決めるからだ。

開発者にとっては、ベンダー選びと設計の両方が変わる。プロジェクト、環境、エージェントごとに上限を設け、到達時には安全に機能を縮退させる必要がある。企業アカウント全体に1つだけ設定する上限は粗すぎる。実験が予算を使い切り、重要な本番システムまで止めかねない。

hard capにも集計の遅れがある

hard capという名前は完全な壁を連想させる。しかし、cloudの請求データには遅延があり、処理中のリクエストは通常そのまま完了する。Googleも、適用は即時ではなく、超過分は顧客負担になると明記している。月間上限だけでなく、リクエスト数のquota、リアルタイム計測、緊急停止を組み合わせる必要がある。

停止による損失が超過料金を上回る場合もある。企業には、実験を完全停止するモード、社内ツールを制限運転するモード、重要サービスで担当者へエスカレーションするモードが必要だ。選択肢がなければ、最初の不都合な停止をきっかけに安全機能が無効化される。

初期設定と実際の超過額が成否を分ける

最初に見るべき指標は、AWSとGoogleが新規プロジェクトでhard capを自動的に有効にするか、設定画面の奥に置くかだ。次は実運用の数字である。設定額をどれだけ超えた時点で、新しい利用が止まるのか。

事業者は上限をAPIから設定できるようにし、エージェントへ他の権限と一緒に予算を渡せるようにすべきだ。機械的に管理できる上限がなければ、デプロイ速度が請求管理を追い越し続ける。

Lilithの判定

支出上限のないエージェントは、監督者のいない夜勤で法人カードを持たされた研修生だ。警告メールが届く頃には、請求書はもう机の上にある。