結論

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が対応表の新しい値と一致するかを見比べます。