論文書く医者のための、壊れない知識ベース：Claude×Obsidianを"入れ子"で進化させた話

結論から言うと、Claude Code × Obsidian で作る「第二の脳」は、論文を書く医者にはそのままでは少し足りない。

足したのは、入れ子（ネスト）構造のナレッジベースだった。

---

1. 論文2本目で、みんな"引用迷子"になる

論文を書いたことがある医師なら、たぶん身に覚えがある感覚がある。

1本目を書き上げた半年後、2本目で似たテーマを扱う。そのとき、こう思う。

• あの論文、どこに置いてあったっけ
• この定義、前に整理したはずなんだけどな
• PubMedで同じ検索を、また最初からやり直すのか……

実はこれ、一次情報（論文・ガイドライン・公式レポート）が"使い捨て"になっているサインだ。PDFを一度ダウンロードして、Word に引用を書いて、投稿して、投稿が終わったらそのPDFは「どこかのフォルダ」に沈む。

次の論文で同じ領域に触れるとき、ゼロから探し直す。専門領域の知識が蓄積されていないわけじゃない。「手元で引用可能な形」ではないことが問題なんだ。

2. Claude×Obsidianの"第二の脳"という概念

この問題の処方箋として、少し前にXで話題になった記事がある。mana さん（@MakeAICEO）の「[今さら聞けない！Claude × Obsidian、これはもう"違法"でしょ](https://x.com/MakeAICEO/status/2043674800888119512)」（2026-04-13 公開）。

要点はシンプル。

• Obsidian（ローカルのMarkdownフォルダ）を知識の箱にする
• Claude Code（AIターミナルクライアント）にその箱を任せる
• 生の情報を投げ込めば、Claude が要約・概念抽出・相互リンクをやってくれる
• 使えば使うほど、自分専用のWikipediaが育っていく

Obsidian Vault とは何か、簡単に補足しておく。Vault は、ローカルの Markdown ファイルの集まりを「保管庫」として扱うだけのシンプルな概念だ。特殊なデータベース形式ではなく、普通の .md テキストファイル。[[ページ名]] 形式の内部リンクとグラフ表示が標準機能で、クラウドに依存せず、フォルダを丸ごと Git 管理できる。Claude Code のような外部ツールも、フォルダパスを指定するだけで読み書きできる。

研究者視点で相性が良いのは、データ主権とツール独立性が担保されている点。Obsidian 社がサービスを止めても、自分の .md ファイルは手元に残る。いつでも別のエディタに移行できる。論文執筆と同じ感覚でバージョン管理ができるので、「変更の履歴を追える知識ベース」を持てる。

この発想の元ネタは、元 Tesla AI責任者カルパシー氏が提唱した「LLM Wiki」。AI自身が管理するWikiという考え方だ。

試してみると、確かに気持ちいい。記事を保存すると、Claudeが要約ページを作り、関連する過去記事とリンクを張ってくれる。

でも、論文執筆には、もう一歩必要だった。

3. 足りなかったのは「スコープ分離」

問題は、論文執筆中の作業と、普段の知識管理を同じ箱でやると、いくつかの摩擦が生じること。

具体的には:

1. 情報衛生: 論文ドラフト段階の仮説や検討中の引用が、恒久的な知識ベースに混入する。半年後に別の執筆をするとき、未確定情報を誤って引用するリスクがある（これが一番深刻）
2. 検索品質: Claude に「この論文の引用を整理して」と頼むと、論文と関係ない雑多な記事も検索対象に入り、回答の焦点がぼやける
3. コスト: Vault 全体を走査する頻度が上がるので、セッションあたりのトークン消費も増える（大規模 Vault で顕在化）

必要なのは、論文プロジェクトごとに独立した小さい知識ベースを作り、完成後に大きい知識ベースへ統合する仕組だった。

4. 入れ子（ネスト）構造の設計図

結論、こういう構造にした。入れ子（ネスト）＝ 大きい箱の中にプロジェクト専用の小さい箱を入れる設計だ。

【本体】Obsidian Vault（恒久的な知識ベース）

└── knowledge-base/

├── raw/ 生データ（PDF・記事クリップ等）

├── wiki/ AIが管理する整理済み知識

│ ├── sources/ 原典要約

│ ├── concepts/ 概念・用語

│ ├── entities/ 人物・組織・ツール

│ └── syntheses/ 検索結果・総合分析

└── KB_SCHEMA.md スキーマ定義

【プロジェクト】D:\development\{論文名}\（執筆用の小さい箱）

├── CLAUDE.md スコープルール（「本体のvaultは検索しないこと」を明記）

├── research/

│ ├── reference/ 論文用PDFのraw

│ └── wiki/ ミニWiki（本体と同じスキーマ）

│ ├── sources/

│ ├── concepts/

│ └── syntheses/

└── .claude/commands/ プロジェクト専用スラッシュコマンド

ポイントは 「小さい箱」のスキーマが「大きい箱」とほぼ同じ こと。昇格（小→大への統合）時、ファイルをコピーしてパスを少し書き換えるだけで済む。

「本体 と プロジェクト をほぼ同じルールで動かす」、これが設計の肝だった。

5. Wikiエコシステムの4層

sources / concepts / entities / syntheses の4つは、役割が明確に違う。最初これが混乱ポイントだった。

論文を書くときは sources と syntheses を多用する。日常業務の知識整理では concepts が主役になる。

ここで注意したいのは、wiki/ の中身を書くのはAIの仕事だということ。人間が直接 sources/ や concepts/ に書き込むことはない。raw/ にPDFや記事を放り込むだけで、AIが自動で4層に整理してくれる。

つまり人間が覚えておくのは「どこに何があるか」だけ。論文の詳細なら sources/、用語定義なら concepts/、過去の総合分析なら syntheses/ を見に行く、という動線さえ掴めば、あとは AI が勝手にメンテしてくれる。

6. スラッシュコマンドの循環サイクル

箱だけあっても動かない。循環させる仕組みが要る。Claude Codeに覚えさせたスラッシュコマンドで、こう流れる。

本体Vault側（日常運用）

この4つで、raw → wiki → 再利用 の循環が回る。

プロジェクト側（論文執筆時）

ポイントは `/research-kb-query`。本体Vaultの知識を論文側に引き込むだけでなく、同時に論文用の syntheses も生成される。論文執筆中、ここに加筆・深化させていく。論文完成時、深化された synthesis が本体Vaultに戻る。

つまり、本体Vaultは論文を書くたびに深化する。これがこの設計の一番気持ちいい部分だ。

全体の循環図

一次情報（PDF・公式レポート）

↓ /wiki-ingest（本体）／ /research-wiki-ingest（プロジェクト）

要約＋Tier評価（sources/）

↓ 2ソース以上で昇格

概念ページ（concepts/）

↓ /wiki-query または /research-kb-query

総合分析（syntheses/）

↓ 論文執筆中に深化（プロジェクト側）

↓ /research-wiki-promote（完成後）

本体Vaultに還流（既存conceptsに「○○論文文脈」セクション追加）

使うほど知識の濃度が上がる。これが「第二の脳」の真髄だと思う。

7. 論文執筆そのものは専用スキルに任せる

ここまで作ったwikiは「知識の入れ物」で、論文本体を書くのは別の話。

私は academic-research-skills という Claude Code 用のスキル集を使っている。 → https://github.com/Imbad0202/academic-research-skills

これが本当に強力で:

• deep-research — 13エージェントでの文献サーベイ（PRISMA systematic review対応）
• academic-paper — 12エージェントで執筆、LaTeX / APA7 / IEEE / Chicago 対応
• academic-paper-reviewer — EIC + 3 Reviewer + Devil's Advocate で査読シミュレーション
• academic-pipeline — 10段階のフルパイプライン（research → write → review → revise → finalize）

このスキル集が、自分で作ったwikiの中の参考文献を読み込んで論文を書いてくれる。入れ子構造のミニWikiに参考文献が溜まっていれば、そのまま執筆の材料として参照される。

入れ物（wiki）と書き手（academic-research-skills）を組み合わせる設計。両者が分業できるから、どちらも強くなる。

8. AI支援執筆でのハルシネーションを、構造的に抑えられる

研究者は元々、一次情報を参照しないと論文が書けない。引用を手抜きする問題は基本的にない。では、この仕組みの何が新しいのか。

本当の価値は、AI支援で執筆するときに、AIのハルシネーション（事実でないそれらしい生成）を構造的に抑えられる点にある。

近年、論文の下書き・関連研究の整理・査読対応のドラフトなどをAI（Claude、GPT等）に任せる場面が増えた。ここで常につきまとう問題が、AIが生成する「実在しない引用」だ。典型的には:

• 実在しない論文タイトル・著者名・DOI
• 実在するガイドラインの古い版、誤ったセクション番号
• 主張と出典が微妙にずれている（近い内容の別論文が引用元になっている等）

入れ子wikiに一次情報をTier評価付きで登録しておくと、AIが参照可能な情報が「自分が読んで、Tier評価済みの原典」だけに絞られる。具体的には:

• AIが参照できるのは wiki の source 要約（原典パス・Tier・出版年を Frontmatter に保持）のみ
• 主張を書くとき、根拠が [[wiki/sources/YYYY-原典スラグ]] 形式で本文に紐づく
• 読者・査読者・共著者が、主張の出典を1クリックで原典PDFまで辿れる traceability が確保される

結果、AIが下書きを書いても、出典を改変・捏造しにくい構造になる。既存のワークフロー（手動で正確に引用）の精度を落とさずに、AIの速度を使える。

ただし、この仕組みは「AIの誤りをゼロにする」ものではない。以下は継続的に人間の責任で行う必要がある:

• AIが生成した source 要約は、必ず原典で再確認する（要約段階でのハルシネーション検出）
• Tier 1-2 のガイドラインは改訂されるので、鮮度管理が要る（日本のガイドラインも毎年動く領域がある）
• syntheses（AIの総合分析）を論文本体に直接貼らない。原典を辿り直して、自分の言葉で書く
• Tier・版・セクション番号は、最終稿で必ず人間が検証する

AIが便利になるほど、「正しい情報を選ぶ」「正しく引用する」「最終判断は人間が担う」という行為の重みが増す。この仕組みは責任の重みを軽くするのではなく、責任を果たしやすくするためにある。

9. 初めて触るとき、ここで詰まる

これから試す人のために、「先回りメモ」を置いておく。私自身も最初はここで混乱した。

詰まりポイント1: sources と concepts の違い

設計上の定義はこう:

• sources = 1原典1ページ（論文1本、ガイドライン1版など）
• concepts = 複数の原典から抽出される抽象概念（「SOAP形式」「QLoRA」「電子保存の3要件」など）

ここで注意したいのは、この振り分けは AI が自動で行うこと。人間が「これは sources、これは concepts」と手で仕分けるわけではない。

実際の流れはこうなる:

1. 人間は raw/ にPDFや記事を積む
2. /wiki-ingest を走らせる
3. AI が各原典を読んで sources/ に要約ページを作成
4. 複数の source で言及された概念を AI が検出し、concepts/ に full page を生成（それまでは stub）
5. 既存 concept があれば新情報源リンクを自動追記

人間の仕事は、上記の 1 と 2（「原典を raw に積む」「`/wiki-ingest` を叩く」）だけ。4層構造は使っているうちに自動で成熟する。

そしてたまに /wiki-lint を行って wiki をきれいに整理する。

詰まりポイント2: スラッシュコマンドの使い分け

• 普段の知識管理 → /wiki-* シリーズ（本体 Vault）
• 論文執筆時 → /research-* シリーズ（プロジェクト内）

両者は別スコープ。プロジェクト内で /wiki-ingest は動かない（そもそも呼び出せない）。

詰まりポイント3: 論文完成 → 本体への昇格タイミング

• ドラフト段階で昇格させない。投稿 or 受理後が目安
• 理由: 未確定情報が本体Vaultを汚染すると、他の執筆作業で誤引用リスクになる
• 昇格時は synthesis を丸ごと移さず、加筆部分を対応 concept に深化統合するのを優先する（本体 Vault から引き出しただけの synthesis を戻すとエコーチェンバーになる）

詰まりポイント4: Tier評価は AI の自動推定、最終判断は人間

/wiki-ingest は AI が原典を読んで Tier を自動推定するが、推定が誤ることはある。よくある例:

• Preprint を Tier 1 と誤推定する（未査読なので Tier 3 が妥当）
• 専門家ブログの肩書検証が曖昧なまま Tier 2 と推定する（Tier 3 が妥当）
• 古いガイドライン（改訂済み）を Tier 1 のまま残す

生成された source ページの Tier フィールドは、他の論文で引用元として使う前に必ず目視確認する。この一手間を省くと、AIの誤判定がそのまま自分の論文の引用品質に直結する。

まとめ

• Claude×Obsidian の「第二の脳」は便利だが、論文執筆にはそのままでは足りない。スコープ分離が必要
• 本体Vault（恒久的な知識）と プロジェクトwiki（論文用の仮置き場）を入れ子にする
• 4層（sources / concepts / entities / syntheses）は AI が自動で振り分けて管理する
• スラッシュコマンドで raw → wiki → 再利用 → 昇格 の循環を回す
• 論文執筆そのものは academic-research-skills に任せる
• 結果、AI支援執筆でもハルシネーションを構造的に抑え、出典の traceability が確保される

研究者として AI に文章生成を手伝ってもらう場面は今後さらに増える。そのとき本質的に問題になるのは、AIの生成物を自分の名前で出すときの出典責任だ。入れ子ナレッジベースは、それをかなり改善できる実用的な答えの一つだと思っている。

運用していて気づいたことがあれば、また書く。

---

付録: この記事を元に同じシステムを構築する

この記事には、設計思想・ファイル構造・スラッシュコマンドの役割が整理されている。Claude Code にこの記事を読み込ませて、次のように依頼すれば、ほぼ同じ設計を自分の環境に再構築できる。

この記事の設計に従って、自分の環境にも入れ子ナレッジベースを構築してください。

私の環境:
- Obsidian Vault のパス: {あなたのパス}
- 論文プロジェクトのパス: {あなたのパス}
- 対象領域: {医療/AI/人文など}

AI が対話的に、フォルダ構造・KB_SCHEMA（Tier 1-5 の評価ルール）・スラッシュコマンド定義・CLAUDE.md（スコープルール）を順番に整備する。

この記事だけで再現できる部分:

• 入れ子のフォルダ構造（本体 Vault＋プロジェクトミニWiki）
• 4層 Wiki スキーマ（sources / concepts / entities / syntheses）
• スラッシュコマンドの役割と循環サイクル
• 深化統合・エコーチェンバー回避などの運用原則

環境に合わせて詰める部分:

• 自分の領域固有の Tier 判定例（医療ガイドラインなのか、医学論文なのか等）
• 自動化の範囲（Task Scheduler 連携、Discord 通知、週次メンテナンスなど）
• 既存ワークフローとの統合

AI と一緒にセットアップする前提で書かれた記事、というのが建て付けだ。疑問があれば、記事の該当セクションについてAIに聞いて、AIと詰めれば十分再現できる。

---

参考

• Obsidian（公式サイト）. https://obsidian.md/
• mana「今さら聞けない！Claude × Obsidian、これはもう"違法"でしょ」X (旧Twitter), 2026-04-13. https://x.com/MakeAI_CEO/status/2043674800888119512
• academic-research-skills (v3.1). Imbad0202. GitHub. https://github.com/Imbad0202/academic-research-skills