Gemini CLI 停止に備えて、既存スクリプトを止めずに agy へ寄せる互換シム

困るのは、gemini というコマンド名が cron・CI・Makefile・古いメモの中に散らばっていて、どこから呼ばれているのか自分でも全部は把握できていない、という状態でした。提供終了の日に一斉置換しようとすると、必ず数本が漏れて深夜に静かに失敗します。個人開発で自動投稿のパイプラインを回していると、この「漏れた一本」が翌朝まで気づけません。

そこで私は、全箇所を直接書き換える前に、gemini という名前のまま中身だけ agy（Antigravity CLI）に流す薄い互換シムを一枚かませました。これで締切に追われず、呼び出し元を一本ずつ落ち着いて移せます。

なぜ一斉置換ではなくシムなのか

gemini から agy への移行で本当に怖いのは、コマンドが消えること自体ではなく、「呼び出し元の全リストを正しく持っていない」ことです。grep で拾えるのはリポジトリ内だけで、crontab・systemd タイマー・別マシンのスクリプトは漏れます。

シムは、この不確実性を時間で吸収する仕組みです。古い名前を残したまま新しい実装へ委譲し、移行の締切（6/18）と、自分が全呼び出し元を直す締切を切り離します。コマンドが消える日までに「名前の互換」さえ確保できていれば、中身の移行は自分のペースで進められます。

フラグの対応表を先に作る

シムを書く前に、自分が実際に使っているフラグだけ対応表にします。全フラグを網羅する必要はありません。使っていないものを移しても意味がないからです。私のパイプラインで使っていたのは次の4つだけでした。

-p / --prompt（プロンプト文字列）→ agy run -p
-m / --model（モデル指定）→ agy run -m
--json（機械可読出力）→ agy run --format json
-f / --file（入力ファイル）→ agy run --input

ここで大事なのは、出力形式の差です。旧 CLI の --json と新 CLI の --format json ではキー名や階層が変わることがあります。後段でパースしているなら、シムを通した直後に一度だけ実出力を目視し、jq のパスがそのまま使えるか確認してください。ここを飛ばすと、コマンドは成功しているのに後段が静かに空を掴む、という最悪の失敗をします。

互換シム本体（drop-in 置き換え）

gemini という名前で PATH の先頭に置く実行ファイルを用意します。引数を解釈して agy に渡し直すだけの薄い層です。

#!/usr/bin/env bash
# /usr/local/bin/gemini  ← 旧コマンド名で PATH の先頭に置く
# 役割: 旧 gemini の呼び出しを agy run へ橋渡しする互換シム
set -euo pipefail
 
# 本物の agy を解決（無ければ即座に分かるように落とす）
AGY="$(command -v agy || true)"
if [ -z "$AGY" ]; then
  echo "gemini-shim: agy が見つかりません。Antigravity CLI を導入してください。" >&2
  exit 127
fi
 
args=()
while [ $# -gt 0 ]; do
  case "$1" in
    -p|--prompt) args+=( -p "$2" ); shift 2 ;;
    -m|--model)  args+=( -m "$2" ); shift 2 ;;
    -f|--file)   args+=( --input "$2" ); shift 2 ;;
    --json)      args+=( --format json ); shift ;;
    -h|--help)
      echo "gemini-shim → agy run の互換層。未知のフラグはそのまま透過します。" >&2
      shift ;;
    *)           args+=( "$1" ); shift ;;   # 未知の引数はそのまま渡す
  esac
done
 
# 移行の可視化: シム経由の呼び出しを記録し、残った呼び出し元を炙り出す
echo "$(date -Iseconds) shim-call: $*" >> "${HOME}/.gemini-shim.log"
 
exec "$AGY" run "${args[@]}"

exec で置き換えているのは、終了コードとシグナルを agy のものへ素通しするためです。間にもう一段プロセスを挟むと、CI が終了コードを誤判定したり、タイムアウトのシグナルが届かなかったりします。

ログを「残った呼び出し元」の地図として使う

このシムの隠れた主役は、最後のログ行です。シム経由の呼び出しを記録しておくと、数日運用するだけで「実際にどこから gemini が呼ばれているか」が自然に集まります。grep で見つからなかった crontab や別スクリプトも、動けば必ずログに足跡を残します。

# 直近1週間で gemini を呼んだ実体を集計し、移行残のリストにする
sort "${HOME}/.gemini-shim.log" | awk '{$1=""; print}' | sort | uniq -c | sort -rn

私はこの集計を見て、リポジトリ内には無かった古いバックアップ用 cron が一本残っていたことに気づきました。静的な grep では永遠に見つからなかった一本です。移行の進捗を「呼び出し元が何本残っているか」で測れるようになると、締切前の不安がかなり減ります。

シムを外すタイミングの見極め

シムはあくまで橋であって、終着点ではありません。ログの集計が数日連続でゼロになったら、呼び出し元はすべて agy 直叩きに移し終わったと判断できます。

# 過去3日間シム経由の呼び出しがゼロなら、撤去候補
RECENT=$(awk -v cut="$(date -d '3 days ago' -Iseconds)" '$1 > cut' "${HOME}/.gemini-shim.log" | wc -l)
[ "$RECENT" -eq 0 ] && echo "シム経由の呼び出しなし → /usr/local/bin/gemini を撤去できます"

撤去まで含めて初めて移行が完了します。シムを入れたまま放置すると、本来直すべき呼び出し元が「動いているから」と温存され、いつまでも二重管理になります。ここはあえて期限を決めて外しました。

まずやるべきは、自分が実際に使っているフラグを4〜5個だけ書き出し、上のシムをその範囲で動かすことです。完璧な互換を目指す必要はありません。6/18 の停止までに「名前さえ生きていれば中身は後で移せる」状態を作っておけば、締切に追われる移行から解放されます。同じく自動化スクリプトの移行を控えている方の役に立てば嬉しいです。