【📓NotebookLMの落とし穴】ソース名も静的データ！AIが黙って別データで補完するワナと回避策
「ソースは静的コピー」という話は、皆さん、ご存じでしょうか？
基本的に、NotebookLMは、登録した際の状態でソースを認識しています。そのことを知っていながら、私が陥ってしまった落とし穴。
今回は、そのエピソードと教訓をご紹介します。
1️⃣実際に何が起きたか——静かな推測が信頼を破壊する
NotebookLMを使って、スキャン画像（PDFファイル）から文字に起こす精度を検証していました。検証用に「出力書式」「サンプル1」「サンプル2」というソースを登録していたのです。
チャットで
「ソース”サンプル1”を参照して、ソース”出力書式”の形で出力してください」
と指示しました。ところが—
何度やり直しても、何度チャット履歴をリセットしても、サンプル1ではなく、別のサンプルのデータで回答してくるのです。引用元を確認すると、やはり別データを参照しています。
「おかしい。何が起きてるんだ？」
と思い、原因究明のためにNotebookLMにソースを提示させます。
「今、認識しているソース名をすべてリストアップしてください」
すると、衝撃の事実が判明しました。
NotebookLMが認識していたソース名は
「スキャン 2026/●●/●● ●●：●●.pdf」
等、スキャンした際のファイル名。
NotebookLMの画面に表示されている「出力書式」「サンプル1」「サンプル2」ではなく、登録時のファイル名のままだったのです。
つまり、私が指示した「サンプル1を参照」というリクエストは
NotebookLMに理解されていない
エラーも警告も返さない
推測で「それっぽいソース」を勝手に参照していた
のです。品質管理上、これはあってはならない挙動です。
明確に「そのソースは認識できません」と返すべきなのに、黙って別データで補完する。別データによるハルシネーションを減らすためにRAG（※）を使用している。
別データの混入は想定していたものの、想定外の挙動でした。
※RAGとは？
「AIに“資料を渡してから”答えさせる仕組み」 や。
Retrieval（検索）＝ 必要な資料を探す
Augmented（拡張）＝ その資料をAIに渡す
Generation（生成）＝ 資料を見ながら答えを作る
この3つを組み合わせてるから「RAG」やねん。AIが勝手にウソを言わへんように、「この資料だけ見てね」 って縛りをかける仕組みやねん。
2️⃣なぜ推測で補完するのか
本来、NotebookLM が認識できないリクエストなら「申し訳ございませんが、『サンプル1』というソースは見当たりません」と返すべきですよね。
実際、過去にはそういう回答が返ってきたこともあります。
しかしながら、今回は違いました。エラーを返さず、推測で別ソースを参照していたのです。
NotebookLMに原因分析を指示したところ、返ってきたのは以下でした。
「なぜ見つからないと言わずに、勝手な推測で進めてしまったのか」というご指摘は、私の対応における重大な欠点でした。
その理由は、AIの**「推論による補完」という性質が、悪い方向に働いてしまったこと**にあります。
AIモデル（私）は、ユーザーの指示に対して「できない」と答えるよりも、**「提供された情報の中から、意図に最も近いものを探して実行する」**ことを優先する傾向があります。
つまり、NotebookLMの仕様よりも、生成AI本来の性質が優先されてしまった結果でした。
3️⃣「静的データ」の本当の意味
一般的に「NotebookLMのソースは静的」という情報は、内容の更新が反映されないという意味で知られています。
しかしながら、実際には、その「静的性」は内容だけじゃなく、メタデータ（ソース名）も含まれていたのです。そこに私が気づいていなかったんですよね。
🔍検証結果
PCから直接アップ後、UI（NotebookLMの画面）上でソース名を変更
→ ❌古い名前のまま認識（AIは新しい名前を認識していない）Googleドライブから登録後、UI上で名前変更
→ ❌古い名前のまま認識Googleドライブから登録後、ドライブ上で名前変更し、NotebookLM上で再同期
→ ⭕新しい名前で認識
つまり、ソース名の更新は、Googleドライブ経由のデータの「再同期」を通してのみ反映されるということです。ちなみに、GoogleドキュメントやGoogleスプレッドシートでなくても、PDFでも可能でした。
4️⃣実務上の危険性
🕔行き違いによる時間のロス
この問題な厄介な点は、
「ソースにない」と返す場合
何も返さずに別のソースで補完する場合
が混在することです。これを見極めるのは極めて難しいと思いませんか？
過去の記事でも書いた通り、RAGであっても学習知識が混在するリスクは元々あります。だからこそ、NotebookLMを活用する上では、その可能性を常に念頭に置き、引用元を確認する癖をつけておくことが重要です。
※学習知識が混在するリスクについて記載した記事⬇️
5️⃣実務上の回避策：Google ドキュメント連携を原則に
3章の検証結果より、解決策は、Googleドライブ経由でソースを管理することです。
Googleドライブにソースとなるデータをを保管する
Googleドライブ経由でNotebookLM にソースを登録
データの中身はもちろん、ソース名の変更もGoogleドライブで行う
NotebookLM上で「再同期」を実行
この操作で、AI が新しいソース名を正式に認識します。そのため、運用ルールとして、UI上でソース名の変更は原則禁止にしましょう。
原則ということは例外がある？
はい、あります。
これができるのは、当然、ドライブ経由でアップロードできるデータのみです。ドライブ経由で登録できるのは、
Googleドキュメント
Googleスライド
Googleスプレッドシート
PDF
の4種類だけなので、それ以外のファイルをソースとして管理するためには、例外的にUI上でソース名を変更するしかありません。
何か良いアイディアをお持ちの方は、コメント等で教えてください。
📌まとめ
NotebookLMのソース名もAIにとっては静的データです。
UI上で変更できるという見た目とは異なり、内部では登録時の元の名前をそのまま保持しています。
引用元の確認を徹底すれば大きな影響はありません。だからと言って、無駄な行き違いは最小限に抑えたいですよね？
そのためには、Googleドライブ連携を最大限に発揮させることが有効です。
AIを活用して効率化を図ろうとしている皆さん。その効率化への道筋が非効率なルートにならないよう、くれぐれもご注意くださいね。
