Antigravityの2つのモードを徹底比較！PlanningとFastの違いとは？

2026年3月9日

URLをコピーしました！

GoogleのAIエディタ「Antigravity」を使い始めると、まず迷うのが作業モードの選択です。指示を出した後にじっくり計画を練る「Planning（プランニング）」と、即座に実行に移る「Fast（ファスト）」の2つがあり、これらを適切に切り替えることが開発効率を左右します。

どちらも強力な機能ですが、性格は正反対です。この記事では、それぞれのモードが持つ強みや弱点、そして実際の開発現場でどのように使い分ければいいのかを具体的に解説します。Antigravityを使いこなして、アプリ開発のスピードをさらに引き上げましょう。

AntigravityのPlanningとFastはどう違う？

Antigravityを使う上で避けて通れないのが、作業の「進め方」を決めるモード選択です。思考の深さを優先するPlanningと、速度を優先するFast。これらは車のギアを切り替えるように、タスクの重さに合わせて使い分ける必要があります。

まずは、それぞれのモードが開発現場でどのような役割を担っているのか、その根本的な違いを見ていきましょう。

実行前に「計画書」を出すかどうかの違い

Planningモード最大の特徴は、AIが実際にコードを書く前に「これから何をするか」という計画書を提示することです。AIは指示を受けると、まずプロジェクト全体を見渡し、必要なファイルの作成や修正の手順を箇条書きでまとめます。

人間はその計画を見て、納得がいけば「Approve（承認）」ボタンを押して作業を開始させます。一方のFastモードは、この計画プロセスを一切省きます。指示を出した瞬間、AIが迷わずファイルの中身を書き換え始めるため、待ち時間がほとんどありません。

AIが考える時間の長さと精度の関係

Planningモードは、いわば「熟考タイプ」です。複雑な指示に対しても、複数の解決策を比較検討してから最も安全な道を選びます。そのため、時間はかかりますが「うっかり別の場所を壊してしまった」というミスが起きにくいのがメリットです。

対するFastモードは「反射タイプ」です。簡単な修正なら数秒で終わらせますが、複雑なロジックを任せると、前後の文脈を無視した不自然なコードを書いてしまうこともあります。スピード重視の場面では頼りになりますが、正確性ではPlanningに軍配が上がります。

1回あたりの利用枠（クォータ）の減り方

Antigravityには、プランごとにAIを使える回数（利用枠）が決まっています。Planningモードは高度な推論を行うため、1回の指示で消費される「ポイント」のようなものがFastモードよりも多くなる傾向にあります。

Planning：消費量が多く、制限に達しやすい
Fast：消費量が少なく、サクサク使える

無料プランを使っている場合、何でもPlanningで頼んでしまうと、すぐに週間制限に達してしまいます。簡単な作業はFast、大事な設計はPlanningというメリハリが、長く使い続けるためのコツです。

比較項目	Planningモード	Fastモード
主な特徴	計画を立ててから実行	即座に書き換える
得意なこと	大規模な新機能の実装	単純な修正やテスト
精度	非常に高い	普通〜高い
速度	準備に時間がかかる	爆速
消費枠	多い	少ない

Planningモードで慎重に進めるべき3つのケース

Planningモードは、プロジェクトの「根幹」に関わる作業に向いています。AIに丸投げするのではなく、AIと一緒に設計図を確認しながら進めることで、手戻りの少ない開発が可能になります。

具体的に、どのような場面でこの慎重なモードを選ぶべきか、3つのシチュエーションを紹介します。

新しく機能を追加するとき

「新しくお気に入り登録機能を付けて」といった、ゼロから何かを生み出す作業はPlanningの独壇場です。DBのテーブル設計、サーバーサイドの処理、フロントエンドの表示など、やるべきことが多岐にわたるからです。

計画書を見れば「あ、このライブラリは使わないでほしいな」といった修正が、実作業の前にできます。もしFastモードでいきなり作らせると、自分のイメージと違う方向に突き進んでしまい、後から直すのが大変になることもあります。

複数のファイルに影響が出る修正をするとき

一つの変更が、プロジェクト内のあちこちに影響を及ぼすような作業も注意が必要です。例えば「ユーザーの名前を表示する共通パーツの仕様を変える」といった場合、Planningモードなら関連するすべてのファイルを漏れなくリストアップしてくれます。

「ここを直すと、あっちのページが動かなくなるかもしれない」といったリスクも計画段階で指摘してくれるため、大きなトラブルを未然に防げます。複雑な依存関係がある大規模なアプリほど、Planningの恩恵は大きくなります。

エラーの原因が特定できていないとき

「なぜか動かないけど、どこが悪いのかさっぱりわからない」というバグ調査にもPlanningが適しています。AIはエラーログを読み込み、怪しい箇所をいくつか挙げ、それらを順番に検証する計画を立てます。

闇雲にコードをいじって傷口を広げるのではなく、論理的な手順で原因を潰していけるのが強みです。内蔵ブラウザで実際に画面を動かしながら、一歩ずつ正解に近づいていく様子は、まるでベテランエンジニアが横にいるような安心感があります。

Fastモードでサクサク進めるのが正解な場面

一方で、わざわざ計画を立てるまでもない「ちょっとした用事」は、Fastモードで瞬時に終わらせましょう。開発のリズムを崩さず、集中力を維持するためには、このスピード感が欠かせません。

Fastモードを最大限に活かせる、具体的な3つの場面を見ていきましょう。

コードの書き間違いやタイポを直す

変数名の打ち間違いや、閉じカッコの忘れといった単純なミスは、Fastモードの得意分野です。指示を出してから計画を待つ必要はありません。「ここ直して」と伝えるだけで、一瞬で正しいコードに置き換わります。

こうした軽微な修正にPlanningを使うのは、時間の無駄と言っても過言ではありません。短い指示で完結するタスクであれば、Fastモードの方が圧倒的にストレスなく作業を進められます。

単純なテストコードを量産する

「この関数のテストをJestで書いて」といった、パターンが決まっている作業もFastモードに向いています。テストコードは構造が決まっていることが多いため、AIが迷う要素が少なく、高速に生成できます。

正常系のテストを作る
エラー時の処理を確認する
境界値のテストを加える

これらを一つずつFastモードで依頼していけば、ものの数分でテストカバレッジを引き上げることが可能です。退屈なルーチンワークを爆速で終わらせる快感は、Fastモードならではです。

CSSやデザインの微調整を繰り返す

「文字をもう少し大きくして」「余白を10px空けて」といった、見た目の調整は試行錯誤がつきものです。修正しては画面を確認し、また少し変えるというサイクルを何度も回す必要があります。

Planningモードだと、その都度「計画→承認→実行」というステップを挟むため、リズムが非常に悪くなります。Fastモードなら、指示した瞬間に画面が変わるため、自分の手でCSSをいじっているような感覚で、直感的にデザインを追い込めます。

どちらのモードを選ぶ？迷ったときの判断基準

モードの特性はわかっても、いざ目の前の作業をどちらで進めるか迷うこともあるはずです。そのときは、以下の3つの基準に照らし合わせてみてください。

これらを意識するだけで、無駄な待ち時間や利用枠の浪費を劇的に減らすことができます。

タスクの「影響範囲」が広いかどうか

その指示によって、いくつのファイルが書き換わるかを想像してみましょう。

1つのファイル内で完結するならFast、3つ以上のファイルにまたがるならPlanningを選ぶのが安全な境界線です。影響範囲が広いほど、AIが矛盾したコードを書くリスクが高まるため、計画段階でのチェックが欠かせません。

AIに「自律的なテスト」を任せたいか

Antigravityの目玉機能である「AIが自分でブラウザを動かして確認する」機能を使いたいなら、Planningモード一択です。

Planningでは「コードを書く→ブラウザを起動する→動作を確認する→ダメなら直す」という一連の流れを一つのプランとして組み立てます。Fastモードは基本的に「書くだけ」で終わってしまうことが多いため、最後まで責任を持って動かしてほしいときはPlanningを選びましょう。

自分でコードを書き換える手間を許容できるか

もしAIが間違ったときに「自分でサッと直せばいいや」と思える程度の作業なら、まずはFastモードで試すのが効率的です。

逆に、自分で直すのが難しいような高度なアルゴリズムや、不慣れな言語のコードを書かせる場合は、最初からPlanningでじっくり考えてもらった方が、結果的に近道になります。自分のスキルレベルに合わせてモードを使い分けるのも、賢い方法です。

効率を最大化する！2つのモードを組み合わせる手順

上級者のエンジニアは、一つのタスクの中で2つのモードを巧みに使い分けます。最初から最後まで同じモードで突き進む必要はありません。

開発のフェーズに合わせてギアを変える、理想的なフローを紹介します。

Planningで土台を作りFastで細部を整える

まず、新しい機能を実装する際は、Planningモードでしっかりとした骨組みを作ってもらいます。AIが作成した計画を承認し、一通りの機能が動く状態まで持っていきます。

全体の形ができあがった後は、Fastモードに切り替えます。「このボタンの文言を変えて」「このアイコンの色を青にして」といった細かい微調整は、Fastモードでテンポよく進めるのが最も効率的です。

エージェントごとにモードを使い分ける方法

Antigravityでは、複数の「エージェント（作業担当者）」を同時に立ち上げることができます。例えば、一つのエージェントにはPlanningモードで重たいバグ修正を任せ、その待ち時間の間に、別のエージェントをFastモードで起動して、簡単なドキュメント作成を依頼するといったことが可能です。

待ち時間を有効活用できるため、まるで自分を分身させて作業しているような感覚になります。手持ち無沙汰な時間をゼロにする、マルチタスクの醍醐味です。

指示を出すプロンプトの書き方を変えてみる

モードに合わせて、こちらが出す指示（プロンプト）の書き方も変えてみましょう。

Planningへの指示：「〇〇機能を実装したい。DB設計を含めて、影響範囲を考慮した安全なプランを立てて」
Fastへの指示：「この関数の戻り値を数値型から文字列型に変更して。今すぐ反映して」

Planningには「文脈」を、Fastには「結論」を伝えるのがコツです。AIの思考の深さに合わせた言葉選びをすることで、それぞれのモードの良さを引き出せます。

モードを切り替えるときに注意したいこと

非常に便利な2つのモードですが、使い方の落とし穴もいくつか存在します。思わぬ失敗で時間を無駄にしないために、以下の3点には気をつけておきましょう。

特に、作業をAIに任せて席を外すときなどは、今のモードがどちらになっているかの確認が重要です。

Planningモードで「承認」を忘れて放置しない

Planningモードで一番多い失敗が、指示だけ出して満足し、計画書の作成完了に気づかないことです。AIが完璧なプランを用意していても、人間が「Approve」を押さない限り、1行もコードは書かれません。

「全然進まないな」と思ったら、AIがあなたの承認を待っていないか確認しましょう。コーヒーを淹れに行く前に承認ボタンを押す、という習慣をつけるのがおすすめです。

Fastモードによる予期せぬコード書き換えを防ぐ

Fastモードは、承認ステップがない分、AIが間違った判断で大切なコードを消してしまうリスクもゼロではありません。

特に、GitHubなどでバージョン管理をしていない状態でFastモードを連発するのは危険です。万が一に備えて、大きな変更をFastモードで行う前には、必ずコードをコミット（保存）しておくか、バックアップを取っておくようにしましょう。

ネットワーク環境が不安定なときの挙動

Planningモードは、Fastモードよりも多くの通信を行います。カフェのWi-Fiなどで電波が不安定なときにPlanningを使うと、計画作成の途中で接続が切れてしまい、最初からやり直しになることがあります。

通信環境が良くないときは、なるべく通信量の少ないFastモードで細かく指示を出すか、オフラインでも書ける作業に専念するのが無難です。

利用枠（クォータ）を節約するための使い分け術

Antigravityの強力なAIを、一ヶ月間フルで使い倒すためには、利用枠の節約術が欠かせません。特に無料プランやProプランを使っているユーザーにとって、これは死活問題です。

限られたリソースの中で、最大限の成果を出すための3つの工夫をまとめました。

無料プランで長く使うための工夫

無料プランの制限は週間単位でリセットされます。月曜日や火曜日にPlanningを使いすぎると、週末にはAIが全く動かなくなってしまうことも。

週の前半は自分で考えながらFastモードで地道に作り、週の後半に溜まった難しい課題を一気にPlanningで解決する、といった「利用枠の予算管理」を意識してみてください。

無駄な思考をさせないための指示出しのコツ

AIに余計なことを考えさせないことも節約に繋がります。Planningを使うときでも「今回のタスクはフロントエンドの修正だけだから、バックエンドのファイルは読み込まなくていいよ」と範囲を限定してあげましょう。

探索する範囲が狭まれば、AIの思考コスト（トークン）が抑えられ、利用枠の減り方を緩やかにできます。

どちらでも解決できるならFastを選ぶ理由

「どっちのモードでもできそうだな」と迷ったときは、ひとまずFastを選びましょう。

もしFastで失敗しても、そこからPlanningでやり直すことはできますが、最初からPlanningを使って枠を浪費してしまうと、後で「Fastで十分だった」と後悔しても枠は戻ってきません。まずは「軽い方」から試すのが、賢いエンジニアの戦略です。

シチュエーション	推奨モード	理由
プロジェクトの初期構築	Planning	土台作りでのミスは致命的だから
既存コードのバグ修正	Planning	根本的な原因を突き止める必要があるから
ユニットテストの追加	Fast	パターンが決まっていて思考が不要だから
デザインの微調整	Fast	何度も試して画面を確認したいから