research-vault
Zotero + Obsidian を利用した研究・論文管理用Vault。
読む → 考える → 統合する → 問いを作る → 書く、という研究ワークフローを支えるための Vault であり、知識管理そのものは目的にしない。
Structure
research-vault/
├── 00_Inbox/
├── 10_Projects/
├── 20_Concepts/
├── 30_Papers/
├── 40_Notes/
│ ├── Methods/
│ └── Ideas/
├── 90_Maps/
├── 99_Templates/
│ ├── Paper.md
│ ├── Concept.md
│ └── Project.md
├── Attachments/
├── CLAUDE.md # AI が Vault を操作するときの規約
└── library.yaml # Better BibTeX が自動生成。手で編集しない
ディレクトリ名・ファイル名に空白は使わない。区切りはアンダースコアを使う。
基本方針
Zotero
文献そのものを管理する。
- 書誌情報
- ハイライト。Zotero 内に保持し、Paper ノートへの自動転記はしない。AI の初稿は PDF から生成する
- 引用・参考文献
Better BibTeX（必須プラグイン）
citekey は smith2024 のような文字列で、同じ論文を Zotero のエントリ・Obsidian の Paper ノート・原稿中の引用の間で対応づける共通ID。Better BibTeX が発行・管理する。
- citekey は著者+年の短い形式にする。ファイル名としても使うため、タイトル語を含む長い形式にはしない。同一著者・同年の論文には Better BibTeX が自動で
abを付けて区別する。一度決めた形式は途中で変えない - citekey は、Paper ノートや原稿から参照された時点で Better BibTeX の pin 機能で固定する。以後 Zotero 側で書誌を修正しても citekey は変わらない。日本語文献などで生成されるキーが不適切な場合は、手動で指定して pin する
- Zotero と Vault で citekey が食い違ったときは、pin 済みの Zotero 側を正として Vault を合わせる
- ライブラリ全体を Better BibTeX の自動エクスポート機能で CSL-YAML 形式の
library.yamlに書き出す。Zotero で保存するたびに更新される library.yamlは paper-template のcite.yamlと同形式。執筆時は paper-template からlibrary.yamlを直接参照する。Pandoc は引用された文献しか出力しないので、全ライブラリを渡して問題ない。paper-template のビルドは Docker なので、Makefile で vault をマウントして bibliography に指定する
PDF の置き場所
Zotero の内部 storage は無料枠が 300MB しかないので使わない。添付は「リンクファイル」とし、実体は Google Drive 上の論文フォルダに置く。
- ZotMoov プラグインで、取り込み時に PDF を Drive のフォルダへ
<citekey>.pdfで自動改名・移動する。<citekey>.pdfにするのは本文 PDF のみで、補足資料などの添付は改名しない。pin 前に citekey が変わったときは PDF 名も追従させる - Zotero からは通常どおり開け、同期は Google Drive が担い、Claude やスクリプトはファイルパスで直接読める。誤削除・誤上書きは Drive の版履歴とゴミ箱で復旧する
- 論文フォルダは Drive の同期モードを「オフラインで使用可能」にする。ストリーミングだと実体のないプレースホルダが残り、一括読みが不安定になる。容量が問題になったら範囲を見直す
Obsidian
文献から得た知識と、自分の研究上の思考を管理する。
- 論文の要点
- 自分の解釈
- Concept
- 論文同士の関係
- Research Question
- 研究アイデア
- Project
- 執筆の材料
Claude
原則: AI に参照させる知識は markdown ファイルとして Vault に置く。PDF と library.yaml は原資料としてファイルパスから直接読む。
Vault はプレーンテキストなので、Claude はそのまま検索・横断・要約できる。Vault は git 管理する。
AI が Vault を操作するときの規約は CLAUDE.md に書く。README は人間向けの設計・運用方針を書く。Claude 以外のエージェントにも同じ規約を適用するため、AGENTS.md を CLAUDE.md へのシンボリックリンクとして置く。
活用例: PDF から Paper ノートの初稿を生成する。テーマ横断で survey の下書きを作らせる。
00_Inbox
まだ分類していないメモを一時的に置く。
思いついた段階で保存し、後から適切なノートへ移動・統合する。
40_Notes/Ideas との使い分け: 一時的なメモは Inbox、後で加筆・発展させる前提のメモは Ideas。Inbox に1週間以上残っているメモは、移動するか捨てる。
10_Projects
現在進行中の研究単位で管理する。
10_Projects/
├── Project_A/
│ └── Project_A.md
└── Project_B/
Project の文献一覧・仮説・アイデアは Project ノート内の節で持ち、別ファイルにしない。横断的な俯瞰は 90_Maps の役割。
Projectノート例：
# Project - ○○に関する研究
## Research Questions
- RQ1:
- RQ2:
## Concepts
- [[Concept_A]]
- [[Concept_B]]
## Core Papers
- [[smith2024]]
- [[tanaka2023]]
## Literature Gaps
-
## Hypotheses
-
## Next Actions
- [ ] 文献検索
- [ ] smith2024 を読む
- [ ] Concept_A を整理する
20_Concepts
研究上重要な概念・理論を管理する。
論文を分類するためのタグではなく、複数の論文から得られた知識を統合する場所として使う。
Concept は需要駆動で作る。
- 新しい Concept を導入する前に、既存 Concept を aliases 含めて検索する。追記で済むなら作らない
- 同一概念の表記ゆれは frontmatter の
aliases:で吸収する。AI_Literacyのノートにaliases: [Artificial_Intelligence_Literacy]を持たせれば、どちらの表記でもリンクが解決される - Concept ノートは、複数の論文から統合して書く必要が生じるまで作らない。それまでは
[[Concept_X]]の未解決リンクのままでよい。未解決リンクへの参照数が、ノート化の需要を示す - 未解決リンクを新しく書く前も、既存 Concept を検索する
- Concept ノートを作るときは、表記ゆれで分かれていた未解決リンクを統合する
Concept の分割・統合の細かな規則は作らない。
# Concept Name
## Definition
概念の定義。
## Key Arguments
### Argument 1
[[smith2024]] では……
一方、[[tanaka2023]] では……
## Questions
-
## Related Concepts
- [[Concept_B]]
- [[Concept_C]]
30_Papers
1論文につき1ノート。
フォルダによる細かい分類はせず、基本的にフラットに管理する。
30_Papers/
├── smith2024.md
├── tanaka2023.md
└── ...
ノートのファイル名は citekey と同一にする。PDF の <citekey>.pdf・原稿中の [@citekey]・ノート間の [[citekey]] がすべて同じ文字列で対応する。Paper ノートでは citekey を frontmatter に複製せず、ファイル名で表す。論文タイトルはノート先頭の見出しに書く。Paper ノートがまだ無い [[citekey]] は未解決リンクになるが、library.yaml と PDF から内容を検証できる。
基本テンプレートは TL;DR・Key Findings・My Thoughts の3項目。Research Question / Method / Related Papers は書く内容がある場合だけ節を追加し、空見出しを残さない。TL;DR と Key Findings は AI が初稿を生成してよい。My Thoughts は人間が書く。
論文がどの Concept に関わるかは、本文ではなく frontmatter の concepts: に書く。frontmatter 内のリンクもバックリンク・グラフに表示され、検索やスクリプトで「Concept_A に関わる論文の一覧」を取り出せる。本文には要点・解釈・文脈のある言及を書く。
論文と Project の関係はここには書かない。それは Project 側の編集判断と、執筆原稿の [@citekey] が記録する。
Related Papers は関連文献の網羅的な一覧にはしない。論文同士の直接的な関係を説明できる場合だけ節を追加し、- [[tanaka2023]] : 同じ手法を別データで検証 のように「なぜ関連するのか」を短く添える。テーマ・概念単位で複数論文をまとめる役割は Concept が担う。
Paperノート例：
---
concepts: ["[[Concept_A]]", "[[Concept_B]]"]
tags: [education, hci]
---
# Smith (2024) Paper Title
## TL;DR
論文の要点を数行で記述。
## Key Findings
-
-
## My Thoughts
この論文から考えたこと。[[Concept_A]] の観点では……
Abstractをそのまま保存することよりも、
この論文から自分は何を得たのか？
を残すことを優先する。
40_Notes
論文やConceptに直接属さない研究メモ。
40_Notes/
├── Methods/
└── Ideas/
Methods
統計手法、研究デザイン、分析方法など。
Ideas
仮説、研究アイデア、まだ Project に属さない研究上の問い、気づきなど。
Project に属する問いは Project ノートの Research Questions 節が正本。概念への疑問は Concept ノートの Questions 節に書く。
90_Maps との使い分け: 既存ノートへのリンク集約なら Maps、自分の主張・考察なら Notes。
90_Maps
複数のConceptやPaperを俯瞰するためのMOC（Map of Content）。
MOC は取捨選択や構造化など自分の編集判断が入るものに限定する。機械的に列挙できるだけの一覧は作らない。
90_Maps/
├── MOC_Topic_A.md
├── MOC_Topic_B.md
└── MOC_Research_Methods.md
例：
# MOC - Topic A
## Core Concepts
- [[Concept_A]]
- [[Concept_B]]
- [[Concept_C]]
## Key Papers
- [[smith2024]]
- [[tanaka2023]]
## Related Projects
- [[Project_A]]
## Open Questions
-
99_Templates
Obsidianで使用するテンプレート。
99_Templates/
├── Paper.md
├── Concept.md
└── Project.md
Attachments
画像など、Obsidianノートから参照する添付ファイルを保存する。
論文PDFの正本はここには置かない。実体は Zotero のリンクファイルが参照する Google Drive の論文フォルダにある。
Tags
タグは分野のような粗い分類に使う。
タグは frontmatter の tags: に書き、本文中には書かない。Obsidian の Properties・検索・スクリプトから一貫して扱える。
タグは小文字の kebab-case で書く。追加する前に既存タグを検索し、同義語・単複・表記ゆれを増やさない。
例：
tags: [hci, education, machine-learning]
使い分けの基準：
- 複数の論文から知識を統合して文章を書く対象 → Concept ノートを作り
[[Concept_A]]のようにリンクする - 分野のように、ラベルを付けるだけで書く内容がないもの → タグ
frontmatter に持つのは Paper の concepts: と tags:、Concept の aliases: だけ。ノートの種類はフォルダが、書誌情報は library.yaml が表すので、frontmatter に複製しない。読書状態は管理しない。
Workflow
基本的な流れ：
論文を発見
↓
Zotero Connector で保存
↓ ZotMoov が PDF を Drive へ <citekey>.pdf で配置
↓ Better BibTeX が library.yaml を自動更新
PDFを読む・ハイライト
↓
残す価値があれば citekey を pin し、Paper Note を作成
↓
Conceptとリンク
↓
Concept Noteで複数論文を統合
↓
Research Question / Idea
↓
Project
↓
paper-template で論文執筆
vault の library.yaml を bibliography として直接参照し [@citekey] で引用
Scale
Zoteroに登録したすべての論文について、Obsidianノートを作成する必要はない。
例えば：
Zotero
1,000 Papers
│
├── 未読・参考程度: 700
│
└── 読了・重要: 300
↓
Obsidian
300 Papers
↓
50 Concepts
↓
5 Projects
Obsidianは文献データベースではなく、研究上重要な情報を抽出・統合する場所として使用する。
Design Principles
Pull
情報が存在するから整理するのではなく、研究上必要になったときに知識化する。
- 論文を読んだからではなく、残す価値があるから Paper Note を作る
- Concept を見つけたからではなく、複数の知見を統合する必要があるから Concept Note を作る
- ノートが増えたからではなく、俯瞰する必要が生じたから Map を作る
- 過去のストックを網羅的に遡って整理しない
- タグやリンクを完全にするためだけの遡及作業をしない
Vault の完成度やノート数ではなく、研究活動を前に進めることを優先する。
Folders
このVaultでは、フォルダを研究テーマの分類体系として使用しない。
フォルダはノートの「種類」を区別するために使用する。
Layers
Zotero
│
│ PDF / Metadata / Citation
↓
Paper
│
│ Evidence / Findings
↓
Concept
│
│ Synthesis / Interpretation
↓
Project
│
│ Research Question / Argument
↓
Writing
役割を整理すると：
| Layer | Role |
|---|---|
| Zotero | 何を読んだか |
| Paper | その論文から何を得たか |
| Concept | 複数の論文から何が言えるか |
| Project | それを使って何を研究するか |
| Writing | paper-template で執筆。引用は citekey で対応づける |
この分離を維持することで、文献数が1,000本以上になってもVaultを管理しやすくする。
Setup
新しいマシンで再現する手順。
- Zotero をインストールし、プラグインを追加する。本体は
brew install --cask zotero。プラグインは各リポジトリの.xpiを Tools → Plugins から入れる- Better BibTeX: citation key formula を
auth.lower + yearに設定する。ライブラリを CSL-YAML で Vault 直下のlibrary.yamlに自動エクスポート - ZotMoov: リンクファイルの保存先を Google Drive の論文フォルダに設定。ファイル名は
<citekey>.pdf - Zotero 本体: linked attachment base directory を同じ論文フォルダに設定する。Drive のローカルパスがマシンごとに違っても、リンクが相対パスで解決される
- Better BibTeX: citation key formula を
- Google Drive for Desktop で論文フォルダを「オフラインで使用可能」に設定する
- Obsidian でこの Vault を開く
- paper-template の Makefile を、vault の
library.yamlを Docker コンテナにマウントして bibliography に指定するよう変更する。以後はmakeだけで最新の文献DBが使われる
How to Install
- Download the ZIP or clone the repository
- Open the folder as a vault in Obsidian (File → Open Vault)
- Obsidian will prompt you to install required plugins
Stats
Stars
0
Forks
0
Last updated 12d ago