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

2026-02-05

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

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

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

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

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

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

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

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

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

VSCode

Obsidian

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

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

Markdownの別の特徴として、構造的な見た目が記法にも反映されている点があります。このため、特定のアプリで整形しなくても文書の構造を読み取りやすくなっています。例えばアウトライン（木構造をもつ箇条書き）の場合、各項目は先頭に - 記号のある行で、深さはそのインデントとして表現されており、一般的な箇条書きの見た目をもっています。

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

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

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

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

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

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

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

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

このMarkdownをアウトラインとして解釈する場合、空行で区切られたブロックを、アウトラインの1項目として扱います。ブロック内は、任意のMarkdownを受け入れます。アウトライン項目の深さは、ブロックの先頭に何もなければ深さ1、- があれば深さ2、 - があれば深さ3・・というように、記号の有無とインデントの深さで決定します。ブロック内のMarkdownは、インデントの深さを先頭の記号と揃えなくてよいものとします。

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

まず、-記号を用いたインデントの幅が1つ減っています。アウトラインは木構造であるのが当たり前なので、木構造の項目であることはデフォルトにしてよいという解釈です。項目の中身もインデントの深さを揃える必要があったのは、Markdownのリストがそういう解釈ルールだからです。アウトラインをMarkdownのリストで表現しないならば、この制限はなくなります。

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

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

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

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

完全なMarkdownのリスト形式の文書がほしい場合は、ここから簡単に変換できると思います。わたしがほしかったのは、アウトラインとして編集しやすいこういうMarkdownファイルだったんじゃないかなぁ。

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

Note

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

（追記 2026/10/24）その後、このときのアイデアを発展させて、自分用のアウトライナーであるPetaJournalの記録用フォーマットとしてflatmarkdownという名前で検討を進めています。書きやすさ、互換性、メタデータの表現方法など、まだ試行錯誤を続けています。