Antigravity IDE を使い始めると、最初に悩むのが「どのモデルをどの場面で使えばいいのか」という問いです。Gemini 2.5 Pro は強力ですが、毎回のコード補完や簡単な質問に使うとクレジットが一瞬で溶けていきます。一方で Gemini 2.5 Flash は、使い方さえ押さえれば、日常の開発タスクの大半を驚くほど速く、低コストでこなしてくれます。
Pro との使い分け基準についても整理しましたので、ぜひ参考にしていただければ幸いです。
Gemini 2.5 Flash が Antigravity 開発に向いている理由
Gemini 2.5 Flash は、Google が「高速・低コスト・実用十分な精度」をコンセプトに設計したモデルです。Antigravity IDE のコンテキストで使うと、特に次のような場面で真価を発揮します。
- コードの説明やコメント生成: 大量のコンテキストを読み込んで要約する処理が速い
- 小さなバグの特定と修正提案: エラーメッセージ＋スタックトレースへの反応が素早い
- ボイラープレートの生成: CRUD コードや型定義など、パターンが決まった生成作業
- リファクタリングの提案: 既存コードを読んで改善案を出す作業
Gemini 2.5 Pro との最大の違いは「推論の深さ」です。Pro は複雑なアーキテクチャ設計や数百行にまたがるリファクタリングで力を発揮しますが、日常の8割の作業は Flash で十分対応できます。
Antigravity でモデルを切り替える方法
Antigravity IDE でモデルを切り替えるには、チャットパネル右上のモデル選択ドロップダウンを使います。セッション単位で切り替えが可能で、タスクの内容に応じてリアルタイムに変更できます。
# モデル選択の基本的な使い方
1. Antigravity のチャットパネルを開く
2. 右上のモデルセレクターをクリック
3. "Gemini 2.5 Flash" を選択
4. 通常通りプロンプトを入力
# AGENTS.md でデフォルトモデルを指定する場合
# プロジェクトルートの .antigravity/AGENTS.md に記述
model: gemini-2.5-flash # デフォルトモデルを Flash に設定
ポイント: 長いコーディングセッションの冒頭でモデルを選択しておくと、意図しない Pro 消費を防げます。私の場合、Antigravity を起動したらまず Flash に切り替えてから作業を始めるのが習慣になりました。
Flash を使うべき場面 vs Pro を使うべき場面
どちらを使うかで迷わないよう、私なりの基準を整理しました。
Gemini 2.5 Flash を選ぶ場面:
- 「この関数に JSDoc コメントを追加して」
- 「エラーメッセージの意味を教えて」
- 「この変数名をリファクタリングして」
- 「TypeScript の型を追加して」
- 「テストケースを1つ追加して」
- ログやエラースタックの解析
Gemini 2.5 Pro を選ぶ場面:
- 新機能全体のアーキテクチャ設計
- 大規模リファクタリング（複数ファイルにまたがる）
- 設計の意思決定や技術選定の相談
- 複雑なバグで原因の特定が難しい場合
- プロジェクト全体の構造を把握した上でのレビュー
この分け方で運用すると、Pro の消費量を週あたり30〜40%削減できた経験があります。コスト意識を持って使い分けるだけで、同じプランで明確に多くの作業をこなせるようになります。
高速イテレーションを実現するワークフロー
Flash の「速さ」を最大限活かすには、ワークフロー自体を高速サイクルに最適化する点が肝心です。私が実践しているのは「小さな質問を連続して投げる」スタイルです。
// 例：SwiftUI のコンポーネントを段階的に改善する
// Step 1: まず基本実装を Flash に頼む
// プロンプト: 「商品一覧を表示する SwiftUI のリストビューを作って」
struct ProductListView: View {
let products: [Product]
var body: some View {
List(products) { product in
ProductRow(product: product)
}
}
}
// Step 2: 次の質問で即座に改善
// プロンプト: 「Pull to Refresh を追加して」
// → Flash が素早く refreshable 修飾子を追加してくれる
// Step 3: さらに絞り込み
// プロンプト: 「空のリストのとき EmptyView を表示して」
// → 条件分岐を即座に追加このように「1つの質問 = 1つの改善」という小刻みなやりとりをすると、Flash の応答速度が体感として分かるようになります。Pro だと少し待つような処理も、Flash なら会話テンポで進められます。
クレジットを節約しながら品質を維持するコツ
Antigravity のクレジット消費を抑えるには、プロンプトの書き方にも工夫が必要です。
1. コンテキストを絞る: チャットに貼り付けるコードは必要最小限に。関連する関数だけを @mention で参照し、不要なファイルを読み込ませない
2. 一度の質問で完結させる: 「まずXをして、それからYをして、最後にZをして」という複合指示より、一回の指示で完結するタスクに分解する
3. モデルの確認を習慣化: ときどきモデルセレクターを確認します。長時間作業中にいつの間にか Pro に切り替わっていることがある
4. エージェントモードは Flash から始める: エージェントを起動するとき、最初は Flash で試して結果を確認してから必要に応じて Pro に切り替える
実際に試してみて感じた限界と対策
Flash が得意でない場面も正直にお伝えします。
複数ファイルにまたがる変更: ファイルが3〜4個を超えると、Flash は変更の一貫性を保つのが難しくなります。このような場合は Pro に切り替えることをお勧めします。
長い会話セッション後の精度低下: 1つのセッションが長くなると（目安は15〜20ターン以上）、Flash は以前のコンテキストを「忘れ」やすくなります。新しいセッションを開始して、必要な情報を @mention で再度渡すと改善します。
高度な設計判断: 「マイクロサービスにすべきか、モノリスで良いか」などのアーキテクチャ判断は、Flash の回答が表面的になりがちです。こういった相談は Pro の出番です。
それぞれの特性を理解した上で使い分けると、Antigravity の体験が大きく変わります。
全体を振り返って：Flash ファーストの習慣から始めてみてください
Antigravity での開発を続けるなら、ぜひ「Flash ファースト」の習慣をつけることをお勧めします。最初は Flash で試して、物足りなければ Pro に切り替えるフローにするだけで、クレジットの使い方が自然と最適化されていきます。
今日からすぐできる一歩として、Antigravity を開いたらモデルセレクターで Flash を選び、まず5つのタスクを Flash だけでこなしてみてください。きっと「これで十分だった」という場面の多さに気づくはずです。
iOS/Android アプリ開発での具体的な活用については、Antigravity × iOS 26・Android 17 アプリ開発ワークフローもご参照いただけますと幸いです。Xcode Cloud との組み合わせについてはAntigravity × Xcode Cloud で iOS CI/CD を完全自動化するが参考になります。