6月18日まで、あと6日になりました。Gemini CLI と Gemini Code Assist の IDE 拡張がリクエストの受け付けを終え、Go 製の後継である Antigravity CLI（agy）へ役目を引き継ぐ期日です。
告知を読んだときから「早めに移行しよう」と思っていたはずなのに、実際に手を動かしたのは今週でした。個人開発の常で、いま動いているものはつい後回しになります。期日の1週間前というぎりぎりのタイミングではありましたが、移行作業そのものよりも、作業のあいだじゅう考えていたことのほうが長く残りそうなので、記録として書き留めておきます。
まず「gemini」と打っている場所を数えることから始めました
移行作業は、新しい CLI のドキュメントを開く前に、grep から始めました。経験上、この種の移行でいちばん時間がかかるのは新しいツールの習得ではなく、「古いツールにどこで依存しているかを自分が思い出すこと」だからです。
# シェル履歴での使用頻度を確認する
history | grep -c "gemini "
# スクリプト・設定ファイル内の依存箇所を洗い出す
grep -rn "gemini " ~/bin ~/.zshrc ~/.config 2>/dev/null
# 定期実行ジョブに紛れていないか確認する
crontab -l 2>/dev/null | grep gemini私の環境で見つかった依存は18箇所でした。内訳は、運営している4つの技術サイト（Dolice Labs）の記事パイプラインを補助するシェルスクリプトが7箇所、壁紙アプリのビルド前チェックに挟んでいた小さなスクリプトが3箇所、シェルのエイリアスが4箇所、そして存在を忘れていた実験用スクリプトが4箇所です。
収穫だったのは、この「忘れていた4箇所」が見つかったことです。提供終了という外からの締め切りがなければ、ある日突然動かなくなって初めて気づいていたはずでした。
「Go 製の別実装」という言葉を、少し軽く見ていました
Antigravity CLI は Gemini CLI の改名版ではなく、Go で書き直された別の実装です。Agent Skills・Hooks・Subagents・Extensions といった概念は引き継がれていますが、概念が引き継がれることと、手元の設定がそのまま動くことは、別の話でした。
実際、2.0 への移行では既存のセットアップが一時的に動かなくなったという報告がいくつも出ています。私の手元でも、スクリプトから呼んでいた非対話モードの出力形式が一部変わっていて、結果をパースしていた箇所を2つ直すことになりました。インストールやスラッシュコマンドの対応関係は、以前公開した Antigravity CLI（agy）を触る：Gemini CLI からの移行手順とスラッシュコマンドの読み解き に整理してあるので、ここでは運用面で効いた手順だけ書きます。
# 1. 既存の設定を日付付きでバックアップしてから始める
cp -r ~/.gemini ~/gemini-config-backup-$(date +%Y%m%d)
# 2. agy を導入し、動作確認だけ先に済ませる
agy --version
# 3. 新旧を数日併存させ、スクリプトを1本ずつ切り替える要点は3の「併存期間」です。期日が迫ると一括置換で済ませたくなりますが、コマンド名の単純な置換は引数仕様や出力形式の差を無視してしまいます。1本動かしては確かめる、を繰り返したほうが、結果的には速く終わりました。
反省していること: コマンド名を直に書き散らしていました
18箇所を直しながらずっと考えていたのは、「そもそも18箇所も直す必要はあったのだろうか」ということです。
答えは明らかで、コマンド名を各スクリプトに直書きしていたからです。最初から薄いラッパーを1枚かませておけば、直すのは1箇所で済んでいました。
#!/usr/bin/env bash
# ~/bin/ai-cli — AI CLI の実装をこの1箇所に集約する薄いラッパー
# 各スクリプトは ai-cli を呼ぶ。実装が変わってもこのファイルだけ直せばよい
exec agy "$@"データベースの接続情報を環境変数へ逃がすのと同じ発想です。ただ、接続情報では当たり前にやっていたことを、CLI ツールに対してはやっていませんでした。エディタや言語ランタイムと同じように、CLI ツールを「あって当たり前の空気」のように扱っていたのだと思います。
移行を終えた今は、外部の CLI を呼ぶスクリプトを書くたびに、「このコマンド名は1年後も同じ名前で存在するだろうか」と一度立ち止まるようになりました。
提供終了は、依存を選び直す機会でもあると考えるようになりました
個人開発を続けていると、ツールの提供終了には繰り返し立ち会うことになります。正直に言えば、そのたびに少し疲れます。ただ今回の作業を終えて、受け止め方が以前と変わったことに気づきました。
提供終了の期日は、自分の環境にどれだけの依存が積もっているかを強制的に可視化してくれます。日々の開発では依存は増える一方で、棚卸しの機会は自分から作らない限りやってきません。「6日後に止まる」という事実が、棚卸しを「いつかやる」から「今日やる」に変えてくれました。
変化の激しいエージェント開発の領域に身を置くと決めた以上、ツールは寿命を持つという前提で環境を設計しておくこと——依存を1箇所に集め、いつでも交換できるようにしておくこと——が、新しいものを恐れずに試すための土台になるのだと、いまは考えています。
もしまだ移行がお済みでない方は、agy のインストールよりも先に、シェル履歴とスクリプトを grep して依存箇所を数えるところから始めてみてください。私の場合は、その10分の棚卸しが、移行作業全体の見通しを決めてくれました。