「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 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 の振り分けが、私のコスト最適バランスでした。
判断フレームワーク（決定木）
迷ったときに使えるよう、決定木を共有します。次の質問に答えるだけで、どちらに寄せるか決まります。
- 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 に投げています。
全体を振り返って — 次の一歩
ここまで読んでいただいたあなたへ、今日試してほしい一歩は1つだけです。直近で詰まっているタスクを 1 つ取り出し、上の決定木に当てて、現在使っているツールが正しいかを確認すること。もし違う側のツールのほうが向いているなら、そっちで 30 分だけ試してみてください。判断が肌感に変わります。
ツール選びに正解はなく、自分の作業の輪郭が変われば最適解も変わります。半年後にこの記事を読み返して「いや、もう違うな」と思っているくらいのつもりで、自分のワークフローを観察し続けるのが、結局いちばん早道だと感じています。