1 背景とゴールをそろえる
Gemini 2.5 は、マルチモーダル推論や長文コンテキスト、開発者向け無料枠の訴求など、2026 年時点で Google クラウド AI の前面に立つブランドです。Google AI Studio はブラウザからプロンプトとモデル選択、キー発行までを一気通貫で扱う UI で、ローカルのエディタやスクリプトからは generativelanguage.googleapis.com をはじめとする Google API エンドポイントへ HTTPS で接続します。ここで問題になるのは、単一アプリだけではなく認証・課金・テレメトリ・CDNに分散した複数ホストが短時間に並列で開く点です。ブラウザ拡張や社内プロキシ、VPN の「分割トンネル」が混ざると、AI Studio だけ開けるのに API だけ 403 や TLS エラーになる、という切り分けが難しくなります。
本稿のゴールは、帯域を無理に広げることではなく、Clash の Rule モードで Google 向けトラフィックを意図したアウトバウンドへ集約することです。IDE 向けに既に公開しているCursor と Clash の記事は、Electron ベースの開発ツール全般に焦点を当てています。こちらは Google クラウド側のドメイン設計に寄せた補完編として読むと、AI コーディングと Gemini API を同じマシンで安定運用しやすくなります。
2 Gemini と AI Studio が触るホストをざっくり把握する
実際のホスト名は時期やリージョン、A/B テストで増減しますが、設計上は次のような束に分かれます。ひとつでも DIRECT に落ちると、ブラウザ上は成功ログでも裏で別リクエストが失敗する、という見え方になります。
- Google AI Studio／コンソール UI：
*.google.com、*.google.dev、*.ai.google.dev周辺の HTTPS。OAuth やアカウント連携ではaccounts.google.com系も絡みます。 - Generative Language API（Gemini API）：
generativelanguage.googleapis.comを中心に、*.googleapis.com配下の gRPC／REST。クライアントライブラリは環境変数HTTPS_PROXYを見る場合と、OS のプロキシを見ない場合があります。 - 補助ドメイン： ドキュメントや静的アセット、フォント、テレメトリなど
gstatic.com、googleusercontent.com、gvt*.com系が混ざることがあります。厳密にホワイトリストだけにすると保守が破綻しやすいので、広めのサフィックスルール＋信頼できる Rule Provider を組み合わせるのが現実的です。
まずは Clash の接続ログで、失敗時にどの SNI が出ているかを確認してください。ルールが細かすぎて未知のサブドメインが直行しているケースは、ログを見れば一発で絞れます。
3 ルールモードとプロキシグループの置き方
推奨は mode: rule で、Google 向けに専用のセレクタまたは URL テスト付きグループを一枚挟む構成です。例えば PROXY-GOOGLE のようなグループを作り、遅延の低いノードと、帯域はあるが不安定なノードを分けておくと、Gemini API の長めのストリームが途中で切れる問題を A/B しやすくなります。グローバルモードにすると国内向けサービスまで遠回りし、逆にダイレクト固定では Google だけ詰まる、というジレンマが出ます。
すでに購読ルールに「国外サイト用」のプロキシ行がある場合は、そのブロックの直前に Google 向けの明示ルールを置き、意図せず別リージョンのノードへ飛ばないようにします。セレクタで国を切り替える運用では、AI Studio の利用規約上、特定リージョンに紐づく制限がある場合もあるため、公式ドキュメントの表記とあわせて確認してください。
4 YAML に書くルール例（Mihomo／Clash Meta 互換）
以下はイメージです。実際のインデントや proxy-groups 名は、手元の購読テンプレートに合わせてください。コメントは英語のみとします。
# Example: route Google properties to a dedicated selector
rules:
- DOMAIN-SUFFIX,google.com,PROXY-GOOGLE
- DOMAIN-SUFFIX,google.dev,PROXY-GOOGLE
- DOMAIN-SUFFIX,googleapis.com,PROXY-GOOGLE
- DOMAIN-SUFFIX,gstatic.com,PROXY-GOOGLE
- DOMAIN-SUFFIX,googleusercontent.com,PROXY-GOOGLE
- DOMAIN-KEYWORD,google,PROXY-GOOGLE
# Optional: tighten after you confirm working hostnames
# - DOMAIN,generativelanguage.googleapis.com,PROXY-GOOGLE
DOMAIN-KEYWORD,google は強力ですが、誤って関係ないホストへまでマッチする可能性があります。運用が落ち着いたら接続ログを見て、サフィックスルールへ寄せていくと安全です。Rule Provider で「Google 系」のリモートリストを購読している場合は、ローカルの追記ルールと優先順位が衝突しないよう、rules セクションの並びを確認してください。上位に書いたルールが先に評価されます。
CLI から API を叩く場合、プロキシを明示しないと OS のルーティングに任せます。Python などでは HTTPS_PROXY=http://127.0.0.1:7890 を併用するか、TUN モードで仮想 NIC レベルに揃えると、環境変数のばらつきを減らせます。
5 DNS・FakeIP・TLS をセットで見る
Google 系はドメイン数が多く、DNS の答えが期待とズレると「ブラウザでは開けるのに CLI だけ名前解決が変」という現象が出ます。Mihomo では DoH、FakeIP、fallback-filter の組み合わせが定番です。設定の細部はMeta カーネル DNS の実務記事に譲り、ここでは要点だけ挙げます。Clash の DNS セクションと OS の DNS を二重管理しないこと、TUN と DNS ハイジャックを併用するときにローカル開発用ゾーンを DIRECT に残すこと、が安定運用の鍵です。
6 Google AI Studio と API の動作確認
ブラウザで AI Studio を開き、モデル一覧とチャットが表示できる状態を基準にします。次に、同じマシンからターミナルで curl により generativelanguage.googleapis.com へ TLS ハンドシェイクが完了するかを見ます。ここでだけ失敗する場合は、ルールではなく環境変数か、CLI がプロキシを参照していないことが多いです。ストリーミング応答は HTTP/2 の長めのセッションになるため、不安定な UDP ベースのトランスポートや、パケット損失の大きいノードでは UI 上「途中で途切れる」ように見えます。セレクタで別アウトバウンドへ切り替え、再現性を比較してください。
API キーと課金の注意
キーはリポジトリにコミットしない、環境変数やシークレットマネージャに載せる、といった基本は変わりません。無料枠と従量課金の境界は公式ダッシュボードの数字を正としてください。ネットワーク記事では料金や上限がすぐに古くなるため、手元のプロジェクト設定で必ず確認してください。
7 Gmail、Drive、Colab など「Google 全系」への展開
本稿で整えた google.com／googleapis.com 系のサフィックスは、Gmail の Web、Google Drive、Colab、Calendar など、同じエコシステムの HTTPS トラフィックにも広く効きます。細かいドメイン差分は時期で変わるため、接続ログで未知のホストを拾い、ルールを少しずつ補強するのが安全です。動画会議や Meet では UDP が絡むケースがあり、TCP だけのプロキシ設計だと音声だけ不安定になることもあります。そうしたときは TUN と、アウトバウンドの UDP 対応を含めた設計を検討してください。
ルーター層で家族全員のデフォルト経路を揃えたい場合は、OpenClash on OpenWrtのような構成も選択肢です。PC 単体の検証が済んでから家全体へ広げると、夜中の切り戻しが楽になります。
8 トラブルシューティング
- ブラウザだけ成功して CLI が失敗： システムプロキシと環境変数のどちらかが未設定、または TUN がオフ。シェルに
http_proxy／https_proxyを足すか、TUN を有効化して経路を一本化します。 - 403／地域制限のメッセージ： ルールではなくアカウント側の制約の可能性があります。接続先リージョンと、Google アカウントの設定を公式ドキュメントと照合します。
- ストリームが途中で切れる： ノードのパケット損失や、HTTP/2 の長连接切断を疑い、セレクタで別サーバへ切り替えて比較します。
- 証明書エラーが出る： 企業ゲートウェイの TLS インスペクション、またはローカルセキュリティソフトの HTTPS スキャンを疑います。
- ルールを足したら国内サイトが遅くなった：
GEOIP,CN,DIRECTなど定番の直行ルールとの順序を見直し、Google 向けルールが国内トラフィックに誤マッチしていないか確認します。
9 まとめ
Gemini 2.5 と Google AI Studio を「ブラウザだけ速くする」のでなく、Generative Language API を含む Google クラウドへの経路をルールと DNS で一貫させると、開発者ワークフロー全体の再現性が上がります。Clash 互換クライアントは、セレクタと Rule Provider、FakeIP を組み合わせることで、単発のプロキシ設定よりも長時間の API セッションに強い構成を作りやすいです。Cursor など別の AI IDE を併用する場合も、出口設計を揃える意味で、本稿の Google ドメイン整理とIDE 向けの記事を対で読むと理解が早いです。
まずは手元の YAML に Google 向けサフィックスを追記し、接続ログで漏れがないか確認し、必要なら Rule Provider のリストと優先順位を調整してください。DNS の細部はDNS 実務記事に譲ります。ルール分流とログの読み方さえ身につけば、同じ考え方を他のクラウド API にも転用できます。
単機能の軽量プロキシより、ルールと DNS を一体で扱える Clash 互換スタックの方が、長めの HTTPS ストリームや分散ドメインに強い場面が多いです。Gemini のようなストリーミング応答では、安定性の差がそのまま試行回数とコストに影響します。
