前編の「Obsidianプロパティ設計｜最小構成の作り方」では、3〜4項目から始める基本ルールと、型・語彙を統一する考え方を紹介しました。
型が決まったら、次に気になるのは「実際の運用でどう回すか」という部分だと思います。この記事では、以下の3つを持ち帰れる形でまとめました。
- 用途別にそのままコピペできるYAMLテンプレート
- 部品（モジュール）を組み合わせてプロパティを自作する考え方
- TemplaterやBasesと連携した自動化・一覧化のフロー
「型は理解したけど、自分のVaultにどう当てはめればいいか分からない」という方向けの実践編です。
コピペで即使える！用途別プロパティ実装パターン
各テンプレートの冒頭には「このプロパティでどんな問いに答えたいか」を示しています。目的を先に決めておくと、必要なプロパティと不要なプロパティの見分けがつきやすくなります。
※以降のYAML内のコメント（#以降）は、各プロパティのデータ型を示しています。
ブログ・Web記事管理（制作フローと公開予約の分離）
答えたい問い：下書き中（draft）の記事だけをBasesで一覧化し、公開予定日順に並べたい
---
title: 記事タイトル # テキスト (Text)
type: blog # テキスト (Text)
status: draft # テキスト (Text: inbox/research/draft/scheduled/published/archived)
created: 2026-09-03 # 日付 (Date)
updated: 2026-09-03 # 日付 (Date)
scheduled_date: 2026-09-10 # 日付 (Date: 予約投稿日)
published: 2026-09-10 # 日付 (Date: 実際の公開日)
series: Obsidian プロパティ設計 # テキスト (Text)
category: 技術 # テキスト (Text)
tags: [obsidian, properties, template] # リスト (List / Tags)
source: 参照元 # テキスト (Text)
priority: 2 # 数値 (Number: 1〜5)
word_count: 0 # 数値 (Number)
---
- 予定と実績を分ける：
scheduled_dateとpublishedを分けておくと、予約投稿と公開実績が混同しません。 - シリーズ一覧に活用：
seriesにシリーズ名を入れておくと、MOC（目次ノート）作成時に一覧抽出が楽になります。 - Basesで進捗管理：
statusで執筆工程を可視化できるため、status: draftで絞り込めば「今書きかけの記事一覧」ができます
実装例：実際に使用しているプロパティ
これは、実装例とは異なる、私が実際に使用しているブログ記事用のプロパティです。
- type（固定）：DataViewやMOC作成で可視化しやすくするため
- status（進行状況）：BaseBoardで一目で進捗確認できるように
- slug（スラッグ）：実際に使用するスラッグをあらかじめ記入
- url（公開URL）：公開後、ノートから即座にページへ遷移できます
- published / last_mod（日付）：公開日とリライト日をカレンダー表示するため
このようにご自身のノートに合わせて、柔軟に追加して使うことができます。
プロジェクト＆タスク管理（Basesと相性抜群の1ノート1タスク設計）
答えたい問い：遅延しているタスクはどれか？ 親プロジェクトごとの進捗率はどうなっているか？
タスクは1つのノート内に箇条書きするか、1ノート＝1タスクで独立させるか、2つの方法があります。おすすめは「1ノート＝1タスク」の設計です。Basesのテーブル・カード・Kanbanボードで、ステータスや担当者による絞り込みがそのまま効くためです。
プロジェクトノート：
---
type: project # テキスト (Text)
status: active # テキスト (Text: planning/active/on_hold/completed/cancelled)
area: Work # テキスト (Text: Work/Personal/Learning)
priority: high # テキスト (Text: high/medium/low)
created: 2026-09-03 # 日付 (Date)
due: 2026-12-31 # 日付 (Date)
progress: 45 # 数値 (Number: 0-100)
team: ["[[佐藤花子]]", "[[田中一郎]]"] # リスト型内部リンク (List of Links)
related: ["[[プロジェクトA要件書]]"] # リスト型内部リンク (List of Links)
---
タスクノート（1ノート＝1タスク）：
---
type: task # テキスト (Text)
task_name: API エンドポイントの実装 # テキスト (Text)
status: in_progress # テキスト (Text: todo/in_progress/done)
assignee: "[[佐藤花子]]" # 内部リンク (Link)
due_date: 2026-09-15 # 日付 (Date)
start_date: 2026-09-01 # 日付 (Date)
estimated_hours: 8 # 数値 (Number)
actual_hours: 5 # 数値 (Number)
priority: high # テキスト (Text)
dependencies: ["[[認証機能実装]]"] # リスト型内部リンク (List of Links)
labels: [backend, api, urgent] # リスト (List)
project: "[[プロジェクトA]]" # 内部リンク (Link: 親プロジェクトへの参照)
---
⚠️ 内部リンク型プロパティ（"[[ノート名]]"）は、ダブルクォートで囲むとYAMLパースエラーを防げます。ノート名に記号（:, [] など）が含まれる場合は特に重要です。
progressを数値で持たせておくと、Basesでゲージ表示と組み合わせて進捗を一目で確認できます。dependenciesでタスク間の依存関係をリンクしておけば、「先行タスクが終わっていないのに着手中」といった矛盾にも気づきやすくなります。
ナレッジ蓄積・活動記録（書籍・会議・アイデア）
読書メモ・会議記録・アイデア帳など、日々のインプットも目的に応じて最小限のプロパティで機能します。
書籍・学習メモ：
---
type: book # テキスト (Text)
title: 書籍タイトル # テキスト (Text)
author: "[[著者名]]" # 内部リンク (Link)
isbn: 978-4-123456-789 # テキスト (Text)
status: reading # テキスト (Text: to_read/reading/completed)
rating: 4 # 数値 (Number: 1-5)
started: 2026-09-01 # 日付 (Date)
finished: 2026-09-20 # 日付 (Date)
tags: [技術書, obsidian] # リスト (List / Tags)
summary: 3行要約 # テキスト (Text)
---
会議メモ：
---
type: meeting # テキスト (Text)
title: 定例ミーティング # テキスト (Text)
date: 2026-09-03 # 日付 (Date)
attendees: ["[[佐藤花子]]", "[[田中一郎]]"] # リスト型内部リンク (List of Links)
agenda: 進捗報告・課題共有 # テキスト (Text)
action_items: ["[[タスクA]]", "[[タスクB]]"] # リスト型内部リンク (List of Links)
next_meeting: 2026-09-10 # 日付 (Date)
---
アイデア・インサイト：
---
type: idea # テキスト (Text)
title: 新しい機能のアイデア # テキスト (Text)
created: 2026-09-03 # 日付 (Date)
area: Product # テキスト (Text)
status: backlog # テキスト (Text: backlog/evaluating/approved/rejected)
related: ["[[プロジェクトA]]"] # リスト型内部リンク (List of Links)
confidence: 3 # 数値 (Number: 1-5)
---
全てのテンプレートでtypeを明示している点が重要です。これにより「本だけ」「アイデアだけ」といった絞り込みがBasesで一瞬です。
組み合わせ自由！頻出プロパティ部品（モジュール）6選
プロパティを1から設計するのは思った以上に大変です。そこで活躍するのが「モジュール化」という発想。以下の6つのセットから、用途に応じて2〜3個を組み合わせるレゴブロック的な思考法をおすすめします。
- 日付3点セット ➜
created/updated/published（またはdue_date） - 進行管理セット ➜
status/priority/progress - 分類3層セット ➜
area（大分類） /category（中分類） /tags（キーワード） - リレーションセット ➜
assignee/dependencies/related/project - 数値評価セット ➜
rating/confidence/priority - 工数管理セット ➜
estimated_hours/actual_hours/start_date/due_date
使い方は簡単です。「読書メモ」なら①＋⑤（日付＋評価）で十分。「プロジェクト」なら②＋④（進行管理＋リレーション）を軸に。まずはどのセットを組み合わせるかで考え始めてみてください。
入力の手間をゼロにする「テンプレート自動化」の実装手順
プロパティは決まったものの、毎回手入力していては続きません。ここではTemplaterとLinterを使って、入力の手間を減らす方法を紹介します。
Templaterによる動的プロパティ生成
---
title: <% tp.file.title %>
type: <% tp.system.prompt("タイプを入力 (project/task/book)") %>
status: draft
created: <% tp.file.creation_date("YYYY-MM-DD") %>
updated: <% tp.file.last_modified_date("YYYY-MM-DD") %>
priority: 2
tags: []
---
💡 ポイントはtp.date.nowではなくtp.file.creation_dateを使うこと。tp.date.nowだと、テンプレートを再展開すると作成日が上書きされる事故が起こります。tp.file.creation_dateならファイル作成日を参照するため、この問題が回避できます。
Obsidian標準の「Templates」コアプラグインを使う場合は、<% %>構文の代わりに{{title}}や{{date}}といったプレースホルダーに置き換えてください。
Linterプラグインで並び順を自動統一
プロパティのキー順（例：title→type→status→created）がノートごとにバラバラだと、見返すときに読みにくくなります。Linterなら、この並び順をVault全体で自動統一できるため、プロパティ数が増えた段階で導入を検討するとよいでしょう。
参考・公式リポジトリ
破綻しない「自分専用プロパティ」設計の5原則
ここまで紹介したテンプレートをベースに、自分のVaultに合わせてカスタマイズしていく際に意識したい原則をまとめます。
- キー名はスネークケース統一（
duedate✗ →due_date✓）
DataViewやBases参照時のエラー防止 - 3〜5個から開始（いきなり増やさない）
- 手入力が必要なプロパティは作らない
- タグとプロパティで役割分け（タグ＝キーワード、プロパティ＝属性・状態）
- Basesで可視化してメリットを実感する
特に原則3は見落としがち。「あったら便利そう」でプロパティを増やすと、手入力が続かず形骸化します。Templaterで自動挿入できるかを、追加前の必須チェックにしましょう。
まとめ
前編でプロパティの基本ルールを紹介し、本記事では用途別YAMLテンプレートと自動化の仕組みをお伝えしました。
さっそく実装するなら、自分のVaultで最もよく使うノートタイプ（ブログ、プロジェクト、読書メモなど）を1つ選び、3〜5個のプロパティから始めてください。慣れてきたら、今回の6つのモジュールを組み合わせて拡張すると、堅牢なプロパティ設計に育てられます。
