Obsidian Dataviewの使い方｜条件でノートを一覧化

Obsidian Dataviewが必要な場面を判断する

Dataviewは、ノートの属性をインデックスにまとめ、専用のクエリ言語（DQL）で一覧・絞り込み・並べ替え・グループ化をする仕組みです。公式の概要では、Dataviewは表示と計算のための機能で、ノートやメタデータを書き換えないと説明されています。例外は、後で触れるTASKクエリからタスクにチェックを付けた場合です。公式：Dataviewの概要

一方、ObsidianのコアプラグインであるBasesは、ノートとプロパティを表やカードで表示し、その場で編集・並べ替え・絞り込みができる機能です。公式：Bases 属性で絞った表を作り、セルから値を直したいだけなら、追加のプラグインを入れずにBasesで足ります。作り方はObsidian Basesでノートを一覧化する方法で説明しています。

表の2行目以降は、Dataviewの公式ドキュメントに書かれている機能です。値ごとのグループ化や、特定のノートへのリンクを条件にした絞り込みは今のBasesでもできるため、それだけを理由にDataviewを選ぶ必要はありません。Basesの機能は版によって変わり得るため、この表は目安として使ってください。迷ったらまずBasesで作り、条件を書き切れなくなった時点でDataviewを検討すれば十分です。

DataviewにはJavaScriptで書くDataviewJSもあります。公式リポジトリは、JavaScriptのクエリは他のプラグインと同じ権限で動き、ファイルの書換えや削除、通信もできると注意しています。通常のDQLはサンドボックス内で動き、保管庫に害のある変更はできないとされています。公式リポジトリ：JavaScriptクエリの注意 この記事の例はすべてDQLで書けます。業務の保管庫では、中身を理解できないJavaScriptを貼り付けないでください。

Dataviewのクエリに使うノートと属性を用意する

Dataviewはコミュニティプラグインです。Obsidian公式ヘルプの手順では、設定で制限モードを解除し、コミュニティプラグインの一覧からインストールして、有効化します。第三者のコードが動くこと、更新が自動では行われないことも書かれています。公式：コミュニティプラグイン プラグイン全般の選び方はObsidianおすすめプラグインの記事にまとめています。

導入したら、練習用の保管庫にProjectsというフォルダを作り、次の4件のノートを置きます。Dataviewが読めるのはインデックスされた情報だけで、本文の段落そのものは検索対象になりません。公式：インデックスされる情報 条件にしたい情報は、属性として書いておく必要があります。

案件Dの期限は、わざと書いていません。業務ノートでは、期限が決まっていない案件や入力漏れがよく出ます。この1件があることで、後半の絞り込みで起きる混入を説明できます。

属性はノート先頭のフロントマターに書きます。Dataviewの公式ドキュメントでは、フロントマターのYAML項目はすべて自動でDataviewの項目になるとされています。案件Aは次のように書きます。

---
status: 進行中
owner: 営業
due: 2026-11-05
---
# 案件A
見積もりの返答待ち。

本文の途中に書く「インライン項目」も使えます。1行に単独で書く場合はdue:: 2026-11-05、文中やタスクの行に書く場合は[due:: 2026-11-05]のように角かっこで囲みます。フロントマターと違い、区切りはコロン2つです。公式：メタデータの追加 4件の練習では、条件を見比べやすいようにフロントマターへそろえます。

項目名は英小文字でそろえておくと、後のクエリで迷いません。公式では、空白や大文字を含む項目名は、小文字にして空白をハイフンにした名前でも参照できるとされています。日本語の項目名も使えますが、チームで使うなら、誰が見ても同じ名前で書ける表記を先に決めます。

このほか、ファイル名・フォルダ・作成日時・更新日時・タグ・リンクなどは、書かなくてもfile.nameやfile.mtimeのような暗黙の項目として使えます。公式：ページの暗黙の項目

Dataviewの最小クエリで一覧を出す

クエリは、言語名をdataviewにしたコードブロックに書きます。公式ドキュメントは、コードブロックの前後をバッククォート3つで囲むこと、見た目の似たアポストロフィと混同しないよう注意を促しています。公式：DQL・JavaScript・インライン この節と次の節で組むクエリの順番を、先に図で示します。

DQLで必須なのは、LIST・TABLE・TASK・CALENDARのどれを使うかという「クエリ種別」だけです。対象を選ぶFROMは0回か1回で、クエリ種別の直後に書きます。公式：DQLクエリの構造 最初のクエリは、対象をProjectsフォルダに固定したLISTにします。

```dataview
LIST
FROM "Projects"
```

FROMにフォルダ名を書くと、そのフォルダとサブフォルダのノートが対象になります。公式：データコマンド この練習ではProjectsに4件しか置いていないので、期待値は案件A〜Dの4件です。5件以上出たら、サブフォルダや別のノートが入っていないかを確かめます。

FROMを省いたLISTだけでも有効なクエリですが、保管庫のすべてのノートが対象になります。公式ドキュメントは、保管庫の規模によっては処理に時間がかかり、Obsidianが固まる場合もあるとして、FROMで範囲を絞るよう勧めています。業務の保管庫では、最初からフォルダかタグを指定してください。

次に、同じ4件を表にして、属性が読めているかを見ます。

```dataview
TABLE status, owner, due
FROM "Projects"
```

TABLEの先頭列には、既定で結果の件数が表示されます。公式：クエリの種類 ここで確かめるのは次の3点です。

1. 件数が4件か。合成データの表と同じ数かを数えます。
2. 案件A〜Cのstatus・owner・dueが、合成データと同じ値で表示されているか。
3. 案件Dのdueだけが空になっているか。書いていない項目が空になるのは想定どおりです。

この段階で値が空のノートがあれば、絞り込みを足す前にノート側を直します。条件を足してから気づくと、ノートの書き方の問題とクエリの問題が混ざって原因を追いにくくなるためです。

Dataviewで絞り込みと並び順を加える

件数と値が合ったら、条件を1つずつ足します。DQLでは、FROM以外のコマンドは何度でも書けて、上から書いた順に実行されます。公式：DQLクエリの構造 SQLのように全体を一度に解釈するのではなく、前の行の結果を次の行が受け取る流れです。公式：DQLとSQLの違い

WHEREで進行中の案件に絞る

```dataview
TABLE owner, due
FROM "Projects"
WHERE status = "進行中"
SORT due ASC
```

合成データから考えると、対象は案件A・C・Dの3件です。案件Aの期限は案件Cより前なので、昇順の並べ替えではAがCより上に来ます。期限のない案件Dがどの位置に並ぶかは、公式ドキュメントに明記された説明を確認できなかったため、この記事では期待値に含めません。

期限で絞ると、期限のない案件が混ざる

次に「11月10日までが期限の進行中案件」を出すつもりで、条件を足します。日付の項目は日付オブジェクトと比べる必要があるため、date(2026-11-10)のような日付リテラルを使います。公式：リテラル 実務ではdate(today)も使えますが、練習では期待値が日によって変わらないよう日付を固定します。

```dataview
TABLE owner, due
FROM "Projects"
WHERE status = "進行中" AND due <= date(2026-11-10)
```

意図した答えは案件Aの1件ですが、仕様どおりに考えると案件Dも対象に入り、A・Dの2件になります。公式ドキュメントでは、項目が設定されていない場合その値はnullになり、null <= date(today)はtrueを返すと説明されているためです。公式：異なる型の比較

期限のない案件を除くには、型の確認を条件に入れます。公式でも、同じ型どうしで比べるためにtypeofを使う書き方が示されています。

```dataview
TABLE owner, due
FROM "Projects"
WHERE status = "進行中" AND typeof(due) = "date" AND due <= date(2026-11-10)
```

この条件なら、対象は案件Aの1件になるはずです。WHERE due AND ...のように項目の有無を確かめる書き方も公式で紹介されていますが、型まで確かめる方が結果を予測しやすいとされています。

反対に、期限の入力漏れを探す一覧も作れます。WHERE status = "進行中" AND !dueとすれば、期限のない案件Dだけを拾う意図になります。絞り込みから漏れた案件を、別の一覧で確かめる使い方です。

GROUP BYとLIMITは順番に注意する

担当ごとにまとめるときは、GROUP BYを使います。グループ化すると1グループ1行になり、元のノートはrowsという配列にまとめられます。公式：GROUP BY

```dataview
TABLE rows.file.link AS "案件"
FROM "Projects"
WHERE status = "進行中"
GROUP BY owner
```

合成データでは、営業の行に案件AとD、管理の行に案件Cがまとまる想定です。LIMITで件数を絞るときは、書く位置に注意します。公式ドキュメントでは、LIMITをSORTより前に書くと、件数を絞った後の結果を並べ替えると説明されています。「期限が近い順に上位5件」が欲しいなら、SORTを先に書きます。

タスク単位で集めたい場合は、TASKクエリを使います。TASKはノートではなくタスクを結果として返し、条件もタスク単位で判定されます。結果のタスクにチェックを付けると、元のファイルのタスクにもチェックが入ります。公式：TASKクエリ 一覧を見ているつもりで元のノートを変えることになるため、共有している保管庫では扱いを決めてから使います。

Dataviewの空欄・型・クエリの失敗を切り分ける

結果がおかしいときは、クエリを書き直す前に、どの段階で数が合わなくなったかを確かめます。FROMだけの最小クエリまで戻し、件数と値が合えばノート側は正常で、足した条件に原因があると切り分けられます。

日付の扱いについて、公式ではISO8601形式に合う文字列が日付として扱われ、より具体的な型に当たらない値はテキストになると説明されています。公式：項目の型 項目名がfromやwhereのようにDQLの語と同じ場合は、row.fromのように書きます。この書き方は、空白を含む項目名の参照方法とともに公式のよくある質問に載っています。

もう一つの限界は、Dataviewの表が「表示」だということです。公式の説明どおりノートを書き換えない機能なので、ノートのファイルに残っているのはクエリの文面です。表の内容を別の人や別のツールへ渡すときは、表示結果ではなく、元になった各ノートの属性を渡す前提で考えます。ノートをAIに読ませる具体的な方法は、ObsidianとClaude Codeの連携方法で紹介しています。

Dataviewは、件数を説明できるクエリから業務へ広げる

最初の目標は、4件の合成ノートで「全件4件」「進行中3件」「期限で絞って1件」を、なぜその数になるのか説明できる状態にすることです。特に、期限のない案件が混ざる理由を自分の言葉で説明できれば、業務ノートに広げたときの見落としを防げます。

業務へ広げるときは、クエリより先に属性を決めます。どの項目を必須にするか、状態の値は何種類か、期限が未定のときに何を書くかを決めておかないと、表記のゆれでクエリが拾えないノートが増えます。保管庫の作り方から見直したい場合は、Obsidianの基本と始め方もあわせて確認してください。

属性がそろったノートは、人が一覧で確かめるだけでなく、AIに読ませる資料としても扱いやすくなります。案件の状態や期限をノートの属性として持ち、AIにどの範囲を渡すかまで設計したい場合は、PLaiのAI社員導入支援で、対象業務と属性の決め方から一緒に整理できます。

● 代表・市岡と話す、30分の個別面談

AI活用の「何から？」を、
30分で解決。

御社の仕事を伺い、AIに任せる業務と
最初に試すことを、一緒に決めます。

• 01AIに任せたい仕事を整理
• 02自社に合う始め方を具体化
• 03明日からの一歩を決める

30分の面談を申し込む↗

オンラインで30分AI社員導入支援について →

記事を読む、その先へ。
次は、御社の話を聞かせてください。