Antigravity 2.0 が単体のエディタから 5 つの面を持つ基盤へ姿を変えてから、いちばん最初に迷ったのは新機能の使い方ではなく、「この仕事をどの面で動かすのが正しいのか」という問いでした。デスクトップで対話しながらやるのか、CLI で叩くのか、SDK でアプリに組み込むのか、Managed Agents API でクラウドに投げるのか。同じ「コンポーネントを直す」という作業でも、文脈によって正解の面が変わります。
私自身が個人開発で 4 つのサイトを並行運用するなかで、最初はすべてデスクトップで済ませようとして手が回らなくなりました。面を仕事の性質で選び分けるようになって、ようやく落ち着いたのです。ここでは、その選び方を判断軸として整理します。
まず 4 つの面の素の性格を押さえる
エンタープライズ Cloud を除くと、個人開発で触れるのは次の 4 面です。それぞれ得意な仕事の形が違います。
| 面 | 素の性格 | 最も向く仕事 |
|---|
| デスクトップ | 対話的・並行エージェントを目で監督 | 探索しながら作る・判断が要る作業 |
| CLI | 非対話・スクリプトに組み込める | 定型処理・CI・夜間バッチ |
| SDK | 自前アプリにエージェントを内蔵 | プロダクトの機能としての常駐処理 |
| Managed Agents API | 隔離環境を単一呼び出しで起動 | 重い・危ない・隔離したい処理 |
ここで大事なのは、これらが「優劣」ではなく「向き不向き」だという点です。デスクトップが上位で API が下位、ではありません。仕事の性質に当てると、自然に向く面が決まります。
4 つの軸で仕事を測る
面を選ぶとき、私は仕事を次の 4 軸で測っています。
対話性
人の判断が途中で要るか。要るならデスクトップ。完全に手順が決まっているなら CLer や API へ寄せられます。「やりながら方針が変わる」作業を無理に自動化すると、結局やり直しが増えます。
スケジュール
決まった時刻に無人で動かしたいか。そうなら CLI を cron に載せるか、SDK のスケジュール実行を使います。デスクトップは人が前にいる前提なので、無人運用には向きません。
隔離
失敗したときの被害を閉じ込めたいか。信頼できない入力を扱う、破壊的な操作を試す、といった仕事は Managed Agents API の隔離環境に逃がします。手元のワークスペースで走らせる必要はありません。
統合深度
その処理を自分のプロダクトの一部として常駐させたいか。ユーザー操作に応じてエージェントが動く機能を作るなら SDK 一択です。CLI やデスクトップでは製品には組み込めません。
判断をコードに落とす
軸が決まると、選択は機械的に書けます。タスクの性質を受け取って面を返す小さなルータです。
from dataclasses import dataclass
from enum import Enum
class Surface(Enum):
DESKTOP = "desktop"
CLI = "cli"
SDK = "sdk"
MANAGED = "managed_api"
@dataclass
class Task:
needs_human_judgment: bool # 途中で人の判断が要るか
scheduled: bool # 無人で定刻実行したいか
needs_isolation: bool # 失敗の被害を隔離したいか
embed_in_product: bool # プロダクトに常駐させたいか
def choose_surface(t: Task) -> Surface:
if t.embed_in_product:
return Surface.SDK # 統合深度が最優先
if t.needs_isolation:
return Surface.MANAGED # 危険・重い処理は隔離へ
if t.scheduled:
return Surface.CLI # 無人の定刻実行
if t.needs_human_judgment:
return Surface.DESKTOP # 対話して詰める
return Surface.CLI # 既定は軽量な CLI
判定の順番には意味があります。統合深度と隔離を先に見るのは、この 2 つが「他の面では代替できない」要件だからです。対話性とスケジュールは後段で、互いに排他なので最後に振り分けます。この順序を逆にすると、隔離したい処理をうっかりデスクトップで走らせる、という事故につながります。
CLI と SDK の最小起動例
実際の呼び出しはごく短く済みます。CLI は非対話モードで叩きます。
# 定型処理を非対話で実行（CI や cron から）
antigravity run \
--headless \
--task "lint と型チェックを通し、失敗時は差分を要約" \
--output json > result.json
SDK は自前のコードからエージェントを起動します。
from antigravity import AgentClient
client = AgentClient()
def handle_user_request(prompt: str) -> str:
# プロダクトの機能としてエージェントを常駐起動
run = client.start(task=prompt, tools=["read_file", "run_tests"])
return run.wait().summary
どちらも数行で、面の選択さえ間違えなければ実装は軽いものです。難しいのは書き方ではなく、最初の「どの面か」の判断にあります。
面をまたぐときの落とし穴
4 面を併用して本番運用に入ると、面ごとに状態が分かれている点が落とし穴になりました。デスクトップで途中まで進めた作業を CLI から続けようとして、文脈が共有されておらず一からやり直し、ということが起きます。
私の回避策は、面をまたぐ前提の作業では、状態を面の外（リポジトリのファイルやチケット）に書き出しておくことです。
1. 面をまたぐ作業は、進捗を必ずファイル/チケットに残す
2. 各面はそのファイルを読んで再開する前提で組む
3. 面の中だけに状態を抱えさせない
こうしておくと、デスクトップで設計を詰め、CLI で定型部分を流し、最後に Managed API で重いテストを隔離して回す、という面の橋渡しがスムーズになります。状態を面の中に閉じ込めないことが、複数面運用のいちばんの勘所だと感じています。
私の選び方
最後に、迷ったときの個人的な優先順位をまとめます。
| 問い | はいなら |
|---|
| プロダクトに常駐させる機能か | SDK |
| 失敗を隔離したい重い処理か | Managed Agents API |
| 無人で定刻に回したいか | CLI |
| やりながら判断が要るか | デスクトップ |
私はこの表を上から順に当てて、最初に「はい」になった面を選んでいます。習慣にしてから、面の選択で迷う時間がほぼ消えました。すべてをデスクトップで抱えるのをやめ、仕事の性質で面を分けることを個人的にお勧めします。Antigravity 2.0 の広がった利用面を持て余している方の、整理の手がかりになればうれしいです。