SkillStack Lab（スキスタ）運営者のスタックです。
NotebookLMを使い込んでいると、「ノートブックが増えすぎて、どこに何を入れたか分からない」「Googleドライブのようにフォルダ分けできないの？」と感じることがあります。
私も仕事・ブログ・個人的な検証を合わせて、現在は約30個のノートブックを常時使っています。
導入当初は「社内会議まとめ」「AIツール比較」のような曖昧な名前を付けていたため、「先月の部門定例の議事録はどこだっけ？」と探すことがありました。
先に結論を言うと、NotebookLMの整理で重要なのは、無理にフォルダを再現することではなく、「1ノートブック1目的」と分かりやすい命名を徹底することです。
スタック30個ほど使うようになると、「AIが賢いから整理しなくても大丈夫」とは言えなくなりました。私が一番重視しているのは、開く前に目的が分かる名前です。
また、Standardでは1ノートブック50ソースまで追加できますが、私は上限まで詰め込みません。実務では15〜20ソースを超えたあたりから、引用元を確認する作業が急に面倒になったからです。
- NotebookLMにフォルダがない場合の現実的な整理方法
- 約30個のノートブックを管理している実際の命名ルール
- 50ソースまで詰め込まない方がよい理由
- 複数資料を1つのGoogle Docsへ統合して失敗した理由
- 原本ソースを削除してはいけない理由
- 共有ノートブックを汚さないための運用ルール
NotebookLMにフォルダ分けはできる？
現時点のGoogle公式ヘルプでは、ノートブック自体をGoogleドライブのようなフォルダ階層へ格納する機能は確認できません。
一方、ノートブックの中にあるソースについては、整理機能が強化されています。
5つ以上のソースがある場合、Gemini Notebookはソースを自動でラベル付け・カテゴリ分けできます。ラベルは自分で追加・名称変更・削除したり、ソースを別のラベルへ移動したりすることも可能です。
最新の仕様は、Google公式のソース追加・整理に関するヘルプで確認できます。
「ノートブック一覧の整理」と「1つのノートブック内のソース整理」は別問題です。私は前者を命名ルール、後者をソース数の抑制で管理しています。
約30個のNotebookLMを管理する私の命名ルール
旧記事では「00_」「10_」「20_」「90_」のような数字を使った命名方法を紹介していました。
現在、この方法は使っていません。
個人だけなら成立しますが、チームで共有すると「10は何？」「80は何？」というルールそのものを覚える必要があり、管理が硬直的になったからです。
現在は、もっと単純なカテゴリ接頭辞にしています。
| 用途 | ノートブック名の例 |
|---|---|
| 社内業務 | [社内] 経費精算マニュアル・規程QA |
| ブログ | [Blog] Udemy5月プロモーション実績分析 |
| 検証 | [検証] 新規SaaSのAPI仕様書解読 |
ポイントは、NotebookLMを開く前に「何のために作った作業場所なのか」が分かることです。
ステータスではなく用途で分ける
旧記事では、ノートブックを「インボックス」「作業中」「アーカイブ」の3段階に分ける方法も紹介していました。
これも現在は使っていません。
NotebookLMはタスク管理ツールではないため、私の場合はステータスよりプロジェクト・用途単位で分けた方が直感的でした。
- 1つの業務テーマにつき1ノートブック
- 1つの記事群・リサーチテーマにつき1ノートブック
- 一時検証は本番ノートブックと分ける
- タイトルだけで用途が分かる名前にする
ソース上限50個まで詰め込まない｜私の目安は15〜20個
Gemini Notebook Standardでは、現在1ノートブックあたり最大50ソースを利用できます。
ただし、上位プランでは上限が増えるため、「NotebookLMは必ず50個まで」というわけではありません。
最新の上限は、Gemini Notebook公式ヘルプの利用上限で確認してください。
それより重要なのが、仕様上の上限と、人間が管理できる上限は違うということです。
私はブログの比較リサーチで、複数のAIサービスやアフィリエイト商材について、公式サイト・料金ページ・PDFパンフレットなどを大量に読み込ませた経験があります。
限界近くまでソースを増やしましたが、15〜20ソースを超えたあたりから管理が急に難しくなりました。
スタック50個入るから50個入れる、ではないですね。私の場合は15〜20個を超えたあたりから「この回答の根拠はどの資料だ？」を確認する時間が増え、かえって非効率になりました。
NotebookLMのチャットには引用が付きますが、ソース一覧自体が増えすぎると、人間側のファクトチェックが大変になります。
ソース数が増えてきたら「上限を突破する方法」を探す前に、そもそも目的の違う資料が同じノートブックへ混ざっていないか確認してください。
50ソース制限を回避するために資料を1つへ結合しない
旧記事では、複数の資料をGoogle Docsのタブなどへまとめ、1ソースとして読み込ませる方法をおすすめしていました。
私はこの方法を実際に試しましたが、現在は使っていません。
致命的だったのは引用元が分からなくなること
例えば、10個のPDFを1つのGoogle DocsへコピーしてからNotebookLMへ追加すると、NotebookLM上ではそのGoogle Docsが1ソースになります。
表面的にはソース数を減らせます。
しかし、回答の引用元もその統合Google Docsになってしまうため、元々どのPDF・どの規程・どの公式資料から取得した情報なのか追いにくくなります。
ソース数を減らすためだけに複数の原資料を1ファイルへ結合すると、引用元のトレーサビリティを失う可能性があります。業務利用では特に注意してください。
元情シスとして、私は「回答できること」以上に、その回答が何を根拠にしているか後から追えることを重視しています。
そのため、1つのノートブックが大きくなりすぎたら、資料を無理に結合するのではなく、目的ごとにノートブックを分けます。
メモをソース化しても原本PDFは削除しない
Gemini Notebookには、作成したNoteをSourceへ変換する公式機能があります。
機能自体は便利ですが、私は「要約したNoteを残したから元のPDFは削除していい」とは考えません。
AIが作った要約では、
- 例外条件
- 小さな脚注
- 金額の端数
- 補足事項
- 一見重要に見えなかった条件
などが省略される可能性があります。
後から「例外の場合はどうだった？」と聞きたくても、元ソースを削除していれば確認できません。
AIの要約を原本の代わりにして、元PDF・公式資料・規程などの生ソースを削除しないでください。
NoteをSourceへ変換する現在の公式機能は、Google公式のNotesヘルプで確認できます。
スタック要約は原本ではありません。後から例外条件を確認できるように、私はPDFなどの生ソースを残したまま使います。
ソースの自動ラベルは便利だが、私は依存していない
現在のGemini Notebookでは、5ソース以上になると自動でラベル・カテゴリ分けする機能があります。
自動分類後に、自分でラベル名を変更したり、ソースを別カテゴリへ移したりすることもできます。
ただし、私はこの機能に実務を依存させていません。
理由は単純で、1つのノートブックへ入れるソースを多くても十数個程度に抑えているからです。
少ないソースを自分で確認できる状態なら、AIによる分類を手直しするより、最初から用途を絞った方が管理しやすいと判断しています。
完了したノートブックは「残す」と「削除する」を分ける
ノートブック一覧を軽く保つには、命名方法だけでなく、使い終わった後の処理も重要です。
私は次のように分けています。
| 種類 | 処理 | 例 |
|---|---|---|
| 継続利用・定期更新 | 残す | 就業規則、継続的な実績データ |
| 後から再検証する可能性が高い | 残す | 長期リサーチ、複雑な設定資料 |
| 単発作業 | 成果物を取り出して削除 | 英文の単発確認、ニュース調査 |
| 単発の検証 | 不要になれば削除 | 一時的なSaaSテスト |
例えばブログ構成案ならNotionへ、社内FAQならSharePointなどへ成果物を移してから、NotebookLM自体を残す必要があるか判断します。
NotebookLMのメモや表を外部へ出す具体的な方法は、NotebookLMのメモをエクスポートする方法で詳しく解説しています。
共有ノートブックは「権限」と「ガベージイン」に注意
チーム利用では、個人利用とは別の問題が出てきます。
私が特に困ったのは、次の2つです。
ソース単位で見せる相手を分けにくい
Gemini Notebookの共有では、ノートブックに対してViewerまたはEditorとしてユーザーを追加できます。
私の運用では、「Aさんにはマニュアルを見せたいが、同じノートブックにある役員会議資料は見せたくない」といったソース単位の細かな権限制御ができないことが問題になりました。
そのため、機密度が異なる資料を最初から同じノートブックへ入れません。
共有範囲が異なる資料は、同じノートブックへ混在させず、ノートブック自体を分ける方が安全です。
共有の現在の仕様は、Google公式のNotebook作成・共有ヘルプも確認してください。
関係ない資料を追加されると回答がブレる
もう一つ実際に起きたのが、共有ノートブックへの「とりあえず追加」です。
他のメンバーが古いPDFや個人メモなど、今回の目的と直接関係のない資料を追加すると、AIが参照する前提情報が増えます。
その結果、同じ質問でも以前と回答の切り口が変わったり、確認すべきソースが増えたりして、使いづらくなりました。
- 1ノートブック1目的にする
- 機密度が違う資料を混在させない
- 古い資料を追加する前に現行版か確認する
- 「とりあえず追加」をしない
- 不要になったソースを定期的に見直す
フォルダ用の非公式Chrome拡張機能は企業利用ではおすすめしない
旧記事では、NotebookLMへフォルダ表示を追加する非公式Chrome拡張機能を複数紹介していました。
現在の記事では、これらをおすすめから外します。
私自身が業務環境で検証していないことに加え、会社アカウントで利用するブラウザへ、開発元が不透明な拡張機能を追加することには慎重だからです。
拡張機能によっては、閲覧しているWebページへのアクセス権限などを要求する場合があります。
社内資料や機密情報をNotebookLMで扱う場合、整理の便利さだけを理由に非公式ブラウザ拡張を導入しないでください。会社のITポリシーと権限内容を先に確認しましょう。
少なくとも私の運用では、カテゴリ接頭辞・ノートブック分割・不要Notebookの削除だけで十分管理できています。
私が現在使っているNotebookLM整理ルール5つ
- 1ノートブック1目的にする
- [社内] [Blog] [検証]の接頭辞で用途を見える化する
- ソースは15〜20個を超える前に分割を検討する
- 要約を作っても原本ソースは残す
- 単発Notebookは成果物を取り出したら削除する
フォルダ構造を複雑に設計するより、この程度のルールの方が現在の私には合っています。
正式な社内ファイルの保管場所について迷う場合は、SharePointとTeamsの違い・正しい使い分けも参考にしてください。
NotebookLMのフォルダ分け・整理に関するよくある質問
まとめ｜NotebookLMはフォルダを作るより「増やしすぎない」
NotebookLMを整理するとき、私は複雑なフォルダ階層を再現しようとはしていません。
- [社内] [Blog] [検証]で目的を見える化する
- 1つのノートブックへ目的の違う資料を混ぜない
- 15〜20ソースを超えたら分割を考える
- 引用元を失うような資料結合はしない
- 要約を作っても原本ソースを消さない
- 単発作業のノートブックは成果物を取り出して削除する
整理に時間をかけすぎるくらいなら、ノートブックを小さく分け、成果物を外へ出し、不要になったものを消す。
現在30個ほど使っている私には、この方法が一番シンプルで運用しやすいです。
使い終わったNotebookLMのメモ・比較表・Audio Overviewなどをどこへ保存するか迷っている場合は、エクスポート方法も整理しておくと運用がさらに楽になります。
＼ NotebookLMの出口も整理する ／
