Antigravity を触りはじめて最初に戸惑うのは、機能の難しさよりも入り口の多さかもしれません。デスクトップアプリ、ターミナル、エディタ、そして Python ライブラリ。同じ「Antigravity」という名前でも、入り口が4つあると「自分はどれを開けばいいのか」で手が止まります。
私自身、個人開発で Dolice Labs という4つのAI技術ブログを並行運営していて、記事の下調べやコード検証に Antigravity を日常的に使っています。その中で、作業の性質によって開く入り口を変えると体感が大きく変わると気づきました。ここでは4つのサーフェスを「どんなときにどれを選ぶか」という一点に絞って整理します。
4つは「同じエンジン・違う入り口」と捉える
最初に押さえておきたいのは、4つのサーフェスが見た目こそ違っても、内部では同じエージェントハーネスの上で動いているという点です。Google Cloud の公式解説でも、どのサーフェスを選んでもプラグインやスキルといった仕組みは共通でサポートされる、と明記されています（Choosing your surface: Antigravity 2.0, CLI, IDE, or SDK）。
つまり「どれが高機能か」で悩む必要はほとんどありません。コアのロジックは共有されているので、違うのはあくまで操作感と、どの作業に手が届きやすいかという接点の部分です。エディタが好きな人は IDE を、ターミナル中心の人は CLI を選べばよく、能力で劣る入り口を引かされるわけではない、というのが安心できるところでした。
| サーフェス | インターフェース | いちばん効く場面 |
|---|---|---|
| Antigravity 2.0 | デスクトップアプリ | 複数タスクを同時に走らせて見張る |
| Antigravity CLI | ターミナル（TUI） | コマンドライン中心・ヘッドレス実行 |
| Antigravity IDE | デスクトップアプリ | コードを直接見ながら1行ずつ承認 |
| Antigravity SDK | Python コード | 自分専用のエージェントを組む |
Antigravity 2.0 — 並行作業を見渡したいとき
公式が「デフォルトのおすすめ」として挙げているのが Antigravity 2.0 です。スタンドアロンのデスクトップアプリで、メインの作業をブロックせずに複数のタスクを同時に動かせるよう設計されています。
私の使い方でいうと、片方のプロジェクトでコードの品質チェックを走らせながら、別の画面で古くなった依存パッケージの洗い出しを進める、といった並行運用に向いています。コード品質の点検や古いパッケージの検出を定期実行するようスケジュール設定もできるので、「気づいたら裏で回っていた」という状態を作りやすいのが魅力でした。ひとりで複数の案件を抱える個人開発者には、この同時実行のしやすさがそのまま時間の節約になります。
Antigravity CLI — ターミナルから離れたくないとき
CLI は高速性を狙って Go で書かれていて、キーボードだけで完結させたい人に向いています。アクティブなコマンドラインをロックせずに、ターミナルからバックグラウンドのエージェントを起動できるのが特徴です。
決め手になりやすいのは、ヘッドレス実行が要るかどうかです。SSH 越しの作業や、リモートのコンテナ内で動かしたい場合は、画面を持つアプリよりも CLI のほうが素直に収まります。私の場合、ブログのデプロイ周りをサーバー上で確認するときなど、手元にエディタを開かない作業では CLI を選ぶ場面が増えました。
Antigravity IDE — 変更を1行ずつ確かめたいとき
IDE サーフェスは、エージェントを今のワークスペースの中に直接置く形です。エージェントが編集しているコードを正確に目で追い、変更を1行ずつ承認したり拒否したりしたい場面で力を発揮します。
組み込みのデバッグ機能を使うと、エージェントがランタイムエラーを確認し、修正案をエディタ上に提示してくれて、それをワンクリックで適用できます。「AI に任せきりにせず、自分の目で通してから反映したい」という慎重なレビュー志向の人には、この入り口がいちばん落ち着きます。私もリリース前の最終確認では、変更を一つずつ目視できる IDE に切り替えるようにしています。
Antigravity SDK — 自分専用のエージェントを組みたいとき
SDK は Python のライブラリで、独自のカスタムエージェントをゼロから組み立てたいときの選択肢です。公式ツールを支えているのと同じ共有ハーネスの上で動くため、Google 公式のツールがアクセスしているのと同じツールやルールに直接触れられます。
ローカルでエージェントを書いて、コードを一切変えずに Google Cloud へデプロイできる、という流れも示されています。アプリの自動化パイプラインに AI の判断を組み込みたい、定型作業を自前のエージェントに任せたい、といった用途ではこのサーフェスが本命になります。実装の具体例は後編で詳しく扱います。
どれを選ぶか — 迷ったときの判断軸
入り口で迷ったら、次の順に自分へ問いかけると素早く絞り込めます。まず「コードを書くより、複数の作業を同時に回したいか」を考え、当てはまるなら Antigravity 2.0 です。次に「ターミナルから出たくない、あるいはヘッドレスで動かしたいか」が当てはまるなら CLI を選びます。「変更を1行ずつ自分で承認したいか」なら IDE、「自分でエージェントのロジックを組みたいか」なら SDK、という順です。
大事なのは、最初から正解を当てにいかないことです。コアは共通なので、ある作業で IDE を使い、別の作業で 2.0 に移っても学び直しはほとんど発生しません。私自身、案件の段階に応じて入り口を行き来していて、その都度いちばん手の届きやすいものを選ぶ運用に落ち着きました。
後編では、この4つを実際のプロジェクトでどう組み合わせるか、そして SDK で小さなカスタムエージェントを動かすところまで、実装を交えて掘り下げます。まずは一番手に馴染む入り口をひとつ開いてみるところから始めてみてください。