Noratetsu Lab

　基本的には見た目に変化はないことですが、サイトのデータの管理方法を大きく変えました。

　これまではDynalist上で書いてDynalistからAPIでデータを取得してサーバーサイドでサイト用データに変換していましたが、全てmdファイルにしてローカルに置き、そこからサイト用データを生成する形にしました。
　Dynalistの構造を利用して表現していた記法を機械的にMarkdownとHTMLに置き換えてmdファイルを生成しているため、一部表示が変化したり乱れたりしている箇所があり得ます。軽くチェックした限りでは概ね大丈夫だとは思いますが、リンクの置換ミスが稀にあったりするので、しばらく「あれ？」と思うような部分が残るかもしれません。
　お知らせは以上です。

---

　ここからは変更の経緯などを記録として書いていく。
　当初、自分の文章の公開方法はBloggerというサービスを利用してのブログだった。Bloggerはブログサービスとしては編集もしやすく昔から使っていたもので馴染みもあって気に入っていたが、やはりデータが自分の手元にないということが不便だった。記事を編集するとなればいちいちその記事の編集画面を開いて編集して保存してということをやらなければならないし、複数の記事について一括で置換する的な処理はできない。何もかも手動でやらなくてはならない。
　そこで全て自分の裁量でデータを扱えるように自分でサイトを作ることにして、現在はDeno Deployというサービスを使って公開している。記事データについては最終的にサイトを開いた時に読み込まれるJSONができていればいいので、どういう経路でそのJSONに至るかはなんでも構わない。今回の変更もJSONを生成する手前の話なので、サイト自体のコードはなんにも変わっていない。
　今の形式でエディタとして利用できる手段は「APIで自分のデータを自由に取得・編集できるアプリケーション」または「ローカルファイルを編集できるアプリケーション」ということになる。前者の例がDynalistやNotionで、後者の例がObsidianや一般的なテキストエディタである。

　Dynalistは文章エディタとして非常に優秀だ。それは「文章のアウトラインが作れるから」という意味ではない（それも重要な要素ではあるが、私にとってはさほど大事なことではない）。それ以上に、行単位で子要素を持てたりノート欄を持てたりすることによって、自分向けの情報も機械用の処理の指示も自由自在に文に付属させられることが大きなメリットである。
　たとえばMarkdownに専用の記法がない折りたたみなども、「この記号で始めたノードは子要素を中身としたdetails要素にせよ」ということを（コーディングの知識があれば）柔軟に定義できて、detailsタグなどを文中に記述する必要はない。自分が文章を書く上でそのような異物が混じらないことは重要だ。
　最終的に文章に反映させない、いわゆるコメントなどもノート欄や子要素で表現できる。加えて、没にする部分についてはプログラミングと同様の形でコメントアウトの記法も定義している。
　行単位でメタデータや構造を持てることによって、アイデアを思いつきさえすればなんでもできるのだ。

　ただしDynalistでは不自由な面もある。それがネットワークの作りにくさだ。
　Dynalistにもノードリンクという機能があるのでそれを使えば「この記事へのリンク」ということは表現できるが、サジェストを使おうとすると全てのノードが対象になってしまうがゆえにノイズだらけでまともに機能しない。ノードリンクについては以前書いたが（ノードリンクを活用し全てのノードに意味のあるアウトラインを作っていく）、ノードリンクを機能させるには使い方に注意を払う必要がある。
　全てのデータが上から下に並んでいなければならないというのもネックだ。データが全て時系列のブログ的記事なら公開日順に並んでいればそれでいいのだが、例えばキーワード単位で作るデータ（当サイトでは「用語集」としている）については、順番に並ぶことに必然性がないので、自分の認識とDynalist上で表現されているデータの並びとが一致しない。
　それゆえに用語集部分だけ先にネットワーク型の管理方法に移転していたのだが、そうするとツールが別になるので記事とリンクが直接繋がらない。これまでどうしていたかというと、Dynalistのタグを用語集に含むキーワードと一致させることで、JSON生成時にサイト上でリンクになるよう処理を可能にしていた。サイトのデータを作るという意味ではそれでも良いのだが、自分の手元でリンクになっていないので作業が直感的にならないという問題があった。

　また、Dynalist（というかアウトライナー）に情報を蓄積させ続けるのが果たして妥当かということもある。Dynalistは仕組み上データベースであるし、検索機能が充実していることもあって主観的にもデータベースらしく使うことは不可能ではないが、しかしデータベースとしての活用が向いているかというととてもそうは言えない。無限に増え続けるタイプの情報を扱うなら他に相応しいものがある。

補足（クリックで開く）

　以前Dynalistのデータベース化について書いたが（アウトライン型データベースとしてのDynalist）、それは今話していることと少しレイヤーの異なる話である。というのは、データベースと言ってもひたすらに情報を蓄積していく種のデータベースと、何かを表現するにあたってそれを構成するデータの集まりとして必要なデータベースとがあって（データベースというものに詳しい訳ではないのでふわっとした言い方になってしまうがご容赦願いたい）、前回は後者のためにデータベース然とした形式から解放され自由に文脈を添えられる有機的なデータベースを考えることが有効だという話をした。 　サイトの記事データというのもある程度までの規模は「サイトを構成するためのデータの集まり」という性格が強かったが、やはり何百件も蓄積して更に今後も増え続けるとなると（既に800件近くある）、これらは単にサイトの構成のためのデータではなく自分の歴史と一体になった情報であり、データベースとしての性格も変わったと言える。 　最初から増え続けるタイプのものだというのはわかっていたわけだから限界は予見できたはずのものだが、やってみなくては「向いてなさ」の形が見えてこなかった。 　実際、今後もDynalistに蓄積させ続けるのも無理なことではない。もしデイブ・ワイナー氏のようにアプリケーション自体を自分で作っていてDynalistに不足している要素を自力で完全にカバーできるのであれば、アウトライナーという形態自体が欠点になることもない。アウトライナーであるというのは単にデータの表現形態のひとつに過ぎないからだ。 　ただ現状、Dynalistのシステムでは何千件のような単位の膨大な件数を管理することに特段のアドバンテージはない。データの読み込みのタイミングからしても、何千ノード程度ならいいとしても一件が何十から何百のノードで構成され得るデータが何千件となるとかなり厳しい。画像を多く含めば通信量が嵩むし、ノード数が増えすぎると差が認識できる程度に挙動も重くなる。

---

　Dynalistのノードはどうとでも解釈して使えるという利点があると同時に、自力で解釈を加えないと特定の範囲を一件のデータとして扱えないという難点がある。個別のデータとして形が定まったならば、それはNotionやObsidianのようなデータベースらしく使えるツールの方が扱いやすいし、年月が経った後でも未来の自分が認識しやすい。 　アウトライナーは情報を流動的に扱えるのが武器であり、基本的には「今ホットなもの」のための場であった方がよいと思う。過去のものになった情報、つまり情報として固定的になったものは、流動性の乏しさの代わりにデータとしての扱いに長けている種のツールを使った方が後々便利だろう。

　そのようなわけで、サイトのデータはmdファイル化し、Obsidianを用いて管理することにした。
　ただしDynalistで書くのが楽なので、Dynalistで初稿を書くというのは継続する。一通り書いたらプログラムでmdファイルに変換し、以降はmdファイルを編集する。
　書き終わったものの管理はObsidianを使えるmdファイルの方が楽だが、これから書くものはアウトライナーの方が良い。形が定まっていない曖昧な状態で置いておけるからだ。
　

　アウトライナーでどんどん書いていってアウトラインを作ったとする。その内容が自分の中でホットな間はそれで困らないのだが、少し時間が経ってから見返すと、全体のメリハリが一目でわからなくなり内容の認識に手間取ることがある。

　HeadingやColor、太字や斜体などを駆使してアウトラインの見た目をリッチにするという手もあるが、あんまりごてごてとやってもかえって把握しづらいし、ノードの操作が硬直的になるからノードの役割がはっきり決まっている場合以外はその手は使いにくい。
　CSSの上書きによる全体のスタイルの調整で解決することはできないだろうか。

　内容が一目でわからないというのは、単純に言えば「どこからどこまでがどういう一塊かわからない」ということだ。DynalistやWorkflowyのようなプロセス型アウトライナーは全てのノードが同じ見た目をして同じように扱えるのが良いところだが、それゆえに文字とインデントしかヒントがないということになり全体がのっぺり見えることがある。
　このことに対して二つの道を考えた。
　まずひとつは子項目を含めてノードを枠で囲ってしまうこと。そうすればその枠内が親子関係上一塊であることが一応明確になる。ちょっと設定が雑だがイメージとしては以下のような感じ（サンプルの文言が不自然だがこれは一番最後の例のために用意したもの）。

　塊は認識できるが、階層が深くなっていくと枠が何重にもなってしまうのが気になる。もうちょっと綺麗にしようはあるものの、そうしたとしてもあんまり嬉しい感じではない。
　かなり前だが、子項目部分に不透明度を下げた色をつけるというのも試したことがある。階層が深くなればなるほど色が重なって濃くなっていくという形だ。

　これはやや極端に色を付けた例。仕組みとして悪いとは思わなかったが、視覚情報が増えすぎて疲れてしまう感じがあったので程なくしてやめた。

　もうひとつ考えたことは、「メリハリがわからない」という状態を視線誘導で解消するみたいなものだ。具体的には、各ノードの本文を文字列のサイズ依存で枠で囲み、行というより粒状の見た目にしてみる。

　枠で囲むとその範囲にピタッと視線が定まる感じがあり、またインデントが明確になるので大量に並んでいてもある程度把握が容易になる。話題の一塊をまとめて括っているわけではないが、何もしないよりは認識しやすくなる。
　スマホアプリとしてリリースされているアウトライナーでもこのように各ノードを内容のサイズに合わせて囲っているものがある。パッと見た時は枠が煩わしい印象を覚えたが、目が滑らないようにノードをはっきり視認したいという要求を抱いた上でデザインを自分好みに調整したならば、これはなかなか悪くない感じがする。
　なお足したCSSは以下の通り。画像では他に適用しているスタイルが反映されているがそれについては省略。

.Node-renderedContent {  
    outline: solid 1px #bbb;  
    width: fit-content;  
    padding-right: 6px;  
    padding-left: 2px;  
    max-width: 100%;  
    border-radius: 3px;  
}  

　実際、何ヶ月か前に書いてそのままになっていたアウトラインが読みにくく感じて手を加えるのを億劫に思っていたが、このようにスタイルを変えたら随分認識が楽になって作業が進んだ。
　しばらく続けるとまた何か思うところが出てくるかも知れないが、とりあえずはこのまま使ってみようかと思う。
　

→【Dynalist】ノードリンクのスタイルをCSS上書きで見やすくする｜のらてつ

関連

• ノードリンクを活用し全てのノードに意味のあるアウトラインを作っていく
• 【Dynalist】考え事を進める時に私が使っている記号

→【Dynalist】タイトルノードのノート欄にコードブロックでファイルの定義を書いてみる｜のらてつ

　最近、Dynalistでノードのリンクを活用するようになった。

　Dynalistでは全てのノードにURLが存在し、別のノードにそのURLを貼るとノード間で紐づけられバックリンクも表示してくれる。貼り方はURLだけでもいいしMarkdown形式でもいい。URLのみ貼った場合は自動的にリンク先のノードの本文が表示されるようになっている。
　また、行頭または半角スペースの後でダブルブラケットを入力するとリンクのサジェストが表示される。文字を打っていくと候補が絞られていく。範囲はアーカイブしていない全ファイルで、編集中のファイル内のノードが優先されるが他のファイルのノードも候補に並ぶ。 候補のノードがどこに存在するものかというのは、パンくずリストも一緒に表示されるので判別できる。
　なお、サジェストの絞り込みに反映されるのは本文部分のみで、ノート欄の内容は候補のピックアップに関係しない。

　サジェストとバックリンク表示機能があるわけなので、Dynalistをネットワーク型のツールとして扱うことも機能的には可能である。しかしながら、推測するにノードリンクを多用している人はそういないような気がしている。なぜなら、普通に使っていたらノードのリンクをあちこち張り巡らしたくなるような使い方にはおそらくならないからだ。
　今Dynalistを使っている人は実際にダブルブラケットと何か文字を入力してみてほしい。そうでない人もちょっと想像しただけでわかると思うが、存在している全てのノードが対象になってしまうとなると、サジェストはおそろしく雑然としたものになるだろう。ノードごとに粒度はばらばらだし、そもそもアウトライナーというのは文脈の可視化やコントロールのためのエディタ、つまり文脈エディタとでも言うべきものであり、周辺のノードがわからなければそのノードの意味は見えてこない場合が多い。
　ノードのリンクを貼りたい、つまり「あのノード」と指し示したいと思うようなノードというのはそう多くはない。自分の中でそういう重さのノードかもっと軽いノードかというイメージを持っていても、ツールの側はそれを察してくれはしないので、気を使わなければサジェスト候補は各々の文脈でしか意味を持たない細かいノードで埋め尽くされ、まともに機能しない。

　じゃあどうするか。気を使って利用すればいいのである。ノードリンクを活用することを前提としたアウトラインづくりを考えてみる。
　まずは普通に自由に書いていく。例えばこんなアウトラインができたとしよう。（例は昔Scrapboxに書いた内容を一部変えたもの。）

　考えの整理という点ではこれで構わないのだが、このままだとどのノードもリンクを貼りたくはならない。各々のノードが話題のひとかたまりを示しているわけではないからだ。
　このように細かくノードが分かれていることによって更に思考が発展する可能性が十分にある場合は、もちろんそのままにしておいた方がいい。ノードリンクを活用すると言っても、それよりも自分の頭が自由に働くほうが優先されるということは忘れてはいけない。
　とはいえ、このように細かいノードを林立させている状態というのは、深く考えずにとりあえずブレストしていった結果というだけのことも多い。その場合そのまま残しておくことに大した必然性がない。
　アウトラインを作る中での一連の思考から得られた結果を、ひとつひとつ文にまとめてみると例えばこうなる。

　どんな話題にどんな結論が出たのかを明快にすると同時に、それぞれのノードでひとつの内容を完結させている。こうすると、「あの話」と言って特定のノードを指し示すことも可能になる。
　この一連は「自分語り」をテーマとしたものだが、全てのノードに「自分語り」の四文字を入れることで、後から「自分語り」で探した時にそれぞれ引っかかり、周辺ノードが作る文脈に頼らずに個々のノードを活用することができる。
　ちなみに先日思いついて始めた工夫だが、一行目の最後につけている「：」は「このことについて子ノードで考えを展開しています」ということを示している。サジェストでこのノードを見た時に位置づけが一目瞭然になる。「：」をつけていない場合には、例えば何かの考え事をした結果「～について考えよう」という結論に至った、ということを意味する可能性がある。
　考える過程で発生したものの最終的に要らなくなったような内容については、それをずばり指し示したい瞬間はおそらくないので、ノードとして存在している必要がないということになる。それでも残しておきたいという場合はノート欄に移しておく。ノート欄はサジェストには関わらないが検索すればちゃんと出てくるので、後から探すのに支障はない。

　ノードリンクのサジェストがどうなってほしいかを念頭にこのように整理する癖をつけると、アウトラインの各ノードはそれ単体で明瞭な意味を示した、謂わばアトミックなものになる。そうすると結局今まで何を考えてどんな結論を出したのかもわかりやすい。ノードひとつひとつが財産になっていく。
　考えた結果はちゃんとまとめよう、という心がけを持とうとしても、どういう状態になっていればOKなのかがはっきりしていなければ努め続けるのは難しい。しかし「サジェストに出てきた時に納得できる粒度」という尺度があれば、それを満たしていればまとめは完了したと言えるし、そうなっていないものにはもやもやと不快感を覚えるのでもうちょっとどうにかしようと思うことができる。心がけの力ではなく、収まりの悪さへの苛立ちによって整理を進めていくわけである。
　なお、冒頭に書いたようにサジェストの範囲はアーカイブしていないファイルに限られる。アウトライナーを使って扱いたい全ての内容についてこのような整理を目指す必要は全くなく、ノードリンクを使いたい領域以外はアーカイブしてしまえばいい。アーカイブ設定は全体検索にも影響が出ることには注意が必要だが、個人的には全体を横断して検索したいことはほとんどないのでアーカイブ設定で支障を感じたことはない。設定のオンオフは簡単なので必要が生じたら解除すればいいだろう。

　リンクの貼り方にはURLそのままとMarkdown形式とがあると最初に書いた。URLだけを貼った場合には、リンク先の内容を変更した場合にそれが常に表示に反映されるという利点がある。そして同じ文面をあちこちに書くことにならないので、検索やサジェストのノイズにもならない。
　となれば、Markdown形式は表示を意図的に変更したい場合に使えばよいと言える。リンク元が何十字かの文になっていたとしても、それを数文字で示して文中に組み込むということもできる。その都度エイリアスを生み出せるようなものだ。
　ネットワーク型ツールではリンク元のタイトルそのままでしか扱えないことも多く、その場合文中に馴染ませるためにタイトル付けに工夫が必要になったりするが、その都度適当に言い表せばいいとなればタイトル付けに悩むこともない。アウトラインの各ノードにタイトルは不要である。
　ただしこの場合、どのノードを指してその表現にしているのかが自分でわからなくなることもある。リンクをクリックすれば確認できるが、いちいち飛ばなくてもわかったほうが便利ではある。この課題について、私はChrome拡張機能を作りスクリプトを走らせてマウスオーバーでリンク元の本文とパンくずリストを表示できるようにしているのだが、その話は別の機会にするかもしれない（しないかもしれない）。

　ノードリンクは便利な機能だが、ひとつ問題を挙げるならば、デフォルトの状態だとノードリンクはちょっと見づらいということがある。

　本文に溶け込んでいないし、画面の端で内容が省略されてしまう。なのでChrome拡張機能（例えばMagic CSS）でCSSを上書きしてこのようにしてみた。

.node-inline-item:not(.node-inline-image) {  
    display: inline;  
    border: unset;  
    background-color: unset;  
    color: #384d98;  
    font-size: inherit !important;  
    text-overflow: unset !important;  
    white-space: normal !important;  
    text-decoration: underline dotted;  
  
    &:before {  
        display: none;  
    }  
}  

　こうすると本文中に混ざっていても違和感はない。既出の概念についてはリンクになっていた方が嬉しいという感覚も生まれ、一層リンクを活用したくなる。
　CSS書き換えはDynalist自体に備わっている機能ではなく裏技的なものである。Webブラウザでしか実行できないという難点もあるが、見た目を変えるだけで使用感が劇的に向上するということはよくあるので、ツールの機能をフル活用するために試してみる価値はある。（書き方を細かく解説するのはちょっと手間がかかりすぎるので割愛する。）

　最後に。重大な注意点として、ノードを別のファイルにMove to...で移動してしまうとそこでリンクが切れるということがある。ファイル一覧にドラッグして移動した場合には更新されるようだが、ありとあらゆるパターンを試して確認してはいない。動かし方によってリンクの追跡がされたりされなかったりということになるので、ファイルの構成に迷っている間はあまり多用しない方がよいかもしれない。

　Dynalistはアウトライナーだが、私にとってはデータベースである。アウトライナーとして使えるデータベース、くらいの言い方をしてもいいかもしれない。

　もちろん普通にWebブラウザやスマホアプリで操作する分にはただの（と言うのもおかしいが）アウトライナーである。Dynalistがデータベースであるというのは、アウトラインの形をトップダウンできちっと整備してデータベースとして使うというような意味ではない。発想としてはむしろ全く逆である。

APIで取得できるデータはアウトライン構造に縛られない

　DynalistはAPIを提供しており、プログラムを通じて自分のデータを参照したり編集したりすることができる。あるファイルのノード情報を取得する場合、そのファイルに含まれるノードがフラットな配列として取り出される。以下の型のオブジェクトがひとつの容れ物にわっと入っている状態である。

{  
    id: string,  
    content: string, // 本文  
    note: string, // ノート欄  
    checked?: boolean,  
    checkbox?: boolean,  
    color?: number, // 0~6  
    heading?: number, // 0~3  
    created: number,  
    modified: number,  
    collapsed?: boolean,  
    children: string[], // idの配列  
}  

　アウトライン構造はchildrenプロパティに子ノードのidが列挙されることで表現されている。なのでこのidに一致するデータを探せばそれが子ノードだと分かる。しかしデータ自体はアウトライン構造にはなっていないわけである。ルート直下のノードも10層インデントしているノードもデータ上は隣に並ぶ。
　つまり、そのノードがどこにあろうが関係なく扱えるということになる。例えば色を赤に設定したものに何らかの意味付けをするとしたら、それぞれてんでばらばらな深さに存在していてもcolorプロパティによって同じ種類のデータとしてまとめて取り出せる。色なり見出しなりノート欄なりを使ってそのノードの種類を自分で定義すれば、ノードの種類を示すためにアウトライン構造を使う必要はなくなる。
　アプリケーション上のビューでは全てのノードがアウトライン構造のどこかに位置づけられる必要があっても、それぞれのノードのデータはアウトライン構造とは無関係に活用することが可能なわけである。
　このことにより私の中でDynalistの使用感は大きく変化した。APIが使えなかった頃は分類的な視点でアウトライン構造を用いていたが、そのように形式的なアウトラインを作る必要がないとなれば、完全に「気分」で自由にノードを配置できる。これとこれが近い方が便利だ、その方が気分が良い、そういう理由で配置することに違和感を覚えなくなった。
　もちろんカオスな方が良いということではない。自分が納得する基準で適切に配置させられるのがアウトライナーを使う理由なのだから、自分なりに整えていくことにはなる。そこに自分の気持ちとは無関係な形式的構造を混入させずに済むというのがAPI活用のポイントである。

活用例①　サイト記事のデータベース

　ここまでの話だと「データベース」感は薄い気がするので、データベースとしての活用の話をもう少し具体的にする必要があるだろう。単に特定の条件で一度にピックアップできるというだけなら検索機能を使えば済んでしまう。
　このサイトの記事はDynalistに書いてAPIを通じてサイト用のデータを生成している、という話は既に何度か書いている。それはつまり、Dynalistのひとつのファイルが記事のデータベースになっているということだ。
　特定の書式（例えば色が赤でノート欄に日時が書いてあるなど）に従って書いているノードをタイトル行、その子項目を本文と解釈することで、それをひとまとまりの記事データとみなす。

　判定にはアウトライン上の位置は全く関係ないので、書式に従ってさえいればどこにあってもいい。データの並び替えは後で日付順にすればいいのだから、アウトラインの中では時系列がめちゃくちゃでも別に構わない（もちろん敢えて乱す必要はない）。
　その記事が、サイトの中で、あるいは私の考えの中でどういう位置づけにあるのか、アウトライン操作によって整理していきたいこともある。そんな時は並べ替えたり階層を上げ下げしたり自由にぐりぐり動かせばよい。どう動かしたって記事のデータベースとしては何も影響を受けない。

活用例②　ブックマークのデータベース

　インターネットを使っていると、日々数多のページにアクセスすることになる。有用なものがあればリンクを保存しておきたいと思う。便利なツールのURL、興味深い記事のURL、誰かのサイトのURL、後でチェックしたいもののURL、等々、さまざまな種類や状態の情報を保存しておくことになる。
　全てをブラウザのブックマークに入れるとごちゃつきに耐えられなくなるのだが、これらを如何にもなデータベースで管理するとなると、保存の気軽さや頻度の多さとデータベースというものの仰々しさが大抵見合わない。とても手入れはしていられないし、テーブル形式のぴしっとした感じの割にそれほど見やすいわけでもなかったりする。
　とりあえずDynalistにファイルをひとつ作り、そこに全部突っ込んでしまうことにした。最初は「検索すればいい」というつもりでDynalistを選んだのだが、ある時「ほかにビューワを作ってDynalistをデータベースとして使えばいいのではないか」と思いついた。作ったブックマークのビューワがこれ。（画像の内容はもちろんごく一部。）

　ブックマーク用のファイル内にある色付きのノードをブックマークとして解釈し、その色をそのまま背景色にしている。色は「サイト」「ツール」「記事」のような意味合いを表している。分類はノードのノート欄につけたタグで判別していて、アウトライン上の位置とは関係がない^[1]。タグがないものが「未分類」になっている。
　大量に保存したリンクの中でビューワに表示したいノードにちょちょっと色をつけるだけで、あとはプログラムがいい感じにやってくれる。アウトライン上は汚部屋みたいにとっ散らかっていたとしても、ビューワはさも手入れの行き届いたデータベースがあるかのように美しく表示してくれるわけである。
　アウトラインも汚くはない方がいいが、そっちはそっちで別の基準で操作して整えていけばいい。

外からデータを編集する

　ここまではDynalist上で書き込んだ情報を取得・解釈して活用することについて記してきた。しかしDynalist APIでできることは情報の取得だけではない。データの編集も可能である。
　不可逆的な操作になるのであまり軽率に試していいものではないが、APIを使えばファイルやフォルダ、ノードの作成・編集・削除ができる。Dynalistを開いていなくてもDynalistのデータにアクセスして弄れるのだ。
　例えば、あるファイルの中のノードについて一括で置換したい何かがあるという時に、普通はひとつひとつ手作業でやるしかない気がするが、APIを使えばプログラムで処理できる。ルールを前もってきっちり決めなくても後で軌道修正できることになり、大規模な何かをやるにしてもあまり構えずにやれるようになる。
　あるいは、何かのページを見ていてリンクを保存したいとなった時に、自作のChrome拡張機能にDynalist APIを使った処理を実装しておけば右クリックメニューから直接Dynalistの特定の場所に送信するみたいなこともできる。私はブックマーク、記事の本文、Twitter（X）のポスト、YouTubeの情報などをそれぞれ然るべき場所に送れるようにしている。
　こうするといよいよDynalistがデータベースらしくなってくる。Dynalist上での操作より外から操作する方が多いファイルというのもあり得るし、アウトラインの形で見たい時だけDynalistを開くという使い方も考えられる。アウトラインの表示を自分で作るのは割と面倒くさいので、データのアウトライン化を簡単に実現してくれる手段としてDynalistを利用するわけである。

見出し、色、ノート欄の存在意義

　このようにしばしばアウトライナーとしての在り方から逸脱した使い方をしているが、もちろんDynalistのファイルおよびノードを全てデータベースとみなして使っているというわけではない。普通のアウトライナーとしてアウトラインを考えることにも使っているし、その方が当たり前に多い。しかしそれらはいつでもデータベースとして解釈して活用することが可能である。
　Dynalistの見出し、色、ノート欄は最初の頃はさっぱり上手く使えなかった。検索での絞り込みにそれらを使うことはできるが、結局のところ当時の自分にとっては見た目の問題でしかなかったからだ。何色をどういう意味で使うかに必然性はないし、6色もあるが6色しかないということも活用を難しくしている。
　しかしながら、プログラムでの判定にそれらを活用できるとなると、急にそれらが便利なものに変身した。全てをノードの本文部分に書かなくてはならないとなれば、私自身には必要のない機械用のデータが場所を取って見ていて嫌になってくる。なのでメタデータを付与できる手段がほかに色々あるのはとてもありがたいことなのだ。
　今となっては色設定とノート欄は必要不可欠である。色付けに必然性が生まれたことによって使うタイミングに迷うことはなくなり、また「使いこなせてない」という気分もなくなった。

　アウトライナーは全ての情報をアウトライン上に位置づける。その特徴は私たちの理解を助けてくれる一方で、情報が位置に縛られるという欠点にもなる。しかしDynalistには別の切り口で情報を扱う手立てがあり、工夫次第でデータを如何ようにも活用することができる。
　その意味で、私はDynalistを単なるアウトライナーではなく「アウトライン型データベース」だなと思って使っている。

---

1. プログラミングを始めた頃はアウトラインの位置を基準にしたブックマークビューワを作っていたが、手入れが面倒になってしまった。 ↩︎

　ここのところデジタルのメモの整理を大規模に進めている。

　　

これまでの様子

　なかなかアプリケーションに納得できずあっちこっちを渡り歩いてきたので、色々なところに色々な形式で散らばっていた。少し前にエクスポートデータの整頓は済ませていたので一応おおよそ一箇所に集まってはいたが、ほとんどがそれぞれの形式でエクスポートしたままになっているのでひとまとめに扱える状態ではなかった。
　大体はテキストエディタで開けば見れなくはないものだが、やはり専用のビューがないと見づらいし、結局は死蔵になってしまっていた。見づらいというだけで見なくなってそれで大して不都合を感じないのだから、その程度のものと言えばそれまでだが、やはりその時その時は一生懸命考えたようなことがたくさんあるし、日記の類を確認できなくなるとその期間が空白だったかのような気持ちにもなってしまうので、いつでも確認できる状態にして安心したいと前から思っていた。
　一応ある程度のコーディング能力は獲得しているのでデータの加工はもう少し前から可能だったわけだが、問題は「どこに集めるか」だ。これだと思うものがなかなかなく、それまでの放浪の経験から「このアプリケーションも結局途中で嫌になっちゃうんじゃないか」という予感があってどこにも集められずにいた。

Dynalistへの認識の変化

　これまでに何度も書いているけれど、最近はデジタルノートツールについてはCapacities＋Dynalistという形で安定している。自分が混乱しない枠組み作りもできて、どの情報についても「これはここだな」とあるべき場所を迷いなく判定できるようになった。
　特にDynalistの位置づけが定まったのが大きいが、実のところ最も重要なのはCapacitiesとの棲み分け方やアウトライナーというものの理解の進み方ではない。やや大きいテーマなので別途記事を書くけれども、Dynalistが私にとってこれほど必要不可欠になったのは以下の理由がある。

• APIがあること
• ノート欄があること
• WebアプリなのでChrome拡張機能で干渉できること

　これらは「アウトライナーの特徴」ではない。Dynalistがたまたま備えている仕組み・特徴であって、私がDynalistを使ってやっていることをアウトライナーの良さとして語ることはできない。
　Dynalistを使い始めたのはそれなりに昔のことだが、その当時はプログラミングのプの字もわからずAPIだの拡張機能開発だのはすごいプログラマのためのものと思っていて、ノート欄については存在意義がわからなかった。ノート欄にごてごてと書いたらそのノードを操作しづらくなるからだ。なので今感じているような自由というのは昔は想像もできなかったし、そのために一時はDynalistから離れることにもなった。
　かつては「紙に書いたら動かせないが、デジタルなら動かせる」程度にしかDynalistの良さをわかっていなかったのが、今は「各ノードのデータは自由自在に利用できる」という認識を強く持ち、その変化によって、Dynalistを情報の置き場として捉えることに納得できるようになった。

実行

　そのような前提のもと、これまでに発生した文字情報を全てまとめてしまう場としてDynalistを使ってもいいんじゃないかと思えるようになり、ここ半月ばかりでそれを実行に移した。
　各ツールのエクスポートデータの形式に合わせてそれぞれOPMLファイルを生成するコードを書き、そのOPMLをDynalist上でインポートして取り込んでいった。XMLの知識がまだあまりないために謎のエラーに苦しめられたが、どのデータについてもどうにかOPMLに変換できた。
　インポートしたツール類は以下のものたちだ。

• Diaro
• UniversalDiary
• POPdiary
• Clipto
• ミミノート
• XTMemo
• CatMemoNote
• ハルナアウトライン 18ファイル
• Transno
• Logseq
• Obsidian 4Vault
• Cosense（Scrapbox）9プロジェクト
• 階層付きテキストファイル 2ファイル
• 自作ツール 4種

　一部は既に自作ツールに取り込んであったものなので、これら全種類のコードを書いたわけではない。データの出自を辿るとこれらのものが集約されたことになる（厳密にはもっと多い気がする）。
　これだけの散らかり具合ではデータの活用も何もあったもんじゃないが、ようやくひとつの規格で統一することができ、探し出すのも極めて容易になった。JSONなどに対してただテキスト検索しても結果は見づらいが、Dynalistのノード検索ならとても視認性が良い。
　一番スッキリしたのは日記類の集約だ。ツールを乗り換える度に日記の場が移ってしまい、データの加工技術もなかった時は引っ越しは容易でなく（そもそも不可能なこともある）、散らばるだけ散らばった状態になっていた。今回の整理で2014年頃から2024年8月までのほとんどがひとつのアウトラインに集まった。（2024年8月以降はCapacitiesにある。）

　デジタルツールに書き留めた日記やメモの類がこのように一箇所に集まったことは未だ嘗てない。なので私の中では人生史上で割とすごい出来事である。

　毎年の年末に倉下忠憲さんが発行なさっている『ライフハックの道具箱』の2024年版が発売されました。

• 『ライフハックの道具箱2024』が発売されました | R-style

　私も参加しております。「ネットワークファーミングツール」セクションのCapacitiesの項です。コンパクトにまとめるのに骨が折れましたが、気合を入れて書いたのでCapacitiesのことが気になっている方はお読みいただけたら嬉しいです。Kindle Unlimitedで読めます。
　私も他の方の記事はこれから読むところなので楽しみです。

　さて、告知だけというのも当サイトの記事としては寂しいかなと思ったので、Capacitiesの使用風景の紹介を兼ねてこの原稿を書く際に使ったツールの話でも書いておこうかと思います。
　原稿を書くとなってまず最初にしたことは、CapacitiesでProjectオブジェクトを用意することです。タイトルは「ライフハックの道具箱2024にCapacitiesの記事を寄稿する」でした。そのままですね。（厳密には「寄稿」ではないのですがそれはさておき。）

　やるぞ～という気持ちを表すものとしてアイコンに炎を設定しました。そしてこのページをピン留めしておきます。
　このページには、締切等の決まり事や字数の目安などのメモ、どういう工程で何をするかの検討、やり取りのログといったことを書き込んでいきました。内容そのもの以外の情報を全部ここで扱うという形です。
　作業を進める時はデイリーノートにトグル項目としてこのページへのリンクを貼り、下位項目に個別のToDoやログを記述します。するとこのページのバックリンク欄に作業ログが並びます。

　次に、Dynalistに専用のファイルを作りました。ファイル名は「ライフハックの道具箱2024」です。ここでは内容に関わることを扱います。

　公式の情報、他の方が書かれた記事のリンク、自分が思うツールの特徴、文章の構成などを全部ここに集約しました。本文もここで書きます。
　自作のChrome拡張機能によってDynalistで文字数カウントできるようにしてあり、普段からごく普通のテキストエディタのようにしてDynalistを使っています。あちこちに情報を分散させずに済むので取り扱いが楽です。（Chrome拡張機能を自分で作って活用する（Dynalist））
　また、今回書くにあたって公式ドキュメントとブログはほぼ全部に目を通しました。といっても私は英語をすらすらとは読めないので、ChatGPTの力を借りました。元の英文を全部Dynalist内にコピーし、ChatGPTによる訳をノート欄にペーストし、英文と和訳を照らして誤訳や省略などがないか気をつけながら読んでいきます。ChatGPTのおかげでドキュメントを読むだけなら英語が不自由でもほとんど困らなくなりました。ありがたいことです。
　本文はMarkdown書式で書いていて、書いたものはGitHub Gistで確認しました（もちろんSecret設定です）。バージョン管理ができること、コメントをつけられることから、原稿を扱う形式として便利だと思ったからです。

　原稿提出後はその後のやり取りのログをCapacitiesに記録し、全部終わってからCapacitiesとDynalistの内容を整理して、後で見て一目瞭然な形に整えてこの件については完了ということになりました。
　書くにあたっていつもの数倍神経を使いはしましたが、短い記事を一本提出するだけなので、そんなにきっちりしなくてもできたことではあります。しかし敢えて雑にやる意味もないので、意識的に情報をきちんと整理しながらやりました。元々几帳面な質ではなく油断するとすぐ雑然とするので「どうせなら綺麗にやっていこう」と意識しています。
　Capacitiesはその「どうせなら綺麗に」という気持ちを惹起してくれるので、ズボラ人間でも恰も几帳面な人かのように情報を整えられます（個人の感想かつ当社比の話です）。

　Capacitiesがメインの場となったことでノートツール環境はどうなったのか、現時点の様子を書いておこうかなと思う。

　まずCapacities以前はどうだったかというと、大体こんな感じ。

• Dynalist
  • ライフ・アウトライン（生活上で発生する事柄全般）
  • 書き物
• Cosense（Scrapbox）
  • 自分の関心に基づく情報保管庫
• Obsidian
  • 自分の必要に基づく情報保管庫
  • 規模の大きい書き物の作業場
• Notion
  • 自分以外の人と共有する情報保管庫

　ScrapboxとObsidianの使い分けについては3月時点で以下に書き留めている。（ただしそこから8月までの間に少し変化している。）

• ScrapboxとObsidianの個人的使い分け（2024年版）

　現在はこう。

• Capacities
  • ライフ・アウトライン（生活上で発生する事柄全般）
  • 自分の関心に基づく情報保管庫
  • 自分の必要に基づく情報保管庫
  • 規模の大きい書き物の作業場（本文以外）
• Dynalist
  • 書き物
• Notion
  • 自分以外の人と共有する情報保管庫

　情報の混在を嫌って場を分けていたようなものについては、Capacitiesが全てを解決してくれたので全部まとめられるようになった。Obsidianに置いていた情報は全部Capacitiesに移した。Scrapboxの中身を移すのは現実的ではないので、基本的に既存のデータはそのままにして必要を感じた時だけその都度移すことにしている。
　書き物については、Dynalistに自作のChrome拡張機能を合わせてうまくやれるように環境を整えているので、それをそのまま継続している。（Chrome拡張機能を自分で作って活用する（Dynalist））
　自作ツールはもう全然使っていない。こうだったらいいのになあと思っていたことのほとんどをCapacitiesが実現してくれているので作る必要がもうなくなってしまった。割と最近マルチウインドウのプロセス型アウトライナーを作ったりしていたが、それを重用する未来がイメージできなくなったので中断した。
　頑張って獲得したプログラミングのスキルは、自分用のChrome拡張機能を作るとかAPIを活用してデータを取得・加工するとかで発揮されているので、まあ無駄になったわけではない。
　紙のノートは最近出番が少ない。これは別にCapacitiesに役割が吸収されたということではなく、単純に紙のノートが活躍するようなことをたまたましていないというだけ。まあ「どこでもいい」種のメモを紙に書くかデジタルツールに打ち込むかということはあって、そのブームが今はデジタルツールの方に来ている状態ではある。

　Capacitiesによってツールの使い分けが減り、情報管理がだいぶ単純になった。
　Capacitiesには既に何百かのページができているが、それでもScrapboxの蓄積と比べれば全然なので、このままCapacitiesに情報が増えて使い勝手がどうなるかはまだ未知数だ。現時点の感触ではデータが増え続けても問題は起こらないような気がしているが、果たしてどうか今後わかってくるだろう。
　

　久々にDynalistのカスタマイズの話。

　MarkdownやScrapboxを常用していると、Dynalistでも似たような形で書式が反映されればいいのに、と思うことがある。例えば引用やコードブロック。
　Dynalistでは各ノードに色を設定でき、そうするとノードのHTML要素にclassが適用されるので、CSSをいじれば「紫色設定は引用書式ということにする」みたいなことも可能である。最初はそうやっていた。
　しかしこのやり方だとその情報はDynalist上でしか有効でないし、未来永劫同じルールで運用しなければならなくなる。色の設定も微妙に手間だ。だんだん苦しくなってきたので、別のやり方を考えることにした。

　コピペで他のツールと行き来できた方が良いので、例えば引用は「> 」を頭に付けることで引用判定されるといい。つまり、本文が「> 」で始まるノードに引用スタイルを適用したclassを付けたい。
　これはDynalistの機能ではできない操作なので、自分でスクリプトを書いて実行する。具体的にはChrome拡張機能を作る。あるいはブックマークレットにしてロード時に手動で実行する。
　Chrome拡張機能開発については以前Chrome拡張機能を自分で作って活用する（Dynalist）でちょっと書いた。

　class付与のタイミングをイベントで判定するのは面倒な気がしたので、setIntervalを使っている（試していないがblur時とかでもいいかも）。実際に使っているコードの一部がこちら。

// styleを記述しやすいようにclassを整理しておく  
const IS_COMMENT = 'is-comment';  
const IS_QUOTE = 'is-quote';  
const IS_CODE = 'is-code';  
const IS_BODY = 'is-body';  
  
// スタイルを記述する（ここでは引用のみ例示）  
const style = document.body.appendChild(document.createElement('style'));  
style.textContent = `  
.${IS_QUOTE} > .Node-self .Node-renderedContent {  
    background-color: #f0f0f0;  
    padding: 2px 4px;  
    font-size: 12px;  
    border: 1px solid #888;  
}  
`;  
  
// 条件を整理しておく（今回は本文が何で始まるかで判定するものとする）  
const condition = [  
    { start: '🖋', className: IS_BODY },  
    { start: '//', className: IS_COMMENT },  
    { start: '> ', className: IS_QUOTE },  
    { start: 'Code:', className: IS_CODE }  
]  
  
// 毎秒各条件をチェックしてclassを付け外し  
setInterval(() => {  
    const lines = document.querySelectorAll('.node-line.Node-renderedContent');  
    lines.forEach(elm => {  
        condition.forEach(({ start, className }) => {  
            if (elm.textContent.startsWith(start)) {  
                elm.closest('.Node').classList.add(className);  
            } else {  
                elm.closest('.Node').classList.remove(className);  
            }  
        })  
    })  
}, 1000);  

　ここでは「何で始まるか」だけで判定しているが、何を含むかや何で終わるかで判定しても良い。こうすると本文次第でスタイルを変更できるので、Dynalist固有のメタデータに依存することもなく、また条件の数も無制限に設定できる。（とはいえあんまり複雑にすると後で嫌になってくる可能性がある。意味が自明なルールに限った方が健康的だろう。）
　現在実際に設定しているのはコード例に書いた四種だけで、それぞれ以下のような意味と見た目になっている。

（書き忘れたけどコードブロック風スタイルはフォントもコード用に変更している。）

　Webブラウザの仕組みに頼ったものなのでスマホアプリでは反映されないのが難点だが、今現在はほとんどPCで編集しているのでPCだけでも効果は高い。
　ちなみにこのようにしてからもう半年近く経っているけれど、今のところ飽きはないし便利に思っている。