「Gemini CLI で十分じゃない？」「いや Antigravity の体験は別物だよ」— 個人開発者の集まりで、この種の言い合いを何度聞いたかわかりません。私自身、半年ほど両方を本気で並行運用してきて、最近ようやく自分なりの結論にたどり着きました。先に言ってしまうと、答えは「どちらか一方を選ぶ」ではなく「作業の粒度に応じて住み分ける 」です。ただし、その住み分けには明確な軸があります。
この記事は、両者の機能を網羅的に並べる比較記事ではありません。実際にいくつかのプロダクトを Gemini CLI と Antigravity で同時並行に開発してきた手応えと、思わぬところで詰まったコスト・運用上の問題、そして今は固まりつつある判断フレームワークを共有する記事です。同じように二刀流でいきたいけれど、頭の中が整理できていない方の参考になれば嬉しいです。
「使い分ける」ためにまず押さえる3つの軸
両者を比べるとき、機能リストを並べてもあまり意味がありません。同じ「コードを書く」用途でも、ツールの設計思想が違うと使いどころも変わります。私が最終的に重視している軸は3つに絞れました。
軸1: 操作の単位が「コマンド」か「セッション」か
Gemini CLI は基本的に「1コマンド = 1タスク」で完結する設計です。gemini -p "このログをサマライズして" のように、入力と出力が1対1で対応します。状態を持たないため、シェルパイプラインや Makefile、シェルスクリプトに自然に組み込めます。
一方の Antigravity は「セッション内で複数のステップを行き来する」前提で作られています。ファイルを開き、コードを編集し、エージェントに指示を出し、結果を見て次の指示を考える、という流れが滑らかに繋がります。
この違いが意外と侮れません。「ログを 1 回要約してほしい」だけなら Gemini CLI のほうが明確に早く、「コードベースを理解しながら段階的にリファクタする」なら Antigravity のほうが明確に速いです。
軸2: コンテキストの「持ち方」
Gemini CLI のコンテキストは、毎回明示的に渡すのが基本です。@file.ts @docs/spec.md のように @ 記法でファイルを添付するか、stdin でパイプ経由で渡します。これは透明で予測可能な反面、長く付き合う「育てるコンテキスト」には向きません。
Antigravity は IDE のワークスペース全体が暗黙のコンテキストになります。エージェントは関連ファイルを自動的に探索し、.agentrules や AGENTS.md で永続的なルールを学習できます。便利ですが、何が読まれているかブラックボックスになりやすく、デバッグ時に困ります。
軸3: エージェントの「粒度」
Gemini CLI のエージェントは、ほぼ「単発の関数呼び出し」です。長時間動かすことを想定していません。一方 Antigravity のエージェントは「Manager Surface で監視しながら時間をかけて動かす」前提です。
この違いを無視して両者を取り違えると、CLI で長時間タスクを走らせてセッションがタイムアウトしたり、Antigravity でワンライナー的な質問をしてセッション切替のオーバーヘッドだけ取られたりします。
Gemini Code Assist を挟むと、三者の輪郭がはっきりします
ここまで二者の話をしてきましたが、実際に相談を受けるとき最も多いのは「Gemini Code Assist との違いが分からない」という声です。同じ Google の名前を冠しているのに、置かれている場所がまったく違うため、混乱するのは当然だと感じております。
三者を分けているのは機能ではなく、エディタとの距離 です。
私が実務で線を引いているのは、**「エディタを乗り換える覚悟があるかどうか」**の一点です。
Code Assist は、いま使っている VS Code や JetBrains をそのまま維持したい人のための選択肢です。チームの誰かが Vim を使い、誰かが IntelliJ を使っている状況で、全員に同じ AI 支援を配りたいなら現実解はこちらになります。エディタの設定・キーバインド・プラグイン資産を捨てずに済むという利点は、移行コストを実際に払う立場になると想像以上に大きいものです。
Antigravity はその逆で、エディタ自体を AI エージェント前提に組み替えたツールです。Manager Surface で複数エージェントの進捗を並べて見る体験は、拡張機能という形では成立しません。得られるものは大きいのですが、日々の作業場所を移すという決断が先に必要になります。
私自身は、自分のプロダクトは Antigravity、他社のリポジトリに間借りして手を入れる案件では相手のエディタ文化に合わせて Code Assist、無人で回す処理は CLI、という三層に落ち着きました。三択に見えて、実際には「誰の環境で作業しているか」がほぼ答えを決めています。
補足として、Code Assist と Antigravity は排他ではありません。VS Code に Code Assist を入れたまま Antigravity を併用している時期が私にもありましたが、補完の提案が二重に走って邪魔になったため、片方の inline 補完を切って役割を分けました。同居させるなら、補完は片方だけに任せる設定にしておくと落ち着きます。
ターミナル前提のタスクは Gemini CLI が依然として強い
私が「これは CLI 一択」と即断するパターンを、実際の使用例で示します。
例1: コミットフックでの差分レビュー
.git/hooks/pre-commit に組み込んでステージ済みの差分を機械的にレビューさせるユースケースです。Antigravity ではこの処理を IDE の外で完結させるのが難しいですが、Gemini CLI なら自然に書けます。
#!/usr/bin/env bash # .git/hooks/pre-commit # ステージされた diff を Gemini CLI で軽量レビュー。重大な問題のみ commit を止める。
set -euo pipefail
DIFF = "$( git diff --cached --diff-algorithm=minimal )" if [ -z " $DIFF " ]; then exit 0 fi
# 100 行未満なら時間の無駄なのでスキップ LINES = $( echo " $DIFF " | wc -l ) if [ " $LINES " -lt 100 ]; then exit 0 fi
REVIEW = $( echo " $DIFF " | gemini -p "次の差分を 'BLOCK:'（重大な問題）または 'OK' のいずれかで判定してください。理由は1行で。" 2> /dev/null || echo "OK CLI 利用不可" )
if [[ " $REVIEW " == BLOCK: * ]]; then echo "❌ Gemini レビューが commit をブロックしました：" echo " $REVIEW " exit 1 fi
echo "✅ Gemini レビュー: $REVIEW " exit 0 期待する動作は、差分が 100 行未満なら何もせず通過し、100 行以上なら Gemini に判定させ、BLOCK: プレフィックスのときだけコミットを止めることです。|| echo "OK CLI 利用不可" のフォールバックで、ネットワーク切断時にも開発を止めない設計にしているのがポイントです。**「AI を介在させたいけれど、AI が落ちたときに作業が止まる設計はしたくない」**という考えで、私はこの種のフックは必ずフェイルオープンで書きます。
例2: 月次の運用レポート生成
CRON で毎月走らせる集計スクリプトに、Gemini CLI を組み込んだ例です。
#!/usr/bin/env bash # scripts/monthly_summary.sh # 月次の Cloudflare Workers ログを集計し、Gemini に異常値の検出を依頼する。
set -euo pipefail
OUTPUT_DIR = "reports/$( date +%Y-%m)" mkdir -p " $OUTPUT_DIR "
# 1. 集計 npx wrangler tail --format=json --search= "status>=500" \ | jq -s 'group_by(.path) | map({path: .[0].path, count: length})' \ > " $OUTPUT_DIR /errors.json"
# 2. Gemini に解釈を依頼 SUMMARY = $( cat " $OUTPUT_DIR /errors.json" | gemini -p "次の API エラー集計から、急増しているエンドポイントと推定原因を3項目だけ箇条書きで。原因は『仮説』として書いて。" 2> " $OUTPUT_DIR /gemini.err" || echo "Gemini 解釈失敗" )
# 3. レポート出力 cat > " $OUTPUT_DIR /summary.md" << EOF # $( date +%Y-%m) 月次エラーサマリー
$SUMMARY
--- 集計データ: errors.json を参照 EOF
echo "✅ 月次レポート: $OUTPUT_DIR /summary.md" このパイプラインを Antigravity の中でやろうとすると、IDE を起動して、エージェントに wrangler tail を実行させて、結果を確認して……という流れになり、CRON で無人運用するには向きません。**「人間が見ていない時間に走らせる集計は CLI で書く」**は私の中で固まっているルールです。
例3: シェル統合の深さ
地味ですが見逃せないのが、xargs や parallel との相性です。たとえば 200 ファイルの README を一括で日本語化したい場合：
find docs -name "README.md" \ | parallel -j 4 'gemini -p "次の README を日本語に翻訳してください。コード例はそのままで。" --file {} > {.}.ja.md' これに相当する処理を Antigravity でやるには、エージェントを長時間ループで走らせる必要があり、コスト・速度ともに不利です。シェルが既に持っている並列処理の強みを使い切れる のは、CLI 系ツールの大きな美点です。
IDE と分かちがたい作業は Antigravity 一択
逆に、私が「これは Antigravity 以外考えられない」と感じるのは、コードベースを理解しながら手を動かす作業です。
マルチファイル編集での相応の楽さ
たとえば「UserRepository の API 名を findById から getById に変えたい。テストとモックも全部更新して」というタスク。Antigravity なら以下のような指示で 1 セッションで完了します。
src/repositories/UserRepository.ts の findById を getById にリネームし、
呼び出し側 (src/, app/) とテスト (tests/) のすべてを追従させてください。
変更後、npm test を実行して結果を報告してください。
エージェントは関連ファイルを横断的に編集し、Manager Surface で進捗が見え、テストの失敗があれば修正案を提示してきます。Gemini CLI で同じことをやろうとすると、ファイル一覧の取得・編集・テスト実行を別々のコマンドで人間が繋ぎ込む必要があり、テンポが完全に死にます。
Checkpoints とロールバックの安心感
私が Antigravity を手放せない最大の理由は、Checkpoints の存在です。エージェントに大きな改修を任せた後で「やっぱり違う方向に進めたい」と思ったとき、Restore Checkpoint で数十秒前の状態に巻き戻せます。CLI 系で git stash や git reset を駆使するのと比べて、試行に伴う心理的なコストがぐっと下がります。
「リスクを取った試行を頻繁にしたい」プロジェクトでは、これだけで Antigravity を選ぶ価値があります。詳しい使いこなしは Antigravity の Checkpoints とロールバックを使いこなす にまとめています。
Browser Sub-Agent の存在
これも CLI には絶対に持ち込めない強みです。「このフォームを実際にブラウザで開いて、3パターン入力して挙動を確認して」というタスクを、Antigravity は IDE 内蔵のサブエージェントで完結させられます。スクリーンショット付きでレポートが返ってきます。
同じ「コードレビュー」でも、両者で結果が違う
ここは多くの人が見落としがちな点なので、実例で示します。私が Promise.all の使い方が怪しい関数を、両者にレビューさせた結果を比較してみました。
対象コード（意図的に問題を仕込んだ TypeScript）：
// src/services/userSync.ts export async function syncUsers ( userIds : string []) { const results = await Promise . all ( userIds. map ( async ( id ) => { const user = await fetch ( `/api/users/${ id }` ). then (( r ) => r. json ()); await db.users. upsert (user); return user; }) ); return results; } Gemini CLI（gemini -p "次のコードをレビュー" --file src/services/userSync.ts）の指摘:
Promise.all で全件並列に発射するため、userIds が 1000 件なら 1000 同時リクエストになりレート制限に引っかかる可能性fetch のエラーハンドリングがないr.json() のステータスコード検証がない
3 点とも妥当ですが、コード全体を「ファイル単独」で見ているので、db.users.upsert がトランザクション境界をどう持っているかには触れません。
Antigravity（同じコードを開いた状態でエージェントにレビュー依頼）の指摘:
上記 3 点に加え、upsert の実装（src/db/users.ts）を読みに行き「トランザクションが各 upsert ごとに張られているため、整合性を求めるなら一括トランザクション化が必要」という構造的な指摘
周辺の呼び出し元（src/jobs/userSync.ts）を読んで「リトライ処理が呼び出し側にあるが、syncUsers 内部でも部分的にリトライしているため二重化している」という運用上の指摘
つまり、**Antigravity のレビューは「コードベース全体での整合性」を見にいきます。**Gemini CLI は「渡されたコード単独」を見ます。どちらが優れているかではなく、用途が違うのです。新規スクリプトをサッとレビューしたいなら CLI、本番コードの構造的問題を洗いたいなら Antigravity、と分けています。
私の実際の使い分け（プロジェクト種別ごと）
抽象論だけだと使えないので、私のプロジェクト棚卸しをそのまま開示します。
既存リポジトリの保守（業務委託案件など） : Antigravity 中心、9 割。コードベース理解と部分修正が大半なので、IDE のコンテキスト保持が効きますゼロから作るプロトタイプ（個人アプリ） : 50/50。最初の数日は CLI でガリガリ書き、構造が見えてきたら Antigravity に移行しますCI/CD・自動化スクリプト : CLI 一択。CRON や GitHub Actions で動かすことが前提なのでドキュメント・記事・READMEの英訳 : CLI。xargs -P で一括処理するためデザイン作業（Figma 連携） : Antigravity 一択。MCP 経由で Figma を読む体験は CLI では再現できません
この比率は人によってまったく違うはずです。重要なのは、自分のプロジェクト種別に対してどちらが向くかを言語化しておくこと です。
落とし穴：両者を同じプロジェクトで併用するときの地雷
ここからが本題かもしれません。両方使うと決めると、いくつか必ず踏む地雷があります。
地雷1: ルールファイルの競合
Antigravity は AGENTS.md や .agentrules、Gemini CLI は .geminirc や GEMINI.md を見ます。両方を別々に書くと、同じプロジェクトに対して矛盾する指示が混在し始めます。
私の解決策 : 真実のソースを AGENTS.md 1 つに集約し、.geminirc は AGENTS.md を読み込ませる薄いシムにします。
# .geminirc context_files : - AGENTS.md - docs/architecture.md
system_prompt : | プロジェクト固有のルールは AGENTS.md に従ってください。 追加で、CLI 実行時は変更を提案するだけで実際のファイル編集はしないでください。 ファイル編集は IDE 側で人間が確認してから行います。 「AGENTS.md だけメンテすればいい」という運用にすると、両者の指示の食い違いがなくなります。
地雷2: 履歴の二重化と検索性の劣化
CLI のセッション履歴と Antigravity のチャット履歴が別々に蓄積されると、「あれどこで議論したっけ」が頻発します。私は両方の決定事項を docs/decisions/YYYY-MM-DD.md に手動で書き出すことにしました。手間ですが、半年後の自分への投資です。
地雷3: コスト管理がブラックボックス化
これが最も痛いです。Gemini CLI は API 利用量、Antigravity はクレジットで課金されますが、月末に明細を見て「こんなに使ってたのか」となるパターン を私は何度もやりました。
対策 : 月初に予算を決めて、両方のダッシュボードを Notion か手帳に貼り付けて、毎週見る。地味ですが、これしかないです。コスト最適化の具体策は Antigravity Ultra クレジットを最大限使い切る運用ガイド にまとめました。
価格・コストの実情（2026年5月時点）
数字は変動するので、ここでは「考え方」だけ書きます。
Gemini CLI: API 従量課金（モデルごとに単価あり）。バッチ処理で「1 万件のドキュメント翻訳」のような重い使い方をすると一気に膨らみます
Antigravity: クレジット消費型。Ultra 等の上位プランで月固定費 + クレジット枠
個人開発で月 5〜10 時間使う程度なら Antigravity 単体で完結することが多いです
ただし、CRON で深夜に大量集計を走らせる用途は CLI に寄せた方が安く済む場合があります
「全部 Antigravity に寄せるとクレジット枯渇、全部 CLI にすると IDE 体験を失う」が現実です。重作業は CLI、対話作業は Antigravity の振り分けが、私のコスト最適バランスでした。
制限ネットワークと DevContainer では、判断軸が一段増えます
決定木をひと通り使ってもらった後で「その通りにしたのに動かない」と言われることがあります。たいていの場合、原因はタスクの性質ではなく実行環境のほうにあります。
プロキシ配下では壊れ方が非対称です
企業ネットワークや検査型プロキシの内側に入ると、二者の壊れ方が揃いません。
Gemini CLI は環境変数だけを見ます。HTTPS_PROXY と NO_PROXY、それに自己署名証明書を使う環境であれば NODE_EXTRA_CA_CERTS を渡せば、たいていそのまま通ります。壊れるときは明確に壊れるので、切り分けも速いです。
# 制限ネットワーク下で CLI 側を通すための最小セット export HTTPS_PROXY = "http://proxy.example.internal:3128" export NO_PROXY = "localhost,127.0.0.1,::1,.internal" export NODE_EXTRA_CA_CERTS = " $HOME /.certs/corp-root.pem"
# 通信が生きているかを、モデル呼び出しの前に確認する curl -sS -o /dev/null -w '%{http_code}\n' https://generativelanguage.googleapis.com/ \ || echo "proxy/cert layer is broken — fix this before blaming the tool" Antigravity 側は事情が違います。認証・モデル API・エージェントが起動する子プロセス・拡張機能の更新が、それぞれ別々の経路で外に出ます。プロキシはそのうちの一部だけを落とすため、「補完は効くのにエージェントだけ沈黙する」という中途半端な壊れ方になります。原因を追いにくいのはこちらです。
そのため私は、社内ネットワークや出先の回線で作業する日は、重い判断を要するタスクほど先に CLI 側で疎通を確認してから Antigravity に移すようにしております。レイヤー別の切り分け手順は Antigravity をプロキシの内側で動かす に分けて書きました。
DevContainer に閉じ込めると、選択肢が片側に寄ります
コンテナ内で開発する構成にすると、判断は単純になります。コンテナに入れておけば済む CLI 側が有利になるためです。
{ "name" : "app-dev" , "image" : "mcr.microsoft.com/devcontainers/typescript-node:20" , "remoteEnv" : { "HTTPS_PROXY" : "${localEnv:HTTPS_PROXY}" , "NO_PROXY" : "localhost,127.0.0.1,host.docker.internal" }, "postCreateCommand" : "npm ci" , "mounts" : [ "source=${localEnv:HOME}/.config/gemini,target=/home/node/.config/gemini,type=bind,consistency=cached" ] } remoteEnv でホスト側のプロキシ設定を持ち込み、認証情報のディレクトリだけを bind mount する形にすると、コンテナを作り直しても再ログインが要りません。NO_PROXY に host.docker.internal を入れているのは、ホスト側で動かしているローカル LLM をコンテナから叩くときにプロキシを経由させないためです。ここを忘れると、ローカルへの接続が社内プロキシに吸われて無応答になります。
一方の Antigravity をリモートコンテナ前提で運用する場合、ワークスペースの探索対象がコンテナ内のファイルシステムになるため、ホスト側に置いた資料やメモは自動では読まれません。私はこれで一度、「なぜ設計メモを無視するのか」と数十分悩みました。コンテナ境界はそのままコンテキスト境界になります。
まとめると、判断木の手前にもう一問足すのが正確です。「そのタスクは、いま自分がいるネットワークとコンテナの内側で完結するか」。ここが NO のときは、ツールの向き不向き以前に環境の設定が答えを決めます。
判断フレームワーク（決定木）
迷ったときに使えるよう、決定木を共有します。次の質問に答えるだけで、どちらに寄せるか決まります。
Q0: そのタスクは「いま自分がいるネットワークとコンテナの内側」で完結するか？
NO → 先に環境を通す。ここが未解決のまま先へ進むと、ツールの向き不向きの話に見えて実は設定の問題を追うことになります
Q0b: 使っているエディタを乗り換える意思があるか？
NO → Gemini Code Assist （既存 IDE に拡張機能として載せる）か Gemini CLI
Q1: そのタスクは「CRON や CI で人間が見ていない時間に走らせる」可能性があるか？
Q2: そのタスクは「複数ファイルを横断して編集する」必要があるか？
Q3: そのタスクは「実行時間が 30 秒以内で終わる単発の質問」か？
YES → Gemini CLI （IDE 起動オーバーヘッドが無駄）
Q4: そのタスクは「途中で巻き戻したくなる可能性がある」か？
YES → Antigravity （Checkpoints の安心感）
Q5: そのタスクは「ブラウザでの動作確認」を含むか？
YES → Antigravity （Browser Sub-Agent）
上記すべて NO → 好きな方を選んでください。最終的には慣れているツールが速いです
よくある間違い・落とし穴（運用半年で見えたパターン）
間違い1: 「速い」を機能比較で決める
新規プロジェクトのプロトタイプを作るときは CLI のほうが「初速」は速いです。しかし「3 日後に構造が複雑化したとき」は Antigravity のほうが速くなります。初速と巡航速度の両方を見て選ぶ のが正解です。
間違い2: 設定ファイルを増やしすぎる
AGENTS.md、.agentrules、.geminirc、GEMINI.md、.cursorrules（残骸）……気づくとプロジェクトルートが設定ファイルだらけになります。真実のソースを 1 つに絞り、他はシム が原則です。
間違い3: コスト・実行時間のメトリクスを取らない
両方使い始めると「なんとなく便利」で済ませがちですが、月初に「先月どっちで何時間消費した」を集計しないと、片方に偏りすぎている事実に気づけません。私はシェルスクリプトで両ダッシュボードからデータを取得して Notion DB に投げています。
どこまでのコードが手元を離れるか
ツール選定の議論でほとんど語られないのに、受託の現場では真っ先に確認される観点があります。どのファイルが自分の機械の外へ出るか、という点です。
Gemini CLI で外に出るのは、@ で明示的に添付したファイルと標準入力に流した内容だけです。範囲が入力と一致しているため、何を送ったかを後から説明できます。これは技術的な安心というより、契約上の説明責任の話です。
Antigravity は設計上、エージェントがワークスペースを自律的に歩きます。強力さの源泉がそのまま範囲の広さになるため、「自分が指し示していないファイルも読まれうる」という前提で扱う必要があります。読ませたくない領域があるなら、AGENTS.md 側で除外を明記しておきます。
私は、秘密保持契約のあるリポジトリでは、クライアントに範囲を確認できていないディレクトリに触れるタスクを CLI 側に寄せることにしております。技術的な優劣ではなく、説明できる範囲で作業するための線引きです。個人のプロジェクトであればここまで気にする必要はありませんが、ツールの選択が契約遵守の選択でもある という視点は、事故が起きる前に持っておくほうが安く済みます。
全体を振り返って — 次の一歩
ここまで読んでいただいたあなたへ、今日試してほしい一歩は1つだけです。直近で詰まっているタスクを 1 つ取り出し、上の決定木に当てて、現在使っているツールが正しいかを確認すること 。もし違う側のツールのほうが向いているなら、そっちで 30 分だけ試してみてください。判断が肌感に変わります。
ツール選びに正解はなく、自分の作業の輪郭が変われば最適解も変わります。半年後にこの記事を読み返して「いや、もう違うな」と思っているくらいのつもりで、自分のワークフローを観察し続けるのが、結局いちばん早道だと感じています。