私自身、Obsidianを使い始めた頃は「便利そうだけど、なにをどう使えばいいかわからない」と感じていました。そのため、プロパティの項目はデフォルトだけを使っていました。とりあえず作成日くらいは入っているものの、それ以外は特に意識せず放置していました。その結果、ノートが増えるにつれて「あのメモ、どこに書いたっけ」と探す手間がどんどん増えていきました。フィルターをかけようにも分類の軸になる項目がそもそもありません。結局フォルダを一つずつ開いて探す、という状態に陥ったのです。
この記事では、そんな「なんとなくデフォルトのまま」から抜け出すために整理した考え方をまとめました。プロパティを「検索・一覧化・自動化」のための道具として、無理なく使い続けるための工夫です。最小構成の作り方から、用途別の設計例、Basesやテンプレートを使った自動化、私が実際に使用しているプロパティ郡、そしてやってしまいがちな失敗パターンまで、実際に運用している設計をベースに紹介します。
なぜ今、Obsidianの「プロパティ」を見直すべきなのか
プロパティの本質は、ノートを装飾するための項目ではありません。「検索・一覧化・自動化のためのメタデータ」だと捉えると、設計がぐっとシンプルになります。基準にすべきは「このプロパティを使って、どんな質問に答えたいのか」です。そう考えると、なんとなく良さそうという理由だけで項目を増やしてしまう事態を避けやすくなります。
ここで整理しておきたいのが、フォルダ整理とプロパティ整理の役割の違いです。
- フォルダ＝ノートの物理的な置き場所を整理するもの
- プロパティ＝検索・フィルター・自動化のための論理的なタグ付け
フォルダを完全になくす必要はありません。添付ファイルやアーカイブなど、物理的にまとめておいた方が扱いやすいものはフォルダに任せましょう。そのうえで、「横断的に探したい・一覧化したい」という要求にはプロパティで応える、という棲み分けが現実的です。ノートを探すときは、Omnisearchのようなあいまい検索機能と組み合わせるのがおすすめです。フォルダ階層を意識せずに、目的のノートへたどり着きやすくなります（設定方法はOmnisearch設定ガイドで詳しく紹介しています）
【基本編】失敗しない最小構成（3〜4項目）
まずは基本編として、以下の4項目を意識して使ってみましょう。statusは必ずしも全体で統一する必要はありませんが、typeごとにわかりやすいもので固定して使うようにすると迷わなくなるはずです。
汎用メモの基本セット
最初から項目を増やしすぎず、以下の4項目から始めることをおすすめします。
| プロパティ | 役割 |
|---|---|
type | ノートの種類（note・blog・reviewなど）を分類する |
status | 進行状況（seedling・draftなど）を管理する |
category | テーマ・分野で分類する |
created | 作成日を記録し、時系列で並べ替えられるようにする |
この4項目だけでも、「種類でフィルターする」「進行状況で一覧化する」「作成日でソートする」という基本的な操作は一通りカバーできます。最初から項目を増やすより、慣れてきてから必要な項目を足していく方が挫折しにくいと感じています。
忘れがちな「型」の重要性
プロパティには、テキスト・数値・日付・チェックボックスといった「型」があります。これを意識しないと、ソートや集計が正しく機能しなくなるので注意が必要です。たとえば評価を表す rating というプロパティを考えたとき、次の2つは見た目が似ていても型がまったく異なります。
rating: "4" # テキスト型として扱われる
rating: 4 # 数値型として扱われる
前者はテキストとして扱われるため、数値としての大小比較やソートができません。コピペで値を入力していると、この違いに気づかないまま型が混在してしまうことがあります。
⚠️ 型が混在すると、Basesでのフィルターやソートが正しく機能しなくなります。特に数値・日付は入力時に型を意識しておくことをおすすめします。
表記揺れを防ぐ！ステータス値の固定ルール
キー名だけでなく、値（語彙）の表記揺れにも注意が必要です。たとえば同じ「進行中」という状態でも、progress と 進行中 のように表記が揺れることがあります。この状態でフィルターをかけると、片方しか拾えなくなってしまいます。
私は status の値を inbox progress draft published のように英語の固定語彙で統一しています。同じ種類のノート内では、この表記を崩さないようにしています。あとから見返しても「どの表記が正解だったか」で迷わずに済むため、地味ですが効果の大きい工夫だと感じています。
【実践編】用途別プロパティ設計パターン集
ここからは用途ごとに、実際に使えるプロパティ構成を紹介します。
※ コード内の <% tp.xxx %>（例: <% tp.file.creation_date("YYYY-MM-DD") %>）はコミュニティプラグイン「Templater」用の構文です。Templaterを使わずObsidian標準のテンプレート機能を利用する場合は、適宜 {{date}} や {{title}} に置き換えて活用してください。
知識ノート（エバーグリーンノート）
---
type: note
status: seedling
category:
- Obsidian
created: <% tp.file.creation_date("YYYY-MM-DD") %>
updated: <% tp.file.last_modified_date("YYYY-MM-DD") %>
---
# <% tp.file.title %>
status を seedling（種）→ growing（育成中）→ evergreen（定着）のように段階を分けておくと、まだ考えがまとまっていないメモと、繰り返し参照している完成度の高いメモを一覧上で見分けられます。
記事・ブログ下書き：制作フロー（draft → published）
---
type: article
status: draft
category:
- Obsidian
- KnowledgeManagement
tags:
- writing
created: <% tp.file.creation_date("YYYY-MM-DD") %>
---
# <% tp.file.title %>
## 概要
status を draft → review → published のように制作フローに合わせて変化させると、今どの記事がどの段階にあるかを一覧で把握できます。私自身、複数の記事を並行して書いているときはこの一覧化にかなり助けられています。
プロジェクト・タスク：期限と優先度の管理
due（期限）と priority（優先度）を日付型・数値型で持たせておくと、期限が近いタスクだけを絞り込んだり、優先度順に並べ替えたりできます。ここでも型を崩さないことが重要で、due はチェックボックス型ではなく必ず日付型で入力するようにしています。
※このタスクリストはDataviewやBasesとの組み合わせを前提にしています。
---
tasks:
- name: "要件定義書の作成"
due: 2026-08-25
priority: 1
status: "todo"
- name: "ワイヤーフレーム作成"
due: 2026-08-28
priority: 2
status: "in_progress"
- name: "アイコン素材の選定"
due: 2026-09-05
priority: 3
status: "todo"
---
書籍・製品レビュー：数値型とリンク型プロパティの活用
---
type: review
status: draft
category: book
rating: 4
author: "[[著者名]]"
created: <% tp.file.creation_date("YYYY-MM-DD") %>
---
# <% tp.file.title %>
## 総評
ここで使っている author: "[[著者名]]" は、テキストではなくノートへの内部リンクを持たせる「リンク型プロパティ」です。著者名を別ノートとしてリンクさせておくと、その著者の他のレビューをバックリンクから辿れるようになります。グラフビュー上でも、つながりが見える化されるのがメリットです。テキストで書くよりも一手間増えますが、著者やシリーズものをまたいで振り返りたい場合には効果的です。
【発展編】プロパティを活かしてVaultをデータベース化する
この項では実践編からさらに発展させ、コアプラグインやコミュニティプラグインを使った活用方法を紹介します。
コアプラグイン「Bases」でノートを一覧・カード化する基本
Basesを使うと、type や status を列にしたテーブルビューを作成できます。プロパティの値をもとに、ノートを一覧・フィルターすることが可能です。たとえば type: blog かつ status: draft の条件でフィルターをかければ、下書き中の記事だけを一覧表示できます。Basesの基本的な使い方や画面構成については、Obsidian Bases紹介記事で具体的なビュー作成手順を紹介していますので、あわせてご覧ください。
💡 Basesでのフィルターは、プロパティの型が揃っていることが前提になります。数値やチェックボックスの型が崩れていると、フィルター条件に引っかからないことがあるため、基本編で紹介した型の統一が効いてきます。
テンプレート機能で「プロパティの手入力」をゼロにする仕組み作り
プロパティ設計がどれだけ良くても、毎回手入力していては続きません。Obsidian標準の「テンプレート」機能や、コミュニティプラグインの「Templater」を使いましょう。新規ノート作成時に、created などのプロパティを自動挿入できるようになります。
| 項目 | 標準「テンプレート」 | コミュニティ「Templater」 |
|---|---|---|
| 導入難易度 | 極めて簡単（標準コアプラグイン） | 普通（プラグインのインストールが必要） |
| 動的処理 | 日付・時刻・タイトルの基本変数のみ | JS実行、ファイル名操作、分岐処理など自由度が高い |
| 向いている人 | 手軽に自動入力を試したい初心者 | 作成日固定や高度な自動化を行いたい中級者 |
この記事で紹介したYAML例のうち <% tp.file.creation_date(...) %> のような記法はTemplater独自のものです。標準テンプレートしか使わない場合は {{date}} のような基本変数に置き換えてください。両者の役割分担や具体的な設定手順については、QuickAddとTemplaterの役割分担ガイドでより詳しく解説していますので、自動化を本格的に組みたい方はそちらもあわせてご確認ください。
※ Templater独自の表記は、プラグインが有効化されていないと展開されず、文字列のまま残ってしまいます。Templaterを使う場合は、プラグインの有効化を忘れないようにしましょう。
運用を重ねると、プロパティはこう育つ
ここまで紹介してきたのは、あくまで「最小構成」からの育て方でした。実際に運用を続けていくと、プロパティは少しずつ増えていきます。参考として、私自身のVaultで実際に運用しているノートのプロパティをご覧ください。
type status category created updated に加えて、tags slug url published last_mod といった項目が並んでいます。ここでの type: blog や category: Software は、このブログ全体の管理用に運用しているカテゴリ体系です。実践編で紹介した type: article の例とは、あくまで用途の異なる別の運用ルールとして参考にしてください。
これは「最初からこれだけ揃えるべき」という意味ではありません。ブログ運営を続ける中で、「公開URLを一覧管理したい」「更新日を分けて記録したい」といった具体的な問いが生まれるたびに、必要な項目を一つずつ足してきた結果です。
大切なのは項目数そのものではなく、「今のプロパティが、答えたい問いに応えられているか」という視点です。もし増えたプロパティに少しでも違和感を覚えたら、次の章で紹介する落とし穴に当てはまっていないか、一度棚卸ししてみることをおすすめします。
やってはいけない「プロパティ設計」4つの落とし穴
- 項目が多すぎて書くのが嫌になる（プロパティメタボ）：便利そうという理由だけで項目を増やすと、入力の手間が負担になり、結局形骸化してしまいます。
- 「分類すること」自体が目的化してしまう：プロパティで整理すること自体が目的になると、実際には使わない分類軸まで作り込んでしまいがちです。
- 答えたい「問い」がないプロパティを作ってしまう：「このプロパティで何を検索・一覧化したいのか」が曖昧なまま項目を作ると、結局活用されずに残り続けます。
- 使わなくなったプロパティを放置し、棚卸しをしないまま増やし続けてしまう：運用を続けるうちに使わなくなった項目や、意味が重複した項目が残りがちです。
プロパティの整理と合わせて、ノート全体の管理体制を見直したい場合は、散らかったObsidianを卒業しよう。ノート管理が楽になるプラグイン活用術も参考にしてみてください。
まとめ
プロパティ設計で大切なのは、最初から完璧な構成を作ろうとしないことだと感じています。まずは type status category created の4項目から始めて、型と語彙のルール（type別に語彙を固定する）だけは崩さないようにしましょう。そのうえで、必要になったらリンク型プロパティやBasesでの一覧化、テンプレートによる自動化を少しずつ足していきます。この「小さく始めて、必要になったら育てる」という進め方が、結局いちばん長続きすると思います。
