本日6月18日、Gemini CLI と Gemini Code Assist IDE 拡張が、無料の個人利用と AI Pro / Ultra 向けのリクエスト提供を終了し、後継の Antigravity CLI へ統合されます。CLI を使った自動化を組んでいる人にとっては、今日が切り替えの節目です。
ここで多くの移行検証がやりがちなのが、新旧の標準出力を比べて「同じ文字列が出るか」を見ることです。私自身、最初はそれで十分だと思っていました。ところが、自動化が実際に価値を生むのは標準出力ではなく副作用——ファイルを書き、コミットを作り、外部 API を叩く部分です。出力が一字一句同じでも、書き込み先が1つずれていれば本番は壊れます。だから検証は、出力ではなく副作用の等価性で行うべきです。
なぜ出力一致では足りないのか
CLI エージェントの仕事は、たいてい画面に何かを表示することではありません。リポジトリにファイルを生成し、変更をコミットし、デプロイ用の API を呼ぶ。標準出力はそのついでに流れるログにすぎません。
つまり、出力の一致は「同じことをログに書いた」ことしか保証しません。新旧 CLI が内部でツールを呼ぶ順番や引数が微妙に変わっていても、ログが似ていれば気づけない。私はこの落とし穴に一度ハマって、出力は同じなのに書き込んだファイルのパスだけが違う、という事故に近い状況を経験しました。
副作用を3つの面で捉える
副作用は、観測できる3つの面に分けると扱いやすくなります。この3面が新旧で一致すれば、本番に載せても挙動は同じだと言えます。
このうち最も事故が多いのはファイル面です。出力検証ではまず捕まえられません。
サンドボックスで両CLIを同じ入力に当てる
検証は、本番とは隔離した作業ディレクトリで行います。同じ入力（プロンプトと対象リポジトリのコピー）を、新旧それぞれの CLI に与え、終わったら状態を比べます。
#!/usr/bin/env bash set -euo pipefail INPUT_PROMPT = " $1 " # 同一のタスク指示 SRC = " $2 " # 対象リポジトリ
run_one () { local cli = " $1 " outdir = " $2 " rm -rf " $outdir " && cp -r " $SRC " " $outdir " ( cd " $outdir " && " $cli " run --prompt " $INPUT_PROMPT " \ > "../$( basename " $outdir ").stdout" 2>&1 ) }
run_one gemini sandbox_old # 旧CLI run_one agy sandbox_new # Antigravity CLI（後継） echo "両CLIの実行が完了しました。副作用を比較します。" ポイントは、毎回まっさらなコピーから始めることです。前回の残骸が混ざると、差分が CLI の違いなのか実行順の違いなのか判別できなくなります。
書き込んだファイルの差分を取る
実行後、2つのサンドボックスを丸ごと比較します。diff -r で十分です。ここで差分がゼロなら、ファイル面の副作用は等価です。
# ファイル面の等価性チェック（.git は別途比較するので除外） if diff -r --exclude=.git sandbox_old sandbox_new > file_diff.txt ; then echo "✅ ファイル副作用: 等価" else echo "❌ ファイル副作用に差分あり:" head -40 file_diff.txt fi
# Git面: 生成されたコミットの diff を比較 ( cd sandbox_old && git diff HEAD~1 HEAD ) > old.patch 2> /dev/null || true ( cd sandbox_new && git diff HEAD~1 HEAD ) > new.patch 2> /dev/null || true diff old.patch new.patch && echo "✅ Git副作用: 等価" || echo "❌ コミット内容に差分あり" 私はこの diff を最初に回したとき、本文は完全に一致しているのに改行コードだけ CRLF と LF で割れている、という差分に出くわしました。出力検証なら絶対に見逃していた違いです。こうした細部こそ、本番でビルドを壊します。
ネットワーク呼び出しの等価性を確認する
3面目はネットワークです。新旧で叩く宛先や回数が変わると、レート制限や課金に直結します。送信プロキシを1枚かませて、アクセスログを比べるのが確実です。
宛先ホストとメソッドの集合が一致しているか、呼び出し回数が大きくずれていないかを見ます。経験上、回数が約20%以上ずれていたら、内部のツール呼び出し設計が変わったサインです。等価でないまま本番に載せると、想定外の課金やレート制限を踏みます。経験上ここは厳しめが安全で、私は20%を上限の目安として推奨します。
切り替え可否を機械判定するゲート
最後に、3面の結果を1つの判定にまとめます。当日の切り替えは、人の「たぶん大丈夫」ではなく、ゲートの合否で決めます。
ファイル面の diff -r がゼロ差分か
Git のコミット diff が一致するか
ネットワークの宛先集合が一致し、回数の乖離が20%以内か
3つすべてが緑なら切り替え可。1つでも赤なら保留し、差分の原因を特定してから再検証する
このゲートを通したものだけを本番のスケジュールに載せ替えます。私は Dolice Labs の自動化をこの手順で1本ずつ切り替え、出力は同じでも副作用が割れていた2本を事前に止められました。もし出力一致だけで判断していたら、その2本はそのまま本番で壊れていたはずです。
切り替えの締切に追われると、つい「動いたから大丈夫」で済ませたくなります。けれども本番を守るのは、動いたという感触ではなく、副作用が等価だという証拠です。今日の切り替えでは、まず1本だけでもこのゲートに通してみてください。緑が出てから載せ替える、その順番が事故を防ぎます。