見出し画像

NotebookLM×Claude｜150冊を蒸留した記録

paluck│生成AIゆるく検証

NotebookLMで質問しすぎて破綻した話

NotebookLMに大量の資料を入れていると、いつか必ず別の問題にぶつかります。

「資料は読める。でも質問履歴が増えすぎて整理できない。」

私の場合は150冊以上の発掘調査報告書を投入し、260問の質問を投げた結果、ログが1.4万行を超えました。NotebookLMだけでは扱いきれず、Claudeとの受け渡しやデータ整理の方法まで考える必要が出てきました。

この記事では、試行錯誤の末にたどり着いた「NotebookLM×Claudeのパイプライン」を、失敗も含めて記録します。


まとめ

  • NotebookLMの制限（ソース数・容量）は結合と圧縮で回避できる

  • プロンプトはClaudeで設計し、質問自体はNotebookLMに投げる

  • 大量ログはテーマ軸で分割するとClaudeに渡しやすくなる

  • 出力を整形して「蒸留テキスト」にすると次のソースとして再利用できる

  • この流れは後から調べたらETLパイプラインと同じ構造だった

注意点・免責

この記事で紹介するワークフローは2026年6月時点の個人の試行です。NotebookLMの仕様は変更される場合があります。Proプランへの移行で不要になる工程も含んでいます（後述）。

大量PDF整理｜150冊の発掘報告書を投入した

特定地域の古代史を調べようとして、気づいたら150冊以上の発掘調査報告書をAIに読ませていた。

NotebookLMの無料版はソース数50件・1ソースあたり200MB・50万字という制限がある。150冊をそのまま放り込めるわけがない。

結論だけ言うと、Proプランにすればソース数300件まで拡張できるので、この問題の大半は解決する。今回は無料版でどこまでできるかを試したかった、それだけの話だ。

NotebookLM制限回避｜PDF結合と圧縮を試した

ソース数を削るために、複数の報告書PDFを1ファイルに結合することにした。ただ結合するだけだと200MBを超えるものが出てくるので、自作の圧縮スクリプトも用意した。

結合時に何万字になるかを確認する文字カウント機能も組み込んだ。NotebookLMの50万字制限に引っかからないよう、結合前に確認するためだ。

ここで使ったツール類の開発経緯はこの記事に書いた。

なお、Proプランでも制限に合わせてソースをギチギチに詰め込む方針は変わらない。同じノートブックに入れたほうが情報密度が上がるからだ。

入力側の報告書PDFには手を加えない。クレンジングは出力ログに対してやる工程だ。生の報告書をソースに保つことで、NotebookLMが原典を直接参照できる状態を維持している。

NotebookLMプロンプト設計｜Claudeを設計担当にした

NotebookLMに何を聞くかはClaudeと一緒に考えた。「推測・補完は禁止」「記載がない場合は記載なしと明示する」という制約を入れたプロンプトを設計し、それをNotebookLMに投げ続けた。回答には可能な限りソースのページ番号・図表番号を付記させることで、原典に辿れるようにしている。

何日かに分けて260問。全部合わせると1.4万行のテキストになっていた。

ここでのポイントは役割分担だ。NotebookLMは一次資料を持っている。Claudeはプロンプトの設計と後段の整形・分析を担う。質問自体はNotebookLMにやらせる、という分業が機能した。

ログ分割失敗｜遺跡軸では整理できなかった

1.4万行の生ログをClaudeに渡そうとしたが、そのままではコンテキストウィンドウに載らない。分割が必要だった。

最初は調査対象ごとにファイルを分ける方針で試した。これが見事に失敗した。260問の多くが複数の対象をまたいで言及していたため、ほぼすべてのブロックが複数ファイルに重複することになった。

分けた意味がなくなった。

ここで別の問題に気づいた。軸の選び方を間違えると、分割ではなく増殖になる。

テーマ軸分割｜Claudeで整理し直した

軸をテーマに切り替えた。通史・基本情報・年代観・調査史・横断分析という5テーマに分類する方針にして、Claudeでスクリプトを組んで実行した。

重複がゼロになった。全ブロックが5ファイルに綺麗に収まった。

あわせてクレンジングスクリプトも作り、日付・質問文・テンプレート文言を除去した。1.4万行が8700行になった。約40%削減だ。

分け方の軸を間違えると重複が爆発する、というのはやってみるまで気づけなかった。

ETLパイプラインとの共通点に気づいた

8700行のクリーンなテキストをClaudeに渡してHTMLレポートを生成した段階で、ふと思った。「ビッグデータの操作みたいだな」と。

調べてみると、今回やったことはETL（Extract・Transform・Load）という概念とほぼ同じ構造だった。

  • Extract：NotebookLMから260問で情報を引き出す

  • Transform：スクリプトでクレンジング・テーマ別に整形する

  • Load：クリーンなテキストをClaudeに渡してレポート化する

名前を知らずに正解を引いていた、ということになる。

260問の意味｜RAGの弱点補完に近かった

260問を投げ続けたのは、正直なところ「なるべく多くの情報を引き出したい」という単純な動機だった。

後から調べると、これはRAG（検索拡張生成）の弱点を補う構造と似ているらしい。同じテーマを角度を変えて繰り返し問うことで、一度の検索では漏れるチャンクを結果的に網羅できる、という話だ。

意図してやったわけではない。ただ、意図せず正しいことをしていたのは確かだ。この話は別の記事で詳しく書く予定なので、ここでは触りだけにとどめる。

蒸留テキスト再投入｜次のNotebookLMを作る

今回作った8700行のクリーンテキストは、次のステップでNotebookLMのソースとして再投入する予定だ。

今回は県内のある地方のみを対象としたが、地方を増やしていけば全域を網羅できる狙いだ。

生のPDF報告書をソースにしていたときは、150冊で制限をほぼ使い切っていた。蒸留テキストに置き換えれば、同じソース枠に広域のデータが入る可能性がある。

PDFでは物理的に不可能だったことが、蒸留されたテキストなら可能になる。制限との格闘が、制限を逆手に取る発想につながった。これがこの取り組みの、今のところの着地点だ。

結び

150冊以上の報告書をNotebookLMに詰め込んで、260問投げて、スクリプトで整形して、Claudeでレポートにする。書いてしまえば一行だが、そこには失敗と作り直しがいくつもあった。

ClaudeとNotebookLMを行き来するパイプラインは、最初から設計したものじゃない。詰まるたびに次の手を考えた結果として出来上がった。

後から名前がついたことがいくつかある。ETLもRAGの話もそうだ。名前を知らなくても、問題に向き合えば似たような構造に辿り着くことがある。それは少し面白いと思っている。

また、今回の知見を活かして、情報を抜き出すプロンプトやワークフローをブラッシュアップした。今後はさらなる成果が見込めるはずだ。

大量のデータをAIで扱う人の参考に、少しでもなれば。

FAQ

Q. NotebookLMのログが増えすぎた場合、削除以外の整理方法はありますか？
テーマ別に再構成して別ソース化する方法があります。記事の蒸留工程はその一例です。

Q. Claude以外のAIでも同じパイプラインは作れますか？
役割が代替できれば可能です。重要なのは製品名よりも設計思想です。

Q. 大量PDF整理で最初に詰まるポイントは何ですか？
容量よりも「後から何を取り出したいか」を決めないまま投入することです。

Q. NotebookLMに全部入れれば整理は不要ですか？
情報取得はできますが、再利用しやすい形への整形は別問題です。

出典

付録：同じ領域での取り組み

奈良文化財研究所×早稲田大学（2025年）
発掘調査報告書からLLMを使って遺物・遺構・時代などの考古学情報を自動抽出する研究。遺物名・数量・時代区分という細粒度の構造化データを機械可読な形で取り出すことを目指している。今回の取り組みとは対象とするデータの粒度が異なる。

ルンド大学×フランス国立美術史研究所「AIRプロジェクト」（2021年〜）
考古学の発掘データを管理・公開するシステムの開発プロジェクト。2024年からLLMを使ったデータ解釈テストを開始している。対象はJSON-LD形式に整備された構造化データで、生のPDF報告書を直接処理するものとは出発点が異なる。

なお今回は調査軸が異なるため詳しく取り上げなかったが、LLM×考古学の応用事例は他にも存在する。2025年11月には古代テキスト・遺物・フィールドデータ・知識グラフへのLLM/LMM応用を体系的に整理した包括的レビュー論文も発表されている。


「名前から入る学びもあるけど、問題から入ると同じ場所に着くこともあるんだなって、ちょっと気になってました。」
「それ、この記事そのものの話でもあるよね。」

いいなと思ったら応援しよう！