Info
このノートは、サンプルデータとしてYAMLタイトルに「[D=]」を含めている。
Draft状態を維持してよいノートを一目で判別する表記ルール
ObsidianでZettelkastenを整理しているとき、すべてのDraftノートをPermanent化・清書・公開まで進める必要はない。
中には、
Draftではあるが、現時点ではその状態のまま維持するのが正しい
と判断できるノートがある。
この「未完成だから放置されているDraft」と「意図的にDraftのまま維持してよいノート」を、Obsidian上で一目で区別できるようにする方法を検討した。
問題
既存の draft: true はQuartz上の公開制御として使っている。
つまり、
draft: true= Quartz上で非公開draft: false= Quartz上で公開
という意味であり、
このノートはDraftのままでよい
という知識管理上の判断までは表していない。
そのため、別の視覚的なマーカーが必要になった。
特に重要だった要件は、次の両方を満たすことだった。
- Structure NoteやInbox系ノートなど、複数ノートへのリンクを一覧している状態でも判別できる
- 該当ノートそのものを開いたときにも、そのノートが「Draft維持でよい」と分かる
最初に検討したYAMLによる状態管理
当初は、
draft: true
draft_status: stableあるいは、
status: parkedのように、YAMLへ状態を追加する案を検討した。
これはデータ構造としては整理されているが、問題がある。
YAMLだけに状態を書いた場合、ノートを開いてYAMLを確認しない限り分からない。
Structure NoteやInboxなどからノート一覧を見ている段階で、
このノートはもうDraftのまま触らなくてよい
という判断ができない。
そのため、この案は今回の目的には適さなかった。
Structure Note側だけに記号を付ける案
次に、Structure Noteなどのリンク側へ、
- ◌ [ノートA](note-a.md)
- [ノートB](note-b.md)
- ◌ [ノートC](note-c.md)のような記号を付ける案を検討した。
これなら一覧上では非常に分かりやすい。
しかし今度は逆に、
該当ノートを単体で開いたときに、自分が「Draft維持でよい」と判断したノートなのか分からない
という問題が発生する。
つまり、Structure Note側だけに情報を持たせると状態管理が分散する。
この案も不十分だった。
ファイル名に状態を入れる案
一覧からも単体ノートからも見えるようにするため、一時は、
note-name [D].mdのようにファイル名へ状態を含める案も検討した。
しかし、実際の運用ではObsidianおよびQuartz上の表示タイトルはYAMLの title で制御しており、実ファイル名は変更しない方針である。
したがって、ファイル名そのものへ状態を埋め込む必要はなかった。
状態マーカーはYAML title に付ければよい。
D だけでは意味が足りない
Draftを表すだけなら、
[D]でよい。
しかし今回伝えたい意味は、
Draftである
ではなく、
Draftのままでいることが正しい
である。
単なる [D] では、
- 未整理のDraft
- 作業途中のDraft
- 後で清書すべきDraft
- 現状維持でよいDraft
を区別できない。
そのため、Draftであることに加えて「状態維持」の意味を含める必要があった。
レ点 ✓ を使わなかった理由
候補として、
[D✓]も検討した。
これは、
DraftでOK
という意味を直感的に表現できる。
しかし ✓ は一般に、
- 確認済み
- チェック済み
- 完了済み
という意味合いが強い。
今回表したいのは「確認した」という事実ではなく、
この状態を維持する
という判断である。
そのため、レ点は意味が少しずれると判断した。
🔏を使う案
次に、
[D🔏]という案を検討した。
Draft状態をロックして保持しているように見えるため、「そのまま維持」という意味は分かりやすい。
一方で、
- 編集禁止
- 変更禁止
- 固定済み
というニュアンスも生じる。
実際にはDraft維持と判断したノートでも、将来必要になれば編集してよい。
そのため、「ロック」という意味はやや強すぎる。
[D=] を採用
最終的に、
[D=]を採用する方向になった。
意味は、
D= Draft== 現状維持 / keep as-is[]= 状態ラベル
とする。
つまり、
Draft状態を維持する
という意味を短い記号で表す。
[D=] は独自記法ではあるが、一度意味を決めてしまえば視認性が高い。
✓ のような「確認済み」、🔒 のような「編集禁止」という別の意味も比較的生じにくい。
大文字 D を採用する理由
D と d では、大文字の D を使う。
[D=]とする。
理由は、これは本文中の文字ではなく状態コードとして使うため。
大文字の方が、
- 一覧上で目立つ
- 状態記号として認識しやすい
Draftの略であることも分かりやすい
という利点がある。
PrefixとSuffixの比較
当初は、
タイトル [D=]というSuffixも考えた。
しかし、今回もっとも重要なのは、
Structure NoteやInboxなどで大量のノートを一覧しているときに、一目で判別できること
である。
そのため、最終的にはPrefixの方が適している。
[D=] AIエージェントの役割分担
[D=] ZettelkastenとAI
Claude Codeの運用
[D=] ローカルLLMの検討この形式なら左端だけを追えば状態を確認できる。
Suffixの場合、
AIエージェントの役割分担 [D=]
ZettelkastenとAI [D=]
Claude Codeの運用
ローカルLLMの検討 [D=]となり、タイトルの長さによって [D=] の位置がばらつく。
一覧性ではPrefixの方が優れている。
実ファイル名は変更しない
状態マーカーはファイル名ではなく、YAML title に付与する。
例えば、
title: "[D=] AIエージェントの役割分担"
aliases:
- "[D=] AIエージェントの役割分担"
draft: true実ファイル名は従来どおり、
ai-agent-role-separation.mdなどの英語slugを維持する。
これにより、
- 実ファイル名は安定する
- URLやslugを状態変更のたびに変更しなくてよい
- Obsidian上では状態付きタイトルを確認できる
- Structure / Index / Inboxなどのリンク表示にも状態を反映できる
- ノート単体を開いても状態を確認できる
という運用が可能になる。
aliases には title と完全に同じ値を含める既存ルールがあるため、title に [D=] を追加した場合は aliases 側にも同じ表記を反映する。
[D=] の定義
[D=] は次の意味として扱う。
Draft Keep / Draft維持
Draft状態を意図的に維持するノート。
現時点では公開化・清書・Permanent化・統合・追加整理などを積極的に行う必要がない。
将来の編集を禁止するものではない。
重要なのは、
draft: trueと、
[D=]は別の情報だという点である。
| 表示 | 意味 |
|---|---|
draft: true | Quartz上で非公開 |
[D=] | Draft状態のまま維持してよいという知識管理上の判断 |
したがって、[D=] は公開・非公開制御ではなく、人間がノート整理を行う際の判断補助マーカーである。
対話から分かった設計上のポイント
今回の検討では、「情報として正しく管理できるか」だけでは不十分だった。
最初のYAML案では状態自体は正確に保存できるが、一覧から見えない。
Structure Note側だけに記号を付ける案では一覧性は高いが、単体ノートから状態が分からない。
ファイル名変更は両方を満たせるが、既存の title とslugを分離する運用では不要だった。
最終的に、
既存の表示名であるYAML
titleに状態を含める
ことで、
- 一覧性
- 単体ノートでの判別
- ファイル名の安定
- Quartzとの整合
を同時に満たせることが分かった。
さらに、「Draft」という状態だけでなく、
Draftであることを意図的に維持する
という判断を表現するため、単純な [D] ではなく [D=] を使用する。
決定
- Draftのまま維持してよいノートには
[D=]を付ける。 Dは大文字を使用する。=は「現状維持 / keep as-is」を意味する。- 表記位置はPrefixとする。
- 形式は次のとおり。
[D=] ノートタイトル- 実ファイル名は変更しない。
- YAML
titleに[D=]を含める。 aliasesにもtitleと同値の表記を維持する。draft: trueはQuartz上の公開制御として従来どおり使用する。[D=]は「Draftのままでよい」という人間側の判断を示す。[D=]は編集禁止を意味しない。
今回の不満から得られた判断基準
状態管理を考えるとき、「データとして記録されているか」だけで判断してはいけない。
今回必要だったのは、
その情報を必要とする場面で、一目で確認できること
だった。
そのため、今後もノート状態を示す仕組みを追加するときは、
- 一覧から見えるか
- 単体ノートから見えるか
- 状態変更のたびにファイル名やリンクを壊さないか
- 既存のYAMLやQuartz運用と役割が重複しないか
- 記号そのものから誤った意味を連想しないか
を確認する。
特にZettelkastenでは、内部的に正しいだけでなく、整理・見直し時の認知コストが低いことも重要な設計条件になる。