2026 年 6 月 18 日。この日付を手帳に書いてからずっと、頭の片隅で小さく時計が鳴り続けています。個人向けの Gemini CLI / Code Assist IDE 拡張がこの日に提供終了となり、私が毎朝走らせている自動化スクリプトの土台が、そのままでは動かなくなるからです。
agy という短いコマンド名でターミナルから Antigravity 2.0 を呼ぶ新しい TUI(Antigravity CLI)は、その移行先として用意されたものです。ただ Gemini CLI の流れを汲みながらも、認証もコマンド体系も設定ファイルの場所も別物になっていて、最初に触ったときは何度か手を止めて読み直しました。
ここでは、どのアプリを入れるのか、認証をどう通すのか、そして一番大事な「6 月 18 日までに、止められない既存スクリプトをどう寄せるか」を、個人開発で複数リポジトリを並行運用してきた立場から順に書き出していきます。締切がある移行は、最後の一週間に慌てて壊すのではなく、二週間前に静かに地ならししておくのが私自身のやり方です。
Antigravity 2.0 と Antigravity IDE のどちらを入れるか
agy は単体のバイナリですが、CLI を動かす前段で Antigravity 側の認証を通しておく必要があります。ここで自分は何が必要なのかを意識しないと、間違ったアプリを入れて時間を溶かします。
二系統に分かれます。
- Antigravity 2.0:複数のローカルエージェントを並列で監督する「司令塔」アプリ。プロジェクトごとに会話をまとめ、ワークスペース横断の操作や予約メッセージで定期作業を組めます。Chrome DevTools for agents もここにバンドルされています。
- Antigravity IDE:エージェントマネージャーとアーティファクトを内包した、コードベースを深く読みにいくエージェント型 IDE。読みと書きが一体になった作業空間です。
v1.0 から続いている感覚でつい Antigravity 2.0 を選ぶと、IDE ではなくエージェント管理用のデスクトップアプリが入ります。これは IDE ではないぞ、と気づくまで自分も 5 分ほどかかりました。CLI から本格的にコードを動かす予定なら、まず Antigravity IDE を入れて認証を通すのが素直です。Antigravity 2.0 が要るのは、複数エージェントを並走させるフェーズに入ってからで構いません。
agy のインストールと、最初に固めておく設定
macOS なら公式ドキュメントどおり、curl の一行で済みます。
curl -fsSL https://antigravity.google/cli/install.sh | bash
シェルを開き直して agy を叩くと、初回はテーマと認証の設定が走ります。個人 Google アカウントなら OAuth を選び、表示されたリンクをブラウザで開いて認可。データ提供の利用規約に答えた時点で完了です。Gemini CLI と違って、API キーを .env に書く必要はありません。
設定ファイルは ~/.gemini/antigravity-cli/settings.json に作られます。起動中に /config か /settings で GUI 的に編集できますが、私は最初に次の形まで一気に固めてしまいます。あとから一つずつ直すより、初日に「事故らない初期値」を置く方が結果的に速いと感じています。
{
"colorScheme": "tokyo night",
"editor": "vim",
"enableTerminalSandbox": true,
"model": "Gemini 3.5 Flash (High)",
"notifications": true,
"permissions": {
"allow": ["command(git)", "command(npm test)", "command(npm run build)"],
"deny": ["command(rm -rf)", "command(git push --force)"]
},
"runningLightSpeed": "fast",
"trustedWorkspaces": []
}
permissions.deny に rm -rf と git push --force を入れているのは、個人開発で公開中のアプリのリポジトリを agy から触ることがあるからです。App Store と Google Play に出ているコードは、エージェントの一手で取り返しがつかなくなる場面が現実にあります。許可は最小から始めて、必要になったら足す。これだけで事故の母数がはっきり減ります。
6 月 18 日までにやること:既存スクリプトを止めない「互換シム」
ここが今回いちばん書きたかった部分です。Gemini CLI が止まると、gemini コマンドを前提に組んだ cron やシェルスクリプトが一斉に無言で失敗します。私の環境では、記事の下書き生成・画像のリネーム・ログ集計などで gemini を呼ぶ箇所が 17 ファイルに散っていました。これを一つずつ書き換えるのは、締切前にやる作業として最悪です。
そこで、gemini という名前のまま中身だけ agy に差し替える薄いシムを PATH の先頭に置きます。本体のスクリプトには一切手を入れません。
#!/usr/bin/env bash
# ~/bin/gemini — Gemini CLI 停止後も既存呼び出しを agy に寄せる互換シム
# PATH の先頭(/usr/local/bin より前)に置く
# 旧: gemini -p "..." → 新: agy run --prompt "..."
# 旧: gemini --model X → 新: agy run --model X
args=()
prompt=""
model="gemini-3.5-flash-high"
while [ $# -gt 0 ]; do
case "$1" in
-p|--prompt) prompt="$2"; shift 2 ;;
-m|--model) model="$2"; shift 2 ;;
*) args+=("$1"); shift ;;
esac
done
exec agy run --model "$model" --prompt "$prompt" "${args[@]}"
置いたら実行権限を付けて、旧コマンドが本当にシム経由になっているか確認します。
chmod +x ~/bin/gemini
hash -r # シェルのコマンドキャッシュを破棄
which gemini # → /Users/you/bin/gemini になっていれば成功
gemini -p "ping" # agy 経由で疎通確認
このシムを 6 月 18 日より前に入れておくと、当日に何も起きません。止まるはずだったスクリプトが、名前を変えないまま agy で動き続けます。完全移行は落ち着いてから、ファイルを一つずつ agy run に書き換えていけばよく、その間も本番は止まりません。私は移行の山場を「締切当日」から「二週間前の地ならし」へずらすために、いつもこの薄い一枚を先に挟みます。
なお、設定そのものの引き継ぎは公式の取り込み機能が用意されています。agy を初回起動すると Gemini CLI の設定を読む「移行オプション」が出ますし、出てこなければ後から agy plugin import gemini で MCP サーバの登録・許可済みコマンド・キーバインドをそのまま取り込めます。
モデル選択とコスト:Pro($20)と Ultra($100)の損益分岐
/model を開くと、現在は次のような候補が並びます。
- Gemini 3.5 Flash (High / Medium)
- Gemini 3.1 Pro (High / Low)
- Claude Sonnet 4.6 (Thinking)
- Claude Opus 4.6 (Thinking)
- GPT-OSS 120B (Medium)
デフォルトは Gemini 3.5 Flash (High)。preview の接尾辞が外れたのは、Antigravity 2.0 で各モデルが正式扱いになった証拠です。Gemini CLI で gemini-3.1-pro-preview 相当を常用していた人は、Gemini 3.1 Pro (High) を選び直すと体感が揃います。
ここで移行と同時に多くの人が悩むのが、Pro($20/月)のままでいくか、AI Ultra($100/月・上限が Pro の約 5 倍)に上げるか、です。私は損益分岐を「料金の絶対額」ではなく「上限に当たって手が止まる回数」で考えています。
判断軸はシンプルです。Pro の上限に週 1〜2 回しか当たらないなら、$20 のままで十分です。これが平日ほぼ毎日「クォータに達しました」で止まるようになったら、その待ち時間こそが本当のコストです。仮に上限超過で 1 日 30 分待たされるとして、月 20 営業日なら 10 時間。自分の時給換算がいくらであっても、$80 の差額($100 − $20)はたいてい割に合います。逆に言えば、月の半分も上限に届かない使い方なら Ultra は過剰投資で、その $80 はモデル料金よりエディタや実機テストに回した方が利きます。
クォータの内訳が不透明なのは正直に弱点で、/usage で消費の傾向はつかめても、残量が秒単位で正確に出るわけではありません。私は 1 週間 Pro のまま回して、/usage を毎日メモし、上限に当たった日数だけを数えてから上げるかどうかを決めました。最初から Ultra に飛びつかないことを推奨します。
権限設計:自律レベルを上げる前に決めておくこと
/permissions でエージェントの自律度を request-review / always-proceed / strict から選べます。移行直後にやりがちな失敗は、Gemini CLI で慣れている安心感から、いきなり always-proceed にしてしまうことです。
CLI が変わると、許可リストの中身も内部のツール呼び出しも別物になっています。「Gemini CLI では安全だった操作」が agy でそのまま安全とは限りません。私は移行から最低 1 週間は request-review のまま走らせ、エージェントがどのコマンドを実行しようとするかを目で見てから、頻出する安全な操作だけを permissions.allow に足していきます。
「Gemini CLI で動いていたのに agy で止まる」とき、私が真っ先に確認するのも権限です。旧 allow リストにあったコマンドが agy の permissions.allow へ引き継がれていない場合があり、ターミナル実行が途中で止まります。/permissions でその場で確認・追加するのが手早い対処です。
覚えておくと作業が速くなる入力テクニック
agy は普通の対話 UI ですが、入力欄に記号を混ぜると挙動が変わります。最初の数日で身体に入れておきたいものを挙げます。
@ を打つとパス候補が出て、ファイルを直接プロンプトに添付できます
- 行頭に
! を付けるとターミナルコマンドをそのまま実行できます
? でヘルプとスラッシュコマンド一覧
esc を 2 回押すと入力欄が空になります(ストリーミング中以外)
- セッションを閉じても、CLI が再開用のコマンドを自動的に表示してくれます
特に @ 補完は効きます。プロンプトに渡すファイルを最初に丁寧に絞るだけで、後の応答の精度が体感ではっきり変わります。材料を選び抜いてから組む、という当たり前の工程を、CLI でも省かないことだと思っています。
スラッシュコマンドの読み解き:会話・設定・ツールの三軸
スラッシュコマンドは数が多いので、用途別に三軸へ分けておくと迷いません。
会話の流れを制御する系:
/resume(別名 /switch)— 会話ピッカーを開いてセッションを切り替える
/rewind(別名 /undo)— 直前のチェックポイントまで会話を巻き戻す
/rename <name> — 会話スレッドに名前を付けて棚卸ししやすくする
/fork — 過去のある時点から会話を枝分かれさせて別ワークスペースで続行
/clear — プロンプトを消して新しいセッションを開始
設定を変える系:
/permissions — 自律レベルを request-review / always-proceed / strict から選ぶ
/model — 既定モデルの変更(セッションをまたいで保持)
/keybindings — キーボードショートカットエディタ
/statusline — ステータスバーに出すリアルタイム指標のカスタマイズ
ツールと監視系:
/tasks — 走らせているバックグラウンドタスクの状態とログ
/skills — ローカル/グローバルに定義したスキル一覧
/mcp — MCP サーバの設定パネル
/usage — インラインのインタラクティブヘルプ
一覧には載っていませんが、/fast を実行するとエージェントが計画フェーズを省いて直接タスクを実行するモードに入ります。素早く試したい時に便利で、/artifacts で実装計画を後から管理できるのも安心です。長めのタスク中は /task で状態を見つつ、/btw で割り込みの質問を投げる、という使い分けが板についてきます。
予約メッセージで定期作業を回す:CLI と GUI の役割分担
ここまで来たら、Antigravity 2.0 側の予約メッセージに進みます。agy 単体は対話と単発実行に強く、決まった時刻に同じ作業を回すのは Antigravity 2.0 の予約メッセージが向いています。私は「人が見て判断する作業は CLI」「毎日同じ手順を繰り返す作業は予約メッセージ」と切り分けています。
定期作業を組むときに私が守っているのは三点です。
- オフピークの時刻に散らす。複数の定期タスクを同じ分にぶつけると、クォータの瞬間消費が跳ねて互いに待たせ合います
- 各タスクの最初に「権限は最小・破壊的操作は deny」を効かせた状態で起動する。無人実行ほど
rm -rf 系の事故が怖いからです
- 失敗時は黙って止めず、ログに残してから終わる。無人だからこそ、後から原因を追える形にしておく
この設計判断は、複数の自動投稿パイプラインを並行で回してきた実体験から固まったものです。エージェントに任せる範囲を広げるほど、止め方と記録の作法が効いてきます。
実力検証:Three.js の花火を一発生成
移行後の感触を確かめるため、Gemini CLI と agy の双方に同じプロンプトを投げてみました。
Three.js を使って、1 つの HTML ファイルだけで完結する美しい 3D 花火アニメーションを作ってください。
両方とも Gemini 3.1 Pro 系を選び、/fast で Plan を省略。生成された index.html の構造はかなり近いものの、agy 側は OrbitControls の damping や ACESFilmicToneMapping まで自動で組み込んで、見栄えで一歩前に出る印象でした。Gemini CLI 側は最小構成寄りで、後から手を入れやすい素直なコードを返してきます。
どちらが優れているか、というよりは、agy は「初手の完成度を盛りに行く」性格、Gemini CLI は「素材としての扱いやすさを保つ」性格、と捉えるのが私の感覚に近いです。生成物を最後にチューニングするのは人間の仕事であり、その配分が CLI 側でも残されているのは嬉しい設計です。
まず最初の 30 分で何をするか
agy を入れたら、次の順で触ると土地勘がつかみやすいです。
- 互換シム(
~/bin/gemini)を入れて、既存スクリプトを止めないように先に保険をかける
agy plugin import gemini で Gemini CLI の設定を持ち込む
/model を開いて手元のタスクに合ったモデルに切り替える
/permissions を request-review のまま運用する(最初は自律度を上げない)
- 既存リポジトリで
@ 補完を使ってファイルを 2〜3 個渡し、/fast を付けずに会話だけ進める
- 安心したら
/fast と /artifacts を試し、計画と実装の切り替えに慣れる
ここまで触ったあとで、Antigravity 2.0 側の予約メッセージや Chrome DevTools for agents 連携に進むと、CLI と GUI のどちらに何を任せるかという設計判断ができるようになります。6 月 18 日は、慌てる日ではなく、二週間前に置いた一枚のシムのおかげで何も起きない日にしておきたいところです。同じ移行に向き合っている方の、地ならしの参考になれば幸いです。