Obsidian 上級者向けセットアップ：パーソナル・インテリジェンス OS の構築

AIでお金を生むのは「メモの量」ではない

最初に、少し冷静な話をしておく。

年収1億円とObsidianの構成に因果関係がある、という研究はない。「富裕層しか知らない秘密のプラグイン」が存在するわけでもない。

ここでいう「1億円プレイヤー」とは、知識を大量に保存している人ではない。

得た情報を、

意思決定
交渉
採用
投資判断
商品設計
コンテンツ
営業資料
組織の仕組み
再利用できる知的資産

へ、極端に速く変換できる人のことだ。

普通のObsidianユーザーは「何を保存するか」を考える。

強いユーザーは「将来、どんな状況で、どんな問いを使って、この情報を取り出すか」を先に考える。

さらに強いユーザーは、取り出した知識が最終的にどんな意思決定や成果物へ変換されたかまで追跡する。

つまり、本当に設計すべきものは「第二の脳」ではない。

意思決定と知的生産を複利化する、Personal Intelligence OSである。

ObsidianはノートをローカルのMarkdownファイルとして保存する。Vaultは単なるフォルダであり、外部エディタやスクリプトから変更してもObsidian側へ反映される。設定やプラグイン情報は.obsidianフォルダに分離される。これは、Obsidianをアプリではなく、Git、CLI、Claude、Codexから扱える「知識リポジトリ」にできるということだ。

この記事では、Obsidianを次のように扱う。

Obsidian上の要素知識システムとしての意味MarkdownソースコードProperties型システムTemplatesコンストラクタLinks依存関係MOC人間が編集したインデックスBasesデータベースビューCanvas一時的な思考空間Skills再実行可能な業務手順CLI外部エージェント向けAPIGit履歴、差分、復旧Weekly Reviewテストとリファクタリング

この見方へ到達すると、Obsidianの使い方は完全に変わる。

第1章　海外事例を調べると、勝ち筋は「整理」ではなく「検索」だった

1. 研究者7人のVaultから分かったこと

2025年に公開された、ブラジルの研究機関に所属するコンピューターサイエンス研究者7人のObsidian利用を調べたケーススタディがある。

この研究で特に重要なのは、参加者がどのようにノートを作ったかではない。

将来どう取り出すつもりかが、ノートの作り方や整理方法に強く影響していたという発見だ。参加者は検索欄、タグ一覧、本文中のタグ、内部リンクなどを使い分けていた。また、作成したノートをいったんInboxへ入れ、週に一度処理する利用者もいた。

研究者らが導いた設計上の提案は、次の3つに集約できる。

最初から完璧な分類を要求せず、最低限の初期構造を用意する
利用中に構造を変更できるようにする
作成・整理方法と、将来の検索方法を最初から結びつける

つまり、「正しいフォルダを作れ」ではない。

未来の自分がどのように探すかを決め、その検索経路に合わせて記録せよということだ。

この一点だけでも、よくあるObsidian講座の大半が逆向きだと分かる。

多くの講座は、最初にフォルダ、タグ、プラグイン、見た目を決める。

しかし実際には、先に決めるべきなのは次の問いである。

三カ月後、私は何について悩んでいるときに、この情報を必要とするのか。

2. Nicole van der Hoeven――ノートをキャリアの学習装置にする

Developer Advocate、パフォーマンスエンジニアとして活動するNicole van der Hoevenは、仕事上のノートを継続的に取ることが、学習速度だけでなくテック業界でのキャリアにも良い影響を与えたと述べている。

重要なのは、彼女が「きれいな知識データベースを作った」からではない。

仕事中の学習を記録し、それを公開、説明、発表へ再利用している点だ。

学習ノートを自分だけの記録で終わらせず、

発表
記事
動画
ドキュメント
教材
次の仕事

へ流す。

この「入力から出力への変換」が、知識の経済価値を作る。

3. Bruno Paz――ローカル、Markdown、最小プラグイン

ソフトウェアエンジニアのBruno Pazは、コードスニペット、会議、プロジェクト仕様、調査、生活上の知識までをObsidianへ集約している。

ただし、何でもObsidianへ入れることより重要なのは、その設計思想だ。

彼はMarkdownの可搬性とGitによる履歴管理を重視し、プラグイン数を最小限に抑える方針を取っている。プラグインはObsidianを便利にするが、コンテンツそのものを特定プラグインへ依存させすぎない。

また、typeのようなFrontmatterをテンプレートで標準化し、topicsには関連ノートへのWikilinkを入れ、BasesやDataviewで一覧化している。

ここから得られる結論は明確だ。

高機能であることより、壊れたときにMarkdownだけで復旧できることの方が重要である。

4. Ian O’Byrne――情報を「Consume → Curate → Create」へ流す

教育・研究分野でObsidianを使うIan O’Byrneは、Vaultをおおむね次の流れで構成している。

Consume：記事、本、論文、ポッドキャストなどの入力
Curate：要点を蒸留し、関連づけ、MOCを作る
Create：ブログ、ニュースレター、教材などの出力
Meta：Vault自身の運用情報

重要なのはフォルダ名ではない。

情報が入力から意味づけを経て、出力へ移動する構造になっていることだ。本人も、プラットフォームよりプロセスが重要であり、Vaultは必要に応じて進化すると説明している。

この海外事例群をまとめると、優れたVaultには五つの共通点がある。

Retrieval-first――未来の検索から逆算する
Output-centric――保存ではなく成果物へ流す
Local-first――Markdownを原本にする
Minimal schema――入力時の項目を増やしすぎない
Evolutionary――使いながら構造を変える

第2章　「1億円Vault」を定義する6つの指標

ノート数、リンク数、Graphの美しさは、本質的な成果指標ではない。

私なら、Vaultの性能を次の6指標で測る。

1. Capture Latency

思いついてから保存するまでの時間。

目標は30秒以内。入力時にタグ、関連ノート、保存先を考えさせる構造は弱い。

2. Retrieval Time

必要な情報へ到達するまでの時間。

通常の情報は30秒以内、重要な意思決定記録は60秒以内を目標にする。

3. Context Reconstruction Cost

昔のノートを見たとき、何の話だったかを復元するための時間。

会議タイトルしか残っていないノートは弱い。

「背景」「決定」「理由」「前提」「次の行動」が残っているノートは強い。

4. Decision Traceability

重要な判断について、

なぜ決めたか
何を却下したか
どんな前提があったか
何が起きたら撤回するか

を後から追跡できる割合。

5. Output Conversion Rate

保存したSource NoteやEvergreen Noteのうち、記事、提案書、製品、意思決定、会議、営業活動へ再利用された割合。

6. Agent Executability

ClaudeやCodexが、Vaultのルールを誤解せずに検索、提案、検証できる割合。

これらをまとめると、知識システムのROIは次のように考えられる。

**Knowledge ROI ＝再利用された知識＋改善された意思決定＋回避できた失敗 ÷ 記録・整理・保守に使った時間**

ノート数が増えても、再利用されなければ分母だけが増えている。

第3章　日本人が使いやすいVaultの完成構造

私がゼロから作るなら、トップレベルは次の構造にする。

MyVault/

├── 00_Inbox/

│ ├── AI/

│ └── Clippings/

├── 10_Daily/

│ └── 2026/

├── 20_Projects/

├── 30_Areas/

├── 40_Notes/

│ └── MOCs/

├── 50_Sources/

├── 60_Entities/

│ ├── People/

│ ├── Companies/

│ └── Products/

├── 70_Outputs/

│ ├── Drafts/

│ └── Published/

├── 80_Assets/

├── 90_System/

│ ├── Templates/

│ ├── Bases/

│ ├── Schemas/

│ ├── AgentSkills/

│ └── AI/

├── 99_Archive/

├── scripts/

├── .claude/

├── .agents/

├── .codex/

├── CLAUDE.md

└── AGENTS.md

00_Inbox

未分類の入力。

ここでは整理しない。タグも原則不要。

「とにかく保存する」ための場所である。

10_Daily

時系列の作業ログ。

独立したノートを作るほどではないメモ、会話、気づき、進捗を残す。

Daily NotesはObsidianのコアプラグインで、標準ではYYYY-MM-DD形式のファイルを作り、テンプレートも指定できる。

20_Projects

終了条件のある活動。

「売上を伸ばす」はAreaまたはGoalだが、「法人プランの価格を2026年9月までに改定する」はProjectである。

Projectには必ずnext_actionを持たせる。

30_Areas

終わりのない責任範囲。

経営、営業、採用、財務、健康、家族、学習など。

Projectが完了してもAreaは残る。

40_Notes

長期的に再利用する知識。

ここには単なる抜粋ではなく、自分の言葉で説明できる内容を置く。

「1ノート1概念」を厳格に守る必要はない。

日本語は主語や前提を省略しやすいため、細分化しすぎると文脈が壊れる。基準は「1ノート1概念」ではなく、

1ノート＝未来に一単位として再利用したい内容

とする。

50_Sources

外部情報の記録。

本、論文、記事、動画、会議資料、調査データなど。

ここでは「相手が何を言ったか」と「自分がどう解釈したか」を分ける。

60_Entities

人物、企業、製品、顧客、競合、技術などの実体。

同じ人物や企業が複数プロジェクトに登場しても、Entity Noteは一つにする。

70_Outputs

記事、企画書、提案書、動画台本、プレゼン、営業資料、製品仕様など。

Outputsを独立したトップレベルに置くことが重要だ。

保存だけを目的にしたVaultは、知識の墓場になる。

90_System

テンプレート、Schema、Bases、AIルール、Skillsなど、Vault自身を動かす仕組み。

ここを作ることで、自分の運用を自分で説明できるようになる。

一つのVaultにするべきか

原則は一つ。

Obsidianの内部リンクはVault内で解決されるため、Vaultを分けると知識間の関係も分断される。公式も、リンクがVault単位であることを説明している。前述の研究でも、Vaultを三つに分けた参加者が検索の混乱を報告している。

ただし、次は物理的に分離する。

顧客との契約で外部AI投入が禁止されている情報
医療、個人番号、認証情報
機密性の高い人事情報
規制対象データ
組織ポリシー上、外部モデルへ渡せない情報

「Personal Vault」と「Regulated Vault」を分けるイメージだ。

第4章　フォルダ、Properties、Links、Tagsの役割を混ぜない

Obsidianが破綻する最大の原因は、同じ分類をフォルダ、タグ、プロパティ、リンクの全部で表現することだ。

役割を次のように固定する。

フォルダは「ライフサイクル」

Inbox、Project、Source、Output、Archiveなど。

ノートが現在どの工程にあるかを表す。

Propertiesは「機械が扱う型と状態」

type、status、created、project、revisitなど。

ObsidianのPropertiesはYAMLとして保存され、テキスト、リスト、数値、チェックボックス、日付、日時、タグなどの型を持てる。同じ名前のPropertyはVault全体で同じ型として扱われる。

Linksは「意味関係」

[[価格戦略]]、[[株式会社ABC]]、[[意思決定の可逆性]]など。

トピックをタグではなくノートにすると、そのトピック自体へ説明、反証、参考資料、MOCを持たせられる。

Tagsは「一時的な横断状態」

タグは次の程度に限定する。

「マーケティング」「心理学」「AI」のような概念は、可能な限りリンクにする。

タグを概念辞書として使うと、似たタグが増殖する。

日本語では表記揺れが起きやすい。

そこで、概念ノートにAliasesを持たせる。

type: note

status: active

created: 2026-07-24

aliases:

LTV
顧客生涯価値
lifetime value

ObsidianのPropertiesでは、内部リンクをテキストやリストに入れる場合、引用符で囲むのが正しい形式である。

第5章　最小Property Schema

入力時から20項目を埋めようとしてはいけない。

Schemaは三段階に分ける。

Capture段階

必須はこれだけ。

type: inbox

created: 2026-07-24

status: inbox

Promoted段階

長期保存する価値が出たら追加する。

type: note

created: 2026-07-24

status: active

topics:

"[[価格戦略]]"
"[[B2B SaaS]]" source_notes:
"[[SRC 競合価格調査 2026-07]]" confidence: medium sensitivity: internal

Operational段階

ProjectやDecisionで必要な項目を追加する。

type: project

created: 2026-07-24

status: active

owner: me

area: "[[経営]]"

due: 2026-09-30

next_action: 競合5社の年額プランを比較する

推奨する共通語彙は次の通り。

type:

inbox

daily

project

area

meeting

decision

source

note

person

company

output

status:

inbox

active

waiting

done

archived

confidence:

low

medium

high

sensitivity:

public

internal

confidential

never_ai

updatedは手入力しない。

更新日時はfile.mtimeで取得できるため、手動Propertyにすると保守コストになる。Basesはfile.mtimeなどのファイル情報を参照できる。

第6章　日本語ファイル名のルール

日本語の本文やタイトルを無理に英語へする必要はない。

ただし、機械処理で使うProperty名とフォルダ名はASCIIに寄せる。

私なら次の命名規則を使う。

Project:

PJT 法人向け料金体系の再設計

Decision:

DEC 2026-07-24 年額プランを標準提案にする

Meeting:

MTG 2026-07-24 株式会社ABC 定例

Source:

SRC 著者名 - 記事または論文タイトル

Evergreen Note:

価格は機能数より導入失敗リスクで決まる

Person:

田中太郎

Company:

株式会社ABC

Evergreen Noteは「分野名」より「主張」にする。

弱いタイトル：

価格戦略

営業

採用

AIエージェント

強いタイトル：

高価格商品ほど機能より失敗回避を売る

採用面接では能力より再現条件を聞く

AIエージェントには自由度より検証可能性を与える

主張型タイトルにすると、検索結果だけで内容を思い出せる。

第7章　実際に入れるテンプレート

ObsidianのコアTemplatesでは、{{title}}、{{date}}、{{time}}などを利用でき、テンプレート内のPropertiesも新しいノートへ統合される。

Daily Note

type: daily

created: "{{date:YYYY-MM-DD}}"

status: active

今日の勝ち筋

[ ] 今日これだけは終わらせる：
[ ] 二番目：
[ ] 三番目：

Timeline

{{time:HH:mm}}

Decisions

Captures

Friction Log

何を探したが、見つからなかったか：
どの作業で認知負荷が高かったか：

End of Day

[ ] 独立して残す内容をInboxまたはNotesへ移した
[ ] 重要な判断をDecision Noteにした
[ ] 明日の最初の行動を決めた

Friction Logが重要である。

「何を探したが見つからなかったか」を記録すると、実際の検索失敗に基づいてVaultを改善できる。

見た目の好みではなく、失敗した検索から構造を進化させる。

Project Note

type: project

created: "{{date:YYYY-MM-DD}}"

status: active

owner: me

area:

due:

next_action:

topics: []

sensitivity: internal

Outcome

このプロジェクトが完了したと判断できる状態を書く。

Why Now

なぜ今やるのか。やらない場合のコストは何か。

Constraints

期限：
予算：
人員：
やらないこと：

Current State

現在地を三行以内で説明する。

Next Actions

Decisions

Key People

Sources

Risks

Log

Project Noteはタスクの倉庫ではない。

誰かが30秒で現状を理解できる、プロジェクトの司令室にする。

Decision Note

高収益な仕事ほど、情報より意思決定の品質が重要になる。

したがって、Decision NoteはVault内で最も価値の高いノートタイプになる。

type: decision

created: "{{date:YYYY-MM-DD}}"

status: active

project:

owner: me

revisit:

confidence: medium

sensitivity: internal

Decision

何を決めたかを一文で書く。

Context

この判断が必要になった背景。

Options Considered

Option A

利点：

欠点：

Option B

利点：

欠点：

Do Nothing

何もしない場合に起きること：

Why This Option

この選択肢を選んだ理由。

Evidence

確認できている事実：
使用したデータ：
関連Source：

Assumptions

まだ検証できていない前提：

Reversal Trigger

何が起きたら、この判断を撤回または変更するか。

Expected Signal

判断が正しければ、どの指標が、いつ、どう変化するはずか。

Follow-up

最も重要なのはReversal Triggerである。

優秀な意思決定者は、正しさを主張し続ける人ではない。

どの条件で自分の判断を変更するかを、決定時点で書ける人である。

ClaudeやCodexへ「前提が崩れているDecisionを列挙して」と依頼できるのも、この構造があるからだ。

Source Note

type: source

created: "{{date:YYYY-MM-DD}}"

status: inbox

source_url:

author:

published:

topics: []

confidence: medium

sensitivity: internal

Source Summary

著者・発言者が主張している内容を、自分の評価と分離して書く。

Claims

Evidence Presented

My Interpretation

Counterarguments

What Changes If True

この内容が正しい場合、何を変えるべきか。

Promote

[ ] Evergreen Noteにする
[ ] Decisionに反映する
[ ] Projectに反映する
[ ] Outputで使う
[ ] 保存せず破棄する

「要約した」で終わらせない。

What Changes If Trueを必須にすると、情報収集が行動へ接続される。

Evergreen Note

type: note

created: "{{date:YYYY-MM-DD}}"

status: active

topics: []

source_notes: []

confidence: medium

sensitivity: internal

Claim

このノートで主張すること。

Explanation

自分の言葉で説明する。

Why It Matters

意思決定や行動へどう影響するか。

Evidence

Counterevidence

Use When

どのような状況でこのノートを参照するか。

Examples

Possible Outputs

Use Whenは、未来の検索意図を文章として保存する欄だ。

たとえば、

料金プランを改定するとき

高単価商品の営業トークを作るとき

顧客が価格に反対したとき

と書く。

この記述は、人間の検索にもAIの意味検索にも効く。

第8章　MOCはリンク集ではなく「編集された思考モデル」

MOC、Map of Contentを単なる目次にしてはいけない。

良いMOCには編集者の判断が入っている。

type: note

created: 2026-07-24

status: active

aliases:

Pricing MOC topics:
"[[価格戦略]]"

MOC 価格戦略

Current Thesis

現時点での自分の結論を三〜五行で書く。

Core Principles

[[価格は機能数より導入失敗リスクで決まる]]
[[割引は価格ではなく比較基準を破壊する]]
[[年額契約は資金回収より解約判断回数を減らす]]

Evidence

[[SRC 競合価格調査 2026-07]]
[[SRC 顧客インタビュー価格反対理由]]

Counterarguments

[[低価格参入が市場教育を加速する条件]]
[[価格弾力性が高い市場では値上げが逆効果になる]]

Open Questions

どの顧客セグメントで価格反対が最も強いか
導入支援を価格へ含めるべきか

Decisions

[[DEC 2026-07-24 年額プランを標準提案にする]]

Outputs

[[法人向け料金改定提案書]]

MOCは「関連ノート一覧」ではない。

現在の自分が、領域全体をどう理解しているかを圧縮した、編集済みの認知モデルである。

AIに自動生成させてもよいが、最終編集は人間が行う。

どの考えを中心へ置くかは、知識整理ではなく戦略判断だからだ。

第9章　Basesで「経営ダッシュボード」を作る

Obsidian Basesは、ノートのPropertiesをデータベースのように表示、フィルター、並び替えできるコア機能である。データは別の独自データベースへ移されるのではなく、MarkdownのPropertiesとして残る。.baseファイルとして保存したり、ノート内へ埋め込んだりできる。

Active Projects Base

90_System/Bases/Projects.baseを作る。

filters:

and:

'file.ext == "md"'
'type == "project"'

formulas:

missing_next_action: 'if(status == "active" && !next_action, "⚠ next actionなし", "")'

stale: 'if(status == "active" && file.mtime < now() - "14d", "14日以上更新なし", "")'

properties:

file.name:

displayName: Project

owner:

displayName: Owner

next_action:

displayName: Next Action

due:

displayName: Due

formula.missing_next_action:

displayName: Health

formula.stale:

displayName: Stale

views:

type: table name: Active filters: and:
'status == "active"' order:
file.name
owner
next_action
due
formula.missing_next_action
formula.stale

type: table name: Waiting filters: and:
'status == "waiting"' order:
file.name
owner
next_action

Basesでは複数ビューを持ち、Propertyやファイル情報を使ってフィルター、ソート、グループ化できる。today()やnow()、日付計算も公式構文に含まれている。

Decision Review Base

filters:

and:

'file.ext == "md"'
'type == "decision"'

formulas:

review_state: 'if(revisit && revisit <= today(), "要レビュー", "")'

properties:

file.name:

displayName: Decision

project:

displayName: Project

revisit:

displayName: Revisit

confidence:

displayName: Confidence

formula.review_state:

displayName: Review

views:

type: table name: Revisit Due filters: and:
'revisit'
'revisit <= today()' order:
file.name
project
revisit
confidence
formula.review_state

このBaseを見るだけで、「決めっぱなしになっている判断」を回収できる。

第10章　プラグインはTier制にする

Tier 0：コア機能だけ

まずは次で運用する。

Properties

Templates

Daily Notes

Bases

Backlinks

Outgoing Links

Bookmarks

Workspaces

Canvas

File Recovery

Random Note

これだけで大半のシステムは作れる。

Tier 1：明確な摩擦が出たら入れる

QuickAdd

一つのホットキーから、テンプレート作成、既存ノートへの追記、マクロ実行などをまとめられる。Capture、Template、Macro、Multi Choiceという仕組みを持つ。

おすすめは入力経路を次の四つに固定することだ。

Capture Idea

Create Meeting

Create Decision

Create Source

Templater

条件分岐、変数、JavaScriptを使う必要が出たら入れる。

ただし、Templaterは任意のJavaScriptやシステムコマンドを実行できる。理解していない外部テンプレートをそのまま使ってはいけない。

Tasks

複数ノートに分散したタスクを横断検索したい場合に入れる。期限、繰り返し、完了状態、絞り込みに対応し、クエリ上で完了すると元ノートも更新される。

Tier 2：Basesで足りない場合だけ

Dataview

MarkdownのFrontmatterやインラインフィールドを索引化し、クエリやJavaScriptで表示できる。

ただし、DataviewJSはVaultの書き換え、ファイル作成・削除、ネットワークアクセスも可能である。通常のDataview Queryよりリスクが高い。

原則はこうする。

BasesでできるならBases。 Dataviewでしかできない場合だけDataview。 DataviewJSは、自分で読んで理解できるコードだけ。

プラグイン数に絶対的な上限はないが、私ならアクティブなCommunity Pluginを12個以内にする。

各プラグインに次を記録する。

導入目的

代替手段

データの保存形式

プラグインを外した場合に失われる機能

最後に使った日

削除条件

第11章　2026年の決定的変化――Obsidian公式CLI

古いObsidian解説では、ターミナル連携に非公式スクリプトやURIを使う例が多い。

しかし2026年7月時点では、Obsidianに公式CLIがある。

CLIはObsidian 1.12系のインストーラーが必要で、現在の公式案内では1.12.7以上が推奨されている。デスクトップ版Obsidianをターミナルから操作し、検索、読み込み、作成、Property更新、リンク調査、タスク操作、テンプレート、Basesなどを扱える。

今日のDaily Noteを開く

obsidian daily

Daily Noteへ追記する

obsidian daily:append content="- [ ] 顧客インタビューを整理する"

Vaultを検索する

obsidian search query="価格改定"

周辺行つきで検索する

obsidian search:context query="Reversal Trigger"

ノートを読む

obsidian read path="20_Projects/PJT 法人向け料金体系の再設計.md"

テンプレートから作成する

obsidian create \

path="20_Projects/PJT 新プロジェクト.md" \

template="Project"

Propertyを設定する

obsidian property:set \

path="20_Projects/PJT 新プロジェクト.md" \

name=status \

value=active \

type=text

Backlinkを確認する

obsidian backlinks path="40_Notes/価格戦略.md"

未解決リンクを調べる

obsidian unresolved counts

Incoming Linkのないノートを調べる

obsidian orphans total

未完了タスクを一覧する

obsidian tasks todo

CLIでmoveやrenameを実行すると、Obsidian側で「内部リンクを自動更新」が有効ならリンクも更新される。単純なOSのmvより安全である。

これによってClaudeやCodexは、Markdownを直接編集するだけでなく、Obsidian自身の解決ロジックを使って操作できる。

なお、公式CLIはデスクトップ版を制御するものだ。デスクトップ版なしでサーバー上のVaultを同期する場合は、オープンベータのObsidian Headlessを使う。HeadlessはNode.js 22以上を必要とし、リモートバックアップ、定期処理、エージェントへPC全体ではなくVaultだけを渡す用途などが公式に想定されている。

第12章　AIネイティブVaultの正しい構造

AIに全部のノートを自由に編集させるのは、AI活用ではない。

それは、監査されていないインターンへ会社の全資料を渡すのと同じだ。

正しい役割分担はこうなる。

担当役割人間目的、価値判断、最終承認、MOC編集Obsidian原本、関係、履歴、ビューClaude意味の蒸留、比較、反証、文章化Codex構造変更、スクリプト、検証、差分レビューGit復旧、監査、実験の分離ValidatorSchema違反、リンク異常、形式崩れの検出

ClaudeとCodexに同じ仕事を競わせる必要はない。

私なら、Claudeには意味中心の仕事を割り当てる。

会議から論点・決定・未解決事項を抽出

複数Sourceを比較して主張と反証を整理

過去のDecisionと現在の状況の矛盾を探す

Evergreen Note候補を提案

記事・提案書のアウトラインを作る

Codexにはリポジトリ中心の仕事を割り当てる。

Property Schemaの一括移行

命名規則違反の検出

重複ファイルの調査

CLIスクリプトの作成

Basesやテンプレートの生成

Validatorの実装

Git差分を伴う大規模修正

Obsidianプラグインの開発とテスト

これはモデルの優劣ではない。

意味を考える工程と、構造を壊さず変更する工程を分離するための設計だ。

第13章　CLAUDE.mdとAGENTS.mdを置く

Claude CodeはプロジェクトのCLAUDE.mdを継続的な指示として読み込む。一方、Skillsは必要なときだけ全文が読み込まれる。ClaudeのAuto Memoryは学習したパターンを保持するが、強制したいルールの置き場所ではない。

CodexはAGENTS.mdをプロジェクトルートから現在の作業ディレクトリまで探索し、より近いファイルの指示を優先する。公式ベストプラクティスでも、永続的なルールはAGENTS.md、繰り返す手順はSkillsへ分けることが推奨されている。

VaultルートのCLAUDE.mdとAGENTS.mdには、まず同じ契約を書く。

Vault Operating Contract

This repository is an Obsidian vault whose source of truth is Markdown.

Language and format

Write prose in Japanese unless explicitly requested otherwise.
Use ASCII snake_case for property names.
Use ISO dates: YYYY-MM-DD.
Preserve valid YAML frontmatter.
Quote Wikilinks used inside properties.

Safety

Default to dry-run for bulk work.
Never delete, rename, move, or overwrite files without explicit approval.
For moves and renames, prefer Obsidian CLI so internal links can be updated.
Never fabricate sources, quotes, evidence, dates, or links.
Separate observed facts, source claims, model inference, and decisions.
Do not read or edit notes under 90_Private/.
Do not process notes with \sensitivity: never_ai\.

Writing locations

Put unreviewed AI drafts in \00_Inbox/AI/\.
Put approved output drafts in \70_Outputs/Drafts/\.
Do not directly promote AI-generated text to \40_Notes/\ without review.

Schema

Before creating or editing typed notes, read:

\90_System/Schemas/note-types.md\
\90_System/Schemas/property-vocabulary.md\

Validation

Before edits:

Run \git status\.
State which files will change.

After edits:

Run \python scripts/vault_check.py\.
Run \git diff --check\.
Summarize changed files, assumptions, and unresolved issues.

CLAUDE.mdやAGENTS.mdへ全業務手順を書き込まない。

毎セッション必要な規則だけを書く。

長い手順はSkillsへ移す。

第14章　Claude経由でObsidian業務をSkills化する

Claude CodeのSkillsは、SKILL.mdを中心にしたディレクトリで定義する。

プロジェクト固有Skillは次へ置く。

.claude/skills/<skill-name>/SKILL.md

個人共通Skillは次へ置く。

~/.claude/skills/<skill-name>/SKILL.md

ClaudeはSkillの説明を見て必要時に読み込むほか、/skill-nameで明示実行できる。

Skill化する判断基準

次のどれかに該当したらSkillにする。

同じ指示を三回以上書いた
同じチェックリストを毎週使う
CLAUDE.md内の一節が長い手順になった
成果物の形式を毎回修正している
実行後に必ず同じ検証をする
人によって品質がぶれる業務を標準化したい

逆に、一度しか行わない仕事はSkillにしない。

共有Skill：obsidian-distill

まず、次を作る。

90_System/AgentSkills/obsidian-distill/

├── SKILL.md

├── references/

│ ├── schema.md

│ ├── good-examples.md

│ └── evals.md

└── scripts/

└── check_output.py

SKILL.mdは次のようにする。

name: obsidian-distill

description: ObsidianのInbox、Daily、Meeting、Sourceノートを、出典を保持したEvergreen Note、Decision、Task、Projectリンクへ蒸留する。ユーザーが「整理」「蒸留」「promote」「会議メモから決定を抽出」「Sourceから知識化」と依頼したときに使う。破壊的な一括変更やファイル名移行には使わない。

Goal

Convert a raw Obsidian note into reusable knowledge without losing provenance,

introducing unsupported claims, or prematurely fragmenting context.

Default mode

Operate in dry-run mode unless the user explicitly says to apply or write changes.

Required inputs

Target note path
Intended use, when known
Related project, when known

Read first

Read \CLAUDE.md\ and \AGENTS.md\ if present.
Read \90_System/Schemas/note-types.md\.
Read the complete target note.
Inspect its frontmatter and outgoing links.

Classification

Separate the source into:

Observed facts
Claims made by a source or participant
User interpretation
Model inference
Decisions
Tasks
Open questions
Candidate durable insights

Never merge these categories without labeling the result.

Retrieval search

Before proposing new durable notes:

Extract 3–7 distinctive search phrases.
Search the vault for existing related notes.
Inspect likely duplicates.
Inspect backlinks of the related project or MOC.
Prefer enriching an existing note over creating a near-duplicate.

Use Obsidian CLI when available:

\obsidian search\
\obsidian search:context\
\obsidian backlinks\
\obsidian links\

Promotion rules

Create a Decision candidate when the source contains:

a chosen option,
a commitment,
a rejected alternative,
or a condition that changes future action.

Create an Evergreen candidate only when:

the idea is understandable outside the source context,
the claim can be expressed in the user's own words,
provenance can be linked,
and a future use case can be stated.

Keep information in the Source note when it is mainly evidence, quotation,

or source-specific detail.

Proposal output

Before writing, report:

Proposed files to create
Proposed files to update
Proposed links
Decisions and tasks extracted
Claims that require verification
Potential duplicates
Information that should remain unpromoted

Write rules

Only after explicit approval:

Preserve the original source note.
Add \source_notes\ links to promoted notes.
Use only allowed property vocabulary.
Put uncertain material under \## Open Questions\ or \## Assumptions\.
Do not convert model inference into \## Evidence\.
Do not create fabricated Wikilinks solely to make the graph look connected.

Validation

After writing:

Run \python scripts/vault_check.py\.
Run \git diff --check\.
Review the diff for accidental deletions.
Report changed paths and unresolved warnings.

Completion format

Return:

Files created
Files updated
Decisions extracted
Tasks extracted
Assumptions
Validation result
Recommended human review

Skillのdescriptionは説明文ではなくルーターである。

「いつ使うか」と「いつ使わないか」を明確に書く。

ClaudeもCodexも、Skillの全文を常時コンテキストへ入れるのではなく、名称やDescriptionを手掛かりに必要時に読み込む方式を取っている。

Skillのテストケース

references/evals.mdを作る。

Positive triggers

この会議メモをDecisionとNext Actionに蒸留して
このSource Noteから再利用可能な知識を抽出して
DailyのメモをProjectとEvergreenへ整理して
この顧客インタビューから仮説と反証を作って

Negative triggers

Vault全体のファイル名を一括変更して
古いノートを全部削除して
Dataviewプラグインを修正して
Git履歴を整理して

Required behavior

Default is dry-run.
Original source remains.
No unsupported facts are created.
New durable notes contain provenance.
Decision candidates contain assumptions and reversal triggers.
Existing related notes are searched before creating new notes.

Failure conditions

Writes before approval
Missing source_notes
Invented quotes
Invented URLs
Duplicate note creation without search
Moving files with raw filesystem commands when Obsidian CLI is available

優れたSkillは「賢そうな指示」ではない。

入力、手順、禁止事項、完了条件、失敗条件が明示された再実行可能な作業標準である。

第15章　同じSkillをCodexでも使う

CodexもオープンなAgent Skills形式を採用しており、SkillはSKILL.mdと任意のscripts/、references/、assets/などで構成される。

リポジトリ固有Skillの保存先は、2026年7月時点では次である。

.agents/skills/<skill-name>/SKILL.md

Codexは現在の作業ディレクトリからリポジトリルートまで、各階層の.agents/skillsを探索する。ユーザー共通Skillは~/.agents/skillsへ置く。明示実行は$skill-nameまたはSkill選択UIを使える。

ここで重要なのは、Claude用Skillを.agents/skillsへ直接置くだけではClaudeから見えず、Codex用Skillを.claude/skillsへ置くだけではCodexから見えないことだ。

したがって、原本を一つにする。

90_System/AgentSkills/

そして、両方へ同期する。

scripts/sync_skills.py：

#!/usr/bin/env python3

from __future__ import annotations

import shutil

from pathlib import Path

ROOT = Path(__file__).resolve().parents[1]

SOURCE = ROOT / "90_System" / "AgentSkills"

DESTINATIONS = [

ROOT / ".claude" / "skills",

ROOT / ".agents" / "skills",

]

def copy_skill(source: Path, destination_root: Path) -> None:

destination = destination_root / source.name

if destination.exists():

shutil.rmtree(destination)

shutil.copytree(source, destination)

print(f"synced: {source.relative_to(ROOT)} -> {destination.relative_to(ROOT)}")

def main() -> None:

if not SOURCE.exists():

raise SystemExit(f"Missing skill source directory: {SOURCE}")

skills = sorted(path for path in SOURCE.iterdir() if path.is_dir())

if not skills:

raise SystemExit(f"No skills found under: {SOURCE}")

for destination in DESTINATIONS:

destination.mkdir(parents=True, exist_ok=True)

for skill in skills:

if not (skill / "SKILL.md").exists():

raise SystemExit(f"Missing SKILL.md: {skill}")

copy_skill(skill, destination)

if __name__ == "__main__":

main()

実行：

python scripts/sync_skills.py

共有SkillのFrontmatterは、原則として標準的なnameとdescriptionだけにする。

Claude固有のallowed-toolsやcontext: forkなどを共有原本へ入れると、他のエージェントでの互換性が下がる可能性がある。

プラットフォーム固有設定は、薄いラッパーや設定ファイルへ分離する。

破壊的Skillは明示実行だけにする

たとえばobsidian-apply-migrationのような書き込みSkillは、自動起動させない。

Claude固有版では次を使える。

name: obsidian-apply-migration

description: 承認済みのObsidian Schema移行計画を適用する。明示的に呼び出された場合だけ使う。

disable-model-invocation: true

ClaudeのSkillsではdisable-model-invocationを使い、モデルによる自動呼び出しを無効にできる。

Codex側ではSkill内のagents/openai.yamlに次を置く。

policy:

allow_implicit_invocation: false

Codexはこの設定により、明示的に指定した場合だけSkillを起動する構成にできる。

第16章　Codexへ依頼するときの本気のプロンプト

Codex公式のベストプラクティスでは、依頼にGoal、Context、Constraints、Done whenを含めると、スコープが安定しやすいとされている。

悪い依頼：

Vaultを整理して

良い依頼：

$obsidian-vault-audit

Goal:

20_Projects配下のProject Noteについて、Schema違反と運用上の停止を検出する。

Context:

AGENTS.md
90_System/Schemas/note-types.md
90_System/Bases/Projects.base
20_Projects/

Constraints:

今回はread-only。
ファイルの作成、編集、移動、削除をしない。
status、due、next_actionの存在だけで機械的に判断しない。
本文のCurrent StateとLogも読む。
個人情報を回答へ全文転載しない。

Done when:

Schema違反一覧がある。
14日以上更新されていないactive Project一覧がある。
next_actionが曖昧なProject一覧がある。
重複または統合候補がある。
修正案を優先順位順に提示している。
ファイル変更がゼロであることをgit statusで確認している。

一括移行なら、まずPlanだけ作らせる。

Goal:

既存の\category\ Propertyを\type\へ移行する計画を作る。

Constraints:

まだ変更しない。
categoryとtypeの両方があるファイルを別扱いにする。
値の対応表を推測せず、観測値を集計する。
Archiveとnever_aiは除外する。
Rollback手順を含める。

Done when:

対象ファイル数
値ごとの件数
衝突ファイル
移行スクリプト案
検証方法
Rollback方法が提示されている。

承認後に別ブランチで適用する。

git switch -c ai/migrate-category-to-type

codex --sandbox workspace-write --ask-for-approval on-request

Codexのローカル環境は、デフォルトでワークスペース外への書き込みやネットワーク利用を制限するサンドボックスを利用できる。workspace-writeでは作業領域内の編集を許可し、境界外やネットワークが必要な操作では承認を求める構成にできる。

第17章　Claude、Codex、Obsidian CLIの連携パターン

パターン1：会議メモの蒸留

DailyまたはMeeting Noteへ生ログを保存
Claudeで/obsidian-distillを実行
Claudeが既存ノートとDecision候補を検索
変更案だけを表示
人間が承認
ClaudeがDecision、Task、Evergreenを作成
Validatorを実行
Git差分を確認

パターン2：週次経営レビュー

Claudeへ次を依頼する。

/weekly-review

今週のDaily、active Project、Decision、Output Draftを確認し、

今週決まったこと
決まったが実行されていないこと
停止しているProject
崩れた前提
繰り返し発生した摩擦
来週のTop 3
Outputに変換できる知識

をまとめてください。

事実、推論、提案を分離し、原文リンクを付けてください。

変更は行わず、レポートだけ作ってください。

パターン3：Schema Drift監査

Codexへ依頼する。

$obsidian-vault-audit

Propertiesの型揺れ、表記揺れ、未使用Property、許可されていないstatus、

引用符のないWikilink、Frontmatterの壊れを検出してください。

今回は修正せず、件数、対象パス、修正方針、危険度を報告してください。

パターン4：決定の前提監査

Claudeへ依頼する。

20_Projects/PJT 法人向け料金体系の再設計.md と、

そこからリンクされているDecision Noteを調べてください。

最近のDaily、Source、Meetingと比較し、

すでに崩れているAssumption
弱くなったEvidence
Reversal Triggerへ近づいているDecision
検証されていないまま事実扱いされている主張

を列挙してください。

書き換えは行わず、根拠ノートへのリンクを付けてください。

これが「AIでノートを要約する」レベルを超えた使い方である。

AIを検索窓として使うのではなく、過去の自分の判断を監査する知的コントローラーとして使う。

第18章　Vault Validatorを入れる

AIがVaultを編集するなら、「見た感じ問題ない」で終わらせてはいけない。

最低限の静的検査を入れる。

scripts/vault_check.py：

#!/usr/bin/env python3

from __future__ import annotations

import re

from pathlib import Path

ROOT = Path(__file__).resolve().parents[1]

MANAGED_FOLDERS = {

"20_Projects",

"30_Areas",

"40_Notes",

"50_Sources",

"60_Entities",

"70_Outputs",

}

ALLOWED_TYPES = {

"inbox",

"daily",

"project",

"area",

"meeting",

"decision",

"source",

"note",

"person",

"company",

"output",

}

ALLOWED_STATUSES = {

"inbox",

"active",

"waiting",

"done",

"archived",

}

REQUIRED_BY_TYPE = {

"project": {"type", "created", "status", "next_action"},

"area": {"type", "created", "status"},

"meeting": {"type", "created"},

"decision": {"type", "created", "status"},

"source": {"type", "created", "status"},

"note": {"type", "created", "status"},

"person": {"type", "created"},

"company": {"type", "created"},

"output": {"type", "created", "status"},

}

FRONTMATTER_RE = re.compile(

re.DOTALL,

)

WIKILINK_RE = re.compile(r"!?\[\[([^\]]+)\]\]")

def parse_top_level_properties(frontmatter: str) -> dict[str, str]:

properties: dict[str, str] = {}

for raw_line in frontmatter.splitlines():

if not raw_line or raw_line.startswith((" ", "\t", "-")):

continue

if ":" not in raw_line:

continue

key, value = raw_line.split(":", 1)

properties[key.strip()] = value.strip().strip("\"'")

return properties

def vault_targets() -> tuple[set[str], set[str]]:

paths: set[str] = set()

names: set[str] = set()

for path in ROOT.rglob("*"):

if not path.is_file():

continue

if any(part in {".git", ".obsidian"} for part in path.parts):

continue

relative = path.relative_to(ROOT)

without_suffix = relative.with_suffix("").as_posix()

paths.add(without_suffix)

names.add(path.stem)

return paths, names

def main() -> int:

errors: list[str] = []

warnings: list[str] = []

known_paths, known_names = vault_targets()

markdown_files = sorted(ROOT.rglob("*.md"))

for path in markdown_files:

relative = path.relative_to(ROOT)

if not relative.parts:

continue

if relative.parts[0] not in MANAGED_FOLDERS:

continue

text = path.read_text(encoding="utf-8")

match = FRONTMATTER_RE.match(text)

if not match:

errors.append(f"{relative}: missing YAML frontmatter")

continue

properties = parse_top_level_properties(match.group(1))

note_type = properties.get("type", "")

status = properties.get("status", "")

if note_type not in ALLOWED_TYPES:

errors.append(

f"{relative}: invalid or missing type={note_type!r}"

)

else:

required = REQUIRED_BY_TYPE.get(note_type, set())

missing = sorted(

key for key in required if not properties.get(key)

)

if missing:

errors.append(

f"{relative}: missing required properties: "

", ".join(missing) )

if status and status not in ALLOWED_STATUSES:

errors.append(

f"{relative}: invalid status={status!r}"

)

for raw_target in WIKILINK_RE.findall(text):

target = target.split("#", 1)[0].strip()

target = target.removesuffix(".md").replace("\\", "/")

if not target:

continue

target_name = Path(target).name

if target not in known_paths and target_name not in known_names:

warnings.append(

f"{relative}: unresolved link [[{raw_target}]]"

)

if errors:

print("
ERRORS")

for item in errors:

print(f"- {item}")

if warnings:

print("
WARNINGS")

for item in warnings:

print(f"- {item}")

print(

f"
Checked {len(markdown_files)} Markdown files: "

f"{len(errors)} errors, {len(warnings)} warnings"

)

return 1 if errors else 0

if __name__ == "__main__":

raise SystemExit(main())

これは完全なYAML Parserではない。

しかし、最初の防波堤としては機能する。

将来的にはPyYAMLなどを使い、

Property型
日付形式
重複ID
許可されたフォルダ
Decision本文の必須見出し
Sourceの出典欠落
AI生成物のProvenance
個人情報ルール

まで検査できる。

第19章　Gitを必須にする

ObsidianはMarkdownフォルダなのでGitとの相性が良い。

.gitignoreは最低限、次のようにする。

.DS_Store

Thumbs.db

.trash/

.obsidian/workspace.json

.obsidian/workspaces.json

90_Private/

*.tmp

Obsidian公式も、workspace.jsonとworkspaces.jsonはファイルを開くたびに変化しやすいため、Git管理時は無視する選択肢を案内している。

AIによる大規模変更は、必ずブランチを切る。

git status

git switch -c ai/normalize-project-schema

ClaudeまたはCodexで変更

python scripts/vault_check.py

git diff --check

git diff --stat

git diff

変更が大きい場合は、別Worktreeを使う。

git worktree add ../MyVault-AI -b ai/vault-refactor

AIはMyVault-AIだけを編集する。

人間が差分を確認してから、本体へ取り込む。

第20章　セキュリティ――「AIに読ませない」を文章ではなく設定にする

「機密ファイルを読まないで」とCLAUDE.mdに書くだけでは弱い。

Claude Codeでは.claude/settings.jsonのpermissions.denyで、特定パスのReadを拒否できる。拒否対象はファイル検索結果からも除外される。

{

"$schema": "https://json.schemastore.org/claude-code-settings.json",

"permissions": {

"deny": [

"Read(./90_Private/\\)",

"Read(./\\/.env)",

"Read(./\\/.env.*)",

"Read(./secrets/\\)",

"Read(./credentials/\\)"

"ask": [

"Bash(git push *)",

"Bash(obsidian delete *)",

"Bash(rm *)"

]

}

Claude Codeは基本的に読み取り中心から開始し、編集やシステム変更につながるコマンドでは権限を求める設計を持つ。ただし、自動承認や権限緩和は安全を保証するものではない。

Codexは.codex/config.tomlを次のようにする。

sandbox_mode = "workspace-write"

approval_policy = "on-request"

[sandbox_workspace_write]

network_access = false

writable_roots = []

Codexのworkspace-writeでは、通常は作業領域内の書き込みに限定し、ネットワークはデフォルトで無効にできる。まず狭く始め、必要な権限だけを追加する。

そして、最も重要な原則がある。

AIに絶対読ませてはいけないデータは、AIを起動するVaultへ置かない。

設定ミス、コピー、添付、リンク先、バックアップなどを考えると、物理分離が最も強い。

第21章　Daily、Weekly、Monthlyの運用

Daily：5分

朝：

Dailyを開く
今日の勝ち筋を最大三つ書く
active ProjectのNext Actionを確認する

日中：

小さいメモはDaily
独立した入力はInbox
重要な判断だけDecision

夜：

Decision候補を昇格
明日の最初の行動を書く
見つからなかった情報をFriction Logへ書く

Dailyで整理しすぎない。

Weekly：30〜45分

週次レビューでは、次だけを見る。

Inbox

古い順に処理する。

各入力を、

Delete

Monthly：60〜90分

月次ではシステムそのものを監査する。

使用していないProperty
表記揺れ
14日以上停止したProject
リンクのない重要ノート
肥大したMOC
使っていないプラグイン
AI Skillの失敗事例
Restoreのテスト
GitまたはSyncの確認

Graphはここで使う。

毎日眺めるのではなく、孤立クラスタ、異常なハブ、知識の偏りを調査するために使う。

第22章　測るべきKPI

私なら90_System/Metrics/へ月次レポートを残す。

Operational Health

Inboxの最古日数

active Project数

next_actionのないactive Project率

14日以上停止したProject数

期限超過Project数

Knowledge Health

SourceからEvergreenへ昇格した件数

SourceからOutputへ使われた件数

新しいMOC数ではなく、更新されたMOC数

未解決リンク数

検索失敗件数

Decision Health

今月作ったDecision数

Reversal Triggerがある割合

Revisit Dateがある割合

前提が崩れて変更されたDecision数

決めたが実行されなかったDecision数

Output Health

公開または提出した成果物数

一つ以上の既存ノートを再利用した成果物率

Sourceから成果物までの日数

一つの知識が複数成果物へ使われた回数

AI Health

AIが変更したファイル数

Validator合格率

人間が差し戻した変更率

重複ノート作成件数

出典欠落件数

Skillの誤起動件数

最重要指標は、ノート数ではない。

既存ノートを使って、どれだけ速く良い判断や成果物を作れたかである。

第23章　私自身なら、どうやってObsidianを「完璧」に使いこなすか

私は人間のように日々一つのVaultを生活の中で所有しているわけではない。

したがって、ここは体験談ではなく、これまで見た失敗パターン、海外事例、検索設計、エージェント設計からの推論になる。

私が自分の知的活動をObsidianへ実装するなら、次の九原則を絶対に守る。

原則1　保存前に分類せず、昇格時に分類する

入力時はInboxまたはDailyだけ。

構造化は「再利用価値が確認された後」に行う。

原則2　すべての昇格ノートに未来の利用場面を書く

Use Whenを必須にする。

未来の自分が悩んでいる状況を、文章で保存する。

原則3　すべての重要情報に二つの検索経路を持たせる

一つは人間用。

タイトル

MOC

リンク

Alias

もう一つは機械用。

type

status

project

created

topics

これをTwo-Key Retrieval Ruleと呼ぶ。

片方が壊れても、もう片方で見つかる。

原則4　事実、主張、解釈、判断を混ぜない

AI時代は特に重要だ。

Source Claim

Evidence

My Interpretation

Model Inference

Decision

を見出しで分離する。

AIが作った「もっともらしい解釈」が、数カ月後に事実として再利用される事故を防ぐ。

原則5　Decisionを第一級オブジェクトにする

会議記録よりDecisionを優先する。

会議は消費されるが、Decisionは未来の行動を拘束する。

したがって、

何を決めたか

なぜ決めたか

何を却下したか

どの前提に依存したか

何が起きたら変えるか

を残す。

原則6　OutputをVaultの外側に置かない

記事を書くときだけGoogle Docsへ行き、提案書を作るときだけPowerPointへ行き、完成後のリンクだけ残す運用は弱い。

構想、論点、使用ノート、反証、構成をまずObsidian側へ置く。

最終フォーマットだけ外部ツールへ出す。

原則7　AIを「自動整理係」にしない

AIに毎日すべてを自動分類させると、静かに誤分類が蓄積する。

AIには次をさせる。

候補を作る

矛盾を探す

不足を指摘する

比較する

形式を検証する

差分を説明する

人間は次を行う。

何を残すか

何が重要か

どの判断を採用するか

どの考えを中心へ置くか

原則8　壊れる前提で作る

プラグインが消える。

Property名を変えたくなる。

AIが誤編集する。

同期が競合する。

だから、

Markdownを原本にする
Gitを使う
Plugin依存を局所化する
Schemaを文書化する
Validatorを持つ
大規模変更をブランチで行う
定期的に復元テストする

原則9　美しさではなく、検索失敗から改善する

フォルダを眺めて「なんとなく汚い」と感じたから再設計するのではない。

次の事実が起きたときだけ変更する。

必要な情報が見つからなかった

同じノートを二度作った

AIが誤ったtypeを選んだ

Projectの現状を再構築できなかった

判断理由が分からなかった

出典と自分の考えが混ざった

Outputへ再利用できなかった

これらは具体的な障害である。

障害を直すためにSchemaやMOCを変える。

そうすれば、Vaultは趣味の庭ではなく、実用システムとして進化する。

第24章　30日で構築する順番

1〜3日目：最小Vault

作るのはこれだけ。

00_Inbox

10_Daily

20_Projects

40_Notes

50_Sources

70_Outputs

90_System/Templates

99_Archive

有効化するのはCore Plugin中心。

Daily、Project、Decision、Sourceの四テンプレートを作る。

4〜7日目：ProjectとDecision

既存の全ノートは移行しない。

現在進行中のProjectだけ作る。

今週の重要判断からDecision Noteを始める。

古い情報は、必要になったときだけ移行する。

これをMigration on Touchと呼ぶ。

2週目：検索経路

実際に検索した言葉を記録する。

Aliasを追加する。

MOCを二つか三つだけ作る。

PropertiesとBasesでactive Project、Decision Reviewを表示する。

3週目：GitとValidator

Git管理を開始する。

.gitignoreを設定する。

vault_check.pyを導入する。

一括変更は必ずブランチで行う。

4週目：Claude SkillsとCodex

最初にSkills化するのは三つだけでよい。

obsidian-distill

weekly-review

obsidian-vault-audit

Claudeで意味の蒸留を行う。

CodexでSchema監査とValidator改善を行う。

そして、Skillの失敗例をevals.mdへ追加する。

Skillは一度書いて完成ではない。

失敗事例をテストへ変え、徐々に信頼性を上げる。

結論――完成形は「すべてを知っているVault」ではない

完璧なObsidianとは、ノートが何万件もあるVaultではない。

Graphが宇宙のように光っているVaultでもない。

プラグインを50個入れたVaultでもない。

完璧に近いVaultとは、

入力が速い
必要なときに見つかる
過去の文脈を復元できる
重要な判断理由が残っている
情報が成果物へ変換される
AIが安全に扱える
壊れても復旧できる
使うほど自分の判断パターンが見える

Vaultである。

最終形を一文で言えば、こうなる。

Obsidianを記憶の倉庫としてではなく、意思決定をコンパイルする知識リポジトリとして設計する。

Markdownは原本。

Propertiesは型。

Linksは意味。

MOCは人間の編集判断。

Basesは現在地。

Decision Noteは経営判断の履歴。

Claude Skillsは思考手順の再利用。

Codexは構造変更と検証。

Obsidian CLIはそれらをつなぐ操作境界。

Gitは失敗しても戻れる保証。

ここまで構築すると、Obsidianは「メモアプリ」ではなくなる。

自分が何を学び、何を信じ、何を疑い、なぜ決め、何を作り、その結果どこを修正したか。

それらが連続した一つのシステムになる。

そして、本当に大きな差を生むのは、知識を持っていることではない。

必要な瞬間に、正しい知識と過去の判断を呼び戻し、次の行動へ変換できることだ。

天才や高所得者だけが実践している Obsidian 構築術

AIでお金を生むのは「メモの量」ではない

第1章 海外事例を調べると、勝ち筋は「整理」ではなく「検索」だった

1. 研究者7人のVaultから分かったこと

2. Nicole van der Hoeven――ノートをキャリアの学習装置にする

3. Bruno Paz――ローカル、Markdown、最小プラグイン

4. Ian O’Byrne――情報を「Consume → Curate → Create」へ流す

第2章 「1億円Vault」を定義する6つの指標

1. Capture Latency

2. Retrieval Time

3. Context Reconstruction Cost

4. Decision Traceability

5. Output Conversion Rate

6. Agent Executability

第3章 日本人が使いやすいVaultの完成構造

00_Inbox

10_Daily

20_Projects

30_Areas

40_Notes

50_Sources

60_Entities

70_Outputs

90_System

一つのVaultにするべきか

第4章 フォルダ、Properties、Links、Tagsの役割を混ぜない

フォルダは「ライフサイクル」

Propertiesは「機械が扱う型と状態」

Linksは「意味関係」

Tagsは「一時的な横断状態」

第5章 最小Property Schema

Capture段階

Promoted段階

Operational段階

第6章 日本語ファイル名のルール

第7章 実際に入れるテンプレート

Daily Note

{{date:YYYY-MM-DD}}

今日の勝ち筋

Timeline

Decisions

Captures

Friction Log

End of Day

Project Note

{{title}}

Outcome

Why Now

Constraints

Current State

Next Actions

Decisions

Key People

Sources

Risks

Log

{{date:YYYY-MM-DD}}

Decision Note

{{title}}

Decision

Context

Options Considered

Option A

Option B

Do Nothing

Why This Option

Evidence

Assumptions

Reversal Trigger

Expected Signal

Follow-up

Related

Source Note

{{title}}

Source Summary

Claims

Evidence Presented

My Interpretation

Counterarguments

What Changes If True

第1章　海外事例を調べると、勝ち筋は「整理」ではなく「検索」だった

第2章　「1億円Vault」を定義する6つの指標

第3章　日本人が使いやすいVaultの完成構造

第4章　フォルダ、Properties、Links、Tagsの役割を混ぜない

第5章　最小Property Schema

第6章　日本語ファイル名のルール

第7章　実際に入れるテンプレート

第8章　MOCはリンク集ではなく「編集された思考モデル」

第9章　Basesで「経営ダッシュボード」を作る

第10章　プラグインはTier制にする

第11章　2026年の決定的変化――Obsidian公式CLI

第12章　AIネイティブVaultの正しい構造

第13章　CLAUDE.mdとAGENTS.mdを置く

第14章　Claude経由でObsidian業務をSkills化する

第15章　同じSkillをCodexでも使う