はじめに

Google Antigravityに初めて触れたとき、これまで他のAIエージェントツールで感じていたもどかしさが一気に解消された感覚だった。

近年、Cursor、Windsurf、GitHub Copilot Workspaceなど、様々なAI支援ツールを試してきた。どれも確かに便利だった。しかし、どこか「痒いところに手が届かない」感覚があった。コード補完は優秀だが、複雑なリファクタリングになると途端に使い物にならない。エージェント機能を謳っていても、結局は人間が細かく指示を出し続ける必要がある。本当の意味での「委任」はできなかった。

Antigravityは違った。Manager SurfaceとEditor Viewという明確に分離された操作面を持ち、「認証モジュール全体をJWTベースに書き換えろ」といった高レベルの目標を与えると、エージェントが自律的にリポジトリを調査し、計画を立て、実装し、検証までやり遂げる。しかも、その思考プロセスが「Artifacts」として可視化される。この設計は、他のツールとは根本的に異なっていた。

ただし、この力を最大限に引き出すには、使い方を理解する必要があった。Planning ModeとFast Mode、どちらを使うべきか。セキュリティ設定はどうするか。チームでどう運用するか。初期段階での試行錯誤を経て、ようやく体系的なフレームワークが見えてきた。

本稿は、Antigravityを使ってより高度なことをより早く実現したいエンジニアのための、実践的なガイドである。

他のツールとの決定的な違い

Cursorや他のエージェントツールを使っていて感じていた限界は、主に3つあった。

一つ目は、コンテキストの理解範囲。多くのツールは現在のファイルや周辺のコードには強いが、プロジェクト全体の構造を理解するのが苦手だった。大規模リファクタリングを依頼すると、必ずどこかで依存関係を見落とし、コンパイルエラーを起こす。

二つ目は、思考プロセスの不透明さ。エージェントが何を考えて、どういう判断でそのコードを生成したのか分からない。結果だけが提示されるため、レビューする側は常に不安を抱えながらコードを読むことになる。

三つ目は、自律性の欠如。「次は何をすればいいですか？」と頻繁に聞いてくる。本来委任したはずのタスクなのに、結局は人間が細かくステップを指示し続ける必要がある。

Antigravityはこれらをすべて解決していた。Gemini 3 Proの強力なコンテキスト理解能力により、リポジトリ全体を俯瞰した判断ができる。Planning Modeでは、Task PlanとImplementation Planという形で思考プロセスが外在化される。そして何より、本当の意味での自律実行が可能だった。

初めて複雑なリファクタリングをPlanning Modeで実行させたとき、エージェントが生成したImplementation Planを見て驚いた。依存関係を完全に把握し、変更が必要なファイルを漏れなくリストアップし、さらに変更の順序まで最適化されていた。これは他のツールでは実現できなかったことだった。

二つのモード：システム1とシステム2

Antigravityの本質を理解する鍵は、Planning ModeとFast Modeの使い分けにある。これは単なる速度の違いではなく、認知科学でいう「システム1」と「システム2」の違いだと理解したとき、すべてが腑に落ちた。

Fast Modeは直感的で高速な思考。プロンプトに対して、学習済みデータの統計的パターンに基づき即座に反応する。中間的な計画策定をスキップし、直接的にコードを生成する。主に現在開いているファイルや明示的に指定されたコンテキストに依存する。速いが、全体を俯瞰する視点は弱い。

Planning Modeは論理的で熟慮的な思考。Gemini 3 Proの「Deep Think」機能を活用し、強化学習で最適化された複雑な推論チェーンを実行する。コードを書く前に、タスクを理解し、リポジトリ全体を調査し、実行すべき手順を構造化する。そして重要なのは、その思考プロセスが「Artifacts」として可視化されることだ。

この区別を理解してから、使い方が劇的に変わった。単純なタスクにPlanning Modeを使っていた無駄がなくなり、逆に複雑なタスクでFast Modeを使って失敗することもなくなった。

コストと品質のトレードオフとして捉えると分かりやすい。Fast Modeは低コスト（トークン消費少、時間短）で低品質リスク。Planning Modeは高コスト（トークン消費多、時間長）で高品質。すべてのタスクにPlanning Modeを使うのは資源の浪費だし、逆に重要なタスクをFast Modeで処理するのはリスクが高い。

この「認知的ディスパッチ」を体系化する必要があった。

4象限マトリクス：実践的な判断基準

個人の感覚に頼るのではなく、チームで共有できる判断基準が欲しかった。そこで構築したのが、「タスクの複雑性」と「リスク・影響範囲」の二軸による4象限マトリクスだ。

第1象限は低複雑性・低リスク。JSONのパース、変数のリネーミング、ドキュメントの誤字修正など。失敗してもすぐに戻せる領域。ここはFast Mode一択だ。Terminal PolicyをTurboに設定し、Review PolicyはAlways Proceedにする。エージェントに自律的に試行錯誤させ、Linterやコンパイラのエラーをフィードバックとして活用させる。人間は最終結果だけを確認する。

初期段階では、こういう単純なタスクにもPlanning Modeを使っていた。「慎重であることは良いこと」という思い込みがあったが、これは明らかに過剰だった。変数のリネームに詳細な計画書は不要だ。Fast Modeで十分であり、その方が開発のリズムも保たれる。

第2象限は高複雑性・低リスク。新しいライブラリの評価、ベストプラクティスの調査、レガシーコードの解析など。探索的なタスクで、失敗しても影響は限定的。ここではPlanning Modeを使う。Terminal PolicyをAutoに設定し、Review PolicyはAgent Decidesにする。

ここでのAntigravityの真価は凄まじい。例えば「Next.jsとSupabaseで認証フローを実装する際のベストプラクティスを調査し、実装の雛形を作れ」と指示すると、エージェントはWeb検索を駆使して最新のドキュメントを調査し、複数のアプローチを比較検討し、プロジェクトの文脈に最適な実装案を提示する。これは従来、人間が数時間かけて行っていた作業だ。

生成されたTask PlanやImplementation Planを読むこと自体が学習になる。エージェントの思考プロセスを追うことで、自分自身の理解も深まる。

第3象限は高複雑性・高リスク。システムの根幹に関わる変更。APIの認証方式の全面刷新、メジャーバージョンアップ、決済処理のリファクタリングなど。ここで最も慎重になる必要がある。

Planning Modeを使用し、Terminal PolicyをOffに設定してAllow Listのコマンドのみを許可する。Review PolicyはRequest Reviewとし、すべてのステップで人間の承認を必須とする。

ここでのAntigravityの威力は、他のツールとの差が最も顕著になる部分だ。例えばOAuth2からJWTへの認証方式変更を指示すると、エージェントはまずリポジトリ全体を調査し、影響を受けるすべてのエンドポイント、ミドルウェア、テストコードをリストアップする。そして変更の順序を最適化し、各ステップでの検証方法まで提示する。Implementation Plan Artifactは、まるで経験豊富なシニアエンジニアが書いた設計書のようだ。

この計画書を精査することで、「幻覚的インポート」（存在しないライブラリの参照）や循環参照のリスクを事前に検出できる。そしてエージェントが提示するWalkthrough（検証記録）が、品質ゲートとして機能する。チーム内でこれを義務化してから、重大なバグの本番混入が激減した。

第4象限は低複雑性・高リスク。本番環境の環境変数更新、セキュリティパッチの適用、ホットフィックスなど。作業は単純だが、対象が重要。

ここではFast Modeを使う。タスクの単純さからPlanning Modeのオーバーヘッドは不要だが、リスクの高さから自動実行は許容できない。Terminal PolicyをOffに設定し、Review PolicyはRequest Reviewにする。エージェントが生成したdiffを1行ずつ検証し、コマンド実行も明示的に許可する。

本番環境に触れる際は、タスクの単純さに関わらずこのプロトコルを徹底している。

Artifacts：可視化された契約

Planning Modeが生成する「Artifacts」は、Antigravityの最も革新的な機能の一つだ。他のツールにはない、この機能こそが「信頼のギャップ」を埋める鍵となる。

Task Plan Artifactは、エージェントが理解したタスクと解決手順の明示だ。これを見ることで「スコープ・クリープ」を未然に防げる。エージェントが要求範囲を逸脱していないか、手順に論理的な飛躍がないかを確認する。計画段階で誤りを発見すれば、実装前に軌道修正できる。

このレビューを徹底してから、「なぜこのファイルが変更されているのか」という疑問がなくなった。すべてが計画書に明記されているからだ。

Implementation Plan Artifactは、具体的な変更内容を記述した技術設計書だ。どのファイルのどの関数をどう変更するか、新しいファイル構造はどうなるか。これによって「アーキテクチャ整合性」を担保する。

このArtifactに対してコメントを付与することで、エージェントの設計を修正できる。「このインポートは存在しない」「このパターンではなく既存のアーキテクチャに従うべき」といった指摘を加えると、エージェントは理解して設計を修正する。これは従来のコードレビューよりも上流工程での品質担保を可能にする、画期的な仕組みだ。

Walkthrough / Verification Artifactは、実装後の動作確認記録だ。ブラウザ操作のスクリーンショット、録画、テスト実行のログなど。エージェントは「完了しました」と報告するだけでなく、実際に動作している証拠を提示する。

この確認を徹底してから、レビュー時の不安が大幅に軽減された。コードを読むだけでは分からない動作の詳細が、視覚的に確認できる。

運用での重要な原則

運用を通じて、いくつかの重要な原則が見えてきた。

Fast Modeでの曖昧なプロンプトの反復は、コンテキストを汚染し推論品質を劣化させる。エラーが2回続いたら、アプローチそのものが誤っていると判断し、コンテキストをクリアして新しいセッションを開始する「2ストライク・ルール」が有効だ。

大規模リファクタリングでは、Planning Modeを使用し、「依存関係グラフを描画し、循環参照がないことを確認せよ」と明示的に指示する。Fast Modeは逐次的な処理になるため、全体の依存関係グラフを俯瞰できない。Planning Modeでエージェントにグラフ構造を生成させ、それを検証してから実装に進むことで、構造的な問題を事前に検出できる。これはAntigravityならではの強みだ。

セキュリティ設定：安全性と生産性の両立

Antigravityの力を最大限に引き出すには、適切なセキュリティ設定が不可欠だ。

Terminal Execution Policyは、エージェントによるコマンド実行を制御する。Offは最もセキュアで、Allow Listのコマンドのみを許可する。Autoはエージェントの判断に委ねる。Turboは最速で、Deny Listのコマンド以外をすべて許可する。

重要なのは、Allow ListとDeny Listの本質的な違いだ。Allow List（ポジティブセキュリティ）は、ls、grep、cat、git status、pytest、npm testといった安全なコマンドのみを許可する。これは未知の攻撃やエージェントの誤動作を確実に防ぐ。

Deny List（ネガティブセキュリティ）は、rm、sudo、curlなどを禁止するが、これは本質的に脆弱だ。エージェントは難読化によってこれを回避できる。base64エンコードされた文字列をデコードして実行するコマンドは、単純な文字列マッチングのDeny Listをすり抜ける。セキュリティの主要な防御手段としてDeny Listに依存すべきではない。

Browser Allowlistも重要だ。~/.gemini/antigravity/browserAllowlist.txtに、github.com、stackoverflow.com、公式ドキュメントなど、信頼できるドメインのみを登録する。これにより「プロンプト・インジェクション」のリスクを軽減できる。悪意のあるWebサイトに隠されたテキストによって、エージェントが乗っ取られる可能性があるからだ。

Review Policyは、エージェントの自律性を制御する。Always Proceed（承認なし）、Agent Decides（不確実な場合のみ問い合わせ）、Request Review（常に承認必須）をタスクに応じて使い分ける。

チーム運用：組織的な活用

個人レベルでの最適化を超え、チーム全体で活用するための標準化が必要だった。

.antigravity/ディレクトリを活用し、プロジェクト単位でエージェントの挙動を統一した。mcp_servers.jsonで社内APIドキュメント検索用サーバーなどの独自MCPサーバーを設定し、.antigravity/rules.mdにプロジェクト固有のコーディング規約を自然言語で記述する。

この標準化により、チームメンバー間でエージェントの出力が統一された。各自が独自のプロンプト戦略を用いていた初期段階では、レビュー時の認知負荷が高かったが、標準化後は予測可能性が向上し、レビューの効率が改善された。

コードレビューのプロセスも変化した。従来の「コードの書き方」に焦点を当てたレビューから、「プロンプトの適切性」と「Artifactsの妥当性」に焦点を当てたレビューへ。Pull Requestには、生成されたコードだけでなく、Implementation PlanへのリンクとVerification Artifactを添付することを義務化した。

これによりレビューの質が向上した。計画書を参照することで設計意図が明確になり、レビューコメントも「このコードは不適切」から「この計画では依存関係に問題がある」といった、より構造的な指摘に変化した。

より高度なことを、より早く

Google Antigravityは、エンジニアリングの新しい地平を開いた。他のAIツールでは実現できなかった、真の意味での「委任」が可能になった。

Fast Modeの反射的実行とPlanning Modeの熟慮的実行を適切に使い分ける4象限マトリクスは、この力を最大限に引き出すための実践的フレームワークだ。システム1とシステム2を適切にオーケストレーションすることで、従来では考えられなかった速度と品質でソフトウェアを構築できる。

Artifactsによって思考プロセスが可視化され、Allow Listによってセキュリティが担保され、人間が最終的な意思決定者として機能する。これが実現できているのは、Antigravityの設計が根本的に優れているからだ。

ただし、これは単に導入すれば使えるツールではない。適切な設定、適切なモード選択、適切なレビュープロセスを確立して初めて、その真価を発揮する。本稿で示したフレームワークは、その確立のための指針だ。

20年以上のキャリアで様々なツールを使ってきたが、Antigravityは間違いなく最もエキサイティングなものだ。これは単なる生産性向上ツールではなく、エンジニアリングのあり方そのものを変えるツールだ。

開発者の役割は「コーダー」から「アーキテクト」へ、そして「オーケストレーター」へと変化している。より高度な問題に集中し、より大きな価値を生み出す。Antigravityは、その変化を可能にする。

そしてこれは、始まりに過ぎない。このツールの可能性は、まだ十分に探索されていない。より高度なことを、より早く実現するために。それがこの記事を書いた理由であり、同じ志を持つエンジニアたちと知見を共有したいと考えている。