公式ドキュメント、ベンダーホワイトペーパー、社内マニュアル、技術ブログの記事を NotebookLM に蓄積していくと、いつのまにか 1 つのノートブック（Notebook）にソース（Sources）が積み上がり、何をどこに入れたのか追えなくなる。粒度設計を最初に決めておけば、再編成にかかる手作業を後から大きく圧縮できる。本記事は、無料版 50 ソース・有料版 300 ソースという上限を起点に、4 つの分割軸でノートブックを切り、Discover Sources（ディスカバーソース）と Deep Research（ディープリサーチ）を「ソースを拾う／作る」初手として位置づける運用設計をまとめる。動作確認日は 2026 年 5 月 3 日、すべての手順を NotebookLM 無料版で再現できる構成にした。
インフラエンジニアの実素材として、AlmaLinux のサービス別運用、CNCF プロジェクト別の仕様束、ベンダー比較目的の調査、半期ごとの時系列メモ、社内マニュアル統合の 5 系統を例として扱う。プラン呼称は本記事では Free / Plus / Pro / Ultra の 4 段階で書き分ける（公式ヘルプ準拠）。
NotebookLM 学習効率化シリーズ（全 8 回）
- 第 1 回 NotebookLM 機能マップ 2026 年 5 月版
- 第 2 回 技術書 1 冊を完走する NotebookLM 学習フロー
- 第 3 回 ノートブック設計論 — 粒度と Discover / Deep Research いまここ
- 第 4 回 英語の技術ドキュメントを日本語で読み解く
- 第 5 回 自分の学習メモを NotebookLM のソースにする
- 第 6 回 通勤・移動中の Audio Overview 運用
- 第 7 回 Studio で学びを構造化する
- 第 8 回 モバイルとデスクトップの役割分担
ソース上限から逆算するノートブック粒度設計 — 50 / 300 の数値を起点にする
粒度設計は「テーマで分ける」よりも先に、上限の数字を確認するところから始まる。1 ノートブックに入るソースの数と総語数が決まっているため、そこから逆算したほうが、後から再編成する確率が下がる。
無料版と有料版の上限
NotebookLM の公式ヘルプ（英語版アップグレードヘルプ、確認日 2026-05-03）はプランを Free / Plus / Pro / Ultra の 4 段階で示しており、リソース上限はそれぞれ独立した数値が記載されている。日本語版アップグレードヘルプには現時点で 4 段階の詳細表が見当たらないため、本記事は英語版を典拠とする。
| 項目 | Free（無料） | Plus | Pro | Ultra |
|---|---|---|---|---|
| ノートブック数 | 100 件 | 200 件 | 500 件 | 500 件 |
| 1 ノートブックあたりのソース数 | 50 件 | 100 件 | 300 件 | 600 件 |
| 1 ソースの語数 | 500,000 語 | 500,000 語 | 500,000 語 | 500,000 語 |
| 1 ソースのサイズ | 200MB | 200MB | 200MB | 200MB |
| チャットの 1 日クエリ数 | 50 クエリ | 200 クエリ | 500 クエリ | 5,000 クエリ |
| 音声概要（Audio Overview）の 1 日生成数 | 3 件 | 6 件 | 20 件 | 200 件 |
注目すべきは「1 ソースあたりの語数 / サイズはプランに依存しない」という点だ。500 ページ前後の技術書 1 冊は 1 ソースに収まる。逆に 1,000 ページ級の英語仕様（複数 RFC を束ねた PDF など）は 500,000 語の上限に当たることがあり、ソースを章単位に分割して投入する判断が要る。
粒度を「先に決めない」設計順序
粒度設計の典型的な失敗は、テーマ名から先に決めて、ソースを後から詰め込むパターンだ。1 ノートブック 50 ソース上限は無料版運用では到達しやすい数字で、運用 3 か月で 50 を超えるノートブックが出てくる。順序を逆にする。
- 1 ノートブックに入る最大ソース数（Free 50 / Plus 100 / Pro 300 / Ultra 600）を確認する
- 1 ノートブックの運用期間（半期・プロジェクト終了まで・恒常的）を仮置きする
- その期間内に追加されるソース数を見積もる（公式・ベンダー・社内・外部記事の合算）
- 見積もりが上限の 70〜80% を超えるなら、テーマをさらに分割する
- 収まりそうなら、テーマ名・運用期間を確定する
1 ノートブックあたりの運用指針
1 ノートブックあたりの推奨ソース数は、2026 年 5 月時点の公式ヘルプには明記がない。上限のみが示されている。本記事では運用上の判断材料として、確信度: 中の指針を提示する。
運用指針（公式未明記、本記事の判断材料）
- 横断質問の精度を保ちたいなら、1 ノートブック 10〜30 ソースを主軸にすると話題が散らばりにくい
- 無料版 50 ソース上限に対しては、70〜80% 程度の埋め方（35〜40 ソース）で運用すると、後で追加する余地が残る
- 1 ソースが大容量（500,000 語近い技術書 1 冊など）の場合は、件数より語数の総和で判断する
10〜30 という範囲は、公式が示した値ではなく運用上の判断指針だと理解した上で使う。多すぎると質問の回答が散漫になり、少なすぎると横断質問の旨味が薄れる、という両側の落とし所を取った数字となる。技術書 1 冊で 1 ノートブックを使う運用については 技術書 1 冊を完走する NotebookLM 学習フロー で扱った。本記事はそれよりも一般的な「複数素材を束ねるノートブック」の粒度設計に踏み込む。
4 つの分割軸でノートブックを切る — サービス別・目的別・プロジェクト別・時系列
粒度を逆算した次は、分割軸を選ぶ。インフラ業務の素材は、サービス・目的・プロジェクト・時系列の 4 軸で切るとほとんどのケースに当てはまる。1 つのノートブックに対しては基本 1 軸で運用し、複数軸が混ざりそうなときは分割を検討する。
4 軸の概観と向き不向き
| 軸 | 設計例 | 典型ソース | 向くケース | 向かないケース |
|---|---|---|---|---|
| サービス別 | 「AlmaLinux 10 運用」「Cisco IOS XE」「PostgreSQL 18」 | 公式ドキュメント、ベンダーリリースノート、社内設定例 | 恒常的に運用する基盤、長期で更新が続く製品 | 1 回限りの調査、複数サービスを横断する比較 |
| 目的別 | 「IPv6 移行調査」「監視基盤刷新検討」 | 各ベンダー比較資料、関連論文、社内 RFC、技術ブログ | 複数ベンダー横断比較、選定理由の整理 | 恒常運用に切り替わったあとも持ち越すケース |
| プロジェクト別 | 「Project-A 設計検討」「リプレース案件 X」 | プロジェクト固有の資料、議事録、設計書 | 開始日と終了日が明確な案件 | 恒常運用、共有用途 |
| 時系列 | 「2026-Q2 技術選定メモ」「半期キャッチアップ」 | 期間内に読んだ素材を寄せ集める | 素材の主題が定まる前のキャッチアップ期 | 主題が固まった後の長期運用 |
サービス別: AlmaLinux 10 運用ノートブック
サービス別は最も使いやすい軸で、長期で更新が続く製品の公式ドキュメントとベンダーリリースノートを束ねる用途に合う。AlmaLinux 10 を例に取ると、公式リリースノート PDF、Errata の Web URL、関連 RPM の changelog、社内のキックスタート設定例、systemd の運用スクリプトと service ファイル集をまとめておけば、次にバージョンが上がった際の差分調査が 1 つのノートブックで完結する。
目的別: ベンダー比較や選定調査
目的別は、複数ベンダーの主張を横断するときに向く。「コンテナランタイム選定」のような目的を立てたら、Docker / containerd / CRI-O / Podman の各公式ドキュメント、CNCF プロジェクトの README、関連ホワイトペーパー、ベンダー寄りの技術ブログを束ねる。横断質問で「主張が異なる項目を 5 つ挙げて」と聞ける状態を作れば、選定理由の整理が 1 ノートブックで進む。目的が達成された後は、得られた結論を別の社内ナレッジへ移し、ノートブックはアーカイブするか削除する。
プロジェクト別: 開始と終了が明確な案件
プロジェクト別は「Project-A 設計検討」「リプレース案件 X」のように、開始日と終了日が明確な単位でノートブックを立てる軸だ。プロジェクト固有の設計書、議事録の抜粋、関連する公式ドキュメント、選定根拠となったホワイトペーパーを束ねる。プロジェクトが終了したら、削除するか「アーカイブ」用ノートブックの位置づけに切り替える。プロジェクト中に入った素材は、後から別ノートブックへの「移動」が公式 UI 上は確認できないため、最初から正しい粒度に置く意識が要る。
時系列: 主題が固まる前の半期キャッチアップ
時系列は、主題がまだ定まっていない段階の素材置き場として使う。「2026-Q2 技術選定メモ」のような半期ノートブックを 1 つ持っておき、Q2 の間に読んだ素材を寄せ集める。期が変わった時点で、内容を眺めて主題が立ったテーマだけ別ノートブックへ切り出し、雑多に終わった素材は削除する。長期で持ち続けると上限に当たるため、必ず期の終わりに棚卸しを 1 回挟むのが運用のコツとなる。
CNCF プロジェクト別と社内マニュアル統合
CNCF プロジェクト別はサービス別の派生で、Kubernetes / etcd / Cilium / KubeVirt 等のプロジェクトを 1 つずつノートブックに置く運用となる。1 プロジェクトの公式ドキュメントは複数ファイル・複数 README に分散しているため、Web URL とリリースノート PDF を 10〜20 ソース束ねれば、横断質問が回せる規模になる。社内マニュアル統合はやや特殊で、複数部署のマニュアル PDF を 1 ノートブックに集めて「どの手順がどのマニュアルに書いてあるか」を引ける状態を作るパターンだ。社内 RFC や運用ハンドブックを 20〜30 ソース置けば、検索の起点として動く。
補足: 4 軸を厳密に守る必要はない。「サービス別だが、特定プロジェクトでだけ追加調査した素材も同居させたい」のように混在することは普通に起きる。混在を許容しつつ、上限の 70〜80% を超えそうになったら分割を検討する、というルールにしておくと、運用が硬直化しない。
Discover Sources でソースを「拾う」 — 既知テーマの周辺を広げる初手
粒度と分割軸が決まったら、ソースを集める段階に入る。Discover Sources は、テーマやクエリを入力すると Web 上から関連するソース候補を提示してくれる機能で、モバイル版では Fast Research（ファストリサーチ）の名称で提供されている。2025 年 1 月の公式アナウンスでは「最大 10 件のソース候補」を提示する仕様が公開された。
Discover Sources の動かし方
- ノートブックを開き、ソース追加メニューから「Discover」を選択する
- テーマやクエリを 1〜2 文で入力する（例: 「KubeVirt の運用ガイドと公式チュートリアル」）
- NotebookLM が Web を検索し、最大 10 件のソース候補を一覧表示する
- 候補を確認し、ノートブックに追加するソースを選択する
- 選んだソースだけが Web URL ソースとして取り込まれる
候補件数は 2026 年 5 月時点の公式アナウンスを根拠に「最大 10 件」と記載しているが、時期によって件数が変わる可能性はある。本記事執筆日 2026-05-03 時点の数字として位置づける。
利用シーンと注意点
Discover Sources が向いているのは、馴染みの薄い OSS の周辺資料を拾う初手だ。Cilium の eBPF 周辺、KubeVirt の VM 運用、Falco のセキュリティルール集など、自分が概要しか知らないテーマで、まずどんな一次情報があるかを 10 件規模で見せてもらう、という使い方になる。提示された候補が常に最良の一次情報になるとは限らないため、最終的に取捨選択するのは利用者側だ。
注意: Discover Sources の利用回数上限は、Free / Plus / Pro / Ultra いずれも 2026 年 5 月時点の公開ヘルプで上限の存在自体が明記されていない（プラン間の差も含めて未確認）。連続利用で何らかの上限に当たるかは公式記述が確認できない範囲となる。Web ページを候補化するため、提示される URL の信頼性は利用者側で確認する前提で扱う。
取り込んだ後の運用
Discover で取り込んだソースは、通常の Web URL ソースとしてノートブックに格納される。横断チャットの対象になり、ソース一覧のチェックボックスで個別に絞り込みもできる。Web URL ソースの自動再取得（refresh）挙動は 2026 年 5 月時点の公式ヘルプに明記がないため、元ページが更新された場合に NotebookLM 側が自動で追従するかは断定しない。重要な公式ドキュメントは、必要なタイミングで同じ URL を再追加し直す、または PDF をダウンロードして投入する運用に切り替えるのが安全だ。
Deep Research でソースを「作る」 — 馴染みの薄い領域を 1 本のレポートに圧縮する
Discover Sources が「既存の Web ページを候補として拾う」機能だとすれば、Deep Research は「複数ページを統合した新規レポートを生成する」機能となる。エージェント機能として位置づけられており、ユーザーの質問に対して NotebookLM が自律的に Web を巡回し、引用付きの分析レポートを 1 本作って、そのレポート自体をノートブックのソースとして保存する。
Deep Research の動かし方
- ノートブックを開き、ソース追加メニューから「Deep Research」を選択する
- 調査したい質問を入力する（例: 「2026 年時点の主要な eBPF ベース観測ツールの比較」）
- NotebookLM が複数の Web ページを巡回し、数分かけて分析レポートを生成する
- 生成されたレポートが、引用付きの 1 ソースとしてノートブックに追加される
- 追加されたレポートは、他のソースと同様にチャットの対象になり、引用クリックで参照元 URL に戻れる
制約: Deep Research は 18 歳以上のユーザー限定で提供されている（2026 年 5 月時点の公式ヘルプおよび公式ブログに明記）。年齢条件を満たさないアカウントでは利用できない。
Discover Sources との使い分けマトリクス
公式は両機能の使い分け表を出していない。本記事では論理的な整理として、確信度: 中の判断フレームを提示する。
| 軸 | Discover Sources（Fast Research） | Deep Research |
|---|---|---|
| 出力 | Web ページ候補を最大 10 件程度提示 | 引用付きの分析レポート 1 本（ソース化される） |
| 利用シーン | 既知テーマの周辺ソースを広く拾う | 馴染みの薄い領域を一気に俯瞰する初手 |
| 必要時間 | 数十秒〜数分 | 数分（より長い） |
| 結果の扱い | 利用者が候補を取捨選択 | レポート自体が読み物 |
| 年齢制約 | 公開ヘルプに記載なし | 18 歳以上限定 |
| 無料 / Pro 差 | 双方で利用可、上限の存在自体が公開ヘルプに明記なし（無料・有料の差も含めて未確認） | 同左 |
補完関係として使う
2 つの機能は対立するものではなく、補完関係として運用できる。Deep Research のレポートを読んで全体像を掴み、レポート末尾の参照元 URL を確認しつつ、追加で掘り下げたいテーマだけ Discover Sources で関連ページを拾う、という流れが組める。逆に、Discover で集めた素材群に対して、横断的な分析が欲しいタイミングで Deep Research を 1 本後追いで生成し、ソース群の交差する論点をまとめさせる使い方もある。
インフラ実務での使い分け例を 3 つ挙げる。
- 未知技術の俯瞰: WebAssembly System Interface（WASI）のような馴染みの薄い領域は、Deep Research で 1 本レポートを作り、概要を読み終えた後に Discover で関連ページを拾う
- ベンダー比較の初稿: コンテナランタイム選定やオブジェクトストレージ選定の初手として、Deep Research で 1 本「主要選択肢の比較レポート」を生成し、各ベンダーの公式 PDF は手動で追加
- 既知テーマの周辺拡充: AlmaLinux 10 の運用に新ノートブックを切ったタイミングで Discover を回し、見落としていた公式ドキュメントを 5〜10 件追加で拾う
Deep Research が巡回する Web ページは英語の一次ソース由来になることが多く、生成されるレポートも英語素材が中心になる傾向がある。英語素材を Deep Research に集めて日本語の出力を得たい場合は、出力言語の設定が要る。出力言語の運用と英語素材の日本語化は 英語の技術ドキュメントを日本語で読み解く で詳しく扱う。
既存ノートブックの再編成と再現テンプレート — 上限到達時の現実的な対処
運用を半年も続けると、いずれかのノートブックがソース上限に近づく。再編成の現実的な手順と、Featured Notebooks（フィーチャードノートブック）をテンプレート観察対象として使う活用法をまとめる。
公式が手順を示している操作と示していない操作
| 操作 | 公式に手順記述があるか | 暫定運用 |
|---|---|---|
| ノートブックのリネーム | 記述あり | UI から変更 |
| ノートブックの削除 | 記述あり | ホーム画面から削除 |
| ソースの個別削除 | 記述あり（ソース一覧から削除） | 古いソース・重複ソースを片付ける |
| ソースを別ノートブックへ「移動」する公式 UI | 2026-05-03 時点の公式ヘルプで明示の確認が取れていない | 移動先ノートブックに再追加し、元から削除する |
| ノートブックのコピー / 複製 | 同上、明示の確認が取れていない | 同じソースで新ノートブックを作るなら手動再追加 |
| ノートブックの統合 | 統合機能の公式記述なし | 統合先に不足ソースを再追加し、元を削除 |
「移動」「複製」「統合」の 3 つは、公式 UI 上で確認できないため、再追加と元削除を組み合わせる手作業になる。だからこそ、最初の粒度設計で「どこに置くか」を決めておく価値が大きい。後から動かしにくいという制約を念頭に置けば、設計時点で慎重になれる。
ソース追加方法ごとの再取得挙動
ソースを追加する経路は複数ある。再追加運用に絡むため、各経路の取り込み挙動を整理する。Web URL と Google Drive の自動再取得については、2026 年 5 月時点の公式ヘルプに明記がないため、本記事では自動同期と断定しない。
| 追加方法 | 取り込みの性質 | 再取得（refresh）の扱い |
|---|---|---|
| ファイルアップロード（PDF / ePub / Word / .txt / .md / .pptx / 画像 / 音声 等） | アップロード時点のスナップショット | 元ファイル更新時は再アップロードが必要 |
| Web URL | 取得時点のスナップショット | 自動再取得の挙動は公式に明記なし。同じ URL を再追加するか、公式 UI の最新挙動を確認する |
| YouTube URL | 字幕ベースで取り込み | 字幕がない動画は取り込み不可、または部分的 |
| Google Drive（Docs / Slides / Sheets） | Drive から選択して追加 | Drive 上のドキュメント変更が NotebookLM 側に同期反映されるかは公式ヘルプで確認した範囲では明記が見つからない |
| コピー貼り付け（テキスト） | 貼り付け時点のスナップショット | 更新したい場合は同じ手順で再貼り付け |
| Gemini チャットからのソース化 | チャット履歴のスナップショット | 更新したい場合は再度ソース化 |
上限到達時の選択肢
無料版でソース 50 に当たったときの選択肢は、大きく 3 つに整理できる。
- 分割: テーマが内部で分かれているなら、新ノートブックを 1 つ作り、半分のソースを再追加して元を削除する。最初に 4 軸のいずれかで分割線を引き直す
- 古いソース削除: バージョンが古いリリースノート、過去プロジェクトの議事録など、参照頻度が落ちたソースをノートブックから削除する。アーカイブが必要なら手元のファイルとして保管する
- 統合先への再追加: 似た主題で別ノートブックを作っていた場合、片方を「メイン」と決め、もう片方の必要ソースを再追加して、不要になった方を削除する
3 つの選択肢のいずれを選んでも、再追加の工程が入る。設定時点で 70〜80% の埋まり具合を保つよう設計しておけば、上限到達自体が起きにくくなる。個人の学習メモを別ノートブックで運用してナレッジベース化する観点は 自分の学習メモを NotebookLM のソースにする で扱う。
Featured Notebooks をテンプレート観察対象として使う
NotebookLM は「おすすめ」タブから Featured Notebooks を閲覧できる。Google がキュレートした公開ノートブックで、書籍 1 冊を 1 ノートブックに束ねた構成、研究分野ごとに資料を集めた構成、ニュース集成型の構成など、テーマ単位の作例が並んでいる。自分が粒度判断に迷ったときの比較材料として、2〜3 件開いてソース構成を観察する使い方ができる。
補足: Featured Notebooks は提供地域が限定されている場合がある旨、公式ヘルプに記述されている。個別タイトルやソース構成は時期で変動するため、本記事では特定のノートブック名は引用しない。アクセスできる場合に「テーマ単位での束ね方の作例」を観察する目的で活用する位置づけとする。
共有を見据えるなら粒度を狭める
共有用ノートブックを見据える場合、自分用の粒度より一段狭く作り直すのが現実的だ。公開ノートブックの発行自体は無料版でも可能で、共有モード切替（チャットのみ／全体）とアナリティクスは Plus / Pro / Ultra 等の有料版で利用できる追加要素となる。読み手は元のソースを横断する文脈を持たないため、テーマを 1 つに絞ったほうが質問の精度が安定する。有料版の共有モード切替を使えば、自分のメモを同居させたままチャットだけ共有することもできるが、共有を最優先するなら、共有専用ノートブックを別建てして「読み手の関心に最も近い 10〜20 ソース」だけを置く設計が向いている。
音声概要を週次運用に組み込みたい場合や、スタジオ（Studio）パネルのアーティファクトをノートブック内に蓄積していく運用は、それぞれ 通勤・移動中の Audio Overview 運用 と マインドマップ・要約・学習ガイドで学びを構造化する Studio 活用 で扱う。本記事のノートブック粒度設計は、その前段の土台に位置づけられる。
2026-05-03 時点で公式未明記の項目一覧
本記事で「公式未明記」と注釈した項目を一覧化する。運用上はいずれも断定せず、最新の公式ヘルプを画面で確認する前提で扱う。
| 項目 | 未明記の内容 |
|---|---|
| 1 ノートブックあたりの推奨ソース数 | 上限のみ明記（Free 50 / Plus 100 / Pro 300 / Ultra 600）。推奨件数の記載なし |
| Discover Sources の候補件数 | 2025 年 1 月アナウンスの「最大 10 件」が現行値か、時期で変動するかは未明記 |
| Discover Sources の利用回数上限 | 上限の存在自体が公開ヘルプに明記なし（無料・有料の差も含めて未確認） |
| Deep Research の利用回数上限 | 同上 |
| Web URL ソースの自動再取得（refresh） | 元ページ更新時の追従挙動が公式ヘルプに明記なし |
| Google Drive 連携の同期反映 | Drive 上の更新が NotebookLM 側に同期されるかが公式ヘルプで確認できない |
| ソースの移動・コピー・統合の公式 UI | 公式ヘルプで明示の手順記述が確認できない |
| スタジオ アーティファクトの自動再生成 | ソース構成変更時にマインドマップ・ブリーフィング資料・学習ガイド等が自動再生成されるかが公式ヘルプに明記なし。再生成が必要な場合は手動でやり直す前提で運用する |
| Featured Notebooks の提供地域 | 地域限定の旨は公式に記述あり、対象地域の具体名や時期は未明記 |
まとめ — 上限を起点に粒度を逆算し、4 軸で切って Discover / Deep Research を初手に置く
本記事のフローを 5 段で振り返る。第 1 に、ノートブックの粒度設計は「テーマ名から決める」のではなく「Free 50 / Plus 100 / Pro 300 / Ultra 600 のソース上限から逆算する」順序で進める。1 ノートブックの埋まり具合を 70〜80% 程度（Free なら 35〜40 ソース）に保つ運用が、上限到達と再編成の発生を抑える。第 2 に、サービス別・目的別・プロジェクト別・時系列の 4 分割軸を持っておけば、インフラ業務の素材はおおよそカバーできる。第 3 に Discover Sources は「最大 10 件のソース候補を Web から拾う」初手として、第 4 に Deep Research は「複数ページを統合した分析レポートを 1 ソースとして生成する」初手として位置づけ、両者を補完関係で使う。第 5 に、ソースの「移動」公式 UI が確認できない都合上、再編成は再追加と元削除の手作業になる。Featured Notebooks をテンプレート観察対象として 2〜3 件眺めると、自分の粒度判断の比較材料が増える。
本シリーズの「ノートブック設計論」は、機能の問題ではなく上限と粒度の問題として整理した。最初に上限を意識して粒度を置けば、後から発生する再編成の手間が減る。Deep Research の 18 歳以上限定や、Web URL / Google Drive の自動再取得が公式に明記されていない範囲を踏まえて、断定せずに運用設計するのが現実的な立て付けとなる。技術書 1 冊をフローで完走する運用は 技術書 1 冊を完走する NotebookLM 学習フロー、英語素材を日本語アウトプットで扱う運用は 英語の技術ドキュメントを日本語で読み解く、生成済みの音声概要を移動中に消費する運用は 通勤・移動中の Audio Overview 運用、スタジオの各アーティファクトの使い分けは マインドマップ・要約・学習ガイドで学びを構造化する Studio 活用 でそれぞれ詳しく扱う。
