なぜ今「Gemini Mac」と Clash 分流なのか

2026 年に入り、Google は生成 AI の体験をデスクトップへ寄せる動きを強めており、その一環として macOS 向けのネイティブ Gemini クライアントや、画面上から素早く呼び出せるショートカット的な導線が話題になりました。新しいクライアントは「ひとつのドメインに全部集約された単純な Web アプリ」ではなく、Google アカウントの OAuth、会話本体のバックエンド、Google AI Studio（旧来の Maker Suite 系の文脈を含む開発者向け UI）、そして Generative Language API のようなホストへ、用途ごとに通信が分岐しがちです。

その結果、ネットワーク環境によっては「ブラウザでは Google のページが開けるのに、Gemini Mac だけログインが終わらない」「トップ画面は出るのに、送信後の生成がずっと回る」「Studio だけ別のエラーになる」といった部分的成功が起きます。ここで有効なのが、Clash／mihomo の分流です。広い PROXY 一括よりも、ドメインルールで「このサフィックスはこの出口」と決めておくと、原因の切り分けが速くなり、日常利用のノード切り替えも安全になります。

症状の型：ログイン、生成、Studio、API が別々に止まる

まず現場で多いのは次のようなパターンです。どれにも当てはまるかをメモしてからルールを足すと迷いが減ります。

  • 認証まわり：accounts.google.com や oauth 系の往復が遅い／ブロックされ、ログイン画面が回り続ける。ブラウザの Google ログインは成功しているのに、アプリだけ失敗する、という差も出ます。
  • 会話 UI：gemini.google.com やクライアント同梱の取得先に依存するホストがタイムアウトし、送信後に応答が返らない。一方で静的アセットだけは届いているように見えることもあります。
  • Google AI Studio：ブラウザ版 Studio は通るが、デスクトップ連携や特定 API キーの検証だけ失敗する、など開発者向けエンドポイントに偏った詰まり。
  • API 直叩き：generativelanguage.googleapis.com など Google API サフィックスへの TLS が意図しない経路に落ち、SDK や CLI からの呼び出しだけ失敗する。

いずれも「とりあえず全部プロキシ」でも直る場合はありますが、国内向けサイトを誤って遠回りにしたり、逆に広い DIRECT が先に当たって Gemini Mac だけ直結のまま残る、というルール順序の問題が混ざると再現がブレます。だからこそ、ホスト名をログで確定させることが先です。

「汎用 AI サイト分流」との違い（ChatGPT／Grok 記事との差）

当ブログでは、ブラウザで ChatGPT や Grok などの Web を安定させるための分流を、別記事で扱っています。そちらは「生成 AI のドメイン集合を RULE-SET や DOMAIN-KEYWORD で束ね、AI 専用プロキシグループへ流す」という骨格が中心です。一方、本稿の焦点は Gemini Mac と Google AI Studio、そして Generative Language API のようなGoogle 生態系に閉じたホストの組み合わせです。

つまり「AI サイト用グループを一つ増やせば万事解決」とは限らず、Google アカウントの認証、会話アプリ、開発者コンソール、API で出口ポリシーを分けた方が運用しやすいケースがあります。ブラウザ向けの一覧と機械的に同じルールを貼り付けるのではなく、クライアントの接続ログに出る実名を軸に足していくのがコツです。

押さえるホストの地図（例と注意）

以下は設定の出発点としての例示であり、利用する機能・リージョン・アプリのバージョンで変わります。必ず自分の環境のログで確認してください。

  • 会話・製品 UI：gemini.google.com、関連する google.com サブドメイン。
  • 開発者向け UI：aistudio.google.com、ドキュメントや取得先に紐づく ai.google.dev など。
  • Generative Language API：generativelanguage.googleapis.com を代表とする *.googleapis.com 配下。ここは他の Google クラウド API と広く共有される名前空間のため、可能ならAPI ごとのサフィックスを限定し、安易に全域マッチを増やさない方が安全です。
  • 認証：accounts.google.com、必要に応じて ssl.gstatic.com などの静的配信。ログインだけ別ノードにしたい場合に分離します。

記法の共通理解は YAML・ルール分流の解説記事と対応します。RULE-SET で信頼できる集合体を取り込みつつ、Gemini／Studio 用の追記行をその上に置くイメージが扱いやすいです。

ヒント

macOS はシステムの DNS キャッシュやプライベートリレー、別セキュリティ製品のフィルタと相互作用します。Clash 側のルールが正しくても名前解決が別経路だと「ルールが効いていないように見える」ことがあるため、DNS モードと nameserver-policy を会話系サフィックスで揃えると改善することがあります。仕組みの補足は ドキュメントの Fake-IP／DNS 解説が参考になります。

プロキシグループ設計：GEMINI_APP / GEMINI_API / GOOGLE_AUTH

実務では、次のような意味の違いでグループを分けると切り分けが楽です（名前は任意）。

  • GEMINI_APP：会話クライアント本体が伸びるホスト。体験優先でレイテンシの小さいノードを選びたいときに使います。
  • GEMINI_API：generativelanguage.googleapis.com など API 専用。SDK や自動化からの失敗をここに集約すると原因が見えやすいです。
  • GOOGLE_AUTH：accounts.google.com など。認証だけ別出口にしたいポリシー（企業プロキシとの兼ね合い等）に対応します。

いずれも select 型にしておくと、症状に応じてそのグループだけ差し替えられます。url-test は便利ですが、セッション中に頻繁に切り替わると認証や長い生成が途切れることがあるため、まずは手動選択から始めるのが無難です。

# Concept only — verify every suffix in your own logs; avoid over-broad googleapis rules.
proxy-groups:
  - name: GEMINI_APP
    type: select
    proxies:
      - node-low-latency
      - node-us-west
      - DIRECT
  - name: GEMINI_API
    type: select
    proxies:
      - node-us-west
      - DIRECT
  - name: GOOGLE_AUTH
    type: select
    proxies:
      - node-us-west
      - DIRECT

rules:
  - DOMAIN-SUFFIX,accounts.google.com,GOOGLE_AUTH
  - DOMAIN-SUFFIX,gemini.google.com,GEMINI_APP
  - DOMAIN-SUFFIX,aistudio.google.com,GEMINI_APP
  - DOMAIN-SUFFIX,ai.google.dev,GEMINI_APP
  - DOMAIN-SUFFIX,generativelanguage.googleapis.com,GEMINI_API
  # Keep these above broad GEOIP / DIRECT / MATCH ...
  - MATCH,PROXY

上記はあくまで雛形です。実際には googleusercontent.com や CDN 系、テレメトリ／更新ホストが追加で現れることがあります。Clash の接続ログで Matched を確認し、漏れを足してください。

DNS と Fake-IP：名前解決をルールと同じ意図に揃える

分流が効かない典型原因は、ルール以前にDNS の出口と Fake-IP の例外です。macOS のネイティブクライアントは短時間に多数の名前解決を行うため、nameserver-policy で google.com 系の一部サフィックスだけ信頼できるリゾルバへ寄せる、といった整理が有効なことがあります。Fake-IP を使う構成では、fake-ip-filter に誤って必要ホストが入っていないか、逆に不要な広い例外が入っていないかを点検します。

dns:
  enable: true
  enhanced-mode: fake-ip
  nameserver:
    - https://dns.example/dns-query
  nameserver-policy:
    "+.google.com": https://dns.example/dns-query
    "+.googleapis.com": https://dns.example/dns-query

ポリシーに書くサフィックスは、自宅／職場のポリシーと衝突しない範囲で最小限に留めるのが安全です。

macOS での Clash：TUN とシステムプロキシの見方

Gemini Mac のようなネイティブアプリは、Electron 製の IDE ほど極端ではないものの、システムプロキシ設定を参照しない挙動や、キーチェーンに保存した資格情報に依存する認証フローが絡むことがあります。Clash を TUN で動かしている場合は OS 全体のトラフィックがコアに集まりやすく、ルールの当たりが素直に見えます。一方、HTTP プロキシのみの場合、アプリがプロキシを迂回すると「ブラウザは通るがアプリだけ詰まる」が再発します。

症状がアプリ限定のときは、システム設定のネットワークと Clash のモード（TUN／システムプロキシ）をセットで確認し、他の VPN クライアントと競合していないかも見ます。Windows 向けの詳細は別稿ですが、TUN 全般の切り分けの考え方は TUN のトラブルシューティング記事の論点（二重適用、ルート競合）と通じる部分があります。

Google AI Studio と API キー利用者へのメモ

Google AI Studio はブラウザでも開けますが、デスクトップ連携やキー発行フローは aistudio.google.com 以外のホストへ跳ぶことがあります。キーを使って Generative Language API を直接叩く場合、SDK のデフォルトエンドポイントが generativelanguage.googleapis.com に向く構成が一般的です。このとき GEMINI_API グループに明示的に流すと、「Studio は開くが API だけ失敗」といったホスト単位の切り分けが容易になります。

なお、Google Cloud の他製品（BigQuery など）も googleapis.com を共有するため、広すぎる DOMAIN-SUFFIX を安易に増やすと、意図しない業務トラフィックまで同じ出口に寄せてしまいます。API 名のサフィックスをログで絞り込むことを推奨します。

切り分けチェックリスト

  1. ログで実ホストを特定：ログイン中／生成中に失敗しているサフィックスを列挙する。
  2. ルール順序：広い DIRECT や地域判定が先に当たっていないか。Gemini／Studio／API 用の行を上へ。
  3. グループの責務：認証・会話・API を混ぜすぎていないか。必要なら GOOGLE_AUTH を分離。
  4. DNS：クエリがコアの設定どおりか、別 DNS クライアントが上書きしていないか。
  5. ノードの差し替え：同じ表示地域でも別出口で改善するかを試す。
  6. 重複ルールの整理：ブラウザ向け AI ルールと競合していないかを確認する。
注意

利用規約、プライバシー、雇用契約、社内セキュリティポリシーは環境ごとに異なります。本稿はネットワーク設定の一般的な説明であり、特定サービスの利用を推奨・保証するものではありません。

まとめ

Gemini Mac のような新しいデスクトップクライアントは、話題に比例してトラフィックの形も複雑になりがちです。Clash 分流の要点は、ブラウザ向けの汎用リストに頼り切らず、Google AI Studio や Generative Language API を含むドメインルールをログで裏取りし、認証・会話・API の出口を分けることにあります。こうしておくと、「どのホストが詰まっているか」を素早く特定でき、日常のノード運用も壊しにくくなります。

ルール検証を安定したクライアントから始めたい場合は、ダウンロードページで OS に合ったビルドを選ぶと手順が短くなります。オープンソースのリポジトリは挙動の理解に役立ちますが、実行ファイルの入手は配布ページを主な入口にすると、コアと UI の対応関係が追いやすいです。→ 無料で Clash をダウンロードし、Gemini 向け分流の検証を始める