Antigravity は 7 月初頭に、複数のビルドを同じ日に公開しました。2.1.4 のような新機能寄りの系統と、2.0.11 のような安定寄りの系統が、並行して更新されていく体制です。これは歓迎すべき変化ですが、個人で使う側には新しい宿題が生まれました。どちらのラインに乗るのかを、自分で決めなければならないのです。
自動投稿や定期バッチをエージェントに任せている人ほど、この判断は重くなります。新機能は魅力的ですが、更新のたびに挙動が変われば、夜間に静かに回っていた処理が翌朝には黙って失敗しているかもしれません。二系統のビルドをどう選び、どう安全に切り替えるかを、ここから設計していきます。
2つのビルドラインが並行する意味
安定系と新機能系が分かれるのは、目的が違うからです。安定系は「今日と同じ挙動を明日も保つ」ことに寄せて、修正を絞って取り込みます。新機能系は「新しい能力を早く試せる」ことに寄せて、変更を積極的に入れます。どちらが上でも下でもなく、使う場面が違うだけです。
問題は、両方を一つのマシンで無自覚に混ぜてしまうことです。手元で新機能を試すつもりが、そのまま自動処理の実行環境も更新してしまえば、探索の代償を運用が払わされます。だから最初に決めるのは「どの作業をどちらに乗せるか」です。
| 作業の性質 | 推奨ライン | 理由 |
|---|---|---|
| 夜間バッチ・定期実行・自動投稿 | 安定系(2.0) | 挙動の一定さが最優先。変更は少ないほどよい |
| 手を動かす探索・新機能の試用 | 新機能系(2.1) | 失敗しても人間がその場で気づける |
| 本番リリース前の最終確認 | 安定系(2.0) | 再現性のある環境で通したい |
バージョンを固定し、起動前に突き合わせる
「安定系に乗る」と決めても、勝手に上がってしまえば意味がありません。まず、使うバージョンをプロジェクトに書き留めます。人が読める一つのファイルに固定版を宣言し、自動処理の起動時に、実際に入っている版と突き合わせます。ズレていれば処理を始めずに止めます。
// .antigravity-version.json — このプロジェクトが乗るビルドを宣言
{
"line": "stable",
"pinned": "2.0.11",
"allowPatchDrift": false
}#!/usr/bin/env bash
# preflight.sh — 自動処理の先頭で呼ぶ。固定版と実際の版を突き合わせる
set -euo pipefail
PIN=$(grep '"pinned"' .antigravity-version.json | sed -E 's/.*: *"([^"]+)".*/\1/')
ACTUAL=$(antigravity --version 2>/dev/null | grep -oE '[0-9]+\.[0-9]+\.[0-9]+' | head -1)
if [ "$PIN" != "$ACTUAL" ]; then
echo "⛔ バージョン不一致: pinned=$PIN actual=$ACTUAL" >&2
echo " 自動処理を中止します。切替を意図した場合は .antigravity-version.json を更新してください。" >&2
exit 1
fi
echo "✅ バージョン一致: $ACTUAL で実行します"このプリフライトの価値は、「知らないうちに上がっていた」を「止まって気づける」に変えることです。失敗を静かに垂れ流すより、始まる前に大きな声で止まるほうが、放置運用では圧倒的に安全です。私はこの一手間を、自動処理を任せる前提の保険だと考えています。バージョンがずれた状態で夜間に走り続けるより、朝に一度止まってくれるほうが、結果として手戻りは小さく済みます。