なぜ「どの AI IDE を選ぶか」が収益に直結するのか
「最近の AI 開発 IDE で、結局どれが一番いいですか？」という質問を、月に何件も受けるようになりました。私の答えはいつも同じです。「あなたが何で稼ぐかによって、答えが変わります」。
3つの主要選択肢——Google Antigravity、Cursor、Bolt——は、表面的にはどれも「AI でコードを書ける IDE」です。しかし設計思想が根本的に違うため、得意な案件タイプ・適切な月額コスト・収益化の経路が大きく異なります。間違った IDE を選ぶと、月数万円の無駄なサブスクリプションを払いながら、得意な案件を逃すという二重損失になります。
3つの IDE の本質的な違い
まず、3つの設計思想を整理します。これが理解できると、その後の選択がほぼ自動的に決まります。
Google Antigravity — エージェント中心の自律開発
Antigravity の核は「エージェントが自律的にタスクを完了する」モデルです。あなたが「このリポジトリに認証機能を追加して」と指示すると、エージェントが計画を立て、必要なファイルを編集し、テストを実行し、コミットまでを自律的に進めます。あなたはレビューと承認をする立場になります。
これは「ペアプログラミング」ではなく「マネージャーとジュニア開発者」の関係に近いです。1人で複数のエージェントを並列に走らせて、複数案件・複数モジュールを同時に進められるのが最大の特徴です。
Cursor — 人間とAIの密なペアプログラミング
Cursor の核は「人間が常にエディタの主導権を持ち、AI が瞬時にサポートする」モデルです。Tab補完、Composer、Chat、すべてが「人間の思考速度を加速する」ための機能設計になっています。
Antigravity と違い、エージェントが自律的に進むより、人間が1行ずつ確認しながら進める形に最適化されています。コーディングそのものに集中したい開発者、コードのコントロール権を細かく持ちたい開発者に向いています。
Bolt — ブラウザ完結の即時プロトタイプ
Bolt の核は「ブラウザだけで、ゼロからフル動作する Web アプリを瞬時に作る」モデルです。ローカル環境構築不要、デプロイも自動。プロトタイプから MVP までを最速で届けることに特化しています。
Antigravity・Cursor が「既存コードベースの開発」を主戦場にしているのに対し、Bolt は「新規プロジェクトのゼロイチ立ち上げ」が主戦場です。
月額コスト × 時間単価リターン比較
各 IDE の月額コストを、生産性向上による「時間単価リターン」で評価します。
■ Google Antigravity 月額コスト: $20〜$200（プランによる） 得意領域: 既存コードベースの大規模変更、並行案件管理 時間単価リターン: 高（複数並行で稼働できれば3〜5倍） 損益分岐点: 月20時間以上の開発稼働
■ Cursor 月額コスト: $20〜$40（プランによる） 得意領域: 1人で深く掘る開発、コードの精密な制御 時間単価リターン: 中〜高（人間の生産性が1.5〜3倍） 損益分岐点: 月10時間以上の開発稼働
■ Bolt 月額コスト: $20〜$50（プランによる） 得意領域: プロトタイプ・MVP・ランディングページ作成 時間単価リターン: 高（ゼロイチ立ち上げで5〜10倍） 損益分岐点: 月3〜5プロトタイプ以上の作成 時間単価リターンは「あなたが副業・本業で時間あたり何円稼げるか」によって変わります。時間単価1万円の方が Antigravity で生産性3倍になったとすると、月20時間の稼働が生む売上は 20時間 × 1万円 × 3倍 で月60万円相当です。月額200ドル（約3万円）は、そのうちの5%に収まります。
逆に、時間単価2,000円のジュニア開発者にとって、月額200ドルは実労働の100時間相当。Cursor のスタータープラン $20 から始めるのが現実的です。
その倍率を、自分の数字に置き換える
ここまでの「3〜5倍」「1.5〜3倍」という数字は、私の手元の案件から出したものです。あなたの案件構成では、まず一致しません。ですのでこの節では、倍率を借りるのではなく、自分で測る手順を置いておきます。
測る値は1つだけです。IDE ごとの実効時間単価 。
計測の肝は、実時間に「レビューと差し戻し」を必ず含めることにあります。エージェントに任せた作業は、生成が終わった時点では終わっていません。読んで、直して、もう一度走らせる時間まで含めて、初めて実時間になります。私の台帳では、Antigravity で進めた案件の実時間のうち、およそ4割がこのレビューと差し戻しでした。生成が速くなるほど、レビューが律速になります。ここを実時間から外すと、倍率だけが立派になって手取りが増えない、という結果になります。
記録は案件が終わるたびに1行足すだけで足ります。私が使っている最小構成のスクリプトです。
#!/usr/bin/env python3 """ide_ledger.py — IDE ごとの実効時間単価を記録して集計する最小台帳。""" import json import sys from collections import defaultdict from pathlib import Path
LEDGER = Path.home() / ".ide_ledger.jsonl"
def log (ide, hours, revenue, kind): """1案件を追記する。hours にはレビュー・差し戻しの時間も含める。""" rec = { "ide" : ide, "hours" : hours, "revenue" : revenue, "kind" : kind} with LEDGER .open( "a" , encoding = "utf-8" ) as f: f.write(json.dumps(rec, ensure_ascii = False ) + " \n " )
def report (): if not LEDGER .exists(): print ( "記録がありません" ) return agg = defaultdict( lambda : { "hours" : 0.0 , "revenue" : 0 , "n" : 0 }) for line in LEDGER .read_text( encoding = "utf-8" ).splitlines(): if not line.strip(): continue r = json.loads(line) a = agg[(r[ "ide" ], r[ "kind" ])] a[ "hours" ] += r[ "hours" ] a[ "revenue" ] += r[ "revenue" ] a[ "n" ] += 1
rows = [] for (ide, kind), a in agg.items(): rate = a[ "revenue" ] / a[ "hours" ] if a[ "hours" ] else 0.0 rows.append((rate, ide, kind, a))
for rate, ide, kind, a in sorted (rows, reverse = True ): print ( f " { ide :<12 } { kind :<14 } { a[ 'n' ] :>2 } 件 " f " { a[ 'hours' ] :>6.1f } h 実効 { rate :>8,.0f } 円/h" )
if __name__ == "__main__" : if len (sys.argv) >= 5 and sys.argv[ 1 ] == "log" : kind = sys.argv[ 5 ] if len (sys.argv) > 5 else "misc" log(sys.argv[ 2 ], float (sys.argv[ 3 ]), int (sys.argv[ 4 ]), kind) else : report() 使い方は「終わったら1行」だけです。
$ python3 ide_ledger.py log antigravity 18.5 350000 refactor $ python3 ide_ledger.py log cursor 9.0 120000 ui-polish $ python3 ide_ledger.py log bolt 4.5 80000 prototype
$ python3 ide_ledger.py report bolt prototype 3件 12.0h 実効 17,778 円/h antigravity refactor 4件 61.5h 実効 16,260 円/h cursor ui-polish 6件 38.0h 実効 9,474 円/h 2週間ぶんたまると、「どの IDE が速いか」ではなく「どの種別の仕事をどの IDE に載せると単価が上がるか」が見えてきます。個人開発者にとって意味があるのは後者のほうです。私の場合、リファクタリング案件は Antigravity、App Store 向けアプリの細かな UI 調整は Cursor という分岐が、感覚ではなく数字で確定しました。逆に、短いバグ修正を Antigravity に載せると単価が落ちることも同時に見えました。段取りの時間が作業時間を上回るからです。
請求が発生しない自分のプロダクトの作業は、外注したらいくら払うかを仮の請求額として入れておくと、受託案件と同じ土俵で並びます。厳密な会計ではなく、判断のための物差しなので、これで十分です。
台帳が最初に返してくる順位は、たいてい案件構成の影です
ここで一度、私の失敗を書き残しておきます。
台帳を回しはじめて2週目、report の出力を眺めて「Bolt がいちばん稼いでいる」と受け取りました。並びのいちばん上にいたからです。その週の私は、受けるはずだった移行案件を後ろへずらし、プロトタイプの引き合いを先に入れました。月末に手取りを見て、増えていないことに気づきました。
順位の中身を数えて、理由が分かりました。Bolt には prototype しか載せておらず、Cursor には単価の低い ui-polish が6件ぶら下がっていたのです。並んでいたのは IDE の実力ではなく、私がどの IDE にどの種別を流したかという配分——つまり案件構成のほうでした。
手元の30件を IDE ごとに丸めると、こう出ます。
bolt 4件 15.0h 実効 17,333 円/h antigravity 10件 96.5h 実効 13,523 円/h cursor 16件 105.5h 実効 11,848 円/h この並びだけを見れば Cursor が最下位です。ところが同じデータを種別ごとに切り直すと、bugfix では Cursor が Antigravity を上回っていました。Cursor を最下位に見せていたのは、ui-polish 38時間ぶんの重みです。試しに ui-polish の行だけを外して集計し直すと、Cursor は 11,848 円/h から 13,185 円/h へ動きました。道具は一つも変えていません。動かしたのは、何をそこに載せたかの内訳だけです。
比べてよいのは、同じ種別を持っている IDE どうしだけです。 種別をまたいだ順位は、道具の性能ではなく仕事の配り方を映します。
そこで ide_ledger.py に、同じ種別を2つ以上の IDE で持っている行だけを並べる paired を足しました。件数の少ないセルには印を付けて、読まずに飛ばせるようにしてあります。
MIN_N = 3 # 1 セルがこの件数に満たないうちは順位を読まない
def paired (): """同じ kind を 2 つ以上の IDE で持っている行だけを、kind ごとに並べる。""" agg = load() by_kind = defaultdict( dict ) for (ide, kind), a in agg.items(): by_kind[kind][ide] = a
for kind in sorted (by_kind): cells = by_kind[kind] if len (cells) < 2 : print ( f "[ { kind } ] 比較不能（ { ', ' .join(cells) } のみ）" ) continue print ( f "[ { kind } ]" ) ranked = sorted ( cells.items(), key =lambda kv: kv[ 1 ][ "revenue" ] / kv[ 1 ][ "hours" ] if kv[ 1 ][ "hours" ] else 0.0 , reverse = True , ) for ide, a in ranked: rate = a[ "revenue" ] / a[ "hours" ] if a[ "hours" ] else 0.0 mark = "" if a[ "n" ] >= MIN_N else f " ← n= { a[ 'n' ] } ・まだ読まない" print ( f " { ide :<12 } { a[ 'n' ] :>2 } 件 { a[ 'hours' ] :>6.1f } h 実効 { rate :>8,.0f } 円/h { mark } " ) report() の集計部分を load() として切り出しておけば、そのまま使い回せます。同じ30件を paired に通すと、出力はこうなります。
$ python3 ide_ledger.py paired [bugfix] cursor 5件 12.5h 実効 12,000 円/h antigravity 3件 9.0h 実効 10,556 円/h [prototype] bolt 4件 15.0h 実効 17,333 円/h cursor 2件 11.0h 実効 10,909 円/h ← n=2・まだ読まない [refactor] antigravity 4件 61.5h 実効 16,260 円/h cursor 3件 44.0h 実効 14,091 円/h [ui-polish] cursor 6件 38.0h 実効 9,474 円/h antigravity 3件 26.0h 実効 8,077 円/h この形にしてから、読み方が変わりました。refactor は Antigravity、bugfix は Cursor と、比べてよい土俵の上でだけ差が出ています。prototype の Cursor 側は2件しかないので、印のとおり保留です。この保留を我慢できずに読んでしまったのが、最初の2週間でした。
件数の下限は MIN_N に置いています。私は3件にしていますが、案件ごとの規模のばらつきが大きい方は5件でもよいかもしれません。値そのものより、下限を先に決めておくことのほうが効きます。後から決めると、都合のよい数字が出たところで読みたくなりますので。
案件タイプ別の最適 IDE 選択
実際の案件タイプごとに、どの IDE が最も稼げるかを整理します。
既存コードベースのリファクタリング・機能追加
最適 : Google Antigravity
数万〜数十万行規模のコードベースに対して、整合性を保ちながら変更を入れる作業は、Antigravity のエージェント機能が明確に強いです。エージェントが影響範囲を分析し、複数ファイルを同時編集し、テストで検証してから提案してくれます。
私の体感では、人間単独 + Cursor が必要な期間に対して、Antigravity を本気で使えば3〜5分の1の時間で完了します。リファクタリング案件は工数見積もりが難しく価値ベース見積もりが効くため、生産性向上分をそのまま収益にできます。
新規 Web アプリ・SaaS の MVP 開発
最適 : Bolt（プロトタイプ） + Antigravity（本番化）
ゼロから作るアプリは、まず Bolt でブラウザ上で動くプロトタイプを最短2〜3時間で作ります。クライアントに見せて方向性を合意してから、Antigravity に乗せ替えて本番品質まで仕上げます。
この組み合わせが最も短時間で「動くもの」を提示できるため、提案段階での受注率が大きく上がります。「来週の打ち合わせまでに動くデモを持ってくる」を当然のように実現できると、競合との差別化になります。
1人で深く掘るプロダクト開発（個人 SaaS など）
最適 : Cursor
自分が長期で育てるプロダクトは、コードのすべてを自分が把握している状態が望ましいです。Cursor は人間の思考速度に合わせて補完してくれるため、コードベースへの理解が損なわれません。
Antigravity でエージェントに任せると速いですが、半年後に自分が読み返したときに「これ、なぜこうなってるんだっけ」状態になりやすいです。長期メンテを自分で続けるなら、Cursor の密な人間-AI協調のほうが結果的に生産性が高くなります。
大量プロトタイプの量産（コンサル・営業ツール用）
最適 : Bolt
「クライアント10社それぞれに個別カスタマイズしたデモを作る」「自社サイトのABテスト用に5パターンのランディングページを作る」のような、量産が必要な案件は Bolt が実用的です。
ローカル環境構築・デプロイ・URL払い出しまでを自動化できるため、1案件あたりの所要時間が他の IDE の3分の1以下になります。
バグ修正・障害対応
最適 : Cursor または Antigravity（コードベースの規模次第）
小〜中規模のコードベースなら Cursor が即時性で勝ちます。大規模コードベースで原因箇所が不明な場合は、Antigravity のエージェントに調査させるのが効率的です。Bolt はこの領域では弱いです。
個人開発者の最適構成
「結局1個に絞るべきか、複数併用すべきか？」という問いへの私の回答です。
シナリオA: 受託開発専業（月20件以上の案件管理）
推奨構成 : Antigravity（メイン） + Cursor（サブ）
Antigravity で並行案件を回し、コードレビュー・微修正は Cursor で行います。年間コストは合計 $400〜$600 程度。月収200万円ライン以上のフリーランスなら、コスト比で見て明確に黒字です。
シナリオB: 個人 SaaS 運営（自分のプロダクトを長期育成）
推奨構成 : Cursor（メイン） + Bolt（プロトタイプ用）
メインプロダクトは Cursor で深く理解しながら開発。新機能や別プロダクトの初期アイデア検証には Bolt を使います。年間コストは $350〜$500 程度。月額収益が $1,000 を超えれば即時黒字化します。
シナリオC: コンサル・教育・受発注の請負
推奨構成 : Bolt（メイン） + Antigravity（本番化案件）
クライアント向けデモ、提案書付属プロトタイプ、ワークショップ用サンプルアプリは Bolt で量産。本番開発に進んだ案件のみ Antigravity に乗せ替え。年間コストは $400〜$600 程度。1案件で十分回収可能。
シナリオD: 副業・趣味開発（月10時間以下の稼働）
推奨構成 : Cursor のスタータープランのみ
複数 IDE の月額を払うコスト感に見合いません。Cursor の $20 プランで十分高い生産性が得られます。Antigravity は無料枠で試して、本格活用のタイミングが来たら検討します。
Antigravity ならではの提案テンプレート
最後に、Antigravity を使った提案で使える「価値ベース見積もり」のテンプレートを共有します。
Antigravity の最大の強みは、「エージェントが自律的にタスクを完了する」ことです。これをクライアントに分かりやすく伝えるためには、「あなたは私の代わりに、AIエージェントを雇うのと同じ」というメンタルモデルを提示します。
■ 提案書の書き方例
【ご提案内容】 本案件では、Google Antigravity 環境を活用した 「マルチエージェント開発体制」をご提供します。
具体的には、私（廣川）が設計判断・品質保証・本番デプロイを統括し、 複数の AI エージェントが実装作業を並列で進める体制を構築します。
【期待される成果】 - 通常の単独開発に対して2〜3倍の納品速度 - マルチエージェントによる並行開発のため、 10〜15モジュールを同時に進行可能 - すべてのコードに対して、別エージェントによる 自動レビュー・テスト生成を必須化
【お見積り】 従来工数: 6人月相当 本体制での想定: 2〜3人月相当 ご請求額: ◯◯◯万円（従来見積もりの70〜80%） このテンプレートのポイントは、「単独開発より速い」ではなく「マルチエージェントで並行作業する体制」を売る ことです。クライアントから見ると、1人のフリーランスではなく「AIエージェントチームを率いるテックリード」を雇っている感覚になります。価格を抑える必要が減り、価値ベースで料金を取れます。
実案件で見えた「使い分けの分岐点」
抽象的な比較ではなく、私が実際に判断に迷った案件で何を基準に IDE を選んだかを、3つのケーススタディで共有します。
ケース1: 既存 Rails アプリの大規模リファクタリング
クライアント: 中堅 EC 事業者
案件規模: 約8万行の Rails 6 → Rails 7 移行 + コード整理
予算: 350万円・期間 3ヶ月
選んだ IDE: Antigravity
判断の決め手は「コードベース全体を読ませる必要がある」こと。Cursor では渡せる文脈量に限界があり、移行作業の途中で「他のファイルでも同じパターンが使われている」を見落とすおそれが大きいと判断しました。Antigravity のエージェントに「アップグレード手順を計画して」と指示し、計画書をレビューしてから実行に入る、という流れで進めました。
実工数は2.2ヶ月、価値ベース見積もりだったため売上はそのまま、時間単価は実質1.4倍に上がりました。
ケース2: スタートアップの新規 MVP
クライアント: シード期スタートアップ
案件規模: マッチング系 Web アプリ MVP（フロント＋バックエンド）
予算: 80万円・期間 4週間
選んだ IDE: Bolt → Antigravity
最初の1週間は Bolt でブラウザ完結のプロトタイプを作成。クライアントが画面を触りながら「ここはこう」「これは違う」と指示できる環境を作り、3往復で要件を固めました。
要件確定後、Antigravity に乗せ替えてから3週間で本番品質まで仕上げ。Cloudflare Workers 環境への デプロイ、Stripe 決済組み込み、認証実装を含めて期日内に完了。Bolt 単体では本番品質の認証・決済まで行くのは難しく、Antigravity 単体ではプロトタイプフェーズの往復が遅いため、組み合わせがベストでした。
ケース3: 自分の個人 SaaS 機能追加
私自身のドメイン: claudelab.net
案件規模: 検索機能の改善 + メンバーシップ機能拡張
選んだ IDE: Cursor
自分が長期で運営しているコードベースですので、すべての変更を自分の手で把握しておきたい案件でした。Antigravity に任せると速いですが、半年後に自分が触れなくなるリスクがあります。Cursor で1行ずつ確認しながら進めました。
これは「速度より、自分のメンタルモデルとコードの一致を優先する」案件。個人 SaaS のメイン開発は、ほぼすべて Cursor で進めています。
1年スパンでの選択戦略
最後に、1年スパンで考えたときの IDE 戦略について。
AI 開発 IDE 市場は、現在も急速に変化しています。3ヶ月前にベストだった選択が、今ではセカンドベストになっていることが頻繁にあります。新しいエージェント機能、新しいモデル統合、新しい価格プランが、月単位で発表されています。
そのため、「1つの IDE に過度にロックインしない」ことが、長期的にも重要です。具体的には:
第一に、コードは標準的な構造で書きます 。エディタ固有の機能やプロジェクト構造に依存すると、別エディタに移行できなくなります。.vscode/ .cursor/ .antigravity/ といった設定は、Git に含めず、各開発者が個別に設定する形が安全です。
第二に、プロンプトとシステムインストラクションは IDE から独立した形式で保管します 。Markdown ファイルでプロジェクトルートに置いておけば、どの IDE からも読み込めます。
第三に、新しい IDE が登場したら3ヶ月以内に1案件で試します 。最先端を追い続けるコストは、追い続けないコストより遥かに小さいです。私自身、新しい IDE が登場するたびに小さな案件で試して、自分の手に馴染むかを確認しています。
クライアントへの「どの IDE を使っているか」の伝え方
提案や見積もりの場面で、自分の使っている IDE を伝えるかどうか、伝え方は工夫が必要です。
クライアントによっては「AI で書いてるなら、自社内で出来そう」と感じる方もいます。その懸念を先回りで解消する伝え方を持っておくと、価格交渉が大きく楽になります。
私が使っている説明のテンプレート例:
「私の開発体制は、Google Antigravity・Cursor・Bolt を案件特性に応じて使い分ける形を取っています。これらのツールは確かに AI を活用しますが、ツールが優秀でもアウトプットの品質は『誰が、どの場面で、どう使うか』で決まります。私の付加価値は、案件ごとに最適な構成を選び、複数のエージェントを統率し、品質保証と本番運用設計を統括する部分にあります。納品物の最終責任は私が持ちます。」
この伝え方の良いところは、「AI を使っている事実」を隠さず、しかし「自分の付加価値」を明確に言語化していることです。クライアントが感じる「自社内でも出来そう」という不安に、正面から答える形になります。
また、ツール選定そのものを「コンサルティング項目」として提案書に入れることもあります。「貴社の開発体制に合わせて、どのツールでどう構築するかも含めてご提案します」とすると、ツール選定の専門性自体が課金対象になります。
3つの IDE をどう束ねるか
3つの IDE はそれぞれが、異なる稼ぎ方に最適化されています。Antigravity は「並行案件管理と大規模開発」、Cursor は「精密な単独開発」、Bolt は「ゼロイチ立ち上げと量産」。あなたが何で稼ぐかが決まれば、選択はほぼ自動的に決まります。
そして、3つすべてを「シナリオに応じて使い分ける」のが、おそらく最も生産性が高い体制です。月額コストの総和は $40〜$200 程度で済みますが、リターンは時間単価で2〜10倍になります。フリーランスにとって、これほど ROI の高い投資は他にありません。
補足: 料金表は変わるので、損益分岐点は自分で引き直します
最後に、プランの話に触れておきます。
3つの IDE はいずれも、プラン構成を短い周期で変えています。ここに「いまはこういう料金です」と書いても、読んでくださる時点では古くなっている可能性が高いのです。私自身、以前この手の記事に書いた金額を、半年後に自分で書き換えることになりました。ですので金額は各社の料金ページで確かめていただくとして、ここには確かめたあとの手順だけを置いておきます。
月額が変わったら、paired の出力からその IDE が勝っている種別を1つ選び、その種別の実効時間単価で新しい月額を割ってください。何時間ぶんの稼働で元が取れるかが出ます。その時間が自分の月の稼働時間を超えていたなら、プランを落とすか、その種別を別の IDE へ移すかの判断に入ります。
料金の変化は、契約を見直す合図ではなく、配分を見直す合図です。 月額が上がったから解約する、ではありません。その IDE に載せている種別が、いまもそこで勝っているのかを見直します。台帳があると、この判断が感覚ではなく数字になります。
本記事のシナリオ別構成は、私自身の案件から出した現時点での最適解にすぎません。稼ぎ方も案件種別も人によって違うので、別の組み合わせが正解になることは十分あります。
そこで最後に、明日から動かせる形にしておきます。シナリオA〜Dのうち自分に最も近いものを1つ選び、その推奨構成で2週間走らせてください。そのあいだ ide_ledger.py に案件を記録し、report ではなく paired の出力から読みはじめていただければと思います。数字が出た時点で、この記事の倍率はもう不要になります。
比較記事の価値は、読んだ人が自分の数字を持つところまでで終わりです。お読みいただきありがとうございました。