NotebookLMに自炊PDFが読み込めない2大原因と対処法｜OCR非対応と容量制限

はじめに

自炊した本のPDFをNotebookLMに入れたのに、中身をまったく読んでくれない、という経験はありませんか。

アップロードは成功したように見えるのに、質問すると「ソースに情報がありません」としか返ってこない。
あるいは、そもそも取り込みの段階で失敗してしまう。
私も自炊PDFやKindle本のPDFをAIに読ませる運用を続けてきて、このあたりの挙動はひととおり踏みました。

結論から書くと、原因はほぼ次の2つに集約されます。

NotebookLMは画像PDFをOCRしてくれない
容量・語数の制限に引っかかっている

この記事では、それぞれの仕組みと見分け方、そして2つを一度に解決する対処法をご紹介します。
なお、NotebookLMは仕様の更新が速いので、この記事に出てくる数値や制限は2026年6月時点の情報として読んでください。

そもそもNotebookLMはどう動いているか

原因の話に入る前に、NotebookLMの仕組みを少しだけ整理させてください。
ここが分かっていると、2つの原因がどちらも「なるほど」に変わります。

NotebookLMは、アップロードした資料（ソース）をテキストとして取り込みます。
そして質問が来ると、資料の中から関係のありそうな箇所を検索して、その部分だけを読んで出典付きで答えます。
いわゆるRAG（検索拡張生成）という方式で、資料をかたまりに分割し、検索できる形に変換しておいて、質問のたびに該当箇所を引いて読む、という流れが裏側で動いています。

ポイントは「テキストとして取り込む」というところです。
NotebookLMの世界は最初から最後までテキストでできていて、ページの見た目や画像は基本的に扱いません。
ここから、2つの原因が生まれます。

原因1：画像PDFはOCRされない

1つ目にして最大の原因がこれです。

自炊やスクリーンショットで作ったPDFは、中身がページの画像になっています。
人間の目には文字が見えていますが、テキストデータは1文字も入っていません。
文字の形をした「絵」が並んでいるだけです。
そしてNotebookLMはテキストを読むAIなので、画像だけのPDFは白紙同然に見えています。

「アップロードはできたのに読んでくれない」のはこのためです。
取り込み自体はエラーにならないことがあるので、かえって原因が分かりにくいのですが、抽出できるテキストがゼロなので、何を質問しても「ソースに情報がありません」になります。

見分け方

見分け方は簡単です。

そのPDFをPCで開いて、本文をマウスでなぞってみてください。
文字が選択できなければ（青くハイライトされなければ）画像PDFなので、NotebookLMには読めません。
文字が選択できるなら、テキストデータは入っているということなので、原因は次の原因2のほうです。

対処の方向性としては、NotebookLMに入れる前に、こちらでテキスト化（OCR）を済ませておくことになります。
「NotebookLM側がOCRしてくれる」という情報を見かけることもありますが、私が調べた範囲では記述に矛盾のある情報源が多かったので、アテにしない運用のほうが安全かと思います。

原因2：容量・語数の制限に引っかかっている

2つ目はサイズの問題です。
NotebookLMには明確な上限があります。

以下は2026年6月時点の内容です。

項目	上限
1ソースあたりの語数	50万語
1ソースあたりのファイルサイズ	200MB
1ノートブックあたりのソース数	無料プランは50、有料プランは100〜600（プランによる）

このほかに、無料プランはチャットの回数にも1日あたりの上限があります。
また、コピープロテクト（DRM）が付いたPDFは、入り口の時点で取り込みを拒否されます。

自炊系のPDFで効いてくるのは200MBのほうです。
スキャンした本や、高解像度でキャプチャしたPDFは、本1冊で数百MBになることが珍しくありません。
この場合は取り込み自体が失敗します。

「検索可能PDFにすればいい」は遠回りです

ここで多くの方が考えるのが、「Adobe AcrobatなどでOCRをかけて、検索可能PDFにすればいいのでは」という対処かと思います。
理屈としては正しいのですが、実はこれ、けっこうな遠回りになります。

検索可能PDFは、元のページ画像を丸ごと抱えたまま、その裏に透明なテキストを重ねた形式です。
テキストは足されますが、重さの原因である画像はそのまま残ります。
つまり原因1は解決しても、原因2の200MBに当たる本ではやはり詰みます。
数百MBの自炊本の場合、この経路は通れません。

そもそもNotebookLMが必要としているのはテキストだけで、ページの見た目は使いません。
だったら画像のほうを捨ててテキストだけ渡せばいい、というのが次の対処法です。

対処法：PDFではなくテキスト/Markdownを渡す

2つの原因を同時に解決する方法が、PDFという容れ物を捨てて、テキストまたはMarkdownで渡すことです。

同じ本でも、画像PDFが数百MBのところ、Markdownにすれば1MB前後になります。
OCR済みのテキストなので原因1はクリアで、サイズも2桁以上小さくなるので原因2もクリアです。
DRM由来の拒否も起きません。
解釈・要約・出典の特定はすべてNotebookLM側の仕事なので、渡す側はきれいなテキストを用意することだけに集中すればいい、という整理になります。

私はこの変換に、自作の無料アプリ「kindle_shot」を使っています。
Kindleなどの電子書籍のキャプチャ取得から、自炊PDFの読み込み、OCR（国立国会図書館製のNDLOCR-Lite・日本語縦書き対応）、Markdown出力までを1つのアプリでやるツールです。

手順の流れだけ書いておくと、次の3ステップです。

自炊PDFを「PDF読込」タブで画像に展開する（DPI200・PNG）
トリミングでページ番号や柱を削る
変換タブでMarkdownを出力する

所要時間はOCRが支配的で、私の環境では300ページの本でCPUのみ30分〜1時間くらいでした。

Markdownで出すときの2つのポイント

ただテキスト化するだけでも読めるようにはなりますが、次の2つを効かせると、NotebookLMでの使い勝手が一段変わります。

1つ目は、段落整形をかけることです。

OCRの生テキストは画面の見た目どおりに改行が入るので、1行ごとにブツブツ切れています。
検索して読むタイプのAIには、これがなかなか扱いにくいです。
kindle_shotの「段落を自動整形」は、句読点で終わらない行を機械的に結合して、読める段落に再構成します。
ルールベースの処理なのでLLMを使わずオフラインで動き、内容が書き換わる心配がありません。

2つ目は、章見出しを付けることです。

NotebookLMは必要な箇所を検索して読むタイプなので、# による見出し構造があると「いま読んでいるのが第何章か」という文脈が保たれます。
その結果、回答の精度と出典の正確さが上がります。
kindle_shotの章自動検出を有効にすると、「第◯章」「Chapter N」といった定型語をMarkdownの見出しに変換してくれます。

逆に、ページ画像をMarkdownに併記するオプションは、NotebookLM用途ではオフにしてください。
テキスト中心のNotebookLMでは、サイズを食うだけになります。

注意：ゴミもそのまま読まれます

最後にひとつ、大事な注意点です。

NotebookLMは、渡されたテキストをそのまま正しいものとして扱います。
OCRの誤認識が残っていれば、その誤りを含んだまま回答してきます。
いわゆる「garbage in, garbage out」です。

なので、精度の要る用途では、テキスト側の品質にこそ手をかける価値があります。
具体的には次の3つかと思います。

トリミングを丁寧にやる：ページ番号や柱（ページ上部に入っている章名）が画像に残っていると、本文のあちこちに断片として混入します
OCR前処理を有効にする：文字を拡大してコントラストを強調してから認識させると、誤認識が体感で明らかに減ります
置換辞書で癖を潰す：「この本は『ー』が『゠』に化ける」のような規則的な誤りは、辞書に1行足せば全体に自動適用されます

ちなみに：他のAIでも事情は似ています

「NotebookLMが駄目ならClaudeやChatGPTに画像PDFを投げればいいのでは」と思われるかもしれません。
たしかに画像PDFを直接読めるAIもあります。

ただ、画像のまま渡すと、テキストに比べてトークンコストが3〜5倍かかります。
ファイルサイズや枚数の制限も各サービスにあります。
本1冊レベルの分量になると、画像のままの運用はどのAIでもコスト高になります。

つまり「本をテキスト/Markdown化しておく」のは、NotebookLM専用の対処ではありません。
どのAIに渡すときにも効く、共通の土台です。
一度Markdownにしておけば、出典付きで確認したいときはNotebookLM、全体を俯瞰して議論したいときは長いコンテキストを持つClaude、というように同じファイルで使い分けられます。

1冊入れるときのチェックリスト

運用に落とすとき用に、手順をチェックリストにしておきます。

PDFの本文をマウスでなぞって、文字が選択できるか確認する（できなければOCRが必要です）
ファイルサイズが200MB未満かどうか確認する（超えるならテキスト/Markdown化します）
OCR＋段落整形＋章見出し付きでMarkdownに変換する
できたMarkdownの最初の3ページを目視で確認する（段落の繋がり・見出し・ゴミの混入をチェックします）
1冊＝1ソースで登録する（複数の本を1ファイルに結合すると出典が追えなくなります）
テスト質問を1本投げて、出典付きで返ってくるか確認する

最後のテスト質問は、「この本の主張を章ごとに3行で要約して」あたりが確かめやすいかと思います。

よくある疑問

Q. テキストが入っているPDF（買った電子書籍のPDFなど）なら、そのまま入れていいですか。

A. 文字が選択できるPDFで、200MB未満であれば、そのままで読めます。
ただしDRM付きのものは拒否されます。

Q. 50万語というのは、どのくらいの分量ですか。

A. 一般的な単行本1冊であれば、普通は収まります。
辞典級の本や合本で超えてしまう場合は、巻や部の単位で分割して複数ソースにしてください。

Q. 精度が心配です。どのくらい正確に答えてくれますか。

A. 回答には出典（ソースの該当箇所）が付くので、怪しいと思ったらワンクリックで原文を確認できます。
この確認のしやすさが、NotebookLMの一番の強みだと思っています。
ただし前述のとおり、OCRのゴミはそのまま出てくるので、入り口の品質が大事です。

まとめ

いかがでしたか。
今回は、NotebookLMに自炊PDFが読み込めない2大原因と、その対処法をまとめました。

要点をもう一度並べておきます。

原因1は、画像PDFがOCRされないこと。NotebookLMから見ると白紙同然なので、文字が選択できないPDFは読めません
原因2は、1ソースあたり50万語・200MBの上限とDRM拒否。自炊PDFは200MBに当たりがちです
検索可能PDF化は遠回り。画像を抱えたままなので、サイズの問題が残ります
対処法は、OCR済みのテキスト/Markdownで渡すこと。軽くて確実で、段落整形と章見出しを足せば精度がさらに上がります

なお、ここに書いた制限値は2026年6月時点の情報なので、実際に使うときは最新の仕様を確認してみてください。

本をAIに読ませる環境が一度できると、読書と勉強のやり方がかなり変わります。
ぜひ試してみてください。

この記事が誰かの役に立てばうれしいです。