Obsidianは「メモ帳」ではなく「圧縮帳」である
をテンプレートにして作成
[
トップ
] [
新規
|
一覧
|
単語検索
|
最終更新
|
ヘルプ
]
開始行:
* 目次 [#pa1c4fb4]
#contents
* Obsidianは「メモ帳」ではなく「圧縮帳」である [#main]
** はじめに [#introduction]
Obsidianはしばしば「メモ帳」「ナレッジベース」「第二の脳...
自分の感覚では、Obsidianは「書き溜める場所」ではない。
むしろ、''文章を圧縮し、分解し、再利用可能な形に整えるた...
本記事では、Obsidianを「圧縮帳」と捉える視点と、なぜ設計...
** 問題意識：AIは文章を生成しっぱなしで圧縮しない [#probl...
生成AIは非常に便利だが、現状は「文章を増やす方向」に強く...
- 丁寧に説明する
- 前提をすべて書く
- 補足を重ねる
その結果、文章は読みやすいようでいて、''責務が混ざり合っ...
これはコードで言えば、
- God Class
- SRP違反
- 責務の混在
に相当する状態だ。
** 設計書とコードは同型であるべき [#isomorphism]
設計書の最終的な成果物は「コード」である。
そしてコードは、クラスやモジュールといった''役割を持った...
にもかかわらず、設計書だけが
- 長文の説明
- 時系列の文章
- 前提と本題の混在
という未圧縮状態のままだと、次の工程で歪みが生じる。
設計書が未圧縮だと、コードを書く段階で誰かが「圧縮」する...
これはバグや認識ズレの温床になる。
** 文章にもSRP（単一責務原則）を適用する [#srp]
ここで重要になるのが、''文章のSRP（単一責務原則）''という...
- 1つの文章は、1つの責務だけを持つ
- 説明が増え始めたら、責務が肥大化しているサイン
- 肥大化した部分は、別の単位に切り出す
これはコード設計では当たり前の感覚だが、自然言語ではあま...
** Obsidianのリンクは「文章のクラス化」 [#link-as-class]
Obsidianのリンクは、単なる関連付けではない。
文章中で、
- 用語の説明が始まったとき
- 前提条件を詳しく書きたくなったとき
- 概念を一般化したくなったとき
それは「この部分は独立した責務を持ち始めている」という合...
その内容を丸ごとリンク先ノートに移し、元の文章にはリンク...
これは、
- クラスを外だしする
- 実装詳細を隠蔽する
- 名前で意味を圧縮する
という行為と本質的に同じである。
** 知識の直積を防ぎ、圧縮する [#compression]
文章をインラインで書き続けると、知識は直積的に増殖する。
- 本題 × 用語説明
- 本題 × 前提条件
- 本題 × 補足知識
これをObsidianのリンクによって分解すると、
- 本題（圧縮）
- 用語定義（別ノート）
- 前提条件（別ノート）
という形に分離できる。
結果として、''情報量は減るが、意味量は減らない''。
これは可逆圧縮に近い。
** なぜ利用者は不便を感じにくいのか [#usability]
文章を強く圧縮すると、通常は「読みにくさ」が問題になる。
しかしObsidianでは、
- クリック一つで展開できる
- ホバーで中身を確認できる
- バックリンクですぐ戻れる
つまり、''展開コストが極端に低い''。
これはIDEで
- クラス定義にジャンプする
- 実装を必要なときだけ読む
体験とよく似ている。
** Obsidianは自然言語のIDEである [#ide-for-natural-langua...
プログラマーは長年、IDEを通して次の知恵を身につけてきた。
- 分割する
- 名前を付ける
- 圧縮する
- 必要なときだけ展開する
Obsidianは、この設計思想を''自然言語の世界に持ち込んだツ...
つまり、
|ノート|クラス|
|リンク|参照|
|グラフ|構造図|
|AI|リファクタリング補助|
という対応関係が成立する。
** まとめ [#summary]
Obsidianは、メモを溜める場所ではない。
- 思考を圧縮する
- 設計を正規化する
- コードと同型な構造を作る
そのための「圧縮帳」である。
生成AIと組み合わせることで、
- 人間は考える（圧縮の判断）
- AIは展開する（生成・補足）
という分業が可能になる。
ーーーーーーーーーーーーー
* 圧縮処理システムの設計 [#compression-system]
** 基本的な考え方 [#basic-concept]
- Obsidianを「ドキュメント指向DB」として扱う
- 文章の圧縮 = 概念の外出し + リンク化
- 構造化により、AIのコンテキスト消費を最小化
** フォルダ構造案 [#folder-structure]
vault/
├── 00_inbox/ # 圧縮前の生ドキュメント
├── 10_concepts/ # 用語・概念（クラス相当）
├── 20_docs/ # 圧縮済みドキュメント
└── 90_archive/ # オリジナル保存
** 人間とエージェントの役割分担 [#role-division]
|処理|担当|h
|ファイル投入・承認|人間|
|パターン検出・置換|エージェント|
|概念の粒度・命名判断|人間|
** TBD/TODO管理 [#tbd-management]
*** 方針 [#tbd-policy]
複雑な独自システムは作らない。既存ツールを活用する。
- TBD/TODOの管理 → '''Forgejo Issue'''（#番号で参照）
- 未管理TBDの検出 → '''grep'''
- 会議アジェンダ → Issueのマイルストーン機能
*** 運用フロー [#tbd-flow]
1. 未管理TBD検出
grep -rn "%%TBD%%" docs/ | grep -v "TBD-#"
2. Issue登録（Forgejo）
→ #123 が発行される
3. ファイル更新
%%TBD%% → %%TBD-#123%%
4. 会議でIssueを確認・決定
5. コード/設計書を更新、PR作成
Fixes #123 でコミット
6. マージ → Issue自動クローズ
** コンテキスト効率 [#context-efficiency]
|方式|消費トークン|h
|全文読み込み|26,000|
|構造化（ピンポイント）|500|
構造化により、AIの'''継戦能力'''が向上する。
*** 効率化のポイント [#efficiency-points]
- grepで位置特定 → AIは該当箇所のみ読む
- Issue番号で参照 → 全文検索不要
- 概念のリンク化 → 重複説明を排除
** まとめ [#summary]
- 複雑なシステムより'''運用ルール'''
- 既存ツール（Forgejo Issue、grep）を活用
- AIには最小限のコンテキストを渡す
終了行:
* 目次 [#pa1c4fb4]
#contents
* Obsidianは「メモ帳」ではなく「圧縮帳」である [#main]
** はじめに [#introduction]
Obsidianはしばしば「メモ帳」「ナレッジベース」「第二の脳...
自分の感覚では、Obsidianは「書き溜める場所」ではない。
むしろ、''文章を圧縮し、分解し、再利用可能な形に整えるた...
本記事では、Obsidianを「圧縮帳」と捉える視点と、なぜ設計...
** 問題意識：AIは文章を生成しっぱなしで圧縮しない [#probl...
生成AIは非常に便利だが、現状は「文章を増やす方向」に強く...
- 丁寧に説明する
- 前提をすべて書く
- 補足を重ねる
その結果、文章は読みやすいようでいて、''責務が混ざり合っ...
これはコードで言えば、
- God Class
- SRP違反
- 責務の混在
に相当する状態だ。
** 設計書とコードは同型であるべき [#isomorphism]
設計書の最終的な成果物は「コード」である。
そしてコードは、クラスやモジュールといった''役割を持った...
にもかかわらず、設計書だけが
- 長文の説明
- 時系列の文章
- 前提と本題の混在
という未圧縮状態のままだと、次の工程で歪みが生じる。
設計書が未圧縮だと、コードを書く段階で誰かが「圧縮」する...
これはバグや認識ズレの温床になる。
** 文章にもSRP（単一責務原則）を適用する [#srp]
ここで重要になるのが、''文章のSRP（単一責務原則）''という...
- 1つの文章は、1つの責務だけを持つ
- 説明が増え始めたら、責務が肥大化しているサイン
- 肥大化した部分は、別の単位に切り出す
これはコード設計では当たり前の感覚だが、自然言語ではあま...
** Obsidianのリンクは「文章のクラス化」 [#link-as-class]
Obsidianのリンクは、単なる関連付けではない。
文章中で、
- 用語の説明が始まったとき
- 前提条件を詳しく書きたくなったとき
- 概念を一般化したくなったとき
それは「この部分は独立した責務を持ち始めている」という合...
その内容を丸ごとリンク先ノートに移し、元の文章にはリンク...
これは、
- クラスを外だしする
- 実装詳細を隠蔽する
- 名前で意味を圧縮する
という行為と本質的に同じである。
** 知識の直積を防ぎ、圧縮する [#compression]
文章をインラインで書き続けると、知識は直積的に増殖する。
- 本題 × 用語説明
- 本題 × 前提条件
- 本題 × 補足知識
これをObsidianのリンクによって分解すると、
- 本題（圧縮）
- 用語定義（別ノート）
- 前提条件（別ノート）
という形に分離できる。
結果として、''情報量は減るが、意味量は減らない''。
これは可逆圧縮に近い。
** なぜ利用者は不便を感じにくいのか [#usability]
文章を強く圧縮すると、通常は「読みにくさ」が問題になる。
しかしObsidianでは、
- クリック一つで展開できる
- ホバーで中身を確認できる
- バックリンクですぐ戻れる
つまり、''展開コストが極端に低い''。
これはIDEで
- クラス定義にジャンプする
- 実装を必要なときだけ読む
体験とよく似ている。
** Obsidianは自然言語のIDEである [#ide-for-natural-langua...
プログラマーは長年、IDEを通して次の知恵を身につけてきた。
- 分割する
- 名前を付ける
- 圧縮する
- 必要なときだけ展開する
Obsidianは、この設計思想を''自然言語の世界に持ち込んだツ...
つまり、
|ノート|クラス|
|リンク|参照|
|グラフ|構造図|
|AI|リファクタリング補助|
という対応関係が成立する。
** まとめ [#summary]
Obsidianは、メモを溜める場所ではない。
- 思考を圧縮する
- 設計を正規化する
- コードと同型な構造を作る
そのための「圧縮帳」である。
生成AIと組み合わせることで、
- 人間は考える（圧縮の判断）
- AIは展開する（生成・補足）
という分業が可能になる。
ーーーーーーーーーーーーー
* 圧縮処理システムの設計 [#compression-system]
** 基本的な考え方 [#basic-concept]
- Obsidianを「ドキュメント指向DB」として扱う
- 文章の圧縮 = 概念の外出し + リンク化
- 構造化により、AIのコンテキスト消費を最小化
** フォルダ構造案 [#folder-structure]
vault/
├── 00_inbox/ # 圧縮前の生ドキュメント
├── 10_concepts/ # 用語・概念（クラス相当）
├── 20_docs/ # 圧縮済みドキュメント
└── 90_archive/ # オリジナル保存
** 人間とエージェントの役割分担 [#role-division]
|処理|担当|h
|ファイル投入・承認|人間|
|パターン検出・置換|エージェント|
|概念の粒度・命名判断|人間|
** TBD/TODO管理 [#tbd-management]
*** 方針 [#tbd-policy]
複雑な独自システムは作らない。既存ツールを活用する。
- TBD/TODOの管理 → '''Forgejo Issue'''（#番号で参照）
- 未管理TBDの検出 → '''grep'''
- 会議アジェンダ → Issueのマイルストーン機能
*** 運用フロー [#tbd-flow]
1. 未管理TBD検出
grep -rn "%%TBD%%" docs/ | grep -v "TBD-#"
2. Issue登録（Forgejo）
→ #123 が発行される
3. ファイル更新
%%TBD%% → %%TBD-#123%%
4. 会議でIssueを確認・決定
5. コード/設計書を更新、PR作成
Fixes #123 でコミット
6. マージ → Issue自動クローズ
** コンテキスト効率 [#context-efficiency]
|方式|消費トークン|h
|全文読み込み|26,000|
|構造化（ピンポイント）|500|
構造化により、AIの'''継戦能力'''が向上する。
*** 効率化のポイント [#efficiency-points]
- grepで位置特定 → AIは該当箇所のみ読む
- Issue番号で参照 → 全文検索不要
- 概念のリンク化 → 重複説明を排除
** まとめ [#summary]
- 複雑なシステムより'''運用ルール'''
- 既存ツール（Forgejo Issue、grep）を活用
- AIには最小限のコンテキストを渡す
ページ名:
