Google が AI コーディングツールを Antigravity に集約すると発表したとき、便利さと同じだけの不安を覚えた個人開発者は少なくないはずです。
学習対象が一本化されるのはありがたい。けれど、すべてを一つのプラットフォームに預けるということは、その判断ひとつで自分の開発環境が左右されるということでもあります。6/18 には Gemini CLI と Code Assist の個人向け提供が終わり、Antigravity CLI へ移ることになりました。締切のある移行は、設計を見直す良い機会です。
ここでお伝えしたいのは、集約に乗りつつも「いつでも降りられる」状態を保つための、ロックインの測り方と退避路の残し方です。
ロックインを感覚でなく数字で測る
「ロックインが怖い」と言うとき、私たちは漠然とした不安を語りがちです。まず、その怖さを3層に分けて採点することをお勧めします。
第一に 学習投資。そのツール固有の操作・概念を覚えるのにかけた時間。これは移行コストとして直接効きます。
第二に ワークフロー結合。日々の作業がそのツールのコマンドや UI にどれだけ食い込んでいるか。スクリプトやエイリアスに固有コマンドが埋まっているほど高得点です。
第三に データ・資産の持ち出しやすさ。プロンプト、設定、エージェント定義を別環境へ運べるか。ここが低いほど危険です。
私は各層を0〜3点で採点し、合計が6点を超えたら退避路の整備を最優先にしています。Antigravity への集約は学習投資の点を下げてくれますが、ワークフロー結合は油断すると一気に上がります。
採点を3分の習慣にする
採点は重くする必要がありません。私は3分で終わる簡単なシートを使っています。
たとえば、ある週の自分の構成を採点するとこうなります。学習投資は、Antigravity 固有の概念に慣れた分で2点。ワークフロー結合は、自動化スクリプトの7箇所に固有コマンドが直書きされていて3点。持ち出しやすさは、プロンプトはリポジトリにある一方で設定がツール内部に残っていて1点。合計6点で、退避路の整備に着手する閾値ちょうどでした。
この採点を月初に一度だけ行うと、ロックインがじわじわ上がっていないかを早期に察知できます。点が上がった層に、その月の改善を集中させればよいのです。数字に置き換えると、漠然とした不安が具体的な作業項目へと変わります。私はこのひと手間を、保険料のようなものだと考えています。
資産を「持ち出せる形」で置く
退避路の核心は、プロンプトとエージェント定義をツールの中ではなくリポジトリに置くことです。
Antigravity は AGENTS.md や設定ファイルでエージェントの振る舞いを定義できます。これをツール内部の状態に頼らず、バージョン管理されたファイルとして持つだけで、持ち出しやすさの点が大きく改善します。
#!/usr/bin/env bash
# export_agent_assets.sh — エージェント資産をリポジトリへ退避する
set -euo pipefail
DEST="agent-assets/$(date +%Y%m%d)"
mkdir -p "$DEST"
# エージェント定義・プロンプト・設定をまとめて控える
cp -v AGENTS.md "$DEST/" 2>/dev/null || echo "AGENTS.md なし"
cp -rv .antigravity/ "$DEST/config/" 2>/dev/null || echo "設定ディレクトリなし"
find prompts/ -name '*.md' -exec cp -v {} "$DEST/" \; 2>/dev/null || true
echo "退避完了: $DEST"
このスクリプトを週次で回しておくと、仮にツール側で何かが変わっても、昨日までの自分の作業資産は手元のリポジトリに残ります。
コマンドを直書きしない
ワークフロー結合の点を下げる最大の打ち手は、固有コマンドを直接叩かないことです。
私は普段の自動化スクリプトから、ツール固有のコマンド名を一段隠しています。gemini を直接呼ぶのではなく、agent_run のような薄い関数を経由させる。こうしておくと、gemini から agy（Antigravity CLI）へ名前が変わっても、書き換えるのは一箇所だけで済みます。
# agent_lib.sh — ツール名の差異を吸収する薄い抽象レイヤ
agent_run() {
local prompt_file="$1"
# 利用可能なバイナリを優先順で探す（移行期は両方が共存する）
if command -v agy >/dev/null 2>&1; then
agy run --file "$prompt_file"
elif command -v gemini >/dev/null 2>&1; then
gemini --prompt-file "$prompt_file"
else
echo "エージェント CLI が見つかりません" >&2
return 127
fi
}
この一枚があるだけで、6/18 のような切り替え日にスクリプトが全滅する事態を避けられます。移行期は両方のバイナリが共存するので、優先順で探す作りにしておくのが実務的です。
6/18 で実際に動かなくなるもの
提供終了の影響は、頭で考えるより具体的です。実際に確認しておくべき点を挙げます。
- 個人の無料枠・AI Pro（$20/月）・Ultra（$100/月）での Gemini CLI のリクエストが通らなくなる
- CI から
gemini を呼んでいるパイプラインが、コマンド不在で失敗する
- エイリアスやエディタ連携に埋め込んだ旧コマンドが沈黙する
特に2番目は本番の自動化を止める落とし穴です。CI のログを gemini で grep し、ヒットした箇所を前述の抽象レイヤ経由に書き換えておく。これを締切の前にやるか後にやるかで、慌て方がまるで違います。
組織向けの Code Assist ライセンスは継続しますが、個人開発者が頼ってきた無料・Pro 枠の CLI は対象です。自分がどの枠で動かしているかを、まず確認することをお勧めします。
集約に「乗る」と「預けすぎない」の両立
ここまで退避の話を続けましたが、私は集約そのものには前向きです。
学習対象が一本化され、エディタ・ターミナル・ブラウザをまたぐエージェント実行が一つの土台に乗るのは、個人開発者にとって素直に効率的です。App Store と Google Play の両方へ向けた作業を一人で回す身としては、覚えることが減るのは純粋にありがたい。
大切なのは、乗ることと預けすぎることを分けて考える姿勢だと感じています。プロンプトと設定をリポジトリに置き、コマンドを抽象化し、ロックイン点を定期的に採点する。この三つを習慣にしておけば、集約の便利さを享受しながらも、判断の主導権は自分の手に残せます。
次の一手として、まずは自分のスクリプトを gemini で grep してみてください。直書きが何箇所あるかが、いまのロックイン度の正直な答えになります。