1 背景とゴールをそろえる
NotebookLM は、論文や社内資料などをアップロードして要約や質問に答えてもらう、Google 提供の研究・学習向け AI サービスです。2026 年時点でも利用はブラウザ中心で、表向きの入り口は notebooklm.google.com に集約されています。一方で実際の通信は、Google アカウントの OAuth、静的アセット、バックエンドの *.googleapis.com、場合によっては生成モデルまわりの別サブドメインへと枝分かれします。社内ネットや地域制限のある回線では、「トップは開くがログイン後だけ真っ白」「PDF は上がるが要約だけ永遠にスピナー」のように、ホスト単位で経路が割れた症状が出やすいのが特徴です。
本稿のゴールは、Clash（Mihomo コア）の Rule モードで NotebookLM に関わる Google トラフィックを意図したアウトバウンドへ揃えることです。Gemini や Google AI Studio は別記事で ドメイン束と API 経路を整理していますが、NotebookLM は製品 URL と利用シナリオ（アップロードと長めの生成待ち）が異なるため、本章ではそこに寄せた切り分けを足します。職場端末では社内ポリシーを最優先し、本稿はあくまで技術的な経路設計の参考として読んでください。
2 NotebookLM が触るホストをざっくり把握する
ホスト名はアップデートで増減しますが、切り分けの単位として次の束を頭に置くと楽です。どれか一つが意図せず DIRECT や別ノードに落ちると、画面だけ部分的に壊れたように見えます。
- Web UI：
notebooklm.google.comおよび同じく*.google.com配下のスクリプト・設定画面。リダイレクトでaccounts.google.comやogs.google.comなどが絡むことがあります。 - 認証・セッション：
accounts.google.com、ssl.gstatic.com、www.gstatic.comなど。ここがプロキシと直行で割れると、ログイン直後だけ 400 系や無限リダイレクトが起きがちです。 - API／バックエンド：
*.googleapis.comを中心とした REST／長めの HTTPS。アップロードや生成処理はここに集約されやすく、ログに出たホスト名をそのままDOMAIN-SUFFIXの補強材料にできます。 - ストレージ・アップロード： 大きな PDF では
googleusercontent.comやstorage.googleapis.comなどが絡むケースがあります。帯域の細いノードだとタイムアウトだけが先に出ます。
まずは Clash の接続ログ（または Mihomo のダッシュボード）で、失敗の瞬間にどのドメインが Reject／DIRECT／意図しない Proxy になっているかを確認してください。未知のサブドメインが直行しているなら、ルール順か Rule Provider の内容が原因であることが多いです。
3 汎用「Google 直行／プロキシ」との優先順位
多くのテンプレートには「Google はプロキシ」「国内は GEOIP,CN,DIRECT」のような行が既に入っています。NotebookLM だけ特別扱いしたい場合でも、ルールリストは上から評価されるため、次のような順序を意識すると衝突が減ります。
- クライアント自身・LAN：
127.0.0.0/8や社内イントラなど、誤ってプロキシに送らない行を最上段付近に置く（購読テンプレの定義に従う）。 - 明示したい Google 束： NotebookLM 利用中にログで頻出する
DOMAIN-SUFFIXを、曖昧なDOMAIN-KEYWORDより上に置くと期待どおりの出口に寄せやすいです。 - Rule Provider 経由のブロック： 広告・追跡・マルウェア用リストが
googleapis.comの一部を誤って塞いでいないか確認します。塞いでいる場合は Provider の順序か、例外ルールで上書きします。 - 汎用 Google／国外サイト： 既存の「Google 系まとめてプロキシ」行はそのまま活かし、NotebookLM 向けの細かい行をその手前に重ねるイメージです。逆に、NotebookLM だけ別ノードにしたいときは
PROXY-NOTEBOOKLMのようなセレクタを定義し、対応するDOMAIN-SUFFIXだけをそちらへ送ります。 - フォールバック： 最後の
MATCHが意図と違うと全体が崩れるため、ここが「残り全部プロキシ」か「直結」かをテンプレと方針で固定します。
「Google は全部同じノードでよい」のであれば、PROXY-GOOGLE に google.com・googleapis.com・gstatic.com などをまとめて載せ、NotebookLM 専用ルールを増やさずに済ませるのが最も保守しやすいです。問題は分割トンネルや広告ブロックが API だけ食うときなので、そのときに限ってログ駆動でサフィックスを足していくのが現実的です。
4 ルールモードとプロキシグループの置き方
推奨は mode: rule です。NotebookLM はアップロード後に数十秒単位の生成待ちが続くため、遅延よりも切断に強いノードを選ぶ価値があります。URL テスト付きの fallback や url-test グループを挟み、メインが不安定なときにだけ別アウトバウンドへ逃がすと、ブラウザの「もう一度試す」回数を減らせます。
グローバルプロキシは設定は簡単ですが、国内の決済や社内 SaaS まで遠回りになります。逆に「Google だけプロキシ」のテンプレでも、Rule Provider の誤判定や DNS の食い違いで Google だけ半分直結、という状態になり得ます。TUN モードでアプリ横断の経路を揃えると、ブラウザとバックグラウンドの挙動差が減り、NotebookLM のような複数ホスト型サービスで効きます。
5 YAML と Rule Provider の例（Mihomo／Clash Meta 互換）
以下はイメージです。proxy-groups 名や購読 URL は手元の構成に合わせてください。コメントは英語のみとします。
# Example: explicit NotebookLM-related suffixes + shared Google bundle
rule-providers:
google-lite:
type: http
behavior: classical
url: "https://example.com/rules/google.txt"
path: ./rules/google-lite.yaml
interval: 86400
rules:
- DOMAIN-SUFFIX,notebooklm.google.com,PROXY-GOOGLE
- DOMAIN-SUFFIX,accounts.google.com,PROXY-GOOGLE
- DOMAIN-SUFFIX,googleapis.com,PROXY-GOOGLE
- DOMAIN-SUFFIX,gstatic.com,PROXY-GOOGLE
- DOMAIN-SUFFIX,googleusercontent.com,PROXY-GOOGLE
- DOMAIN-SUFFIX,google.com,PROXY-GOOGLE
- RULE-SET,google-lite,PROXY-GOOGLE
RULE-SET はリモートの Rule Provider を参照する際の書き方の一例です。実際の url は信頼できるリストに差し替えてください。ローカルで短いリストだけ運用するなら rule-providers を削り、DOMAIN-SUFFIX 行だけにしても構いません。いずれにせよ上位の行が先に勝つので、例外を入れたいホストは Provider より上に置きます。
ブラウザ以外のツールから Google API を叩く場合は、HTTPS_PROXY を明示するか TUN で仮想 NIC に揃えます。環境によっては拡張機能の「プロキシ設定を独自に持つ」ケースもあるため、シークレットウィンドウや拡張オフで再現するかを比較してください。
6 症状別：ログイン・PDF アップロード・要約生成
NotebookLM で多い問い合わせは、次の三種に集約されやすいです。いずれも「どのホストがどのルールに当たったか」をログで確認するのが近道です。
ログインやリダイレクトがループする
accounts.google.com と本体 UI のドメインで出口が分かれていると、Cookie の扱いや地域判定が不整合になります。対策は、両方を同じ PROXY-GOOGLE に載せる、広告・追跡系 Rule Provider が認証ドメインをブロックしていないか確認する、ブラウザのサードパーティ Cookie 設定を公式の推奨に寄せる、の順が現場では効きやすいです。企業端末では証明書検査（TLS インスペクション）でログイン画面だけ壊れることもあるため、エラー文が証明書関連ならまず IT ポリシーを確認します。
PDF や大きなファイルのアップロードが失敗する
進行バーが途中で止まる場合は、storage.googleapis.com や googleusercontent.com が別ルールに吸われていないか、ノード側のアップロード帯域やタイムアウトが厳しくないかを疑います。Clash 側では該当サフィックスを明示的に同じアウトバウンドへ揃え、必要ならセレクタで帯域の広いノードに切り替えて比較してください。ダイレクトで上げてプロキシで要約だけ、のような経路の混在は、セッションやリージョンの解釈で変なエラーに繋がることがあります。
要約・生成だけ失敗する・永遠に待つ
UI は生きているが生成だけ終わらないときは、バックエンドの *.googleapis.com が REJECT されていないか、HTTP/2 の長めの接続が途中で切られていないかを見ます。別ノードに切り替えて再現が消えるならルールよりノード品質の問題です。消えないなら Rule Provider のブロック、DNS の誤解決、IPv6 の迂回経路などを疑い、DNS 実務記事の設定とあわせて確認すると早いです。
7 DNS・TUN・TLS をセットで見る
Google 系サービスはドメイン数が多く、FakeIP と実 IP の切り替わり、DoH のフォールバック順がずれると「名前は解けるが実体の経路が別」という状態になります。Mihomo では dns セクションと fallback-filter の組み合わせが定番で、細部は前述の DNS 記事に譲ります。ポイントは、OS の DNS と Clash の DNS を二重に信じないこと、TUN 利用時はローカル名解決の例外を残すこと、です。
企業環境では自社 CA による TLS インスペクションがあり、ブラウザは信頼ストア経由で通るが、他プロセスは失敗する、というパターンもあります。NotebookLM のような Web アプリ単体で完結する場合でも、裏側の fetch が厳密な証明書検証をする実装だと同種の差が出ます。エラーが CERTIFICATE や SSL を含むなら、まず信頼ストアとポリシーを疑ってください。
8 Gemini／AI Studio 記事との使い分け
Gemini API や Google AI Studio は、開発者向けの generativelanguage.googleapis.com や ai.google.dev 周辺が前面に出ます。NotebookLM も最終的には Google のクラウド基盤に乗りますが、ユーザーが意識する URL と典型トラブル（大容量アップロード、長い生成待ち）が異なります。すでに Gemini 向けの分流記事で googleapis.com を束ねているなら、NotebookLM では同じ PROXY-GOOGLE を流用し、ログで足りないサフィックスだけ足すのが最短です。逆に NotebookLM から入った読者は、API や AI Studio を触る段階で同記事へ進むと設計が一貫します。
9 まとめ
NotebookLM を安定させるコアは、派手なチューニングではなくGoogle 関連ドメインを同じ意図のアウトバウンドに揃え、ルールの上から順に評価される構造を把握することです。DOMAIN-SUFFIX で notebooklm.google.com や googleapis.com を明示し、Rule Provider が API を誤ってブロックしていないかを確認し、ログイン・アップロード・生成のどの段階でホストが変わるかをログで追う。この三点がそろうと、2026 年時点でも製品改修があっても追従しやすいです。
Clash 互換クライアントは、セレクタと Rule Provider、DNS を一体で扱えるため、「ブラウザのプロキシだけオン」より再現性の高い検証がしやすいです。まずは手元の YAML にサフィックスを足し、接続ログで漏れを潰し、必要なら Mihomo のダッシュボードでノードを切り替えながらアップロードと要約を試してください。
単機能ツールより、ルールと DNS を同じ画面で管理できるスタックの方が、NotebookLM のようにホストが分散した SaaS に強い場面が多いです。長い生成待ちでは、わずかな切断の差が作業のストレスに直結します。
