年末に向けて帳簿を整理していた夜、サブスクの明細が思いのほか長くなっていることに気づきました。エディタ、AI コーディング環境、API の従量課金——どれも「使っているつもり」で、どれがどれだけ元を取れているのか、私は一度も数えたことがなかったのです。
この記事は、その棚卸しの記録です。Antigravity・Cursor・Bolt を機能で比べるのではなく、「月額を何時間の節約で回収できるか」という一点で見ます。
最初にお伝えしておくと、ここに書く効率の差は計測値ではなく、私の手触りです。料金も改定が続くため、金額は書かずに「自分の数字で出す方法」を残します。
料金は「額面」ではなく「膨らみ方」で見る
3つの製品を並べたとき、月額の高い・安いよりも先に確認したいのは、使い込んだときにコストがどう動くかです。
- 固定費に近いもの: 使っても請求がほぼ動かず、予算が読めます。
- 従量が混ざるもの: 月によって請求が変わり、ヘビーに使った月に跳ねます。
- 回数や容量で上位プランへ誘導されるもの: 気づくと一段上のプランにいます。
どの製品がどの型に当てはまるかは、プランの改定で入れ替わります。ですので、ここでは公式の料金ページを開いて、上の3分類のどれかを自分で判定してください。判定に5分とかかりません。
私は過去に、従量の上限を設定しないまま Agent を長時間回してしまい、翌月の請求を見て手が止まったことがありました。それ以来、従量が混ざる環境には必ず上限アラートを先に置くことを線引きにしています。
用途で分けると、見るべき指標が変わる
同じ道具でも、使う場面によって「回収」の意味が違います。私は次の3つに分けて考えています。
受託の制作案件では、納期までの時間が収益に直結します。複数ファイルにまたがる変更を計画から実行まで任せられる環境は、既存のコードベースを引き継いだ案件で効きました。一方、日々の実装・テスト追加・小さな修正では、エディタの反応のよさと補完の安定感がじわじわ効きます。
自社アプリの保守では、コードベース全体を把握したうえで整合性を保てるかが大事です。壁紙アプリのような長く運用しているプロダクトは、新機能よりも既存の挙動を壊さないことのほうが価値を持ちます。
試作・提案用のデモでは、速さがすべてです。ブラウザで完結する生成環境は、打ち合わせの前日に「動くもの」を用意するのに向いていました。ただし、試作を本番へ育てる段階では、別の環境へ移す手間が出ます。
ここで気づいたのは、「どれが一番優れているか」という問いそのものが、的を外していたということです。道具の優劣ではなく、その月の作業の比重で主軸を選ぶ——これが私の線引きです。
自分の数字で損益分岐を出す
では、月額を回収できているかをどう確かめるか。私は次の短いスクリプトに、自分の数字を入れています。
何を解決するかというと、「このツールは月に何時間節約できれば元が取れるのか」を、感覚ではなく数字にすることです。
# breakeven.py — ツール月額が何時間の節約で回収できるかを計算する
# 数字はすべて自分の実績で置き換えてください（下の値は例です）
def breakeven_hours(monthly_cost: float, hourly_rate: float) -> float:
"""月額を回収するのに必要な節約時間（時間/月）"""
return monthly_cost / hourly_rate
def monthly_net(saved_hours: float, hourly_rate: float, monthly_cost: float) -> float:
"""節約した時間の価値からツール費を引いた、月あたりの純益"""
return saved_hours * hourly_rate - monthly_cost
if __name__ == "__main__":
hourly_rate = 4000 # 自分の実効時給（円）。受託の単価ではなく、実際に稼いだ総額 ÷ 総稼働時間
tools = {
"ツールA": {"cost": 6000, "saved_hours": 10}, # 月額（円）と、実測した節約時間
"ツールB": {"cost": 3000, "saved_hours": 4},
"ツールC": {"cost": 3000, "saved_hours": 0.5},
}
for name, t in tools.items():
be = breakeven_hours(t["cost"], hourly_rate)
net = monthly_net(t["saved_hours"], hourly_rate, t["cost"])
verdict = "回収できている" if net > 0 else "見直し候補"
print(f"{name}: 損益分岐 {be:.1f} 時間/月 / 実測 {t['saved_hours']} 時間 / 純益 {net:,.0f} 円 → {verdict}")なぜこう書くかというと、saved_hours に入れる数字を「実測」に限定するためです。感覚で入れると、どのツールも必ず黒字になります。タイマーでもコミット履歴でもかまいませんので、同じ種類の作業を以前どれだけかかったかと比べて、数字を出してみてください。
実効時給は、受託の見積単価ではなく「稼いだ総額 ÷ 総稼働時間」で置きます。見積の時給で計算すると、営業や打ち合わせの時間が抜け落ちて、回収の見立てが甘くなります。
私が試したとき、いちばん意外だったのは、使用頻度の低い月額が、節約時間の実測値を入れた途端に「見直し候補」へ落ちたことでした。ほとんど起動していなかった環境があったのです。
組み合わせで使うときの目安
複数を併用する場合、私は役割を次のように決めています。この配分は私の働き方に合わせたもので、あくまで叩き台です。
主軸 : 毎日触る環境（日常のコーディング・テスト・小修正）
大きな変更用 : 月に数回、複数ファイルにまたがる変更や設計見直しのときだけ使う
試作・提案用 : クライアント打ち合わせ前や、新しいアイデアの仮説検証のときだけ使う併用の場合は、稼働日数の少ない環境ほど、年額プランより月額プランのほうが身軽です。使わない月に解約や縮小ができるからです。反対に、毎日触る主軸は、年額に切り替えられるなら切り替えたほうが割安になることが多いです（割引率は公式でご確認ください）。
乗り換えの隠れたコスト
見落としがちなのが、乗り換えにかかる手間です。
- キーバインドや操作感の再習得（慣れるまで生産性が落ちます）
- lint・デバッグ・フックなど、プロジェクトごとの設定の再構築
- 自分用に磨いたプロンプトやルールファイルの移し替え
特に3つ目は、積み重ねた分だけ重くなります。私は、乗り換えを考えたら、まず新規の小さな案件で1か月だけ試すようにしています。既存の主軸は、新しい環境の成績が出るまで手放しません。 これも線引きの一つです。
1つだけ選ぶなら
「併用する余裕はない」という方向けの、私なりの判断の順番です。
- 今月の作業の半分以上を占めるのは何ですか（日常の実装／大規模な変更／試作）。
- その作業で、上のスクリプトに入れた「節約時間」が最も大きく出たのはどの環境でしたか。
- その環境の請求は、上限を置けますか。
3つ目に「いいえ」が付くなら、その環境は主軸にしないほうが安全です。
チームで使う予定がある場合は、ライセンスや共有機能の条件が個人利用とは別に決まります。人数が増える前に、公式のチームプランの条件を確認しておくと、後からの移行を避けられます。
今週やること
この記事を閉じたら、まず契約中のツールの月額と、直近1か月の実際の使用日数を書き出してみてください。次に、上のスクリプトに自分の数字を入れて、「見直し候補」が出るかどうかを確かめます。
比較記事を読み比べるよりも、自分の明細を一度数えてみるほうが、はるかに確かな答えが出る——私はそう感じています。
関連して、Antigravity vs Cursor vs Bolt の本番判断 もあわせてご覧ください。