ClaudeがノートをひけるObsidian Vaultのつくり方

半年前に決めた方針と、その後の判断がどう積み上がったかを、一本の流れにまとめたい。 手元のObsidianには、その会議のメモも、途中の議事録も、関連する数字も、確かに書いてある。 Claude Codeにそのフォルダを渡して、「この案件について過去に決めたことを時系列で出して」と頼む。

返ってくるのは、関係しそうなノートを浅くまとめた文章だけだった。 「いつ何を決めたか」は拾えていない。 自分で検索しても、似た言葉のノートが何十件も並ぶだけで、目的の一件にたどり着けない。

数百ページ書いたのに、必要な瞬間に何ひとつ引き出せない。 ここで多くの人は「AIがまだ賢くないからだ」と考える。 だが原因はそこではない。

ノートを取り出せないのは、Vaultが「しまうため」に作られていて、「AIが引き出すため」に設計されていないからだ。 本稿では、AIを第一の読み手に置いてObsidianを設計し直す方法を順に見ていく。 題材はX上で広く読まれた英語のガイド¹と、それを日本の業務現場向けに組み直した解説²である。

ひとつ前置きしておく。 この設計は、ノートを「何度も練り直して成果物にする資産」として扱う人に向いている。 資料を一度か二度調べて終わりにしたいだけなら、ここで手間をかける必要はなく、別記事で比べたとおりNotebookLMのほうが速い³。 以下は、その選別を済ませて「自分のVaultをClaudeに引かせたい」と決めた人のための手順だ。

しまう設計と引き出す設計は別物

蓄積はあるのに引き出せない。 この食い違いは、ほとんどのVaultが「保存する瞬間」に合わせて作られていることから生まれる。

ノートを書くとき、人は「とりあえずどこかに置く」ことを考える。 フォルダを開いて、それらしい場所に入れる。 保存するその瞬間は、それで困らない。

困るのは半年後に取り出すときだ。 保存した瞬間に「ここでいい」と思った場所は、取り出すときには何のヒントにもならない。 「アイデア」というフォルダに入れたビジネスの着想を、半年後に探そうとして、それが「アイデア」なのか「案件」なのか「議事録」なのか思い出せない。 この経験には覚えがある人が多いだろう。

ここで二つの設計を区別したい。 ファイリングキャビネットはしまうこと（storage）に最適化されている。 思考の道具は引き出すこと（retrieval）に最適化されている。 この二つは目的が違うので、出来上がる構造もまるごと違う。

引き出すための設計は、評価の軸が違う。 フォルダをきれいに分けることが目的ではない。 「将来この情報が必要になったとき、自分とAIは何を手がかりに探すか」を先に決めて、その手がかりをノートに持たせておくことが目的だ。

フォルダの組み方そのものは、この記事の主役ではない。 トップレベルのフォルダを五個から八個にまとめる、という基本は踏んでいる前提で進める⁴。 今日の主役はフォルダではなく、ノート一枚ずつが持つ「AIが読む手がかり」である。

自分のVaultを診断する

設計を直す前に、自分のVaultが「しまう設計」で止まっていないかを確かめておく。 次の項目に三つ以上当てはまれば、止まっていると考えてよい。

• Claudeに「過去の○○を出して」と頼むと、的確な一件ではなく浅い要約が返る
• 自分で検索しても候補が多すぎて、目的のノートを絞り込めない
• ノートのファイル名がバラバラで、開かないと中身が分からない
• ノート冒頭に、種類や状態を示す情報欄をつけていない
• タグをつけていない、またはルールなくつけている
• 「いつ・何について・どの状態か」でノートを絞る方法がない
• 三か月以上前のノートを、最後に取り出せたのがいつか思い出せない

当てはまる項目が多いほど、蓄積した知識がAIに届いていないことになる。 ここから先で、一つずつ埋めていく。

AIを第一の読み手に置く

引き出せるVaultを作る出発点は、設計の主語を変えることだ。 これまでノートを整える基準は「人間が探しやすいか」だった。 これからは「AIが探しやすいか」を基準にする。

人間のために整える設計は、人間が探し続けることを前提にしている。 AIのために設計すると、その前提ごと消える。 よく設計された構造はAIの検索精度を直接上げるので、整える作業とAIに引かせる作業は、同じ一つの設計の表と裏になる。

ここで一点だけ注意がいる。 AIが読むための手がかりは、人間が貼る整理ラベルとは別物だという点だ。 人間は色や場所でなんとなく覚えるが、AIはノートに書かれた構造化された情報を読む。 だからAIのために設計するときは、「AIが何を手がかりにノートを引くのか」を具体的に知っておく必要がある。

AIが必ず使う四つの手がかり

将来ノートを引き出すとき、自分とAIが必ず手にしている手がかりは四つしかない。

• type（種類）：会議録、提案、調査、意思決定、顧客メモ
• when（時期）：作成した日、関連する時期
• topic（主題）：案件名、取引先、テーマ
• status（状態）：進行中、完了、保留、参照用

実際の業務でAIに何かを頼むとき、私たちは無意識にこの四つを組み合わせている。 「進行中の（status）、新規事業案件で（topic）、先月以降の（when）、意思決定（type）を出して」。 この一文は、四つの手がかりを組み合わせている。

ノートにこの四つが記録されていれば、AIはこの問いにそのまま答えられる。 記録されていなければ、AIはノートの本文を一字ずつ読んで推測するしかない。 冒頭で要約しか返ってこなかったのは、この四つがノートになかったからだ。

ここから先は、この四つをノートに持たせる具体的な方法を、ファイル名、ノート冒頭の情報欄、タグの順で進める。 どれも新しいツールを入れる話ではない。 今あるObsidianのノートに、AIが読める手がかりを足していくだけだ。

ファイル名だけで中身が分かる命名

四つの手がかりのうち、いちばん手軽に持たせられるのがファイル名だ。 型を決めておくと、AIはノートを開く前に、名前だけで「いつの・何の・何についての」ノートかを判断できる。 おすすめは日付から始める型である。

YYYY-MM-DD-[種類]-[主題].md

2026-05-20-会議録-新規事業レビュー.md
2026-05-18-提案-A社向け運用改善.md
2026-05-15-調査-競合価格ベンチマーク.md
2026-04-28-意思決定-来期予算方針.md
2026-04-20-顧客メモ-B社ヒアリング.md

種類と主題は、自分の業務の言葉に置き換える。 経営企画なら「予算方針」、事業開発なら「新規事業」、コンサルなら案件名、リサーチャーなら調査テーマ、といった具合だ。

日付を先頭に置くと、三つのことが同時に起きる。 ファイルが自動で時系列に並び、最近のノートが上に来る。 正確な名前を思い出せなくても、だいたいの時期から絞れる。 同じ主題のノートが別の日に作られても、名前がぶつからない。

種類と主題をファイル名に入れておくと、AIは本文を読まなくても「これは新規事業の会議録だ」と判別できる。 四つの手がかりのうち、when、type、topicの三つが、ファイル名だけで埋まる。

この命名にはもう一つの強みがある。 入口で使うツールを変えても、AIのモデルが新しくなっても、ファイル名そのものは残る。 Vaultの中身は、ツールが移り変わっても引き継げる資産になる。

ファイル名で埋まらない残りの一つが、status（状態）だ。 状態は日々変わるので、ファイル名には向かない。 これは次の情報欄で持たせる。

AIが読む情報欄（フロントマター）を設計する

ファイル名の外側で、AIにさらに細かく引かせるための情報を、ノート自身に持たせる。 Obsidianには、ノートのいちばん上に --- で挟んで項目と値を並べる仕組みがある。 これはフロントマター（プロパティ）と呼ばれ、人間向けの見出しや装飾ではなく、AIが構造化された情報として読む部分だ。

---
type: 会議録
status: 進行中
date: '2026-06-20T02:00:00+09:00'
topic: 新規事業
tags: [新規事業, A社, 投資判断]
---

(ここから下に、いつものノート本文を書く)

この五項目が、四つの手がかりをそのまま埋める。 type、date（when）、topicはファイル名と重なるが、情報欄にも持たせておくと、AIはファイル名と本文の両方から同じ事実を確認できる。 ファイル名には向かないstatusも、ここでなら持てる。

ノート種別ごとに、項目を足してもよい。 案件ノートなら deadline、priority、next_action、completion を足す。 書籍メモなら author、rating、key_insight を足す。 参照資料なら source、reliability（出典の信頼度）を足す。 四つの手がかりを土台に、業務に応じて項目を増やしていく形になる。

タグは三種類に絞り、接頭辞で見分ける

タグは、つけないか、ルールなくつけすぎるかのどちらかになりやすい。 どちらも取り出しの場面では同じ結果になる。 何も見つけられないタグだ。

機能するタグは、三つの種類に分け、種類ごとに接頭辞をそろえる。

• 主題タグ：接頭辞なし。#新規事業 #価格戦略
• 状態タグ：接頭辞 status/。#status/active #status/waiting #status/complete
• 案件タグ：接頭辞 project/。#project/website-launch #project/client-acme

接頭辞をそろえておくと、タグで検索したとき、自分がどの種類で絞っているかが接頭辞から分かる。 #新規事業 は状態を問わず新規事業に関するノートを返す。 #status/active は主題を問わずアクティブなノートを返す。 #project/client-acme は種類を問わずその案件のノートを返す。

タグが膨らむのを防ぐ目安が一つある。 五件以上のノートで使う見込みがないタグは作らない。 一件や二件にしか付かないタグは、検索できるパターンにならず、ノイズになるだけだ。

ノートが二十枚を超えたらMOCで束ねる

ノートが数百から数千に増えると、検索とフィルタだけでは追いきれなくなる。 そこで使うのがMOC（Map of Content）、つまり目次ノートだ。

MOCはフォルダではない。 ノートをそこへ移動させるのではなく、MOCからノートへリンクを張る。 こうすると、関連する知識のかたまりを、一つの起点からたどれるハブになる。 一つの主題に二十枚を超えるノートが溜まり、バックリンクだけではたどりにくくなったら作る、というのが目安だ。

「探す」が「聞けば出てくる」に変わる

ここまでの手がかりが入ると、Claudeに対する問いの解像度が変わる。 英語版ガイドが挙げる問いの例を、そのまま日本語の業務に置けばこうなる。

• 「価格戦略について、この半年で書いたノートを全部出して」
• 「時間の管理とエネルギーの管理について、自分が何を書いてきたかまとめて」
• 「進行中の案件ノートのうち、七月より前に締め切りがあるものを出して」

ClaudeはVaultの構造、フロントマター、本文を読み、なぜその一件がマッチしたのかという理由を添えて返す。 人間がやっていた「どのフォルダだったか思い出す」「検索語を変えて何度も試す」という作業は、まるごと消える。 「探す」のではなく「聞けば出てくる」。 これが、AIを第一の読み手に置いて設計したVaultの到達点だ。

冒頭の経営会議の準備に戻れば、「この案件の意思決定を時系列で、関連する数字も添えて出して」の一言で、論点ペーパーの下地が返ってくる。 引き出す作業はClaudeが、その筋が正しいかどうかの判断は人間が受け持つ。

次の一ノートから始める

ここまで読むと、数百ページある既存のノートを全部作り直さないといけないように感じるかもしれない。 その必要はない。 作り直しは、いちばん挫折しやすいやり方だ。 代わりに、次に作る一ノートから始める。

# 今日やること（10分）

1. 次に作る1ノートに、命名の型で名前をつける
   例: 2026-06-20-会議録-週次定例.md
2. ノートの冒頭に、情報欄を5行つける
   ---
   type: 会議録
   status: 進行中
   date: 2026-06-20
   topic: 定例
   tags: [定例, チーム運営]
   ---
3. それだけ。中身はいつもどおり書く

今週は、新しく作るノートを全部この型で作る。 既存のノートは、開いて使ったときだけ、ついでに名前と情報欄を直す。 一括変換はしない。

この型で作ったノートは、その日からClaudeが引ける。 一週間後には、今週作ったノートはどれも「あの件のメモを出して」で返ってくる状態になる。 完璧に整え終わるのを待つ必要はない。

蓄積した知識は、構造を持たせてはじめて、引き出せる資産になる。 手がかりのないノートは、書いてあってもAIには届かない。 次の一ノートに十分かけるだけで、VaultはClaudeが読み手として引ける場所に変わり始める。

正直に言えば、これは一度やれば終わる設定ではなく、続けるあいだだけ効く習慣だ。 新しいノートに毎回型を守る手間は残り、守らなければVaultはまた「しまう設計」へ戻る。 その手間に見合うのは、ノートを引き出して何かを作る機会が、実際に繰り返しあるときに限る。

まとめ

• ノートを引き出せないのは、AIの能力ではなく、Vaultが「しまう設計」で止まっているから
• 引き出す設計は「将来何を手がかりに探すか」を先に決める
• 設計の主語を人間からAIに移すと、人間が「探す」行為そのものが消える
• 四つの手がかり（type / when / topic / status）を、命名・フロントマター・タグで持たせる
• 既存は作り直さず、次の一ノートから始める

なお、ここで作った構造を実際にClaudeへつなぐ方法（Claude CodeでフォルダをそのままひくやりかたとMCPサーバーを使うやりかた）は、本シリーズの別記事で扱う。