ネットワーク実践 Agent IDE タグ： Google Antigravity Gemini Clash TUN

Google Antigravity が総タイムアウト？Clash TUN と Google ルール分流で Gemini API を安定させる（2026）

Google Antigravity のような Agent IDE は、会話 UI だけでなくバックグラウンドのコード補完、エージェント実行、依存取得、Google アカウント連携まで抱え合わせます。ブラウザ版 Gemini が概ね安定していても、IDE からだけ Google API が遅い・TLS や接続が切れる場合は、経路の乗り方（システムプロキシと TUN）と、ルール分流の順序・ノード選択をセットで疑うのが早いです。本稿はネットワーク観点の整流手順であり、規約違反や不正な迂回を助長する内容ではありません。

読了時間：約20分
Clash 編集部
目次

1. Agent IDE で増える接続の複雑さ

Google Antigravity のような製品は、単一のチャット画面に閉じないワークロードを抱えます。エディタ本体、言語サーバ、ターミナル子プロセス、署名付き更新、埋め込みブラウザ相当の取得、そして長めに張り付く Gemini 呼び出しが同居し、失敗の見え方は「会話だけ止まる」「補完だけ遅い」「ビルド前処理は通るのにエージェントだけ固まる」などに分散します。

ブラウザで gemini.google.com を開く用途と、IDE が SDK 越しに叩く Google API は、ホスト名・タイムアウト閾値・再試行ポリシーが一致しません。Gemini 汎用稿で整理した googleapis.com と静的配信、accounts.google.com 周辺の関係はそのまま土台になりますが、IDE では「どのプロセスがどの環境変数を読むか」まで含めて設計する必要が出ます。

まずはクライアント導線を最新に保ち、用語の補助線として ドキュメントと ダウンロードページを併用してください。以降はログ中心の話なので、GUI が接続履歴を残せる設定になっているかだけ先に確認しておくと手戻りが減ります。

2. システムプロキシと TUN の使い分け

多くのデスクトップ向け Agent IDE は Electron 系のシェルを前提にし、OS の HTTP(S) プロキシ設定を直接読まない子プロセスが混ざります。ここで「ブラウザは速いのに IDE だけ遅い」が起きやすく、原因はサインイン画面ではなく下流の API にある場合もあります。

Clash TUN は、プロセスが自己完結したプロキシ設定を持っていなくても、OS のルーティング表レベルでトラフィックをコアへ載せ替える発想です。管理者権限やカーネル拡張、競合 VPN の有無は環境差が大きいので、まずは利用中クライアントの公式手順に沿って TUN を有効化し、同じ端末で他の「全トラフィック capture」が生きていないかを整理します。GUI によっては TUN モードの詳細が分かりやすいので、たとえば macOS での初期セットは TUN 解説記事を併読すると早いです。

ヒント：システムプロキシと TUN を同時に有効化していると二重経路に見えることがあります。切り分けのため、どちらか一方に寄せて再現性を確認してから、必要最小限の組み合わせへ戻すと判断がしやすくなります。

Windows でプロセス名ルールを使う構成も有効ですが、IDE は名前付き実行ファイルが複数に分かれることがあり、保守コストが上がります。まずは TUN で全体をコアに載せ、ログに出たホストへルールを絞り込むのが再現性の高い順序です。

3. タイムアウト・TLS・HTTP エラーの見分け

「ずっと待つ」だけでは単一の原因に帰れません。TLS handshake timeout や証明書検証エラーは、ノード品質や途中のフィルタ、期待しない DIRECT、IPv6 の別出口など、ルーティング層の疑いが濃厚です。TLS 近傍稿のチェック項目と併せて、IDE の開発者コンソールに出るホスト名と Clash ログの Server Name を一致させてください。

一方、HTTP ステータスが 403 や 429、あるいは JSON のエラーコードが定型的に返る場合は、プロキシ以前にクォータや権限、課金段階、地域に依存するポリシーを疑います。ここをネットワークのレイヤで触り直しても改善しないまま時間を溶かすケースがよくあるため、まずレスポンス本文を読む習慣が効きます。

開発者向けの GitHub Models や Cursor 系のエージェント経路とはホスト集合が完全には一致しません。GitHub 寄りの症状は Cursor 記事、OpenAI Prism など別プロバイダは Prism 記事を参照し、Antigravity については本稿の Google 集合を正としてください。

4. Google 系ホストの束ね方（思考の地図）

具体的なエンドポイントは更新され得ます。以下は設計メモとしての例であり、正は常にクライアントログと公式情報です。

  • 対話と UI：google.com 配下、gemini.google.com、時折絡む accounts.google.com。
  • 静的資産：gstatic.com、ページの半分だけ読み込みが止まるときに疑う。
  • Generative AI API：SDK が向きがちな generativelanguage.googleapis.com など googleapis.com 配下。
  • 開発者向け入口：ai.google.dev やコンソール周辺。キー発行フローで追加ホストが出ます。

これらを「ひとかたまりの業務」として同一の プロキシグループへ寄せるのが ルール分流の本体です。DOMAIN-KEYWORD,google で一気に書く手もありますが、過剰マッチのリスクがあるため、ログに現れた実名から DOMAIN と限定的な DOMAIN-SUFFIX を育てる運用が安全です。

IPv6 と分割トンネルの観点

IPv4 だけ意図した出口に揃っていても、IPv6 が別経路へ抜けるとブラウザと IDE で体感が分かれることがあります。OS 側の優先度やルータ設定とあわせ、必要なら一時的に IPv6 を切って挙動差を見るのも現実的な切り分けです（恒久的な無効化が常に正しいわけではありません）。

5. ルール分流の書き方と順序の罠

Mihomo 系 Clash では rules: を上から評価します。巨大な GEOIP やサードパーティの RULE-SET が先に当たると、googleapis.com だけ意図せず DIRECT へ滑る、という典型があります。Antigravity で API だけが不安定なときは、まずその事実をログで確定してください。

# Example only — adjust to your policy group names and verify in logs
rules:
  - DOMAIN-SUFFIX,gemini.google.com,PROXY
  - DOMAIN-SUFFIX,googleapis.com,PROXY
  - DOMAIN-SUFFIX,gstatic.com,PROXY
  - DOMAIN-SUFFIX,googleusercontent.com,PROXY
  - DOMAIN-SUFFIX,accounts.google.com,PROXY
  - DOMAIN-SUFFIX,ai.google.dev,PROXY
  - DOMAIN-SUFFIX,google.com,PROXY
  - MATCH,DIRECT

実運用では、社内ポリシーや誤爆回避のため、サフィックスの広げ方を段階的にすることが多いです。先行する購読ルールを一時的に外し、最小再現セットで改善するかを見てから本流へ戻すと、設定が壊れた時間を最小化できます。

注意：外部ルールセットは鮮度と方針にばらつきがあります。IDE が触る Google API だけが不安定なとき、短い追記ルールで改善が確認できたら、なぜ効いたのかをログで言語化してから巨大セットへ寄せるのが安全です。

6. DNS・Fake-IP・ログイン周り

Fake-IP を使う構成では、名前解決とルール評価の接続が密です。accounts.google.com や OAuth のリダイレクト連鎖が、意図せぬフィルタに掛かっていると「サインインだけ不安定」に見えます。fake-ip 切り分け稿に沿って、上流 DNS と fake-ip-filter を点検してください。

ブラウザ内の DNS over HTTPS を併用していると、OS 配下のプロキシと二重に名前解決が走り、ログと実体感が読みにくくなることがあります。比較のために一時的にオフへ寄せ、差が出るかを見るのは現実的です。

企業プロキシやセキュリティ製品による HTTPS インスペクションが有効な端末では、IDE だけ証明書ストアの参照経路が異なり、TLS 失敗に見えることがあります。自宅ネットや別アカウントでの再現性を取ると切り分けが早くなります。

7. ノード選択とフェイルオーバー

ノード選択は遅延テストの数字だけでは決め切れません。Gemini 向けの長めのストリームは、短い ping では見えない輻輳やレート制限の影響を受けます。自動フェイルオーバーが過敏だと、実行中のセッションが途切れて IDE 側の再試行ループに入り、結果として「総タイムアウト」に見えることもあります。

実務では、まず手動で安定ノードに固定し、同じ操作手順で再現しないことを確認してから、フェイルオーバー閾値を緩めたり、グループ設計を見直します。別ノードへ切り替えた瞬間だけ改善するなら、プロバイダ側の一時的要因も疑います。

HTTP レイヤの 429 が出る場面では、アプリのリトライ間隔を短くしすぎない、など実装側の作法も効きますが、ここはプロキシの責務外です。ネットワークを揃えたうえで残るコードは、アプリ設定と利用枠の確認に進むのが筋です。

8. セルフチェック

短文チェックリストです。上から順に潰すと手戻りが減ります。

  1. クライアント更新：GUI とコアの組み合わせが古いと TUN の挙動やログ形式がズレます。
  2. TUN とシステムプロキシ：IDE プロセスがどちらに載る想定かを統一し、競合 VPN を止めて比較する。
  3. ルール命中：googleapis.com と gstatic.com が期待のポリシーへ落ちているか。
  4. DNS：Fake-IP 設定とログイン連鎖が矛盾していないか。
  5. TLS：SNI と証明書、途中機器のインスペクションを疑う。
  6. HTTP エラー：403／429 の本文がクォータや権限を指していないか。

ここまで揃っても改善が限定的なら、単純にプロバイダ側の輻輳や地域的要因である可能性もあります。公式ステータスやコミュニティ報告と突き合わせ、時間を置いて再試行するのも合理的です。

9. 他 IDE 記事との棲み分け

Developer 向けのエージェント IDE は 2026 年も増え続けていますが、接続の要点は「どのホスト集合を正にするか」です。OpenAI Prism 路線は Prism 稿、Cursor／GitHub 寄りは Cursor 稿、汎用 Gemini は Gemini 稿が近い参照です。Antigravity は Google 名空間に寄り切るため、Prism や Cursor のルールをそのまま流用しても穴が残りやすいです。

観点 Cursor／GitHub 側（参照） Antigravity／Google 側（本稿）
主な名前空間 github.com、モデル CDN、OpenAI 互換エンドポイントなど google.com、googleapis.com、gstatic.com、アカウント連携
失敗の出方 モデル一覧や拡張取得、Copilot 系 API Gemini 呼び出し、補完、エージェント実行、ログイン連鎖
ルール流用のリスク Google の静的 CDN が DIRECT に残る GitHub 向けルールだけでは googleapis.com に届かない
最初に見るログ Cursor 記事のチェックリスト Gemini 記事＋本稿の API ホスト優先度

10. よくある質問

検索で繰り返される論点のみを短文でまとめます。

  • Q. TUN をオンにすると社内 LAN の管理画面が遅くなりました。
    分割トンネルや bypass 設定、ローカル CIDR の除外を確認してください。まずは一時的に TUN を切って差分を見るのが早いです。
  • Q. 共有 Wi-Fi ではうまくいくのに自宅だけダメです。
    DNS のキャッシュ、IPv6、ルータのフィルタ、他 VPN の常駐が典型です。同じ端末でネットワークを切り替えて再現性を取ってください。
  • Q. ルールは増やしたのにまだタイムアウトします。
    順序が先に食われていないか、別プロセスが別経路へ抜けていないかを疑います。ログの Server Name が想定と一致しているか再確認してください。

11. まとめ

Google Antigravity のような Agent IDE は、Gemini と Google API を前端・静的資産・アカウント連携まで跨いで使うため、ブラウザ単体よりも経路のズレが出やすい機器です。Clash TUN で OS 直下の乗り方を揃え、命中ログに沿って ルール分流と ノード選択、DNS を同じテーブルに収束させると、TLS や接続系のタイムアウトはだいぶ読みやすくなります。

商用・無償を問わず、単機能のプロキシツールやルールの薄いクライアントは、IDE のような複合ワークロードでは「一部だけ抜ける」盲点を抱えがちです。ログとルールの対応が追いやすく、コミュニティのルール資産も豊富な Clash 系は、そのギャップを小さくする選択肢になります。使い慣れたプロファイルを保ったまま、Google 名空間だけを手早く強化したい場合も、同じ設計思想に乗せて運用できます。ここまでの手順を試したあとも改善が限定的なら、プロバイダ側の輻輳やアカウント制限に目を向けてください。安定したクライアントを手元に置きたい場合は、各 OS 向けビルドを 無料で入手して、Antigravity／Gemini の接続をログベースで詰めるのがおすすめです。