土曜の朝、いつものように夜間ジョブのログを眺めていて、前日と出力の体裁がほんの少し違うことに気づきました。プロンプトも入力データも変えていません。変わっていたのは一点だけ、agy が夜のあいだに v2.1.3 から v2.1.4 へ自動で上がっていたことでした。
Go で書き直された Antigravity CLI は全ユーザーへの提供が始まり、v2.1.x 系の更新が短い間隔で続いています。手元で対話的に使うぶんには、勝手に新しくなってくれるのはありがたい挙動です。けれど自動運用に組み込んだ CLI が「自分の知らないうちに別のバージョンになる」のは、再現性という観点では小さな落とし穴になります。
私は個人開発者として、Dolice Labs で運営する4つのサイトを夜間のオフピーク帯に自動更新しています。私自身、対話用と自動運用用で同じ CLI を別々に扱うようになったのは、ちょうどこの再現性のつまずきに気づいてからでした。各ジョブは人が見ていない時間に走るので、「昨日は通った処理が今朝は微妙に違う」ときに、原因がプロンプトなのか入力なのかツール自身なのかを切り分けられる状態にしておかないと、調査だけで午前が溶けてしまいます。
自動実行が「少しだけ違う」とき、最初に疑うのはツール自身です
再現性を一本の式で書くなら、自動パイプラインの出力は「バイナリ × プロンプト × 入力」で決まります。多くの人はプロンプトと入力には気を配ります。Git で履歴を残し、差分を見ます。ところが三つ目の「バイナリそのもの」は、いつのまにか更新される前提で運用から抜け落ちがちです。
特に CLI を自動化に組み込んでいると、バージョンが上がったこと自体に気づきにくくなります。対話的に使っていれば起動時のバナーで気づけますが、ヘッドレスで回しているとバナーは捨てられ、結果だけがログに残ります。だからこそ「いま走っているのはどのバイナリか」を、運用の側から能動的に記録しておく必要があります。
Go 製の単一バイナリだから、固定が驚くほど素直です
ここで効いてくるのが、Antigravity CLI が Go の単一バイナリで配布されているという性質です。Node 製のツールを固定しようとすると、node_modules やグローバルインストールの状態、Node 自体のバージョンまで絡んで話が大きくなりがちです。単一バイナリは違います。「そのファイルを取っておく」だけで、固定がほぼ完了します。
考え方はシンプルです。自動運用で使うバージョンを一つ決め、そのバイナリを既知のパスに置き、ジョブからは必ずそのパスを呼ぶ。最新版は手元の対話用として別に持っておき、自動運用とは混ぜない。これだけで「夜のあいだに勝手に上がる」経路を断てます。
バージョンを固定する最小の手順
まず、自動運用専用のバイナリ置き場を一つ決めます。ホームディレクトリ配下に固定用のディレクトリを作り、選んだバージョンをそこへ取り置きます。
# 自動運用が参照する固定パスを用意する
PIN_DIR="$HOME/.agy-pinned"
mkdir -p "$PIN_DIR"
# いま手元にある agy を、バージョン名つきで固定ディレクトリへ取り置く
VER="$(agy --version | grep -oE '[0-9]+\.[0-9]+\.[0-9]+')"
cp "$(command -v agy)" "$PIN_DIR/agy-$VER"
ln -sf "$PIN_DIR/agy-$VER" "$PIN_DIR/agy"
echo "pinned: agy-$VER -> $PIN_DIR/agy"ポイントは、$PIN_DIR/agy をシンボリックリンクにして、その実体にバージョン名を持たせていることです。こうしておくと、後でバージョンを上げたくなったときにリンクの張り替えだけで切り替えられ、古いバイナリも agy-2.1.3 のまま残るので、すぐ元へ戻せます。
スケジュールジョブ側は、PATH 任せにせず、この固定パスを明示的に呼びます。
# ❌ 望ましくない例：PATH 上の agy を呼ぶ（夜間に上がっていても気づけない）
agy run ./pipeline.task
# ✅ 望ましい例：固定したバイナリを明示的に呼ぶ
AGY="$HOME/.agy-pinned/agy"
"$AGY" run ./pipeline.task上の二つは一見ほとんど同じですが、意味はまるで違います。前者は「そのマシンにたまたま入っている agy」に依存します。後者は「自分が選んで取り置いた一本」に固定されます。自動運用で守りたいのは後者です。
各ランのログに、バイナリの素性を残す
固定しただけでは半分です。後から「この出力を出したのは本当にそのバージョンだったのか」を確かめられるよう、各ランの冒頭でバイナリの素性をログへ刻みます。バージョン文字列だけでなく、ファイルのハッシュも一緒に残すのがおすすめです。同じバージョン名でも中身が差し替わっていれば、ハッシュが変わって気づけます。
AGY="$HOME/.agy-pinned/agy"
# ランの先頭で、使うバイナリの素性をログに残す
{
echo "run_started: $(TZ=Asia/Tokyo date '+%Y-%m-%d %H:%M:%S %Z')"
echo "agy_version: $("$AGY" --version | tr -d '\n')"
echo "agy_sha256: $(sha256sum "$AGY" | awk '{print $1}')"
} >> run.log
"$AGY" run ./pipeline.task >> run.log 2>&1これを習慣にしておくと、冒頭で書いた「前日と少しだけ違う」場面で、ログの agy_version と agy_sha256 を二日ぶん並べるだけで、ツールが動いたのか動いていないのかが一目で分かります。原因の切り分けにかかる時間が、体感でいちばん縮みました。
固定の有無で、運用がどう変わるかを並べてみます。
| 観点 | 固定なし（PATH 任せ） | 固定あり（取り置き＋記録） |
|---|---|---|
| 夜間の自動更新 | 気づかないまま挙動が変わりうる | 更新は手動の張り替えのみ |
| 出力が変わった原因 | ツールか入力か切り分けづらい | ログのバージョンとハッシュで即判別 |
| 元へ戻す手間 | 過去バイナリが残らず困難 | リンクを旧バージョンへ張り替えるだけ |
上げるときは「一本だけ」先に通す
固定は「更新しない」という意味ではありません。CLI の改善は素早く取り込みたいものです。私が意識しているのは、上げる順番です。複数のジョブを一度に新バージョンへ移すのではなく、影響のいちばん小さいジョブを一本だけ先に新バイナリへ向け、数日ぶん走らせて出力が崩れないことを見届けてから、残りへ広げます。
# 新バージョンを「固定ディレクトリ」に取り置く（リンクはまだ張り替えない）
agy --version # 例: 2.1.5 に更新済みの手元 agy
cp "$(command -v agy)" "$HOME/.agy-pinned/agy-2.1.5"
# まず1ジョブだけ新バイナリを明示指定して試す
NEW="$HOME/.agy-pinned/agy-2.1.5"
"$NEW" run ./low-risk.task >> trial.log 2>&1
# 数日問題なければ、本線のリンクを張り替えて全体へ展開する
ln -sf "$HOME/.agy-pinned/agy-2.1.5" "$HOME/.agy-pinned/agy"この「一本だけ先に通す」進め方は、Gemini CLI から Antigravity CLI へ移るときにも私が頼った段取りそのものです。切り替え前に出力を突き合わせたい場合は、旧CLIと同じ結果が出るか — Antigravity CLI へ切り替える前に組む出力照合ゲートで組んだ照合の考え方が、新旧バージョンの比較にもそのまま使えます。速度面が気になる方はGo 製 Antigravity CLI の応答性を実測して、夜間バッチの組み方を見直すも合わせてどうぞ。
次の一歩としては、いま自動で走っているジョブのうち一つを選び、固定ディレクトリを作って今日のバージョンを取り置き、ランのログに agy_version と agy_sha256 を一行ずつ足すところから始めてみてください。再現性は、特別な仕組みより「いま動いている一本を記録しておく」という小さな習慣から積み上がっていきます。スケジュール実行の任せ方そのものを見直したくなったら、Antigravity CLI 移行後、スケジュール実行をどこまで任せるかの棲み分け設計も手がかりになるはずです。
同じように夜間の自動運用と付き合っている方の、調査の時間を少しでも減らせれば幸いです。