見出し画像

Obsidianのノート管理は「フォルダ中心」から「Dashboard中心」へ

ハイノ

はじめに

デイリーノート、読書メモ、Web記事のClippings、仕事の記録、行きたい店、記事のアイデア。Obsidianを使い続けるうちに、ノートは種類ごとにフォルダへ収まっていった。

それでも困るようになった。困っているのは「どこに保存したか」ではなく、「今見るべきノートはどれか」だった。

フォルダを開けばノートは見つかる。しかし、そこに並んでいるのはファイル名の一覧だ。

  • まだ処理していないノートはどれか

  • 今進めているものは何か

  • 記事にできそうな情報はどれか

  • しばらく更新していないノートは何か

こうした問いに、フォルダだけで答えるのは難しい。

そこで、分野ごとにObsidianのBasesを用意し、Dashboardを入口にする方式へ少しずつ移している。

フォルダは保管場所、Dashboardは操作画面

先に整理しておくと、Dashboard方式に移してもフォルダは不要にならない。

  • 情報の保存場所を大まかに分ける

  • 自動化ツールの出力先を固定する

  • 公開用と非公開用のノートを分離する

これらはフォルダでしかできない。

一方、フォルダは「一つの場所」しか表現できない。あるClippingが「AI」に関する情報であり、「記事化候補」であり、「未処理」であり、「今週追加されたもの」でもある場合、フォルダだけでこれらを同時に表せない。分類軸ごとにフォルダを増やせば、今度はどこへ置くか迷う。

ノートが増えて必要になったのは、分類ではなく状態の管理だった。未処理か処理済みか、進行中か完了か、次に何へ使うのか、最後に更新したのはいつか。これはファイル管理ではない。

フォルダは保管場所として優秀だが、状態を見ながら仕事を進める操作画面としては弱い。管理の中心をDashboardへ移す意味は、見た目をきれいにすることではなく、ノートを「保存されたファイル」ではなく「次の処理を待つ情報」として扱えるようにすることだ。

4層に分けて考える

Dashboard方式は、次の4層に分けると考えやすい。

フォルダ → プロパティ → Bases → Dashboard

保管場所、状態、抽出、入口の順に流れる。

1. フォルダは保管場所

読書メモは読書フォルダ、ClippingsはClippingsフォルダ、記事は記事フォルダ。大きな責任範囲だけを分け、細かな状態はフォルダで表現しない。

2. プロパティは状態と意味

ノートに最低限のプロパティを持たせる。

type: clipping
status: unprocessed
created: 2026-08-08
updated: 2026-08-08
genre: knowledge-management
next_use: article

大切なのは、最初から項目を増やしすぎないことだ。入力されないプロパティを大量に用意しても、管理項目だけが増えて運用が続かない。

3. Basesは検索・抽出・集計

フォルダやプロパティを条件にして、同じノート群から複数のビューを作る。Clippingsなら「要約待ち」「記事化候補」「保管のみ」「最近追加したもの」といったビューになる。

ノートを別の場所へ移動しなくても、条件を変えるだけで複数の切り口から見られる。

4. Dashboardは人が見る入口

Baseファイルを直接開くだけでも一覧は見られる。それでもMarkdownノートにビューを埋め込むのは、何のための一覧なのかを書き添えられるからだ。

## 今処理するもの
![[Clippings.base#要約待ち]]

## 次の記事に使えそうなもの
![[Clippings.base#記事化候補]]

Dashboardには一覧だけでなく、「この画面をいつ見るか」「上から何を処理するか」も書いておける。

Baseがデータの抽出を担当し、Dashboardが人間の判断を助ける。この二つは分けた方がよいと思う。

読書ノートで試した

実際に作ってみたのは、読書ノートのDashboardだった。未読・読書中・読了だけでなく、レビュー待ちや記事化できそうな本まで含めて一覧にした。

1冊ずつノートを探すよりも、「今読んでいる本」「感想を書いていない本」が一目で分かる方が便利だった。構成の詳細は以前の記事に書いている。

https://note.com/hainote/n/naaa2e7b512ae

一つ動かしてみて、同じ形が他の分野にも使えると分かった。

次に作る単位

同じ形で、次の単位を考えている。

Clippings — 外部から保存した記事や動画を、保存したまま沈ませないための画面。要約待ち、記事化候補、行動候補、保管のみ。ジャンル別にきれいに並べることより、「次に何へ変換するか」が見えることが大事だ。

アイデアと記事 — 思いついたまま放置せず、アイデアから公開までを一つの流れとして見る。別々の一覧で持つより、つなげた方が「アイデアは多いのに記事にならない」という詰まりが見えやすい。

振り返り — デイリーノート、目標、振り返りをつなぐ画面。最近の日次ノート、未完了タスク、継続中の目標、振り返り未記入。記録の一覧ではなく、次の行動を決めるための画面にしたい。

Home Dashboardで横断する

分野別Dashboardが増えたら、その上にHome Dashboardを置く。

ただし、すべてのノートを並べる必要はない。出すのは、今の自分が判断すべきものだけでよい。未処理のInbox、進行中のアイデアや記事、レビュー待ちの読書ノート、一定期間動いていない進行中ノート。

Home DashboardはVault全体の目次ではなく、「今日どこから手をつけるか」を決める画面にする。

効くのは「未処理が見える」ことだった

Dashboard方式の利点はいくつも挙げられるが、実際に効いたのは一つだった。処理されていないノートが見えるようになったことだ。

ノートが増えること自体は問題ではない。増えたノートのうち、手をつけていないものが分からなくなることが問題だ。フォルダの一覧では、処理済みと未処理が同じ見た目で並ぶ。

Basesを使うと、空欄のプロパティや未処理の状態をそのまま作業リストにできる。「statusが空欄」「要約がない」「next_useが未設定」を拾うビューを作れば、抜けは自動的に集まる。

プロパティの空欄は、異常ではなく処理対象だ。そう扱えるようになったことが、フォルダ管理との一番大きな違いだった。

気をつけたいこと

Dashboardを作りすぎない。 細かなテーマごとにBaseとDashboardを作ると、今度はDashboardを探すことになる。同じプロパティと処理フローを使うノートは、一つのBaseにまとめる。

プロパティ入力を目的にしない。 管理項目を増やしすぎると、ノートを書くよりプロパティを埋める時間の方が長くなる。一覧で使わない項目は作らず、欲しいビューから逆算して決める。

いきなりファイルを移動しない。 既存ノートを一斉に移す必要はない。まずは今のフォルダ構成を維持したままBaseを重ねる。フォルダが本当に不要だと分かってから整理すればよい。

小さく始めるなら

Vault全体をDashboard化する必要はない。

  1. ノート数が多く、困っている分野を一つ選ぶ

  2. その分野で知りたい状態を3つ決める

  3. 必要最低限のプロパティを追加する

  4. Baseに3つのビューを作る

  5. MarkdownのDashboardへビューを埋め込む

  6. 週に一度開いて、実際に処理する

Clippingsなら、最初は「要処理」「記事化候補」「保管のみ」の3ビューでよい。

豪華なDashboardを完成させることではなく、開くと次の行動が決まる状態を作ることが目的だ。

まとめ

役割を分けると、こうなる。

  • フォルダは保管場所

  • プロパティは状態と分類

  • Basesは検索・抽出・集計

  • Dashboardは次に見るもの、やることの入口

フォルダを捨てる必要はない。フォルダだけに、分類・状態管理・作業管理のすべてを背負わせないようにする。

ノートが少ないうちは、きれいに保存できれば十分だ。しかしノートが増えた後に必要なのは、保存場所の一覧ではなく、今の自分に必要な情報を取り出して次の行動へつなげる画面だ。

Dashboard方式は、Obsidianを「ノートを保管する場所」から「情報を動かす作業場」へ変える方法だ。

関連記事

Obsidianは「保管庫」ではなく「変換装置」として使う
https://note.com/hainote/n/nd7abca25da89

Obsidianの運用方法
https://note.com/hainote/n/n057f2a761272

いいなと思ったら応援しよう！

ハイノ おもしろい、役立つと思いましたら応援よろしくお願いします！！