Antigravityの設定がデバイス間で同期されない — Settings Syncが効かない時の原因と修復手順

メインのデスクトップとモバイルワーク用のノート PC で、同じテーマ・同じキーバインド・同じ拡張機能をそのまま使いたい。それだけのはずなのに、ノート PC 側の Antigravity を立ち上げると、まるで別のエディタを触っているような状態になっている — Settings Sync を有効にしたあとも、こうした症状はかなりの頻度で発生します。

私自身、外出先でちょっとした記事用のサンプルコードを書こうとしたときに、なぜか手元の補完ショートカットが効かず、結局 30 分ほど Settings Sync の調査に費やしてしまったことがあります。問題は単純な「同期が遅い」ではなく、認証・ローカルストレージ・ネットワーク・対象スコープの 4 層のどこかで詰まっていることが多いのです。

ここでは私が複数のデバイスで Antigravity を運用しながら遭遇したトラブルを、上から順に切り分けていく流れで紹介します。「とりあえず Sign Out して Sign In し直す」より一段上の精度で、再発を防ぐところまで持っていく手順です。

まず Settings Sync の「現在の状態」を確認する

問題を切り分ける前に、いま Sync が「どこまで動いていると Antigravity 自身が思っているか」を見ます。コマンドパレットを開いて以下を順番に確認してください。

Cmd/Ctrl + Shift + P → Settings Sync: Show Sync Activity を実行
表示されたパネルで「Last Synced」「Account」「Status」の 3 項目を確認
続けて Settings Sync: Show Synced Data で実際にクラウド側に上がっているデータを表示

確認するポイントは「同期が止まった時刻」と「対象のスコープ」です。たとえば Last Synced が 2 日前で止まっていれば、これは「直近 2 日のうちに認証が切れたか、ネットワークが落ちたか」のどちらかです。Status が Turned on でも、Show Synced Data 側に settings.json が含まれていない場合、設定本体は同期対象から外れている可能性があります。

ここで「同期されているはずのキーバインドだけが反映されていない」ように見えるケースは、後述するスコープの問題（User vs Workspace）であることが多く、同期そのものは動いている、というのが落ち着いた判断です。

アカウントの認証が切れているケースの復旧

最も多い原因が、Google アカウントまたは GitHub アカウントの OAuth トークンの期限切れです。Antigravity は内部的に短命のリフレッシュトークンを使っているため、長期間オフラインで放置していたマシン側で「黙ってログアウト状態」になっていることがあります。

復旧の手順はシンプルですが、順番を間違えると手元の設定が上書きされて消えてしまうので注意が必要です。

先にローカル設定をバックアップする: コマンドパレットから Preferences: Open User Settings (JSON) を開いて、ファイル全体を別のテキストファイルに保存しておく
Settings Sync: Sign Out を実行（これは「同期を止める」だけで、ローカル設定は消えません）
Antigravity を一度再起動する
Settings Sync: Sign In で再認証します。このとき Replace Local ではなく Merge を選ぶ（Replace Local を選ぶと、最後に同期に成功した古いクラウド側の状態でローカルが上書きされます）

Merge ではなく Replace Local を選んでしまったときは、手順 1 でバックアップしておいた JSON を settings.json に貼り直すことで、ほぼ被害なく復旧できます。バックアップを取る癖をつけておくと、ここで救われます。

同期ストレージが破損したときのリセット手順

Sign In し直しても直らない場合、クラウド側ではなくローカル側の Sync データベースが破損していることがあります。Antigravity は内部に SQLite ベースのキャッシュを持っており、強制終了やストレージのフルなどで稀に整合性が崩れます。

リセットの順序は次の通りです。

# 1. まず Antigravity を完全に終了させる（Quit ではなく強制終了でも OK）
# macOS の場合: Activity Monitor で antigravity プロセスがいないことを確認
 
# 2. ユーザーデータディレクトリをバックアップ
cp -R ~/Library/Application\ Support/Antigravity ~/antigravity-backup-$(date +%Y%m%d)
 
# 3. Sync 関連のキャッシュだけを削除（設定本体は残す）
rm -rf ~/Library/Application\ Support/Antigravity/User/sync
rm -f ~/Library/Application\ Support/Antigravity/User/syncedKeybindings.json.lock
 
# 4. Antigravity を再起動して Settings Sync: Reset Local を実行
# 期待する出力: "Local sync data has been reset. Please sign in again."

Linux の場合は ~/.config/Antigravity/User/sync、Windows の場合は %APPDATA%\Antigravity\User\sync が同じ役割を果たします。Reset Local を実行してから Sign In し直すと、クラウド側の最新状態を取り直してローカルを再構築してくれます。

ここまでで多くのケースは解決しますが、それでも「片方のマシンだけ反映されない」場合はネットワーク層を疑います。

企業ネットワーク・プロキシ環境で同期が通らないケース

社内ネットワークや VPN 経由で Antigravity を使っているとき、Settings Sync は HTTPS で *.antigravity.google 系のエンドポイントに接続を試みます。プロキシで TLS 終端をしている環境では、自己署名証明書が信頼されずに同期だけが静かに失敗することがよくあります。症状の特徴は「Sign In は通るのに Last Synced が古いまま」です。

確認すべきは Antigravity の argv.json と環境変数の 2 つです。

// ~/.antigravity/argv.json — プロキシ経由でも証明書を許容する設定例
{
  // 社内 CA を信頼する（Antigravity 起動時に読み込まれる）
  "proxy-server": "http://proxy.corp.example:8080",
  "proxy-bypass-list": "<local>;*.corp.example",
 
  // ⚠ 個人マシンでは絶対に true にしないこと（中間者攻撃のリスク）
  "ignore-certificate-errors": false
}

argv.json は起動時にしか読まれないので、編集後は必ず Antigravity を再起動してください。期待する動作は、コマンドパレットの Settings Sync: Show Sync Activity で Last Synced が現在時刻に更新されることです。

社内 CA がある環境では ignore-certificate-errors を有効にしたくなりますが、これは個人マシンでは絶対に避けてください。代わりに OS の証明書ストアに社内 CA をインストールするのが正攻法です。プロキシ周りは Antigravity の社内プロキシ・ファイアウォール接続エラーの直し方で別途まとめているので、症状が一致していたらそちらを先に読むほうが早いです。

そもそも同期対象に含まれていない設定がある

最後に、初心者がいちばん引っかかるのがこのスコープの問題です。Settings Sync は「User 設定」だけを同期し、以下は同期しません。

ワークスペース設定（.vscode/settings.json または .antigravity/settings.json）
拡張機能の認証情報（GitHub の PAT、API キー、サインインセッション）
Git の credential helper に保存された認証情報
argv.json（前述のプロキシ設定もこれに該当します）
マシン固有の絶対パス（フォントファイルへのパスなど）

「キーバインドだけは同期されたが、API キーは同期されない」という挙動は仕様どおりです。同期されるべきもの・されるべきでないものを誤解していると、何度同期を直しても解決しないので、まず一度コマンドパレットの Settings Sync: Configure... で対象スコープを見直してください。

私はワークスペース設定はあえて同期せず、プロジェクトリポジトリ側に .antigravity/settings.json をコミットして管理しています。チーム開発では「個人の好み（User）」と「プロジェクトの規約（Workspace）」を分けると、Sync まわりのトラブルが激減します。

次にやること

ここまでの手順を上から順に試して、Last Synced の時刻が動き始めたら成功です。再発を防ぐために、いまのうちに 1 つだけやっておくとしたら、Preferences: Open User Settings (JSON) の内容を Git リポジトリに dotfile として置いておくことです。Settings Sync が将来また壊れても、git pull で 30 秒で復旧できます。

クラウド同期はあくまで「便利な仕組み」であって、「自分の設定の最終的な保存場所」ではない、と捉えておくのが、複数デバイスで開発を続けるうえで気が楽になるコツだと感じています。