アウトライン型データベースとしてのDynalistというのを以前書いた。このことについて、より正確な表現を目指して考えてみる。

データと文脈の分離

　普通データベースというのは、ある規格のデータ（＝レコード）によってテーブルが形成されており、それ以外のものはテーブル内に含まない。もしもレコード間の関係性を記述するならば、それは各レコードの中に書かれるか、或いは関係性を示すための別のテーブルをデータベース内に設ける。この場合決まった形を予め作らなくてはならない。
　それ以外に関係性について考え記述するには、全く別の場（例えば研究ノートなど）を使うことになる。
　このことで何か困った事態を引き起こすのかというと、別にない。そのような形になっていることでデータベースは汎用性が備わり、使う人を選ばないものになる。事実と解釈は分離しているべきである。

　それはそれとして、もしも自分たった一人が使うデータベースというのがあるならば、そう厳密に分かれていなくても支障はないということになる。データベースとノートが有機的に統合しているような形になってしまっても構わない。データベースの維持管理にはコストがかかり、普段使いのノートと一体になっていていいなら楽である。
　ただし完全に融け合っているとデータベースとして機能しなくなってくる。もしもこのデータベースとノートというのが紙で作られているならば、混ざっていったらただのノートになってしまう感がある。
　しかしデジタルなら、ある書き方をしている部分だけをデータとして引っ張り出すという処理をすることで、「データベースが融けているノート」から「データベース」を抽出するというようなことが可能になる。そのためには書き方を事前に決めて統一していることが必要である。（AIの力を使えばその限りではないが、ここではAIについては置いておく。）

データベースであり且つデータベース的でない

　ところでDynalistである。Dynalistは（というかプロセス型アウトライナーは）各ノードがひとつのレコードをなしたデータベースになっている。ゆえに検索をかければノード単位でヒットさせることができる。このデータベースには、DynalistならAPIを使えば直接アクセスできる。
　一方で、普通に使っていてプロセス型アウトライナーをノードをレコードとしたデータベースとは思わないだろう。そのように解釈して使うということはもちろんあり得るが、多くの場合アウトライナーはテキストエディタの一行一行を動かせてインデントできるものといった感覚で使われるもので、その一行一行を「データ」とはあまり考えない。なにしろ規格らしい規格をあからさまには感じない。
　まずこの二重性がポイントである。実際にデータベースであるので、一行一行をレコードとして任意のやり方で取り出せる。しかし使う際にはデータベース的でない使い方があり得て、むしろその方が普通なのである。

データ単位とノードの関係

　次に、Dynalistの各ノードにはいくつかのプロパティがある。ユニークID、本文、ノート欄、コンプリートの有無、チェックボックスの有無、色の設定、見出しの設定、そして子要素とその並び方。
　これらの要素があるので、ただアウトライン操作できるだけのシンプルなアウトライナーより、個別のノードはデータベースとして認識しやすいし、実際に処理がしやすい。何らかの設定をしたノードに対してこれはこういう意味のデータであると自分が解釈しやすいし、そしてAPIを通じてプログラムを使えばそれをそのように扱うことができる。
　一方で、自分がDynalist上で主観的に捉えている「ひとつのデータ」の粒度は、ひとつのノードが単位とは限らない。むしろ違う場合のほうが多い。つまり子孫要素を含めてひとまとまりと認識しているということである。しかし逆に、ひとつのノードがイコールひとつのデータであり子孫要素とはデータとしては別、と解釈した方が都合が良いこともある。親子関係が関係あったりなかったりするのである。
　この統一されなさはデータベースとしては厄介だが、統一しなければならないとなると自分の自由が損なわれる。データベースの都合に自分を合わせなくてはならないのは明らかに不自由である。
　その不自由さを打破する術がDynalistにはある（他のアプリケーションにはないと言いたいのではない。単に私が使っているところのDynalistでは事実としてできますよという話である）。Dynalistはユーザーがデータベース全体に自由にアクセスできるので、データの構造の解釈も自由にできる。つまり、この条件ならノード単体でひとつのデータと見なし、こっちの条件なら子孫項目も含めてひとつのデータと見なす、ということが（コードを書けさえすれば）自在にできる。

アウトライナーにデータベースを融け込ませる

　さてこの辺で前提に立ち戻ってみると、自分たった一人が使うデータベースならばノートと融け合ってしまっても構わないだろうという話だった。そしてそれがデジタルデータであればノートと融け合ったデータベースを（予め十分な用意をしておけば）抽出することができる。
　Dynalistではそれが技術的に可能であり、しかもそれが比較的容易であるということをここまで書いてきた。
　ではDynalistでそのようにすることの何が嬉しいのか。言い換えると、アウトライナーの中にデータベースを融け込ませられることの何が嬉しいのか。
　ひとつ重要なことを強調しておくと、APIでDynalistのデータベースにアクセスしてデータを取得できるということはつまり、データはアウトライン構造とは一切関係なく直に取得できるということを意味している。すべてのデータは見かけ上アウトライン構造のどこかに位置づけられるが、それを利用するにあたってはアウトライン構造は完全に無視できるということである。子要素を辿っていくことはあるが、そのデータがアウトライン全体のどこに位置するかはどうでもよい。
　少し混乱が生じる可能性を感じるので、Dynalistがユーザーのデータを保持するにあたって構築しているデータベース（APIでアクセスできるデータベース）と、アウトライナーの中に自分が融け込ませるデータベースを区別して、後者を「任意のデータベース」と表現する。
　Dynalist（または同様のことが可能なアウトライナー）に任意のデータベースを融け込ませた場合、任意のデータベースの各データはアウトライン構造の中で何らかの意味を自由に持てて、且つアウトラインの影響を全く受けないという二重性がある。
　ごく簡単な具体例を示してみる。例えばWebブックマーク用にアウトラインを作っているとする（実際にそのようなものを作っている）。そしてそれがこのような形になっているとしよう。

　この中に、色のついたノード（子要素は含まない）をレコードとする任意のデータベースが融け込んでいるものとする。データベースとしては、本文からタイトルとURL、色からブックマークの種類、ノート欄から分類を取得してレコードを作っている。このデータベースは別の場所から参照して、例えば自分用Webページの生成などに使う。
　融け込んだデータベースにとって、「2025年7月のブックマーク」の行や「四つのエッセンシャル・アウトラインとは：」の行などは一切意味を持たない。各ブックマークをデータとして見たい時にいつのブックマークかとかそのリンク先に具体的に何が書かれているかは必要ないと私が判断しているので、それらをプロパティに含めていないのである。
　そしてこれらのブックマークのノードを「2025年7月のブックマーク」ではなく他の位置にある「のらてつの記事」というノードの下に置きたいなと思ったら、ただ動かしてしまえばいい。自分にとってそのノードがどういう意味を持つかは変化するが、データベースとしては何らの影響も受けない。
　つまり、任意のデータベースの任意のデータを、任意の文脈に位置づけられるということである。データを抽出すればそれらはひとつのテーブルになるが、アウトライナーに融け込んでいる間、それらはテーブルの形式からは全く自由である。そしてそれは同時に、そのデータベースとは無関係な記述がデータとデータの間に入り込んでいることを意味している。私にとっては意味があるが、データベースにとっては無意味な情報である。

有機的なデータベースの意義

　ひとつ疑問を持たれるかもしれない。データベースは別に作って（例えばNotionに）、アウトライナーなどのノートにはそれへの参照を書けばいいのではないか？
　もちろん、それでも構わない。その方が合理性で言ったら上であろう。が、しつこいようだが自分ひとりが使うデータベースである。それをデータベースとしてきちんと整備してメンテナンスし続けられるかどうかという問題がある。システム上どんな合理性があっても「面倒くさい」「時間がない」には負ける。なので、文脈を扱うノートと一体にして有機的に管理したいという要求が生まれるのである。
　普通にアウトライナーを使うように使って、「これはデータと解釈したい」と思ったノードに色なりノート欄なりを使ってちょっと印をつけるだけで、それが（Dynalistそのもののデータベースとは全く無関係の、自分が定義した）データベースになる。データベース用の場所も必要ないし、データベースのための作業もほとんど必要ない。自分の感覚によるノート作りをしているだけで同時にデータベースができていく。そしてそのデータベースは全く別の場所から利用することができる。
　これは結構すごいことだと私は感動した。もしかしたら「融け込んだデータベースを更に他から参照して使う」ということのイメージを持つかどうかで話の印象は大きく違ってくるかもしれない。あくまで自分ひとりの世界の中に限られる話だが、完全にシステマチックな構造の中に全くシステマチックでない形のものが恰もシステマチックに作られているかのようにしれっと混じることができる、そのようなイメージである。