6月15日、Google が AI コーディングツールを Antigravity に集約する方針を示しました。手元には Antigravity 2.0 のデスクトップアプリ、CLI、SDK という三つの入り口が残ります。私自身、最初の数日はこの三つを「気分で」開いていて、同じ作業をデスクトップでもターミナルでも走らせてしまい、どちらが正だったのか分からなくなる場面が何度もありました。
混乱の原因は機能の重複ではありませんでした。三つとも同じエージェントハーネスを共有しているので、できることはほとんど同じです。問題は「いつどれを開くか」を決めていなかったことでした。
そこで、機能ではなく開発フェーズで三層を割り当て直したところ、迷いが消えました。その分け方と、層をまたぐときの受け渡し設計をまとめます。
デスクトップは「探索」のための場所
新しいライブラリの挙動を確かめる、仕様が固まっていない機能を試作する、エージェントの提案を見ながら方針を決める——こうした探索フェーズはデスクトップアプリが向いています。
理由は、出力を目で見て即座に方向転換できるからです。エージェントが書いたコードのプレビュー、ブラウザ操作の様子、差分の確認が同じ画面に並ぶので、「この方針は違う」と気づいた瞬間に止められます。
私はこのフェーズでは、あえて指示を曖昧なまま投げます。「この画面の余白が窮屈なので整えてほしい」程度の粒度で投げ、返ってきた提案から要件を逆算するほうが、最初から仕様を書き下すより速いと感じています。探索の目的は正解を出すことではなく、要件を発見することだからです。
CLI は「反復と検証」のための場所
方針が固まったら CLI に移ります。同じ処理を別の入力で何度も回す、結果を機械的に判定する、変更を一括で適用する——この反復フェーズは、ターミナルから非対話で叩けることが効いてきます。
たとえば記事の品質ゲートを 30 本まとめてかけたいとき、デスクトップで 1 本ずつ確認するのは現実的ではありません。CLI ならシェルのループに乗せられます。
#!/usr/bin/env bash
set -euo pipefail
# 変更された記事だけを対象に、エージェントで整合性チェックを回す
changed=$(git diff --name-only HEAD~1 -- 'content/**/*.mdx')
fail=0
for f in $changed; do
# 非対話モードで起動し、終了コードで合否を受け取る
if ! agy run --headless --prompt "$(cat checks/consistency.md)" --input "$f"; then
echo "NG: $f"
fail=$((fail + 1))
fi
done
echo "完了: ${fail} 件が要修正"
[ "$fail" -eq 0 ]
ここで大切なのは、CLI に渡す指示をファイルとして固定することです。デスクトップで対話的に詰めたプロンプトを checks/consistency.md のような形に書き出しておくと、反復のたびに揺らがなくなります。私の体感では、指示をベタ書きから外部ファイルに移しただけで、同じ入力に対する判定のブレが目に見えて減りました。
SDK は「定常運用」のための場所
毎日決まった時刻に走る処理、人間が見ていない時間帯に動くタスク——この定常運用フェーズは SDK の領域です。スケジュール実行とサブエージェントの組み立てを、自分のコードの一部として持てます。
from antigravity import Agent, Schedule
# 毎朝、前日のクラッシュレポートを集約して要約するエージェント
triage = Agent(
name="crash-triage",
instructions=open("agents/crash_triage.md").read(),
tools=["fetch_crashlytics", "read_repo"],
max_cost_usd=0.50, # 1 回あたりの上限を必ず設ける
)
@Schedule.daily(at="07:00", tz="Asia/Tokyo")
def morning_triage():
result = triage.run(
input={"window_hours": 24},
timeout_s=600,
)
if result.severity >= 3:
notify_me(result.summary) # 重大なときだけ通知
定常運用で私が最優先するのは、コスト上限とタイムアウトを必ず付けることです。デスクトップなら暴走に気づけますが、無人で動くタスクは誰も見ていません。max_cost_usd を付けずに回したスケジュールが、想定の 3 倍近くトークンを消費していたことが一度あり、それ以来この 2 つは省略しないと決めています。
層をまたぐときのハンドオフ設計
三層を分けると、今度は層から層への受け渡しが課題になります。探索で得た知見を反復に渡し、反復で固めた処理を定常運用に載せる——このとき状態を口頭やメモで運ぶと、必ずどこかで欠落します。
私が採っているのは、各層の成果物をリポジトリ内のファイルに落とすやり方です。
- デスクトップでの探索が終わったら、固まった指示を
agents/<task>.md に書き出す
- CLI の反復スクリプトはその
.md を読み込む形にして、プロンプトを二重管理しない
- SDK のスケジュール定義も同じ
.md を open() で参照する
こうすると、指示の正本が一箇所に集まります。デスクトップで方針を変えたら .md を更新するだけで、CLI も SDK も自動的に追従します。逆に、層ごとに指示をコピーして持つと、片方だけ直して片方が古いまま、という事故が起きます。実際これは最初にやらかした失敗で、原因の特定に半日かかりました。
どの層を開くかの判定基準
迷ったときは、次の問いで切り分けています。
- 出力を見ながら方針を決めたいか → はい、ならデスクトップ
- 同じ処理を 2 回以上、別の入力で回すか → はい、なら CLI
- 人間が見ていない時間に動かすか → はい、なら SDK
二つ以上に当てはまる場合は、フェーズが移行する途中だと考えます。探索しながら少し反復が混じってきたら、それは「そろそろ CLI に移す頃合い」のサインです。無理に一つの層に閉じ込めず、移行のタイミングと捉えるほうが自然でした。
なお、三層すべてを使う必要はありません。使い捨ての検証ならデスクトップだけで完結しますし、単発のバッチ処理なら CLI で十分です。SDK まで持ち出すのは「明日も明後日も同じ処理が走る」と確信できたときだけにしています。早すぎる自動化は、まだ揺れている要件を固めてしまう副作用があるからです。
本番運用で踏んだ落とし穴
三層を束ねて運用するなかで、特に効いた注意点を挙げておきます。
一つ目は、デスクトップでの探索結果をそのまま定常運用に直結させないことです。探索フェーズの指示は曖昧さを許容して書いているので、無人運用に載せると判断がぶれます。間に CLI での反復を必ず挟み、十数回回して出力が安定することを確認してから SDK に上げる、という順序を守るようにしています。
二つ目は、コスト計測を層ごとに分けて取ることです。同じエージェントでも、対話的に使うデスクトップと無人で回す SDK では消費の桁が変わります。私の場合、定常運用が全体コストの約 7 割を占めていて、削減の効果が大きいのは明らかに SDK 側でした。どこにコストが寄っているかを知らないまま最適化しても、徒労に終わります。
三つ目は、6 月 18 日に旧来の CLI が提供終了になる点です。反復フェーズのスクリプトが古い CLI を前提にしていると、ある朝いきなり動かなくなります。シェルスクリプトの中でコマンド名を一箇所にまとめておくと、移行のときに直す場所が一つで済みます。
次の一歩
まずは、いま手を動かしている作業が探索・反復・定常運用のどれに当たるかを言葉にしてみてください。それだけで、開くべき入り口が自然と決まります。
私自身まだ運用しながら境界線を引き直している途中ですが、機能ではなくフェーズで層を割り当てるという視点は、三つの入り口を前にした迷いをかなり減らしてくれました。同じように三層の使い分けに悩んでいる方の助けになれば幸いです。