研究型「AI 検索」と IDE ツールチェインは、ネットワークの悩み方が違う

Perplexity のような対話型検索や、Google NotebookLM のような資料取り込み・要約・音声ガイドまで含むリサーチ支援は、一見ブラウザの一タブに収まっているように見えます。しかし実際には、ページの HTML を返すオリジン、推論や検索裏側の API エンドポイント、アイコンやスクリプトを載せる CDN、そして Google 系では アカウント／OAuth／ストレージ まで、短いセッションのなかで複数ホストへリクエストが散らばります。

この性質は、Cursor や GitHub を中心にした AI 開発スタックの悩みとは重なりつつも焦点が違います。IDE 側は拡張マーケットや Git 操作、LFS、Copilot 系 API など「開発者インフラ」への依存が前面に出ますが、研究型 AI 検索は「検索結果の取得」「引用リンクの追跡」「PDF や Drive 連携」「Google ログインの往復」といったウェブとクラウド ID の境界が主戦場になりやすいです。だからこそ、同じ「AI」と言ってもルールセットを丸ごと流用せず、ドメインの束を分けた方が運用が楽になります。

本稿は正当な利用と、各サービスの利用規約・職場ポリシー・法令を順守する前提で書いています。ドメイン例は公開情報と一般的な観測に基づくものであり、プロダクト更新で入れ替わり得ます。実運用ではブラウザの開発者ツールや Clash のログでホスト名を確認し、差分は自分のリストへ反映してください。ルールの外部化や更新間隔の設計は Rule Provider の上級ガイド と相性がよく、長く使うほど効いてきます。

遅さの正体：マルチドメイン・CDN・TLS の積み上げ

体感が「重い」「途中で止まる」とき、単一の出口ノードが弱いだけとは限りません。たとえば、トップページは速いのに回答生成だけ遅い、ログイン直後だけ異常に待たされる、PDF をアップロードした瞬間だけ進行が鈍る、といった部分遅延は、ホストごとに最適経路が違うサインです。国内キャリアや社内回線では、特定リージョンの CDN へ直結すると RTT が伸び、逆に「とりあえず全部同じプロキシ」にすると、そもそも国内向けに最適化されたホストまで余計な迂回をして遅くなる、という両方が起きます。

Clash／Mihomo の分流は、このホスト単位の最適化に向いています。重要なのは「アプリ名」ではなく接続先の名前解決と SNIです。HTTPS の世界では、ブラウザのアドレスバーに出ているドメイン以外へ静かにリクエストが飛ぶのが普通なので、ルールを書くときは「見えている URL だけ」で満足しないことが第一歩になります。

Perplexity 側で押さえたいドメインの考え方

Perplexity 系のクライアントやブラウザ版では、少なくとも perplexity.ai 本体に加え、短縮ブランドで使われる pplx.ai サフィックス（サブドメイン含む）をAPIやアセット配信に使う構成が一般的に知られています。さらにサードパーティ計測や埋め込み、外部検索連携のホストが増えると、購読ルールの「汎用海外サイト」カテゴリに吸われて意図しない出口へ落ちることがあります。

実務では、まずブラウザのネットワークタブで「失敗している／Pending が長い」行のホスト名をメモし、それを DOMAIN-SUFFIX で束ねます。ワイルドカードを広げすぎると、同じサフィックスを共有する無関係サービスまで巻き込む恐れがあるため、ログで実名を確認してから足す運用が安全です。モバイルアプリ版を使う場合は、OS の DNS キャッシュや Private DNS の影響も加わるため、DNS まわりの高速化記事 とセットで読むと切り分けが速くなります。

NotebookLM と Google エコシステム：認証ドメインをどう扱うか

NotebookLM は notebooklm.google.com が表向きの入り口ですが、ログインやトークン更新では accounts.google.com、アセットや共通ライブラリでは gstatic.com や googleusercontent.com 系、バックエンド API では googleapis.com のようなホストが絡みがちです。ここでよくある設計ミスが、「NotebookLM だけ専用出口にしたい」あまり、Google ログイン全体を狭いノードに固定してしまうことです。結果として Gmail や他の Google サービスまで同じ経路に縛られ、逆に遅くなったり、職場ポリシーと衝突したりします。

現実的な落としどころは次のような段階です。（1）社内イントラや決済など、直結必須の Google 系は既存の例外ルールを尊重する。（2）NotebookLM 固有に見えるホストや、明らかにそのセッションで増えたホストだけを AI_SEARCH_PROXY に寄せる。（3）どうしても切り分けが難しいときは、一時的にブラウザのシークレットウィンドウでホスト一覧を取り、ルールを短いリストに落とし込む。Google 全体を DOMAIN-SUFFIX,google.com で一括迂回は強力ですが、副作用も大きいので最後の手段として扱うのが無難です。

分流の骨格：AI 検索専用の proxy-groups を切る

おすすめは、一般ブラウジング用の PROXY とは別に、低遅延・高安定を狙う AI_SEARCH_PROXY（名前は任意）を用意するパターンです。url-test や fallback で自動選択するグループを紐づけるか、手動セレクトにするかは購読の品質次第ですが、「研究用のセッションだけこのグループへ」と心の中で決められることが運用のしやすさに直結します。

ルールの評価順も同じく重要です。巨大なサードパーティ RULE-SET を先頭に置くと、細かい例外が永遠に評価されません。現実的な並べ方は、（1）LAN／ローカル直結、（2）AI 検索で明示したドメインサフィックス、（3）職場・決済などの固定例外、（4）カテゴリ RULE-SET、（5）GEOIP や MATCH、の順が読みやすいです。RULE-SET の読み込み形式や更新頻度は先述の Rule Provider 記事を参照してください。

設定イメージ：ドメイン束ねを一般ルールより上に置く

下記は理解を助けるスケルトンです。ノード名やコアのバージョンは自分の環境に合わせて置き換え、未対応の行は削除してください。

proxy-groups:
  - name: AI_SEARCH_PROXY
    type: select
    proxies:
      - 低遅延ノード
      - PROXY

rules:
  - IP-CIDR,127.0.0.0/8,DIRECT
  - IP-CIDR,10.0.0.0/8,DIRECT

  # Perplexity stack (verify hostnames in your client)
  - DOMAIN-SUFFIX,perplexity.ai,AI_SEARCH_PROXY
  - DOMAIN-SUFFIX,pplx.ai,AI_SEARCH_PROXY

  # NotebookLM + related Google hosts (narrow carefully)
  - DOMAIN-SUFFIX,notebooklm.google.com,AI_SEARCH_PROXY
  - DOMAIN-SUFFIX,googleapis.com,AI_SEARCH_PROXY

  # Your subscription rulesets below ...
  - MATCH,PROXY

この例では googleapis.com を広めに載せているため、他の Google ワークロードまで同じ出口に寄る可能性があります。実際にはログで本当に必要なホストだけに絞るか、Google 全体の扱いを別記事レベルで設計し直すか、いずれかが必要になるでしょう。逆に、NotebookLM だけを直結に固定し、API だけ別出口にしたい場合は、より細かい DOMAIN 行に分解します。

DNS（fake-ip）とログの読み方

DNS モードが fake-ip のとき、ドメインルールと IP ルールの見え方が変わります。AI 検索ツールは短時間に多数の名前解決を発行するため、キャッシュ TTL や DoH の往復がボトルネックになることもあります。症状が「プロキシは通っているのに最初の一手が遅い」であれば、DNS を疑う価値があります。詳細は 高速化の記事 に譲りますが、分流ルールを増やす前に 名前解決が意図どおりかを確認すると手戻りが減ります。

また、ブラウザ拡張や別プロファイルが独自プロキシを指定していると、Clash 側のルールがすり抜けます。TUN モードで全体を捕捉している場合でも、競合 VPN やスプリットトンネル設定で例外が紛れ込むことがあるため、Windows では TUN のトラブルシュート記事、GUI 全体像は Clash Verge Rev ガイド が参考になります。

まだ遅いときの短いチェックリスト

  • 遅い／失敗したホスト名をログで特定し、想定の AI_SEARCH_PROXY にマッチしているか
  • 巨大 RULE-SET や MATCH に先に吸われていないか
  • Google ログイン系を狭く縛りすぎて、他タブまで同じ出口になっていないか
  • IPv6 だけ別経路になっていないか
  • セキュリティ製品の HTTPS 検査で証明書エラーが紛れ込んでいないか
  • ブラウザ拡張や別プロファイルがシステムプロキシを迂回していないか
覚えておきたいこと：研究型 AI 検索の遅延は、単一ノードの「速さ」以前に、ドメイン分散 × ルール順 × DNS × Google 認証の副作用として現れることが多いです。いきなり広い DOMAIN-SUFFIX を増やすより、ログで実名を集めてリストを薄く保つ方が長期運用では安全です。

まとめ

Perplexity や NotebookLM のような AI 検索・リサーチツールは、IDE 型ツールと違ってウェブとクラウド ID、CDN、APIの境目にストレスが出やすいカテゴリです。Mihomo（Clash Meta）世代では、専用の AI_SEARCH_PROXY を切り、実測したドメインを一般 RULE-SET より上に置く、という構造が再現性高く効きます。Cursor／GitHub 向けの分流とドメインが被る部分はありますが、設計の主役をどこに置くかが違うので、リストは分けておくとメンテナンスが楽です。

用語や設定キーの一次情報は 公式ドキュメント も参照し、クライアントとコアの組み合わせを取り違えないようにしてください。ほかの記事は 技術ブログ一覧 から辿れます。安定したルールエンジンと GUI が揃うと、調べ物のセッションも途切れにくくなります。→ Clash を無料ダウンロードし、AI 検索向けの分流を試す

コアのソースや議論は各プロジェクトの GitHub で追えますが、日々のクライアント入手は検証済みパッケージへ誘導されている公式ダウンロード導線の方が、構成ファイルとバイナリの組み合わせを取り違えにくいです。