社会人のためのObsidian：実践的なVault構成とワークフロー

Posted at 2026-04-30

この記事はプラグインや派手な機能の話ではない。ノートの整理方法について述べる——ほとんどのObsidianガイドが見落としているテーマだ。

筆者はObsidianを、仕事のメモ管理（複数プロジェクト同時進行・日本語クライアント対応）、学習、パーソナルナレッジベース、日記と幅広く活用している。試行錯誤を繰り返した末に辿り着いた、最も安定した構成を紹介する。

なぜ構成が必要か

Obsidianには決まった構成がない——ファイルを散らかしたまま使うこともできるし、細かく整理することもできる。どちらも同じ問題に行き着く：3ヶ月後に何も見つからなくなる。

良い構成とは、一つの問いに答えられるものだ：「このノートはどこに置くべきか」——そして答えは、考えなくてもわかるくらい明確である必要がある。

フォルダ構成：PARA + Journal

My Vault/
  ├── 00 Inbox/
  ├── 01 Projects/
  ├── 02 Areas/
  ├── 03 Resources/
  ├── 04 Journal/
  ├── 99 Archives/
  └── _Templates/

番号を付けることで、Obsidianがアルファベット順に並び替えてもフォルダの順序が固定される。

00 Inbox — まず記録、後で整理

新しいアイデアや情報はすべてここに入れる。フォーマット不要、タグも不要。目標は30秒以内に書き留めることだ。

InboxはストレージではなくバッファだIndex——ノートを7日以上ここに置くべきではない。

01 Projects — 締め切りが明確なもの

プロジェクトごとにサブフォルダを作る。プロジェクトとは、具体的な目標と終わりがあるものだ——「スケジュール予約機能の開発」「Q2クライアント向けピッチデッキ作成」など。

01 Projects/
  └── Golf Storage/
        ├── _INDEX.md
        ├── Meetings/
        └── Docs/

各プロジェクトには必ず_INDEX.mdを作成する——関連するすべてのファイルにリンクする中心ファイルだ。

02 Areas — 継続的な責任、終わりのないもの

ここが最も混同されやすいポイントだ。Areasに締め切りはない——キャリア管理や個人の財務管理が「完了」することはないのと同じである。

例：Career/、Finance/、Health/、Writing/。

03 Resources — 参照用ナレッジ

特定のプロジェクトや時間軸に紐づかない、テーマ別の知識を置く場所だ。Evergreenノート——自分の言葉で書き直した、いつでも参照できるメモ——はここに保存する。

03 Resources/
  ├── Tech/
  ├── Business/
  └── Personal Dev/

04 Journal — Daily・Weekly・Retro

3つの時間軸、3つの目的がある：

Daily — 今日のTop 3タスク、ブロッカーの簡易ログ
Weekly — Inboxの整理、プロジェクト進捗確認、来週のフォーカス設定
Monthly/Quarterly — 深い振り返り、方向性の調整

99 Archives — 保存するが削除しない

プロジェクトが完了したり、ノートがアクティブでなくなった場合はここに移動する。削除は行わない——後で参照が必要になる場面が必ず来る。

併用するタグシステム

フォルダは保存場所の問題を解決する。タグはクロスリファレンスの問題を解決する——フォルダの境界を越えた横断検索のためのものだ。

#project/active      #project/pending
#area/career         #area/finance
#type/evergreen      #type/fleeting
#status/draft        #status/published
#client/jp           #tech/aws
#lang/ja             #lang/vi

タグの命名原則として、必ずnamespace（#type/、#status/など）を使う。タグの重複や後々の管理コストを防ぐためだ。

Indexファイル — 地図であって、領土ではない

_INDEX.mdは各フォルダで最も重要なファイルだ。核心原則はリンクするだけ、内容はコピーしないこと。

Indexに長い内容を書き始めた場合、それは別ファイルに切り出してリンクすべきサインである。

Project Indexの例：

---
tags: [project/active, client/jp]
deadline: 2026-05-15
status: in-progress
---

# Golf Storage — Index

## Status: 🟡 In Progress (60%)

## Active tasks
- [ ] スケジュール予約機能 → [[Feature Booking]]
- [ ] Confluenceのspec更新
- [x] キックオフMTG ✅

## Meetings
- [[2026-04-30 渡辺さんMTG]]

## Docs
- [[Spec v2]] · [[DB Schema]] · [[API Design]]

## Key decisions
- 2026-04-28: WebSocketではなくFCMを採用

Area Indexはよりシンプルでよい——方向性とリンク一覧だけで十分だ：

# Career — Index

## 方向性
BrSE → 2年以内にTech Lead

## Notes
- [[スキルマップ 2026]]
- [[資格ロードマップ]]
- [[読むべき本リスト]]

Indexを常に最新の状態に保つためのルールは一つだ：新しいファイルを作成したら、即座にIndexを更新する。10秒の作業だが、Indexの正確さを長期的に維持できる。

ファイル命名規則

「正しい」よりも**「一貫している」**ことの方が重要だ。一つの規則を決め、それを守り続ける：

種類	フォーマット	例
プロジェクトノート	`YYYY-MM-DD Topic.md`	`2026-04-30 Feature Booking.md`
日次ジャーナル	`YYYY-MM-DD.md`	`2026-04-30.md`
週次ジャーナル	`YYYY-WW.md`	`2026-W18.md`
Resources	`Topic — Subtopic.md`	`Kotlin — Push Notification Pattern.md`

Resourcesには日付を付けない。Evergreenの知識は特定の時間に紐づかないためだ。

記事・ドキュメントの配置先

問うべきは*「何について書いたか」ではなく、「誰のためのもので、どんなライフサイクルを持つか」*だ。

種類	配置先
ブログ / 公開記事	`02 Areas / Writing /`
社内ドキュメント / wikiページ	`01 Projects / [Project] / Docs /`
個人的な下書き、方向性未定	`00 Inbox` → 週次triage
繰り返し使うテンプレート	`_Templates/`

ブログはAreasに分類する。「書くこと」は長期的に継続する活動であり、「完了」が存在しないからだ。推奨構成は以下の通り：

02 Areas / Writing /
  ├── _INDEX.md
  ├── published/
  ├── drafts/
  └── ideas/
      └── ideas-backlog.md

典型的なワークフロー

以下は理論ではなく、実際の作業サイクルだ。

毎日：Capture → Work

朝： Daily noteを開き（Cmd+Shift+D）、今日のTop 3タスクを記入する。日中に新しい情報が入った場合——メール、Slack、MTGいずれも——00 Inboxにノートを即座に作成する。

作業中： すべての情報はプロジェクトの_INDEX.mdからリンクする。ノートをあちこちに作らない——プロジェクトフォルダ内に作成し、即座にIndexにリンクする。

毎週：Review — 金曜日の15分

Weekly noteを開き、以下のチェックリストを実行する：

Inboxのtriage — 各ノートの判断：Projects/Areas/Resourcesへの移動、または削除
プロジェクト確認 — statusの更新、ブロッカーの早期検出
今週の3つのハイライトを記録 — 報告のためではなく、振り返りのために
来週のTop 3フォーカスを設定

Weekly Reviewは「外部記憶装置」として機能する。1ヶ月継続すると、時間が実際にどこに使われているかのパターンが明確になる。

プロジェクト完了時：蒸留 → Archive

見落とされがちなステップだが、長期的な価値が最も高い作業だ。

Archiveする前に、プロジェクトから得た技術的知識を03 ResourcesのEvergreenノートとして「蒸留」する。push notification機能の実装後の例：

# Pattern: FCM + Lambda によるPush通知

Golf Storageプロジェクトから抽出。

## 課題
スタッフが予約時にリアルタイム通知を受け取る必要がある。

## 解決策
API Gateway → Lambda → SNS → FCM

## 注意点
- アプリを開かないと1ヶ月でFCMトークンが期限切れになる
- SNS publishにはLambdaタイムアウトを最低10sに設定する必要がある

このノートはプロジェクトから独立しており、以後のプロジェクトでも再利用できる。

完了後の手順：_INDEXのstatusを「Completed」に更新 → Weekly noteに簡易retroを記入 → フォルダを99 Archives / Projects / 2026 /へ移動。

Templaterテンプレート

Community PluginsからTemplaterをインストールし、Template folder locationを_Templatesに設定する。

Daily Note（_Templates/Daily Note.md）：

---
tags: [journal/daily]
date: <% tp.date.now("YYYY-MM-DD") %>
week: <% tp.date.now("[W]WW") %>
---

# <% tp.date.now("YYYY-MM-DD · ddd") %>

## 今日のTop 3
- [ ] 
- [ ] 
- [ ] 

## ログ
- 

## ブロッカー / 確認事項
- 

## 明日やること
- 

---
← [[<% tp.date.now("YYYY-MM-DD", -1) %>]] · [[<% tp.date.now("[W]WW") %>]] · [[<% tp.date.now("YYYY-MM-DD", 1) %>]] →

Weekly Review（_Templates/Weekly Review.md）：

---
tags: [journal/weekly]
week: <% tp.date.now("[W]WW") %>
---

# Weekly Review — <% tp.date.now("[W]WW") %>

## Inboxのtriage
- [ ] Inboxを空にした

## プロジェクト確認
| プロジェクト | Status | メモ |
|------------|--------|------|
|  | 🟢 On track | |
|  | 🟡 At risk | |

## 今週の3つのハイライト
1. 
2. 
3. 

## 来週のTop 3フォーカス
- [ ] 
- [ ] 
- [ ] 

---
← [[<% tp.date.now("[W]WW", -7, "YYYY-MM-DD", 1) %>]]

Settings → Daily NotesでTemplate fileを_Templates/Daily Note.mdに、New file locationを04 Journal/Daily/に設定する。リボンのカレンダーアイコンをクリックすれば、今日の日付のファイルがテンプレート付きで自動生成される。

まとめ

3つの基本サイクルに集約される：

毎日 — 情報が来たら即座にInboxへCapture、プロジェクトフォルダ内で作業
毎週 — Inboxのtriage、プロジェクト確認、フォーカス設定（15分）
プロジェクト完了時 — 知識をResourcesへ蒸留してからArchive

構成に価値があるのは、実際に使われる場合に限られる。まずシンプルに始めることを推奨する——InboxとProjectsとJournalだけで十分だ。必要性を感じた段階でAreasとResourcesを追加すればよい。

本記事が参考になった場合、次回はDataviewプラグインを用いたタグ別クエリとObsidian内の自動ダッシュボード構築について解説する予定だ。

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up