ObsidianとNotebookLMの連携手順｜Claudeと組んで「仮想社員」を作る

メモは溜まっているのに、肝心なときに引き出せない。 汎用のAIに聞くと一般論しか返らず、自社の経緯や過去の決定を踏まえた答えにはならない。 この二つの不満は、同じ一つの設計で解けることが多い。

自分の知識を読み込ませた知識ベースに、役割と判断基準を与えた人格を重ね、実務の出力をAIに担わせる。 こうして作る「特定領域だけは自分以上に詳しく、いつでも同じ基準で答えるAI」を、本稿では仮想社員と呼ぶ。 NotebookLM、Obsidian、Claudeを組み合わせると、特別な開発なしにこれを構成できる。

本稿は二部構成をとる。 前半で仮想社員の定義と、なぜこの三層構成になるのかという設計根拠を述べる。 後半は、前提条件、手順、確認、つまずきと対処までを並べた作業手順書として読めるようにする。

要旨

仮想社員は、知識ベース、人格、想起の三層を外部から与えることで、汎用の大規模言語モデルを担当業務に固定した相手に変える構成である。 本稿では、Obsidianを素材の保管庫、NotebookLMを出典付きの検索層、Claudeを実務文章の生成層に割り当てる。 各層の役割と接続手順、運用上の限界を、国内外の公開事例をもとに示す。

前提と用語の定義

議論の対象を先に固定する。

• 仮想社員：特定領域の知識ベースと固定された人格を持ち、同じ基準で反復的に応答するAIの運用形態。
• 知識ベース：その担当が参照する資料の集合。本稿ではObsidian Vaultと、それを取り込んだNotebookLMのソースを指す。
• ペルソナ：役割、専門性、優先順位、答え方を明文化した人格定義。
• 想起：応答のたびに知識ベースを参照し、根拠に基づいて答える動作。

汎用AIが一般論にとどまるのは、知識ベースが自分のものでなく、人格が応答ごとにぶれるからだ。 逆に言えば、この三つを外から与えれば、モデルを再学習しなくても担当業務に固定された相手になる。 Personal AIは、人格（ペルソナ）を「そのテーマについて完全な記憶を持つ仮想従業員」と説明している¹。

設計：なぜ三層に分けるのか

一つのAIに知識も人格も生成も任せると、役割が混ざって品質が安定しない。 そこで役割を三つの道具へ分離する。

NotebookLMは図書館の司書にあたる。 アップロードした資料だけを根拠に、出典付きで情報を探し出す²。 与えたソースしか参照せず、取り込みは最大50件までという制約が、かえって回答の範囲を担当領域に閉じ込める³。

Claudeは書き手にあたる。 司書が集めた素材を、文脈をふまえた実務の文章に変換する役を担う²。

Obsidianは素材の置き場にあたる。 日々のメモ、議事録、調査をためる保管庫（Vault）であり、知識ベースの一次置き場になる。 ノート間のリンクと履歴を保ったまま知識を育てられる点が、単なるフォルダと異なる。

三層に分ける利点は、各層を独立に差し替えられることにある。 担当を増やすときは知識ベースとペルソナだけ用意すればよく、生成層のClaudeは共有できる。

作業手順書

ここからは、実際に構築する手順を順に示す。

前提条件

着手前に次をそろえる。

• Obsidian（デスクトップ版）と、ノートを置くVault
• Googleアカウントと Google ドライブ
• NotebookLM（Googleアカウントで利用可）
• Claude（Projects機能またはカスタムインストラクションが使えるプラン）

ObsidianとNotebookLMを連携する3つの方法

先に選択肢を並べておく。どれを選んでも、NotebookLM側から見れば「ソースとしてファイルを読ませる」点は変わらない。違うのは手間と事故のリスクだ。

方法	手間	反映の速さ	事故のリスク
(1) VaultをGoogleドライブ内に置いて直接同期	最初に置き場所を決めるだけ	ドライブ同期にそのまま乗る	Vault全体が対象になるため、入れたくない資料まで届きやすい
(2) コミュニティプラグインでpush/pull	プラグインの導入と設定が要る	自分でpushしたときに反映	プラグイン側の挙動に依存する
(3) 必要なノートだけ手動でエクスポート	毎回の作業が残る	出した時点で確定	範囲を自分で選ぶため、いちばん事故が少ない

どのつなぎ方が合うかは、Vaultをまるごと渡してよいかで決まる。プラグインを使う場合は、ClaudeとObsidianのつなぎ方を比べるで扱っている接続の考え方も参考になる。

NotebookLMはソースの形式としてMarkdown（.md）を公式にサポートしている。ドライブから取り込んだソースは自動更新され、数分ごとに同期される。必要なら、ソースを開いて「Click to sync with Google Drive」を押して手動で更新することもできる（NotebookLMヘルプ、2026年9月16日時点）。

ただし、NotebookLM側でMarkdownのリンク記法（[[...]]や[text](url)）がどう表示・解釈されるかについては、公式ヘルプに個別の説明がない。ヘルプには「ソースの内容は、分析と理解のために、NotebookLMのビューアでは元のファイルと異なって表示されることがある」という記述があるだけで、元ファイルの書式自体は変更されないとされている。リンク記法の扱いは公式には明示されていないため、運用に入れる前に自分の環境で確かめてほしい。

Claudeをどこで挟むか（連携の3構成）

3つとも使う必要はない。目的で構成を変える。

• Obsidian + NotebookLM：手元の資料から出典付きで調べたいだけなら、これで足りる。
• Obsidian + Claude：出典より、長い文章を書かせることが目的ならこの構成になる。
• 3つ全部：調べる層と書く層を分けたいときに効く。本稿が扱うのはこの形だ。

どちらを選ぶかの判断材料は、NotebookLMとObsidian＋Claudeの使い分けにまとめてある。

手順1：知識ベースを構築する

目的：担当が参照する資料を、NotebookLMが読める場所に集める。

1. Obsidianで、その担当の領域に絞ったVaultを用意する。
2. VaultをGoogleドライブと同期する。新規Vaultの保存先をGoogleドライブ内のフォルダにするか、コミュニティプラグインでpushとpullを行う⁴。
3. NotebookLMで新しいノートブックを作り、ソースとして同期先のGoogleドライブのファイルを追加する⁴。
4. 担当範囲に関係する資料だけを入れる。関係の薄い資料は混ぜない。

Vaultの側をどう作っておくと引きやすいかは、Claudeがノートをひけるvaultのつくり方で扱っている。

確認：NotebookLMのチャットで資料内の固有名を尋ね、出典付きで返ることを確かめる。

手順2：ペルソナを定義する

目的：知識ベースに、誰として何を優先するかという視点を与える。

1. NotebookLMの設定からチャットをカスタマイズする（Chat customization）。
2. 肩書き、専門性、判断基準、答え方を具体的に書く。たとえば「SaaS業界10年のリードプロダクトマネージャーとして、ROIと実装可能性の二点から評価する」のように固定する³。
3. 必要なら、丁寧さより厳しさを優先した人格にする。国内では「性格の悪いベテラン社員」を憑依させ、想定問答を詰めさせるFAQ作成の例も報告されている⁶。

入力上限はかつて500文字だったが、10,000文字へ拡張され、判断基準を細かく書けるようになった⁵。

確認：同じ問いを二度投げ、視点と答え方が安定していることを確かめる。

手順3：NotebookLMとClaudeを連結する

目的：出典付きの検索をNotebookLMに、実務文章の生成をClaudeに分担させる。 公開されている実装例は、次の三段で説明している²。

1. リサーチ設計：どんな切り口で調べるかをClaudeに相談し、NotebookLMへ渡す問いを作る。
2. 知識の構造化：NotebookLMに、原則、フレームワーク、避けるべきパターンといった観点を指定して資料を体系化させる。
3. 人格の実装：構造化した知識をClaudeのProjects機能やカスタムインストラクションに貼り、「この知識ベースを持つ◯◯の専門家」として役割を固定する²。

担当ごとに知識ベースとペルソナを変えれば、複数の仮想社員を並べられる。

完了チェックリスト

• [ ] Vaultが担当領域に絞られている
• [ ] VaultがGoogleドライブに同期され、NotebookLMのソースに入っている
• [ ] NotebookLMが出典付きで答える
• [ ] ペルソナで役割と判断基準が固定されている
• [ ] Claude側に知識ベースとペルソナが設定されている

つまずきと対処

症状	原因	対処
回答が一般論に戻る	担当外の資料が混ざっている	ソースを担当領域に絞り直す
出典が示されない	NotebookLMのソース未設定、または資料に根拠がない	資料を追加するか、断定を避ける運用にする
答え方が毎回ぶれる	ペルソナが曖昧	判断基準と答え方の規則を明文化する
古い基準で答える	知識ベースが更新されていない	Obsidian更新後にドライブ同期とソース入替を行う

連携でつまずく点と対処

症状	原因	対処
画像や添付が反映されない	Vault内の添付ファイルはテキストのソースとして扱われない	必要な内容はノート本文に書き出す
ソースを追加しきれない	ソース件数の上限に当たっている	担当領域の資料に絞る。上限は50件とされているが3、仕様は変わりうるため最新値は公式ドキュメントで確認する
どのソースか見分けられない	ファイル名が日本語や日付のみで内容を表していない	ノート名に主題を入れて識別できるようにする

運用と限界

仮想社員には二つの限界がある。

第一に、出力をうのみにしない。 NotebookLMは与えたソースに基づくとはいえ、要約や言い換えの過程で原文からずれることがある。 重要な判断に使う数値や固有名は、必ず出典のノートに当たって確かめる。

第二に、知識ベースの鮮度を保つ。 古い資料のまま運用すると、仮想社員は古い基準で答え続ける。 Obsidian側を更新したらGoogleドライブへ同期し、NotebookLMのソースも入れ替える。 この入れ替えを手作業で繰り返すのが重いなら、Claude CodeからNotebookLMを操作する方法もある。

Obsidianを素材置き場として育てる発想は、Andrej Karpathyが示した「LLMに知識構造を育てさせる」という考え方とも地続きだ。 人間が保守してたまに質問するのではなく、AIが知識ベースそのものを更新していく流れに寄せると、運用の手間が下がる。

よくある質問

Q. NotebookLMだけでは作れないのか。 A. 作れる。資料とペルソナの二つをソースに入れれば、NotebookLM単体でも担当業務に固定された相手になる⁶。Claudeを足すのは、長文の実務文章や日本語の細かい調整を任せたいときだ²。

Q. Obsidianは必須か。 A. 必須ではない。素材が一か所にまとまっていればよく、Googleドライブのフォルダでも代用できる。Obsidianを使う利点は、ノート間のリンクと履歴を保ったまま知識を育てられる点にある。

Q. ペルソナは何文字くらい書くべきか。 A. NotebookLMの上限は10,000文字に拡張された⁵。すべて埋める必要はなく、役割、専門性、優先順位、答え方の規則を具体的に固定できれば十分だ。

Q. ObsidianとNotebookLMはどうつなぐのが一番簡単か。 A. VaultそのものをGoogleドライブ内のフォルダに置き、NotebookLMのソースとしてそのフォルダのファイルを追加する方法だ。追加の道具がいらない。

Q. Obsidianを更新したらNotebookLM側にも自動で反映されるか。 A. 公式ヘルプによれば、ドライブから取り込んだソースは自動更新され、数分ごとに同期される。すぐ反映させたいときは、ソースを開いて「Click to sync with Google Drive」を押せば手動で更新できる（NotebookLMヘルプ、2026年9月16日時点）。とはいえ、Obsidianからドライブへの同期は別レイヤーなので、更新後はソースの状態を確認する運用にしておくほうが安全だ。

Q. Obsidian、NotebookLM、Claudeの3つとも必要か。 A. 必要ではない。出典付きで調べたいだけならObsidianとNotebookLM、長文の実務文章まで作るならClaudeを足す、という順で考えるとよい。

まとめ

仮想社員は、知識ベースと人格と想起の三層を外から与える設計でできる。 Obsidianで素材をため、Googleドライブ経由でNotebookLMの知識ベースにし、ペルソナで視点を固定し、Claudeで実務の文章に変換する。 特別な開発はいらず、手元の資料と既存ツールの組み合わせで、担当業務に固定された相手を持てる。

出典

関連記事

• ClaudeがノートをひけるObsidian Vaultのつくり方
• ClaudeとObsidianのつなぎ方を比べる（Claude Code直読み / Filesystem MCP / 専用MCP）
• NotebookLMとObsidian＋Claude、いつどっちを使うか
• Claude CodeからNotebookLMを操作｜大量資料を読ませる裏ワザ