目次 †

↑

Obsidianは「メモ帳」ではなく「圧縮帳」である †

↑

はじめに †

Obsidianはしばしば「メモ帳」「ナレッジベース」「第二の脳」と表現される。しかし、設計書や技術文書を扱っていると、これらの表現には違和感が残る。

自分の感覚では、Obsidianは「書き溜める場所」ではない。 むしろ、文章を圧縮し、分解し、再利用可能な形に整えるための帳面に近い。

本記事では、Obsidianを「圧縮帳」と捉える視点と、なぜ設計書において特にこの使い方が有効なのかを整理する。

↑

問題意識：AIは文章を生成しっぱなしで圧縮しない †

生成AIは非常に便利だが、現状は「文章を増やす方向」に強く偏っている。

その結果、文章は読みやすいようでいて、責務が混ざり合った塊になりがちである。

これはコードで言えば、

に相当する状態だ。

↑

設計書とコードは同型であるべき †

設計書の最終的な成果物は「コード」である。 そしてコードは、クラスやモジュールといった役割を持った部品の組み合わせとして表現される。

にもかかわらず、設計書だけが

という未圧縮状態のままだと、次の工程で歪みが生じる。

設計書が未圧縮だと、コードを書く段階で誰かが「圧縮」することになる。 これはバグや認識ズレの温床になる。

↑

文章にもSRP（単一責務原則）を適用する †

ここで重要になるのが、文章のSRP（単一責務原則）という考え方である。

これはコード設計では当たり前の感覚だが、自然言語ではあまり意識されてこなかった。

↑

Obsidianのリンクは「文章のクラス化」 †

Obsidianのリンクは、単なる関連付けではない。

文章中で、

それは「この部分は独立した責務を持ち始めている」という合図である。

その内容を丸ごとリンク先ノートに移し、元の文章にはリンクだけを残す。

これは、

という行為と本質的に同じである。

↑

知識の直積を防ぎ、圧縮する †

文章をインラインで書き続けると、知識は直積的に増殖する。

これをObsidianのリンクによって分解すると、

という形に分離できる。

結果として、情報量は減るが、意味量は減らない。 これは可逆圧縮に近い。

↑

なぜ利用者は不便を感じにくいのか †

文章を強く圧縮すると、通常は「読みにくさ」が問題になる。

しかしObsidianでは、

つまり、展開コストが極端に低い。

これはIDEで

体験とよく似ている。

↑

Obsidianは自然言語のIDEである †

プログラマーは長年、IDEを通して次の知恵を身につけてきた。

Obsidianは、この設計思想を自然言語の世界に持ち込んだツールだと考えられる。

つまり、

ノートクラス
リンク参照
グラフ構造図
AIリファクタリング補助

という対応関係が成立する。

↑

まとめ †

Obsidianは、メモを溜める場所ではない。

そのための「圧縮帳」である。

生成AIと組み合わせることで、

という分業が可能になる。

トップ   新規 一覧 単語検索 最終更新   ヘルプ   最終更新のRSS