テーマ

Obsidian Dataview：4つの表示形式から始めて離れたメモを近くに並べる

BEGIN STDOUT

Obsidian Dataview：4つの表示形式から始めて離れたメモを近くに並べる

Obsidianでノートを書き溜めていくと、フォルダによる整理だけでは物足りなさを感じる瞬間が訪れます。フォルダは、一度決めた場所にノートを保管しておく仕組みです。しかし、後になって「いま考えているテーマに関わるノートだけを並べたい」と思っても、固定されたフォルダは動いてくれません。

デジタルノートをフォルダやタグで分類しようとすると、ノートが増えるにつれて例外が増え、やがて管理が破綻してしまいがちです。完璧な分類を作ったつもりでも、時間が経てば自分自身の関心や状況が変化し、当初の分類そのものが意味をなさなくなります。

紙のカードを用いたアナログのZettelkastenでは、物理的な制約によって隣接するカードしか参照できませんでした。デジタルノートはこの限界を突破し、離れた場所にある知識同士を瞬時につなぎ直すことができます。

そこで役に立つのがDataviewプラグインです。ノートに付与されたプロパティやタグを手がかりに、その場で必要な一覧を動的に組み直してくれます。一度クエリを書いておけば、毎回手作業でノートを探しに行かなくても、常に最新の並びが手元に現れます。

4つの表示形式だけ先に押さえる

Dataviewの導入でつまずきやすいのは、クエリ言語という見た目の難しさです。複雑な構文をすべて覚えようとすると、最初の1本が書けないまま止まってしまいます。

ですが、覚える順番を変えれば難しさは大きく減ります。最初に押さえるべき表示形式は、次の4つだけです。

形式表示される内容
LISTファイル名の一覧。最も単純な形式です
TABLE複数のプロパティを列に並べる表形式。読書リストなどに適しています
TASKチェックボックスの一覧。未完了のタスクだけを集められます
CALENDAR日付プロパティをもとにカレンダー上に配置します

何を一覧にしたいかが決まれば、この4つのうちどれを使うかが決まります。集める場所を指定するFROMや、絞り込み条件のWHEREは、後から書き足していけば十分です。

最初の1本は、最も単純なLISTから始めるのが確実です。一覧が画面に表示される体験さえできれば、最初のハードルは越えられます。

クエリはコードではなく英文として読む

Dataviewのクエリは、プログラムコードとして一文字ずつ読もうとすると記号ばかりが目につきます。しかし、英語の語順に沿って上から追っていくと、意味がそのまま流れていきます。

TABLE file.mtime AS "更新日"
FROM "notes"
WHERE contains(tags, "review")
SORT file.mtime DESC
LIMIT 10

このクエリは、次のように読めます。

  • TABLE：表として表示する（ファイルの更新日時を「更新日」という列名にする）
  • FROM：notesフォルダの中から集める
  • WHERE：reviewタグを含むノートに絞る
  • SORT：更新日時が新しい順に並べる
  • LIMIT：最大10件だけ取り出す

英語の語順で何を集めてどう絞るかがつかめれば、記号への警戒感は薄れます。動くクエリを手元に置き、表示形式をTABLEからLISTに差し替えたり、並び順を変えたりしながら、少しずつ変更していくほうが早く手に馴染みます。

デイリーノートから使い始める

Dataviewの恩恵を一番感じやすい場所はデイリーノートです。

デイリーノートは、日々のメモや突発的なアイデア、調べた内容などを分類に迷わず書き留める一次置き場です。「あとで整理する」という前提でその日のノートへ情報を集約すると、記録に対する心理的な摩擦が消えます。

このデイリーノートのテンプレートにDataviewのクエリをあらかじめ仕込んでおくと、毎日ノートを開くたびに最新の一覧が自動で返ってきます。

たとえば、その日が期日のタスクを集めるクエリです。

LIST
FROM ""
WHERE due = date(today)

各ノートのプロパティに due: 2026-04-15 のように期日を書いておけば、Vault内のあちこちに散らばった締め切りが、当日のデイリーノートに集約されます。タスクを独立したノートに切り出し、Dataviewで抽出するようにすると、予定管理が身軽になります。

また、過去の記録を呼び出すことも一行で書けます。

LIST WHERE file.cday = date(today) - dur(1 yr)

1年前の同じ日に書いたノートが、当日の画面へ自動的に現れます。振り返り専用の時間をわざわざ作ろうとすると習慣は途切れがちですが、今日のノートを開いた瞬間に過去の断片が目に入れば、自然な流れで過去の記録を読み返すことができます。

離れたメモを近くに並べて見せる

基本の使い方が分かってきたら、タグによる自動集約を試してみるのが効果的です。

ノートにタグを付けておくだけで、Dataviewはそのタグを持つノートを拾い上げます。フォルダが別々に分かれていても、プロジェクトノートやまとめノートを開けば、関連する断片が最新の状態でそろいます。手作業でリンク集や目次を作り直す手間はありません。

ここからが、固定されたフォルダ整理では届かない領域です。アナログのカードでは、関連するカードを机の上に並べることで思考の近さを確かめていました。Dataviewは、デジタルの画面上でその状態を再現します。

あちこちに保存されたメモが、タグやキーワードの一覧を通じて画面上に近く並びます。ただのキーワード検索結果と異なり、特定の文脈の中でノート同士のつながりが視界に入ります。前は関係がないように見えていたメモ同士が思いがけず並ぶことで、新しい関係に気づいたり、次の思考が引き出されたりします。

繰り返す記録はプロパティに任せる

同じ形式で繰り返し記録する情報も、Dataviewの一覧化と相性が良い場面です。代表的な例が読書記録です。

TABLE read AS "読了日", title AS "タイトル"
FROM "books"
SORT read DESC

手動で「読んだ本リスト」を更新していると、記録漏れが生じやすく、後から見直したときに何が抜けているのか分からなくなります。各書籍ノートのプロパティに read: 2026-02-15 のように読了日を記録しておけば、本を読み終えるたびに自動で読書リストへ反映されます。手作業の更新作業そのものが不要になります。

プロパティを設計する際は、人間が見て整っていることよりも、機械が処理しやすい形を優先することが大切です。日付であれば YYYY-MM-DD 形式で統一し、項目数は最小限に絞ります。項目を増やしすぎると日々の更新が負担になり、記録自体が滞ってしまいます。

また、一覧の作成にはコアプラグインのBasesという選択肢もあります。Basesはコードを書かずにUI操作で動的なテーブルを作成でき、その場でのデータ編集にも向いています。複雑な条件抽出や集計、定点観測の一覧にはDataviewを使い、日々直接操作するテーブルにはBasesを使うといった使い分けが適しています。

自由さを守る使い分けを考える

Dataviewの便利さを知ると、Vault内のあらゆるノートをDataviewで管理したくなることがあります。しかし、何でもクエリで制御しようとすると、かえってObsidianの良さが損なわれることになります。

Vault全体をクエリ前提に設計してしまうと、厳格な入力規則に縛られ、思考を巡らせる前にノートを整える作業へ意識が向いてしまいます。思いついたことをそのまま自由に書き留められる気楽さは失われてしまいます。

Dataviewは、一覧化による恩恵が大きい場面に絞って使うのが賢明です。一覧が長くなって本文を圧迫する場合は、Calloutで囲んで折りたたんでおけば、普段は執筆や思考に集中できます。

なお、Obsidian PublishでノートをWebに公開する場合、Dataviewによる動的な一覧は表示されません。個人の作業環境では機械が網羅した一覧が役立ちますが、読者に届ける場では、発信者が自分の手で選び、筋道を立てて並べた情報のほうが意図が伝わります。一覧が自動表示されないという制約は、自分にとって本当に必要なノートを厳選して編集するきっかけにもなります。

使う場面をあえて絞ることで、Obsidian本来の自由な書き心地を保ちながら、離れたメモを必要なときだけ近くに引き寄せる環境が整います。 END STDOUT