Obsidian Basesでノートを一覧化し、資料を絞り込む方法

Obsidian Basesは、ノートと表をどう結び付ける？

BasesはObsidianのコアプラグインです。表形式のビューでは、1行が1つのファイル、列がそのファイルの項目に当たります。ノートに「未確認」「確認済み」という状態を持たせると、本文を1枚ずつ開かなくても、その項目を表で見渡せます。公式：Basesの概要

ここでいうプロパティは、ノートに付ける名前付きの情報です。本文へ「確認済み」と文章で書く場合と、statusというプロパティへ「確認済み」と入力する場合では、今回の絞り込みが見る場所が違います。表で使いたい情報は、共通のプロパティへ入力します。

公式の説明では、データはローカルのMarkdownファイルとプロパティに保存され、見せ方を.baseファイルなどで定義します。別の表へ写し取った内容だけを編集するつもりで操作すると、元のノートの項目が変わったことを見落としやすくなります。試すときは、表と元ノートを行き来してください。

保管庫やノートの作成から知りたい場合は、先にObsidianの基本と始め方を確認すると、この後の操作を追いやすくなります。

Basesに並べる4枚のノートを準備する

練習用の保管庫にResearchというフォルダを作り、資料A、資料B、資料C、資料Dの4枚のノートを置きます。今回は「どの資料を次に読むか」を選ぶことが目的なので、入力項目は3つに絞ります。顧客資料を使わなくても、表の基本動作は合成ノートで確認できます。

プロパティは「ファイルプロパティを追加」のコマンドや、ノートの先頭へ---を入力する方法などで追加できます。公式資料では、同じ名前のプロパティには保管庫全体で同じ型を使うと説明されています。既にstatusをリスト型などで使っている保管庫なら、練習用の保管庫を分けるか、別の項目名にそろえてください。公式：プロパティの追加と型

4枚の入力内容は次のようにします。「空欄」は未確認という意味を持つ特別な値ではなく、確認日をまだ入力していない状態です。確認日は日付型に設定し、表示される見た目だけで判断せず、型のアイコンも確認します。

資料Aをソース形式で書くなら、次のようになります。先頭の区切りの内側がプロパティ、下側が本文です。この例のURLは実在する公式資料ですが、確認状態と日付は説明用に設定したものです。

---
status: 未確認
checked_on:
source_url: https://obsidian.md/help/bases
---
# 資料A
練習用のノートです。
資料を読んだら、判断に使いたい点をここへ追記します。

本文には要約や考えたこと、プロパティには表で選びたい項目を置くと役割が分かれます。毎回読む長い文章まで列へ入れようとせず、一覧から開く資料を選べる程度に留めると、入力を続けやすくなります。

Basesの表を作り、対象と列を決める

4枚ができたら、Baseを作成します。公式が案内する方法の一つは、ファイル一覧で作成先のフォルダを右クリックし、New baseを選ぶ操作です。コマンドパレットではBases: Create new baseも使えます。画面の表示名はアプリの言語や版で異なる場合があります。公式：Baseの作成

1. 設定のコアプラグインでBasesを確認します。コマンドが見つからないときは、機能の有効化と利用中のアプリ版を確かめます。
2. 練習用の保管庫にBaseを作り、「資料一覧」と名付けます。
3. ビューの種類をTableにし、表示名を「全件」にします。
4. 対象をResearch内のMarkdownノートへ絞ります。次の節に全体フィルターの例を載せています。
5. 列にファイル名、status、checked_on、source_urlを表示します。

ここでは、Baseを置いたフォルダだけが自動的に対象になるとは考えないでください。公式の構文説明では、フィルターを設定しないBaseは保管庫の全ファイルを対象にします。自分で対象フォルダと拡張子を指定することが、意図した4枚に絞る条件です。公式：Basesの構文とフィルター

最初の確認は「表ができた」だけで終えず、ファイル名が資料A〜Dの4件か、各行の状態が入力表と一致するか、source_urlが対応する資料を指すかを照合します。別のノートやBase自体が含まれていたら、件数を合わせるためにファイルを消すのではなく、対象条件を見直します。

表は見せ方の一つです。今回の目的は画像ギャラリーや複雑な計算を作ることではないので、まずは4つの列を読める状態にします。ノート数を増やすのは、対象と表示項目の関係を説明できてからで十分です。

Basesで「未確認だけ」のビューを作る

全件を見られるようになったら、未確認の資料だけを表示するビューを追加します。同じBaseの中に、条件の違う表を用意する考え方です。「全件」と「未確認」を行き来できると、対象フォルダの問題と、状態の条件による絞り込みを分けて確認できます。

全体の条件と、ビューごとの条件を分ける

以下は、公式構文を基に編集部が組んだ.base定義の例です。全体でResearch内のMarkdownファイルに限定し、「未確認」ビューでだけstatusの条件を加えています。公式仕様では全体とビューの条件は両方を満たす必要があるため、個別ビューを作っても全体の条件を無視できません。

filters:
  and:
    - file.inFolder("Research")
    - 'file.ext == "md"'
views:
  - type: table
    name: 全件
    order:
      - file.name
      - note.status
      - note.checked_on
      - note.source_url
  - type: table
    name: 未確認
    filters: 'note.status == "未確認"'
    order:
      - file.name
      - note.status
      - note.checked_on
      - note.source_url

例のコードを.baseファイルとして保存して開く

上のコードを使う場合は、普段の保管庫ではなく、4枚の合成ノートを作った練習用の保管庫で試します。公式では、Basesの定義を.baseファイルへ保存する方法と、ノートのbaseコードブロックへ埋め込む方法が案内されています。ここではファイルとして保存する方法を使います。公式：Basesのファイル形式／公式：Baseの作成と埋め込み

1. テキストエディタで新しいファイルを作り、上のコードの中身を貼り付けます。
2. 練習用の保管庫の直下、つまりResearchフォルダと同じ階層へ、UTF-8のテキストとして資料一覧.baseという名前で保存します。同名のファイルがあれば上書きせず、資料一覧-練習.baseなど別の名前にします。
3. 保存後の拡張子を確認します。資料一覧.base.mdや資料一覧.base.txtではなく、末尾が.baseになっていることを確かめます。
4. Obsidianでその練習用の保管庫を開き、ファイル一覧から保存した.baseファイルを選びます。「全件」と「未確認」のビューを切り替え、下記の期待値と照合します。

通常のMarkdownノートへ埋め込む場合は、同じコードを、開始行が```base、終了行が```のコードブロックで囲みます。本文へそのまま貼ったり、yamlという言語名のコードブロックに入れたりする方法とは区別してください。保存済みのファイルをノートに表示する方法として、![[資料一覧.base]]という埋め込みもあります。まずは上のファイル保存の方法だけで試すと、定義の保存先を確認しやすくなります。

file.nameはファイル名、note.statusはノートに付けたstatusを参照します。orderはここでは列の並びを指定しています。この例には行の並び順を固定する設定を入れていないため、AからDの順に表示されることまでは期待値に含めません。構文やプロパティ参照の詳細は公式のBases構文で確認できます。

この定義と4枚の合成データから計算すると、全件ビューの対象は4件、未確認ビューは資料Aと資料Cの2件です。ノートが表から外れることと、ノートそのものを削除することは別です。条件を満たさなくなった資料も、元の保存場所に残っているか確かめます。

状態を編集したら、元ノートまで確認する

次に、練習として資料Aのstatusを「確認済み」に変更し、checked_onへ確認日を入れます。表のセルを編集したら資料Aのノートを開き、同じプロパティが更新されたかを見ます。表の表示用メモだけを直したつもりにならないことが、この確認の目的です。

変更後の期待値は、全件が4件のまま、未確認が資料Cの1件になる状態です。もし資料Aが残る場合は、元ノートの値が変わったか、選択中のビューはどれか、条件の文字が一致するかを順番に確認します。記事ではこの変更をアプリ上では実行していないため、読者の環境で元ノートと表示結果を照合してください。

集計の数字は、どのビューの数字かを見る

表ビューには列の集計があり、公式資料では、そのビューに表示されている行を対象にすると説明されています。したがって、未確認ビューの件数を資料全体の件数として読んではいけません。たとえばファイル名のような空欄のない列のFilledを使って確認する場合も、全件ビューか未確認ビューかを一緒に記録します。公式：表ビューと集計

「未確認が減った」という結果を見るときは、状態を変えたのか、フィルターを変えたのかも区別します。後者なら資料を読んだ証拠にはなりません。仕事で利用するときは、一覧の数字と実際の確認作業を結び付けるルールが必要です。

Basesに表示されないときの確認順

表示されない場合は、最初からプロパティを作り直すより、同じ1枚を使って条件を一つずつ確認します。対象ノートを開けるなら、本文が失われた問題なのか、表の対象から外れた問題なのかを切り分けられます。

項目名と列の表示名も区別してください。見やすさのために列へ「状態」という表示名を付けても、元のプロパティ名がstatusなら、条件式はその名前を参照します。公式構文では、表示名はフィルターや数式の参照名に使われないと説明されています。

また、見せるノートを絞っただけでは、共有相手に対する閲覧制限を設定したことにはなりません。会社の資料を扱うときは、ファイルの保存先、共有する範囲、変更する担当を別途決めます。道具の選択も含めて検討したい場合は、ObsidianとNotionの比較で共同作業の条件を確認してください。

Basesは、次に読む資料を選べるところから始める

最初の目標は、4枚を一覧にすることと、未確認の2枚を取り出すことです。その後、1枚の状態を変え、元ノートと未確認の件数を照合します。この小さな確認ができると、項目を増やすときも「この列は何を選ぶために必要か」を判断しやすくなります。

実際の業務では、資料を誰が確認するか、確認済みとは何を終えた状態か、古い資料をいつ見直すかまで決めると、表が次の行動につながります。会社のナレッジ整理やAIから参照する資料の範囲に課題がある場合は、PLaiのAI社員導入支援で、対象業務と保存・更新の流れを整理できます。

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

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

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

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

30分の面談を申し込む↗

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

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