Zettelkastenに適したノートの保存フォーマットについてまとめ

2021年7月13日投稿 カテゴリ：Zettelkasten

著者: jMatsuzaki

私の愛しいアップルパイへ

私は寝静まった砂浜を金色に照らす月明かりの如く尊い私の頭の中に眠る知恵をZettelkastenメソッドにしたがって整理しています。

Zettelkastenではファイルフォーマットを長く使える仕様にしておくことがまずもって重要です。これについてはZettelkastenで永続的に保存可能なフォーマットを採用する重要性にまとめました。

この方針に従い、ファイルの保存形式およびファイル内のフォーマットについて望ましいと考えられる形式をまとめてみましょう。

なお、Zettelkastenのファイルフォーマットについてはメソッド実践者たちによって数々の試行錯誤が繰り返されています。ナイス！私も先人たちの知恵を拝借しながら最適解を模索しました。参考にしたサイトについては適宜脚注に参考サイトを掲載します。

ファイルの保存形式について

まずファイルのデータ保存形式について整理しましょう。

プレーンテキストで保存する

まずファイルの保存形式としてはプレーンテキスト（テキストファイル）を採用することが推奨されます。これはデータの形式が特定の企業へ依存しないために重要です。独自のツールが生成する独自のデータベースは一定の利便性はあるものの、移行が困難となりデータの保存形式として脆弱なためです。1

プレーンテキストをファイルとして保存しておくことで、特定のツールだけでなく特定のOSにも依存しない形でファイルを保存しておけます。ハードウェアの変更にも耐えられますし、バックアップなどのデータ保護も容易です。

処理を自動化するにしても処理がシンプルにしやすく、選択肢も多いです。そのためGitなどオープンな技術を採用しやすくなるメリットがあります。私自身、ノートのバックアップと変更履歴はGitを使って保存しています。

Zettelkastenには永く活用する知恵が凝縮されたものであるため、ファイルの保存形式も半永久的に使えるプレーンテキストの形が望ましいのです。

日付形式のUIDを採用

ノートには1枚につき1つの普遍で一意なID、つまりUID（A unique identifier）の採用が推奨されます。ノートごとにUIDを採番することによってリンクを中心にデータ間の関連が明確に紐づけられます。同時に、簡潔かつ柔軟にノートへの参照を記載できます。

UIDは変わらないので、リンクを多用するZettelkastenにおいてリンク破損のリスクが大きく下がります。ノート間のリンクはZettelkastenにおいて最重要の資産であるため、これは欠かせません。この点において、多くのノートアプリケーションで採用されているノートのタイトル名によるリンクは避けた方が良いでしょう。ノートタイトルほど破損しやすいリンクはありません。

これは多くのZettelkasten実践者の間で広く支持されている方針です。23

また、UIDがあることでリンクの取り回しが簡単になります。他のアプリケーションからノートを参照する場合にも、UIDを記載しておけばよいのです。

極端な話、UIDがあれば手書きのノートから特定のZettelkastenへの参照を記載することも容易です（実際に考案者のルーマンはそれを実践していました）。UIDをメモしておけばよいのです。こうすることで、UIDがあればアプリケーション間の連携技術に頼らずノートへリンクを貼ることができます。

ファイル名リンクを採用してもノートへのリンクを自動更新する機能を備えたノートアプリケーションが多数あるので問題ないとお考えでしょうか。しかし、それは特定のアプリケーションの独自データベースもしくは独自プログラムに依存するリスクをはらむので望ましくありません。それはZettelkastenで永続的に保存可能なフォーマットを採用する重要性に反します。

UIDの形式はというと、日時形式を採用することとしています。ファイル作成日を年月日時分秒で表す14けたの数字をUIDとします（例：20210112162839）。秒を除いた12けたを採用しているケースも見られますが、デジタルZettelkastenにおいては秒まで含めるのが望ましいと考えます。

というのも、デジタル環境においてはファイルをコピーすることが容やすいうえ、環境によっては実際にファイルが生成された日ではなくコピーが実行された日付がファイル作成日となる場合もあります。その場合、秒を除いたUIDの形式では1分間の間に複数のファイルがコピーされてしまうため、UIDが重複することになります。秒まで含めることでUIDのユニーク性はかなり高いレベルで担保できます。

秒を含めることでUIDのけたは増えてしまうのですが、デジタルZettelkastenにおいては文字列のコピーは容易であるため問題にはならないでしょう。

アナログノートで行う場合にはUIDのけた数が多いと不便になるため、ルーマンが採用したFolgezettelを使うことも検討するとよいでしょう。

ファイル名をUIDにする

ファイル名は同じくUIDをそのまま採用するのがよいです。その場合、ファイル名はUID+拡張子の形となります（例：20210112162839.md）。

ファイル名はノートへの基本的なアクセス方法です。ファイル名にUIDを付与することは、データの整合性を保ち、リンクの破損からノートを守ります。

Zettelkasten実践者の間では可読性を高めるためUIDに英字のエイリアスを付与する形式を採用するケースも多いです。4

エイリアスの付与は検索性を高めると同時にリンク破損のリスクを高めます。しかし、ファイル名にUIDが含まれていれば、エイリアス部分に後から変更があったとしてもUIDからリンクを復元するのは容易です。

ただし、エイリアスを含める場合には英字だけに限定する方が望ましいでしょう。日本語などのマルチバイト文字はOSやソフトウェアによって解釈が変わるためです。また、日本語の濁音のようにNFCとNFDとで取り扱いが環境によって変わる場合もあります。

そのため、英字のエイリアスを毎回付与しようとすると、日本語のノートに対応する英語のエイリアスを毎回考えなければならなくなります。これは非効率なので、私はシンプルにUID+拡張子の形式をファイル名に採用しています。

実例として、ここまでのことを実践した私のZettelkastenフォルダを掲載します。

実際のZettelkastenフォルダ

ファイルのフォーマットについて

続いてファイルの中身にあたるノートのフォーマットについてまとめましょう。

Markdown記法

ファイルはプレーンテキストで保存することについてはすでに述べました。そのため、ファイルの中身もピュアなテキストとして記述していくことになります。

純粋なテキストファイルでもよいのですが、見だしや太字などの装飾ができるとノートの可読性が上がります。そこでMarkdown記法を採用します。

Markdown記法は通常のテキストと同じように記述でき、かつHTMLのように文章に基本的な装飾を付与できます。たとえば見だしや太字、リンクなどです。

Markdown記法は標準的な記法として広く採用されていますので、アプリケーションの選択肢が幅広く、アプリケーション間で移行するのも簡単です。また、Markdown記法はそのままでもノートの可読性が高いので、たとえMarkdownに対応していないアプリケーションを使うことになったとしても大きな支障が出ないのも魅力です。

ジョン・タイターのようにわざわざ過去にタイムトラベルして特定のマシンに搭載されたコンパイラーを入手するような事態にはならないでしょう。

Markdownフレーバーの採用

Markdown記法は便利ですが、そのままでは本当に基本的な表現しかできません。そこで、Markdown記法を拡張した記法が存在します。これはMarkdownフレーバーと呼ばれるものです。

有名なものに次の3つがあります。

  • Pandoc flavor
  • Multimarkdown flavor
  • GitHub flavor

どれを採用するかは好みもありますが、Zettelkastenの性質を考えると様々なデータ形式に変換しやすいPandocが適していると考えます。56

Pandoc自体がHTMLやPDF、LaTeXなど様々なドキュメントへの変換をサポートするツールでもあるので、そういった意味でもPandocの記法およびPandocがサポートする記法を採用することで柔軟性が高まります。Pandocの変換機能を使えばMultimarkdownやGitHubを含む様々なMarkdown flavorも解釈できます。7

リンクはMarkdown linkを採用

現状Markdown記法では通常のMarkdownlinkとWikipediaなどに採用されているWikilinkの2種類が多く採用されています。

Markdownリンクは次のように表記します。

[title](link)

Wikilinkは次のように表記します。

[[title | alias]]

Wikilinkは書き方がシンプルである一方、ファイルやフォルダ階層の変更に弱いです。また、アプリケーションによって解釈が変わることもあり、汎用性にも劣ります（後述）。常にタイトルとリンク先を分けて書くMarkdown linkは汎用性が高く、堅牢です。

ただし、基本的にフォルダ分けのないZettelkastenで、かつファイル名にUIDを採用している場合に限ってはWikilinkでもほとんど大きな問題は出ないと考えられます。

フォルダ階層は使用しない

Zettelkastenではフォルダによる階層分けをしないことが強く推奨されます。フォルダによる階層分けは、ノートを固定化したサイロの中に閉じ込め、再利用性を下げるとともにメンテナンス負荷をあげてしまうからです。

このことから、Zettelkastenにフォルダは設けず、ルートフォルダにノートをすべて配置することが望ましいでしょう。

フォルダを排除することはノートの分類に柔軟性をもたらすだけでなく、データの保存形式にも柔軟性をもたらしてくれます。

というのも、Zettelkastenの最重要な情報はリンクですが、フォルダ分けはときにリンクの破損をもたらすからです。リンクの解釈はアプリケーションによってまちまちです。そのため、リンクの記述はシンプルであればあるほど良いです。

たとえば、Wikilinkはあるソフトウェアでは相対パスの指定が不要ですが（たとえばObsidian）、あるソフトウェアでは相対パスがなければうまく機能しません（たとえば1Writer）。また、フォルダが変わればリンク文字列も変わってしまうため、メンテナンスもそれだけ困難になります。

特にノートのパスが何度も変わるようなフォルダ分けは、リンクの破損を招くので注意が必要です。

結論として、 同一階層にあるファイル指定のリンクが最も堅牢で汎用性が高いのです。同じ階層に配置されていれば、どのような形式でもファイル名を指定するだけでリンクは問題なく動作します。もしノートを分類する属性情報があるのであればFront Matterなどにメタデータとして埋め込む方が良いでしょう。

たとえば以前私は書きかけのノートをInboxというフォルダに保存していたのですが、今では上記のようなことからフォルダで識別するのではなく、Front Matterにdraftという項目を設けて管理することにしています。draftがtrueなら下書きで、falseなら執筆済みという訳です。

唯一の例外が画像ファイルなどのバイナリファイルで、これだけは専用のフォルダに配置しています。ただし、原則として一度ファイルを配置したら所属するフォルダの変更がない構成としています。

Front Matterの付与

ノートのヘッダにはメタ情報としてFront Matterを記述すると良いでしょう。特に汎用的に使われているのはYaml形式とToml形式です。

Yaml形式の場合、ノートの一行目にメタデータを記述します。メタデータの始点と終点は3つのハイフン（-）で区切り、その間に埋め込みたいデータを記述することになります。

Yaml、Tomlはノートにそのまま埋め込んでも可読性が高いだけでなく、これらの読み込みに対応しているソフトウェアが多いので汎用性が高いです。

例として、私が通常使用するYaml FrontMatterの形式を次に記します。

---
uid: 20210106161417
title: ノートタイトル
aliases: [ノートタイトルの別名(カンマ区切りで複数指定可能)]
date: 2021-01-15 19:23:09 
update: 2021-01-15 21:18:05
tags: [Zettelkasten, 第二の脳, Vim]
draft: true
---

タグはFront Matterに埋め込む

タグはノートを探したり読み返したりするときのエントリポイントとして有効に機能します。これについてはなぜノートにタグをつけるのか？にも書いたとおりです。

ではノート内にどのようにタグを記述するかというと、Front Matterに配列として埋め込むのが良いでしょう。一般的にはタグ名の頭に#をつけて、文中のどこにでもタグを埋め込めるいわゆるハッシュタグの形式を採用しているノートアプリケーションも多いですが、これはお勧めできません。

なぜなら、#は別の意味を持った特殊記号として解釈されかねないからで、特にノートをMarkdowで書く場合には見だし1を表す#と重複するため汎用的に使えるとは言いがたいものです。

よって、タグはメタデータとしてFrontMatteに埋め込むのが良いでしょう。タグの記述様式については上述したFrontMatterの例に記載されています。

フォーマットの自動整形について

書き出してみるとフォーマットとルールが多いため、慣れるのはたいへんですが、一度環境を整えて慣れてしまえばほとんど意識することなくノートを書き連ねていくことができます。

とはいえ、ノートの形式がルールに沿っているか毎回意識しながら書くのは面倒です。

そこで私はノートの形式をチェックし、ルールから外れた箇所があった場合にはある程度自動で修正してくれるPythonプログラムを自作して使っています。8ノート更新時にはGit Hooksをとおしてこのプログラムが自動で実行されるようになっています。

これは主にここに記載したルールをチェックして自動でノートを整形するとともに、Yaml FrontMatterの更新（updateの項目を現在の日時に更新なども含む）も実行しています。

これによってノートをフォーマットどおりに記述することがたいへん楽になりました。

最後に、私が実際に書いたZettelkastenのノートを1枚掲載しておきましょう。なんでそんなことをしてくれるのかって？それは私が紳士だからですよ。

Zettelkastenノートの実例

貴下の従順なる下僕　松崎より

参考文献

  1. Adam Jahnke, Simple Markdown Zettelkasten, Evan Travers, Mar. 13, 2020.
  2. Daneb, Why are UID necessary/used? — Zettelkasten Forum, ZETTELKASTEN FORUM, Apr. 2020
  3. pat, If you’re not using date-based IDs, you’re doing it wrong — Zettelkasten Forum, ZETTELKASTEN FORUM, Dec. 2020.
  4. Daneb, Why are UID necessary/used? — Zettelkasten Forum, ZETTELKASTEN FORUM, Apr. 2020
  5. Using pandoc | Pandoc User’s Guide
  6. John MacFarlane, Pandoc vs Multimarkdown, jgm/pandoc Wiki, Sep. 08, 2016.
  7. Options | Pandoc User’s Guide
  8. jmatsuzaki/note-normalization-for-zettelkasten
カテゴリ：Zettelkasten
著者画像
著者名：jMatsuzaki

システム系の専門学校を卒業後、システム屋として6年半の会社員生活を経て独立。ブログ「jMatsuzaki」を通して、小学生のころからの夢であった音楽家へ至るまでの全プロセスを公開することで、のっぴきならない現実を乗り越えて、諦めきれない夢に向かう生き方を伝えている。