Antigravity のクオータ制限を模索・トークン節約｜Gemini CLI 連携で品質を底上げする「エビで鯛を釣る」試み 前編

1. 今回の目的と設計思想

目的は品質向上です。Antigravity の Flash でも、可能な限りそれ以上の結果を出せるようにします。

そのために、ユーザーが Antigravity の会話に依頼する → その内容をもとに Gemini CLI と Antigravity がやり取りします。Gemini CLI は Plan モード（読取専用で計画を立てるモード。公式では同等かより高度な LLM が使われる）で計画を出し、Antigravity がその結果を読み込み判断します。判断結果を CLI に返し、この往復でより良い Plan を導き、最終的に Gemini CLI で成果物を生成する——Antigravity は Flash のまま、トークン量を抑えつつ品質を最大限にする、という設計思想です。

上記の流れを図にすると次のとおりです。

2. 前提条件：Skill 知識・Gemini CLI 設定・OAuth・Git Bash

次の前提がそろっている必要があります。

• Skill の知識：Antigravity と Gemini CLI を連携させるための Skill を利用する前提で、その内容を理解していること。
• Gemini CLI の設定（利用可能な状態）：npm install -g @google/gemini-cli でインストール済みで、gemini コマンドが使えること。
• OAuth 認証済み：Gemini CLI で「Login with Google」により認証済みであること。Google AI Pro / Ultra の契約アカウントでログインすると、Code Assist と CLI のクオータ（例：Google AI Pro で 120/分・1,500/日）が共有されます（公式 Quotas・Gemini CLI Authentication 参照）。
• ターミナルは Git Bash：Antigravity 内のターミナルで Git Bash を使用すること。Bash 前提の指示やドキュメントと相性がよい（brief053 でターミナルを Git Bash にする方法をまとめています）。

要のスキル：gemini-cli-control

Antigravity が司令塔となり、Gemini CLI をヘッドレスで呼び出して編集・解析・複数ステップを完遂させるためのスキルです。要点を図と表で示します。

司令塔の基本思想

CLI の出力は鵜呑みにせず Antigravity が精査。Plan 作成→精査→修正→合意→実装を Antigravity が制御し、重い処理は CLI に委譲。

最短の 1 回の流れ

編集時は --approval-mode=yolo、Plan 時は --approval-mode=plan。Git Bash では /c/... で cd。

役割分担

Antigravity がやる	CLI に委譲
思考・方針・指示出し・ユーザー対応	ファイル編集・一括変更・検索
小規模なコード提案	ビルド・テスト実行
Plan の精査・修正依頼	大規模読み取り・解析

最小読込・参照リソース

通常は SKILL.md のみ。必要になったタイミングで該当リソースを読む（トークン節約）。

資料	読むタイミング
agent-behavior.md	委譲・安全・Plan 精査
manual-for-agent.md	実行手順・コマンド・Git Bash
reference.md	オプション・終了コード
prompt-templates.md	定型プロンプト
trusted-folder / troubleshooting	信頼フォルダ・エラー切り分け
conversation-patterns.md	会話往復型のフロー

3. なぜ Antigravity 単独ではなく CLI を組み合わせるのか

Antigravity の LLM 利用枠と、Gemini Code Assist・Gemini CLI のリクエスト枠は別カウントです（Quotas and limits）。

Plan モードでは、CLI 側で同等かより高度な推論モデルが使われ、読取専用で計画を立てるため、Antigravity 側の編集・実行負荷を減らしつつ計画の質を上げられます。会話・指示・確認は Antigravity に、編集・生成は CLI に寄せることで、クオータをやりくりしつつ品質向上を狙います（brief052 の「エビで鯛を釣る」の延長です）。

4. 連携フロー：Antigravity 依頼 → CLI Plan モード → Antigravity 再判断 → CLI 実行

流れは次のとおりです。

1. ユーザーが Antigravity の会話に依頼を出す。
2. その依頼をもとに、Gemini CLI と Antigravity がやり取りする。CLI は Plan モードで計画を出力する（公式では Plan モードで同等かより高度な Pro モデルが使われる：Plan mode is now available in Gemini CLI）。
3. Antigravity が CLI の Plan 結果を読み込み、判断する。
4. 判断結果を CLI に返し、やり取りを繰り返してより良い Plan を導く。
5. 最終的に Gemini CLI で成果物を生成する。

このやり取りにより、Antigravity は Flash のままでトークン量を抑えつつ、CLI の Plan と実行を活かして品質を底上げする、という狙いです。

5. 今回試す前半 8 パターンの見方

テストパターンは全部で 16 パターン用意しており、Antigravity と Gemini CLI 連携用の Skill を利用しながら模索していきます。今回は前半 8 パターンを扱い、後編で残り 8 パターンを扱う予定です。

6. パターン一覧 1–8：何をテストするか・会話に流す依頼

ZIP 解凍後の各テストフォルダ（test-01 ～ test-08）には README があり、その中の「依頼内容」・「想定される依頼文」を Antigravity の会話にコピーして流します。必要なファイルは各フォルダにすでに用意されているので、そのフォルダをプロジェクトルートで開いた状態で依頼文を貼り付けるとスキルが発動し、あとは自動で進みます。

テスト	何をテストするか	会話に流す依頼（コピペ用）
test-01	曖昧要求の具体化。雑な依頼から要件・未確定事項・確認質問を整理し、実装前の要件定義書を作らせる。	input-note.md を読んで、実装可能な要件定義書 REQUIREMENTS.md を作って。
test-02	Plan 監査（計画精査）。不備のある計画書をレビューさせ、矛盾・欠落・セキュリティ懸念を指摘し、改善版を作らせる。	この計画に問題がないか確認して、改善した refined_plan.md を作って。
test-03	ドキュメント要約と技術選定。複数ライブラリの仕様を比較させ、制約に合うものを選定・推奨させる。	プロジェクトで HTTP 通信ライブラリを選定したい。ドキュメントを読んで比較表を作り、どちらが良いか提案して。
test-04	段階的開発。複雑な機能を Phase に分け、Phase 1 だけ先に実装・検証させる。	requirements.md の Phase 1 だけまず実装して。
test-05	自然言語からのゼロイチ実装。仕様から動くプロトタイプ（画像リサイズスクリプト）を一気に生成させる。	Python で、画像をリサイズして別フォルダに保存するスクリプトを Pillow で作って。
test-06	API 連携とエラーハンドリング。成功時しか考慮していない API クライアントに、例外処理・リトライ・カスタムエラーを追加させる。	この API クライアントにエラーハンドリングを追加して。リトライ処理も入れて。
test-07	既存コードのリファクタリング。スパゲッティコードを関心の分離・DRY・適切な命名でクリーンにさせる。	このコードをリファクタリングして。メンテナンスしやすく分割して。
test-08	既存コードへの機能追加。商品一覧アプリに価格帯フィルタを追加し、既存構造を壊さず拡張させる。	既存の商品一覧に、最低価格・最高価格で絞り込むフィルタを追加して。

各テストは、該当フォルダを Antigravity で開いた状態で、上記「会話に流す依頼」をチャットにコピーして送信するとスキルが発動します。必要なファイルは各 test-0X 内に同梱されています。

テスト結果の分析（8 パターン実施後）

ZIP の状態は 8 テスト実施後の成果物。各テストの成果と所見を表にまとめた。

テスト	成果物	結果・所見
test-01	REQUIREMENTS.md	雑メモから要件・MVP・未確定・確認事項を整理。Plan へ進める粒度で達成。
test-02	refined_plan.md	Data First・パスワードハッシュ・認証・テスト工程を反映。矛盾・セキュリティ不備を解消。
test-03	comparison.md	比較表・制約適合表・Lib-A 採用と理由を記載。制約に沿った選定。
test-04	main.py	Phase 1 のみ（argparse・add サブコマンド）。過剰実装なし。
test-05	resize.py, requirements.txt	Pillow・800px・アスペクト比維持・Dir 作成・エラー処理。成功条件を満たす。
test-06	api_client.js（修正）	ApiError・3 回リトライ・5xx リトライ・タイムアウト対応。成功条件を満たす。
test-07	spaghetti.js（リファクタ）	バリデーション・計算・永続化・メインに分割。関心の分離を達成。
test-08	index.html, app.js（拡張）	価格帯フィルタ・空で全件表示。既存維持の差分拡張。

総括: 8 パターンとも依頼→スキル発動→CLI 実行の流れで期待どおりの成果物が得られた。Antigravity（Flash）が司令塔となり、重い処理を CLI に委譲して精査する設計どおりに動作している。

7. 後編で扱う残り 8 パターンへの予告

後編ではパターン 9–16 を扱い、難問・鬼門・やや大きなコンテンツに挑戦する予定です。依頼の粒度・Skill の渡し方・Plan と実行の分離など前半との違いをそろえて実験し、実運用の目安をまとめます。

本記事はコストパフォーマンス重視の苦肉の策として始めましたが、予想以上に精度が出て「これもありかな」と感じています。Antigravity の Thinking 系を制限なく使えるならスピード・やり取りの正確性などを考えると単体利用がベストかもしれません。それでもスキル定義のやり方次第で、連携運用もまだまだスムーズにいきそうです。