AI Ultra 100ドル枠は個人開発に見合うか — 上限の壁と並列度で損益分岐を測る

Antigravity で並列エージェントを回し始めてから、ある夕方、実装の途中で利用上限に当たって手が止まりました。React の画面、API の構成、視覚回帰テストを同時に走らせていると、上限の消費は思ったより速いのです。そのとき頭をよぎったのが、月100ドルの AI Ultra 枠に上げるべきか、という問いでした。Pro の5倍の上限が使えるプランです。最上位の AI Ultra は月200ドルで Pro の20倍の枠になります（倍率と価格は、Google が公開している I/O 2026 の AI サブスクリプション更新 の記載に基づきます）。個人開発でまず現実的に迷うのは、この100ドルの一段だと思います。

ただ「5倍だからお得」という言葉だけで決めるのは危ういです。5倍の枠が価値になるのは、あなたが実際に上限へ当たっていて、そこで待たされている時間に意味がある場合に限られます。ここでは、その損益分岐を感覚ではなく数字で見るための考え方を書きます。

「上限に当たっている」ことを、まず観測する

上位プランを検討する前に確かめるべきは、そもそも自分が上限に当たっているかどうかです。当たっていないなら、5倍の枠は使われないまま毎月100ドルが流れていくだけになります。私が最初にやったのは、一週間、上限に当たった回数と、そのたびに待った時間をメモに取ることでした。

観測すると、思い込みと実態がずれていることがよくあります。「よく上限に当たる」と感じていても、実際に手が止まったのは週に二回だけ、というように。逆に、当たった回数は少なくても、当たるのが決まって締め切り直前で、その1時間の停止が重い、ということもあります。回数だけでなく、当たった場面の重さも一緒に見ます。

私自身、この観測をやるまでは体感で「毎日のように当たっている」と思い込んでいました。ところが実際に記録してみると、手が止まった日は週のうち二日だけで、しかもそのうち一度はテストの回し方を見直せば避けられたものでした。個人開発は固定費の判断を誰かに相談しづらく、勢いで上位プランに上げてそのまま使わない、という失敗をしがちです。だからこそ、上げる前の一週間の観測が効きます。App Store と Google Play の両方でアプリを運用していると、月100ドルは決して小さくない額で、その一段を上げるかどうかは、勘ではなく手元の記録で決めたいところです。

損益分岐を、待ち時間の価値で式にする

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}")   # ≒ $155
print(verdict(v))                          # 上げてよい（余裕を持って回収）

recovered_ratio を 0.8 に置いたのは、上位プランに上げても待ちが完全にゼロにはならないからです。5倍の枠でも、極端に重いバッチを深夜にまとめて回せば当たることはあります。全部が消える前提で計算すると、判定が甘くなります。数字を自分の観測値に差し替えれば、上げるべきか据え置くべきかが一行で出ます。

何回当たったら分岐になるかを逆算する

月次価値を出すだけでなく、「週に何回当たれば100ドルに届くか」を逆算しておくと、観測の一週間が終わった時点で結論が出ます。上のスクリプトの式を plan_cost_usd について解き直しただけの関数です。

def breakeven_blocks_per_week(wait_minutes, hourly_value_usd,
                              plan_cost_usd=100.0, recovered_ratio=0.8):
    value_per_block = wait_minutes / 60.0 * 4.3 * recovered_ratio * hourly_value_usd
    return plan_cost_usd / value_per_block
 
print(round(breakeven_blocks_per_week(45, 30), 2))   # 1.29

この関数を手元で走らせて並べた結果が、次の表です（recovered_ratio は 0.8、月の週数は 4.3 のまま）。

読み取れるのは、分岐を決めるのが「回数」だけではない、ということです。1回の停止が1時間に及ぶなら、週に1回で100ドルに届きます。反対に待ち時間が短く時間単価も低いなら、週2回当たっても据え置きが妥当になります。私が最初に思い込んでいた「毎日のように当たる」は、この表のどの行にも当てはまらないほど過大な見積もりでした。

上げる前に、上限対策で回収できる分を先に取る

損益分岐が境界線に近いなら、プランを上げる前にやれることがあります。並列度を上げすぎて消費が速くなっているだけなら、同時実行の本数を要所に絞るだけで、上限到達の頻度は下がります。私の場合、視覚回帰テストのような重い工程を常時並列で回していたのをやめ、必要な局面だけ並列にしたところ、当たる回数がはっきり減りました。

こうした対策で回収しきれず、それでも待ち時間の価値が100ドルを超えるなら、そのときは上げる判断に自信を持てます。対策を尽くしたうえでの不足は、プランで埋めるのが素直です。

誰に100ドル枠が向くか

観測してみると、100ドル枠がはっきり見合うのは、並列エージェントを日常的に使い、上限に週数回は当たり、しかもその停止が収益や締め切りに直結する人です。逆に、上限にほとんど当たらない、あるいは当たっても待てる状況なら、Proのまま上限対策を詰めるほうが手元に残るお金は多くなります。

次の一歩としては、いきなりプランを上げるのではなく、まず一週間だけ上限到達の回数と待ち時間を記録し、上のスクリプトに自分の数字を入れてみることをお勧めします。App Store に出すアプリの開発を一人で回していると、毎月の固定費は積み重なるほど効いてきます。だからこそ、100ドルの判断は感覚ではなく、自分の観測値で下すのがよいと思います。

上げるかどうかは、料金表ではなく、自分の一週間の記録が決めます。 最初に私が頼りにしていたのは体感でしたが、いま思えば、あの夕方に手が止まった悔しさが判断を曇らせていたのかもしれません。

判断の助けになれば幸いです。お読みいただきありがとうございました。