Gemini CLI と Antigravity を本気で使い分ける — 2026年5月、現場で出した結論

ターミナル前提のタスクは 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 で人間が見ていない時間に走らせる」可能性があるか？
  • YES → Gemini CLI
• Q2: そのタスクは「複数ファイルを横断して編集する」必要があるか？
  • YES → Antigravity
• 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 分だけ試してみてください。判断が肌感に変わります。

ツール選びに正解はなく、自分の作業の輪郭が変われば最適解も変わります。半年後にこの記事を読み返して「いや、もう違うな」と思っているくらいのつもりで、自分のワークフローを観察し続けるのが、結局いちばん早道だと感じています。