Obsidian Dataview 使い方とクエリ例10選

Obsidianでノートが増えてくると、タグや検索だけでは欲しい情報に届きにくくなります。
そこで効くのが、ノートをデータベースのように扱えるDataviewです。
筆者の経験では、新規 Vault に Dataview を入れて最初の LIST クエリを貼れば、短時間でノート一覧と未完了タスクを並べたダッシュボードの骨格を作れることが多かったです。
ただし、環境や既存ノートの量によって所要時間は変わります。
この記事は、Dataviewを今日から実務投入したい人に向けて、DQLの基本句を短時間でつかみ、コピペで動く実用クエリで一覧化・絞り込み・並び替え・集計まで一気に体験できる構成です。
『あわせて、YAML FrontmatterとInline Fieldsの使い分け、英数字ベースのキー設計が安定する理由、FROM を省いたクエリの重さ、Obsidian Publishでの制約も押さえます。
Dataview公式トップ』が案内する通り、Dataviewは読み取り中心の発想で使うと噛み合いやすく、DQLで足りない場面だけDataviewJSへ進むのが最短ルートです。

前提条件・準備するもの

Dataviewを触り始める前に、ひとつだけ先に知っておきたいのがObsidian Publishとの関係です。
Obsidian PublishはDataviewの動的クエリをデフォルトではそのまま表示できません。
公開サイトで動くダッシュボードを前提に設計すると、ローカルでは便利でも公開時に同じ見え方にならないので、ここは出発点として押さえておくと後で構成を崩さずに済みます。
Dataviewを触り始める前に押さえておきたいのが、Obsidian Publish との関係です。
Obsidian Publish は Dataview の動的クエリをそのまま表示しないため、ローカルで便利に見えても公開先では同じ見え方にならない可能性があります。
一方で、Dataview 自体は基本的にローカルで動作するため、普段使うぶんには常時ネット接続は不要です。
なお、Community plugins からインストールする場合は通常インターネット接続が必要ですが、オフライン配布などの例外もあります。
公開を前提に設計するなら、この点を出発点として押さえておくと後で構成を崩さずに済みます。
この記事の前提としては、Obsidian v1.4以降とDataviewの最新版を想定しています。
v1.4以降を勧める理由はProperties UIが安定していて、Frontmatterを視覚的に編集しやすいからです。
Dataview側は更新が継続しているため、導入時点の最新版をDataview Releasesで確認しておく前提が合っています。
機能差や細かな挙動の差を避けやすく、サンプルの再現性も保ちやすくなります。

環境づくりで見落としやすいのがキー名の設計です。
Propertiesでは日本語キーやスペース入りキーも入力できますが、Dataviewで参照する段階になると記法が煩雑になりやすく、クエリの見通しも落ちます。
たとえば project_status や due_date のように英数字ベースでそろえておくと、DQLでもDataviewJSでも扱いやすく、後から列を増やしても崩れにくくなります。

パフォーマンス面では、最初から「対象範囲を決める」癖をつけておくと安定します。
FROM を省いたクエリはVault全体を見に行くため、ノート数が増えるほど負荷が上がります。
小さなVaultでは気づきにくいのですが、対象が増えると一覧の再描画待ちが目立ってきます。
私は初期の試作で FROM なしの TASK クエリを何本も並べ、表示がもたついてから構成を見直しました。
フォルダ名やタグで対象を先に絞るだけで、ダッシュボードの反応が落ち着きます。

クエリの入り口としては、まずDQLで LIST、TABLE、TASK を使う構成が向いています。
TASK はページ単位ではなくタスク単位で評価されるので、未完了タスクだけを横断表示したい場面にそのまま当てはまります。
一方、CALENDAR は有効な日付フィールドが必要で、SORT や GROUP BY は効かないため、日付の持たせ方を先に決めておく必要があります。
Daily Notes中心なら、作成日時の file.ctime より、日付ベースのファイル名から拾える file.day のほうが意図どおり並ぶ場面が多いです。

DataviewJSは、DQLでは届かない表示を作る段階で効いてきます。
dataviewjs コードブロック内にJavaScriptを書き、dv.pages や dv.table で自由に組み立てられるので、複雑な整形や条件分岐まで手が届きます。
ただ、最初からここへ入ると、クエリの考え方とJavaScriptの両方を同時に追うことになります。
Dataview JavaScript API Overviewの内容に進むのは、DQLで欲しい一覧が一通り作れてからのほうが流れが自然です。

更新が反映されないときの対処も、準備段階で知っていると詰まりません。
メタデータを書き換えたのに一覧が変わらない場合は、再読み込み系のコマンドが効くことがあります。
常用するものではありませんが、クエリが壊れたと勘違いしなくて済むので、覚えておくと切り分けが早くなります。

インストールと最初に確認したい設定

コミュニティプラグインの有効化

筆者の環境で試したところ、Browse で Dataview を検索してインストール後に Enable を押すだけで、すぐに LIST クエリを貼って一覧が返り、最初の成功体験を作れました。
初回は DQL の LIST や TABLE を中心に触ってみることをおすすめします（環境差により表示までの時間は変わる可能性があります）。

手順は次の通りです。

1. Obsidianで Settings を開きます。
2. Community plugins を開き、未許可の状態ならコミュニティプラグインを有効化してください。
3. Browse をクリックしてください。
4. 検索欄に Dataview と入力します。
5. Dataviewを選び、Install をクリックしましょう。
6. インストール完了後は Enable をクリックすると良いでしょう。

有効化できたら、プラグイン一覧にDataviewが表示されます。
ここまで済めば、Vault内のメタデータを一覧・表・タスク形式で読める状態です。
YAML Frontmatter の key: value と Inline Fields の key:: value の両方を拾えるので、既存ノートが少し混在していても、最初の検証はそのまま進められます。

DataviewJSの設定項目

通常のクエリは dataview コードブロックで書く DQL から始めれば十分です。
LIST TABLE TASK を使うだけでも、ノート一覧、未完了タスク、最近更新したメモの抽出までこなせます。
Dataview JavaScript API Overviewを見るとわかる通り、DataviewJSは dv.pages や dv.table のような API を使ってより柔軟な表示を組めますが、そのぶん JavaScript の理解も必要になります。
学習コストを考えると、初回は DQL 中心で進めるほうが迷いません。

それでも dataviewjs を使う予定があるなら、設定だけ先に確認しておくと後で詰まりません。手順は次の通りです。

1. Settings を開きます。
2. 左側のプラグイン一覧から Dataview を選びます。
3. 設定項目の中にある JavaScript Queries を有効化します。

この項目がオフのままだと、dataviewjs コードブロックを書いても実行されません。
逆に、DQL だけ使う段階なら無理にオンにしなくても問題ありません。
最初の段階で覚えることを増やさないほうが、クエリの読み方とメタデータ設計に集中できます。

運用面では、Properties のキー名もここで少し意識しておくと後が楽です。
日本語キーやスペース入りのキーは扱えないわけではありませんが、式を書き始めた段階で引っかかることがあります。
status rating project のような英数字ベースのキーに寄せておくと、DQLでもDataviewJSでも書き方がぶれません。

最初のコードブロックを描画してみる

セットアップ完了の判定は難しくありません。
ノートに短い LIST クエリを書き、Reading View もしくはプレビュー表示で結果が出れば成功です。
ここでは Vault 全体を対象にせず、任意のフォルダを明示して確認します。
対象を絞ったほうが、何が出てきたのかを追いやすく、負荷も抑えられます。

まずは新規ノートを1枚作り、次のコードブロックを貼ります。

LIST
FROM "Projects"

Projects は自分のVaultにある任意のフォルダ名へ置き換えてください。
たとえば Daily Notes や Books でも構いません。
Reading View に切り替えると、そのフォルダ内のページ一覧が描画されます。
ここで何も表示されない場合は、そのフォルダにノートが入っていないか、フォルダ名の表記が一致していないことが多いです。

一覧が表示されたら、初回セットアップとしては十分です。
筆者もこの段階でノート名がそのまま並んだのを見て、Dataviewは「難しい集計ツール」ではなく「まずノートを拾って並べるところから始めるものだ」と腹落ちしました。
最初から複雑な WHERE や GROUP BY を試すより、まず1本描画されることのほうが意味があります。

dataviewjs も最小例だけ触れておくなら、設定を有効化したうえで次のように書けます。

dv.list(dv.pages('"Projects"').file.name)

これでも同じように一覧を出せますが、初学者が日常運用で最初に必要なのは多くの場合こちらではありません。
DQL の LIST FROM "Projects" が自然に読めるようになってから JavaScript 側へ広げたほうが、式の意味を見失わずに進められます。
更新しても表示が変わらないときは、ビューの再描画で直ることもあります。
そういう場面が出てきても、まずはコードの難しさを疑うより、シンプルな LIST が返る状態を基準に切り分けると迷いません。

Obsidian Dataviewとは何か

Dataviewの位置づけと読み取り中心の性質

Dataviewは、Obsidian の Vault にある Markdown ノートをメタデータごと索引し、一覧、表、タスク、カレンダーの形で再構成して見せるためのプラグインです。
単なる検索強化ではなく、「ノートをデータとして読む」ための層が追加されるイメージに近いです。

ここで押さえておきたいのは、Dataviewが読み取り中心で設計されている点です。
Dataview 。
だからこそ、日々の記録フローを壊さずに導入できます。
普段通りノートを書き、あとから TABLE や TASK で必要な切り口を与えるだけで、記録が一覧に変わります。

体感としても、この「読むための層」と割り切ると一気に理解が進みます。
標準検索では見つけられても、たとえば「進行中の案件を担当者ごとにまとめた表」のような構造化表示は作りづらい場面があります。
自分の Vault でも、特定プロパティで集計した表を TABLE と GROUP BY で一度作ってからは、そのノートを毎日開くだけで状況が把握できるようになりました。
検索語を毎回打ち直す時間が消えたことで、情報探索より判断に意識を向けられるようになった感覚があります。

規模面でも、Dataviewは公式に数十万件規模の注釈付きノートまでを視野に入れています。
ただし、クエリ設計は別問題です。
Structure of a Queryでは、FROM で対象範囲を絞らないクエリは Vault の規模によって重くなり得ると案内されています。
つまり、プラグインそのものは大きな Vault を扱えても、日常運用では「どのフォルダ」「どのタグ」「どの条件」を見るクエリなのかを明確にしたほうが、表示も頭の中も散らかりません。
規模の話では、Dataview 自体は大きな Vault を扱える設計です。
ただし「扱える」ことと「日常的に快適に動く」ことは別問題で、クエリ設計次第で体感は大きく変わります。

扱えるメタデータの種類

Dataviewが拾える代表的なメタデータは、YAML Frontmatter、Inline Fields、タグ、そしてタスクのチェックボックスです。
ノート冒頭の Frontmatter に key: value で書いた値はページ全体の属性として扱えますし、本文中の key:: value は Inline Fields として行単位に近い感覚で埋め込めます。

YAML Frontmatter は、status、project、rating のようにノート全体に共通する属性を持たせるときに向いています。
読書メモなら評価や著者名、会議ノートなら案件名や会議日といった具合です。
ページ単位の管理になるので、後から TABLE status, project のような一覧を作ると列が安定します。

Inline Fields は、本文の途中に情報を差し込めるのが強みです。
1ページの中に複数の出来事や観点が混ざるノートでは、Frontmatter だけだと粒度が粗くなります。
たとえば同じ議事録の中でも、決定事項の近くに owner:: tanaka、検討期限の近くに due:: 2026-03-18 と書いておけば、文脈を残したまま後で抽出できます。
Obsidian 標準の Properties だけに寄せる運用より、ノート本文とデータの距離が近くなるのが利点です。

タグも引き続き有効です。
#project や #meeting のようなタグは、ざっくり分類したいときに便利で、Dataview 側でも条件に組み込めます。
さらに見逃せないのがタスクです。
- [ ] で書かれたチェックボックスは TASK クエリで拾え、ページ単位ではなくタスク単位で評価されます。
1つの長いノートに複数の未完了項目があっても、それぞれを個別に一覧へ引き上げられるので、「どこに書いたか」ではなく「何が残っているか」で見られるようになります。
Dataview は「魔法の検索」ではなく、メタデータの設計に従って結果を返すツールです。
設計が揃っているほど恩恵が出やすく、まずは小さな設計ルールを守ることが安定運用の近道になります。
この構造を理解すると、Dataview は魔法の検索ではなく、メタデータの設計図に従って働くプラグインだとわかります。
最初は Frontmatter を中心に始めて、本文の細かい注釈が必要になったら Inline Fields を足す、タスク管理は TASK で切り出す、という順番だと無理が出ません。

Obsidian標準検索との使い分け

Obsidian の標準検索は、文字列を見つける道具として優秀です。
あるフレーズを含むノートを探したい、特定タグの記述箇所を洗い出したい、といった用途なら素早く届きます。
埋め込み検索も、その場で検索結果を見せたいときには便利です。
ただ、検索結果は基本的に「ヒットした箇所の集合」に近く、列を持つ表や、条件別の集計、グループごとの一覧には向いていません。

Dataviewが強いのはその先です。
TABLE で列を定義し、GROUP BY で担当者別やステータス別に束ね、必要なら SORT や LIMIT 10 を組み合わせて、毎日見るためのダッシュボードへ育てられます。
検索はその都度投げる動作ですが、Dataview のクエリはノートに置いて再利用できます。
つまり、「探す」から「見る」に変わります。
この違いが、ノート数が増えたときの効き方を分けます。

自分の運用でも、この差ははっきり出ました。
標準検索では「該当するノートは見つかるが、優先順位や担当別のまとまりは見えない」状態で止まりがちでした。
そこで TABLE と GROUP BY を使って、特定プロパティごとに集計された表を作ったところ、朝にそのノートを開くだけで全体像が入ってくるようになりました。
検索窓で条件を試行錯誤する時間が減ると、Dataview は単なる表示プラグインではなく、作業の入口を整えるレイヤーとして効いてきます。

もちろん、何でも Dataview に寄せればよいわけではありません。
単発で文字列を探すだけなら標準検索のほうが速く、構文も覚えずに済みます。
一方で、同じ条件を繰り返し眺めるなら Dataview が向いています。
特に「未完了タスク一覧」「直近の Daily Notes」「プロジェクト別の進行表」のように、同じ軸で毎日確認する情報は Dataview の守備範囲です。
構造化された表示をノートとして持てるので、Vault が育つほど差が広がります。

Dataviewクエリの基本構文

クエリタイプ4種の使い分け

DataviewのDQLは、最初の1行で「何として表示するか」を決めます。
ここで使うのが LIST、TABLE、TASK、CALENDAR の4種類です。
見た目の違いだけでなく、評価の単位や使える前提も少しずつ異なります。

もっとも手軽なのは LIST です。
対象ページの一覧を素早く出したいときに向いていて、まず動く形を確認したい場面でも扱いやすい形式です。
たとえば「Projectsフォルダのノートを新しい順で並べる」なら、次のような最小構成で十分です。

LIST
FROM "Projects"
SORT file.mtime DESC -- 最新順
LIMIT 10

TABLE は、ページを列付きで見たいときの定番です。
status や project のようなメタデータを横に並べると、単なる一覧より判断材料が増えます。
検索結果の羅列ではなく、管理表に近い見え方になるのが強みです。

TABLE status, file.mtime AS updated
FROM "Projects"
WHERE status
SORT file.mtime DESC -- mtime 降順
LIMIT 10

TASK は名前の通りタスク専用ですが、ここは LIST や TABLE と発想が少し変わります。
ページ単位ではなくタスク単位で評価されるので、1つのノートの中に未完了タスクが3件あれば、その3件が個別に抽出されます。
議事録やDaily Noteにタスクが散らばっている運用だと、この差が効きます。

TASK
FROM "Projects"
WHERE !completed
LIMIT 10

CALENDAR は日付ベースで眺めたい情報に向いています。
Daily Notes、締切、記録ログのように、1日ごとの位置づけで見たいデータと相性が良い形式です。
ただし、使うには有効な日付フィールドが必須です。
さらに SORT や GROUP BY はここでは効かないため、他の3種と同じ感覚で組み立てると引っかかります。

CALENDAR file.day
FROM "Daily"
WHERE file.day

コードブロックはDQLなら dataview を指定します。
JavaScriptでより柔軟に書くDataviewJSは別物で、そちらは dataviewjs を使います。
たとえば同じ一覧でも、JavaScript側では dv.pages や dv.table を組み合わせて組み立てます。

const pages = dv.pages('"Projects"').limit(10);
dv.table(["Name", "Updated"], pages.map(p => [p.file.link, p.file.mtime]));

まずはDQLの4種を使い分けるだけで、普段見る情報のほとんどは整理できます。
自分の運用でも、ページ一覧は TABLE、未完了の拾い出しは TASK、Daily Notesは CALENDAR と役割を分けたあたりから、クエリが読み返しやすくなりました。

FROM/WHERE/SORT/LIMIT/GROUP BY/FLATTENの要点

DQLの骨格は、クエリタイプの下に句を積み上げる形です。
通り、まず覚えたいのは FROM、WHERE、SORT、LIMIT、GROUP BY、FLATTEN の役割です。
全部を一度に使う必要はなく、FROM と WHERE だけでも実務では十分に役立ちます。

FROM はどこを見るかを指定する句です。
フォルダ、タグ、リンク元など、対象範囲を最初に絞ります。
Vault全体を横断することもできますが、ノート数が増えてくると範囲指定の有無で体感が変わります。
実際、数千ノートあるVaultで FROM を省いたクエリを置いたときは、表示がもたついて結果が出るまで待たされる感覚がありました。
これを FROM "Projects" に変え、さらに LIMIT 50 を添えただけで、開いた瞬間の引っかかりがぐっと減りました。
大規模Vaultでは、まず範囲を決めてから拾う、という順序で考えたほうが安定します。

TABLE file.link
FROM "Projects"

WHERE は何を残すかを決める句です。
メタデータの値や日付条件でフィルタできます。
たとえば未完了、特定ステータス、今週分だけ、といった絞り込みに使います。
期間指定では date(today) - dur(1 week) のような書き方もできます。

TABLE file.link, due
FROM "Projects"
WHERE status = "open" AND due >= date(today) - dur(1 week)

SORT はどの順番で並べるかを決めます。
更新日順、作成日順、期限順など、一覧の読み心地を左右する句です。
Daily Notesのようにファイル名に日付が入っている運用では、file.ctime より file.day のほうが意図通りの順番になりやすい場面があります。

LIST
FROM "Daily"
WHERE file.day
SORT file.day DESC
LIMIT 14

LIMIT は何件まで出すかを制御します。
最新10件、未完了10件のようなダッシュボード用途では特に効きます。
検索対象そのものを減らすのは FROM ですが、表示件数を抑えるのが LIMIT です。
両方を組み合わせると、一覧が長くなりすぎず、ノートを開いた直後の見通しも保てます。

GROUP BY は同じ値ごとに束ねる句です。
担当者別、ステータス別、カテゴリ別にまとまりを作れるので、「件数は見えるが塊がない」状態を抜けやすくなります。
単純なソートでは横並びの一覧にしませんが、グループ化すると視線の置き場が生まれます。

TABLE rows.file.link
FROM "Projects"
WHERE status
GROUP BY status

FLATTEN は最初つかみにくい句ですが、配列や複合データを1要素ずつ展開する役割があります。
たとえば1ページに tags や authors のような複数値が入っていると、そのままでは1セルにまとまって見えます。
FLATTEN を挟むと、各要素を個別の行や条件として扱えます。

TABLE file.link, author
FROM "Books"
FLATTEN authors AS author
SORT author ASC

この6つを「対象範囲」「条件」「順番」「件数」「束ね方」「展開」と読み替えると、クエリの意味が頭に入りやすくなります。
DQLはSQLほど大げさではありませんが、考え方は近く、どこを見るかを決めて、残すものを選び、見たい順に整える流れです。

file.*系プロパティ早見

DQLを書き始めた直後につまずきやすいのが、「まず何を表示すればよいか」です。
そこで頼りになるのが file.* 系プロパティです。
これは各ノートが最初から持っているファイル情報で、Frontmatterをまだ整えていない段階でも使えます。

代表的なものを押さえると、次の見方になります。

最初の一本としては file.link が扱いやすく、一覧からすぐ本文へ飛べます。
file.name は文字列だけを見たい場面で向いていますが、実運用ではリンク付きのほうが回遊しやすいので、ダッシュボードでは file.link を選ぶことが多くなります。

TABLE file.link, file.path, file.mtime
FROM "Projects"
SORT file.mtime DESC -- 更新日時が新しい順
LIMIT 10

file.ctime と file.mtime は似ていますが、意味は分かれます。
新しく作った順を見たいなら file.ctime、最近手を入れた順なら file.mtime です。
議事録や作業メモのように更新を追うノートでは、後者のほうが現場感に合うことが多いです。

file.day も見逃せません。
Daily Notesのようにファイル名自体が日付になっているノートでは、この値を軸にすると並び順も条件指定も素直になります。
作成日時ベースだと、後からファイルを作った日と記録したい日がずれることがありますが、file.day ならノート名の年月日をそのまま使えます。

TABLE file.link, file.day
FROM "Daily"
WHERE file.day
SORT file.day DESC
LIMIT 14

FrontmatterやInline Fieldsを整える前でも、file.* だけで一覧の土台は作れます。
そこに status や project を足していくと、単なるファイル一覧が、朝に開く運用ノートへ変わっていきます。

まずはコピペで試せるクエリ例10選

このパートでは、前提がそろっていればそのまま貼って動かせる形に絞って、まず試したい定番クエリをまとめます。
前提となるのは、たとえば Projects Notes Books Daily Tasks のようなフォルダ名、#idea のようなタグ、そして status due title author rating といったプロパティです。
プロパティの書き方自体は前述の通りで、ページ全体なら YAML Frontmatter、文中や個別タスク寄りなら Inline Fields を使うと組み立てやすくなります。
構文の細かいルールは『Structure of a Query』に整理されているので、まずはここで出てくる形を土台にすると崩れません。

自分の運用では、単一のダッシュボードノートにこの手のクエリをまとめて置いています。
週次レビューで開くと、未完了期限超過直近更新が同じ画面に並ぶので、どこに火がついているのかを数秒で拾えます。
Dataview は読み取り中心の道具なので、入力画面というより「今の Vault をどう見渡すか」の設計で効いてきます。

フォルダ／タグ／日付で始める基本レシピ

まずはファイルの置き場所やタグ、作成日・更新日で眺める基本形から試してみましょう。Frontmatter がまだ整っていなくても動く例を中心に紹介します。

まずは、ファイルの置き場所やタグ、作成日・更新日で眺める基本形です。
Frontmatter がまだ整っていなくても動くものが多く、最初の一本として扱いやすい組み合わせです。

前提として、Projects フォルダに案件ノート、Notes フォルダに雑記や調査メモ、#idea タグでアイデアを管理している状態を想定します。

1. フォルダ内のノートを一覧するクエリです。LIST はリンクだけを軽く眺めたいときに向いていますし、TABLE に変えると列を足せます。

LIST
FROM "Projects"

1. 特定タグの付いたノートだけを拾うクエリです。タグ運用を始めた直後でも効果が出やすく、散らばったメモを一か所で見られます。

LIST
FROM #idea

1. 作成日の新しい順に並べるクエリです。新規追加したノートを追いたいときに向いています。LIMIT 10 が入っているので、一覧が伸びすぎません。

TABLE file.link, file.ctime
FROM "Notes"
SORT file.ctime DESC
LIMIT 10

1. 更新日の新しい順に並べるクエリです。作った順ではなく、今触っているノートを見たいならこちらのほうが実務に合います。

LIST
FROM "Notes"
SORT file.mtime DESC -- file.mtime を降順で並べる
LIMIT 10

作成日順と更新日順は似ていますが、見える景色が変わります。
前者は「最近追加した知識」、後者は「今メンテしている知識」です。
ダッシュボードに両方置くと、蓄積と進行中の作業を切り分けて見られます。

タスク抽出

タスク系は、Dataview を導入して効果を感じやすい領域です。
TASK クエリはページ単位ではなくタスク単位で動くので、同じノートの中にあるチェックボックスから必要なものだけを抜き出せます。
ここでは Projects フォルダ配下のタスクと、due を持つ期限付きタスクを想定します。

1. 未完了タスクをまとめる基本形です。案件ノートの中にタスクを埋め込んでいるなら、これだけで進行中の作業一覧になります。

TASK
FROM "Projects"
WHERE !completed

1. 期限を過ぎた未完了タスクだけに絞るクエリです。締切管理が必要な Vault では、週次レビューの中心になりやすい一覧です。

TASK
WHERE !completed AND due < date(today)

期限超過の一覧は、件数が少ないほど健全です。
逆にここが増えているときは、ノートの整理より先に予定の再配分が必要だと気づけます。
自分のダッシュボードでも、この一覧と更新日順の一覧を並べるだけで、「止まっている案件」と「いま触っている案件」が分かれて見えるので、レビューの迷いが減りました。

ログ系

記録ノートとの相性も Dataview の強みです。
読書ログや日報のように、同じ型のノートが増えていく用途では、一覧化した瞬間に価値が出ます。
ここでは Books フォルダに title author rating を持つ読書メモ、Daily フォルダに日付ベースの Daily Notes がある前提です。

1. 評価の高い読書ログを表で見るクエリです。読み返したい本だけを上に寄せられます。

TABLE title, author, rating
FROM "Books"
WHERE rating >= 4
SORT rating DESC

1. Daily Notes を直近分だけ並べるクエリです。日付ベースのファイル名を使っているなら、file.day を軸にすると意図通りに並びます。

LIST
FROM "Daily"
SORT file.day DESC
LIMIT 14

LIMIT 14 は、2週間ぶんをざっと見返したいときに収まりがよく、ノートを開いたときの縦の長さも暴れません。
日報、作業ログ、体調メモのような連続記録は、検索で探すよりこの一覧を上から眺めたほうが流れをつかみやすくなります。

プロジェクトとグルーピング

案件管理に使うなら、status や due を Frontmatter に持たせておくと一覧の密度が一段上がります。
ここでは Projects フォルダの各ノートに status: active のような値と due を入れている前提です。

1. 進行中のプロジェクト一覧を期限順で並べるクエリです。着地点が近いものから見えるので、レビューの入口として使えます。

TABLE file.link, status, due
FROM "Projects"
WHERE status = "active"
SORT due ASC

1. ステータスごとに束ねるグルーピングの例です。件数を塊で見たいときに役立ちます。

TABLE file.link, status
FROM "Projects"
GROUP BY status

同じ考え方で、更新年ごとに束ねることもできます。年単位で棚卸ししたいときは、こちらのほうが向いています。

TABLE file.link, file.mtime
FROM "Projects"
GROUP BY dateformat(file.mtime, "yyyy")

グルーピングを入れると、単なる並び替えでは見えにくい偏りが出ます。
active に案件が集まりすぎているのか、waiting が滞留しているのか、といった状態が一覧の段階で見えてきます。
案件数が増えるほど、この「塊で把握できる感覚」が効いてきます。

CALENDARの前提

カレンダー表示も便利ですが、これは一覧系クエリと少し前提が違います。
有効な日付フィールドが必要で、ここでは Tasks フォルダのノートやタスクが due を持っている前提にします。
通り、CALENDAR は日付を軸に置く表示なので、表やリストと同じ感覚で句を足していくものではありません。

CALENDAR due
FROM "Tasks"

Daily Notes をカレンダーで眺めたい場面でも、考え方は同じです。
日付そのものが確実に取れることが前提になります。
日報や予定メモを「いつの記録か」で見返したいなら、表とカレンダーを役割分担させると、一覧で探す画面と日付で眺める画面がきれいに分かれます。

メタデータ設計のコツ：YAML FrontmatterとInline Fields

設計原則3つ

Dataview のクエリをあとから楽に保守したいなら、まず決めるべきなのは「どこに何を書くか」です。
ここが曖昧なままノートを増やすと、同じ意味の情報が Frontmatter と本文に散って、WHERE 条件も揺れ始めます。
Dataview は YAML Frontmatter と Inline Fields の両方を索引できます。
だからこそ、両方を使えることと、両方に同じものを書くことは別だと切り分けるのが出発点です。

1つ目の原則は、Frontmatter はページ単位の属性に寄せるということです。
たとえば type status tags owner のように、そのノート全体を代表する値は Frontmatter に置くと揺れません。
読書ノートなら「このページは本のメモで、著者は誰で、読了日はいつか」、プロジェクトノートなら「この案件の状態は何で、担当は誰か」といった情報です。
ページを開かなくても一覧化したい項目ほど、先頭に集めておく意味があります。

2つ目の原則は、Inline Fields は文中・段落・タスク単位の注釈に使うということです。
記法は Frontmatter の key: value ではなく、本文中の key:: value です。
たとえば会議メモの一段落に people:: tanaka を添えたり、作業タスクに due:: 2026-03-31 や estimate:: 30m を付けたりすると、その行だけを拾えます。
とくに TASK クエリはタスク単位で評価されるので、プロジェクト全体の期限を Frontmatter に置きつつ、個別タスクの締切だけ Inline Fields で持たせる設計が噛み合います。

3つ目の原則は、キー名の表記を早い段階で固定するということです。
日本語キーやスペース入りキーも書けますが、クエリ側では引用が必要になったり、参照時に手が止まったりしやすくなります。
自分の Vault でも、最初は 進捗状況 や review score のように人間には読みやすい名前を混ぜていましたが、DQL を書くたびに表記を思い出す必要がありました。
status start_date review-score のように英数字へ統一してからは、フィルタ条件をその場で短く書けるようになり、週次レビューで「いま active だけ見たい」「due が今週までのものだけ出したい」と切り替える速度が明らかに上がりました。
可読性は見た目より、クエリを書いた瞬間に効いてきます。

運用ルールも最初から絞っておくと崩れにくくなります。
必須キーは 2〜4 個に抑え、日付は YYYY-MM-DD の ISO 形式で統一し、既存キーを改名するときは移行期間を設ける。
この3つだけでも、あとで status と state が混在したり、2026/3/1 と 2026-03-01 が混ざって並び順が乱れたりする事故を避けられます。

Frontmatterテンプレート例

Frontmatter はノートの先頭を --- で囲み、その中に key: value で書きます。
読書ノートのように「1ページに1冊」という単位がはっきりしている用途では、ページ単位のメタデータと相性が良いです。
たとえば、最低限なら次の形で十分です。

title: "Clean Architecture"
author: "Robert C. Martin"
date: 2026-03-18
rating: 4
type: book
status: finished

この形にしておくと、TABLE title, author, rating のようなクエリが素直に書けますし、評価順や読了日順に並べ替えるときも条件がぶれません。
title はファイル名と重複する場面もありますが、書籍名に副題や原題を含めたいときは独立したフィールドとして持っておくと扱いやすくなります。

プロジェクト用のノートは、進行管理に必要なキーだけを残すほうが安定します。項目を増やしすぎると、入力されない空欄が増えて一覧が濁るからです。

type: project
status: active
due: 2026-03-31
owner: tanaka

このテンプレートなら、進行中の案件だけを期限順に出したり、担当者別に束ねたりできます。
Dataview は読み取り中心の設計なので、まずは「検索・一覧に必要な最小限の属性だけを確実に入れる」ほうが成果につながります。
項目数を欲張るより、全ノートで同じキーが埋まっていることのほうが一覧品質に効きます。

日本語キーを全て避ける必要はありません。
ただし、Dataview に寄せる運用なら英数字ベースの命名が扱いやすいのが利点です。
スペース入りキーも最初は読みやすく見えても、クエリ参照時には一段余計な手間が入ることを覚えておきましょう。
日本語キーを全て避ける必要はありませんが、Dataview に寄せて運用するなら英数字ベースの命名に統一すると、クエリ参照時の手間を減らせます。
スペース入りキーも、最初は読みやすく見えても、クエリ参照時には一段余計な気配りが入ります。
命名規則を snake_case か kebab-case のどちらかに決めて揃えるだけで、ノート数が増えたときの整備コストが下がります。

Inline Fieldsの実用例

Inline Fields は、ページ全体ではなく局所的な情報に向いています。
会議メモの一段落、読書ノートの引用メモ、そしてタスク行に直接メタデータを添えられるのが強みです。
Frontmatter が「このページは何か」を定義するものなら、Inline Fields は「この行に何が起きているか」を埋め込むものだと考えると整理しやすくなります。

たとえば、プロジェクトノートの本文に次のように書けます。
Inline Fields は局所的な情報に向きます。
ページ全体の属性は Frontmatter、行やタスクごとの値は Inline Fields、と役割を分けるとクエリが書きやすくなります。

次回レビューの担当者は田中です。people:: tanaka
見積もりの再確認が必要です。estimate:: 30m

この書き方なら、ページ全体の owner とは別に、特定の作業や文脈だけ people や estimate を持たせられます。
会議ノートでも「この発言は誰のものか」「この段落はどの案件に紐づくか」を後から拾えるので、本文がそのまま半構造化データになります。

タスクとの組み合わせは、さらに実務的です。

- [ ] 仕様レビューを返す due:: 2026-03-31 people:: tanaka
- [ ] 見積もり更新 estimate:: 45m status:: waiting

ここではページの Frontmatter に status: active が入っていても、各タスクには別の締切や見積もり時間を付けられます。
プロジェクト全体は進行中でも、個別タスクには待機中のものがある、という現場の状態をそのまま表現できます。
タスク単位で拾える Dataview の特性と噛み合うので、日々のレビューでは「今週期限のタスクだけ」「estimate が入っているものだけ」といった切り方がしやすくなります。

このときも、運用ルールは Frontmatter と同じです。
due の日付形式を統一し、estimate の単位表記を決め、people と owner の役割を分ける。
役割分担が曖昧だと、「担当者」はページに書くのかタスクに書くのか毎回迷います。
ページ責任者は owner、作業担当は people のように線を引いておくと、クエリで集計するときに意味が崩れません。

Dataview は数十万件規模の注釈付きノートまでスケール可能と案内されていますが、そこまで育った Vault で効くのは凝ったテクニックより命名の一貫性です。
設計が揃っていると、FROM で範囲を絞ったうえで LIMIT 10 のような短いクエリを組むだけでも、欲しい一覧に素早く届きます。
メタデータ設計は地味ですが、Dataview を「たまに動く便利機能」で終わらせず、毎日のレビュー画面に変える土台になります。

DataviewJSはいつ使うべきか

DQLで足りるケース

判断の基準は、欲しい情報を「列として並べるだけ」で済むかどうかです。
LIST TABLE TASK CALENDAR の標準クエリで、対象範囲を FROM で絞り、WHERE で条件をかけ、SORT と LIMIT で見たい順に整える。
ここまでで形になるなら、DataviewJS へ進む必要はありません。
Dataview LIMIT 10 のような短い実例が多くあります。
日々の一覧、表、未完了タスク、直近ノートの抽出といった用途は DQL だけで十分に回せます。

たとえば、読書メモを評価順に並べる、進行中のプロジェクトだけを期限順に出す、今週期限のタスクを拾う、といった場面です。
シンプルな集計や基本的な条件分岐も DQL の守備範囲に入ります。
日付計算も扱えるので、直近1週間や直近14件のような切り方までなら、標準クエリのほうが短く、後から見返しても意図を読み取りやすくなります。

学習順序の面でも、最初は DQL を優先したほうが筋が通ります。
DataviewJS は柔軟ですが、そのぶん JavaScript の文法と Dataview API の両方を意識することになるからです。
まず DQL で「どのノートを、どの条件で、どの順に見たいか」を固めると、一覧の設計そのものが整理されます。
その段階で不足を感じた部分だけを JS に置き換えるほうが、遠回りに見えて失敗が少なくなります。

DataviewJSが活きるケース

DataviewJS に進むべきなのは、表示の柔軟性そのものが目的になったときです。
『Dataview JavaScript API Overview』で案内されている通り、dataviewjs コードブロック内では dv.pages でページ群を取り出し、JavaScript の where や sort で整形します。
続いて dv.table などで好きな形に描画できます。
DQL が「宣言的に条件を書く道具」なら、DataviewJS は「取得した結果をどう見せるかまで作り込む道具」です。

向いているのは、複合列や条件付き表示を入れたいときです。
たとえば「担当者と期限を1列にまとめる」「期限切れだけ赤い記号を付ける」「評価がある本だけ星付きで見せる」といった整形は、DQL でも近いことはできますが、表現が伸びるほど読みにくくなります。
私も DQL で無理に列結合や条件付き表示を書いていた時期がありましたが、dv.table に短い JS を渡してしまったほうが、クエリ全体がすっきりしました。
見た目の調整だけでなく、あとで列を足したり条件を変えたりするときの修正箇所も減り、一覧の見通しが一段上がります。

DataviewJS は、複雑な条件分岐にも向きます。
ページの種類ごとに表示列を変える、値が空なら代替文字列を出す、複数フィールドを組み合わせて 1 つのセルにまとめる、といった処理は JavaScript のほうが素直に書けます。
DQL の延長として考えるより、「Dataview の索引を使って JavaScript でレンダリングする」と捉えたほうが腹落ちします。

もうひとつの境目は、他プラグインや外部データとの連携です。
Dataview は読み取り中心の設計ですが、DataviewJS なら Dataview の取得結果を別の処理に渡したり、独自の HTML ライクな表示に近づけたりできます。
単なる一覧を超えて、ノートを小さなダッシュボードとして見せたい場面では、DQL より DataviewJS のほうが収まりがよくなります。
クリックで展開するような表現や、表示内容を文脈に応じて変えるインタラクティブ寄りの見せ方も、この領域に入ります。

最小サンプル

最初の一歩としては、dv.pages("") でページを取り出し、JavaScript の where と sort で絞り込み、dv.table で描画する形がわかりやすいのが利点です。
コード量は少なくても、「DQL では取得」「DataviewJS では取得後の整形まで握る」という違いがはっきり見えます。
前提として JavaScript 実行を有効化しておく必要があります。

const rows = dv.pages("")
  .where(p => p.type === "book" && p.rating)
  .sort(p => p.rating, "desc")
  .map(p => [p.file.link, p.author ?? "不明", p.rating]);

dv.table(["本", "著者", "評価"], rows);

この例では、Vault 全体から type: book のノートを拾い、rating が入っているものだけを評価順に並べています。
dv.pages("") は入口、where と sort は加工、dv.table は出力という役割分担です。
ここに日付の整形や列結合を足していくと、DQL では窮屈だった表示を少ない行数で収められます。

移行の流れとしては、まず DQL で欲しい一覧を作り、その一覧に「列をまとめたい」「条件で見た目を変えたい」「別のデータと組み合わせたい」という要件が出た段階で DataviewJS に切り替えるのが自然です。
DQL を飛ばして最初から JS に入るより、この順番のほうが何を柔軟にしたいのかが明確になります。

よくあるエラーとハマりどころ

何も表示されない

Dataview で最初につまずきやすいのが、クエリを書いたのに結果が 0 件のまま動かない状態です。
見た目は「無反応」でも、実際にはクエリが一度も評価されていないか、対象が 1 件も見つかっていないことがほとんどです。

最初に見たいのは、コードブロックの言語指定です。
DQL なら dataview、JavaScript なら dataviewjs で始まっていないと、Obsidian はただのコードとして表示するだけで、クエリとして実行しません。
見た目が似ているので見落としやすいのですが、ここが 1 文字違うだけで何も起きません。

次に詰まりやすいのが FROM の指定です。
フォルダ名やタグの綴りが違うと、当然ながら対象は 0 件になります。
私も一度、FROM "Projects" と書くつもりが実際のフォルダ名は Project で、ずっと「Dataview が反応しない」と思い込んでいたことがありました。
実際はプラグインが止まっていたのではなく、対象が存在しなかっただけです。
FROM のパスやタグは文字列として扱うので、ダブルクォーテーションで囲む形も崩さないほうが安全です。

Obsidian の表示モードが影響して、編集中はまだ描画されず、プレビュー寄りの表示で結果が見えるケースもあります。
コード自体は正しいのに空白に見えるときは、クエリの中身だけでなく、いまそのノートがどう描画されているかも切り分けると原因が見つかります。

迷ったときは、いきなり複雑な条件を疑うより、まずは対象を最小限にしたクエリで動作確認すると切り分けが進みます。
Dataview公式ドキュメントでも基本例はシンプルな形から始まっており、入口で余計な条件を足さないほうが不具合の位置を特定しやすくなります。

並び順が意図と違う

SORT を書いたのに順番が妙なときは、並び替えの指定そのものより、比較されている型を疑うほうが当たりやすいのが利点です。
Dataview は見た目が日付や数値に見えても、実体が文字列なら文字列として並べます。
その結果、日付順のつもりが辞書順になり、途中で順番が崩れます。

典型例は日付表記の揺れです。
たとえば 2026/03/01 のようなスラッシュ区切りを混ぜていた時期、月次ノートの一覧で並びが安定せず、同じ 3 月のノートが前後に割り込むことがありました。
これを 2026-03-01 の ISO 形式にそろえた途端、並びが素直になりました。
見た目の違いは小さいのに、クエリの結果は別物になります。

数値でも同じことが起きます。
priority: 10 と priority: 2 が文字列として読まれると、10 が 2 より前後して見えることがあります。
こういうときは、保存している値の書き方を統一し、必要なら date のように型を明示してから SORT に渡すと崩れにくくなります。
降順にしたいのに DESC を付け忘れているだけ、という単純なケースもあるので、並びがおかしいときは型と方向の両方を見直すと早いです。

Daily Notes のようにファイル名そのものが日付なら、本文の独自フィールドより file.day を基準にしたほうが意図どおりに並ぶ場面があります。
作成日時の file.ctime だと、あとから作った過去日付ノートが混ざったときに時系列がずれるためです。

日付が認識されない

Dataview で日付フィールドが空扱いになるときは、書式が Dataview の期待する形から外れていることが多いです。
もっとも安定するのは YYYY-MM-DD の ISO 形式 で、日付として扱う前提のフィールドはこの形に寄せるのが基本です。

見た目では日付でも、Dataview 側ではただの文字列になっていることがあります。
その場合は date(フィールド名) で明示的にキャストすると、比較や並び替えが通ります。
とくに YAML や Inline Fields を混在させているノート群では、同じ「期限」のつもりでも一部だけ文字列扱いになり、抽出条件から漏れることがあります。

日付演算は Dataview の得意分野ですが、入力されている日付が Dataview に正しく解釈されていないと比較が機能しません。
入口の形式（ISO 形式の YYYY-MM-DD を推奨）に揃えておくと、日付演算や並び替えが安定します。

DataviewJSが動かない

この項目は、DQL が動いているぶん発見が遅れます。
dataview ブロックは出るのに dataviewjs だけ沈黙するので、「自分の JS が悪いのか」と思い込みやすいのですが、実際には設定未有効ということが珍しくありません。
前のセクションで触れた通り、DataviewJS は柔軟なぶん入口条件がひとつ増えます。

もうひとつ見逃しやすいのが、日本語プロパティです。
Obsidian の Properties では日本語キーを持てても、Dataview や DataviewJS で式として触った瞬間にパースで詰まることがあります。
とくにスペースや記号を含むキー名は、クエリ側の記述が不安定になりがちです。
実務では status due project のような英数字キーに寄せたほうが崩れにくく、既存ノートが多いなら移行期間だけ日本語キーと英数字キーを併記して吸収する形が現実的です。

更新されない/古い結果が残る

メタデータを直したのに一覧が古いままなら、クエリが壊れているのではなく、インデックスや描画が追いついていないことがあります。
こういうときはコマンドパレットから Dataview: Rebuild current view を実行すると、表示が更新されることがあります。
ノートを再保存して再インデックスを促しただけで直る場面もあります。

この手の不具合は、修正後も結果が変わらないので「まだ間違っている」と判断しがちです。
実際には値は直っていて、画面だけが古い状態を持っていることがあります。
とくにフィールド名を変えた直後や、複数ノートをまとめて手直しした直後は起きやすい印象です。

Vault 全体を広く走査するクエリほど、更新の反映を待つ間に挙動が読みにくくなります。
結果件数が多い一覧では LIMIT 10 のように表示量も抑えておくと、少なくとも「直っているのに見えない」状態を減らせます。

大規模Vault・Publish利用時の注意点

性能対策の基本セット

大規模な Vault でDataviewを運用するときは、クエリの書き方そのものが快適さを左右します。
まず押さえたいのは、FROM で対象を必ず絞るということです。
FROM なしのクエリは Vault 全体を走査するため、規模が大きいと重くなり、極端な場合はObsidianがフリーズする可能性があると案内されています。
公式には数十万件規模の注釈付きノートまでスケールするとされていますが、実務では「動くかどうか」より「日常操作の待ち時間が気にならないか」のほうが先に問題になります。
対象範囲を狭めるだけで、一覧の開き方は別物になります。

絞り込みの起点は、フォルダ、タグ、リンク元のどれかに寄せるのが扱いやすいのが利点です。
たとえばプロジェクト単位なら特定フォルダ、横断テーマならタグ、ハブノート起点ならリンクベースという形です。
トップページに何でも載せたくなりますが、Vault 全体を一枚で見ようとすると負荷も設計の複雑さも一気に増えます。
私は数千ノートの Vault でダッシュボードを組んだとき、最初は1ページに集約していましたが、体感の待ち時間が気になりました。
そこでフォルダ別に小さなブロックへ分割し、プロジェクト、日報、資料、未処理メモのように表示単位を分けたところ、開いた瞬間の引っかかりが減り、見る側の視線も散らなくなりました。

表示件数が多い一覧では、LIMIT もセットで入れておくと安定します。
Dataviewのクエリ例でも LIMIT 10 は頻出で、最新ノートや未完了タスクを先頭だけ見せる用途と相性が良いです。
たとえば「最近更新したノートを全部出す」より、「最近更新したノートを10件だけ出す」と決めたほうが、描画の負荷も視認性も抑えられます。
Daily Notes 系でも直近分だけ見たいなら件数を切る発想が有効で、一覧は保管庫ではなく入口だと割り切ると設計が軽くなります。

集計系のクエリも、1本で抱え込まないほうが運用しやすくなります。
重い GROUP BY や複数条件の集計をひとつのページに重ねるより、一覧ページと集計ページを分ける、あるいはクエリ自体を小さく分割するほうが実務では安定します。
とくにトップのダッシュボードは、毎回開くたびに全ブロックが再評価されるため、そこへ重い集計を集めると日常のテンポが崩れます。
「見る頻度が高いページほど軽く」「詳しい分析は別ページへ」という切り分けが効きます。

Publishでの代替案

公開先で Dataview 風の一覧を見せたい場合は、動的なクエリ表示に頼らず「静的に書き出す」運用へ切り替えるのが現実的です。
具体的には手動エクスポートや外部スクリプトでクエリ結果を Markdown 化する方法が一般的です。
特定の変換ツールを使う場合は、その公式ドキュメントや GitHub リポジトリを参照して運用方針を確認してください。

運用ベストプラクティス

大規模 Vault では、性能トラブルと表示更新の遅れが混ざって見えることがあります。
クエリを直したのに結果が古いままなら、まず再描画を促すほうが早い場面があります。
コマンドパレットの Dataview: Rebuild current view はそのための定番で、再保存で更新されるケースもあります。
クエリを何度も書き換えて原因を探す前に、表示側を一度リフレッシュすると切り分けが進みます。

日常運用では、ダッシュボードの役割を欲張らないことも効きます。
トップページは「全情報の集約点」ではなく、「次に開くページへの入口」として設計したほうが破綻しにくくなります。
最新10件、未完了10件、今週分だけ、といった短い一覧を置き、詳細は個別ページへ逃がす構成にすると、重さだけでなく情報の詰まり方も緩みます。
Dataview は読み取り中心の設計なので、何でも自動更新の業務アプリのように振る舞わせるより、既存ノートから必要な情報を薄く引く使い方のほうが長続きします。

運用を安定させるなら、メタデータ設計もクエリ負荷と一緒に考えると効率的です。
前述の通り、キー名の揺れや型の不統一があると、絞り込み条件が増え、結果としてクエリが長くなります。
大規模 Vault ではこの「小さな不統一」が積み重なって保守コストになります。
対象範囲を FROM で限定し、一覧は LIMIT で短く保ち、重い集計はページを分け、表示が怪しいときは手動リフレッシュで切り分ける。
この流れを最初から前提にしておくと、ノート数が増えても Dataview の便利さを失いにくくなります。

まとめ

Dataviewは、完璧なデータベースを先に作るより、まず1ページの一覧を動かしてから育てるほうが定着します。
入口として効くのは、よく見る情報だけを集めた小さなダッシュボードです。
学ぶ順番も、DQLで引く感覚をつかみ、次にメタデータを整え、足りない場面だけDataviewJSへ進む流れで詰まりません。
私自身はDaily 直近14件未完了タスク進行中プロジェクトの3パネルを1画面に置く構成が定番で、週次レビューで開くページが減り、見直しの時間も短くなりました。
Publishや大規模運用を見据えるなら、動的表示への期待を広げる前に、対象範囲と表示件数を先に設計しておくと運用がぶれません。