Antigravity で並列エージェントを回し始めてから、ある夕方、実装の途中で利用上限に当たって手が止まりました。React の画面、API の構成、視覚回帰テストを同時に走らせていると、上限の消費は思ったより速い。そのとき頭をよぎったのが、月100ドルの AI Ultra 枠に上げるべきか、という問いでした。Pro の5倍の上限が使えるプランです。最上位の AI Ultra は月200ドルで Pro の20倍の枠になりますが、個人開発でまず現実的に迷うのは、この100ドルの一段だと思います。
ただ「5倍だからお得」という言葉だけで決めるのは危ういです。5倍の枠が価値になるのは、あなたが実際に上限へ当たっていて、そこで待たされている時間に意味がある場合に限られます。ここでは、その損益分岐を感覚ではなく数字で見るための考え方を書きます。
「上限に当たっている」ことを、まず観測する
上位プランを検討する前に確かめるべきは、そもそも自分が上限に当たっているかどうかです。当たっていないなら、5倍の枠は使われないまま毎月100ドルが流れていくだけになります。私が最初にやったのは、一週間、上限に当たった回数と、そのたびに待った時間をメモに取ることでした。
観測すると、思い込みと実態がずれていることがよくあります。「よく上限に当たる」と感じていても、実際に手が止まったのは週に二回だけ、というように。逆に、当たった回数は少なくても、当たるのが決まって締め切り直前で、その1時間の停止が重い、ということもあります。回数だけでなく、当たった場面の重さも一緒に見ます。
私自身、この観測をやるまでは体感で「毎日のように当たっている」と思い込んでいました。ところが実際に記録してみると、手が止まった日は週のうち二日だけで、しかもそのうち一度はテストの回し方を見直せば避けられたものでした。個人開発は固定費の判断を誰かに相談しづらく、勢いで上位プランに上げてそのまま使わない、という失敗をしがちです。だからこそ、上げる前の一週間の観測が効きます。App Store と Google Play の両方でアプリを運用していると、月100ドルは決して小さくない額で、その一段を上げるかどうかは、勘ではなく手元の記録で決めたいところです。
| 観測する項目 | 取り方 | 判断への効き方 |
|---|---|---|
| 上限到達の回数/週 | 手が止まった回数を記録 | 頻度が低ければ上げる価値は薄い |
| 1回あたりの待ち時間 | 再開できるまでの実時間 | 待ち時間×頻度が損失の総量 |
| 当たる場面 | 締め切り前か平常時か | 締め切り前の停止は重みが大きい |
| 並列で回した本数 | 同時実行したエージェント数 | 並列度が高いほど消費が速い |
損益分岐を、待ち時間の価値で式にする
100ドルの枠が見合うかは、突き詰めると「上限で待たされて失った時間の価値が、100ドルを超えるか」に還元できます。ここで自分の時間の単価を一度だけ決めておくと、以降の判断がぶれません。個人開発だと時間単価を決めにくいものですが、外注に出すならいくら払うか、あるいは同じ時間で稼げる別の作業がいくらか、という置き換えで概算できます。
次の小さなスクリプトは、一週間の観測値から、上位プランに上げることで取り戻せる月次の価値を見積もり、100ドルの損益分岐を判定します。
# breakeven.py — AI Ultra 100ドル枠の損益分岐を、待ち時間の価値から試算する
def monthly_value_recovered(
blocks_per_week: float, # 週あたり上限に当たった回数
wait_minutes: float, # 1回あたり待った分数
hourly_value_usd: float, # 自分の時間の単価（外注置換などで概算）
recovered_ratio: float = 0.8, # 上位プランで避けられる割合（全部は消えない）
) -> float:
weekly_lost_hours = blocks_per_week * wait_minutes / 60.0
monthly_lost_hours = weekly_lost_hours * 4.3 # 月の週数
recovered_hours = monthly_lost_hours * recovered_ratio
return recovered_hours * hourly_value_usd
def verdict(value_usd: float, plan_cost_usd: float = 100.0) -> str:
if value_usd >= plan_cost_usd * 1.3:
return "上げてよい（余裕を持って回収）"
if value_usd >= plan_cost_usd:
return "境界線（他の要素で判断）"
return "据え置き（上限対策を先に）"
# 例）週2回・1回45分・時間単価30ドルの個人開発者
v = monthly_value_recovered(blocks_per_week=2, wait_minutes=45, hourly_value_usd=30)
print(f"取り戻せる月次価値: ${v:.0f}") # ≒ $124
print(verdict(v)) # 上げてよい（余裕を持って回収）recovered_ratio を 0.8 に置いたのは、上位プランに上げても待ちが完全にゼロにはならないからです。5倍の枠でも、極端に重いバッチを深夜にまとめて回せば当たることはあります。全部が消える前提で計算すると、判定が甘くなります。数字を自分の観測値に差し替えれば、上げるべきか据え置くべきかが一行で出ます。
上げる前に、上限対策で回収できる分を先に取る
損益分岐が境界線に近いなら、プランを上げる前にやれることがあります。並列度を上げすぎて消費が速くなっているだけなら、同時実行の本数を要所に絞るだけで、上限到達の頻度は下がります。私の場合、視覚回帰テストのような重い工程を常時並列で回していたのをやめ、必要な局面だけ並列にしたところ、当たる回数がはっきり減りました。
| 症状 | 先に試すこと | 効果の見込み |
|---|---|---|
| 常に並列で重い工程を回している | 並列は要所だけに絞る | 消費速度が下がり到達頻度が減る |
| 締め切り前に集中して当たる | 重いバッチを前倒しで分散 | 停止のタイミングをずらせる |
| 失敗タスクの再実行が多い | 検証を挟んで無駄な再実行を減らす | 枠の空回りを防ぐ |
こうした対策で回収しきれず、それでも待ち時間の価値が100ドルを超えるなら、そのときは上げる判断に自信を持てます。対策を尽くしたうえでの不足は、プランで埋めるのが素直です。
誰に100ドル枠が向くか
観測してみると、100ドル枠がはっきり見合うのは、並列エージェントを日常的に使い、上限に週数回は当たり、しかもその停止が収益や締め切りに直結する人です。逆に、上限にほとんど当たらない、あるいは当たっても待てる状況なら、Proのまま上限対策を詰めるほうが手元に残るお金は多くなります。
次の一歩としては、いきなりプランを上げるのではなく、まず一週間だけ上限到達の回数と待ち時間を記録し、上のスクリプトに自分の数字を入れてみることをお勧めします。App Store に出すアプリの開発を一人で回していると、毎月の固定費は積み重なるほど効いてきます。だからこそ、100ドルの判断は感覚ではなく、自分の観測値で下すのがよいと思います。
判断の助けになれば幸いです。お読みいただきありがとうございました。