なぜ Antigravity＋Gemini は出口が割れやすいか

検索にも載りやすい Google Antigravity や Gemini を搭載したエージェントファースト IDE は見た目は単一ウィンドウでも、OAuth・モデル送信・埋め込みブラウザ相当・静的 CDN・差分配信といった名前空間が並走します。アカウントの同意画面だけが accounts.google.com で完結しないフロースが増え、アシスタント呼び出しでは *.googleapis.com が継続的に並び、Electron／WebView が *.gstatic.com を引く一方で、アップデータが *.gvt1.com などに触れる構成も見えます。そのどこかが Clash で意図したポリシーとズレると、UI は読み込みのまま、モデル欄だけ API タイムアウト、といった不均一な停止へつながります。

Gemini CLI は端末の環境変数やシェル依存が前面に出やすく、Gemini ネイティブ Mac アプリ は macOS 証明書まわりが前面です。Antigravity 側は内蔵ターミナルや統合ブラウザが混ざり観測すべきホスト列が増えます。増減があるためテンプレ写しだけでは長く続きません。自分のイベントごとのライブログを一次情報へ据えるほうが再現できます。

ℹ ログ取得の単位：（1）初回ログインと同意のみ（2）最初のモデル質問送信（3）統合ブラウザ相当を一度だけ操作（4）アップデータ確認。各イベントごとにライブ接続を止めず列挙し、基底はまず DOMAIN-SUFFIX,googleapis.com と DOMAIN-SUFFIX,gstatic.com を単一グループへ揃えるかだけを見れば切り分けが速いです。

OAuth と Google API と antigravity.google ほか名前空間

継続運用に強い束ね方は次のラベル単位です。A. アカウント：accounts.google.com と必要な明示行。必要と判断したら DOMAIN-SUFFIX,google.com（検索や Workspace まで波及する副作用に注意）。B. API：DOMAIN-SUFFIX,googleapis.com。C. 静的 CDN：DOMAIN-SUFFIX,gstatic.com。 D. 配信：DOMAIN-SUFFIX,gvt1.com ほかログのみに出る名前。E. 製品ホスト：DOMAIN-SUFFIX,antigravity.google や DOMAIN-SUFFIX,labs.google など増えたときにだけ線で追加し、増え過ぎたら広いsuffixへ昇格させます。総図の読み進めだけならブラウザ向けにもある Gemini／Google AI Studio を参照してください。ここでの前提はブラウザ版ではなく自分のイベントログです。

ログインのみ失敗するときやモデル側だけタイムアウトのときは、DNS と TLS を切り分けます。certificate 行だけ増えるときは名前解決の二重化や社内検査が疑わしいです。また CDN を本命と同一ポリシーへそろえるだけで UI が進むときは本体とCDNの割裂が本体原因です。その発想自体は別クラウド例でも共通で、本体とCDNを同じ出口へそろえる メタファで捉えると頭が軽くなります。

GUI でルールセット版巻き戻しやライブ並べが素早くできることを先に確認しておけば、この後の追記だけで済みます。クライアント選択 で往復時間を読んでください。

最小 YAML ルール例と優先順位の確認

下の断片はひな型で、自分の proxy-groups 名へ合わせます。国内はGEOIP等で逃がす前提を崩さないでください。書き順の事故は ルール分流ベストプラクティス を参照。

Illustrative YAML fragment

rules:
  - DOMAIN,accounts.google.com,GOOGLE_AI_AGENT_IDE_PROXY
  - DOMAIN-SUFFIX,googleapis.com,GOOGLE_AI_AGENT_IDE_PROXY
  - DOMAIN-SUFFIX,gstatic.com,GOOGLE_AI_AGENT_IDE_PROXY
  - DOMAIN-SUFFIX,googleusercontent.com,GOOGLE_AI_AGENT_IDE_PROXY
  - DOMAIN-SUFFIX,gvt1.com,GOOGLE_AI_AGENT_IDE_PROXY
  - DOMAIN-SUFFIX,google.dev,GOOGLE_AI_AGENT_IDE_PROXY
  - DOMAIN-SUFFIX,antigravity.google,GOOGLE_AI_AGENT_IDE_PROXY
  - DOMAIN-SUFFIX,labs.google,GOOGLE_AI_AGENT_IDE_PROXY
  - GEOIP,JP,DIRECT
  - MATCH,DIRECT

ルールプロバイダ更新直後に壊れたら版巻き戻しを最初に試します。購読URLがループしていないかは 購読とノード保守 を参照。

TUN とシステムプロキシ：Electron／WebView と取り合い

Electron 系は環境変数を無視し独自スタックで通信する振る舞いが珍しくありません。システムプロキシだけでは IDE 本体が載らない一方、TUN は OS ルーティングへ載りやすく観測の単純化に寄与します。競合は macOS TUN と拡張の衝突ノート を参照し、TUN 深読み で MATCH 順の副作用を押さえます。

TUN 後に全体が不安定なら巨大リストと MATCH の位置から疑います。

DoH／fake-ip と証明書まわり

fake-ip とブラウザ DoH と OS DNS を重ねると証明書名と接続先の食い違いが出やすいです。Google 系はサブドメインが多いため Clash Meta の DNS の章に沿って単線化テストを挟みます。

社内 DNS が公開ゾーンを書き換える場合は Clash だけでは直りません。失敗ホストと得られた A／AAAA とポリシー命中行をメモし IT へ渡します。

ログで読むタイムアウトと TLS

TCP 成否、ルータ命中、DNS 応答を並べて読みます。i/o timeout とノード、tls／x509 と名前解決の切り分けは 接続ログの timeout と TLS が流用できます。IDE 事例の近傍は Cursor と Clash と比べつつ名前空間を混ぜないでください。

GEOIP／巨大リストが自分の細かいドメイン行より上に来ていないか常にウィンドウで確認します。

Gemini CLI／Gemini Mac との切り口の違い

CLI は端末と少数エンドポイントへの閉じ方が読みやすく、環境依存が前面です。Mac ネイティブは証明書とキーチェーン側が前面になりがちです。Antigravity 型 IDE はプラグインマーケットや統合ブラウザの名前が増えますが、成功の鍵は依然として googleapis と gstatic とアカウント名前をひとつのポリシーグループへそろえる運用サイクルです。

FAQ（よくある質問）

モデル送信だけタイムアウトするのはどう読むか

oauth と別の増分リストがモデル質問時だけ動いている可能性があります。generativelanguage.googleapis.com に視野を限定せず、送信直前のライブ行を増やしてください。

antigravity.google に一本の DOMAIN で足したが効きにくい

アップストリームの命名が増えると単一点の DOMAIN は追随しきれません。suffix へ昇格させるかログで増えた行だけ追記してください。

Windows と macOS で違う点は何か

DNS／ルール順の論点は共通ですが、企業インスペクションと別 VPN と TUN の干渉度合いだけ OS で差があります。

⚠ コンプライアンス：法令・社内規程・サービス規約を守り、許可されていない迂回を行わないでください。本記事は正当な許可環境での経路診断のみを対象とします。

チェックリスト

  1. 自分の環境で Google Antigravity／Gemini IDE と Clash の併用が許可されているか確認する。
  2. 四イベントごとにライブ接続列挙へそろえるメモを取る。
  3. googleapis・gstatic・アカウント名前が単一グループへ揃っているか俯瞰する。
  4. 巨大リストが細かい Google 行より上に来ないかチェック。
  5. TUN とシステムプロキシの単純化比較を一度挟む。
  6. DNS と fake-ip の単線検証へ切り替え比較する。
  7. ルール修正まで終えてから初めてノード品質とベンダ側障害を疑う。

メモが残るほど、アップストリームの命名増加分の追跡が楽です。

まとめ

Antigravity／Gemini IDE は単一ウィンドウの裏で複数名前空間へ分散しやすく、クラッシュしないまでもスピナーと API タイムアウトに見える並走経路分裂が起きがちです。共通の処方は、テンプレ写しだけでなく自分のイベントログを束ねリストへ昇格させる運用になります。Gemini と Google AI Studio や CLI／ネイティブ記事にある Google API と CDN の束ね方を土台に、IDE が増やす増分だけ追記しましょう。

ルールセットの版巻き戻し運用だけは癖にしておくと、並べ順事故の復旧時間が読みやすくなります。また巨大カテゴリ更新で壊れたらまず並べ順を疑う順序だけは固定すると迷いが減ります。

「すべてを海外ひとつのトンネルへ」だけを強調した閉ざされたクライアント群は開発者ワークフローで増えるドメイン列を自分のリストへ載せきれず、増分が見えづらいまま不透明なタイムアウトだけが続きやすい欠点があります。自分のイベントで増えた行をルールセットへ昇格させながら可視ログとヒット順を同じ画面上で並べられるクライアントでは、アップストリームの名前空間増加が続いても比較的静かです。長期イベントログへ慣れた運用だけが増分耐性になります。この点においてワークスペースごとプロファイルを分けられる設計があると名前空間再同期にも戻りやすく、エージェント IDE の短命な命名よりも自分側のリストの歴史として追える状態を保ちやすくなります。

OS をまたぐ開発にも耐えるオープンに近い構成は、モデル機能のオンオフやワークスペース切替だけで増える並走経路でもルールセット版管理と自分の増分行の diff だけで追えるため、アップストリームの名前空間が週単位でも動いても頭のなかのモデルが壊れにくいという副次的効果があります。ライブ並べへ慣れた時点でもう一段階開発スピードに戻れる時間へシフトできるはずです。

→ Clash をダウンロードし、モデル活用と開発作業本体へ時間を返してください。