カレンダーを見て、少し背筋が伸びました。2026年6月18日、Gemini CLI と Gemini Code Assist の IDE 拡張は、AI Pro・Ultra・無料個人向けのリクエスト処理を停止します。残りは6日です。
対話で使うだけなら、当日に Antigravity CLI へ乗り換えても大きな問題はありません。怖いのは、人間が見ていない場所です。深夜の cron、CI のジョブ、シェルスクリプトの奥に埋まった gemini -p の一行。これらは6月18日の朝、エラーログだけを残して静かに止まります。
私自身、個人開発で運営している複数サイトの更新パイプラインに Gemini CLI を組み込んでいた時期があり、今回の移行ではまず「どこで依存しているか自分でも正確に把握していない」という現実から始まりました。棚卸し、移行、検証の順に、実際にやったことを書き残します。
6月18日に止まるもの・止まらないもの
最初に範囲を正確にしておきます。対象を取り違えると、棚卸しの精度が落ちるためです。
止まるのは次の2つです。
- Gemini CLI（ターミナルの
gemini コマンド）— AI Pro・Ultra・無料個人向けのリクエスト処理が停止
- Gemini Code Assist の IDE 拡張 — 同様に提供終了
止まらないものも明確です。
- Gemini API そのもの — API キーで直接呼んでいるアプリケーションコードは影響を受けません
- Antigravity IDE / デスクトップアプリ — むしろ後継の中心です
- Antigravity CLI — Go 製の新しい CLI で、Agent Skills・Hooks・Subagents・Extensions を引き継ぎます
ここで重要なのは、「Gemini API を使うコード」と「Gemini CLI を呼ぶスクリプト」の区別です。SDK 経由で API を叩いている処理は対象外ですが、シェルから gemini コマンドを起動している処理はすべて対象になります。公式の経緯は Gemini CLI から Antigravity CLI への移行アナウンス にまとまっています。
まず「どこで依存しているか」を機械的に洗い出す
記憶を頼りに探すのはやめました。半年前に書いたスクリプトの中身は、半年前の自分しか知りません。
私が実際に流した棚卸しは、次の3段階です。
# 1. プロジェクトと設定ディレクトリから gemini コマンド呼び出しを検索
grep -rn --include="*.sh" --include="*.yml" --include="*.yaml" --include="*.mjs" \
-E '(^|[^a-zA-Z_-])gemini( |$|[^a-zA-Z_-])' \
~/projects ~/.config 2>/dev/null | grep -v node_modules
# 2. cron に登録されたジョブを確認
crontab -l 2>/dev/null | grep -n 'gemini'
# 3. シェル履歴から「手癖になっている使い方」も拾っておく
history | grep 'gemini -p' | tail -20
1 と 2 が止まると実害が出る箇所、3 は移行後に自分の手が迷う箇所です。検索パターンをやや厳しめにしているのは、gemini-api-client のようなパッケージ名や、antigravity-gemini のような複合語を誤検出しないためです。
このとき、見つかった依存を「対話的に使っているだけ」「スクリプトが無人で呼んでいる」の2つに仕分けしておくと、後の優先順位づけが楽になります。無人実行が最優先です。エラーに気づく人間がいないからです。
私の環境では、grep の結果は11箇所、うち無人実行は3箇所でした。数として大したことはないのですが、3箇所のうち1つは毎朝の定期実行に入っており、見落とせば確実に6月18日に止まっていたものです。
移行で実際に手が止まった3つの互換差分
Antigravity CLI は Gemini CLI の精神的な後継ですが、実装は Go 製の別物です。「コマンド名を置き換えれば終わり」と考えていると、私と同じ場所でつまずくと思います。順に書きます。
差分1: 設定ファイルは自動で引き継がれない
旧 Gemini CLI の ~/.gemini/settings.json は、Antigravity CLI からは読まれません。新しい設定は ~/.gemini/antigravity-cli/settings.json に置かれ、スキーマも変わっています。
移行前に、まず旧設定を退避しておきます。
# 旧設定とカスタム定義を丸ごとバックアップ
mkdir -p ~/cli-migration-backup
cp -r ~/.gemini ~/cli-migration-backup/gemini-$(date +%Y%m%d)
そのうえで、新しい設定は「旧設定の移植」ではなく「必要なものだけ書き直す」方針をおすすめします。私は旧 settings.json の項目を一つずつ眺めて、半分以上が「もう使っていない設定」だと気づきました。移行は棚卸しの好機でもあります。
差分2: 認証の前提が API キーから OAuth に変わる
Gemini CLI では .env の API キーで動かす運用が一般的でしたが、Antigravity CLI の初回セットアップは OAuth が基本線です。手元のターミナルなら、ブラウザで認可リンクを踏むだけなので迷いません。
問題は CI やサーバー上のヘッドレス環境です。ブラウザを開けない場所で OAuth フローは完結できません。ここでの私の判断は次のとおりです。
- 手元の Mac で動く cron — OAuth で認証を通し、トークンを保持させる（一度通せば更新は自動）
- CI 上のジョブ — CLI 経由をやめて Gemini API の直接呼び出しに書き換える。API はサービス終了の対象外なので、無人環境の依存はむしろ CLI から引き剥がしておくほうが長期的に安定します
「すべてを新 CLI に移す」のではなく、「無人環境は API 直叩きに寄せる」という仕分けが、今回の移行でいちばん効いた設計判断でした。CLI はあくまで人間の作業台であって、無人パイプラインの部品としては認証・更新の都合上、API より一段壊れやすい。そう割り切ってからは構成がすっきりしました。
差分3: 出力形式と終了コードの違いでパイプ処理が静かに壊れる
いちばん発見が遅れたのがこれです。旧 CLI の出力をそのまま jq や grep に流していた箇所は、新 CLI の出力に進捗表示や装飾が混ざることで、パースが静かにずれます。エラーにならず、空の結果が下流に流れていくのが厄介でした。
対処はシンプルで、スクリプトから呼ぶときは必ず出力形式を明示することです。
# 装飾なしの素のテキストを明示して受け取る
antigravity -p "リリースノートの下書きを3行で" --output-format text 2>/dev/null
あわせて、下流に渡す前に「空でないこと」を確認するガードを一行入れておくと、形式が変わったときに沈黙ではなくエラーで気づけます。
RESULT=$(antigravity -p "$PROMPT" --output-format text 2>/dev/null)
[ -n "$RESULT" ] || { echo "[NG] CLI 出力が空です" >&2; exit 1; }
移行後の検証をスモークテストとして残す
移行作業そのものより大事だと感じているのが、ここです。「移行した日に動いた」ことと「来週も動いている」ことは別の問題です。
私は次のような小さなスモークテストを書いて、毎朝の定期実行の先頭に置きました。
#!/usr/bin/env bash
# antigravity-smoke.sh — CLI が非対話モードで応答するかの生存確認
set -euo pipefail
VERSION=$(antigravity --version 2>/dev/null) || {
echo "[NG] antigravity コマンドが見つかりません" >&2; exit 1; }
OUT=$(antigravity -p "ok とだけ返してください" --output-format text 2>/dev/null) || {
echo "[NG] 非対話実行が失敗しました（認証切れの可能性）" >&2; exit 1; }
[ -n "$OUT" ] || { echo "[NG] 応答が空です（出力形式の変更を疑う）" >&2; exit 1; }
echo "[OK] ${VERSION} 応答確認済み"
確認しているのは3点だけです。コマンドが存在するか、認証が生きているか、出力が空でないか。たった十数行ですが、「認証トークンの失効」と「アップデートによる出力形式の変化」という、移行後に実際に起こりやすい2つの故障モードを朝の時点で検出できます。
個人開発の現場では、監視ダッシュボードを常に眺めている余裕はありません。パイプラインの本体が動く前にこのテストで止まれば、壊れた出力が下流に流れることはありません。逆にこれがないと、気づくのは「生成されたはずの成果物がない」と人間が違和感を覚えたときで、数日遅れることもあります。
ロールバック先がない移行、だからこそ前倒しで
通常のツール移行であれば、「問題が出たら旧バージョンに戻す」が保険になります。今回はそれが使えません。6月18日を過ぎれば、戻る先の Gemini CLI はリクエストを処理しなくなるからです。
ロールバック不能な移行で取れる安全策は、時間を保険にすることだけです。具体的には次の順番をおすすめします。
- 今日 — 棚卸しスクリプトを流し、依存箇所の一覧を作る（30分で終わります）
- 明日まで — 無人実行の3分類（新 CLI へ移行 / API 直叩きへ書き換え / 廃止）を決める
- 6月15日まで — 移行を済ませ、旧 CLI を呼ぶ箇所をゼロにする
- 6月16日〜17日 — 新構成のまま2日間、通常運転で並走させて様子を見る
- 6月18日 — 期限当日は「何もしない日」にする
ポイントは4の並走期間です。移行直後の1〜2日は、スモークテストと実際の成果物の両方を意識的に確認します。期限ぎりぎりに移行すると、この並走期間が取れず、問題が出たときに調査と修正を期限後の「もう戻れない状況」でやることになります。
締め切りのある移行は、締め切りの3日前に終わらせる。今回の件に限らず、個人開発のように一人で全部を見ている体制ほど、この余白が効くと感じています。
次のアクション
まずは棚卸しスクリプトの1番だけでも、今日のうちに流してみてください。結果が0件なら安心して6月18日を迎えられますし、1件でも出たなら、この週末が移行のちょうどよいタイミングになります。
同じ期限を前にしている方の参考になれば幸いです。