ネットワーク実践 Google AI タグ： Google Gemini ルール分流 Google API

Google Gemini が開けない・API エラー？Clash のルールで Google 系ドメインとノードを固定する（2026）

2026 年も生成 AI の選択肢は広がりますが、Google Gemini のブラウザ UI（gemini.google.com）と、Google API（例：generativelanguage.googleapis.com）は、ホスト名も認証フローも OpenAI／ChatGPT とは別物です。本稿では Clash のルール分流とノード選択、DNS の観点から、接続ログに沿って Google 向けの経路を揃える手順を整理します。違法な迂回や規約違反を助長する内容ではありません。

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

1. なぜ Gemini と Google API を分けて考えるか

生成 AI の利用は、単一のチャット画面に収まらず、ブラウザ上の会話、Google AI Studio や Cloud コンソールからのキー発行、そしてアプリからの REST 呼び出しまで広がっています。Google Gemini を例に取ると、普段触れる gemini.google.com の体験と、SDK が向かう generativelanguage.googleapis.com などの Google API エンドポイントは、TLS の終端もキャッシュポリシーも別物です。

そのため「とりあえず海外ノードに繋げばよい」だけでは足りず、どのホストが DIRECT のまま残っているか、どのルールに先にマッチしているかをログで確認する必要があります。ここが整理できると、Clash のルール分流は「接続の地図」を描くツールとして非常に強力です。

クライアントの入手と更新は ダウンロードページから、用語の整理は ドキュメントを併せて参照してください。

2. ChatGPT／OpenAI 記事との違い（ドメイン集合）

当サイトでは ChatGPT／OpenAI 向けに、openai.com や chatgpt.com 周辺をルール分流する考え方をまとめています。本稿の主題はそこではなく、Google が提供する検索・認証・静的配信・API を束ねる別の名前空間です。

つまり、OpenAI 用に書いた DOMAIN-SUFFIX をそのまま足しても、Gemini のブラウザ体験や Google API のエラーは解消しないことがあります。逆に、Google 向けに広く google.com 系を PROXY に寄せたからといって、ChatGPT 側の CAPTCHA やセッション挙動が自動的に安定するわけでもありません。併用するサービスごとに、ログに出た実名でルールを足すのが現実的です。

Windows クライアントの画面の違いは クライアント比較記事も参照してください。

3. 症状：ブラウザと API で分かれる理由

典型的には次のような組み合わせです。gemini.google.com は開けるが、スクリプトから Google API を叩くとタイムアウトする。あるいはその逆で、API は通るがブラウザのサインインや画像読み込みが不安定になる。前者は googleapis.com 系が別ルールに落ちている、後者は gstatic.com やアカウント系ホストが DIRECT に残っている、などのパターンがよくあります。

また、HTTP ステータスや JSON の error が 403／429 などで返る場合、必ずしもプロキシの失敗ではありません。地域制限、課金プラン、プロジェクトのクォータ、API キーのスコープ不足など、アプリケーション側の理由も並びます。まずは同じノード・同じ DNSでブラウザと CLI の両方を揃え、再現性を切り分けると早いです。

ヒント：ブラウザの開発者ツールで Network タブを開き、失敗しているリクエストのホスト名をメモしてから Clash のログと突き合わせてください。推測で DOMAIN-KEYWORD,google を増やすより安全です。

4. 関係しやすいホストと Google 系サフィックス

実装とリージョンは更新されるため、以下は設定時の思考のための例です。正は常にクライアントの接続ログと、利用中の公式ドキュメントです。

  • 対話 UI：gemini.google.com や関連する google.com 配下のホスト。アカウント連携やリダイレクトで accounts.google.com が絡みます。
  • 静的資産：gstatic.com など。読み込みの一部だけ別経路になると、画面が「半分だけ白い」ことがあります。
  • Generative AI API：多くの SDK が generativelanguage.googleapis.com を参照します（エンドポイントはバージョンや機能で変化し得ます）。
  • Google API 共通：googleapis.com 配下には多数のサービスが同居するため、必要に応じてより細かい DOMAIN 指定へ寄せます。
  • 開発者向け UI：ai.google.dev や AI Studio 系のホスト。キー発行フローで追加のホストが出ます。

この「バラバラのサブドメイン」を一括で意図した出口に寄せるのが、ルール分流です。DOMAIN-SUFFIX,google.com は強力ですが範囲が広いので、社内ポリシーや誤爆の懸念がある場合は、ログに出たホストへ絞り込んでいく運用が向きます。

ログの見方

GUI クライアントでは接続ログに ルール名と実際のノードが並ぶことがあります。期待と違うときは、rules: が上から評価されることを思い出し、先頭付近の GEOIP や巨大な RULE-SET に飲まれていないかを確認します。

5. Clash でのルール分流の書き方

Clash（Mihomo 系コア）では、rules: に DOMAIN、DOMAIN-SUFFIX、外部 RULE-SET などを並べ、最後に MATCH で全体のデフォルトへ落とします。Google Gemini と Google API を広くカバーする最小例を示します（実運用ではログに合わせて追記・修正してください）。

# Example only — verify hostnames in your client logs
rules:
  - DOMAIN-SUFFIX,google.com,PROXY
  - DOMAIN-SUFFIX,googleapis.com,PROXY
  - DOMAIN-SUFFIX,gstatic.com,PROXY
  - DOMAIN-SUFFIX,googleusercontent.com,PROXY
  - DOMAIN,generativelanguage.googleapis.com,PROXY
  - MATCH,DIRECT

DOMAIN-KEYWORD,google は短く書けますが、意図しないホストへマッチするリスクもあるため、可能なら DOMAIN-SUFFIX と明示的な DOMAIN の併用に寄せるのが無難です。購読している RULE-SET が先に当たって Gemini だけ別出口にしたい場合は、ルールの順序を見直すか、プロファイルを分けて切り替える方法もあります。

注意：公開ルールセットは更新頻度と網羅性にばらつきがあります。Google API だけ不安定なときは、まず短い追記ルールで切り分け、改善を確認してから本流へ戻すのが早いです。

6. ノード選択とレート制限の読み方

ノード選択は、単に表示遅延が小さいものを選べばよい、という話だけではありません。Google のフロントと API は、輻輳や BGP、プロバイダ側のレート制限の影響を受けます。体感として「速いが頻繁に切れる」より「やや遅いが落ちにくい」が勝つこともあります。

実務的には、同一プロファイル内で複数ノードを試し、gemini.google.com の会話と、短い Google API リクエストの両方で再現性を見ます。429 が出る場合は、ネットワーク以前にクォータやプランを疑い、リトライ間隔をアプリ側で調整するのが筋です（実装はアプリの責務ですが、ネットワークの揺らぎと混同しないのが重要です）。

フォールバック系の考え方

自動フェイルオーバー系のグループを使う場合、閾値が甘いとノードが泳ぎ、厳しすぎると改善が遅れます。まずは手動で安定ノードに固定し、問題が再現しないことを確認してから自動化を検討するのが無難です。

7. DNS・ログイン・OAuth の落とし穴

Clash 利用者がつまずきやすいのが DNS です。Fake-IP を使う構成では、名前解決のタイミングとルール評価が密接に絡みます。結果として「ブラウザでは見えているのにコアのログでは別挙動」という混乱が起きます。Google アカウントのサインインや OAuth フローは複数ホストに跨るため、ルール分流と矛盾しない名前解決が揃っているかを確認してください。

企業ネットワークやセキュリティ製品の HTTPS インスペクションが有効だと、ブラウザだけ証明書エラーや、API だけ TLS 失敗という切り分けにもつながります。自宅環境で再現するか、別端末で試すのも有効です。

IPv6 だけが別経路に出ているケースも稀にあります。OS やルータで IPv4 を優先し、挙動が変わるかを見るのも手早い切り分けです。

8. 簡易セルフチェック

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

  1. クライアントの更新：古い GUI はコアと挙動がズレます。ダウンロードページから入手できる最新系へ。
  2. システムプロキシと TUN：トラフィックをどちらに載せているかを統一。例外アプリがないか。
  3. ルールのヒット：ログで Google API や gemini.google.com が期待のポリシーに乗っているか。
  4. ノードの健全性：別ノードへ切り替えて再現性を確認。
  5. DNS：Fake-IP や redir-host と矛盾がないか。
  6. API 側のエラー本文：403／429 の理由がクォータや権限でないか。

これでも改善しない場合は、プロバイダ側の障害や地域的な制限の可能性が高まります。公式ステータスやコミュニティの報告と突き合わせ、時間を置いて再試行するのも現実的です。

9. OpenAI との対照表

ChatGPT 向け記事で扱うホスト群と、本稿の Google Gemini／Google API は併用されても、ルールを流用しすぎない方が安全です。

観点 OpenAI／ChatGPT 側（参考） Google／Gemini 側（本稿）
代表ドメイン openai.com、chatgpt.com など google.com、googleapis.com、gstatic.com など
API の典型ホスト プロバイダ固有の API エンドポイント generativelanguage.googleapis.com など
ルールを流用したときのリスク — Google 向けホストが DIRECT に残り、片方だけ不通
まず見るログ OpenAI 記事のチェックリスト gemini.google.com と API ホストの両方

10. まとめ

Google Gemini のブラウザ体験と Google API は、ホスト名が分散しており、ルール分流の設計ミスが「ページは開くが返答だけ出ない」「API だけ 403」といった形に現れます。Clash で google.com／googleapis.com 系を意図した出口に寄せ、ノード選択と DNS をセットで見直すと、体感はかなり落ち着きます。

同種のツールと比べて、Clash 系はログとルールの対応が追いやすい場合があり、試行錯誤のコストを下げられます。ChatGPT 向けのルールと並行して運用するときも、ドメイン集合が異なることを前提に、ログに出た実名からルールを育てていくのが 2026 年時点でもいちばん再現性の高いやり方です。

→ Clash を無料ダウンロードして、Gemini と Google API の接続を試す