Antigravity Planning Mode vs Fast Mode 徹底比較：プロジェクト規模別の最適な使い分け

Antigravityの最大の特徴の一つが、Planning Mode と Fast Mode という2つの実行モードです。同じAI開発ツールでも、この2つのモードを使い分けるだけで、生産性は劇的に向上します。

Planning Modeの全貌：計画→確認→実行

Planning Modeは、Antigravityの最も強力な機能です。Google Docsのような対話的な検証環境で、AIが提案した内容をコメント・フィードバック通じて調整してから、実際のコード実行に進みます。

Artifactsという仮想成果物

Planning Modeで重要な役割を担うのが Artifacts です。これはタスク実行前に生成される「仮想の成果物」で、以下のような形態があります：

• Task Lists：やることリストの自動生成と優先度付け
• Implementation Plans：段階的な実装手順の詳細設計
• Architecture Diagrams：システム構成や処理フローの図解
• Screenshots：UIデザインのプレビュー

これらのArtifactsは、実装前に「本当に正しい方向か」「抜け漏れがないか」を人間視点で検証できます。Google Docsと同じように、ArtifactのコメントやフィードバックをAIが読み取り、修正版を生成します。

Planning Modeの実行フロー

1. 目的を明確に述べる：「リアルタイム通知機能を実装したい」「既存APIを新バージョンに移行したい」など
2. AIが計画を提案：タスク分解、成果物イメージ、所要時間の見積もり
3. フィードバック→修正ループ：「このステップはもっと簡潔にできない？」「この部分の優先度を上げてほしい」
4. 最終確認後に実行：すべてに納得したら、AIが実装を進める

Fast Modeの特徴：迅速性と直感性

Fast Modeは、Planning Modeとは対照的に「さっさと実行する」がコンセプトです。AIの推論チェーンをコンパクトに保ち、すぐに結果を出します。

Fast Modeが活躍するシーン

以下のような軽めのタスクでは、Planning Modeのプロセスが却って足かせになります：

• 1〜3行程度の修正：変数名の統一、スペルミスの修正、1行関数の追加
• テストコードの自動生成：既存ロジックに対する単体テストの素早い生成
• ドキュメント更新：READMEやコメントの追加・修正
• 簡単なデバッグ：明確なエラーメッセージに対する即座の対応

Fast Modeは「確認プロセスなし」ではなく、「最小限の推論で十分なタスク」を想定した設計です。そのため推論時間が短く、結果も素早く返ってきます。

実務的な使い分けフレームワーク

ここからが最も実用的な部分です。どうやって2つのモードを選び分けるのか。

新規ファイル作成は Planning Mode

新しいファイルを一から書く場合、特に仕様が複雑な場合は、Planning Mode一択です。

例：REST APIエンドポイント + データベーススキーマの実装

この場合、データモデルの設計、エラーハンドリングの仕様、認証の流れなど、考慮すべき要素が多数あります。事前にArtifactで設計を見える化し、「この仕様でいい？」を確認してから実装に進むべきです。

スキーマ・データベース変更は Planning Mode

データベーススキーマの追加・変更も Planning Mode が適切です。一度データベースに影響を与えると、ロールバックが複雑になるからです。

Planning Modeなら、カラム追加時のマイグレーション手順、既存データとの整合性確保、インデックス設計などを事前確認できます。

初期機能実装後の微調整は Fast Mode へ

最初の実装を Planning Mode で終えたら、その後の細かな改善は Fast Mode に切り替えるのが効率的です。

Planning Mode：ログイン機能を一から実装
  ↓
Fast Mode：パスワード検証ロジックを強化
  ↓
Fast Mode：エラーメッセージの文言を調整

このように段階的に、大きな決定は Planning、小さな改善は Fast というリズムが理想的です。

実践例：複雑なプロジェクトでの組み合わせ

では、より現実的なシナリオで考えてみます。

シナリオ：既存Webアプリケーションに AI チャット機能を追加

フェーズ1：Planning Mode

• 既存のユーザー認証システムとの統合方法
• チャット履歴の保存先（DB or Vector DB）
• レート制限の仕様
• フロントエンドUIのモック画像

これらを Planning Mode で事前確認します。

フェーズ2：Planning Mode（パート2）

• APIエンドポイントの実装計画

フェーズ3：Fast Mode

• エンドポイントの細かい修正
• エラーハンドリングの追加
• ログ出力の改善

このように大きな判断はPlanning、小さな調整はFastという使い分けが、最も時間効率が良いです。

パフォーマンスと時間比較

実際のところ、Planning Mode と Fast Mode でどのくらい時間が変わるのか。

単純なタスクでは Fast Mode の相応の速さが際立ちます。一方、複雑さが増すと Planning Mode がその価値を発揮します。

実装例：Planning Mode でのコメントフィードバック

Planning Mode を最大活用するには、AIへのコメント方法が重要です。

悪い例：「これ、もっと簡潔にできます」

良い例：「このタスクリストの順序を、
スキーマ設計 → マイグレーション → テスト作成 に変えてほしいです。
理由は、スキーマが定まらないと他のタスクが進まないからです」

具体的な理由を添えることで、AIの修正精度がぐんと上がります。

Planning Mode → Fast Mode への移行タイミング

プロジェクトが進むにつれて、同じ部分でも使い分けが変わります。

• 初期段階：すべて Planning Mode（基盤作り）
• 成長段階：Planning と Fast を混在（大きな変更だけ Planning）
• 保守段階：ほぼ Fast Mode（バグ修正・微調整がメイン）

このダイナミクスを理解すると、プロジェクト全体の効率が向上します。

作業の途中でモードを切り替えるサイン — Fast で詰まる瞬間を見抜く

プロジェクトの段階で大まかに決めたあとも、ひとつのタスクの最中にモードを切り替えるべき瞬間が訪れます。これは事前の計画では決められません。手を動かしながら気づくものです。

Fast Mode で始めた修正が、三度目の依頼に入ったら、それは Planning へ切り替えるサインです。同じ箇所を直し続けているとき、AI は全体像を持たないまま目先のズレだけを埋めています。一度立ち止まって、Planning でタスクの並びを描き直したほうが、結果的に早く着地します。

ひとつの修正が別の場所を壊す連鎖が出たときも同じです。これは設計の前提が共有できていない合図です。Fast のまま追いかけると、壊した分をまた Fast で直す堂々巡りになります。Planning に移し、影響範囲を Artifact で見える化してから進めてください。

逆に、Planning Mode で計画の確認に時間をかけすぎていると感じることもあります。Artifact のコメント往復が三回を超えても合意に近づかないなら、それはタスクが十分に小さい証拠です。思い切って Fast で実行してしまったほうが速い場合があります。

判断の軸はひとつです。「次の一手が予測できるか」。予測できるなら Fast、予測の前に整理が要るなら Planning。この問いを作業中に何度も自分へ向けると、切り替えの精度が上がります。

コストの見え方も変わります。2つのモードの違いは、速度というより推論の往復回数の違いです。Fast で詰まって五回やり直すより、Planning で一度きちんと計画したほうが、消費する手数が少なく済む場面は少なくありません。速いモードが、いつも安いとは限らないのです。

私自身、個人開発で Dolice Labs のブログ運用を回しているとき、小さな文言修正は Fast、記事生成パイプラインの構造を変えるときは Planning、と無意識に切り替えていました。けれど振り返ると、いちばん時間を溶かしていたのは「Fast で押し切ろうとして三回直した」場面でした。詰まった回数こそが、モードを間違えたサインだったのだと、今は感じています。

全体を振り返って：使い分けで Antigravity の力を最大化

Planning Mode と Fast Mode は「どちらが優れている」のではなく、「目的によって使い分ける」設計です。

• Planning Mode：新機能、スキーマ変更、重要な設計判断
• Fast Mode：バグ修正、テスト生成、軽い修正

この違いを理解し、プロジェクトの段階に応じて柔軟に切り替えることで、Antigravity の真価が引き出せます。今度のプロジェクトで、ぜひ意識的に使い分けてみてください。