アウトラインを記録するためのMarkdown解釈

2026-02-05

Written by sosuisen

💾アウトラインをMarkdownで記録する方法

アウトライナーのデータをMarkdown形式のファイルへ保存する場合、Logseqが採用した方法よりも私にとって都合のよい方法がないものか検討しています。

そもそもノートツールでMarkdown記法を用いることについて、流行した背景の一つはRoam Researchだったのかなぁ、と思います。Roamはアウトライナーとしての特徴を多く持っています。LogseqはRoamの記法やWikiリンク構造の影響を受けたアウトライナーですが、データの保存に関するポリシーが大きく異なります。Roamのデータはクラウドのデータベースに保存されますが、Logseq（DB版以前）では、データもMarkdown形式のファイルとしてPCへ保存されます。

Logseqはアウトラインの木構造もMarkdownのリスト記法にして保存します。それは無理のない発想だとは思いますが、個人的には困っている部分もあります。

Logseqの次のようなアウトラインを例に検討してゆきます。

https://gyazo.com/b4ea7ff7a95db3534f918456883eabb5

これは、次のようなMarkdownとしてファイルに保存されます。普通のMarkdownですね。

https://gyazo.com/5dbedb7ecaababe94fd4b7fbd0150fd9

📝ノートはテキストデータで残したい

Markdownの特徴といえば、構造化された文書をテキストデータで記述できることだと思います。テキストデータは特定のアプリに依存しないので、データのやりとりや長期的な保存に向いています。LogseqがMarkdownでデータを保存してくれることは、自分の書いたものを長く残したいノートツールという観点では嬉しいものでした。

試しに、このデータをそのままVSCodeやObsidianで表示してみましょう。

VSCode

https://gyazo.com/afbfff8f76812e8e96f1f258f2052346

Obsidian

https://gyazo.com/e2d3b088b65c78c9ff300bb6088fd780

まぁまぁ表示できています。ToDoに関するLogseq独自の記法は反映されません。VSCodeでは改行の解釈が異なります。Obsidianではリストの中に引用を表示できていません。Markdownには公式の文法がないため、なるべく共通化する活動（CommonMark）やデファクトに近い形で利用されているルール（GFM）があるものの、完全なデータ互換性がないことは折り込んで考えたほうがよいです。しかし、上記の程度であれば、幾つかの簡単な置換ルールを持つツールで妥当な形に変換できますし、AIコーディングの発展でそうした便利ツールを作る作業は昔よりずっと手軽になりました。

📋構造の見た目が反映されることの良し悪し

アウトラインをMarkdownで保存する場合、個人的にはここに引っかかりを持っています。私はLogseqのMarkdownファイルについて、Logseq以外のエディタで編集することがあります。それができるのがテキストデータの利点であるとも思います。

たとえば、スマートフォン用の自作ツールで、次のような画面でぽちぽちと編集しています。私はLogseqのMarkdownファイルをGitHubと同期してるので、PCを開いていないときはスマートフォンでGitHub上のMarkdownを直接編集しています。これはGitHubのWebページ上でもできる作業ですが、ツールではブックマークや検索で多少ページを探しやすくしたり、Logseq向けの入力支援を付けています。こういうことができるのはとても便利だと思います。

https://gyazo.com/6be7d14bcc0395a558594ebde8a332f2

でも、こういう作業をしているときに、いまいち良くないなぁ・・と思っているのは、Markdownのリストって、リスト編集専用のツールを使わない場合にはそれほど扱いやすいものではないことです。インデントのスペースの数をきちんと守る必要があるので、深くなるほど扱いが容易ではなくなります。

たとえばここ。Markdownでは、リストの中のコードブロックは、深さのインデントを揃える必要があります。このためコードブロック内の全ての行のインデントが、深い位置まで必要となっています。

https://gyazo.com/29aa843cf3552e6b6d1b3b0ac9c88cba

文法を間違うとどうなるでしょうか？ Logseqではトップレベルでは木構造以外を持つことができないため、一般的なMarkdownよりも文法上の制約が強くなっています。制約を満たさない場合は、強制的に木構造の一部として解釈する処理が行われており、その結果を明確に予想することは難しくなっています。

💡アウトラインを別の方法で表現する

そこで思ったのは、そもそもトップレベルでは必ず木構造をとるアウトラインについて、このマクロ構造をMarkdownのリストで表現する必要はあるのか？ということです。項目内はMarkdownで書かれているのだから、これは自然なことに思えるかもしれませんが、どうでしょうか。

たとえば、アウトライン表現のための実験的なMarkdownとして、今回のサンプルと同じ内容を次のように書いてみます。

https://gyazo.com/ac7c30858a283e7d3bce7042e2110804

このMarkdownをアウトラインとして解釈する場合、空行で区切られたブロックを、アウトラインの1項目として扱います。

ブロック内は、任意のMarkdownを受け入れます。

ブロック内のMarkdownは、インデントの深さを先頭の記号と揃えなくてよいものとします。

空行区切りのブロックをアウトラインの1項目とするだけで、だいぶすっきりする点が出てきます。

項目の中身もインデントの深さを揃える必要があったのは、Markdownのリストがそういう解釈ルールだからです。アウトラインをMarkdownのリストで表現しないならば、この制限はなくなります。

このようにすると、メモ帳でファイルを編集するようなときにも、インデントに関する苦労がだいぶ減るのではないかなと思います。

加えて、Markdownからアウトライン項目を抽出するルールは、Markdown全体が木構造をもつリストとして解釈できるかどうかに左右されず、空行区切りという単純なルールになります。項目の区切りについて、テキストの見た目だけで解釈しずらいということもなくなります。

なお、これは普通のMarkdownの記法を用いているため、そのままVSCodeで表示することもできます。

こうなります。

https://gyazo.com/1da4f01e5f0ac4259fe75975a890248b

このままでもまぁまぁ元の文書の意図は読み取れると思います。

完全なMarkdownのリスト形式の文書がほしい場合は、ここから簡単に変換できると思います。

わたしがほしかったのは、アウトラインとして編集しやすいこういうMarkdownファイルだったんじゃないかなぁ。

いま、アウトライナーを作っていますので、こうした方向で進めてみようと考えています。

追記 2026/2/21

進めてみてから気付いたのですが、code fenceの中に空行が現れたときへの対処が別途必要なので、あまりスマートともいえないですね。