Obsidian Dataviewの使い方完全ガイド｜クエリの基本からBases連携まで

Obsidianにノートをどんどん貯めてはいるものの、Dataviewは難しそうでなんとなく後回しにしている——そんな段階の方に向けて書いています。

私自身も最初は標準検索だけでノートを探していましたが、記事数が増えてくると「あのメモ、どこに書いたっけ」と探す手間が増していきました。Dataviewを使い始めてからは、条件を指定するだけで欲しいノートの一覧が自動で表示されるようになりました。必要な情報を常に表示させておけるので、とても便利です。

この記事では、Dataviewの基本構文をLIST → WHERE → SORT → TABLEの4ステップで解説したうえで、ブログ管理用ダッシュボードの作り方、そして2025年にObsidian本体へ標準搭載されたBases、コミュニティプラグインのBase Boardとのハイブリッド運用までを一通りまとめています。

この記事で分かること

NotionとObsidianの設計思想の違い
Dataviewクエリの基本構文（LIST・WHERE・SORT・TABLE）
ブログ・ノート管理ダッシュボードの作り方
Dataview・Bases・Base Boardの役割分担とハイブリッド運用

Index

Obsidianを「動くデータベース」に変えるDataview
1. Notionと何が違う？ローカルテキストをデータベース化する仕組みとメリット
準備編：ノートに「メタデータ（Properties）」を持たせよう
実践編：Dataviewクエリの基本4ステップ
応用編：ブログ・ノート管理ダッシュボードを作ってみよう
発展編：Bases・Base Boardと組み合わせたハイブリッド運用
まとめ

Obsidianを「動くデータベース」に変えるDataview

DataviewはObsidianのコミュニティプラグインで、ノートのフロントマター（プロパティ）やタグを読み込み、条件に合ったノートをテーブルやリストとして自動表示してくれます。手動でリンクや目次を更新する代わりに、クエリを1つ書いておけば、新しいノートを追加するたびに一覧が自動で更新されます。

Notionと何が違う？ローカルテキストをデータベース化する仕組みとメリット

Notionを使っていた方（私も含め）がObsidianに移行すると、まず戸惑うのが「データベースがない」という点です。実はObsidianには単一のデータベースという概念自体が存在せず、独立したMarkdownファイルの集まりを、Dataviewが仮想的に集約して表示しているにすぎません。ファイルそのものはあくまでファイルのまま、という感覚を持っておくと理解しやすくなります。

比較軸	Notion	Obsidian（Dataview）
データの実体	単一データベース内のレコード	独立したMarkdownファイル群
一覧表示の仕組み	データベースのビュー機能	クエリでファイルを都度集計
保存場所	クラウド（Notion社のサーバー）	ローカル（自分のPC・端末）
オフライン利用	制限あり	制約なく利用可能
学習コスト	GUI操作が中心で低め	クエリ構文の習得が必要

クラウド前提のNotionに対し、Obsidianはローカルのテキストファイルという資産をそのまま活かせる点が最大の違いです。その分、Dataviewのようなプラグインでの「集計の仕組み」を自分で用意する必要がある、と捉えるとイメージが掴みやすいと思います。

準備編：ノートに「メタデータ（Properties）」を持たせよう

Dataviewはノートの中身を読んでいるわけではなく、フロントマター（プロパティ）やインラインフィールドといったメタデータを頼りにノートを抽出しています。ここでの設計が雑だと、後続のクエリがすべて期待通りに動かなくなるため、最初に丁寧に整えておく価値があります。

プロパティ設計そのものについては、Obsidianのプロパティを最小構成から育てる考え方で詳しく解説しているので、あわせて読んでいただくとスムーズに理解できると思います。

Frontmatter（YAML）の基本ルールと統一テンプレート

Dataviewで扱うプロパティは、ノート冒頭の---で囲まれたYAML（Frontmatter）に書きます。この記事のダッシュボード例では、以下のようなブログ管理用プロパティを想定します。

📋 以下は、そのままご自身のノートにコピペして使えるサンプルです。

---
title: 記事タイトル
type: blog
status: draft
category: Obsidian
updated: 2026-08-30
---

typeでノートの種類、statusで進行状況、categoryでテーマ、updatedで更新日を管理する、というシンプルな構成です。同じ種類のノートには、必ず同じプロパティ名・同じ書式を使うことを徹底してください。こうすることで、Dataviewを使いやすくできます。

インラインフィールド（::）とPropertiesの使い分け

Dataviewには、Frontmatterとは別にインラインフィールドという書き方もあります。本文中にキー:: 値と書くだけで、その場でメタデータとして扱われます。

評価:: 4
読了日:: 2026-08-15

ノート全体に関わる情報はFrontmatterに、文中の特定の一文に紐づく情報はインラインフィールドに、という使い分けが基本です。ブログ管理のようにノート単位で管理したい場合は、基本的にFrontmatterだけで十分です。

初心者が陥りやすい3つのつまずきポイント

Dataviewのクエリが「動かない」と感じたときは、たいていクエリ自体ではなく、メタデータ側に原因があります。

⚠️ 特に以下の3点は、慣れないうちに見落としがちです。

YAMLのインデントミス: スペースの数が揃っていないと、プロパティが正しく認識されません
コロン後の半角スペース抜け: status:draftのようにスペースを省略すると値が読み込まれません（status: draftのように必ず1つ空けます）
プロパティ値の表記ゆれ: draftとDraftのように大文字・小文字が混在すると、別の値として扱われ検索に引っかからなくなります

この3点を押さえておけば、この後のクエリでのトラブルはかなり減らせるはずです。

実践編：Dataviewクエリの基本4ステップ

ここからは実際にクエリを書いていきます。いきなり複雑な構文を覚える必要はなく、LIST（範囲確認）→ WHERE（絞り込み）→ SORT（整列）→ TABLE（表化） の順に、1つずつ機能を足していく形で進めます。
以降の例では、ブログ執筆の進行状況を例にしていますが、タスク管理などに置き換えても使えるので、ぜひ試してみてください。

📋 これ以降に登場するコードブロックはすべて、ご自身のObsidian VaultのノートやCanvasにそのままコピペして試せるサンプルクエリです（Dataviewプラグインが有効な状態でのみ動作します）

STEP1：LISTとFROMで対象フォルダ・タグを絞る

まずはLISTで、対象となるノートの範囲を確認します。

LIST
FROM "Blog"

"Blog"フォルダ内のノートが、シンプルなリストとして表示されます。タグで絞りたい場合はFROM #blogのように書き換えてください。

STEP2：WHEREで目的のノートだけを抽出する

WHEREを足すと、条件に合うノートだけに絞り込めます。

LIST
FROM "Blog"
WHERE status = "draft"

statusプロパティがdraftのノートだけが表示されるようになります。準備編で表記ゆれに気をつけると言ったのは、まさにこの条件指定を正しく機能させるためです。

STEP3：SORTで日付や名前順に整列する

SORTで並び順を指定します。

LIST
FROM "Blog"
WHERE status = "draft"
SORT updated DESC

updated（更新日）の新しい順に並び替えられました。ASCにすれば昇順になります。

STEP4：TABLEとASで見やすい日本語表を作成する

最後にLISTをTABLEに変え、表示したい列と日本語の見出し（AS）を指定します。

TABLE
  status AS "状態",
  category AS "カテゴリ",
  updated AS "最終更新"
FROM "Blog"
WHERE status = "draft"
SORT updated DESC

ここまでで、下書き中の記事だけを最終更新日順に並べた、日本語見出し付きの表が完成しました。この4ステップの組み合わせが、Dataviewクエリのほぼすべての基礎になります。

応用編：ブログ・ノート管理ダッシュボードを作ってみよう

基本の4ステップを組み合わせると、ブログ運営を想定した実用的なダッシュボードが作れます。ここからはクエリが少し複雑になりますが、1つずつ実践していけば、ご自身のノートがさらに見やすくなるはずです。

下書き・レビュー待ち・公開済みを自動分類する

status != "archive"のように否定条件を使えば、「アーカイブ済み（archive）以外のステータス（draft、review、publishedなどをプロパティとして指定していた場合）をすべて表示する」といった逆方向の絞り込みも可能です。

📋 コピペ用サンプル:

TABLE
  file.link AS "記事",
  status AS "状態",
  category AS "カテゴリ",
  updated AS "最終更新"
FROM "Blog"
WHERE type = "blog" AND status != "archive"
SORT updated DESC

file.linkを使うと、ファイル名がそのままクリック可能なノートリンクとして表示されます。表の一番左にこれを置いておくと、そのままダッシュボードから該当ノートへ移動できて便利ですよ。

※ file.link や file.ctime（作成日時）のように file. から始まる項目は、Frontmatterに書かなくても自動で利用できる「暗黙的フィールド（Implicit fields）」です。利用できる一覧や詳しい構文は以下の公式ドキュメントで確認できます。

公式

GROUP BYでカテゴリ別記事数を集計する

GROUP BYを使えば、カテゴリごとの記事数のような集計も可能です。

📋 コピペ用サンプル:

TABLE length(rows) AS "記事数"
FROM "Blog"
WHERE type = "blog"
GROUP BY category

カテゴリごとに何本記事があるか、公開バランスを見直したいときに役立ちます。

コピペ用Frontmatterテンプレート

ダッシュボードを機能させる前提となる、ブログ管理用のFrontmatterテンプレートをまとめておきます。新規記事作成時にこのままコピーして使ってください。

---
title: 記事タイトル
type: blog
status: draft
category: カテゴリ名
updated: 2026-08-30
---

発展編：Bases・Base Boardと組み合わせたハイブリッド運用

Dataviewだけでも十分便利ですが、2025年にObsidian本体へ標準搭載されたコアプラグインBasesと、そのカンバン表示を担うコミュニティプラグインBase Boardを組み合わせると、さらに直感的な運用が可能になります。役割はシンプルに分担できます。

プラグイン	役割	得意なこと
Dataview	検索・集計	複雑な条件でのクエリ・定点観測
Bases	GUI表・カード管理	テーブル上での直接編集
Base Board	ステータス移動	ドラッグ&ドロップでプロパティを更新

【閲覧・集計】コードで柔軟に抽出する「Dataview」

ここまで解説してきた通り、Dataviewは複雑な条件でのクエリや、GROUP BYを使った集計に強みがあります。プロパティを直接編集することはできない「読み取り専用」の集計ツール、と捉えておくと役割がはっきりします。

【直感操作】GUIで手軽に管理する「Bases」

Basesは、テーブル上のセルをクリックしてその場でプロパティを書き換えられる点がDataviewとの決定的な違いです。コードに慣れていない方でも扱いやすく、GUIだけでテーブルを作れます。Basesの構文や埋め込み方法については、Obsidian Basesの構文と使い方をまとめた記事で実例つきで詳しく紹介しています。

【ステータス移動】ドラッグ&ドロップでFrontmatterを書き換える「Base Board」

Base Boardは、Basesのデータをカンバンボード形式で表示するプラグインです。カードをドラッグ&ドロップでカラム間移動させるだけで、裏側のFrontmatterが自動更新されます。「下書き」→「レビュー中」→「公開済み」といった制作フローを視覚的に管理したい場合に向いています。具体的なセットアップ手順はBase Boardの導入・運用方法を解説した記事にまとめています。

初心者におすすめのハイブリッド運用フロー

複雑な条件でノートを横断的に集計したいとき → Dataview
テーブルを見ながらその場でサクッと編集したいとき → Bases
制作フローの進捗をドラッグ&ドロップで管理したいとき → Base Board

3つを対立するものと捉えず、目的に応じて使い分けるのがおすすめです。

なお、より高度な処理をしたい場合はDataviewJS（JavaScriptを使ったクエリ）という選択肢もありますが、導入のハードルが上がるため、この記事では深く扱いません。興味のある方は公式ドキュメントを参考にしてみてください。

公式サイト：DataView - JavaScript Reference

💡 補足になりますが、Dataviewはコミュニティプラグインであり、Basesのような公式コア機能に比べると開発ペースが緩やかになっている、という声も一部で見られます。現状すぐに使えなくなるようなものではありませんが、今後を見据えて、シンプルな用途は少しずつBasesへ寄せていく、という選択肢も知っておくと安心です。

まとめ

最後に、クエリがうまく動かないときのチェックリストをまとめておきます。

Frontmatterのインデントは揃っているか
コロンの後に半角スペースは入っているか
プロパティの値に表記ゆれ（draftとDraftなど）はないか
FROMで指定したフォルダ名・タグ名は正確か

この4点を見直せば、たいていのつまずきは解消できるはずです。

Dataviewは、慣れてしまえば「ノートを探す」時間を大きく減らしてくれるプラグインです。まずはこの記事の4ステップのクエリを、自分のVaultの小さなフォルダで一つ試してみてください。慣れてきたら、BasesやBase Boardと組み合わせて、自分に合った運用スタイルを育てていけると思います。