Claude×Obsidian｜AIが目的のノートを引けるVault設計

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

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

数百ページ書いたのに、必要な瞬間に何ひとつ引き出せない。 ここで多くの人は「AIがまだ賢くないからだ」と考える。 原因は、ノートの整理だけでは特定できない。 アクセス権、検索対象の範囲、使う検索方法、ノートの更新状態、モデルの応答も確認する必要がある。

本稿では、そのうちノート側の手がかりを整える方法を扱う。 以下の導入場面は課題を説明するための想定例であり、検索失敗の原因を実測で特定した事例ではない。 Claudeが参照する情報を人も点検できるように、Obsidianの設計と検索確認を組み合わせる。 本稿の構成案による検索精度や作業時間の改善は、まだ測定していない。 題材はX上で広く読まれた英語のガイド¹と、それを日本の業務現場向けに組み直した解説²である。

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

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

蓄積はあるのに引き出せない。 保存するときの分類と、後から探すときの条件が一致しない場合がある。

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

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

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

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

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

自分のVaultを診断する

設計を直す前に、自分のVaultが「しまう設計」で止まっていないかを確かめておく。 次の項目は、整理方法を見直すきっかけになる。 当てはまる数で原因や検索性能を診断するものではない。

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

検索結果が不十分な場合は、次の順で問題を切り分ける。

確認すること	確認方法	不足していた場合
対象ノートを読めるか	既知の1ファイルを指定し、該当箇所の提示を求める	アクセス権と対象フォルダを確認する
必要な範囲を探しているか	対象フォルダ、除外設定、使用した検索方法を確認する	検索範囲を見直す
最新の内容を参照しているか	ノートの更新日と回答の根拠箇所を比べる	検索索引や参照元の更新状態を確認する
手がかりが不足しているか	同じ案件の複数ノートで日付や状態を比較する	必要な項目を補う
ここから先で、一つずつ埋めていく。

AIを第一の読み手に置く

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

人間のために整える設計は、人間が探し続けることを前提にしている。 ノートに種類や日付が明記されていれば、検索条件や回答の照合に使える。 ただし、実際にそれを利用するかは検索方法や指示によって変わる。 構造を整えた効果は、後述する同じ質問での確認によって判断する。

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

検索条件に使う四つの手がかり

業務のノートを絞るために、本稿では次の四つを基本項目として提案する。 検索に使える情報はこの四つに限らず、本文の語句やリンクなども手がかりになる。

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

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

この四つを記録すると、質問の条件とノートの内容を照合しやすくなる。 ただし、記入だけで回答の正確性や網羅性は保証できない。 本文から条件を読み取れる場合もあり、冒頭のような失敗を項目不足だけで説明することはできない。

ここから先は、この四つをノートに持たせる具体的な方法を、ファイル名、ノート冒頭の情報欄、タグの順で進める。 どれも新しいツールを入れる話ではない。 今ある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には、ノートのいちばん上に --- で挟んで項目と値を並べる仕組みがある。 これはフロントマター（プロパティ）と呼ばれる。 人も項目を確認でき、検索方法が対応していれば条件の指定にも使える。 Claudeが項目を読み取り、検索条件として使ったかは回答の根拠で確かめる。

---
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が、その筋が正しいかどうかの判断は人間が受け持つ。

同じ質問で検索結果を確かめる

以下は本稿で提案する評価手順であり、実施済みのテスト結果ではない。 まず、読者自身が正解を確認できる質問を選び、整備前と整備後で同じ質問を使う。 比較するときは、Claudeのモデル、指示、検索方法、対象フォルダ、参照日時を記録し、ほかの条件をできるだけ揃える。

質問の例	人が先に確認する正解	回答で確かめること	結果欄
案件Aの先月の確定した決定を出して	対象ノートのパス、決定日、確定状態、該当箇所	日付と状態が合うか、保留案を混ぜていないか	未実施
現在有効な予算方針と変更理由を出して	最新方針のパス、旧版のパス、更新日、理由の記述	古い方針を最新と扱っていないか	未実施
記録していない決定について教えて	該当する記録がないことを確認した範囲	不明と答えるか、存在しない記述を作っていないか	未実施

記録には、質問、期待するパスと根拠箇所、実際に返ったパスと根拠箇所、参照日、採否、失敗理由を残す。 期待するノートが出たことに加え、不要なノートの混入と必要なノートの漏れも確認する。 検索できなかった場合は、ノートが読めない、範囲外、更新未反映、条件の読み違いなどに分けて記録する。

合格条件は、期待した根拠を参照し、日付と状態を取り違えず、記録がない情報は不明として扱うこと。 一問の成功をVault全体の成功に広げず、同じ質問群で整備前後の結果を比べる。 必要な根拠を拾えないままなら、項目を増やす前に検索方法とアクセス範囲を再確認する。

次の一ノートから始める

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

# 今日やること（10分）

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

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

型を付けたら、そのノートを含む質問で検索を試す。 一週間という期間や、曖昧な質問だけで全件が返ることは保証できない。 必要なノートを取り出せたかは、次の確認表に記録する。 完璧に整え終わるのを待つ必要はない。

次の一ノートを整え、同じ質問で根拠を確認するところまでを一組にする。 整理に十分かけることと、検索が成功することは別々に記録したい。

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

まとめ

• 取り出せない原因は、ノートの構造、アクセス権、検索範囲、検索方法、応答の内容を分けて調べる
• 引き出す設計は「将来何を手がかりに探すか」を先に決める
• AIが提示したパスと根拠箇所を、人が正解ノートに照らして確認する
• 四つの手がかり（type / when / topic / status）を、命名・フロントマター・タグで持たせる
• 既存は一括で作り直さず、次の一ノートで整備と検索確認を試す

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

その後の動き（2026-06-28 追記）

引き出す設計が効くのは、入れる段と読む段の両方にコストがかかるからだ。 @ClaudeCode_UT は、Karpathyの「LLM Wiki」構造を使うとAIのトークンコストが最大95%削減できるとされる、と紹介している。 理由として、多くの実装が質問のたびに全データベースをゼロから読み直している点を挙げる。 この95%という数字は投稿の主張で未検証だが、引く対象を手がかりで絞れる構造にしておくと、都度の読み込み量が減るという方向は本稿の設計と重なる。

入れる段については、取り込み口を増やす動きがある。 @obsidianstudio9 は、Obsidian 1.13 betaのiOS共有シートを使うと、X投稿やYouTubeの文字起こしを、後から引けるMarkdownとしてVaultへ保存できると報告している。 取り込み時に手がかりを付ける方法も考えられるが、保存したノートを実際に読めるか、対象を検索できるかは別に確認する。