6月18日に Gemini CLI と Gemini Code Assist の IDE 拡張がリクエスト受付を終え、移行先が Antigravity に一本化されました。エディタを手で触っているだけなら、新しい画面に慣れる時間の問題で済みます。
問題は、CLI を定期実行に組み込んでいる場合です。私自身、4つのブログサイトの記事生成とデプロイを毎日スケジュールで回しているため、停止日が決まっている移行は「いつ新しい画面を覚えるか」ではなく「動いている処理をどう止めずに載せ替えるか」という運用の問題になりました。
ここでは、稼働中の自動運用を止めないまま大型更新へ移るための段取りを、私が実際に踏んだ順序で整理します。
移行日が決まっている更新は「切り替え」ではなく「並走」で考える
締め切りがある移行で一番危ないのは、期限の前日にまとめて切り替えることです。新環境で初めて流すジョブが、たまたまその日の本番処理になってしまう。これが一番避けたい形です。
私は移行を「ある日を境に旧から新へ乗り換える」操作だとは考えていません。「新旧を一定期間並べて走らせ、出力が一致することを確認してから旧を畳む」という、重なりのある工程として設計します。
並走期間を取れるかどうかは、移行の安全性をほぼ決めてしまいます。期限が公表されたら、まず逆算して「いつから並走を始めれば、期限までに十分な回数を比較できるか」を先に決めます。
並走期間に確認するのは「出力が同じか」だけ
並走中に見るべき指標は、突き詰めると一つです。同じ入力を与えたとき、新環境が旧環境と同じ成果物を出すか。
私の場合、記事生成パイプラインの最終成果物は MDX ファイルと、それを検証する品質ゲートの合否です。なので比較も成果物どうしで行います。新旧それぞれに同じトピックを渡し、生成された MDX を機械的に差分で突き合わせます。
# 旧環境(gemini)と新環境(agy)に同じ入力を渡し、成果物を比較する
INPUT="content/_fixtures/sample_topic.json"
gemini run generate --input "$INPUT" --out /tmp/out_old
agy run generate --input "$INPUT" --out /tmp/out_new
# フロントマターと本文の構造が一致するかを差分で確認
diff <(grep -E '^(title|slug|category|level|premium):' /tmp/out_old/*.mdx) \
<(grep -E '^(title|slug|category|level|premium):' /tmp/out_new/*.mdx) \
&& echo "✅ frontmatter parity" || echo "⚠️ frontmatter drift — 要確認"
# 生成本文の文字数が極端にずれていないか(±15%以内を目安)
OLD=$(wc -m < /tmp/out_old/body.txt); NEW=$(wc -m < /tmp/out_new/body.txt)
echo "old=$OLD new=$NEW ratio=$(awk "BEGIN{printf \"%.2f\", $NEW/$OLD}")"
文章そのものは生成のたびに変わるので、一字一句の一致は求めません。見るのは構造の同値です。フロントマターの必須フィールドが揃っているか、本文の分量が想定の範囲か、品質ゲートを同じように通過するか。この3点が安定して一致すれば、出力は実用上同じと判断します。
ロールバック経路を先に用意してから移行する
並走と同じくらい大切なのが、戻り道です。新環境に切り替えた後で問題が出たとき、数分で旧環境に戻せる状態を、移行を始める前に作っておきます。
ここでつまずきやすいのが、旧環境を消してしまうことです。「移行したのだから古い方は不要」と早々にアンインストールすると、いざ戻したいときに戻せません。私は旧環境を、並走期間が終わってさらに1週間ほど経つまで残しておきます。
ロールバックは手順書ではなく、1コマンドで戻せるところまで落とし込んでおくのが安全です。
# スケジュール実行が参照するランナーをシンボリックリンクで切り替える
# 切り替え: 新環境へ
ln -sfn "$(which agy)" /usr/local/bin/site-runner
# ロールバック: 旧環境へ即座に戻す
ln -sfn "$(which gemini)" /usr/local/bin/site-runner
スケジュールタスク側は常に site-runner を呼ぶようにしておき、実体だけをリンクで差し替えます。こうしておくと、切り替えもロールバックも同じ一行で済み、深夜の自動実行で異常が出ても、翌朝リンクを戻すだけで前日の状態に復帰できます。
環境を壊さないためにバージョンを固定する
2.0 への更新で既存のセットアップが一度に変わった、という報告が移行初期にいくつも出ました。大型更新では、知らないうちにツールの挙動やデフォルトが変わり、昨日まで通っていた処理が静かに失敗することがあります。
これを避ける一番の方法は、バージョンを明示的に固定することです。私は移行検証の間、新環境のバージョンを固定し、検証が済むまで自動更新に任せないようにしています。
固定すべき対象を整理すると、次のようになります。
| 対象 | 固定しないと起きること | 対処 |
|---|
| CLI 本体のバージョン | 更新で引数やデフォルトモデルが変わり処理が失敗 | 検証中はバージョンを固定し、更新は手動で適用 |
| 呼び出すモデル | 自動で新モデルに切り替わり出力傾向が変化 | モデル名を明示指定し暗黙のデフォルトに頼らない |
| 設定ファイルの場所 | 移行で設定パスが変わり旧設定が読まれない | 移行前後で設定ファイルの実体を diff で確認 |
固定は永続的な方針ではありません。検証期間中だけの安全装置です。出力の同値が確認できたら、固定を外して通常の更新運用に戻します。順序が逆だと、移行と更新の変化が混ざって、どちらが原因か切り分けられなくなります。
4サイトを1つずつ段階導入した順序
私は4サイトを同時に移行しませんでした。一度に全部を新環境へ移すと、もし問題が出たとき4サイト分の運用が同時に止まります。被害の範囲を小さく保つために、影響の小さいところから順に移しました。
実際の順序は次の通りです。
- まず更新頻度が最も低いサイトを新環境へ移し、1週間並走させて出力を比較する
- 問題がなければ次に、トラブルが出ても気づきやすい中規模のサイトを移す
- 旧環境と新環境の成果物が3回連続で同値だったサイトから、旧環境の呼び出しを畳む
- 最後に、最も更新頻度が高く影響の大きいサイトを移す
- 全サイトの移行後も旧環境は1週間残し、想定外の挙動が出ないことを確認してから削除する
この順序の狙いは、最初の1サイトを「練習台」にすることです。最初のサイトで踏んだ落とし穴は、たいてい残りのサイトでも踏みます。1サイト目で対処法を固めておけば、2サイト目以降は同じ手順をなぞるだけになり、本番運用への影響を最小化できます。
移行を急がない判断の基準
期限が公表されると、つい早く全部を移して終わらせたくなります。けれど移行の目的は「期限に間に合わせること」ではなく「運用を止めないこと」です。
私は次のいずれかに当てはまる間は、本番の自動運用を新環境に全面移行しません。並走での出力比較が3回に満たない。ロールバックを1コマンドで実行できる状態になっていない。旧環境を即座に呼び戻せない。この3つは、移行の安全を支える最低条件だと考えています。
逆に、この3つが揃えば、期限ぎりぎりであっても落ち着いて切り替えられます。大型更新は焦って一気に渡るほど、戻れなくなったときの代償が大きくなります。重なりを作り、戻り道を確保し、影響の小さいところから慣らす。地味ですが、稼働中の運用を抱えた個人開発では、これが結局いちばん速い移行になると感じています。
並走と段階導入は手間に見えますが、深夜に自動処理が止まって朝に気づく、という事態を避けられるなら十分に見合う投資です。私はこの並走と段階導入の進め方を、個人開発の自動運用にそのまま取り入れています。同じように定期運用を抱えている方の参考になれば幸いです。