Google Gemini 3.5 と Gemini Spark 公開×Clash：Agent API 分流と DNS 実測（2026）
2026年5月のGoogle I/Oで、高速推論向けのGemini 3.5 Flashと、Gmail・カレンダー・マップなどを横断するGemini Spark（跨アプリ Agent）が話題になり、日本語圏でも「Web は開くのに Agent API だけタイムアウト」「地域制限で Spark が使えない」といった検索が急増しています。外向き HTTPS は gemini.google.com の会話 UI、generativelanguage.googleapis.com のGenerative Language API、認証の accounts.google.com、共有基盤の googleapis.com に分かれ、Clash（多くは Clash Verge Rev＋Mihomo コア）の分流順序やDNSのねじれで症状がぶれます。本稿は热点×Clashの切り口で、3.5／Spark 新機能に合わせたログ主導の DOMAIN ルールと DNS 検証を日本語でまとめます。記載ホストはサービス更新で増減するため、YAML は叩き台とし、必ず自分の接続ログを正にしてください。
検索意図：Gemini 3.5／Spark を「単一ドメイン」で通そうとしない
Gemini 3.5は、従来の Gemini より応答速度とマルチモーダル処理を強化した世代として、開発者コンソールやモバイルアプリからすぐ触れるようになっています。一方Gemini Sparkは、単なるチャットではなく、複数 Google アプリにまたがるタスク実行型 Agentとして設計されており、短い REST より長いストリーミングやツール呼び出しで接続先が増えやすいです。購読テンプレの巨大な RULE-SET や GEOIP に先に吸われて意図しない DIRECTへ落ちる——という失敗は、Kimi K2.6×ClashやManus など AI エージェントの热点記事と同型です。
既存のGoogle Gemini ブラウザ向け分流稿は会話 UI 中心、Gemini CLI タイムアウト稿はターミナル CLI 中心です。本稿はGoogle I/O 2026以降の3.5 モデルとSpark Agent、およびAgent API（generativelanguage.googleapis.com）にフォーカスし、Web と API が別 policy に割れるケースを優先して扱います。用語の前提はチュートリアルとカスタムルールを先に押さえると、以降のログ読みが速くなります。
ステップ 1：Web・Spark・Agent API のどこが壊れているか
切り分け表を頭に置きます。(A) gemini.google.com の Web 会話やモバイルアプリは表示できるが、Sparkの跨アプリ連携だけ失敗する、(B) 自作アプリや SDK からのAgent API（generativelanguage.googleapis.com）だけタイムアウトする、(C) Gemini CLIや IDE 拡張だけハングする、の三つに大別できます。(A) は Spark 連携用の追加 FQDN 漏れや OAuth ループ、(B) は API ホストが別 proxy-groups や DNS 経路、(C) はターミナルがシステムプロキシを読まないか NO_PROXY で迂回、が典型です。
Gemini 3.5 Flashを選んだ直後だけ増えるホストは、コミュニティの固定表にまだ載っていないことがあります。検索結果の「代表ドメイン3つ」より、Clash Verge Revの接続一覧で自分の Rule ログ一行を信頼してください。Spark の Agent 実行では HTTP/2 のチャンク転送が続き、短いヘルスチェックだけ成功する部分的成功にも見えます。地域制限メッセージが出る場合でも、まずは認証と API が同じ出口に揃っているかをログで確認し、ノード品質の問題とルール漏れを分けます。
google.com サフィックスの影響範囲に注意してください。
ステップ 2：Clash 接続ログで Google AI の FQDN を資産化する
分流を書く前に、Mihomo 系 GUI のコネクション一覧や Verge 系のログで、3.5 推論中やSpark タスク実行中に張られた host／sni を拾います。タイムアウト行の直前に現れた名前を DOMAIN の材料にしてください。googleapis.com のサフィックス一括は運用は速い反面、国内向け Google サービスまで同じ出口に乗るため、まずはログで狭める運用が向きます。
並行して、ブラウザ拡張・別 VPN・社内 PAC が同じマシンで別ポートを指していないか確認します。HTTP(S)_PROXY と Clash のシステムプロキシ注入が二重だと、「ルールは正しいのにブラウザだけ別穴」が起きやすいです。NO_PROXY に googleapis.com を広域で入れると、Agent APIだけ意図せず直叩きに逸れ、TLS が途中でぶら下がって総タイムアウトに見えることもあります。
ステップ 3：Gemini 3.5／Spark／Agent API 向け DOMAIN ルール（叩き台）
購読テンプレに大きな RULE-SET がある場合、上から先にマッチした行が勝つため、以下のような狭い行をリスト上位へ寄せます。Gemini_Agent は安定した proxy-groups 名に置き換え、ログに出ていない行は削る／足す前提で使ってください。
proxy-groups:
- name: Gemini_Agent
type: select
proxies:
- あなたの海外ノード名
- DIRECT
rules:
# Replace Gemini_Agent — extend from YOUR logs only
- DOMAIN,generativelanguage.googleapis.com,Gemini_Agent
- DOMAIN-SUFFIX,gemini.google.com,Gemini_Agent
- DOMAIN-SUFFIX,accounts.google.com,Gemini_Agent
- DOMAIN-SUFFIX,googleapis.com,Gemini_Agent
- DOMAIN-SUFFIX,gstatic.com,Gemini_Agent
# Spark / OAuth / CDN — add only what YOUR connections panel showsgenerativelanguage.googleapis.comはAgent APIと Gemini CLI／各種 SDK が共有する入口として検索されやすく、ここが DIRECT のままだと「Web の Spark は動くのに curl だけ死ぬ」に見えます。一方 gemini.google.com は 3.5 の会話 UI と Spark のフロント、accounts.google.com はログイン Cookie の地域ブレを減らすために同じ Gemini_Agent 出口に揃えるのが定石です。
googleapis.com は YouTube や他 Google クラウド API とも共有されるため、影響範囲が広がる可能性があります。問題が出たらログでホストを特定し、DOMAIN で一段狭めるか、Mixin で断片だけ追記する手順はClash Verge Rev の Mixin 稿（macOS でも発想は共通化可能）が参考になります。並行して proxy-groups のガイドで url-test の計測間隔も見直すと、3.5 の長いストリームでノード切替が安定しやすくなります。
ステップ 4：Agent API／SDK／Gemini CLI のターミナルプロキシを揃える
Agent APIを Python／Node SDK や REST クライアントから叩く場合、ブラウザの Spark とは別経路になります。Gemini CLI のタイムアウト稿と同様、親ターミナルに export HTTPS_PROXY=http://127.0.0.1:7890（ポートは自分の mixed-port に合わせる）を入れ、HTTP_PROXY も揃えます。ALL_PROXY を socks5 にする構成では、SDK 側が socks を解釈しないビルドもあるため、まず HTTP プロキシでベースラインを取るのが無難です。
IDE 内の Copilot や Cursor 系エージェントとGemini 3.5を同時に動かすと、別ホストが同じ遅い出口に乗り、Gemini だけが遅いように錯覚することもあります。切り分け時はCursor／GitHub 分流やCopilot 分流との干渉も意識してください。プロキシ変数が効かない実行ファイルには、TUN でコア側にトラフィックを寄せる逃がし経路があります。副作用はTUN モード解説を読んでから試してください。
ステップ 5：DNS（fake-ip／nameserver-policy）を単一変数で振る
DNSは「短い GET は成功するのに、3.5 の長いストリームや Spark の Agent タスクだけ失敗」タイプを生みやすい層です。enhanced-mode の fake-ip と OS の resolver、macOS のネーム解決順、ブラウザの Secure DNS が噛み合わないと、表示と実コネクションの宛先が食い違います。検証は一度に一つの項目だけ変えます。(1) fake-ip と redir-host の切替、(2) nameserver-policy で googleapis.com／gemini.google.com 系だけ別 resolver、(3) IPv6 優先の ON/OFF、の順が追いやすいです。
Public DNS と DoH を同時に二系統足すと、どちらが効いたかログから読みにくくなるため、まずは nameserver を単純化してから policy を足す構成を推奨します。Linux では systemd-resolved との競合が典型で、Linux の Clash DNS トラブルとMeta／Mihomo の sniff と DNSを参照しつつ、Gemini 3.5／Spark 実行中のログ差分を正にしてください。モバイルで Spark アプリだけ失敗する場合は、OS の「常時 VPN」や省電力でクライアントが止まっていないかも確認します。
ステップ 6：他の Gemini／Agent 热点記事との棲み分け
2026 年の热点は Agent 系が並立しますが、ドメインは共有されません。OpenAI Codexは chatgpt.com 系、Claudeは anthropic.com 系、Cursorは cursor.sh 系が中心です。Gemini 3.5／Sparkを触るなら Google AI の FQDN セットを別ファイルで管理し、購読 YAML に無秩序に足さない方が長期運用に向きます。ブラウザだけ安定させたい読者は一般 Gemini 分流稿へ、CLI だけ直したい読者はCLI 稿へ誘導するのが、検索意図の重複を避けるコツです。
Clash Verge Revのログパネルで接続タイムアウトを追う手順はWindows 11 ログパネル稿も参考になります。macOS 初回設定はClash Verge macOS 稿を併読すると、システムプロキシと TUN の選び方が整理しやすくなります。
よくある質問
Gemini の Web は開くのに Agent API だけタイムアウトするのはなぜ？
チャット UI と Generative Language API でホスト集合が分かれ、generativelanguage.googleapis.com が別 proxy-groups や DNS 経路に落ちていることが多いです。API 行の FQDN と採用ルール名をログで揃えてください。
generativelanguage.googleapis.com だけ通せば Gemini 3.5／Spark は足りる？
単一行だけで済む環境もありますが、認証・Spark連携・静的 CDN・OAuth で増えるサブドメインがログに現れるビルドは普通です。Agentタスク実行中だけ増えるホストも追補が必要です。
Gemini Spark と Gemini CLI は同じプロキシ設定で動く？
Sparkはブラウザとモバイルアプリ中心、Gemini CLIはターミナルがシステムプロキシを読まない場合が多いです。CLI 向けは環境変数か TUN で明示し、Gemini CLI 記事の手順も併用してください。
まとめ
Google I/O 2026で注目のGemini 3.5と跨アプリ Gemini Sparkは、実務ではWeb 会話・Agent API（generativelanguage.googleapis.com）・ターミナル SDK／CLIの三経路に分解して考えると、Clash 分流とDNSの設計ミスが「一部だけタイムアウト」として顕在化しやすくなります。利用形態の分類→ログで FQDN と policy を取得→狭い DOMAIN をリスト上位へ→API／CLI のターミナルプロキシを一本化→DNS を単一変数で検証→他 Agent 热点記事とドメイン集合を分離管理の順に進めると、再現性が上がります。
ブラウザ拡張だけの簡易切替や、従来型の単機能プロキシでは、Spark の長い Agent タスクと短い RESTを別経路で追いかけつつ、googleapis.com 共有による副作用までを同一ログ画面で比較する運用までを一気通貫で持ち上げにくいものもあります。一方 Clash／Mihomo 系はルール順と接続ビューを軸に微調整でき、ホストが増え続けるGoogle AI Agentとも相性がよいです。入手経路を一本化したい場合はダウンロードページから確認し、VPN との設計差はClash と VPN の比較も参考にしてください。
→ Clash を公式の入手先からダウンロードし、Gemini 3.5／Spark 利用中の接続ログで Google AI 向け分流を整える