Google Antigravity を使い込んで感じた5つの活用ポイント
はじめに
こんにちは、すらぼです。
この記事は クラスメソッド × AI駆動開発 Advent Calendar 2025 10日目の記事です。
11/18（米国時間）、Google Antigravity （以降 Antigravity）がパブリックプレビューとしてリリースされました。
さらに先日有料プランも公開されたことで、無料利用のときよりも Rate Limit を気にしなくて良くなり、実際の開発でも徐々に活用できるようになってきました。
その中で私自身いろいろ使い込んでみた結果、Antigravity の活用のためのポイントが少し見えてきたので紹介したいと思います。
筆者の環境
- ホストOS(CPU)：macOS（M4）
- Google One プラン: Google AI Pro
- メインで使用しているツール
- AIツール：Claude Code
- エディタ：VS Code
活用のポイント
おおまかに、以下の観点で活用のポイントを整理していきます。
- ユーザー承認の制御
- 思考モードの使い分け
- モデルの使い分け
- DevContainer の活用
- Customizations でのグローバル指示
1. ユーザー承認の制御
Antigravity では、以下の項目でユーザー許可を求める度合いを設定できます。
どちらの項目も「全部許可制」「エージェント判断」「すべて許可不要」の3段階から選べます。（オプションの名前は異なるためご注意ください。）
- Artifact Review Policy
- アーティファクトのレビューを要求するかどうか
- Terminal Command Auto Execution
- コマンドの実行の許可を求めるかどうか
アーティファクトとは、Antigravity がタスクや方針などのプランを立てたり、作業が完了した後の説明書などの成果物を指します。
個人的には、おすすめの設定はそれぞれ以下の通りです。
Artifact Review Policy
これは Request Review （レビュー必須）を使用しています。
理由は大きく3つあります。
- 設計段階などで、早めのレビューをした方が修正を減らせる。
- タイミングが最初と最後に寄るので、必須にしても手間・ストレスが少ない。
- 作業の実行前にモデルが変更できる（最重要）
1, 2に関しては一般的なプロジェクトと同様なので理解しやすいと思います。
最も重要なのは 3 です。計画を立てるときに使うモデルは基本的に思考型のモデルであり、レスポンスまでに時間がかかります。また、Rate Limit に到達するのも早いため、十分な余裕が無い限り実装中に使うのにはあまり向きません。そのため、設計が終わったら、タスクを遂行するのに適したモデルに切り替えるという方法を取っています。（具体的なモデルの使い分けについては後述します。）
Terminal Command Auto Execution
コマンド実行の許可については、 Auto を使用しています。このオプションに設定すると、一部コマンドは自動実行、リスクのあるコマンドはユーザーに許可を求めるようになります。
このオプションの嬉しいポイントは、Read 系のコマンドなどはユーザーに承認を求めずに実行しつつ、ファイルの削除やGit操作などリスクを伴うコマンドや不可逆な操作はユーザーの許可を求めてくれる点です。AI判断であるためリスクは伴いますが、筆者の場合は DevContainer など独立した環境内で実行することでリスクを軽減しています。
コマンド実行の挙動については、以前調査した記事があるので気になる方は確認してみてください。
2. 思考モードの使い分け
- Fast
- 指示に対して、ほぼ1アクションで処理を停止する。
- アーティファクトを 生成しない。
- Plan → アクションではなく、直接アクションを実行。
- 簡単なセットアップを試してほしいとき、簡単な質問に答えてほしいときなどに有効。
- その特徴から、手を動かし続けることには不向き。トライアンドエラーを繰り返すプロセスには向いていない。
- Planning
- 指示に対して、計画を立ててからタスクを実行する。また、計画に沿って実行し続ける。
- Task, Implementation Plan などのアーティファクトは Planning でのみ生成される。
- 具体的な実装は基本的にこちら。また、クラウドインフラの構築やデプロイなど、エラーが出やすいポイントもこちらの方が向いている。
この2つのモードは、「賢さ」というよりは「回答のスタンス」を定めるパラメータとして解釈するのが良さそうです。
個人的には、Planning を使うケースが9割です。 Fast を使うのが向いているのは「コマンド教えて」くらいの些細なタスクで、ほとんど使いません。
3. モデルの使い分け
執筆時点で選択できるモデルには、以下のものがあります。
- Gemini 3 Pro (High)
- Gemini 3 Pro (Low)
- Claude Sonnet 4.5
- Claude Sonnet 4.5 (Thinking)
- Claude Opus 4.5 (Thinking)
- GPT-OSS 120B (Medium)
この中でも筆者が使っているのは Gemini のため、Gemini の2つに関して紹介します。
Gemini に関してはどちらもモデルは Gemini 3 Pro で、Hight と Low があるのでこれを切り替えます。
Gemini API リファレンスの記述を引用すると、それぞれの特徴は以下の通りです。
low: レイテンシと費用を最小限に抑えます。簡単な指示の実行、チャット、高スループット アプリケーションに最適
high（デフォルト）: 推論の深さを最大化します。最初のトークンに到達するまでに時間がかかることがありますが、出力はより慎重に推論されます。
https://ai.google.dev/gemini-api/docs/gemini-3?hl=ja#thinking_level
high は熟考タイプです。最初のプランを作るときはこちらが適している感覚です。一方で、レスポンスが帰ってくるまでの時間が長いです。そのため私は、設計を high で行い、設計が終わった後の実装は low を使用しています。
low と Planning と合わせることで、継続的な処理でも素早いトライアンドエラーが実行され、尚且つ継続的な作業を遂行させることができます。
4. DevContainer の活用
Antigravity は VS Code と同様に DevContainer 機能をサポートしています。なお、VS Code では拡張機能でしたが Antigravity では組み込みの機能として提供されています。そのため、拡張機能のインストールは不要です。
DevContainer はコマンドの実行環境のほか、ファイルシステムや拡張機能などの開発環境を丸ごとコンテナ化することができます。これにより、 Antigravity が自動で実行するコマンドによってホストOSに影響が出るリスクを大きく減らせます。
Antigravity での DevContainer の設定や制約については、以下の記事をご確認ください。
設定ファイルの引き継ぎ
DevContainer を使う場合、git config などホストOSで行った設定は引き継がれない仕様となっています。（VS Code では一部設定は自動で引き継がれます。）
そのため、以下のように設定ファイルをホストからマウントすることでコンテナ内に設定を引き継ぐことができます。
{
"name": "Sample Python",
"image": "mcr.microsoft.com/devcontainers/python:3",
"mounts": [
"source=${localEnv:HOME}/.gitconfig,target=/home/vscode/.gitconfig,type=bind,consistency=cached",
"source=${localEnv:HOME}/.gemini/GEMINI.md,target=/home/vscode/.gemini/GEMINI.md,type=bind,consistency=cached",
],
}
上記の例では、 .gitconfig と ~/.gemini/GEMINI.md をホストから引き継いでいます。
GEMINI.md については、次の章で紹介します。
5. Customizations でのグローバル指示
Antigravity は ~/.gemini/GEMINI.md に書いた指示が全てのセッションでグローバルに共有されます。
スクリーンショットのように Customizations > +Global とクリックすることで、上記のファイルを開くことができます。
私が入れている指示は以下のようなプロンプトです。
思考は英語で行い、ユーザーへのレスポンスは日本語に翻訳すること。
アーティファクトはユーザーにレビューを求める前に日本語に翻訳すること。
タスクを実行中、Stepが10を超えたら一度処理を停止して「完了した作業」「状況の報告」「次のアクション」を報告し、ユーザーの判断を仰ぐこと。
まず、Antigravity 特に指示しなければ英語での出力を行います。Artifact についても同様に英語で出力されてしまうので、英語を読むのがなかなかしんどいです。
このプロンプトをグローバルの GEMINI.md に書くことで、複数のワークスペースで使いまわせるので便利です。
タスクの Step10 制限については個人的な好みで入れています。
複雑なタスクを実行させるとき、たまに明後日の方向に努力をし続けてしまうことがあります。（実装中に Low モデルを使っているからかもしれません）そのようなケースではAIのみでゴールに辿り着くのは難しい状況になっているため、人間が軌道修正をしてあげる必要があります。
また、これはやってみて気がついたことですが「状況整理をさせる」ということ自体にも一定のメリットがあるように感じています。トライアンドエラーを繰り返している中では、エラーの直接原因に向き合い続けてしまい、根本原因を見失うケースが多々あります。しかし、この指示によって立ち止まらせることで、根本原因についても分析してくれるようになっています。
そのため、実際に状況報告を受けたあと、提示されたアクションプランに対して「そのまま続けて」と指示することも多々あります。
最後に
以上が、現時点で分かった活用ポイントの紹介でした。
フリープランしかない時は Rate Limit に引っかかるまでが早くなかなか厳しかったんですが、有料プランの登場によってかなり自由に使えるようになってきました。
また、Antigravity の特性もわかってきて少しずつ活用のポイントも見えてきたので、今後さらにいろいろなアプリケーションを作っていきたいと思います！
以上、すらぼでした！
参考資料
