はじめに

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コネクトではサービス開発支援や技術支援をはじめ、幅広い支援を行っておりますので、何かありましたらお気軽にお問合せください。

お問合せ: https://gmo-connect.jp/contactus/