開発マシンを買い替えた日の夕方、新しい Mac で Antigravity にサインインし、Settings Sync が走るのを眺めていました。テーマもキーバインドも拡張も、ものの数分で手元に戻ってきます。ここまでは拍子抜けするほど順調でした。
ところが最初のエージェント実行で認証を求められ、慣れたはずのワークスペース内検索は空振りし、ローカル LLM のモデルはひとつも見つかりません。設定画面の見た目は昨日までと同じなのに、中身はまるで初対面の相手のように振る舞う。この「見た目だけ戻っている」状態が、移行当日の私を一番戸惑わせました。
原因をたどると、私は「同期で戻る範囲」を過信していたのだと思います。Antigravity の環境は一枚岩ではなく、性質の違う三つの層でできている——移行を終えたいま振り返ると、最初にこの区別を持っていれば、当日の手戻りの大半は避けられました。個人開発で複数のアプリと Dolice のサイト群を一人で見ている身としては、移行に丸一日溶かすわけにはいきません。同じ場面を控えている方のために、層の分け方から当日の順序までを整理しておきます。
環境は性質の違う三つの層でできている
移行の計画を立てる前に、いま使っている環境を三つに仕分けます。基準は「その状態がどこに保存されているか」です。
| 層 | 代表例 | 移行時の扱い |
|---|---|---|
| 同期される層 | 設定・キーバインド・拡張・テーマ | Settings Sync が運んでくれる。事前確認だけで持ち越せます |
| マシンに縛られる層 | OS キーリング内の認証トークン・ワークスペースのインデックス・ローカル LLM のモデル | コピーせず、新しいマシンで作り直します |
| リポジトリに置ける層 | AGENTS.md・プロジェクト固有のスキルやタスク定義 | git clone とともに戻る。移行の影響をそもそも受けません |
この三分法の要点は、真ん中の「マシンに縛られる層」を持ち越そうとしないことです。ファイルコピーで無理に運ぼうとすると、認証は静かに壊れ、インデックスは中途半端な状態で引き継がれます。作り直すものは最初から作り直すと決めておくほうが、結果として速く終わります。
持ち越せる層は、旧マシンで「最後の同期」を確かめてから
Settings Sync に任せられる層は、新しいマシン側では何もすることがありません。気を配るのは旧マシン側です。箱を開ける前に、旧マシンで直近の変更が同期済みかを確認しておきます。
コマンドパレットから Settings Sync: Show Sync Activity を開き、Last Synced が直近の作業時刻より新しいことを見る。それだけの一手間ですが、私はここを飛ばしたせいで、前週に調整したばかりのキーバインドだけが旧マシンに取り残されました。同期の状態確認や、そもそも Sync が動いていないときの切り分けは Antigravityの設定がデバイス間で同期されない — Settings Syncが効かない時の原因と修復手順 に詳しくまとめています。
拡張機能も同期対象に含まれますが、ネイティブ依存を持つものは新しいマシンで初回起動時に再ビルドが走ることがあります。一覧が戻った直後に全部を信用せず、よく使うものから順に一度ずつ動かして確かめるのが堅実です。
作り直す層は、コピーではなくやり直す
戸惑いの中心だったのがこの層です。順に見ていきます。
認証トークン。v2.2.1 以降、更新された OAuth トークンは OS のキーリング（macOS ならキーチェーン）へ保存されます。キーリングはマシン固有の保管庫なので、設定ファイルをどれだけ丁寧にコピーしても認証は戻りません。新しいマシンで普通にサインインし直し、キーリングに新しいトークンを作らせるのが正道です。旧マシンからトークンらしきファイルを探して移す、という発想はセキュリティ面でも運用面でも持たないほうがよいと考えています。
ワークスペースのインデックス。初めて開くリポジトリは、裏でインデックス構築が走ります。規模の大きいリポジトリだと完了までしばらくかかるため、私は移行当日、一番大きいワークスペースを最初に開いてそのまま放置し、その間に他のセットアップを進めました。インデックスがいつまでも終わらない場合の診断は Antigravity の Workspace Indexing が止まる・完了しない時の診断と修復手順 が使えます。
ローカル LLM のモデル。Ollama などで運用しているモデルは、数 GB 単位のファイル群です。帯域に余裕があるなら pull し直すのが一番確実で、モデルフォルダの直接コピーは、バージョン管理のメタデータがずれると原因の見えにくい不調につながります。私は結局、常用している 2 つのモデルだけを pull し直し、残りは必要になったときに取ることにしました。全部を初日に揃えようとしないのも、移行を軽くするコツだと感じます。
リポジトリへ逃がしておくと、次の移行はもっと軽い
三つ目の層は、今回の移行で一番ありがたみを実感した部分です。エージェントへの指示の前提になる AGENTS.md、プロジェクト固有のスキルやタスク定義をリポジトリ側に置いてあったので、git clone した瞬間にエージェントの「振る舞い」だけは旧マシンと同じに戻りました。
逆に言うと、エディタのローカル設定に書き溜めたプロンプトの断片や、マシンのホームディレクトリに置いたメモは全部置き去りになります。移行を機に「これはマシンの持ち物か、プロジェクトの持ち物か」を仕分けて、プロジェクトの持ち物はリポジトリへ移す。AGENTS.md を運用の中心に置く考え方は AGENTS.md は週1の失敗ログレビューで磨き続ける — Antigravity を賢くしていく運用ループ で書いたループとも地続きです。エディタに縛られる状態を減らすほど、マシン移行は「サインインとクローンだけ」に近づいていきます。
当日の順序と、私がつまずいた一点
最後に、実際にやってみて落ち着いた順序を残しておきます。
- 旧マシンで Settings Sync の Last Synced を確認してから電源を落とす
- 新しいマシンで Antigravity にサインインし、キーリングに認証を作り直す
- 主要リポジトリを clone し、一番大きいワークスペースを開いてインデックスを放置
- その間に拡張の動作確認と、常用するローカル LLM モデルの再取得
- 最後に小さなタスクをひとつエージェントに投げ、認証・検索・モデルの三点が生きていることを確かめる
ひとつだけ想定外だったのは、Antigravity 本体のサインインが済んでも、git の署名鍵と gh コマンドの認証は別物として残っていたことです。最初にエージェントへ任せた push を含むタスクが、コミット署名の段階で止まりました。エージェント経由の操作は Antigravity の認証だけで完結するように錯覚しがちですが、足元のツールチェーンの認証は一つずつ別に戻す必要があります。移行チェックリストには「git config と gh auth の再設定」も一行入れておくことをおすすめします。
次にマシンを替える日が来たら、まず白紙に三つの層を書き出して、自分の環境がどこに何を抱えているかを棚卸しするところから始めてみてください。移行そのものより、この棚卸しのほうが価値のある作業かもしれません。本記事がその下書きになれば幸いです。