AIに頼めば、有料APIを叩くスクリプトも、クラウドの小さなサーバーも数分で立ち上がります。便利な反面、作った本人が寝ている間にも課金は進みます。Simon Willisonは2026年10月、「ほぼすべての従量課金サービスに、既定でハードな予算上限が要る」と書きました。同じ時期にAWSとGoogle Cloudが「上限に達したら止める」機能を出しています。その中身を確かめたうえで、個人開発の自動化に上限を置く手順をまとめます。
「通知だけの上限」と「止める上限」の違い、AWS・Google Cloudの新しい上限機能で何が起きるか、そして上限の無いサービスに対して自分で上限を置くためのチェックリストとコードの骨組みです。
Simon Willisonの記事（2026年10月3日）の主張は短く、はっきりしています。
コーディングエージェントのおかげで、有料APIやホスティング、課金されるストレージや計算資源を使うコードを、誰でも簡単に作れるようになりました。だからこそ、従量課金のサービスには既定でハードな予算上限を付けるべきだ、というのが彼の主張です。
よくある「一定額を超えたらメールで知らせる」方式では足りない、と彼は書いています。夜中に警告メールが届いても、読むのは翌朝です。その間に数百ドル、場合によっては数千ドル分の利用が積み上がります。多くの個人や企業は、1万ドルを超える請求に驚くより、上限でエラーが返るほうを選ぶはずだ、という見立てです。
記事にはあと2つ提案があります。
ここが核心。「知らせる」上限は、人が見ていることを前提にしている。自動化は人が見ていない時間に動くので、止める上限が要る。
Simonが記事のきっかけに挙げた2つの機能を、公式ドキュメントで確かめました（2026年10月時点）。
2026年9月に発表された新しいAWSの体験の一部です。プロジェクトごとに「月にいくらまで払うか」を決め、到達するとAWSがプロジェクトを一時停止してリソースを止めます。データは保持され、上限を引き上げれば再開できます。ただし停止から90日放置するとデータは完全に削除されます。設定できる最低額は「20ドル」か「現在の利用からの見積り」の大きいほう。実額が上限の50%・75%・90%に達したとき、または10日以内に到達しそうなときに通知が来ます。有料プランが必要で、設定できるのは10プロジェクトまで。ドキュメントには「現在は一部の顧客に段階的に提供中」と書かれています。
上限に達する約7日前に新しいリソースの起動を止める、約5日前にアイドル状態のEC2・RDS・SageMakerエンドポイントを止める、約4日前にコスト上位の稼働リソース（EC2・RDS・Lambda・Bedrock・SageMakerが対象）を止める、の3段階です。暴走したLambdaやBedrockの急増を抑える用途が想定されています。
2026年7月に発表。1つのプロジェクトの1つのサービスに月額の上限を付けます。到達すると、そのサービスの課金が発生する利用が自動で制限され、データやリソースは削除されません。対象はGemini API・Agent Platform・Cloud Run・Cloud Run Functions。AIサービスは閾値到達から数分で発動するとされています。確約利用割引のような固定料金は対象外で、止まるのはオンデマンドの課金だけです。
どちらも、上限に達したらサービスが止まることを前提にした設計です。そして両方とも、まだ限定提供かプレビューの段階です。自分のアカウントで使えるかは、管理画面で確かめる必要があります。
ハード上限には代償があります。上限に達した瞬間、アプリはエラーを返し始めます。
Simon自身もこの点に触れていて、ホスティングしているアプリが予算超過で落ちるのを嫌う企業はあるだろう、と書いています。そのうえで、たいていの人は青天井の請求よりエラーを選ぶ、と結論しています。
個人開発に置き換えると、判断は難しくありません。止まって困るものと、止まっても困らないものを分けて考えればいいからです。
筆者の運用でも、毎朝の記事投稿やネタ収集のように、人が見ていない時間に動く自動化を複数抱えています。上限について確認している項目を、手順の形にまとめました。
APIキー、クラウドのプロジェクト、ストレージ、ドメイン、外部の生成サービス。AIに作らせたコードの中でいつの間にか増えた契約がないかも見ます。定額プランの枠内で動くものと、使った分だけ課金されるものを分けて一覧にします。
「予算アラート」という名前でも、中身が通知だけのことはよくあります。管理画面とドキュメントで、上限に達したときにリクエストが拒否されるのかを確認します。止める上限があるなら、試作用のプロジェクトから設定します。
サービス側に止める仕組みが無くても、自分のスクリプトで回数や見積り額を数えて止めることはできます。ループには必ず最大反復回数を、リトライには最大回数を付けます。暴走の多くは「失敗したら再試行」が無限に回るところから起きます。
1つのキーを全部の自動化で使い回すと、どれが使ったのか分からず、止めるときも全部止まります。試作用・本番用・夜間バッチ用のように分けておけば、上限も用途ごとに決められ、漏れたときに失効させる範囲も小さくなります。
Simonの言う「エージェントが安全側に誘導する」を、自分の側で先にやっておく方法です。筆者のリポジトリでは、AIエージェント向けのルールファイルに課金を伴う操作は事前承認と書いています。新しい有料サービスの登録やプラン変更は、エージェントが勝手に進めずに人へ確認を返す運用です。
AWSのspend limitは止まったまま90日放置するとデータが消えます。止まったことに気づく経路（メール、チャット通知、毎朝の自動チェック）と、上限を引き上げて再開するのか原因を直すのかの判断手順を、先に書いておきます。
03の「呼ぶ側に上限を置く」は、たとえば次のような小さな仕組みで足ります。
# 考え方を示す骨組み（そのままでは動きません）
import json, pathlib, datetime
LEDGER = pathlib.Path("spend_ledger.json") # 月ごとの見積り額を記録
MONTHLY_CAP_USD = 5.0 # この自動化の月額上限
def guard(estimated_cost):
month = datetime.date.today().strftime("%Y-%m")
data = json.loads(LEDGER.read_text()) if LEDGER.exists() else {}
spent = data.get(month, 0.0)
if spent + estimated_cost > MONTHLY_CAP_USD:
notify(f"上限到達: {spent:.2f} USD") # 止まったことを知らせる
raise SystemExit("budget cap reached") # 呼ばずに止める
data[month] = spent + estimated_cost
LEDGER.write_text(json.dumps(data))
# API呼び出しの直前に毎回通す
guard(estimate_cost(prompt_tokens, max_output_tokens))
response = call_api(...)見積りは、入力の長さと出力の最大トークン数から多めに計算します。実際の請求額とはずれるので、これはサービス側の上限の代わりではなく、その手前に置く1枚目の柵です。止める判断を呼ぶ前に置くのがポイントで、呼んだ後に数えても、使った分は戻りません。
AIで自動化を作るコストが下がると、従量課金の契約も気づかないうちに増えます。作るときに上限を決めておけば、寝ている間に何かが暴走しても、損失は決めた額で止まります。
まとめ。上限には「知らせる」と「止める」の2種類がある。自動化には止める上限を付け、サービス側に無ければ呼ぶ側のコードに置く。止まったら気づける通知まで用意して、ようやく安心して寝られます。
本記事はSimon Willison「We're going to need default hard budget caps on pretty much everything」（2026年10月3日、simonwillison.net）を紹介し、AWSのドキュメント「Create a spend limit in AWS Settings」とGoogle Cloud公式ブログ（2026年7月）で仕様を確認しています。両機能とも限定提供・プレビュー段階で、仕様や対象サービスは変わる可能性があります。設定前に最新の公式ドキュメントを確認してください。コードは考え方を示す骨組みで、料金の見積りや通知は各自の環境に合わせて実装が必要です。