6 月 18 日で、無料の個人ユーザーと AI Pro / Ultra 向けに、Gemini CLI と Code Assist の IDE 拡張がリクエスト処理を止めます。この記事を書いている時点で、残りちょうど 2 日です。
最初にこの告知を見たとき、正直に言うと胃のあたりが少し重くなりました。私は Dolice Labs として複数のサイトを個人で回していて、その運用のところどころに Gemini CLI を組み込んでいたからです。ただ、慌てて移行スクリプトを書き始める前に、机に向かって一度だけ深呼吸をして、別のことをしました。「自分は CLI を、いったいどこで何のために呼んでいたのか」を紙に書き出すことから始めたのです。
締切が決まっている移行は、むしろ落ち着いて進められる
締切が見えていない技術的負債ほど、人を不安にさせるものはありません。「いつか直さないと」という宿題は、いつまでも宿題のまま心の隅に残ります。
その点で、6 月 18 日という明確な期限が切られた今回の移行は、私にとってはむしろ扱いやすいものでした。やるべきことの輪郭がはっきりしているからです。期限が決まっているなら、逆算してできることは限られます。残り 2 日でやるべきは、新しい仕組みを完璧に作り込むことではなく、止まったときに困る箇所を特定して、最小限の手当てをしておくことだと考えました。
完璧な移行を 2 日で狙うと、たいてい中途半端なものが本番に乗ります。私はこの順番を間違えないようにしています。
まず「どこで CLI を呼んでいたか」を一覧にした
頭の中で「あそこと、あそこで使っていたはず」と思い出すのは、いちばん危ない方法です。記憶は都合よく抜け落ちます。なので、リポジトリ全体を機械的に検索して、呼び出し箇所をすべて洗い出しました。
# 自動化スクリプト群から Gemini CLI / Code Assist の呼び出しを抽出する
# -n で行番号、-r で再帰、--include で対象ファイルを絞る
grep -rn --include="*.sh" --include="*.mjs" --include="*.py" \
-E "gemini (generate|chat|code|extensions)|code-assist" . \
> /tmp/cli_callsites.txt
# 何箇所あるか、どのファイルに集中しているかを把握する
wc -l /tmp/cli_callsites.txt
cut -d: -f1 /tmp/cli_callsites.txt | sort | uniq -c | sort -rn実際に走らせてみると、自分の記憶よりも呼び出し箇所は少なく、しかも数本のスクリプトに集中していました。これが分かっただけで、肩の力がだいぶ抜けました。「全体がべったり CLI に依存している」という漠然とした不安は、たいてい事実より大きく膨らんでいます。
直接依存が少なかったのは、過去の自分の小さな判断のおかげでした
なぜ呼び出し箇所が散らばっていなかったのか。理由を辿ると、以前に書いた小さなラッパー関数に行き当たりました。CLI を直接あちこちで叩くのではなく、run_gemini() のような薄い関数を一枚かませて、各スクリプトはその関数だけを呼ぶようにしていたのです。
当時は深い設計思想があったわけではなく、「コマンドのオプションを毎回書くのが面倒だったから」という、ほとんど横着に近い動機でした。それでも、外部ツールへの依存を一箇所に閉じ込めておいたおかげで、今回は差し替えるべき場所が一つに絞られました。
# 以前から使っていた薄いラッパー（呼び出し側はこれしか知らない）
run_gemini() {
local prompt="$1"
# ここだけを Antigravity CLI 向けに差し替えれば、呼び出し側は無傷
gemini generate --model gemini-3.5-flash --prompt "$prompt"
}外部依存を薄い層の裏に隠しておく、という習慣の効き目を、こういう移行のときに実感します。派手な設計ではありませんが、個人開発では「未来の自分が楽をできる小さな仕込み」がいちばん効く、と私自身は感じています。
載せ替える前に、挙動の差分を必ず確認する
移行先として案内されているのは Antigravity CLI です。ただ、「同じようなコマンドだから動くはず」と思い込んで本番のラッパーをいきなり書き換えるのは、私の中では禁じ手です。
私が必ずやるのは、新旧の出力を並べて見比べることです。同じプロンプトを両方に投げて、返ってくる文章の長さ・形式・終端の改行・エラー時の挙動が、自動化の後段の処理を壊さないかを確認します。とくに、出力を別のスクリプトがパースしている場合、わずかなフォーマットの違いが静かに連鎖して、気づかないうちに壊れた結果が積み上がっていく——これがいちばん怖いパターンです。
非推奨やシャットダウンに伴う移行で踏みがちな落とし穴は、Gemini API モデル非推奨・移行エラーの対処法に具体例をまとめています。今回のように手順を体系的に追いたい方は、Gemini CLI と Code Assist の個人向け終了に備える移行棚卸しも併せて読んでいただけたらと思います。
締切ドリブンの移行で、私が決めている 3 つのこと
何度かこうした「期限つきの移行」を経験するうちに、自分なりの小さなルールが固まってきました。
第一に、本番のスクリプトを書き換える前に、止まっても困らない退避手段を一つ用意しておくこと。たとえば該当の自動化を一時的に手動運用へ落とせるようにしておけば、移行に失敗しても被害が広がりません。
第二に、移行は「全部を一度に」ではなく「困る順に一つずつ」進めること。残り 2 日で全リポジトリを完璧にする必要はなく、止まったときにいちばん痛い箇所から手を付けます。
第三に、棚卸しの結果を必ず文字で残すこと。今回も cli_callsites.txt をそのまま作業メモに貼り付けました。次に似た移行が来たとき、過去の自分の記録ほど頼りになるものはありません。
次にやること
もしあなたも CLI を自動化に組み込んでいるなら、まずは移行先を探す前に、上の grep を一度走らせてみてください。呼び出し箇所の一覧を眺めるだけで、「何を、いつまでに、どこまで」やればいいのかが、不安だった頃よりずっと具体的に見えてくるはずです。期限のある移行は、落ち着いて棚卸しから始めれば、思っているほど怖くありません。