ObsidianでProject管理システムを作る方法。人間用画面とSystem側データを分ける設計編

はじめに

Projectの管理をはじめは別のアプリで管理しようとしていた。実際的にタスク管理のアプリは多く試してきた。それが自分にあうというのはあまりなく、実際にはホワイトボードにカンバン形式で管理するのが非常に楽であった。

とはいえその方法であると、どうしても場所に縛られるのと、また別アプリで分けるでも良かったが、できれば管理そのものは一つにまとめたかった。

そのためObsidianで管理をすることを目標とした。ただチェックリストだとどうしても複数のは分かりにくくなる。

Projectの数が分からない
どのProjectが進行中か分からない
タスクに project_id や priority を手入力して、表記がぶれる
AIにProject状況を聞きたいが、Vault全体は読ませたくない
人間は見やすくしたいが、System側は機械処理しやすくしたい

そこで今回は、Obsidian内に「人間用Project画面」と「System側Project管理データ」を分ける設計をまとめる。

この記事は設計編である。具体的なPythonスクリプト、実行コマンド、Dashboard・Gantt・Kanbanの画面結果は、別記事の実装編で扱う。

実装編書きました。

syurainu.com

はじめに
完成イメージ
前提環境
- なぜ作ったか
- 全体構成
人間用とSystem側を分ける理由
Project Recordを正本にする
エラー修正時の指示
- 手順
実行結果
詰まったところ
- セキュリティ上の注意
Before / After
まとめ
参考文献
註

完成イメージ

目指す状態はこうである。

Before:

Projectメモが散らばる
タスクにproject_idやpriorityを手入力する
進捗確認に時間がかかる
AIに読ませる範囲が曖昧

After:

人間はProjectホームから操作する
Project RecordをSystem側の正式データにする
タスク入力欄はProject別に自動生成する
Task IndexとDashboardを自動生成する
AIには軽量なContext Packだけ渡す

この記事で扱うのは、画面の作り方ではなく、役割分担の設計である。

この記事で扱うこと	実装編で扱うこと
人間用画面とSystem側データを分ける理由	実際のフォルダ・ファイル作成
Project Recordを正本にする考え方	Pythonスクリプトの追加
タスクや日付を人間が書きやすくする方針	更新コマンドの追加
AIに渡す範囲を絞る設計	Dashboard、Gantt、Kanbanの生成結果

全体像は次のようになる。

flowchart TD
    A["人間が考える領域"] --> B["Project候補・タスク・日付"]
    B --> C["System側の正本"]
    C --> D["検索・集計用Index"]
    D --> E["人間が読む生成ビュー"]
    D --> F["AIに渡すContext Pack"]
    G["AIが直接読まない領域"] -. "Vault全体・秘密情報・raw素材" .-> F

前提環境

項目	内容
OS	Windows
シェル	PowerShell
AIツール	Codex
ローカルLLM	Ollamaを使う想定。ただし設計自体には不要
関連ツール	Obsidian、Python、Dataview、Mermaid
対象サービス	Obsidian Vault
実行場所	PowerShell、Obsidian、Codex

ObsidianのPropertiesはMarkdownファイル先頭のYAMLとして保存される。Obsidian公式ヘルプでも、PropertiesはYAML形式でファイル上部に保存され、人間にも機械にも読みやすい形式として扱えることが説明されている¹。

なぜ作ったか

Project管理で一番避けたいのは、決まっている情報を人間が毎回手入力することである。

たとえば、タスクに次のような情報を付ける方式にするとする。

- [ ] 課題の提出期限を確認する [project_id:: 001] [priority:: high]

これは一見便利だが、長く運用すると表記がぶれる。

[project_id:: 1]
[project:: 大学課題]
[priority:: 高]
[Priority:: high]

人間が毎回きれいに書く前提にすると、Project管理は壊れやすい。

そこで、人間が書くのはタスク本文だけにし、Project ID、Priority、Tier、StatusはSystem側から自動付与する方針にした。

全体構成

Vault内の構成は、次のように分ける。

<VAULT_PATH>/
├─ 00_人間用/
│  └─ Project/
│     ├─ README.md
│     ├─ 01_Project検討欄.md
│     ├─ 02_タスク入力欄.md
│     ├─ 03_Projectソートビュー.md
│     └─ 04_Gantt日付入力欄.md
│
└─ 90_System/
   ├─ projects/
   │  ├─ records/
   │  ├─ registry/
   │  ├─ indexes/
   │  └─ logs/
   │
   └─ scripts/

役割は次の通りである。

場所	役割
`00_人間用/Project/`	人間が見る、考える、入力する場所
`90_System/projects/records/`	Projectの正式データ
`90_System/projects/registry/`	Project IDの台帳
`90_System/projects/indexes/`	Dashboard、Task Index、Gantt、Kanbanなどの生成物
`90_System/scripts/`	生成処理

DataviewはObsidian内のメタデータを問い合わせるためのプラグインであり、Markdown内のメタデータを一覧・集計する用途に向いている²。ただし、この設計ではAIに渡す正式入力はDataviewの表示結果ではなく、Pythonで生成したIndexにする。

人間用とSystem側を分ける理由

人間用画面には、分かりやすさが必要である。

たとえば、Projectホームには次のようなページを置く。

00_人間用/Project/
├─ README.md
├─ 01_Project検討欄.md
├─ 02_タスク入力欄.md
├─ 03_Projectソートビュー.md
└─ 04_Gantt日付入力欄.md

一方で、System側には機械処理しやすいデータを置く。

90_System/projects/
├─ records/
├─ registry/
├─ indexes/
└─ logs/

この分離をしておくと、人間は見やすい場所で作業し、AIやPythonは決まった場所だけを読むことができる。

Project Recordを正本にする

正式なProject状態は、Project Recordに置く。

90_System/projects/records/001_university-assignment.md

frontmatterには、Project ID、状態、優先度、Tierなどを書く。

---
type: project_record
project_id: "001"
title: 大学の課題作成
status: active
phase: planning
priority: high
tier: Tier 1
progress: 0
progress_source: task_count
created: 2026-06-17
updated: 2026-06-18
---

このRecordを正本にすれば、後からどのような表示やIndexを作っても、情報源が分散しにくい。

タスク入力欄は人間用にする

人間用のタスク入力欄では、Projectごとのブロックを自動生成する。

<!-- PROJECT_TASK:START 001 -->
### 001 大学の課題作成
<!-- project_meta: tier=Tier 1 / status=active / priority=high -->

- [ ] 課題作成
<!-- PROJECT_TASK:END 001 -->

人間が書くのは次だけでよい。

- [ ] 課題作成

所属Projectは見出しではなく、HTMLコメントのIDマーカーから判定する。これにより、Project名が変わってもタスクの所属が壊れにくい。

AIに読ませる範囲

この構成では、AIにVault全体を読ませない。

AIが読むのは、原則としてSystem側の生成物に限定する。

90_System/projects/indexes/project_index.jsonl
90_System/projects/indexes/project_task_index.jsonl
90_System/output/project_context_pack.md

人間用の生メモや、未整理のProject検討欄をAIに丸ごと渡さない。

AIには、整理済みの軽量データだけを渡す。

使ったプロンプト

今回の設計を作るときは、次のように依頼した。

Project管理をスリムにしたい。
人間用のProject把握とSystem側は分ける。
タスク入力で project_id や priority を人間が手入力しないようにする。
Project RecordからProject別タスク入力欄を自動生成する。

制約:
- 人間用フォルダとSystem側を分ける
- AIにVault全体を読ませない
- 実パスや秘密情報は記事に出さない

エラー修正時の指示

この記事は設計編なので、エラー修正プロンプトは発生していない。

実装編では、Pythonスクリプトの構文チェックや .cmd のCRLF確認について扱う。

手順

設計だけを再現するなら、次の順番で決める。

人間が直接触る場所を決める。
System側の正本を決める。
人間が手入力してよい情報と、System側で自動付与する情報を分ける。
AIに読ませる範囲を決める。
生成ビューは「編集場所」ではなく「確認場所」として扱う。
秘密情報や個人情報を書かない場所を決める。

この時点では、まだPythonを実装しなくてもよい。

先に「どこが人間用で、どこがSystem側か」を決めることが重要である。

実行結果

設計後の結論は、次の分担である。

人間が編集する:
Project候補
Project別タスク
Project日付

System側が保持する:
Project Record
Project Registry
Project Index

人間とAIが読む:
Dashboardなどの生成ビュー
Context Pack

設計編で決めるのは、ここまででよい。

具体的なスクリプト名、生成ログ、生成結果のスクリーンショットは実装編に分ける。設計編では、編集する場所と読む場所を混ぜない、という原則を先に固定する。

詰まったところ

詰まったこと	原因	対処
タスクのProject所属がぶれる	人間がIDや優先度を手入力していた	Project別入力欄を自動生成する
Gantt用の日付が入れにくい	Project Recordを直接編集する必要があった	`04_Gantt日付入力欄.md` を人間用に分ける
AIに読ませる範囲が広くなりがち	Vault全体を入力にしようとしていた	System側IndexとContext Packに限定する
人間用ページがSystem寄りになる	スクリプト目線で設計していた	`00_人間用/Project` を入口にする

セキュリティ上の注意

Project管理に何でも入れてよいわけではない。

特に次は書かない。

パスワード
APIキー
OAuthトークン
個人情報の原文
契約・仕事上の機密情報
.obsidian/plugins/*/data.json の中身
実PCのユーザー名や絶対パス

記事やAIへの入力では、実パスは次のように伏せる。

<VAULT_PATH>
<USER_HOME>
<LOCAL_PATH>
<TOKEN>
<API_KEY>

Before / After

Before:
Projectごとにメモが散らばる
タスクにproject_idやpriorityを手入力する
AIに読ませる範囲が曖昧

After:
Project Recordを正式データにする
人間はProject別入力欄にタスク本文だけを書く
日付は人間用の入力欄に分ける
System側でIndexとContext Packを生成する
AIには軽量データだけ渡す

まとめ

この記事では、ObsidianでProject管理システムを作る前に決めておくべき設計を整理した。

結論は、Project管理を「人間が考える場所」と「System側が処理する場所」に分けることである。

人間用:
Projectを見て、考えて、タスクを書く場所

System側:
Project Record、Registry、Index、Context Packを扱う場所

この分離をしておくと、人間はObsidianらしく自由に考えられる。一方で、System側はProject ID、Priority、Tier、Statusのような機械処理しやすい情報を安定して扱える。

重要なのは、人間に「決まった形式を毎回正確に書く」ことを求めないことである。タスク本文や日付のように人間が判断する部分だけを入力し、Project IDや優先度のような決まった情報はSystem側から付与する。これにより、表記ゆれを減らし、あとからDashboardやContext Packを作りやすくなる。

またAIに読ませる範囲を最初から絞れることも大きい。Vault全体をAIに渡すのではなく、System側で生成した軽量なIndexやContext Packだけを使う設計にすれば、プライバシーや安全面を守りやすい。

つまりこの設計の目的は、Obsidianを管理アプリに置き換えることではない。Obsidianの自由さを残したまま、Project管理に必要な構造だけをSystem側に持たせることである。

実装編では、この設計をもとに、実際のファイル構成、Pythonスクリプト、Dashboard、Gantt、Kanbanの生成まで進める。

参考文献

註

Obsidian公式ヘルプでは、PropertiesはYAML形式でファイル上部に保存され、値にはテキスト、数値、チェックボックス、日付、リストなどを使えると説明されている。↩
DataviewはObsidian Vault内のメタデータをIndex化し、Dataview Query Languageで一覧、フィルタ、ソート、グループ化できるプラグインである。↩