公開型ツェッテルカステンの入口となるStructure Note。知識管理の原則とQuartzによる公開環境を、個別ノートの一覧ではなく「どの順で読めば運用判断を追えるか」という導線として案内する。
flowchart TD Principles[運用原則を理解する] --> Records[個別の記録方法を判断する] Records --> Design[基本設計を理解する] Design --> Build[公開環境を構築・運用する] Build --> Review[ノートの役割と公開状態を見直す]
まず運用原則を理解する
次に、個別の記録をどのような目的で残すかを判断する。
基本設計
カードは一つの問いや主張を扱い、関係の理由が分かるリンクで接続する。アトミックであることを文章の短さと同一視せず、別の文脈でも再利用でき、再読時に思考を再開できる単位を目指す。
| 要素 | 役割 |
|---|---|
| フォルダ | 作業段階や利用場面を示す |
type | ノートの現在の知識上の役割を示す |
tags | 分野・情報源などを横断する属性を示す |
type | 意味 |
|---|---|
fleeting | 未整理の着想や一時的な問い |
literature | 外部資料の内容や、それに対する記録 |
permanent | 自分の言葉で成立する再利用可能な主張 |
structure | 複数ノートの関係や読み順を案内する構造ノート |
index | 特定の規則に基づき対象を列挙する索引 |
AI回答は自動的にLiterature Noteにしない。検証段階と保存目的からtypeを選び、AI生成の本文であることはai-generatedタグで示す。外部リンクだけを保存する場合も、接続する問い・主張・目的を残す。
公開環境と運用ルール
| 領域 | 採用するもの | 関連ノート |
|---|---|---|
| ノート作成・管理 | Obsidian | — |
| 静的サイト生成 | Quartz | — |
| リポジトリ管理 | GitHub | Gitエコシステムまとめ |
| ホスティング | Cloudflare Pages | 比較 / 主な制限 |
| ドメイン管理 | conoHa | 外部カスタムドメインの制限 |
公開・管理の設計は、次のノートから辿る。
フォルダ構成
フォルダ間の移動を機械的な必須工程にはしない。ノートの役割と今後の利用方法から保存先を判断する。
| フォルダ | 用途 |
|---|---|
01_Templates | 新規ノート用テンプレート |
02_images | 画像などの添付ファイル |
10_Analytics | 分析結果や集計 |
20_Journal | 日記、活動経過、試行錯誤 |
21_Reading | 負担の軽い読書記録 |
30_Inbox | 未整理のメモと一時的な作業領域 |
31_Research | 調査記録、資料整理、精読 |
32_Zk | Permanent Note、Structure Note、Indexを中心とする知識ネットワーク |