Info
この記事はObsidian Advent Calendar 2025の24日目の記事です。
はじめに
当ブログは、個人ブログのチラシ裏的な情報は地味に有用だという漠然とした認識を、Obsidianで書くマークダウンはそのままWebページとして公開できるはずだろうという技術的な側面が後押しして開始された。それから2年ほど経過し、本稿は当ブログの100個目の記事に当たる。ちょうど2年前くらいにObsidian初心者だったころにもアドベントカレンダーを見ていたと思うと感慨深い。
私は元来特定のツールに傾倒するタイプではない(と思っていた)のだが、Obsidianに関してはなぜだかヘビーユーザーに片足入りかけている。その理由はいろいろあるのだが、1つは｢リンクによるWikipediaっぽい管理｣が私の考えと非常によく合致していたからである。本稿ではリンクによる管理は何が優れているのか、考察していく。
フォルダやタグ管理の限界
PC内のファイルの管理で広く受け入れられている方法に、フォルダによる管理とタグによる管理がある。多くの人が当たり前のように使用している管理方法であるが、その特性について考察したことはあるだろうか。
まず、フォルダ管理は最も直感的でかつ最も絶対的な分類だ。各ファイルは階層的に住所(=ディレクトリ)が与えられて、階層そのものが分類となる。この方法の良い点は、各ファイルに絶対的な属性が与えられるのでプログラム的な区別がはっきりつく点である。一方で、一意の属性しか付与できないため、複数の要素にまたがる情報は保存しにくい。データやメモがどのフォルダに属するべきか迷った経験はないだろうか。こういう時に確実に分類できるように細かく管理するとするほど階層が奥深くなり到達が困難になってしまう。
図：フォルダ管理は階層構造で一意の属性を付与する
｢どこに置くか｣を決めるだけなので簡単だが、同時にその1か所しか居場所がないという窮屈さを生む。特に多面性のある知識の蓄積に関してはフォルダ管理は根本的に困難だと思われる。私は、プログラム的に必要である場合にのみフォルダ管理を使用している(例：このサイトに公開するファイルはPublishフォルダに入れるなど)。
次に、タグ管理は簡便かつ重複を許す管理方法である。タグはフォルダ管理の持つ絶対的な属性しか持てないという問題を一見解決しているように見える。しかしながら、タグは簡便性に振り切っており属性の重み付けは許容していない。実質的には単純にグループとして属性を収集しているだけなのである。また、あとから｢このタグつけておけばよかった｣と考えても対応は難しい。性質上、前向きかつ期間限定での情報やデータの収集に向いていると考えられる。
図：タグ管理は重複を許可した集合を作成する
タグは増やしやすいものの、重み付けや優先度の概念がなく、あと付けもしにくい。システマティックに運用することで便利に使用できるが、いつかは破綻しうることを念頭に運用したい。
この２つの手法は、デジタルデータの管理方法として広く一般的でありながらも、構造的な制約が非常に大きいことがわかる。
分類は本来多次元的である
なぜこのような制約が存在するのだろうか。問題は知識やノウハウのもつ多次元性にあると私は考えている。例えば、ここにリンゴが置いてあるとする。この時、｢何があるか｣を記録する場合は記録すべき情報は｢リンゴ｣ということになる。これが｢何色か｣を記録するのであれば｢赤色｣ということになる。更に｢私がどうやって皮を剥くか｣を記録するのであれば、｢包丁を右手に持って左手の親指を押し出しながら剥く｣ということになる。つまり、リンゴ１つとっても記録対象になりうる情報の分類は無数に存在するということになる。この分類は無限ではないが、リアルワールドにおける活動の数だけ存在しうる。
近年では大規模言語モデル(LLM)の台頭が目覚ましい。学習パラメータや学習量の増加が一定閾値を越えた時に、急激に対話的能力が向上したと言われている。そして、近年のLLMは学習パラメータがBillion(10億)単位で語られている。この事実は、Billionクラスの多次元ベクトルをどう扱うのかという命題の存在を示唆している。リンクを含む自然言語の構造は、この膨大な次元をほとんど削減せずに保持したまま扱えるという点で、LLMの世界観とよく似ている。
視覚表現の限界
Obsidianのようなナレッジベースのツールを使用する時に避けられない欲求が｢視覚化｣だろう。グラフビューに惹かれ、グラフビューに失望し、気づけばオフにする。これは、次元を考慮すると根本的に不可能であることが分かる。2次元で表現可能なのはあくまで3次元の影であり、それ以上の投影で視覚的に理解可能なのはせいぜい4次元くらいまでだろう。
次元削減の手法を用いれば、多次元を2次元に落とし込むことは可能ではあるのだが、実用的かと言われれば全くそうではない。例えば、生物分野でよく使われるUMAPという次元削減の手法がある。
図：UMAPによる次元削減クラスタリング(Geminiが適当に生成)
これはクラスタリングに使用される次元削減の手法である。UMAPを使用する目的は、遺伝子などの多次元要素のベクトル間距離を2次元に影として投影することだ。簡潔にいうと、近しいものを見やすくするということだ。一方で、各要素の詳細に関しては完全に隠れてしまう。この例で何が言いたいかというと、次元削減は常に目的を伴い、情報の削減を伴うということである。
記述的なWiki方式は次元･情報を削減しない
ここでWikipediaのような構造について改めて考えてみる。マークダウンとリンクのみを使用した管理方法だ。リンクは自然言語の中に埋め込まれている状態となる。関係性が自然言語による自由記述になっているということは、自然言語により作成しうるベクトルは表現されているはずである。そのため、この時リンクが形成するベクトルは次元削減を伴わないと考えられる。俯瞰できないが、削減もされない。これが、Wikipedia構造が達成している状態と考えられる。要するにrawの状態が保たれている。
一方で、全くの無策で挑めば間違いなくカオスが訪れるだろう。
図：私のObsidianのグラフビュー
このリンクたちを本当に活用することができているのか？ということだ。
カオスの克服法１：最低限のルール
いかにそのままの情報を保存していくと言っても、最低限のルールは必要だろう。Zettelkastenもそうだが、内容の性質ではなく自分がノートを取るときの｢行動の性質｣に基づいたルールが望ましい。また、Obsidianの特性上、ノートのタイトルに検索性が大きく左右されるのでタイトルにルールを設けるのが最もシンプルと思われる。私は、2023年のアドベントカレンダーで本アドベントカレンダーの発起人であるtadashi-aikawa氏が書いた記事を参考にしている。
例えば
- タイトル命名時にプレフィックスを付けると視認性が高まる。
- 一時的なノートには日付をつける(育てていくノートと明確に分離する)。
などが考えられる。
カオスの克服法２：検索強化とリンクの開通
Wiki構造の性質上、近しいものへの到達は容易いが、遠いものへの到達は困難になる。そのため、丁度ではなくても良いのである程度近くに着地する検索が必要になる。ここでObsidianがマークダウンファイルを使っているメリットが生きてくる。マークダウンファイルはgrepなどの検索ツールの性能をフルに使用できる。
逆に、目的のファイルへの到達速度が十分でない場合に、リンクを適宜整備するという姿勢も重要だ。どこにリンクを開通してもよいのだから、自分がよく使うルートにはどんどん開通させるべきだろう。結果として、よく使うファイルほどすぐに到達できるようになり、高度にPersonalizedされたVaultに成長していくはずである。
この検索強化、リンク強化に関してはtadashi-aikawa氏がコミュニティプラグインを作成されているのでぜひ活用されたい。
Quote
カオスの克服法３：2階建て構造にする
一度慣れてしまえばリンク構造だけでほぼ問題なくなるのだが、何らかの慣れ親しんだフォールバックがあると心理的に安全に運用できる。Obsidian内ではリンクでの管理をしなくても、どのような管理方法もできるようになっている。
最近ではBasesというコアプラグインが出たので、選択肢として挙げておく。
図：Basesを用いたデータベース管理(Obsidian公式)
デイリーノートにとりあえずリンクを貼るというのも有効だ。私は自作プラグインCrystalでノート作成時にデイリーノートに自動でリンクが貼られるようにしている。
とはいいつつ地図が欲しい
ここまで、記述的にリンクを貼りWikipedia的な構造を作ると情報の次元が削減されないということについて述べてきた。しかし、このVaultの中での活動は迷路の中を進んでいるような状況である。言い換えれば｢多次元空間の一人称視点｣に入り込んでいる。現在地はどこにいるのか、地図が欲しい。全体像を実用的に2次元に落とし込むことは難しいが、局所にスポットライトを当てて任意の方向から見た影を実用化することはできる。この時二次元に投射される影は、作者の着想というライトに照らされた影であり、ライトの方向は自在である。
Map of Contents
地図の書き方にはいろいろな方法がある。1つはMap of Contents(MOC)と言われる方法だ。ノートのリンクを羅列して、関係性を記述する。私は最初Obsidianを使用し始めた時、Map of Contentsの意義が理解しきれなかったのだが、今思うとこれはリンクで形成された多次元空間から任意の次元削減を行う作業であった。例えば私がこのサイトのObsidian関連のページのMOCを作成するとなると下記のようになる。
Map of Contentの例
- 基本
- 運用
- コミュニティプラグイン
- CSS
- 他ツール連携
私は簡便性と構造化のバランスから、リストを用いたアウトライナー形式を用いることが多い。上記例は単純にObsidian関連というだけの単純な抽出で作成したが、粒度が大きすぎた場合は切り出すこともできるし、分かりにくい場合は記述的にすることもできる。必要な時に必要なコンテキストのみの地図をつくると良い。例えば、私は自作プラグイン用のMOCを作成していて、プラグイン作成に必要な知識はそこから索引すれば良いことになっている。これはワークスペースとしての要素(本記事で指すところの次元)に焦点を当てたMOCとなっている。
Canvas
視覚化も地図の書き方の1つである。Obsidianのコアプラグインに｢Canvas｣というプラグインがある。これはノートやメモを2次元に配置し、リンクを含めて関係性を明示することができるというものだ。Canvasはマークダウン単体で俯瞰できないという弱点をよく補完している。この機能のポイントは自由に手作業で配置するというところである。Canvasによる視覚化は任意の目的をもち、任意の次元削減を伴うといえる。手間が増えるので私はあまり使っていないが、クリエイター系で使われている方が多いようだ。単純なテキスト表示よりも表現できる次元が大きいのは明らかであり、納得感がある。
図：Canvasによる手順の整理(Obsidian公式)
フォルダ管理やタグ管理も言ってしまえば、｢地図の書き方の手段の1つ｣であり、それぞれが特有の目的と次元削減を伴っている。目的に沿っている場合は選択すべき手段だろう。重要なのは、それを認識しているかどうかだ。
おわりに
まとめると｢Wikipediaってすごいシステムだよね｣という内容だった。そして個人レベルでそれを形成するとなるとやはりObsidianが良い選択肢になるだろう。もちろんその他の使い方も想定され、許容されている。
宣伝
私はBlueskyでObsidian部フィードを運営している。
Skyfeed製は数日しか遡れず反映が遅いが、漏れがなくObsidian公式アカウントのポストを拾う。Bluesky Feed Creator製はかなり遡れて反映が速いが、そこそこ高い確率で拾い漏れが発生する。サードパーティ依存は良くないと思い、最近実験的にセルフホスト版も作ってみた。こちらはリアルタイム性は若干落ちるが、単純な仕組みなので非常に軽く100件まで遡れることができる。たまに寝ているが更新すると起きる。
BlueskyのObsidianコミュニティはなぜかヘビーユーザーが多いので情報収集に役立てもらえると幸いだ。