Gemini CLI 終了まで残り6日 — 自動化スクリプトの依存を棚卸しして Antigravity CLI へ移行する

6月18日の Gemini CLI 提供終了を前に、cron・CI・シェルスクリプトに潜む gemini コマンド依存を洗い出し、Antigravity CLI へ移行して検証するまでの実務手順を整理しました。

Antigravity CLI² Gemini CLI⁸ 移行³ 自動化¹⁴ CI/CD¹³ 運用設計⁷

✦ プレミアム記事

カレンダーを見て、少し背筋が伸びました。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日に止まっていたものです。

✦

ここまでお読みいただきありがとうございます。

この記事の続きを読む

この先には、実装コードやベンチマーク結果など、実務でお役に立てる内容をご用意しています。このサイトは広告を掲載しておらず、サーバーや開発にかかる費用はメンバーの皆様のご支援で成り立っています。もしお役に立てていましたら、ご支援いただけますと大変ありがたいです。

この記事で得られること

✦cron・CI・シェルスクリプトから gemini コマンド依存を機械的に洗い出す棚卸しスクリプトの実例

✦認証・設定ファイル・出力形式という、移行で実際に手が止まった3つの互換差分とその対処

✦ロールバック先が存在しない移行を安全に進めるためのスモークテスト設計と判断基準

Stripe による安全な決済 · いつでもキャンセル可能

✦

この記事を購入する

この先の内容をすべてお読みいただけます。一度のご購入で、いつでも何度でもアクセスできます。このサイトは広告を掲載しておらず、皆さまのご支援がサーバー費用などの運営を支えています。

または

メンバーシップなら全記事が読み放題 →

移行で実際に手が止まった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} 応答確認済み"