はじめに
Google Antigravity のログインに失敗したり、画面が途中で止まったり、AI機能を実行したときだけ通信エラーが表示されたりする場合、原因はアカウントだけにあるとは限りません。認証サーバー、AI処理用のAPI、静的ファイル配信、更新チェックなど、複数のドメインへ同時に接続するため、ネットワーク経路の一部が不安定になると正常に起動できないことがあります。
本記事では、Clash または Mihomo を利用して Google Antigravity の通信を整理し、サブスクリプションの追加、プロキシグループの選択、ルール分岐、DNS、TUNモードまで順番に確認します。使用するクライアントは Clash Verge Rev を中心に説明しますが、Clash Verge、Clash for Windows、Mihomo 対応クライアントでも考え方は共通です。
この記事の目標
Google Antigravityに必要な通信だけを安定したノードへ振り分け、ログイン失敗や接続エラーの原因を切り分けられる状態を作ります。
利用前の注意
Clashは通信を制御するクライアントであり、プロキシサーバーやサブスクリプションを提供するサービスではありません。利用規約と現地の法令を確認し、信頼できるプロバイダーだけを使用してください。
1設定前に確認すること
Clashの設定を変更する前に、Google Antigravity自体が利用条件を満たしているかを確認します。ネットワークを変更しても、アカウントの権限、アプリの対応地域、古いバージョン、端末の時刻ずれなどが原因でログインできない場合があります。
- アカウント状態： Googleアカウントで通常のウェブサービスへログインできるか確認します。多要素認証や不審なログイン通知が保留中の場合は、先に本人確認を完了させます。
- アプリの更新： Google Antigravityと関連ランタイムを最新状態にします。古いバージョンでは認証エンドポイントや証明書の変更に対応できないことがあります。
- 日時とタイムゾーン： 端末の日時を自動設定にします。時刻が大きくずれていると、ログイン用トークンやTLS証明書の検証に失敗します。
- 他のVPNやプロキシ： OSのVPN、ブラウザー拡張、企業ネットワークのプロキシが同時に動作していないか確認します。複数の経路が重なると、接続先とDNSの判定が不一致になります。
- 基本テスト： Clashを停止した状態と有効にした状態で、ログイン画面やAIリクエストの挙動を比較します。差分を記録すると、設定ミスとサービス側の障害を分けやすくなります。
なお、ログイン画面だけ開くのにAIの生成処理で失敗する場合は、認証用ドメインは到達できていても、APIまたはストリーミング用ドメインが別のルールで処理されている可能性があります。最初から全通信を無条件にプロキシへ送るのではなく、ログを見ながら必要な範囲を特定するのが安全です。
2サブスクリプションとノードを設定する
Clashで通信を安定させるには、まず有効なサブスクリプションを読み込みます。サブスクリプションURLは第三者に共有すると、契約中のノードを不正利用されるおそれがあるため、公開チャットやスクリーンショットに表示しないでください。
- Clash Verge Revを起動し、Profiles またはプロファイル管理画面を開きます。
- プロバイダーから発行されたサブスクリプションURLを入力し、プロファイルを取得します。
- 読み込みが完了したら、対象プロファイルを選択して有効化します。
- Proxies 画面で、Google Antigravity用のプロキシグループと実際のノードを確認します。
- 最後に、システムプロキシまたはTUNモードを必要な範囲で有効にします。
更新できない場合
サブスクリプションURLの期限、使用量制限、URLの入力ミスを確認してください。更新エラーが出るときは、まずブラウザーでURLへアクセスできるかを試し、Clash以外の問題かどうかを切り分けます。
ノードの選び方
AIサービスでは、単純な速度測定の数値だけでなく、接続の一貫性とIPアドレスの信頼性が重要です。最初は利用場所から物理的に近い日本、シンガポール、米国などを比較し、ログイン、画面表示、短いリクエスト、長めの生成処理を順番に試します。
- 遅延： 数値が低いノードは操作開始が速くなりやすいものの、応答速度だけで安定性を判断しないでください。
- パケットロス： 短時間の切断やストリーミング停止があるノードは、AI生成中にエラーになりやすい傾向があります。
- 混雑： 利用者が多い共有ノードは、時間帯によって速度や接続成功率が大きく変わります。
- 地域の整合性： ログイン時とAPI接続時で国や地域が頻繁に変わる構成は、追加認証やセキュリティ判定を招くことがあります。
一つのノードで失敗したからといって、すぐに大量のノードを短時間で切り替えるのは避けましょう。認証試行が増え、原因の記録も難しくなります。候補を2〜3個に絞り、同じ条件で比較する方が実用的です。
3ルール分岐とDNSを調整する
Google Antigravityの通信を安定させる基本は、関連ドメインを同じプロキシグループへまとめ、認証やAPIだけがDIRECTへ流れないようにすることです。ただし、実際のドメイン構成はアプリの更新で変わるため、以下は考え方を示す例として利用してください。プロバイダーのルールセットに同等の設定がある場合は、重複登録を避けます。
グループ名やノード名は、実際のプロファイルに存在する名称へ置き換えてください。広すぎるドメインをプロキシへ送ると、Google検索や動画など通常の通信まで経路が変わり、速度低下やログイン状態の変化につながる場合があります。設定後はログ画面で、Antigravityの操作中にどのルールが適用されたか確認します。
DNS設定の確認
DNS解決が不安定だと、ブラウザーでは接続できてもアプリだけが失敗することがあります。Mihomo系クライアントでは、暗号化DNSやfake-ipモードを利用できる場合がありますが、すべての環境で同じ結果になるわけではありません。まずはクライアントの初期設定を保存し、変更は一項目ずつ行ってください。
fake-ipで特定のアプリが動かなくなった場合は、対象ドメインをfake-ip-filterへ追加する前に、まずアプリのプロセスを再起動し、キャッシュを削除して再確認します。ローカルネットワークや企業内サービスへ接続する必要がある場合は、LAN関連のドメインをDIRECTにする設計も必要です。
設定のポイント
DNS、プロキシモード、ルールを同時に変更すると原因が分からなくなります。DNSを変更したらログインを一度試し、次にルール、最後にTUNモードという順番で検証してください。
4ログイン失敗と通信エラーの対処法
設定後も問題が残る場合は、表示されたエラーの種類と発生するタイミングを記録します。「ログインボタンを押した直後」「認証コード入力後」「AI生成開始時」「長い出力の途中」では、疑うべき通信が異なります。
ログイン画面で失敗する場合
- Clashの接続モードが有効か、選択中のプロファイルが実際に稼働しているか確認します。
- 認証関連ドメインがDIRECTとプロキシの間で分断されていないか、ConnectionsまたはLogs画面を確認します。
- ブラウザーのCookieやアプリの認証キャッシュを削除し、同じノードで再試行します。
- 短時間に何度もログインを繰り返さず、アカウント側のセキュリティ通知や追加確認を確認します。
AI処理や生成中に失敗する場合
ログイン後にだけエラーが起きるなら、API、WebSocket、ストリーミング接続、静的リソースのいずれかが別ルールになっている可能性があります。該当リクエストがDIRECTになっていないか、同じ接続が複数のノードへ分散していないかを確認してください。TUNモードを使う場合は、アプリの通信がTUNへ取り込まれていること、システムプロキシだけに依存していないことも重要です。
エラーが続くとき
すべてのドメインを無条件にプロキシへ送る設定や、頻繁な地域変更は、かえって認証判定を不安定にする場合があります。ノードを固定し、ログ、時刻、ルール、DNSを一つずつ確認してください。
最終チェックリスト
- サブスクリプションが正常に更新され、期限切れになっていない。
- Clashのプロファイルが有効で、意図したノードが選択されている。
- Google Antigravity関連の通信が同じプロキシグループへ分岐している。
- DNS解決とTUNモードの設定が、使用している端末とクライアントに適合している。
- ノード変更後にアプリとブラウザーを再起動し、同じ操作で再現性を確認した。
それでも接続できない場合は、Clashを一時停止した状態、別のネットワーク、別のノードを順に比較します。すべての環境で同じエラーが発生するなら、Google Antigravity側の障害、アカウント制限、サービス仕様変更の可能性が高くなります。Clashのログには認証情報やURLが含まれることがあるため、問い合わせ時に共有する場合は個人情報とサブスクリプション情報を必ず伏せてください。