Obsidian Bases入門｜プレーンテキストのままNotion的DB運用をする

Notionのデータベースは便利だけど、結局ノートがクラウドの向こう側に行ってしまう。Obsidianのままプロパティで絞り込みたい。そう思ったことはないだろうか。

この記事では、Obsidian 1.9でコア機能になったBasesが何をしているのかを、実際に618本のノートへ`.base`ファイルを組んで検証した結果とともに解説します。

この記事で分かること

• Basesが「新しいデータベース」ではなく「ビューの重ね方」にすぎないこと
• Dataviewとの本質的な違いは速度でも構文でもないこと
• Basesにできないこと、Dataviewを残すべき場面
• プロパティが揃っていないノートに何が起きるか（実データで確認）

618本のノートに.baseを組んでみた

自分のknowledge-wiki vaultには、618本のMarkdownノートが溜まっている。テーマごとにbase_confidence（確からしさ）やtier（重要度）といったプロパティを振っており、これをBasesで一覧・並べ替えできれば便利だろうと考えた。

そこで実際に.baseファイルを1本書いた。特定フォルダのノートを、確からしさの高い順に並べるだけの単純なテーブルビューである。

filters:
  and:
    - file.hasTag("knowledge")
    - 'file.folder == "Knowledge/Tech/Productivity/PKM/concepts"'
views:
  - type: table
    name: "PKM concepts by confidence"
    order:
      - file.name
      - tier
      - lifecycle
      - base_confidence
    sort:
      - property: base_confidence
        direction: DESC

構文自体は素直だった。詰まったのはここではない。

理由はすぐに分かった。この618本は、記事を書くたびに同じ手順でノートを作る仕組みを通した後のものだったからだ。vaultのルート直下には、その仕組みができる前に書いた初期メモが数本残っている。開いてみると、frontmatterそのものが無い。

Basesのフィルタにこの数本を含めると、エラーは出ない。ただ一覧から静かに消える。プロパティを条件にする以上、プロパティを持たないノートは最初から検索対象の外なのだ。

Basesは何をしているのか

Bases は Obsidian 1.9 で導入されたコア機能で、インストール操作が要らない。ノート群をテーブル・リスト・カード・マップの4ビューで「データベースのように」表示・編集できる。

Notion的なDB運用をしたいからといって、ノートの実体をNotionに移す必要はない。プレーンテキストのファイルのまま、その上に検索・並べ替え・集計のレイヤーを重ねられる、というのがBasesの位置づけになる。

Dataviewとの違いは「編集できるか」

この役割は、長らくコミュニティプラグインのDataviewが担ってきた（2021年〜、300万インストール超）。

実務上効いてくる違いは、速度でもクエリの書きやすさでもない。クエリ結果をその場で編集できるかどうかである。Dataviewのクエリ結果は読み取り専用のレンダリングで、値を直したければ元のノートを開き直す必要がある。Basesはビュー上のセルを直接編集でき、その変更がプロパティに書き戻る。

表示と入力が同じ場所になる。この一点だけで、日々の運用の摩擦はだいぶ変わる。

ビューは4種類ある。テーブル、リスト、カード（画像付きのギャラリー的表示）、そしてマップ（Obsidian 1.10以降、公式コミュニティプラグインのMapsを別途入れる必要がある）。プロパティごとのグループ化や、列を右クリックしてのサマリー表示もできる。1.10.3ではreduce()・mean()・stddev()・median()・html()・random()といったformula関数が追加された。

Basesにできないこと

Basesで解決しない領域も、実際に触ってはっきりした。

• 非構造テキストをクエリできない。対象はプロパティとファイルメタデータだけで、本文中の記述を条件にはできない。条件にしたければ、その情報を先にプロパティへ昇格させる必要がある
• 複雑なテキストロジックが書けない。ビジュアルエディタの範囲を超える条件分岐は表現できない
• JavaScript APIにアクセスできない。Dataviewのdv.pages()のような柔軟な操作はできない

したがって、Basesは「Dataviewの完全な代替」ではない。2026年時点で現実的なのは、プロパティベースの単純な絞り込み・並べ替えはBasesに寄せ、複雑なテキストロジックや既存のDataviewクエリはそのまま残す、という併用である。

プロパティが無いノートは検索から消える

冒頭の実験に戻る。618本のノートでプロパティの欠落が0件だったのは、記事化のたびに同じ手順を通しているからだった。逆に言えば、この手順を経ていないノートはBasesの視界に入らない。

これはBasesの欠陥ではない。プロパティを唯一のデータ源にする、という設計の帰結である。フォルダやタグと違って、プロパティは書き手が意識して付けない限り存在しない。Basesを本気で使うなら、ノートを作る時点でのプロパティ付与を仕組み化しておく必要がある。あとから一括で付け直すのは、618本という規模になると現実的ではない。

まとめ

Basesは、Obsidianを「データベースアプリに乗り換える」ための機能ではない。プレーンテキストのまま、その上に検索・編集可能なビューを重ねるための機能である。

• データの実体はMarkdownのプロパティのまま。Bases自体はビュー定義でしかない
• Dataviewとの本質的な違いは「結果をその場で編集できるか」
• 非構造テキスト・複雑なロジックはBasesの対象外。Dataviewとの併用が現実的
• プロパティの無いノートはフィルタから静かに除外される。付与を仕組み化しておく

一覧に出てこないノートは、消えたわけではない。ただ、探し方を知らなければ見つからない。

→ このブログを書いている人について

関連記事