Obsidianを「ノート」ではなく「データベース」として使う運用術——Dataviewプラグインで自動更新ダッシュボード化

「今日のpending reviewのピッチを編集者順に並べたい」「進行中の案件だけ一覧で見たい」——そんなクエリを書くだけで、毎朝1枚のダッシュボードノートから業務を始められるとしたら？人気のノートアプリ「Obsidian」を、ノートではなくデータベースとして運用するワークフローをXDA Developersが紹介しています。鍵となるのは、コミュニティプラグイン「Dataview」とObsidian標準の「Properties」機能です。

ノートを溜め込むだけの「セカンドブレイン」は機能しない

しかし数か月でvault（保管庫）は数百のノートに膨れ上がり、フォルダは「良いアイデアが死んでいく迷宮」と化したと述べています。標準のグラフビューも、点と線の集まりを眺めるだけで実用的なインサイトはゼロ。アクティブな案件、先月のピッチ、未払いの請求書を探すたびに、通常検索ではうまく集約できず、情報を使う時間より探す時間のほうが長くなっていたといいます。

筆者は、ノートアプリは受動的なファイリングキャビネットであるべきではなく、能動的に機能する「エンジン」であるべきだったと振り返ります。たどり着いた結論はシンプルで、ノートを溜め込むこと自体は簡単で、本当に難しいのは「情報量が増えても使い続けられるシステム」を設計すること。これが出発点になりました。

Dataviewプラグインがvaultを「ローカルDB」に変える

転機になったのが、コミュニティプラグインのDataviewでした。Dataviewは、プレーンテキストのMarkdownファイル群を、実質的にローカルのデータベースとして扱えるようにするプラグインです。ノート同士を手動でリンクするだけでなく、ノート内にクエリを書いてvault全体から動的にデータを引っ張ってこられます。

具体的には次のような変化が起こると説明されています。

インデックスページを手動更新する必要がない
複雑なフォルダ階層へファイルをドラッグして整理する必要がない
簡単なクエリを書くだけで、ステータスやクライアントで絞り込んだ「進行中の執筆案件一覧」がリアルタイムで生成される

Markdownは静的な文章のためのフォーマットだという思い込みを、Dataviewが完全に壊したと筆者は語ります。適切なエンジンを組み合わせれば、テキストファイル群がエンタープライズ級のDBと同じくらい動的かつリレーショナルに振る舞えるという主張です。

ノートを「行」、プロパティを「列」として設計する

Dataviewを活かすには、ノートに対する考え方そのものを変える必要がありました。筆者は「ノート＝個別の文書」ではなく「ノート＝データベーステーブルの1行（row）」として扱うようになります。ここで重要になるのが、Obsidian標準のProperties機能です。

新しいノートを作るたびに、ブログ下書きでもクライアント請求書でも書籍要約でも、最初に構造化メタデータを入力するようにしたとのこと。たとえば次のようなキーを定義します。

プロパティ例	役割
`status:`	進行ステータス（pending / in review など）
`due_date:`	締め切り
`client:`	クライアント名
`type:`	ノートの種類（draft / invoice / summary など）

プロパティを全ファイルで標準化することで、Dataviewが即座に読み取れる「予測可能なデータ型」が手に入り、vault全体が厳格なスキーマを持つようになります。結果として「このファイルをどのフォルダに置くか」という不安からも解放されたといいます。プロパティさえ正しければ、フォルダ位置は重要ではなく、クエリが必要な場所に必要な情報を呼び出してくれるからです。

クエリ駆動のダッシュボードが「自己更新する個人OS」になる

クエリ駆動型のvaultに切り替えたことで、毎朝フォルダを掘り返す代わりに1枚のダッシュボードノートを開くだけで業務が始められるようになったと筆者は述べています。

裏側ではシンプルなDataviewクエリが動作し、記事内では一例として「pending reviewステータスのピッチを編集者名でソートして取り出すブロック」が挙げられています（記事の該当部分はそこで途切れており、それ以降の具体例の詳細は公表されていません）。

このセットアップは手動メンテナンスを大幅に削減できる点がポイントです。リスト更新やファイル移動、リンク切れの心配といった作業の負担が減り、ノート作成時に設定したプロパティを根拠に、データが自動で集約されていきます。

Obsidianをデータベースとして扱うようになったことで、ノートを「管理する」のではなく、ノートにワークフローを管理させる側に回れた——筆者はそう表現します。混沌としたデジタルクローゼットが、主体性の高い「個人用OS」へと姿を変えたという結論です。

フォルダ整理をやめて、1枚のダッシュボードに集約する

すでにObsidianを使っていて「ノートは溜まっているのに活用できていない」と感じているなら、フォルダ整理の労力を減らすために、まずはPropertiesでスキーマを決め、Dataviewで小さなダッシュボードを1枚作るところから試す価値があります。Dataviewはコミュニティプラグインとして無料で導入できます。ノートアプリへの不満が「探す時間が長すぎる」点にあるなら、即座に効果を実感できる更新です。

Obsidian純正「Bases」コアプラグインが事実上の後継に

記事で紹介されたDataviewは依然として強力ですが、2025〜2026年にかけてはObsidian開発元自身が手掛けるコアプラグインBasesが大きな潮流になっています。Basesはオブシディアンチーム自身による新しい取り組みで、いわば「公式版Dataview」とも言える位置付けで、現状はベータの早期アクセスで提供されています。利用するには設定からコアプラグインのBasesを有効化します。

観点	Dataview	Bases
提供形態	コミュニティプラグイン	コアプラグイン
操作	DQLというクエリ言語	ビジュアルなフィルタ／ソートUI
速度	大規模vaultで重くなりがち	大規模でも即時描画

Basesに乗り換える最大の理由は速度で、5万ノート超のvaultでもほぼ瞬時に描画される一方、Dataviewは特にモバイルでパフォーマンスを大きく低下させる傾向があります。Dataview自体は長らく大きなアップデートがなく、開発が停滞している点も無視できません。元記事のスキーマ設計（プロパティ＝列）はそのままBasesにも活きるため、移行コストは思ったより小さく済みます。

カンバン化・CLI連携など2026年に広がるBases周辺エコシステム

Basesの登場で、Dataview時代には難しかったインタラクティブな操作が一気に現実的になりました。象徴的なのが2026年3月にリリースされた拡張プラグインです。

Kanban Bases Viewプラグインは、Obsidianのベースをカンバンボードに変え、Status・Priority・Categoryなど任意のプロパティで列に分け、ドラッグ&ドロップでカード移動と同時にその値を直接更新できます。

指定プロパティを持たないノートは「Uncategorized」列に集約されるため、データが消えずに俯瞰できるのも実用上のポイントです。さらに本体側でも、2026年3月のアップデートで新しいCLI、Basesやファイル操作の拡張、ライブな画像リサイズ、ナビゲーション改善が一括投入されました。一方でBasesは完全にYAMLフロントマターのkey-valueに依存しており、Dataviewのようなインラインのkey-valueは読み取れないという制約もあり、用途に応じた使い分けが現実解になります。

Q&A

Q. Dataviewプラグインは有料ですか？ Dataviewはコミュニティプラグインで、無料で導入できます。

Q. フォルダ構成を作り込まなくても運用できますか？ 本ワークフローでは、ファイルがどのフォルダにあるかは重要ではないとされています。各ノートにプロパティ（status、due_date、client、type など）を正しく設定しておけば、Dataviewのクエリが必要な情報を必要な場所に集約してくれるという考え方です。

Q. どんなユーザーに向いていますか？ 複数の案件・下書き・請求書・リサーチノートを並行管理しているユーザー、たとえば筆者のようなフリーランスのライターや、複数プロジェクトを抱える知識労働者に向いた運用と紹介されています。ノートを「貯める」段階を卒業し、ノートに働かせたい人ほど効果が大きいと言えます。

Q. 学習コストは高くないですか？ 発想の転換として「ノートを行、プロパティを列」と捉え直す必要があるため、最初の設計には少し慣れが要ります。一方で導入後は、ノート作成時にプロパティを埋めるだけでダッシュボードが自動更新されるため、運用負荷はむしろ下がるというのが筆者の体験談です。