作りながら、考える
僕は、検索結果を生成AIへ渡して回答を作るRAGを実装しました。質問に関連するノートの一部を、回答用の情報としてチャットモデルへ渡します。回答だけを表示すると、どのノートが候補に入ったのか分かりません。
そこで、回答の下に「参照ソース」欄を置き、検索で選ばれたノートのパスと見出しを表示しています。見出しがない場合は、ノートのタイトルを表示します。
参照ソースは、回答が正しいことの保証ではありません。どのノートが候補だったかを確認するための手がかりとして使います。
僕は、Obsidianに蓄積したMarkdownノートを探すデスクトップアプリを作っています。名前や用語の一致だけでなく、内容の近さからも候補を出せるように、検索方式を一つに絞りませんでした。
実装では、BM25（単語の一致度で順位を付ける全文検索）と、ONNX形式のモデルで内容の近さを数値化するベクトル検索を使います。検索用のベクトルを用意できている場合は、同じ検索文を両方に渡します。二つの順位はRRF（複数の検索順位を一つにまとめる方法）で統合します。
ベクトルを利用できないときは、BM25の結果だけを返します。利用者に検索方式を選ばせず、一つの検索欄で扱う設計です。
結論
Obsidianで一つの焦点に絞った考えをZettelとして残し、親子関係を階層IDで管理するなら、IDの移動機能では自分自身・子孫への移動を拒否します。利用者が指定した新IDが別のノートですでに使われている場合も、書き込み前に止めます。循環やIDの重複ができると、親子ツリーを一意にたどれなくなるためです。
「Obsidianの階層Zettel IDを移すときは、子孫IDの対応表を先に作る」では、親ノートを移す前に子孫までの新旧ID対応表を作る判断を書きました。
僕は、Obsidianで一つの焦点に絞った考えをZettelとして残しています。ノート先頭には、親子関係を表す一意のZettel IDを付けています。
このIDを管理するために自作プラグインを作りました。Obsidian標準の機能ではありません。
移動先が自分自身または自分の子孫なら、親をたどると元のノートへ戻る循環ができます。指定した新IDが移動元以外で使われていれば、複数ノートへ同じIDを割り当てる衝突になります。僕のプラグインでは、どちらも対応表をノートへ反映する前に拒否します。
これは、実行前に分かる不正な移動を止める処理です。書き込み開始後に保存が失敗した場合は自動で元へ戻らないため、実行前のバックアップと実行後のID照合は別に必要です。
結論
Obsidianで階層Zettel IDを移すなら、親ノートのIDだけを書き換えず、先に子孫までの新旧ID対応表を作ります。親のIDだけを
1から3に変えると、子と孫のIDが古いまま残り、親子関係がずれるためです。
「Obsidianの親子ノートIDを手作業で管理しにくくなり、自動採番プラグインを作った」では、階層IDの採番と重複確認を自作プラグインへ切り出した経緯を書きました。続く「Obsidianの親子ノートIDを自動採番し、子作成とツリー表示まで行うプラグイン」では、子ノートの作成とツリー表示までの設計をまとめています。
僕は、Obsidianノートの置き場所とは別に、考えがどのノートから派生したかをZettel IDで管理しています。1.a は 1 から派生したノート、1.a.1 は 1.a から派生したノートを表します。今回は、フォルダや分類番号ではなく、このIDが表す親子関係を別の位置へ移す話です。
僕の自作プラグインは、変更するノートとその子孫を集め、次の対応表を作ってからfront matter（ノート先頭のメタデータ）へ反映します。Obsidian標準の機能ではありません。
1 → 3
1.a → 3.a
1.a.1 → 3.a.1
対応表は親から子へ順にたどり、新しい親IDに合わせて子のIDを付け直して作ります。1 を 3 へ移した後も、子は 3.a、孫は 3.a.1 という関係で保存されます。
プラグインは、表にあるノートを1件ずつ保存します。途中で失敗しても自動では元に戻らないため、実行前にVault（Obsidianのノート保管場所）をバックアップします。実行後は、各ノートのIDが対応表の新しい値と一致するかを見比べます。
結論
Obsidianで
1、1.aのようなIDを使ってZettelの親子関係を表すなら、次の子IDを選ぶ処理と重複確認は自動化できます。人は「どの考えから派生させるか」を決め、連番の管理をプラグインに任せれば、IDを考えの親子関係だけに使えるようになります。
僕のVault（Obsidianのノートをまとめる保管場所）では、自分の考えを一つの焦点へ絞ったノートをZettelとして残しています。1の考えから派生したZettelには1.a、さらにそこから派生したZettelには1.a.1というIDを付けます。
「NDCは主題、Zettel IDは考えの派生に使う」で書いたように、このIDの役割はノートの分類ではなく、考えの親子関係を残すことです。
Zettelが増えると、新しい子を作るたびに、次の三つを手作業で行う必要がありました。
考えを書く前にこの三つを毎回行うことが、手作業では負担になりました。
そこで、階層Zettel IDの管理だけを補助するObsidianプラグインを作りました。ツリーで親を選んで子を追加すると、プラグインが既存の直下の子IDを調べ、空いている最初のIDを付けたノートを作ります。たとえば1.aと1.bがあれば、次は1.cです。
どの考えを親にするかと、新しいZettelに何を書くかは僕が決めます。プラグインへ任せたのは、その判断の後に繰り返していたIDの割り当て（採番）と重複確認です。
結論
Obsidianで1ノート1焦点のZettelを整理するなら、僕はNDC（日本十進分類法）を参考にした分類番号を、ノートの主題に使います。
1から1.aのようなZettel IDは、どの考えから派生したかという親子関係に使います。主題と考えのつながりを、一つの番号で表さないためです。
僕のVault（Obsidianのノートをまとめる保管場所）では、Zettelを1ノート1焦点で残しています。Zettelは、自分の考えを一つの焦点へ絞ったノートです。
「外部資料から自分の考えまでを、3つのレイヤに分ける」では、Zettelを自分の思考を置くレイヤとして分けました。そのZettelを増やしていくと、ノートの主題と、どの考えから発展したかを別々にたどりたくなりました。
そこで、僕のVaultでは二つの番号へ別の役割を持たせています。
1、1.aのようなZettel ID：どの考えから発展したかを表すここでの分類番号は、日本十進分類法を参考にしてノートの主題を表す、僕のVault内の運用です。一方のZettel IDは分類には使わず、1.aなら1から発展した考え、という派生関係だけを表します。
同じ主題のノートでも、考えの派生関係が別ならZettel IDは別になります。反対に、ある考えから派生した流れが続いていても、焦点が別の主題へ移れば分類番号は見直せます。
この二つを分けておけば、主題に合わせてノートの置き場を変えることと、考えの親子関係を変えることを、同じ操作として扱わずに済みます。
結論
Obsidianで本や記事を読みながらメモするなら、要約・引用は外部資料のノートに残し、そこから生まれた自分の考えはZettel（1ノート1焦点で残す自分の考えのノート）へ分けます。出典と自分の解釈の境界を、あとからたどれるようにするためです。
僕はObsidianのVault（ノートをまとめる保管場所）を、外部資料と自分の考えの両方を残す場所として使っています。
「ObsidianのVaultを、情報の役割ごとに構成する」では、Vault全体の置き場を役割で分けました。その中でも、書籍や記事を読んだ記録は、次の2つを同じノートへ混ぜないようにしています。
僕のVaultで読書由来のZettelに残すのは、本の内容を章ごとにまとめ直したものではありません。元資料を読んで生まれた自分の考えを、一つの焦点へ絞ったものです。
自分の考えが独立したときは、元の要約へ書き足さず、新しいZettelから考えの元になった外部資料のノートへリンクします。これにより、どこまでが資料の内容で、どこからが自分の解釈なのかを分けて読み返せます。
ただし、短い引用に一言だけ感想を添えた段階では、無理にZettelへ切り出しません。あとから単独で考え直したい焦点になったときに、初めて別のノートにします。
結論
Obsidianで複数種類の情報を同じVault（ノートの保管場所）に置くなら、Vault直下は情報の役割ごとに分けます。主題だけで分けると、同じ分野の資料と自分の考えが混ざるためです。Zettel（1ノート1焦点で残す自分の考え）は、その中の一つの役割として置きます。
僕はObsidianを、Zettel専用ではなく、自分の情報をためて整理する場所として使っています。
同じVaultには、役割の異なる情報を置いています。
これらを最初から技術、社会、芸術といった主題だけで分けると、同じ主題について集めた資料と、自分で考えたことと、実用できる形に整理した知識が同じ場所へ混ざります。
そこで、情報を何に使うかで、Vault直下の最初のフォルダを分けています。その内側で、必要に応じて「何について書かれているか」を主題として分類します。
この構成では、Zettelは自分の考えを1ノート1焦点で残す置き場です。Vault全体をZettel中心の構成にせず、ほかの情報と区別して扱うための一つの役割として使っています。
このタグのコンテンツはまだありません。