SkillStack Lab（スキスタ）運営者のスタックです。
NotebookLMへ日本語のPDFやCSVを入れたら、「□□□」や意味不明な記号になった経験はありませんか。
私も実務で何度か経験しています。
例えば、古い基幹システムから出力したCSVを読み込ませたところ日本語だけが文字化けしたり、社内独自の外字を使った古いWord文書をPDF化すると、ソースのプレビュー時点で「□□□」になったりしました。
さらに厄介なのが、見た目は正常なのにNotebookLMが中身を正しく読めていないケースです。
複合機でスキャンしただけの就業規則PDFでは、「情報が見つかりません」と回答されました。また、セル結合が多い減価償却表では、A部署の数字を聞いたのに1行ずれたB部署の数字を返されたこともあります。
つまり、「文字化け」「PDFを読めない」「表の数字を間違える」は、それぞれ原因も直し方も違います。
この記事では、元情シスとして実際に試している切り分け方法と、私が最終的にたどり着いた「直す順番」を紹介します。
なお、Googleは2026年7月16日にNotebookLMを「Gemini Notebook」へ名称変更しました。同じ製品ですが、本記事では検索で広く使われている旧名称のNotebookLMも併記します。
- CSVが文字化けしたときにUTF-8へ直す方法
- スキャンPDFをGoogle Drive OCRで読めるようにする手順
- 外字・特殊フォント入りPDFで起きた実際のトラブル
- 複雑な表をNotebookLMへ無理に読ませない判断基準
- チャット・Audio Overviewを日本語へ設定する方法
- 元情シスが実践する4段階の切り分け手順
NotebookLMの文字化けは症状から原因を切り分ける
最初からOCRやファイル変換を始めるのではなく、まず「何が起きているのか」を確認します。
| 症状 | 私が最初に疑うもの | 主な対処 |
|---|---|---|
| □□□・記号だらけ | 文字コード・外字・特殊フォント | UTF-8化・別形式へ変換 |
| 「情報がありません」 | 画像だけのPDF | OCR |
| 表の数字がずれる | セル結合・複雑なレイアウト | 表を単純化・原本確認 |
| 英語で回答される | 出力言語 | Output Languageを日本語へ |
| アップロードが固まる | ブラウザ拡張機能 | シークレットモードで検証 |
| ファイル自体を追加できない | 保護・権限・形式 | 利用権限と元ファイルを確認 |
特に注意したいのが、「文字化け」と「読み取りミス」は別物という点です。
文字が正常に見えていても、表構造をAIが間違って解釈している場合があります。
CSVの日本語が文字化けしたらUTF-8へ変換する
私が実際に遭遇した中で、最も分かりやすかったのがCSVです。
経費精算システムから出力したCSVをNotebookLMへ読み込ませたところ、日本語部分が文字化けしました。
元ファイルを確認すると、Windows系業務システムでよく使われるShift_JIS系のCP932でした。
そこで、次の手順で保存し直しました。
- CSVをWindowsの「メモ帳」で開く
- 日本語が正常に表示されていることを確認する
- 「名前を付けて保存」を選ぶ
- 文字コードをUTF-8へ変更する
- 保存したCSVをNotebookLMへ再度追加する
私の環境では、UTF-8（BOM付き）へ保存し直すことで日本語を正常に読み込めるようになりました。
これはNotebookLMに限った話ではありません。
Pythonや各種APIで日本語CSVを扱う場合も、CP932とUTF-8の違いは頻繁にトラブルの原因になります。
なお、2026年現在のGemini NotebookはCSVファイルを正式なソース形式としてサポートしています。
Excelの問題とCSVの文字コードを混同しない
ここで少し注意があります。
Excelの.xlsxファイル自体が「Shift_JISで保存されている」という捉え方は適切ではありません。
私が文字コードを確認するのは、主に業務システムから出力されたCSVやテキストデータです。
Excelの表をNotebookLMで扱う場合は、Google Sheetsへ変換するなど、表の構造そのものも含めて整理します。
古いPDFが「□□□」になる原因は外字・フォントも疑う
CSV以外で私が実際に困ったのが、古い社内文書です。
昔のWordファイルには、会社独自の外字や特殊な社内専用フォントが使われているものがあります。
そのWordファイルをPDF化してNotebookLMへ読み込ませたところ、元文書では正常に見えている文字が、ソースプレビューでは「□□□」や意味不明な記号になったことがありました。
この場合、私はNotebookLM側の設定を何度も変更するより、元ファイル側を直します。
- 一般的なフォントへ置き換える
- 外字を通常のUnicode文字へ置き換える
- 可能ならWordやGoogleドキュメント自体をソースにする
- 必要ならフォントを適切に埋め込んでPDFを再作成する
PDFは画面上で正常に表示できても、「AIがテキストとして正しく取り出せる」とは限りません。
私はアップロード後に必ずNotebookLM側のソースプレビューも確認しています。
PDFを読み込めないなら「文字を選択できるか」を確認する
次に多いのが、紙を複合機でスキャンしただけのPDFです。
私は数年前の就業規則をスキャンしたPDFをNotebookLMへ読み込ませたところ、質問しても「該当する情報が見つかりません」という状態になりました。
そこでPDFをChromeで開き、文章をマウスで選択しようとしてみました。
ところが、文字を1文字ずつ選択できず、ページ全体が1枚の画像になっていました。
文字を選択できないPDFなら、まずOCRを疑う。
これが私の最初の切り分けです。
スキャンPDFはGoogle Drive OCRでテキスト化する
画像だけだった就業規則PDFは、Google DriveのOCRを使って復旧しました。
- スキャンPDFをGoogle Driveへアップロードする
- ファイルを右クリックする
- 「アプリで開く」→「Google ドキュメント」を選ぶ
- Googleドキュメントへ抽出された文字を確認する
- そのGoogleドキュメントをGemini Notebookのソースにする
私が試した就業規則では、これでNotebookLMから内容を検索・要約できるようになりました。
OCR後のテキストは必ず目視確認する
ただし、OCRは魔法ではありません。
実際に私が変換した文書でも、数字の「1」がアルファベットの「l」になっているなど、一部の誤認識がありました。
Google公式も、Google DriveからGoogle DocsへのOCR変換では、太字や改行などは比較的残りやすい一方、表・列・脚注などは正しく認識されにくいと案内しています。
そのため、OCR後は特に次の情報を確認します。
- 金額
- 日付
- 条文番号
- 固有名詞
- 表の行・列
重要な数字を含む資料なら、OCR結果をそのまま正式なデータとして扱わない方が安全です。
Google DriveによるPDF・画像のOCR方法は、Google Drive公式ヘルプで確認できます。
複雑な表は「文字化けしていない」からこそ危ない
私がNotebookLMで最も警戒しているのは、実は文字化けよりこちらです。
見た目は正常なのに、AIが表を間違って読んでいるケースです。
例えば、セル結合を多用した減価償却の耐用年数表や、「部署×勘定科目」の予算実績マトリクスをPDF化して読み込ませたことがあります。
そこで、
「A部署の交際費はいくら？」
と質問したところ、1段ずれたB部署の数字を回答されました。
行・列・セル結合で意味を表している帳票は、人間には直感的でも、AIが同じ構造として解釈できるとは限りません。
表がある資料は最初に1問だけテストする
そこで私は、本格的に分析を始める前にピンポイントテストをします。
読み取り確認用の質問例
〇ページ目の表に記載されている「総務部」の「消耗品費」の金額を、そのまま回答してください。
推測や計算は行わず、資料に記載されている数値だけを回答してください。
ここで原本と一致しないなら、その資料を使った集計・比較は行いません。
表を作り直してAIへ合わせる手間が大きい場合は、私はNotebookLMを使うこと自体を諦めて目視確認へ戻します。
AIを使うために30分データを整えるなら、5分で原本を確認した方が速いケースもあります。
NotebookLMが英語になるならOutput Languageを日本語へ
資料は正常なのに、チャットだけ英語になる場合は文字化けではありません。
出力言語の問題です。
私は英語の公式ガイドラインをソースにして日本語で質問したとき、英語で回答されることが何度かありました。
現在のGemini NotebookにはOutput Language設定があります。
- Gemini Notebookを開く
- 画面右上の「Settings」を開く
- 「Output Language」を選ぶ
- 「日本語」を選択する
Google公式では、Googleアカウントの優先言語がGemini Notebookのデフォルト出力言語として使われます。
それでも英語になる場面では、私は質問の最後にも「必ず日本語で回答してください」と明記しています。
出力言語の最新仕様は、Google公式のOutput Languageヘルプで確認してください。
Audio Overviewは現在日本語に対応している
以前、私がNotebookLMを使い始めた頃には、日本語資料からAudio Overviewを作っても英語のラジオ番組のようになることがありました。
しかし、現在の仕様は変わっています。
2026年8月現在、Gemini NotebookのAudio Overviewは日本語を含む80以上の言語に正式対応しています。
生成画面から言語を選べるため、日本語で作りたい場合はAudio Overviewの設定でJapaneseを指定してください。
旧記事にあった「英語が基本」「日本語設定後にソースを再アップロードする」といった手順を、現在の第一選択にする必要はありません。
Audio OverviewにはAI生成特有の不正確さや音声上の不具合が含まれる可能性もあるため、重要な内容は元資料を確認してください。
現在の対応言語は、Google公式のAudio Overviewヘルプで確認できます。
現在のNotebookLMで読み込める主なファイル形式
Gemini Notebookの対応形式も以前より増えています。
| ソース | 対応 | 注意点 |
|---|---|---|
| ○ | スキャン・特殊フォント・複雑な表は確認 | |
| CSV | ○ | 日本語の文字コードを確認 |
| Google Sheets | ○ | 複雑な表構造は原本と照合 |
| Word（docx） | ○ | 外字・特殊フォントに注意 |
| テキスト（txt） | ○ | 文字コードを確認 |
| Markdown | ○ | 比較的シンプルに扱いやすい |
| PowerPoint（pptx） | ○ | 視覚レイアウトの解釈は確認 |
| 画像 | ○ | 種類によって認識精度に差がある |
| Webページ | ○ | 基本的にHTML内のテキストを取り込む |
Google公式では、Google Sheetsは現在1ソースあたり100,000トークンまで、一般のアップロードファイルは最大200MBまたは50万語までと案内されています。
最新の対応形式は、Google公式のソース追加ガイドを確認してください。
パスワード付きPDFは無理に解除してAIへ入れない
私は、取引先から受領したパスワード保護付きNDAや、コピー制限付きの提案書をNotebookLMへ追加しようとしてエラーになった経験があります。
ここで私がやらないのが、AIへ読ませるためだけに保護を解除することです。
「PDFとして印刷し直せば解除できるかもしれない」と考えるより、まずその保護がなぜ付いているのかを考えます。
取引先から意図的に保護された契約書や提案書なら、それを別形式へ変換して外部AIサービスへ渡すこと自体が、契約や社内ルールに反する可能性があります。
私の運用では、取引先の保護ファイルはその時点でNotebookLM利用を中止します。
社内文書であれば、権限を持つ元のWord・Googleドキュメントなど、保護される前の正規ファイルがないか確認します。
「技術的に解除できるか」ではなく「解除してAIへ渡してよい資料か」で判断するのが、元情シスとしての私の基準です。
ブラウザが重い場合は拡張機能も疑う
ファイル自体ではなく、NotebookLMの画面が固まることもありました。
私の場合、Chromeでアップロード画面が固まったり、文字入力が極端にもたついたりしたことがあります。
そこでシークレットウィンドウからNotebookLMを開くと、正常に動作しました。
通常のChromeにはDeepLなどの翻訳拡張機能や広告ブロックを入れていたため、いずれかの拡張機能が干渉していた可能性があります。
ブラウザ側の不具合を疑う場合は、私は次の順番で確認します。
- シークレットウィンドウで試す
- 問題が消えれば拡張機能を1つずつ確認する
- 必要なら別ブラウザで確認する
- それでも直らなければサービス側の問題も疑う
「文字化けしたからキャッシュ削除」と決めつけるのではなく、ファイルの中身が壊れているのか、画面操作だけがおかしいのかを先に分けることが重要です。
アップロード後はソースプレビューを必ず確認する
文字化けや読み取りミスを早く発見するために、私はアップロード直後の確認をルール化しています。
チェック1｜ソースプレビューを目視する
Gemini Notebookへファイルを追加したら、すぐ質問を始めるのではなく、ソースを開きます。
そこで、
- □□□になっていないか
- 日本語が途中から消えていないか
- 文章が極端に崩れていないか
- OCRで重要な数字が変わっていないか
を確認します。
Google公式も、Gemini Notebook上では分析しやすくするため、ソース内容の表示が元ファイルとは異なる場合があると説明しています。
チェック2｜表があるなら既知の数字を質問する
表がある資料では、AIの性能を信じるのではなくテストします。
原本を見れば答えが分かっている数字を1つ質問して、一致するか確認します。
ここでズレたら、その資料を使った数字の分析は中止します。
元情シスが実践する文字化けの直し方4ステップ
いろいろ対策を紹介しましたが、私は実務では次の順番しか使っていません。
STEP1｜文字コード・ファイル形式を変える
最も早く終わる方法から試します。
- CSV → UTF-8で保存し直す
- 古いWord → 一般的なフォントへ変更
- Excel → 必要に応じてGoogle Sheets・CSVへ整理
- PDF → 元データがあるなら正規ファイルから再作成
STEP2｜スキャンPDFならOCRする
文字自体を選択できないならGoogle Drive OCRなどでテキスト化します。
ただしOCR後の数字・表・固有名詞は確認します。
STEP3｜必要な部分だけテキストで直接追加する
ファイル全体を正常化するのが面倒なら、必要な文章だけをコピーします。
Gemini Notebookはコピー＆ペーストしたテキストもソースとして追加できます。
数ページだけ確認したい資料なら、この方法の方が速いこともあります。
STEP4｜直すコストが高ければ諦める
最後が、実務では一番大切だと思っています。
セル結合だらけの表をAIが理解できるように作り直したり、何度もPDFを変換したりするうちに30分経過したら、AIを使う意味がありません。
その資料だけ人間が5分で確認できるのであれば、私は目視へ戻します。
AIを使うことが目的ではなく、仕事を速く正確に終わらせることが目的。
これはNotebookLMに限らず、業務改善で私が一番大切にしている判断基準です。
NotebookLMの文字化けに関するよくある質問
まとめ｜文字化けより「正しく読めているか」を確認しよう
NotebookLMの文字化け対策で、私は難しい設定から触りません。
実務では次の順番です。
- CSVならUTF-8へ保存し直す
- 外字・特殊フォントなら元文書を修正する
- 画像PDFならOCRする
- 表なら既知の数字で読み取りテストをする
- 日本語にならなければOutput Languageを確認する
- 画面が重ければシークレットモードで切り分ける
- 保護された資料は無理に解除しない
- 直す時間がもったいなければAI利用を諦める
そして一番重要なのは、文字がきれいに表示されていることではありません。
AIが元資料を正しく理解できているかを確認することです。
実際、私は文字化けしていない減価償却表で、NotebookLMに1行ずれた数字を回答されたことがあります。
だからこそ、アップロード後にソースを目視し、重要な表では既知の数字を1つ質問してから本番利用します。
AIにクリーンなデータを渡し、読めない資料は無理に読ませない。
これだけでもNotebookLMの実務利用はかなり安定します。
もし「文字は正常なのに、そもそもPDFやURLをソースとして追加できない」という場合は、ファイル形式・権限・容量など別の原因が考えられます。
＼ ソース自体を追加できない場合はこちら ／
