Antigravity を開いて最初に手が止まる場所のひとつが、右上のモデルセレクターです。Gemini 2.5 Pro と Flash のどちらを選ぶべきか、その日の作業内容によって正解が変わるため、慣れないうちは「とりあえず一番賢そうなほう」を選びがちになります。私自身も最初の数週間はずっと Pro に固定していて、月のコストが思った以上に膨らんで初めて使い分けを意識し始めました。
ここでは、どちらのモデルをいつ選ぶのかという判断軸を中心に、切り替え方法と設定のコツをまとめます。
Pro と Flash は「速さ」より「引き返せるか」で選ぶ
二つのモデルの違いは、おおまかには次のように整理できます。
Gemini 2.5 Pro は推論が深く、複数ファイルにまたがる設計判断や、原因の見えにくいバグの調査に向いています。そのぶん応答までの時間は長めです。一方の Gemini 2.5 Flash は応答が速くコスト効率に優れ、日常的なコード補完や軽いリファクタリングのように、結果をすぐ確認して直せる作業に向いています。
私が実際に意識しているのは速度よりも「やり直しのしやすさ」です。出力をその場で目視して、おかしければ秒で書き直せる作業なら Flash で十分です。逆に、一度通すと後戻りが面倒な変更、たとえば認証まわりやデータ層の構造変更は、最初から Pro に任せたほうが結果的に時間を節約できます。安いモデルで何度も往復するより、深く一度で当ててくれるモデルのほうが安く済む場面は意外と多いのです。判断の目安として、「失敗したときの影響がコードの外側、つまりユーザー体験やお金に波及するか」を私はひとつの線引きにしています。波及するなら Pro、コードの中で完結するなら Flash、という具合です。
モデルの切り替えはどこで行うか
モデルを変えるには、画面右上のモデルセレクターをクリックします。会話の途中でも切り替えられ、それまでのコンテキストはそのまま引き継がれます。
この「途中で切り替えても文脈が消えない」点が地味に効きます。Flash で気軽に探索を始めて、込み入った場面に差しかかったところで Pro に持ち替える、という流れを一つの会話の中で完結できます。私は調査の入り口を Flash で広げ、核心の実装だけ Pro に切り替える運用に落ち着きました。
プロジェクト単位でデフォルトを固定する
毎回手で選ぶのが面倒であれば、プロジェクト設定でデフォルトモデルを指定できます。
{
"model": "gemini-2.5-pro",
"context": {
"max_tokens": 128000
}
}このファイル（.antigravity/config.json）をリポジトリにコミットしておくと、複数人で触るプロジェクトでも全員が同じ初期設定で作業を始められます。個人開発でも、リスクの高いリポジトリは Pro 始まり、試作用のリポジトリは Flash 始まり、とプロジェクトごとに既定値を変えておくと、選び忘れによる事故が減ります。
100万トークンを活かせる場面・活かせない場面
Gemini 2.5 Pro は 100 万トークンのコンテキストウィンドウを持ちます。大規模なコードベースをまとめて読み込ませられるため、複数ファイルを横断する変更で力を発揮します。
# 複数ディレクトリを一度にコンテキストへ含める
@src/auth/
@src/api/
@tests/auth/
「認証フローを OAuth2.0 PKCE に移行してください」
ただし、コンテキストは広ければ広いほど良いわけではありません。関係の薄いファイルまで丸ごと渡すと、モデルの注意が分散して、かえって的外れな提案が増える場面がありました。私の場合は、まず変更に直接関わるディレクトリだけを @ で指定し、足りなければ追加する、という順序にしています。全部入れてから絞るより、必要なものを足していくほうが結果が安定します。
切り替えで一度つまずいたこと
ひとつ実体験として書き残しておきたい失敗があります。長い調査セッションを Flash で進めたまま、そのまま大きめのリファクタリングまで Flash に投げてしまったときのことです。提案されたコードは一見もっともらしく整っていたのですが、複数ファイルにまたがる依存関係の更新が一部抜け落ちていて、ビルドは通るのにテストで初めて気づく、という状態になりました。
このとき学んだのは、モデルを途中で持ち替え忘れるリスクは、賢いモデルから安いモデルへ落とすときよりも、安いモデルのまま重い作業へ進んでしまうときに起きやすい、ということです。それ以来、私は「変更の規模が一画面に収まらないと感じたら、手を動かす前にセレクターを確認する」という小さな儀式を挟むようにしています。たった一クリックの確認ですが、後から手戻りで失う時間を考えれば安いものです。
1日の開発でコストを抑える切り替えリズム
長い開発セッションでは、フェーズごとにモデルを持ち替えるとコストと精度のバランスが取りやすくなります。
朝の段階整理や、その日に触る範囲の下調べは Flash で軽く回します。設計を固める段階、レビューでの指摘対応、リリース前の最終確認といった「間違えると痛い」局面だけ Pro に切り替えます。この切り替えを習慣にしてから、Pro 固定だった頃に比べて月のモデル利用コストが体感で半分近くまで下がりました。速いモデルで下ごしらえをして、判断の重い場所だけ賢いモデルに任せる、という分担です。
個人開発の現場で落ち着いた使い分け
ここまでをふまえて、私が個人開発で実際に採用している基準をまとめます。私は App Store と Google Play で長く配信を続けているアプリの保守も並行しているため、「壊してはいけないコードに触れる時間」をいかに減らすかを常に気にしています。モデル選択も結局はそこに行き着きます。慎重さが要る場所にだけ深いモデルの力を集中させ、それ以外の手数は速いモデルで軽やかにさばく。この配分が、限られた一人の時間を守ってくれます。
日常のコード補完と軽い修正は Flash、後戻りしにくい設計判断と難所のデバッグは Pro。プロジェクトごとに既定モデルを config.json で固定し、コンテキストは必要なディレクトリだけを足していく。この三つを守るだけで、モデル選択に悩む時間そのものがほとんどなくなりました。
最初のうちは難しく考えず、「すぐ直せる作業は Flash、引き返しにくい作業は Pro」という一点だけ意識してみてください。そこから自分の作業に合った塩梅が見えてくるはずです。お読みいただきありがとうございました。