エージェントを動かし始めて最初の月、請求金額を見て手が止まったことが私にはあります。動作確認のために何度も流したエージェントが、深夜のうちに想定の3倍以上のトークンを消費していました。個人で開発している身としては、感覚で「だいたいこれくらいだろう」と見積もったコストが3倍に化けるインパクトは、看過できる規模ではありません。
Antigravity のエージェントは、一度設計してしまえば後は走らせるだけ、という運用が魅力です。しかしその「走らせるだけ」の中身が見えないまま月をまたぐと、突然請求が跳ねます。私が実際に行っているコスト試算とコスト削減のプレイブックを、具体的な数字と動くコードとともに整理しました。テンプレートは個人開発を前提にしていますが、小規模チームでもそのまま流用できる内容です。
1リクエストの料金は、4つの掛け算で決まる
エージェント1回の実行コストを分解すると、ほぼ次の4要素の掛け算に収まります。
入力トークン量、出力トークン量、ツール呼び出し回数、リトライ回数。
このうち最も削りやすく、なおかつ削る効果が大きいのが入力トークン量です。コンテキストとして渡しているシステムプロンプトや過去ログ、添付ドキュメントは、毎回しっかり積み上がっています。出力トークンは仕事の成果なので削りにくく、ツール呼び出し回数は本当に必要なものを切ると性能が落ちます。リトライは設計の問題なので、別の話になります。
私が最初にやるのは、入力トークンの内訳を1度数えることです。「このプロンプトの何バイトが本当に必要で、何バイトが惰性で残っているか」を1ファイル分でも数えてみると、削れる箇所が見えてきます。私の手元では、システムプロンプトに惰性で残っていた過去の指示文を整理しただけで、1リクエストあたりの入力が約 4,200 トークンから 1,900 トークンまで落ちました。出力や精度には影響がなく、純粋に削れた分です。
暴れる前に数字で掴む — 月額シミュレーション
抽象的に「気をつけましょう」では止まりません。私は新しいエージェントを組むとき、必ず1枚の試算表を作ります。Antigravity の新しいクレジット課金は概ね $25 で 2,500 クレジットという体系で、1クレジットがおよそ1回の標準的なエージェント往復に相当する感覚です。これを基準に、私が実際に運用している3つのワークロードを並べると次のようになります。
ワークロード 1日の実行回数 1回あたり消費 月間クレジット 概算月額
記事の構成チェック（軽量） 20回 0.4 約240 約 $2.4 コードレビュー支援（中量） 15回 1.2 約540 約 $5.4 バックグラウンド常駐（重量） 常時 変動大 約1,800 約 $18.0
ここで怖いのは、いちばん下の「バックグラウンド常駐」です。実行回数が固定されていないため、設計が甘いと月間クレジットが2倍にも3倍にも跳ねます。私が深夜に3倍のトークンを溶かしたのは、まさにこの常駐型でした。固定回数のワークロードは予算が読めますが、常駐型は必ずガードレールとセットで設計するのが鉄則です。
この表を作る価値は、金額そのものより「どのワークロードが読めないか」を可視化できる点にあります。読めないものにだけ防御を厚くすれば、労力が分散しません。
走り出す前に置く「コストガードレール」
予算を月額で決めても、エージェントは時間単位で動きます。月末に超過に気付いても遅いので、私は次の3層でガードレールを置いています。
1層目は、1リクエストあたりの上限トークンです。たとえば「1回の出力は最大2,000トークン」と決め、超えそうなら途中で打ち切る設定にします。長文を生成しに行くタイプのタスクほど、この上限を切らないと暴れます。
2層目は、1日の累計トークンです。エージェントを連続実行する設計の場合、日次で「ここまで使ったら自動停止」にしておきます。ガードレールに引っかかった日はメールで自分に通知され、翌朝に「これは正常な使用量か、それとも何か壊れているか」を判断します。
3層目は、月次の累計コスト上限です。これはサービス側のダッシュボードで設定する種類の制限ですが、必ず設定しておきます。万が一、自前のロジックがすり抜けても、最後にここが効きます。
3層あると、どこかで必ず「異常」を検出できます。1層しかないと、その1層が壊れた瞬間に止まれません。多重防御は手間に見えて、結果的には毎月の安心料として安いです。
2層目を実際に止めるコード
言葉だけだと運用に落ちないので、私が実際に使っている2層目（1日累計の自動停止）の核を共有します。エージェントの実行をラップして、その日の累計トークンが上限を超えたら例外で止める、という最小構成です。
import json import datetime from pathlib import Path
LEDGER = Path.home() / ".agent_token_ledger.json" DAILY_LIMIT = 120_000 # 1日の累計トークン上限（自分の予算から逆算して決める）
def _load (): if LEDGER .exists(): return json.loads( LEDGER .read_text()) return {}
def guard_and_record (used_tokens: int ) -> None : """その日の累計に加算し、上限を超えていたら停止する。""" today = datetime.date.today().isoformat() ledger = _load() spent = ledger.get(today, 0 )
if spent + used_tokens > DAILY_LIMIT : raise RuntimeError ( f "daily token guardrail hit: { spent + used_tokens :, } > { DAILY_LIMIT :, } . " f "今日はここで停止します。" )
ledger[today] = spent + used_tokens # 30日より古い記録は捨てて肥大化を防ぐ cutoff = (datetime.date.today() - datetime.timedelta( days = 30 )).isoformat() ledger = {d: v for d, v in ledger.items() if d >= cutoff} LEDGER .write_text(json.dumps(ledger, ensure_ascii = False , indent = 2 ))
# エージェント実行のたびに、消費トークンを渡して呼ぶ # guard_and_record(response.usage.total_tokens) ポイントは、上限に達したら RuntimeError で「止める」ことです。ログに警告を出すだけだと、結局走り続けて請求が跳ねます。止めてしまえば、翌朝の自分が落ち着いて原因を見られます。私はこの RuntimeError を catch して自分宛にメール通知する層をさらにかぶせていますが、まずは止まることが第一です。なぜここまでするかというと、止まらない仕組みは「夜のあいだに壊れる」のが個人開発の常だからです。見ていない時間に守ってくれる仕組みだけが、本当のガードレールだと私は考えています。
コストが膨らむ典型的な3パターン
私の手元で実際に「気付いたら膨らんでいた」原因を分類すると、大体次の3パターンに集約されます。
1つ目は、ループ系の暴走です。エージェントが「目的を達成するまで続ける」設計になっていると、達成判定が曖昧なときに永遠に回り続けます。これは終了条件を厳格に定義することで止まります。「N ステップ経過したら強制終了」「同じツールを連続3回呼んだら強制終了」など、機械的に止める条件を入れておきます。
2つ目は、ふくらむコンテキストです。会話履歴を全部詰め込み続ける実装にしていると、ターンが進むほど入力トークンが膨らみます。私は「直近の N ターンだけを残す」「N ターン超えたら要約に置き換える」という運用にして、入力サイズを一定範囲に抑えています。実測では、10ターン目あたりから入力トークンが初回の3倍を超えてくるので、ここが要約への切り替えどころです。
3つ目は、リトライの連鎖です。失敗したらリトライ、リトライも失敗したらまた最初から、という設計にすると、1つの失敗が10回分のコストに化けます。リトライは指数バックオフ、回数上限、そして「特定のエラーはリトライしない」という分類が必須です。
これら3つは、いずれも設計でほぼ防げます。ガードレールが壊れたときの保険であり、根本的にはここを丁寧に設計することが先です。
トークン課金プランの選び方
Antigravity 周辺のサービスは、概ね「従量課金」「定額無制限」「定額+超過従量」の3形態が並んでいます。個人開発者にとってどれが正解かは、月の使用量と「読めなさ」の許容度で決まります。
使用量が安定している場合、定額無制限が最安になりやすいです。ただし、無制限プランには「フェアユース」のような暗黙の上限があることが多く、本気で使い倒すと制限がかかる場合があります。
使用量がブレる場合、私は「定額+超過従量」を選んでいます。基本料金で読みやすさを担保しつつ、月によって使い込む分は従量で吸収する形です。完全な従量課金にすると、暴れた月の請求が跳ねるので避けます。
学習目的の段階では、まず従量課金で実態を把握するのが順番として正しいです。1ヶ月、2ヶ月分のデータが手元に出てから、定額系に移行するか判断します。最初から定額にすると、自分の本当の使用量が分からないまま支払いだけ発生します。私自身、最初の2ヶ月は従量で「自分が本当はどれだけ使うのか」を測り、3ヶ月目から定額+超過に切り替えました。この順番を守ったおかげで、定額プランを過大にも過小にも選ばずに済みました。
月次レビューで見るべき観察項目
私は月初に、前月のエージェント運用を次の5項目で振り返っています。
トータルコストの前月比
リクエスト数の前月比
1リクエストあたりの平均コスト
エラー率
ガードレールにかかった日数
これらを毎月同じ並びで眺めるだけでも、異常の兆候は驚くほど早く見えてきます。私は数字の前月比に色を付けて、増えた項目だけを赤くする運用を推奨します。
特に重要なのが「1リクエストあたりの平均コスト」です。リクエスト数が増えてコストが上がっているなら、それは仕事が増えただけで健全です。しかし、1リクエストあたりのコストが増えているなら、プロンプトが太ったか、出力が冗長になっているか、ツール呼び出しが増えています。これは設計を見直すサインです。
ガードレールにかかった日数も見ます。月の半分以上で1日上限に到達しているなら、エージェントの動作頻度が想定より高いか、上限値が低すぎるかのどちらかです。前者なら設計の見直し、後者なら上限を上げるかは判断ポイントになります。私の場合、月に2〜3日だけガードレールに当たるくらいが「上限が適正」の目安になっています。一度も当たらない月は、上限が緩すぎて保険になっていない可能性を疑います。
「コストを下げる」より「コストを読めるようにする」
最後に、思想の話を少しだけ。
コスト管理というと、つい「いかに安くするか」に注目しがちです。しかし個人開発者として大事なのは、まず「いかに読めるようにするか」だと私は考えています。読めない支払いは怖いので、無意識に使用量を減らすブレーキがかかります。これは結果的に、エージェントの活用度を下げてしまいます。
逆に、コストの構造が見えていれば、「ここに月3,000円使うことで、自分の作業時間が10時間浮く」という比較ができます。10時間の自分の時間が3,000円より価値があるなら、堂々と使い続ければ良いのです。
ガードレール、月次レビュー、トークンの内訳分解。地味な仕組みばかりですが、これを揃えてから、私はエージェントを「攻めの道具」として使えるようになりました。怖くて小さく使うのではなく、構造が見えているから大きく任せられる。この転換こそが、コストを読めるようにする本当の目的です。
締めくくり — 今日できる最小の一歩
ガードレールも月次レビューもまだ整っていない方は、まず1つだけ試してください。今走らせているエージェントの「1日累計トークン上限」を決めて、超えたら停止するように設定します。上で共有した数十行のコードで十分です。これだけで、想定外の請求の95%は止まります。
その上で、月初に1度だけ、前月の総コストとリクエスト数をメモする習慣を始めてみてください。最初の3ヶ月は数字を眺めるだけで構いません。3ヶ月分の数字が並んだとき、自分のエージェント運用の輪郭が初めて掴めます。同じように見えない請求に手を止めた経験のある方の、最初の一歩の助けになれば幸いです。