はじめに
GMOコネクトの永田です。
「NotebookLMは便利だけど、機微な情報を扱えない...」
そんな悩みを持つ方に朗報です。NotebookLM相当の機能を完全ローカル環境で実現するOSSプロジェクト「Open Notebook」があります。
本記事では、Github Copilotと共にOpen Notebookの内部実装を調査し、以下を明らかにします：
- どのLLMモデルをどう使い分けているか
- なぜローカル環境でも高速に動作するのか
- ChatとAskの処理フローの違い
ollama環境での実際の構築手順も含め、技術的な仕組みを詳しく解説します。
最初にまとめ
- Open NotebookはNotebookLMのOSS代替として、完全ローカル環境で動作可能
- 3種類のモデル設定（Chat、Transformation、Embedding）が必要だが、ollamaには2種類のLLMで済む（ChatとTransformationは共有可能）
- Insightsは元ソースをSPRで圧縮要約したもので、Chatの高速化に貢献
- ChatとAskの使い分けが重要：Chatは軽量・高速、Askは高精度だがローカルLLMには負荷が高い
- 機微情報を扱う業務では、ローカルLLM（ollama）との組み合わせで完全プライベートな環境を構築できる
Open Notebookとは
Open Notebookの概要
公式ページはこちらです。
A private, multi-model, 100% local, full-featured alternative to Notebook LM
って、めっちゃNotebook LMを意識していますね。
githubの説明から比較表を日本語にして転記します。（これが一番分かりやすかった）
🆚 Open Notebook vs Google Notebook LM 比較表
| 特徴 (Feature) | Open Notebook | Google Notebook LM | メリット (Advantage) |
|---|---|---|---|
| プライバシーと制御 | セルフホスト、データは自分のもの | Googleクラウドのみ | 完全なデータ主権 |
| AIプロバイダーの選択 | 16以上のプロバイダー (OpenAI, Anthropic, Ollama, LM Studio等) | Googleモデルのみ | 柔軟性とコストの最適化 |
| Podcastの話者 | カスタムプロファイルで1〜4人 | 2人のみ | 圧倒的な柔軟性 |
| コンテキスト制御 | 3段階の詳細なレベル設定 | すべてかゼロか (All-or-nothing) | プライバシーとパフォーマンスの調整 |
| コンテンツ変換 | カスタムおよび組み込み機能 | 限定的なオプション | 無制限の処理能力 |
| APIアクセス | フルREST API | APIなし | 完全な自動化 |
| デプロイ方法 | Docker、クラウド、またはローカル | Googleホストのみ | どこにでもデプロイ可能 |
| 引用 (Citations) | ソースを伴う包括的な引用 | 基本的な参照のみ | 研究の完全性 |
| カスタマイズ性 | オープンソース、完全にカスタマイズ可能 | クローズドなシステム | 無限の拡張性 |
| コスト | AI使用料のみ支払い | 月額サブスクリプション + 使用料 | 透明性が高く管理可能なコスト |
Ollama などのローカルLLMと組み合わせて、完全ローカルなNotebook環境を作れるのが、一番のメリットですね。
機微な情報なので、ってことでNotebookLMを初めとしたクラウドSaaSが使えない業務もまだまだあるので、これは期待できます😊
Open Notebook + ollama環境の構築
さて、調査にあたってまずはローカルでOpen Notebookを準備します。
試した環境は以下です。
- Apple M4 Max 36GB, macOS 26.1
- docker + docker-composeインストール済み
ollamaのインストールとモデルの取得
ollamaのインストールと起動自体はbrewでさくっと終わるので説明は省略します。
Open Notebookでは、3種類のデフォルトモデル設定（Chat Model、Transformation Model、Embedding Model）が必要です。
しかし、ollamaに登録するLLMモデルは2種類で十分です。なぜなら、ChatとTransformationは同じLanguage Modelを使い回せるためです。
ollamaでのそれぞれのお勧めは、公式のgitに記載がありますので参考にしてください。
今回、私は以下の2種類のLLMモデルをollamaにダウンロードしました。
| ollamaに登録するLLM | モデル名 | Open Notebookでの用途 |
|---|---|---|
| Language Model | gpt-oss:20b | Chat Model + Transformation Model として利用 |
| Embedding Model | mxbai-embed-large | Embedding Model として利用 |
curl http://localhost:11434/api/tags でモデル一覧が取得できれば、ollamaの準備は完了です。
（ ollama の待受けを 127.0.0.1:11434 ではなく 0.0.0.0:11434 のように全許可にする必要があるという解説もありましたが、私の環境では 127.0.0.1 のデフォルトのままで動作しました。）
Open Notebookのdocker-compose起動
公式gitにdocker-compose yamlが用意されていますが、git cloneしてbuildする必要はないので、dockerhub公開されているイメージを使うように少し変更します。
修正後のdocker-compose.yml
services:
open_notebook_single:
image: lfnovo/open_notebook:v1-latest-single
ports:
- "8502:8502" # Next.js Frontend
- "5055:5055" # REST API
env_file:
- ./docker.env
volumes:
- ./notebook_data:/app/data # Application data
- ./surreal_single_data:/mydata # SurrealDB data
restart: always
また環境変数ファイルも最低限の内容で準備します。
docker.env
# use ollama
OLLAMA_API_BASE=http://host.docker.internal:11434
# Long timeouts for Ollama (large models take time)
API_CLIENT_TIMEOUT=600
ESPERANTO_LLM_TIMEOUT=300
# DATABASE CONFIGURATION
SURREAL_URL=ws://localhost:8000/rpc
SURREAL_USER=root
SURREAL_PASSWORD=root
SURREAL_NAMESPACE=open_notebook
SURREAL_DATABASE=local
-
OLLAMA_API_BASEでhost.docker.internalとすることで、docker host(=macOS)のollamaに接続できます。（localhostだとdocker container内になり接続できません。） - ローカルLLMのレスポンスはまだ良くないので、タイムアウトを延ばしています
- その他は公式のQuickStartにおおよそ沿っています
Open Notebookの起動
普通にdocker-compose を起動( docker compose up -d )すれば大丈夫です。
その後、ブラウザで http://localhost:8502/ を開くとアクセス可能です。
Open NotebookのModelsと機能の関係
Open Notebookで利用するModels
最初に起動した時、Open Notebookで利用するモデルの選択が必要です。
左メニューのMANAGE --> Modelsで設定が可能です。
最初これをみた時、それぞれ何に使うんだろう？と不明だったのが、今回の調査の動機の1つでもあります。
用語の整理:
- AI Provider: LLMの提供元（今回はollamaのみを使用）
- LLMモデル: ollamaに登録した具体的なモデル（gpt-oss:20b、mxbai-embed-large）
- モデル種別: Open Notebookでの役割（Chat、Transformation、Embedding）
画面を見ると分かる通り、必須項目が赤字の*になっており、Chat Model、Transformation Model、Embedding Modelの3つのデフォルト設定が必要です。
その下に、Language Models（Chat, transformations, and text generation）とEmbedding Models（Semantic search and vector embeddings）があり、ここでAI Providerとモデルを登録します。今回はollamaのみを使用し、以下のように設定しました：
- Language Models: ollama の gpt-oss:20b を登録
- Embedding Models: ollama の mxbai-embed-large を登録
登録したLanguage Modelは、Chat ModelとTransformation Modelの両方で選択できます。つまり、1つのLLMモデルを2つの役割で使い回せるため、ollamaに登録するLLMは2種類で済むわけです。
（正確には、Text-to-Speechと、Speech-to-Textもありますが、今回はスコープ外）
ということで、Chat Model、Transformation Model、Embedding Modelがどこで使われているか、Github Copilotと一緒に調査した結果がこちらです。
| モデル種別 | 主な役割・利用機能 | 代表プロンプト |
|---|---|---|
| Chat(※1) | ノート/ソースチャットの応答生成 | prompts/chat.jinja, prompts/source_chat.jinja |
| Transformation | 変換・抽出・ソース取り込み時のInsights（洞察、要約といった意味）生成 | migrations/5.surrealql（Analyze Paper / Key Insights / Dense Summary / ほか）(※2) |
| Embedding | ソース取り込み時のベクトル化、Ask/Searchでの動的ベクター検索時 | — |
(※1) 一定以上のトークン長（約105,000以上）の場合、自動で Large Context Model に切替え
(※2) Transformationはソースの取り込みでも使われますが、利用者が任意のカスタムプロンプトを追加してソースの要約（Insights）としても利用可能（設定画面は以下）
Model単位で、ざっくりと役割分担が理解できたところで、Open Notebookの主要な機能単位で、Modelがどう使われているか見ていきます。
Open Notebook機能単位でのModel利用状況
調査結果をサマリーでまとめると、こんな感じです。
| 機能 | 使用モデル | 処理フロー | プロンプト | コンテキスト取得 | 特徴 |
|---|---|---|---|---|---|
| ソース取り込み | Transformation + Embedding | ソース追加 → Transformation適用（Dense SummaryでInsights作成）＋ ベクトル化 | migrations/5.surrealql のDense Summaryなど | — | 複数変換の並列実行可能、保存時に自動ベクトル化 |
| Chat with Source | Chat | ソース選択 → コンテキスト生成 → Chat応答 | prompts/source_chat.jinja | 事前構築（ベクトル検索なし） | ソース特定の引用指示 |
| Chat with Notebook | Chat | ユーザー入力 → コンテキスト生成（複数ソース） → Chat応答 | prompts/chat.jinja | 事前構築（ベクトル検索なし） | 過去会話履歴を考慮、複数ソースの統合 |
| Ask & Search | Chat + Embedding | Stage 1: 検索戦略生成 → Stage 2: ベクトル検索＆並列回答 → Stage 3: 最終統合 | prompts/ask/entry.jinja, prompts/ask/query_process.jinja, prompts/ask/final_answer.jinja | 動的ベクトル検索（実行時） | 3段階フロー、並列処理、厳密な引用管理 |
Notebookでのチャットの回答で、ベクトル検索をしているのかと想像していましたが、事前に要約された「インサイト」を使っている点は調査してみて初めて知りました。
いくつかの機能について、実際の画面を見ながら確認してみます。
ソース取り込み
Create -> Sourceで作成が可能です。もしくはNotebookのAdd New Sourceからでも追加が可能です。
URL Link or ファイルアップロード or テキスト貼り付け、が選べます。
ファイルアップロードは以下の拡張子に対応しているようです。
Select multiple files to batch import. Supported: Documents (PDF, DOC, DOCX, PPT, XLS, EPUB, TXT, MD), Media (MP4, MP3, WAV, M4A), Images (JPG, PNG), Archives (ZIP)
次に紐付け先のNotebookを選択できます。これは後でも紐つけや解除が可能です。1つのソースを複数のNotebookで共通化できる点は、NotebookLMと比べて、少し便利かも？と思った点です。
最後にTransformationとEmbeddingが出てきて、先ほどのサマリーの通りのモデルが使われていそうなことが確認できました。
せっかくなので、デフォルトのDense Summaryのpromptを眺めてみます。
Sparse Priming Representation (SPR) がやりたいことのポイントですね。
SPRの詳細は解説記事をみてください。元のソースの文脈を維持しつつ最小限のフレーズで表現することを目指しているようです。
さて、ソースの取り込みが終わると以下のように表示され、Insights 1件とEmbeddingが行われていることが確認できます。1つのソースに対して、複数のInsightsが紐づけられるのは、NotebookLMには無い概念ですね。
ソースをクリックすると詳細画面が表示され、ここに取り込んだコンテンツや生成したInsightsが参照できます。
また、ここから該当ソースに対して、直接Chatもできます。
Insightsは後でも追加できます。
作成されたDense Summaryを見てみましょう。
元にしたページが以下なのですが、かなりぎゅっと要約されているのが分かると思います。
Chat with Notebook
次に、今回のメイン機能のNotebookを見ていきます。
一番左のソースで、情報元を選択可能です。また、ソース毎に青やオレンジのアイコンが見えますが、これはLLMのコンテキストへのソースの渡し方を示しています。
- 青いアイコン --> コンテンツをそのまま利用
- オレンジのアイコン --> Insightsの内容を利用（デフォルト）
- 灰色のアイコン --> 対象外
ソースの状態によってLLMのコンテキストへの渡し方をユーザーが選べるのもNotebookLMには無い観点です。
とは言え、コンテンツが長いとそもそも入りきらなかったり、処理に時間がかかるので、元ソースの状態によって検討は必要そうです。
一番左のところで、チャットで質問などが可能です。
今回は2つのソースを入れた状態で、以下のpromptで聞いてみます。
以下を簡潔にまとめる
(1) gpt-4oと比べたllm-jp-3.1-13b-instruct4の特徴
(2) instruct4の特徴
回答がMarkdownのrawなのはちょっと見辛いですね・・・
以下、回答内容そのまま転記したものです。
(1) llm‑jp‑3.1‑13b‑instruct4 と GPT‑4o との比較
| 項目 | llm‑jp‑3.1‑13b‑instruct4 | GPT‑4o（OpenAI） |
|---|---|---|
| モデル規模 | 13 billion パラメータ、40 層、hidden size 5120 | 約 175 billion パラメータ（推定） |
| トークナイザー | Unigram‑byte fallback（SentencePiece から派生） | GPT‑4o は OpenAI 独自の Byte‑Pair‑Encoding など |
| トレーニングデータ | 2.5 T トークン（日本語・英語・コード・中国語・韓国語） → 2.1 T は事前学習、400 B は指示‑応答ペア（SFT） |
主にインターネット・書籍・対話データの混合、数百 T トークン |
| 指示学習 | ① SFT（日本語・英語の 20+ データセット） ② DPO（Qwen‑2.5‑32B‑Instruct での採点） |
内部の指示最適化（RLHF）を実施 |
| 多様性・安全性 | ① Safety score 4.17、Acceptance 82.4 %、Violation 12.2 %（AnswerCarefully‑Eval） ② DPO で安全データを含める |
公式評価なし（OpenAI が独自に検証） |
| パフォーマンス | MT Bench: 日本語 7.37、英語 7.01（GPT‑4o‑2024‑08‑06 と同等） | GPT‑4o のベンチマークスコアは公開されていないが、実務で優れた応答を示す |
| ライセンス | Apache‑2.0 | Proprietary（商用ライセンス） |
| 利用コスト | オープンソースで自前ホスト可 | API 利用料金が発生 |
Source: llm‑jp‑3.1‑13b‑instruct4 のドキュメント（source:q52al36byl2u21n4n9xg）
(2) instruct4 の主な特徴
| 項目 | 内容 |
|---|---|
| モデルアーキテクチャ | Transformer‑based causal LM, 13 billion パラメータ、40 層、40 attention heads、4096‑token コンテキストウィンドウ |
| モジュール化 | 8‑expert Mixture‑of‑Experts (MoE) で 73 billion パラメータ（2 active experts per step） |
| トークナイザー | llm‑jp‑tokenizer‑v3.0 の Unigram‑byte fallback |
| トレーニングパイプライン | 1. Pre‑training: 2.1 T トークン 2. Mid‑training: 400 B instruction‑response ペア（SFT） 3. Post‑training: SFT + DPO（Qwen‑2.5‑32B‑Instruct で採点） |
| SFT データセット | 20+ 日本語/英語のデータセット（例: ichikara‑instruction‑004‑002, AnswerCarefully, wizardlm8x22b‑logical‑math‑coding‑sft‑ja など） |
| DPO 手法 | ① 生成した複数応答を採点 ② 高スコアを Positive、低スコアを Negative として再学習 ③ 2 階段目で安全データを組み込み |
| 評価 | MT Bench（GPT‑4o‑2024‑08‑06）と同等のスコア AnswerCarefully‑Eval で高い安全性と受理率 |
| ライセンス・利用 | Apache‑2.0 でオープンソース。Python で簡単にロードできる（例: transformers.AutoModelForCausalLM） |
| 推奨環境 | torch≥2.3.0, transformers≥4.40.1, tokenizers≥0.19.1, accelerate≥0.29.3, flash‑attn≥2.5.8 |
Source: llm‑jp‑3.1‑13b‑instruct4 のドキュメント（source:q52al36byl2u21n4n9xg）
これらの点が、llm‑jp‑3.1‑13b‑instruct4 と GPT‑4o との違い、そして instruct4 の特徴です。
ちゃんとソースを元に回答してくれていそうですね！
Ask & SearchのAsk(beta)
最後にAsk(beta)を見てみましょう。
モデル選択に、Strategy、Answer、Finalと3つあり、複数のプロセスに分けて処理が行われていそうなのが分かります。
さて結果をChatと比較してみましょうと思いましたが、Processing your question... のまま処理が終わりません。
MacbookProのgpt-oss:20bには荷が重たかったかもしれません😇
ので、とりあえずソースコードから処理シーケンスをCopilotと追ってみました。
Askの処理シーケンス
特性:
-
3段階フロー: 戦略策定(entry.jinja) → Query処理(query_process.jinja) → 最終統合(final_answer.jinja)
- それぞれのpromptはgit参照
- https://github.com/lfnovo/open-notebook/tree/main/prompts/ask
-
動的ベクトル検索: 実行時に質問に応じて
vector_search()を実行 - 複数LLM呼び出し: Strategy生成（1回）+ 並列Answer生成（N回）+ 統合（1回）
- 並列処理: 複数search termへの答え生成は並列実行可能
うーん、MacbookPro程度のローカルLLMでは、きつそうな処理ですね。
クリスマスプレゼントに DGX Spark を期待するしかありません😊
Ask機能がローカルLLMで重い理由とChatとの使い分け
Ask機能の3段階フローは、質問内容に応じて動的にベクトル検索を行うため、Chatよりも高精度な回答が期待できます。しかし、その分処理負荷も大きくなります：
- Chat: LLM呼び出し1回、事前構築されたコンテキストを利用（軽量・高速）
- Ask: LLM呼び出し1+N+1回（Strategy生成 + N個の並列Answer生成 + 最終統合）+ ベクトル検索
今回のローカル環境（gpt-oss:20b）では、この複数回のLLM呼び出しが処理時間の限界を超えてしまったようです。
使い分けの指針:
- Chat: Notebook内の既知のソースから会話形式で情報を引き出したい時
- Ask: 広範囲なソースから特定の情報を検索・抽出したい時（OpenAI/Anthropic等のクラウドLLM推奨）
まとめ
- Open NotebookはNotebookLMのOSS代替として、完全ローカル環境で動作可能
- 3種類のモデル設定（Chat、Transformation、Embedding）が必要だが、ollamaには2種類のLLMで済む（ChatとTransformationは共有可能）
- Insightsは元ソースをSPRで圧縮要約したもので、Chatの高速化に貢献
- ChatとAskの使い分けが重要：Chatは軽量・高速、Askは高精度だがローカルLLMには負荷が高い
- 機微情報を扱う業務では、ローカルLLM（ollama）との組み合わせで完全プライベートな環境を構築できる
最後に、GMOコネクトではサービス開発支援や技術支援をはじめ、幅広い支援を行っておりますので、何かありましたらお気軽にお問合せください。