正直に言うと、Gemini 2.5 Pro をデフォルトにしたまま使い続けることに、少し疑問を感じていました。
「このコードのバグ直して」「このファイルにコメントを追加して」――そういった日常的な作業に、最上位モデルが本当に必要なのかどうか。毎日何十回も繰り返すような作業では、応答速度のほうが精度よりも体験を左右することが多いからです。
そこで4月中旬から、Antigravity のデフォルトモデルを Gemini 2.5 Flash に切り替えて使い続けています。3週間分の実測をまとめます。
切り替え前に抱いていた不安
モデルを下げることへの抵抗は、「精度が落ちてミスが増えるのでは」という直感的な不安でした。特に複雑なリファクタリングや、コンテキストが長くなるセッションではその不安が大きかったです。
結論から言うと、この不安は半分当たっていて、半分外れていました。
Gemini 2.5 Flash の実際の挙動
Antigravity の設定変更は、左サイドバーの Settings → Model → Default Model から行います。ドロップダウンに「Gemini 2.5 Flash（Thinking）」と「Gemini 2.5 Flash」の2種類があります。
// Antigravity 設定ファイル（~/.config/antigravity/settings.json）
{
"defaultModel": "gemini-2.5-flash",
"thinkingMode": "adaptive",
"thinkingBudget": 1000
}thinkingBudget は Thinking トークンの上限です。デフォルトは auto（無制限）ですが、1000〜2000 に抑えることで応答速度を大幅に短縮できます。
実測値（私の環境: MacBook Pro M4 Max, Wi-Fi 300Mbps）
- Gemini 2.5 Pro: 平均応答 8.2 秒（Thinking あり）
- Gemini 2.5 Flash (Thinking auto): 平均応答 4.8 秒
- Gemini 2.5 Flash (Thinking budget 1000): 平均応答 2.9 秒
- Gemma 4 ローカル: 平均応答 1.4 秒（ただしコンテキスト長に依存）
数字だけ見ると Flash が明確に速く見えますが、重要なのは「体感としての速さ」です。4秒と3秒の差は体感でほぼわからない一方、8秒と3秒は明らかに違います。
どこで差が出たか（実例）
差がほぼなかった作業
- 関数単体のバグ修正
- コメント追加・ドキュメント生成
- テストコード生成（ユニットテスト）
- 小〜中規模のリファクタリング（200行以内）
- TypeScript 型エラーの解消
これらは全体の作業時間の 75〜80% を占めています。日常的なコーディングのほとんどは、Flash で十分に対応できました。
Pro のほうが明らかに優れていた作業
// このような複数ファイルにまたがる設計変更
// Flash: 変更の一部を見落とすことがあった
// Pro: 依存関係を含めて一貫した変更を提案してくれた
// Before (Flash で生成したコード)
const handler = async (req: Request) => {
const data = await db.query(req.params.id);
return Response.json(data);
// ← エラーハンドリングが抜けていた
};
// Pro で再生成したコード
const handler = async (req: Request) => {
try {
const data = await db.query(req.params.id);
if (!data) return new Response('Not found', { status: 404 });
return Response.json(data);
} catch (err) {
console.error('[handler]', err);
return new Response('Internal error', { status: 500 });
}
};大規模なアーキテクチャ変更や、プロジェクト全体の構造を把握した上での提案では、Pro のほうが漏れが少ない印象です。コンテキスト長が長くなるほどこの差は顕著になりました。
コストへの影響
Antigravity の API 使用量は、設定の Usage タブで確認できます。3週間でのトークン消費を比較すると：
- 切り替え前（Pro デフォルト）: 約 1.2M tokens/週
- 切り替え後（Flash デフォルト）: 約 0.9M tokens/週
約 25% の削減でした。絶対額はサブスクリプション内に収まっているので直接の節約にはなりませんが、クレジット消費のペースが落ちたことで「重い作業に Pro を使う余裕」が生まれました。
現在の使い分け戦略
3週間試して落ち着いたのは、Flash をベースに、作業の性質で Pro に切り替えるスタイルです。
Antigravity の Cmd+Shift+M（Mac）でモデルを即座に切り替えられるので、操作コストはほぼゼロです。
Flash で対応：
- 日常的なバグ修正・コメント追加
- 単一ファイル内の変更
- テスト生成・型修正
Pro に切り替える：
- 新しい機能の設計・提案
- 3ファイル以上にまたがる変更
- 「なぜこの設計が良いか」を考えてもらう場面
- レビューコメントへの一括対応
Gemma 4 ローカルは、インターネット接続が不安定な環境や、コードを外部に送りたくない場面で活用しています。
全体を振り返って
Flash に切り替えることで、日常作業のテンポが明らかに上がりました。応答を待つ数秒が積み重なると、思考のリズムに影響するのだと気づいたのは、切り替えてからです。
精度への不安は、「どの作業に Pro が必要か」を経験的に掴むことで解消されていきます。まず Flash をデフォルトにして使い続けることで、その境界線が見えてくるはずです。
自分の作業パターンに合わせたモデル選択が、最終的には一番のコスト最適化になると感じています。
モデルの使い分けをさらに深めるなら、Antigravity のコンテキスト管理と大規模コードベースでの設定最適化の記事も参考になります。