【📓NotebookLMの落とし穴】ソース名も静的データ！AIが黙って別データで補完するワナと回避策

「ソースは静的コピー」という話は、皆さん、ご存じでしょうか？
基本的に、NotebookLMは、登録した際の状態でソースを認識しています。そのことを知っていながら、私が陥ってしまった落とし穴。
今回は、そのエピソードと教訓をご紹介します。

1️⃣実際に何が起きたか——静かな推測が信頼を破壊する

NotebookLMを使って、スキャン画像（PDFファイル）から文字に起こす精度を検証していました。検証用に「出力書式」「サンプル1」「サンプル2」というソースを登録していたのです。
チャットで

と指示しました。ところが—
何度やり直しても、何度チャット履歴をリセットしても、サンプル1ではなく、別のサンプルのデータで回答してくるのです。引用元を確認すると、やはり別データを参照しています。

と思い、原因究明のためにNotebookLMにソースを提示させます。

すると、衝撃の事実が判明しました。
NotebookLMが認識していたソース名は
「スキャン 2026/●●/●● ●●：●●.pdf」
等、スキャンした際のファイル名。
NotebookLMの画面に表示されている「出力書式」「サンプル1」「サンプル2」ではなく、登録時のファイル名のままだったのです。

つまり、私が指示した「サンプル1を参照」というリクエストは

• NotebookLMに理解されていない

• エラーも警告も返さない

• 推測で「それっぽいソース」を勝手に参照していた

のです。品質管理上、これはあってはならない挙動です。
明確に「そのソースは認識できません」と返すべきなのに、黙って別データで補完する。別データによるハルシネーションを減らすためにRAG（※）を使用している。
別データの混入は想定していたものの、想定外の挙動でした。

※RAGとは？

2️⃣なぜ推測で補完するのか

本来、NotebookLM が認識できないリクエストなら「申し訳ございませんが、『サンプル1』というソースは見当たりません」と返すべきですよね。
実際、過去にはそういう回答が返ってきたこともあります。
しかしながら、今回は違いました。エラーを返さず、推測で別ソースを参照していたのです。
NotebookLMに原因分析を指示したところ、返ってきたのは以下でした。

つまり、NotebookLMの仕様よりも、生成AI本来の性質が優先されてしまった結果でした。

3️⃣「静的データ」の本当の意味

一般的に「NotebookLMのソースは静的」という情報は、内容の更新が反映されないという意味で知られています。
しかしながら、実際には、その「静的性」は内容だけじゃなく、メタデータ（ソース名）も含まれていたのです。そこに私が気づいていなかったんですよね。

🔍検証結果

• PCから直接アップ後、UI（NotebookLMの画面）上でソース名を変更
  → ❌古い名前のまま認識（AIは新しい名前を認識していない）

• Googleドライブから登録後、UI上で名前変更
  → ❌古い名前のまま認識

• Googleドライブから登録後、ドライブ上で名前変更し、NotebookLM上で再同期
  → ⭕新しい名前で認識

つまり、ソース名の更新は、Googleドライブ経由のデータの「再同期」を通してのみ反映されるということです。ちなみに、GoogleドキュメントやGoogleスプレッドシートでなくても、PDFでも可能でした。

4️⃣実務上の危険性

🕔行き違いによる時間のロス

この問題な厄介な点は、

• 「ソースにない」と返す場合

• 何も返さずに別のソースで補完する場合

が混在することです。これを見極めるのは極めて難しいと思いませんか？
過去の記事でも書いた通り、RAGであっても学習知識が混在するリスクは元々あります。だからこそ、NotebookLMを活用する上では、その可能性を常に念頭に置き、引用元を確認する癖をつけておくことが重要です。

※学習知識が混在するリスクについて記載した記事⬇️

5️⃣実務上の回避策：Google ドキュメント連携を原則に

3章の検証結果より、解決策は、Googleドライブ経由でソースを管理することです。

1. Googleドライブにソースとなるデータをを保管する

2. Googleドライブ経由でNotebookLM にソースを登録

3. データの中身はもちろん、ソース名の変更もGoogleドライブで行う

4. NotebookLM上で「再同期」を実行

この操作で、AI が新しいソース名を正式に認識します。そのため、運用ルールとして、UI上でソース名の変更は原則禁止にしましょう。

原則ということは例外がある？
はい、あります。
これができるのは、当然、ドライブ経由でアップロードできるデータのみです。ドライブ経由で登録できるのは、

• Googleドキュメント

• Googleスライド

• Googleスプレッドシート

• PDF

の4種類だけなので、それ以外のファイルをソースとして管理するためには、例外的にUI上でソース名を変更するしかありません。
何か良いアイディアをお持ちの方は、コメント等で教えてください。

📌まとめ

NotebookLMのソース名もAIにとっては静的データです。
UI上で変更できるという見た目とは異なり、内部では登録時の元の名前をそのまま保持しています。
引用元の確認を徹底すれば大きな影響はありません。だからと言って、無駄な行き違いは最小限に抑えたいですよね？
そのためには、Googleドライブ連携を最大限に発揮させることが有効です。
AIを活用して効率化を図ろうとしている皆さん。その効率化への道筋が非効率なルートにならないよう、くれぐれもご注意くださいね。