NotebookLMとObsidianで「仮想社員」を作る手順｜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機能またはカスタムインストラクションが使えるプラン）

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

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

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

確認：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更新後にドライブ同期とソース入替を行う

運用と限界

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

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

第二に、知識ベースの鮮度を保つ。 古い資料のまま運用すると、仮想社員は古い基準で答え続ける。 Obsidian側を更新したらGoogleドライブへ同期し、NotebookLMのソースも入れ替える。

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

よくある質問

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

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

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

まとめ

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

出典

関連記事

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