Antigravity 2.0分流

1. I/O 2026 直後に「Antigravity × Clash」が検索される理由

Google Antigravity 2.0のキーノート公開直後、開発者コミュニティでは「デスクトップは入ったが CLI が落ちる」「curl では Gemini API に届くのに Managed Agents だけハングする」「ブラウザの AI Studio は真っ白」といった入口ごとの不整合が同時多発しています。国内回線や会社ネットワークから Google 開発者向けサービスへ向かうとき、常時 VPN 一本化は Meet や社内許可ドメインまで巻き込み、障害説明が難しくなりがちです。ここで Clash Verge Rev のルール駆動分流は、Google 全体ではなくAntigravity と Gemini API 関連ホストだけを策略グループへ送る設計が向きます。

検索意図を整理すると、(A) Antigravity CLIのインストール／更新、(B) Gemini APIとManaged Agentsの REST／SDK 呼び出し、(C) AI Studioやデスクトップアプリの OAuth、(D) エージェント実行時の長時間 WebSocket、の四層です。いずれも「プロキシはオンなのに特定プロセスだけ DIRECT」という症状は、Go 製 CLI のプロキシ無視、DNS・fake-ip のズレ、出口ノード品質のどれかに帰着することが多く、製品ハイプよりログに基づく足し方を優先します。

2. Antigravity 2.0 と Gemini Spark：記事のスコープ

同じ Google I/O 2026 でも、Gemini Sparkは個人向けエージェント体験、Antigravity 2.0は開発者プラットフォームとして位置づけられます。Antigravity は複数エージェントのワークフロー編成、リポジトリ連携、Managed Agentsの API 提供など、CI／ローカル開発／ターミナルから触る前提が強いです。そのため本稿はブラウザの Gemini アプリより、CLI・SDK・API キーの経路安定に焦点を当てます。Spark 向けに書いた gemini.google.com ルールは土台になりますが、CLI 配布 CDN や Agent 実行用ホストは別途ログで追加してください。

Antigravity 2.0 の構成要素として押さえるのは次の四点です。(1) 独立デスクトップアプリ（Electron 系に近い更新モデル）、(2) Go 製 CLI（自己更新・バイナリ取得あり）、(3) 各言語向けSDK、(4) Gemini API上の Managed Agents。いずれも最終的には googleapis.com 系や Google 認証基盤へ収束しますが、最初に失敗するホストは入口ごとに異なります。

3. 観測すべき代表ホスト（出発点リスト）

Google 側のエンドポイント一覧はドキュメント更新に追随します。静的な確定リストではなく観測のたたき台として、Antigravity 導入直後に次を Clash Verge Rev のドメインログと開発者ツールで並べてください。

CLI 配布・自己更新：インストールスクリプトが叩く dl.google.com、storage.googleapis.com、リリースアセット用 CDN（ログで実名を確定）
Gemini API：generativelanguage.googleapis.com（REST／SDK の本体）
Managed Agents：Agent 実行・オーケストレーション用の *.googleapis.com（公式 SDK サンプルの通信先を優先）
AI Studio：aistudio.google.com、認証の accounts.google.com
共通 Google 基盤：google.com／gstatic.com／googleusercontent.com 系静的配信

DOMAIN-KEYWORD,google のような粗い一行は Workspace まで巻き込むリスクがあるため、ログに現れたサフィックスだけを増分で足す運用が安全です。Antigravity のマイナーアップデートで計測ビーコンが増えても、評価は常に「実際に CONNECT した名前」です。

4. Clash Verge Rev：プロファイル・策略グループ・実効モード

作業前に三つをメモします。(1) アクティブな購読プロファイルとローカル上書きのどちらを編集しているか。(2) PROXY／自動選択／地域別リストなど策略グループの実名。(3) Rule モードで Mixed Port・システムプロキシ・TUN のどれが効いているか。I/O 直後は購読提供者が Google 向けルールを足すこともありますが、テンプレート名は環境ごとに違うため、画面ラベルよりログ上のグループ名を正とします。

おすすめの段階は、平常時は Rule＋システムプロキシでデスクトップと AI Studio を扱い、Antigravity CLIと SDK だけ HTTPS_PROXY を足す形です。Go 製バイナリが環境変数を読まない場合だけ TUN を短時間オンにし、競合 VPN や仮想アダプタの有無を見ます。常時 TUN は切り分けが難しくなるため、ホットトピック試用期間こそ「広げすぎない」方が再現性が高いです。

5. ルール断片の例（グループ名は購読に合わせて置換）

以下は概念的な YAML 断片です。PROXY はご利用の策略グループ名に読み替え、社内ドメインやローカルは必ず上流で DIRECT に固定してください。

# Example — rename PROXY / DIRECT to match your subscription
rules:
  - DOMAIN-SUFFIX,generativelanguage.googleapis.com,PROXY
  - DOMAIN-SUFFIX,googleapis.com,PROXY
  - DOMAIN-SUFFIX,dl.google.com,PROXY
  - DOMAIN-SUFFIX,storage.googleapis.com,PROXY
  - DOMAIN-SUFFIX,google.com,PROXY
  - DOMAIN-SUFFIX,gstatic.com,PROXY
  - DOMAIN-SUFFIX,googleusercontent.com,PROXY
  - DOMAIN,accounts.google.com,PROXY
  - GEOIP,JP,DIRECT
  - MATCH,DIRECT

google.com 全体を PROXY にすると検索や広告まで巻き込むことがあります。チーム運用では「Antigravity／Gemini 用の部分集合」を別ファイルに切り出し、レビュー可能な差分にするのが Clash／Mihomo 系の強みです。CLI だけ失敗するときは、インストールスクリプトが参照する別 CDN ホストが DIRECT のまま残っていないかを疑います。

6. Antigravity CLI：Go 製バイナリへのプロキシ注入

Antigravity CLIは Go でビルドされたスタンドアロンバイナリであることが多く、OS のシステムプロキシを自動では読まないケースが典型です。Mixed Port を例に 7890 とすると、インストールや実行前に次を同じシェルで設定します。

export HTTPS_PROXY=http://127.0.0.1:7890
export HTTP_PROXY=http://127.0.0.1:7890
export ALL_PROXY=socks5://127.0.0.1:7891

まず curl -I "https://generativelanguage.googleapis.com" で CONNECT 可否を確認し、続けて CLI のインストールコマンドや antigravity --version を試します。Windows では PowerShell の $env:HTTPS_PROXY、IDE 統合ターミナルでは親プロセスに環境変数が渡らないことがあるため、ラッパースクリプトで明示エクスポートする方が確実です。それでも迂回する場合は TUN でプロセスをキャプチャし、症状が消えるかを短時間だけ検証してください。

WSL2 と Windows ホストを跨ぐときは、127.0.0.1:7890 がどちらの名前空間を指すかを固定します。WSL 側から Windows の Mixed Port へ向けるアドレス写像を間違えると、「Windows の AI Studio は通るが WSL の Antigravity CLI だけタイムアウト」という非対称が起きやすいです。

7. Gemini API と Managed Agents：SDK／curl の実務

Gemini APIは generativelanguage.googleapis.com を中心に REST または google-genai 等の SDK から呼び出します。Managed Agentsはエージェント定義・実行・ツール呼び出しで追加ホストが増えるため、SDK サンプルを一度走らせ、プロキシログに載った名前をルールへ反映してください。Python では環境変数を読むクライアントと読まないクライアントが混在するため、HTTPS_PROXY 設定後も失敗する場合はシステムプロキシか TUN に進みます。

ストリーミング応答や長時間の Agent 実行では、途中の NAT や出口ノードがアイドル切断するとタイムアウトだけが表面化します。ログでは CONNECT 成功後の RST 頻度と HTTP 429（クォータ）を分け、共有用にはステータスコードと相関 ID の最小集合に留めます。CI では API キーを export せずシークレットストアから注入し、プロキシログに本文が出ない設定を確認してください。

8. デスクトップアプリと AI Studio：ブラウザ側の手順

Antigravity 2.0デスクトップは Chrome 内蔵に近いネットワークスタックを使うことが多く、OS のシステムプロキシを尊重する場合と、独自スタックで迂回する場合があります。まず Clash Verge Rev でシステムプロキシをオンにし、aistudio.google.com でサインインとプロンプト実行を試します。デスクトップだけ認証失敗する場合は accounts.google.com が DIRECT のままか、TUN なしではプロセスがプロキシを見ていないかを切り分けます。

ブラウザ拡張の広告ブロックやプライバシー保護が Google 認証リダイレクトだけを落とす例もあります。プロキシ以前の失敗ではログに載らないため、シークレットウィンドウや拡張オフの A/B を短時間だけ行い、原因を二分します。TLS は通るが「地域で利用不可」と出るときは、経路ではなくGoogle アカウントの提供条件側の可能性が高いので、出口ノードの国とログインアカウントを分けて記録してください。

9. 出口ノード選定と DNS・fake-ip

Gemini APIとManaged Agentsはレイテンシとレート制限に敏感です。策略グループで「自動選択」だけに任せず、ログで RTT が安定しているノードを Antigravity 専用に固定するチームも多いです。ルールが正しくても、名前解決が社内 DNS や OS キャッシュだけを見続けると、評価ドメインと実 SNI がずれて DIRECT のままに見えます。fake-ip 構成ではキャッシュを落とし、プロキシログのドメイン列と開発者ツールの Host を突き合わせます。

社内 TLS インスペクション環境では、ブラウザだけ社内 CA を信頼し CLI は別ストアを見ることがあり、Antigravity 試用中にだけ表面化することもあります。セキュリティレビュー前提の上で、プロキシ経由に統一して一つの信頼チェーンに寄せる方法もあります。

10. ログの読み方とチェックリスト

症状を時間順に並べると、(A) CONNECT 未成立（経路・DNS・FW）、(B) CONNECT 後に 401／403／429（鍵・クォータ・リージョン）、(C) 途中 RST（出口品質・keep-alive）、に分かれます。すぐ試す順序は次のとおりです。(1) 有効プロファイルと策略グループ名を確認。(2) CLI インストール・Gemini API・AI Studio で実ホスト一覧をログ確定。(3) HTTPS_PROXY 付き curl で API ホストへ到達。(4) 同じシェルで Antigravity CLI を再実行。(5) デスクトップはシステムプロキシオンで認証を再試行。(6) 取りこぼしだけ TUN を短時間オン、競合 VPN を確認。(7) 429 が続く場合は出口ノードと API クォータを分離記録。

よくある質問

Antigravity CLI のインストールがタイムアウトします。

Go 製バイナリのダウンロード先が DIRECT のまま残っている典型です。インストールスクリプトが叩くホストをプロキシログで確認し、PROXY グループへ追加したうえで HTTPS_PROXY を設定したシェルから再実行してください。

Managed Agents の API 呼び出しだけ 429 やタイムアウトになります。

CONNECT の成否と HTTP ステータスを分けてください。経路は通っていても出口品質や Gemini API クォータが原因のことがあります。別ノードやリージョン付きエンドポイントで再試行します。

AI Studio は開くのに Antigravity デスクトップだけ認証に失敗します。

デスクトップアプリがシステムプロキシを無視している可能性があります。TUN を短時間オンにするか、accounts.google.com 系を PROXY へ統一してください。

Gemini Spark 向けルールをそのまま使えますか？

Generative Language API や AI Studio 向けの基本ルールは共通ですが、CLI 配布 CDN と Managed Agents 用ホストはログで差分を足してください。観測ベースの追加運用を推奨します。

常時オン型の単一 VPN は手軽ですが、Google 全体を一括トンネルにすると Meet や社内 SaaS まで巻き込み、Antigravity 試用中の障害説明が難しくなりがちです。一方 Clash Verge Rev のようなルール駆動クライアントは、Antigravity CLI・Gemini API・Managed Agents関連だけを策略グループへ送り、パッケージレジストリや社内ツールは直通、という粒度の異なる分流をテキスト差分で共有できます。閉じた商用クライアントにありがちな「オンだが経路が説明できない」状態と比べ、I/O 直後の開発者向けホットトピックでもログベースで保守できる点が効きます。ルール設計に納得できたら、下のリンクから OS 別クライアントを揃え、CLI・API・デスクトップの三入口を一度まとめ直してみてください。

無料で Clash 系クライアントを入手し、今すぐ試す →

さっそく使ってみましょう

Antigravity CLI・Gemini API・AI Studio で使うポートとルール名をチームで揃えると、I/O 直後の検証が速くなります。

ダウンロードへチュートリアルを見る