NotebookLMはサイトを無断で取得する？Gemini Notebookのクローラーとrobots.txtの実態

サーバーログに「Google-NotebookLM」という見慣れないUA名を見つけたことはありませんか？

2026年7月16日、GoogleはAIリサーチツール「NotebookLM」を「Gemini Notebook」へ改名しました。これに伴い、サイトへアクセスする際のユーザーエージェント（UA）も「Google-NotebookLM」から「Google-GeminiNotebook」へ移行します。

結論から言うと、「NotebookLMに無断でスクレイピングされているのか？」という疑問への答えは「巡回はしないが、特定の条件下では取得される」が正確です。Googlebotのようにサイト全体を自律的に巡回し続けることはありませんが、ユーザーがURLを指定した際には、robots.txtの制御を受けずにページを取得する場合があります。

実際、AI観測ラボのサーバーログでは、改名翌日の7月17日に24件、7月23日にも8件の「Google-NotebookLM」によるアクセスを確認しました。なぜ改名後も旧UAが来ているのか。そもそも一般的なクローラーと何が違うのか。改名から1週間の実測ログとGoogle公式情報をもとに解説します。

この記事でわかること｜📖：約6分

• Gemini Notebook（旧NotebookLM）がサイトへアクセスする仕組みと、一般的なクローラーとの違い
• robots.txtが効かない理由と、Googleが「User-triggered fetcher」に分類している意味
• AI観測ラボで確認した旧UA「Google-NotebookLM」の実測ログ（7月17日・23日）
• UA移行期間にサイト運営者がやっておくべき対処法

NotebookLMはGemini Notebookへ——改名で何が変わった？

Googleは2026年7月16日付で、AIリサーチツール「NotebookLM」を「Gemini Notebook」へ改名しました。サービス終了や別製品への統合ではなく、既存のノートブックや機能はそのまま、独立したリサーチツールとして提供が継続されます。

NotebookLMは2023年の「Project Tailwind」として発表されて以来、Googleによると3,000万人以上のユーザーと60万以上の組織に拡大。今回の改名は、単独の実験的サービスから、GeminiアプリやGoogle検索のAI Modeを含むエコシステム全体の中核ツールへ位置づける狙いとみられます。

機能面では、各ノートブックに安全なクラウド環境が用意され、ソースに基づいたコードの作成・実行が可能になりました。

サイト運営者にとっての最大の変更点は、サービス名だけでなく、サイトへアクセスしてくるUA（ユーザーエージェント）文字列が「Google-NotebookLM」から「Google-GeminiNotebook」へ変わることです。次に、このUAの正体を見ていきます。

「Google-NotebookLM」はクローラーではなくフェッチャー

サーバーログに「Google-NotebookLM」とあれば、Googlebotのような検索クローラーと同じものだと思うかもしれません。しかしGoogleの公式ドキュメントでは、明確に別のカテゴリに分類されています。

Googleはウェブへアクセスする主体を大きく3つに分けています。

• 一般クローラー：検索インデックス構築のために自動でサイトを巡回するもの（例：Googlebot）
• 特殊クローラー：広告審査など特定の用途で動くもの
• User-triggered fetcher：Google製品のユーザーが操作したときに、そのURLだけを取得するもの

「Google-NotebookLM」は3つ目のUser-triggered fetcherです。ユーザーがGemini Notebook（旧NotebookLM）で、自身のノートのソースとして個別のURLを追加したときにのみ、そのページを1件ずつ取得する仕組みです。

つまり、サイト内のリンクを辿って全ページを巡回するGooglebotとは動きが根本的に異なります。あくまでユーザー起点の、1回きりの取得です。

なお本記事では、検索上での分かりやすさを考慮してタイトル等では「クローラー」と表記していますが、Googleの正式な分類は「ユーザー起点のフェッチャー」です。そしてこの分類の違いが、後述するrobots.txtの扱いに直結します。

関連：GoogleOtherとは？Googleが持つ複数UAの役割と見分け方

AI観測ラボのサーバーログで確認したGoogle-NotebookLMのアクセス

では「Google-NotebookLM」は、実際にどの程度サイトへアクセスしてくるのか。AI観測ラボで、NeonDBに蓄積したアクセスログから観測しました。

旧UA「Google-NotebookLM」によるアクセスを確認したのは、以下の2日です。

• 2026年7月17日：24件（改名発表の翌日）
• 2026年7月23日：8件（AM9時時点の集計）

重要なのは、改名から1週間が経過した7月23日時点でも、旧UAによるアクセスが続いていた点です。Googleの公式資料では新UA「Google-GeminiNotebook」への移行と同時に、旧UA「Google-NotebookLM」は2026年8月までサポートされると案内されています。今回のログは、移行期間中は旧UAが並行して使われることを示す実例です。

もう一つ、アクセスには週次の偏りが見られました。観測期間中、毎週月曜日にまとまったアクセスが記録されています。User-triggered fetcherの性質を踏まえると、特定のユーザーやチームが月曜日に資料ソースを更新する運用をしている可能性が考えられますが、あくまでログからの推測であり、サーバーログ単体でユーザー行動を特定することはできません。

同様に、今回のアクセスが「URLの手動追加」によるものか「共有機能」によるものか、あるいは後述するDiscover Sources関連のものかも、UAと時刻だけでは判別できません。ここでは「Google-NotebookLMというUAから、この日時にこれだけのアクセスがあった」という観測事実として記録します。

関連：AIエージェントのユーザーエージェントを見分けるには

robots.txtが効かない理由——User-triggered fetcherの仕組み

「robots.txtでDisallowを指定すれば止められるのでは？」と考えるのは自然です。しかし「Google-NotebookLM」と後継の「Google-GeminiNotebook」は、通常はrobots.txtのルールを無視します。

これはバグや仕様の抜け穴ではありません。Googleは公式ドキュメントで、User-triggered fetcherは「ユーザーの明示的なリクエストを代行して取得する」ものであり、自動巡回するクローラーとは異なるため、原則としてrobots.txtの対象外になると説明しています。

• Googlebot：サイトを自動で発見・巡回する一般クローラー。robots.txtのDisallowを遵守する。
• Google-GeminiNotebook：ユーザーが資料として指定した個別URLだけを取得するフェッチャー。自動巡回ではなく、ユーザーからの依頼として扱われる。

サイト運営者から見れば「拒否したはずなのに来た」となりますが、Google側の設計上は想定通りの挙動です。

主なクローラーと制御用トークンの違いを整理します。

名称	Google上の位置づけ	robots.txtの扱い
Googlebot	一般クローラー	✅ 遵守
Google-Extended	Geminiでの学習利用を制御するトークン ※HTTPのUAではない	✅ 制御可能
Google-NotebookLM	旧・User-triggered fetcher	❌ 原則無視
Google-GeminiNotebook	現行・User-triggered fetcher	❌ 原則無視

そのため、確実に取得を止めたい場合はrobots.txtではなく、ログイン必須のアクセス制御や、サーバー・WAF・CDN側での制限が必要です。UA文字列は偽装可能なので、本当にGoogleからのアクセスか判定したい場合は、公式が公開しているIP範囲や逆引き・正引きDNSの確認もあわせて行ってください。

ただし、取得を一律で遮断することがすべてのサイトにとって最適とは限りません。判断基準は後半で整理します。

関連：Meta-ExternalAgentとは？robots.txtでの制御方法と実測データ

Discover Sources——元記事への流入なしで要約される可能性

Gemini Notebook（旧NotebookLM）には、ユーザーがテーマを入力するとWeb上から関連する情報源を自動で探して推薦する機能があります。2025年発表時は「Discover Sources」、現在はヘルプ上で「Fast Research」として案内されている機能です。

Googleの発表によると、この機能は数百件の候補から関連性の高いソースを最大10件提示し、それぞれにAI生成の要約と元ページへのリンクを付けます。

サイト運営者として気になるのは、ユーザーが要約だけで満足し、元記事を開かない可能性がある点です。その場合、サイトへの流入やリファラルは発生しません。一方で、根拠を確認するために元記事がクリックされる可能性もあり、流入が必ず失われるわけではありません。

ここでサーバーログとの関係を整理しておきます。GoogleのUser-triggered fetcher公式ページには、Discover SourcesやFast Researchの候補収集時に「Google-NotebookLM」や「Google-GeminiNotebook」が使われるという明記はありません。

公式に説明されているのは、あくまで「ユーザーがソースとして指定した個別URLを取得する」という用途までです。Discover Sourcesが候補を探す際に、元サイトへ直接アクセスしているのか、どのUAを使っているのかは、公開情報だけでは判断できません。

したがって、今回AI観測ラボで確認した「Google-NotebookLM」のアクセスを、Discover Sourcesによるものと結びつけることはできません。現時点で言えるのは「このUAからアクセスがあった」という事実までです。

起点	ログから判別可能か	流入の有無
ユーザーによるURL追加	UAだけでは操作内容まで判別不可	通常の閲覧とは異なる
Discover Sources / Fast Research	使用UAが公式に非公開	リンクがクリックされた場合のみ発生

関連：ChatGPTに引用されるサイトの条件とは？実測データで検証

サイト運営者はどう対処すべきか——ブロックより先に考えること

「robots.txtが効かないなら、どうすればいいのか」。結論、多くのサイトではすぐにブロックするより、先に確認すべきことがあります。

1. 旧UAと新UAの両方をログ監視する

Gemini NotebookのUAは旧「Google-NotebookLM」から新「Google-GeminiNotebook」へ移行中です。Google公式では旧UAは2026年8月までサポートと案内されています。

移行期間中は、集計クエリやWAFのルールで両方を対象にしておく必要があります。

• Google-NotebookLM：旧UA（〜2026年8月まで）
• Google-GeminiNotebook：新UA（現行）

確認用のコマンド例：

# アクセスログから両UAのアクセスを抽出
grep -E "Google-NotebookLM|Google-GeminiNotebook" /var/log/nginx/access.log

# NeonDB / BigQuery で集計する場合
WHERE user_agent LIKE '%Google-NotebookLM%' 
   OR user_agent LIKE '%Google-GeminiNotebook%'

なお、両UAをrobots.txtのDisallowに追加しても、前述の通り確実なブロックにはなりません。

2. 公開コンテンツと非公開コンテンツを分けて考える

ブロックの要否は、サイトの目的ではなく「そのURLが公開情報かどうか」で判断します。

コンテンツの状況	推奨される対応
一般公開しているブログ・解説記事	まずは観測を継続。問題がなければ許可
会員限定・有料記事	robots.txtではなく、ログイン認証で保護
社内資料・未公開情報・個人情報	公開URLに置かず、認証ユーザーのみアクセス可能に
公開しているがAIからの取得を望まない	サーバー / WAF / CDN側でUAとIPで制御を検討

特に重要なのは、robots.txtを機密情報の保護に使わないことです。robots.txtはクローラーへの「お願い」を書くファイルであり、アクセスを遮断する認証機能ではありません。

3.確実に止めたい場合はサーバー側で制御する

Gemini Notebookからの取得を止める必要がある場合は、サーバー、WAF、CDNなどでUAや送信元を確認し、アクセスを拒否する方法があります。

とはいえ、UA文字列は第三者でも偽装できます。ログ上でGoogleを名乗っているだけでは、本当にGoogleからのアクセスとは限りません。GoogleはUser-triggered fetcherが使用するIP範囲を公開しているため、正確に判定したい場合は、送信元IPや逆引き・正引きDNSもあわせて確認します。

IP範囲や配信元は将来変更される可能性があるため、一度設定して終わりではなく、Googleの公式情報と実際のログを定期的に確認する必要があります。

4.公開ブログでは、まず観測する選択肢もある

一般公開しているブログや情報サイトの場合、Gemini Notebookから数件アクセスがあったという理由だけで、直ちにブロックする必要性は高くありません。

まずはアクセス数、対象ページ、発生時間、サーバー負荷などを記録し、実害があるかを確認するのが現実的です。その後、コンテンツの利用方針やビジネス上の利益と不利益を比較し、許可を続けるか、サーバー側で制限するかを判断します。

関連：AIに引用されるコンテンツとは？情報の不可替性という視点

まとめ——「来ているか」を把握することが最初の一歩

Gemini Notebook（旧NotebookLM）のフェッチャーについて、公式情報と実測ログから整理しました。

確認ポイント	結論
サイト全体を自律的に巡回するか	❌ しない。ユーザーが指定したURLのみを取得
robots.txtで止められるか	❌ 原則無視される。止めるならサーバー側制御
旧UAはいつまで使われるか	旧「Google-NotebookLM」は2026年8月まで並行稼働
アクセスの起点は判別できるか	UAと時刻だけでは操作内容まで特定不可
元サイトへの流入は？	ユーザーがリンクをクリックした場合に発生

AI観測ラボでは、改名翌日の7月17日に24件、23日にも8件の旧UA「Google-NotebookLM」によるアクセスを確認しました。公式の案内通り、改名後すぐに新UAへ完全移行するわけではなく、当面は旧UAが並行して使われる移行期間です。

そのため、アクセスログの監視やWAF設定を行っているサイトは、当面「Google-NotebookLM」と「Google-GeminiNotebook」の両方を監視対象に入れておく必要があります。

「自分のサイトに来ているか」を把握することが、対処を考える最初の一歩です。まだ確認していない場合は、一度アクセスログで両UAを含むリクエストがないか検索してみてください。

一般公開しているブログであれば、アクセスがあったからといってすぐにブロックする必要はありません。まずはアクセス数、対象ページ、時間帯、サーバー負荷を観測し、自サイトにとっての利益とリスクを整理した上で判断することが重要です。

AI観測ラボでは、引き続き新UA「Google-GeminiNotebook」のアクセスを観測します。実際に新UAを確認できた際は、本記事に追記します。

関連：GoogleOtherとは？Googleが持つ複数UAの役割と見分け方
関連：AIエージェントのユーザーエージェントを見分けるには
関連：ChatGPTに引用されるサイトの条件とは？実測データで検証
関連：Google-NotebookLMのアクセスは何のサイン？ログを解釈する