notebooklm-mode

NotebookLM に基づく調査パイプライン

ソースに基づいてトピックを調査します。引用文をそのまま収集し、セマンティック検索用にインデックスを作成したうえで、それらのソースに基づいて質問に回答し、成果物を作成します。NotebookLM に着想を得ています。

トリガー

• ユーザーが「ソースに基づいて」トピックを調査するよう依頼する
• ユーザーが「notebooklm mode」、「source-grounded」、または「vault mode」と言及する
• ユーザーが一般知識ではなく、収集したソースを引用した回答を求める
• ユーザーが収集したソースから成果物を作成するよう依頼する

---

モード

ダイレクトモード（デフォルト）

オーケストレーターがすべての役割をインラインで実行します。サブエージェントは使用しません。ほとんどのトピックで使用します。

サブエージェントモード（任意）

本当に必要な場合に限り、delegate_task を通じてエージェントを起動します。異なるサブトピックを並行して調査する場合、またはユーザーから明示的に依頼された場合が該当します。ソース数だけを理由に起動することはありません。作業が本当に並行している場合、またはユーザーが分離を求める場合に切り替えます。

delegate_task(
  goal="<user's request>",
  context="You are the [Research|Response|Output] Agent in a NotebookLM
           pipeline. Vault path: <vault_path>. Load skill 'notebooklm-mode'.
           Your role: [Research|Response|Output]. Topic: <topic>.
           Grounding mode: [strict|augmented].",
  toolsets=[<appropriate toolsets per role>]
)

順序：調査 →（ユーザーが確認）→ 回答 →（ユーザーが依頼）→ 出力。 前のエージェントが戻り、ファイルが検証される前に、依存するエージェントを決して起動しないでください。

根拠付けモード

モード	動作
厳格（デフォルト）	Vault のみを使用します。Vault にない情報は把握していないものとします。不足情報を特定しますが、推論で補うことはありません。
拡張	まず Vault を使用します。一般知識も使用できますが、[background] と明示的にタグ付けし、Vault 由来の主張とは明確に分ける必要があります。ユーザーが明示的にこのモードを依頼します。

拡張モードの例：

Source #3 によると：「LTCI system covers 95% of seniors」[vault]

[background] LTCI は、2000 年に日本の介護保険改革の一環として導入されました。

---

共通ルール（両モードのすべての役割に適用）

• 引用は原文どおりに限る：ソースファイルには正確な文言をそのままコピーします。有料記事で要約しか入手できない場合に限り、[paraphrased] と記します。ページ全体の取得に失敗した場合は、[reconstructed from search snippets] と記します。
• すべてに出典を付ける：Vault の情報に基づく事実の主張はすべて、特定のソースファイルを参照し、可能な場合は出典を示した原文引用を添えます。
• 矛盾を正直に示す：ソース間で見解が異なる場合は、出典を付けて両方を提示します。どちらか一方を裁定しないでください。
• 情報の不足は結論ではありません：「Vault に X の情報がない」は問題ありませんが、「したがって X はおそらく Y である」は禁止です（厳格モード）。拡張モードでは [background] とタグ付けする必要があります。
• 秘密情報を除去する：Vault や出力に保存する前に、ソースの内容をスキャンし、API キー、トークン、認証情報を取り除きます。
• ソースファイルに既存知識を加えない：誤りだと思われる場合でも、ソースをそのまま記録します。評価は回答の役割で行います。

---

ワークスペース Vault

Vault はユーザーの調査専用に作成する一時的なワークスペースディレクトリであり、恒久的なライブラリの一部ではありません。調査トピックごとに、ソースの抜粋、コーパス単位の RAG インデックス、出力を保存します。調査が完了したら削除するか、ユーザーが保存を希望する場合はアーカイブします。

最初のやり取りでは、必ず Vault の場所を確認してください：

「ワークスペースはどこに作成しますか？デフォルト：<project_folder>/research-<topic>/」

ワークスペースは、調査セッションの作業ディレクトリとして機能します。ユーザーは接続済みの任意のチャネル（Telegram、WhatsApp など）からソース資料を提供できます。エージェントはそれらを sources/ に保存し、次のやり取りでインデックスを作成します。ユーザーが VM のファイルシステムに直接アクセスする必要はありません。

出力の納品も同様に行います。エージェントは、ユーザーが指定したチャネルを通じて、完成した成果物を送り返します（例：ファイルは Telegram MEDIA、メモはインラインの Markdown）。

構成

<vault_path>/
├── vault_index.md          # Catalog of sources + outputs
├── sources/                # Verbatim source extracts (one file per source)
│   └── 001_title.md
├── rag_index.db            # Per-corpus sqlite-vec DB (semantic search)
└── outputs/                # Agent-generated deliverables
    └── notes_YYYY-MM-DD.md

ソースファイル形式

# Source Title

| Field    | Value                     |
|----------|---------------------------|
| URL      | https://example.com/page  |
| Author   | Author Name (if known)    |
| Date     | Publication date (if known) |
| Retrieved| YYYY-MM-DD                |
| Type     | web / pdf / user-provided / youtube |

## Extracts

> "Verbatim quote from the source."
> — Section: Introduction

## Key Data Points

- Statistic: 42% of respondents... (Section: Results)

• Webサイトの場合は、URLだけでなく実際のコンテンツを抽出します
• 長すぎる場合は、関連する箇所を抽出し、省略した内容を記載します
• ファイルには連番を付けます：001_、002_ など
• ユーザー提供ファイルの場合は、Type を user-provided に設定し、URL は空欄にします
• 原文どおりではない抜粋には、[paraphrased]（有料記事、要約のみ）、[reconstructed from search snippets]（ページ全体の取得に失敗）というマーカーを付けます

vault_index.md

# Workspace Vault Index
**Topic:** [topic] | **Created:** YYYY-MM-DD | **Sources:** N | **Mode:** [strict|augmented]

## Sources
| # | File | Type | Title | Retrieved |
|---|------|------|-------|-----------|
| 1 | 001_title.md | web | Article Title | YYYY-MM-DD |

## Coverage Notes
- Well covered: [list] | Gaps: [list]

## Outputs
| File | Type | Created |
|------|------|---------|
| notes_YYYY-MM-DD.md | notes | YYYY-MM-DD |

ユーザー提供の資料

ユーザーは、接続済みの任意のチャネル（Telegram、WhatsApp など）を通じて、いつでもファイルを提供できます。エージェントはファイルを sources/ に保存してインデックスを作成し、vault_index.md を更新してから、ユーザーに確認します。VM に直接アクセスする必要はありません。

---

コーパスごとのセマンティック検索（任意）

各ワークスペース内に、新しい rag_index.db が新規作成されます。これは library-rag と同じ bge-m3 埋め込みを使用する、スタンドアロンの sqlite-vec データベースですが、この調査コーパスだけを対象とします。調査トピックごとに別々のワークスペースフォルダーを用意し、それぞれに独立した DB を置きます。~/.hermes/library/rag_index.db にあるメインライブラリ DB には決してインデックスを作成しません。

これは任意です。 このスキルはなくても動作します。小規模なボルトであれば、ファイルを直接読み込めば十分です。コーパスが大きくなるほど（20 件以上のソース）、セマンティック検索の有用性が高まります。library-rag が利用できない場合、ingest_source.py はファイルの書き込みのみを行い、インデックス作成をスキップします。

アトミックな取り込み（1 回の呼び出しで書き込み＋インデックス作成）

同梱の ingest_source.py スクリプトを使用すると、ソースファイルの書き込みと、ボルトの RAG DB へのインデックス作成を（RAG が利用可能な場合）アトミックに実行できます。これにより、性能の低いローカルモデルでは気付かないうちに失敗することがある、保存後にインデックスを作成するという 2 段階の処理をなくせます。

Python API：

import sys; sys.path.insert(0, "<skill_dir>/scripts")
from ingest_source import ingest, search_vault, reindex_vault

# Write + index atomically
result = ingest(vault_path, "001_title.md", content)
print(f"Indexed {result['chunks_indexed']} chunks")

# Semantic search over the vault
results = search_vault(vault_path, "your query", top_k=5)
for r in results:
    print(f"[{r['similarity']:.0%}] {r['source_file']} — {r['section_title']}")
    print(f"  {r['chunk_text'][:200]}")

# Reindex all sources (e.g., after user drops files manually)
reindex_vault(vault_path)

CLI：

# Write + index
python3 <skill_dir>/scripts/ingest_source.py \
  --vault <vault_path> --file 001_title.md --content "..."

# Reindex all sources
python3 <skill_dir>/scripts/ingest_source.py --vault <vault_path> --reindex

# Search
python3 <skill_dir>/scripts/ingest_source.py \
  --vault <vault_path> --search "query" --top-k 5

このスクリプトは、library-rag のスクリプトを次の順で解決します。LIBRARY_RAG_SCRIPTS 環境変数、次に Hermes のスキルレイアウト、最後にリポジトリ相対のフォールバック（例：隣接する library-rag/scripts または research/library-rag/scripts）です。そのため、このリポジトリをそのままクローンすれば、環境変数なしで動作します。MCP への依存はなく、直接インポートします。

使用する場面

• 応答 — すべてのソースファイルをコンテキストに読み込む代わりに、ボルトをセマンティック検索します。大規模なボルト（20 件以上のソース）で特に有用です。
• 出力 — 成果物を作成する前に、テーマに関連するすべての箇所を探します。

小規模なボルト（ソースが 5 件未満で、文書も短い場合）では、ファイルを直接読めば十分です。コーパスが大きくなるほど、セマンティック検索の有用性が高まります。

---

ロール

リサーチ（情報収集）

目的： オンラインで調査し、出典を見つけ、原文の抜粋を抽出して、Vault に追加します。

ツール： web_search、web_extract、browser、terminal（ingest_source.py 用）

動作：

1. トピックが広い場合は、範囲を明確にします
2. リサーチを計画する — トピックを3〜6個のサブクエスチョンに分け、成功基準（包括的に調査できた状態とはどのようなものか）を定義します。この計画は検索戦略の指針となり、ギャップ分析の段階で検索を終了するか判断する基準になります。
3. 日付の確認（必須） — 検索を始める前に、実際の現在の日付を確認します。「Today's date is {current date as 'DD Month YYYY'}. When a search query needs a year or refers to 'latest'/'current'/'this year', use {current year} — never a year inferred from training data.」を挿入します。これにより、学習データのカットオフ年に基づく古い年を検索クエリに使用するのを防ぎます。
4. 信頼性が高く、多様で、最近の出典を検索します — ステップ2のサブクエスチョンを対象にクエリを作成します
5. 品質フィルター — 抽出する前に、品質の低い検索結果を除外します：
   • 内容が薄い：ランディングページ、アグリゲーターの簡易ページ、実質的なテキストが100語未満
   • 関連性がない：トピックとの関連性がなく、キーワードが重複しているだけのもの（部分文字列ではなく、単語境界で一致するもの）
   • URL の重複：複数の検索結果に同じページが表示されているもの
   • テキスト以外：動画のみのページ、画像掲示板、プレビューのないログイン画面
6. 全文を取得し、関連する箇所を選んで、出典の内容に原文のままコピーします
7. 一括取り込み — ingest_source.py を使って、1回の呼び出しで各出典を書き込み、インデックス化します。追加のたびに vault_index.md を更新します。
8. ギャップ分析 — 最初の検索後、調査計画に照らして調査結果を確認します：
   • 未回答のサブクエスチョンはどれですか？調査範囲が薄いものはどれですか？
   • ギャップに対応する追加クエリを作成し、もう一度検索します
   • 合計3回まで検索を繰り返します。残ったギャップは vault_index.md の「Coverage Notes」に記録します
9. 終了基準 — 次のいずれかに該当したら検索を終了します：
   • すべてのサブクエスチョンに、それぞれ1件以上の関連出典がある
   • 検索を3回実施した
   • 20件の出典を収集した（範囲の上限）
   • ギャップが残る状態で終了する場合は、「Coverage Notes」に明記します。推論で埋め合わせてはいけません
10. 見つかったテーマ（内容ではなく）を報告し、さらに詳しく調査するかユーザーに尋ねます
11. 出典を5〜20件収集した時点で終了します（範囲による）。調査範囲が十分か確認します

回答（根拠に基づく回答者）

目的： Vault の情報をもとに質問に回答します。Vault はナレッジベースです。

ツール： read_file、terminal（search_vault 用）

動作：

1. まず vault_index.md を読みます。大規模な Vault の場合は、すべてのファイルを読み込まずに search_vault() を使います。
2. Vault の内容を使って回答します。次のように出典を明記します：「出典 #3 によると：…」
3. 回答する前に、ユーザーが提供した未インデックスのファイルがないか確認します（新しいファイルが見つかった場合は reindex_vault を実行します）
4. Vault に質問の答えが含まれていない場合：
   • 厳密モード：ギャップを明示し、リサーチ用プロンプトを提案します。結論をほのめかしてはいけません。
   • 拡張モード：ギャップを明示し、リサーチ用プロンプトを提案したうえで、必要に応じて Vault の主張とは明確に区別した [background] の背景情報を提示します。
5. 出典が矛盾している場合は、どちらも提示します。どちらが正しいかを判断してはいけません
6. 内容のある回答は、出典を付けて outputs/notes_YYYY-MM-DD.md に保存します

出力（作成者）

目的： 利用可能なツールを使って、Vault のコンテンツから成果物を作成します。

ツール： file、terminal、および出力形式に必要なツール

動作：

1. 受け取る情報：作成するもの、対象範囲、形式、参照するソース
2. 関連する Vault のソースを読み込みます（大規模な Vault では search_vault() を使用します）
3. 適切なツールを使って出力を作成します。エージェントのランタイムにインストールされている、該当する専門スキルに連携します（このリポジトリには含まれていません）。
   • .md → ファイルを直接書き込みます
   • .docx／.pptx／.xlsx → 利用可能であれば、オフィス文書スキルを使用します
   • インフォグラフィック／スライド／雑誌のレイアウト／データレポート／ポスター → 利用可能であれば、対応するデザインまたは作成スキルを使用します。そうでなければ、ユーザーが自身のツールに渡せる構造化された Markdown を作成します
4. 出典の引用（脚注またはインライン）と「Sources」セクションを含めます
5. outputs/ に保存し、vault_index.md を更新します
6. 出力ファイルが存在し、有効であることを確認します

---

ソースの取り込み元

ほかのスキルから Vault にソースファイルを取り込めます。

スキル	取り込み方法	ソースの種類
youtube-topic-research	--export-vault フラグを使うと、レビュー済みの動画を、トランスクリプトの抜粋、映像／デモに関するメモ、メタデータを含む NNN_youtube_*.md ソースファイルとしてエクスポートします	youtube
手動調査	エージェントがウェブからの抜粋を sources/ に直接保存します	web、pdf、user-provided

取り込み元のスキルがソースを書き込んだら、Response／Output の役割で Vault を使う前に reindex_vault() を実行し、Vault の RAG DB にインデックスを作成してください。

オーケストレーターのルーティング

ユーザーの意図	役割	モード
「[トピック]を調査して」、「...のソースを探して」	Research	直接
「Vault には...について何と書かれているか」、「要約して...」	Response	直接
「Vault からスライド／メモ／インフォグラフィックを作成して」	Output	直接
「Vault に何があるか確認して」	Response	直接
「YouTube 動画を探して Vault に追加して」	youtube-topic-research → feeder	直接
「ヨハネの福音書3章16節を学ぶ」、「カルヴァンとともに創世記5章を学ぶ」、「{commentator}は{passage}について何と言っているか」	Research → Response	直接 + references/book-study.md
曖昧な場合 — 調査か回答か	尋ねる：新しいソースを探すのか、既存の Vault に基づいて回答するのか	—

デフォルトでは直接モードを使用します。作業が本当に並列化できる場合、またはユーザーが明示的に分離を求めた場合に限り、サブエージェントモードに切り替えます。

注意点

• 新しいセッションごとに Vault のパスを確認する必要があります — 場所を決めつけないでください
• Vault は一時的なものです — 永続的なライブラリの一部ではありません。作業が終わったらクリーンアップするか、ユーザーが保持を希望する場合はアーカイブしてください。ユーザーから明示的に依頼されない限り、Vault のソースをメインライブラリの RAG にインデックス登録しないでください。
• サブエージェントによるファイル書き込みは信頼できません — サブエージェントの処理が終わったら、必ず ls で sources ディレクトリを確認してください。ファイルがない場合は、自分で再作成してください
• ボット検出により多くのサイトがブロックされます — Wikipedia や政府機関のサイトを優先し、抽出には browser_console を使用してください。再構成した抜粋には [reconstructed from search snippets] と明記してください
• Vault が大きい場合 — すべてのソースファイルをコンテキストに読み込む代わりに、search_vault() を使用してください
• 逐語的とは、文字どおりに、という意味です — ソースの誤字もそのまま保持し、重要な場合は [sic] を付けてください
• 拡張モードの規律 — Vault 以外の知識には必ず [background] タグを付けてください。判断に迷ったら、厳格モードを使用してください。
• クエリの年が古い — 検索前に必ず日付の基準を設定してください。モデルは学習データのカットオフ年を既定で使用するため、時事的なトピックでは無関係な結果が返されます。
• 調査計画を省略する — サブクエスチョンと成功基準がないと、情報収集に方向性がなく、ギャップ分析の基準もありません。検索前に必ず計画を立ててください。
• ギャップ分析を省略する — 1 回の検索では、追加の質問を見落とします。最初の検索後、計画に照らして網羅性を必ず確認し、ギャップに対して的を絞った追加検索を実行してください。
• ギャップを取り繕う — ソースから回答できないサブクエスチョンは、vault_index.md の Coverage Notes にギャップとして記録してください。推論（厳格モード）や、タグのない背景知識（拡張モード）で埋め合わせないでください。
• 書籍の学習には parse_reference.py が必要です — 「John 3:16」を正確な本文に対応させるには、参照解析スクリプト（scripts/parse_reference.py）が必要です。見つからない場合は、セマンティック検索に切り替えてください（精度は低く、誤った章や節の範囲が返される場合があります）。ワークフロー全体については references/book-study.md を参照してください。