ObsidianでYamlを使い倒すための、俺用メモ

Obsidian廃人です。

今回は、ObsidianのVault（ノート群）を「100年後も腐らないデータ」として残すためのYamlフロントマター活用を考えてみる。

過去に「Obsidianでも可搬性を意識した記法をしたほうがいい」と何度か書いてるんだけど、色々と妄想をこねくり回した結果、ひとつの真理に辿り着いた。

それは、「大事なのは、標準の厳格なフォーマットに準拠することじゃなくて、何十年も変わらずにシステムが読み込める普遍性だ」ってこと。

将来、Pythonスクリプトや次世代のAI（LLM）に自分のVaultを丸ごと読み込ませてRAGを構築するとき、メタデータが綺麗に整っていればブースターになる。でも、そのために「現在のツール（Obsidian）」と喧嘩してデータが破損するリスクを抱えては本末転倒。

そもそもマークダウンはただのテキストの記法。マークダウン自体が消えても、テキストは残る。テキストはPCが誕生したときから存在している「今後も無くなることのないデータ形式」といえる。

その普遍的なデータ形式であることと、見やすさバランスが良いのが、マークダウンの最大のメリットのはず。それであれば、Yamlもできるだけ普遍的な記載をすることで、高機能と普遍性を保てるのではないか、っていう妄想なんだな。

と、なにか仰々しいサムネ（Gemini作）と導入だったけど、この記事は、Yamlで最強のメタデータを構築するための、俺（非エンジニア）用の個人的なメモなのです。

これらは妄想の結果であって、運用を保証するものでもなく、未検証部分もあるからあくまでも自己責任でどうぞ。

なぜ「正規の規格」を捨てるのか？

Schema.orgなどの構造化データは強力。これを使えば、AIは「これは本のデータだ」と理解できるはず。しかし、Schema.orgの正規の記法である @context や @type をそのままYAMLにぶち込むと、「@」という記号がYAMLパーサーやObsidianのプロパティUIと猛烈に喧嘩してエラーを吐いてくる。

だから、「プレーンな英数字だけで構成する」というシンプルさが最強の生存戦略になると考える。仕様のカタチに人間が合わせるのではなく、プレーンテキストとして極限までシンプルに保つことで、ツールの寿命を超越する試みなんだな。

階層構造の平坦化（フラット・スキーマ）

YAMLは入れ子構造（リストやオブジェクト）が書けるけど、将来的にRAGに読み込ませる際、深く階層化されたデータは前処理が面倒になる。

• 避けるべき： プロパティ内に複雑なリストを入れすぎる。

• 推す： できる限りフラットにするか、命名規則で解決する。

❌ 将来のPython処理でパース時に階層確認が必要になる

author:
  name: "田中 太郎"
  role: "PM"

✅ フラットならCSV変換も一瞬

author_name: "田中 太郎"
author_role: "PM"

Obsidian方言をYAMLから徹底排除する

Obsidianが便利すぎるがゆえに生まれた「方言」は、YAML内で使うべきではない。
内部リンク（[[ ]]）はMarkdownの標準規格（CommonMark）ではないため、他のテキストエディタで正しくパースできない可能性がある。相対パスを使えば、Obsidianでも機能しつつ他ツールでも有効なリンクとして機能する。

❌ ダブルブラケット（内部リンク）

# Obsidianでは動くが、他ツールではただの文字列になる
project: [[プロジェクトA]]
author: [[田中 太郎]]

✅ 推奨：プレーンテキスト＋相対パス

project: "プロジェクトA"
project_path: "./projects/project-a.md"
author: "田中 太郎"

4/5 や 75% はYAMLではただの文字列として扱われる。数値計算・フィルタリングが必要なフィールドは必ずプレーンな数値型（Integer/Float）で保存する。

❌ Dataview独自の型注釈

# Dataviewのみ解釈できる（非推奨）
rating: 4/5
progress: 75%

✅ 推奨：汎用的な数値型

rating: 4
rating_max: 5
progress_percent: 75

Schema.orgのエッセンスを「安全に」取り入れる

AIやプログラムに「このノートが何者か」を伝えるためにSchema.orgの語彙（Book、Person、Eventなど）を使うが、前述の通り @ は絶対に使わない。

✅ 解決策：meta_ プレフィックスの採用

---
meta_format: "schema.org"
meta_type: "Book"

title: "星の王子さま"
author_name: "アントワーヌ・ド・サン＝テグジュペリ"
---

これならObsidianのプロパティUIでポチポチいじろうが、Dataviewで集計しようが多分バグらない。未来のAIやPythonも、meta_format: "schema.org" を見た瞬間に「これはSchema.orgの語彙を使っている」とメタ認識できるはずや。

時間と期間は「計算のしやすさ」を優先する

日付はISO 8601（2026-06-06）で統一するのが前提。しかし「期間（Duration）」の扱いには問題がある。

ISO 8601の正規の期間フォーマットは PT2H30M（2時間30分）だが、これは文字列のため、Dataviewや単純なスクリプトで「今月の合計勉強時間」を計算しようとすると地獄を見る気がする。

✅ 解決策：基準単位を設けた整数値

# ❌ 正規だけど計算できない
duration: "PT2H30M"

# ✅ 100年後の言語でも一瞬で集計できる
duration_minutes: 150

人間が見ても「150分か」と分かるし、どんなプログラムでも単純な数値として一発で足し算ができる。

実践サンプル（用途別フロントマター）

📚 書籍ノート

---
meta_format: "schema.org"
meta_type: "Book"
title: "サピエンス全史"
author: "ユヴァル・ノア・ハラリ"
isbn: "9784309226712"
publisher: "河出書房新社"
date_read: 2026-05-10
rating: 5
tags:
  - history
  - anthropology
---

🤝 人物ノート（個人CRM）

---
meta_format: "schema.org"
meta_type: "Person"
name: "田中 太郎"
job_title: "プロダクトマネージャー"
company: "株式会社テックスタート（仮）"
email: "taro@example.com"
urls:
  - "https://github.com/taro-"
knows_about:
  - "product-management"
  - "agile"
first_met_date: 2025-11-20
first_met_context: "ProductConf 2025 東京"
---

🍳 レシピ・料理メモ

---
meta_format: "schema.org"
meta_type: "Recipe"
title: "本格カルボナーラ"
category: "pasta"
cuisine: "italian"
prep_time_minutes: 10
cook_time_minutes: 20
yield_servings: 2
rating: 5
last_cooked: 2026-05-25
source_url: "https://example.com/carbonara"
difficulty: "medium"
tags:
  - pasta
  - italian
---

まとめ

閃いた「100年残るデータを作るための3ヶ条」

1. Obsidian方言（[[ ]] や 75%）をYAMLに持ち込まない

2. システムと喧嘩する記号（@）は避け、プレーンな英数字（meta_type）で意味を定義する

3. 期間や時間は、将来の計算が最も容易な「単純な数値（_minutes）」に落とし込む

規格にこだわるのではなく、極限までシンプルに保ち、どのエディタで開いても、どのプログラムでパースしても絶対に壊れない状態を作る。

本当に壊れないかは知らない。

え？試してから記事にしろ？

うるせぇ！俺は勝手にやるから、やりたいやつは人柱になれ！！

過去のObsidian記事

【追記】Yamlがいい感じになったらできそうなこと

以下、Geminiさんからのアイデア（俺は未タッチ）

フロントマターを極限までシンプルかつ機械可読性に優れたものに整備したなら、それを「宝の持ち腐れ」にしないための活用方法は、まさに「外部Pythonスクリプトによる自動加工・集計」が最適解です。

Obsidianのプラグイン（Dataviewなど）は便利ですが、ツール特有の閉じた環境です。Pythonを介せば、Vaultは「ただのテキストファイルの集合体」から「強力なデータベース」へと昇華します。

100年後の未来や、今のあなたがやりたいであろう「活かし方」をいくつか提示します。

1. 「VaultをJSON化してLLMに食わせる」パイプライン

RAG（検索拡張生成）の構築において最も重要なのは、「チャンク（分割されたテキスト）」に「適切なメタデータ」が付随していることです。

PythonでYAMLをパースし、以下のように変換してベクトルデータベース（FAISSやChromaDBなど）へ投入するパイプラインを組むのが理想です。

• 作業内容:

  1. ディレクトリを再帰的にスキャン。

  2. MarkdownからYAML部分（--- で囲まれた範囲）を抽出。

  3. PyYAML で辞書形式に変換。

  4. 本文（Content）とメタデータをセットにしてJSONL形式で保存。

これだけで、どんなAIでもあなたのVaultを「意味のある構造体」として読み込めるようになります。

2. 「meta_type」による自動レポート生成

例えば、「1ヶ月に読んだ本とその評価」を自動でレポート化する場合、Pythonなら複雑なクエリを書く必要はありません。

Python

import yaml
import glob

# meta_type: "Book" を持つノートを全抽出
books = []
for file in glob.glob("vault/**/*.md", recursive=True):
    with open(file, 'r', encoding='utf-8') as f:
        # 簡易的なフロントマター抽出
        content = f.read().split('---')[1]
        data = yaml.safe_load(content)
        if data.get('meta_type') == 'Book':
            books.append(data)

# PythonのPandasで集計（最強に楽）
import pandas as pd
df = pd.DataFrame(books)
print(df.groupby('author')['rating'].mean())

3. 表記ゆれ・構造のバリデーション（データクレンジング）

これが最も「100年残る」ためのメンテナンスとして重要です。

• 自動チェック機能:

  • meta_type: "Book" なのに isbn がないノートをリストアップする。

  • duration_minutes が数値型（int/float）ではないノートを検出する。

  • タグの使い方が統一されているか確認する。

次なる一歩：どう構築するか？

Pythonを導入する場合、以下の「3つの役割」でスクリプトを分けるのが、将来的に破綻しない秘訣です。

1. Extracter (抽出): MarkdownからYAMLと本文を安全に分離する機能。

2. Validator (検証): 決めたスキーマ（meta_typeが必要など）に合致しているかチェックする機能。

3. Exporter (変換): JSON、CSV、あるいは他のグラフDB形式に変換する機能。