t_wの輪郭

Logseq文章のレイアウトが決まってから結論が出る理想論Twitterアカウント凍結解除のために弁護士費用121,000円をかけた事例言葉という知識認知能力Tak., 千葉雅也『書くための名前のない技術 case 3 千葉雅也さん』倉下 忠憲「検索結果から操作できないじゃないですか、だから、意味ない」メモの集合OSS稀有な事例知識の保証独り相撲自分の肩の上に立つWorkflowyメタバース遠い桃源郷発想メモを貯めてもどこにも行きつかない仮説分散型アプリ値上げ過剰な値上げサービス終了アトミック・シンキング個人知識管理サービスで整理された脳によって出力される書籍知識を蒸留ほんまか個人知識管理サービスは長時間使わないと真価が分からないアカウント凍結友達は可搬あくまでエンターテイメント書籍文章力文章が長くなりすぎて力尽きてきたウェブブラウザアウトライナー『ガンダーラ』差別化Tak.「ノートツールなんてそれこそ使い込まないと、ある程度の期間使わないと分からない」『第百十五回:Tak.さんとノート術と執筆術の違いについて』実現困難サービス停止相応の労力知識が人質国立国会図書館dAppsMarkdown人力で書き写す個人知識管理サービス個人知識管理サービスの相互運用性Wordプロダクト型のアウトライナー相互運用同質化個人知識管理ツールプロセス型のアウトライナーメタバースの相互運用性知識の寿命空中戦人質あれDynalistあれ書籍化Tak.うちあわせCast倉下 忠憲

あれ

2022/11/12 11:39:00

Tak.ノートツールなんてそれこそ使い込まないと、ある程度の期間使わないと分からない」
…………
Tak.Logseqって言ってる人、多分多くは去年はObsidianってきっと言ってたよな。そのうちの何割はその前の年はRoam Researchって言ってたよな。でもいいんですけど、ただやっぱり3年4年使わないと分からないことがある。」
倉下 忠憲「でもそれってある種の賭けじゃないですか。このツールで行く。それ以外は使わへん。みたいな。」

 次々に新しいメモアプリ(個人知識管理サービス)が生まれてきている。それらが出る度にどんどんに乗り換えていく、といった状況を見ていると、個人知識管理サービスの相互運用性が問題になるんじゃないかと思う。

 流行りのメタバースではメタバースの相互運用性が議論に上がるが、個人知識管理サービスの方がよほど影響が大きい。メタバースはあくまでエンターテイメントで、そこでできた友達は可搬ほんまか?)だが、膨大な記述を伴う知識を別サービスに人力で書き写すのは並大抵の労力ではない。

 もし記述した知識を個人知識管理サービス間で相互に取り込みができないならば、知識が人質になる。サービスの過剰な値上げに対して対抗できないし、サービス終了に対しても脆弱だ。アカウント凍結に対しても不安がある。
 前例を上げれば、Twitterアカウント凍結解除のために弁護士費用121,000円をかけた事例すらある。それだけ、長期間にわたって書いてきた文章は、書いた本人にとって価値を持つと言えるし、人質としての適性が高いともいえる。

 また、記述した知識を個人知識管理サービス間で取り込むことができれば、「個人知識管理サービスは長時間使わないと真価が分からない」という問題も解決できるかもしれない。他の個人知識管理サービスを使い込んだ後に、新しい個人知識管理サービスに知識を取り込めば、あたかも使い込んだかのような環境が構築される。

 
 しかし、上で上げた話は自分の肩の上に立つようなものだ。
 ある個人知識管理サービスで記述した知識を、ほかの個人知識管理サービスに取り込んだ場合に、それが適合することは少ないと感じる。
 例えば、Workflowyで書いた文章をScrapboxに一切の加工なしに取り込んだとしても、何ら機能するものではない。お互いの良さをつぶし合うだけの結果になる。Workflowyで書いた文章の量にもよるだろうが、なじませるには書き換えが必要になり、相応の労力を要するだろう。
 これについてもうちあわせCastにて議論されている。アウトライナーを使って書かれたと思われるTak.氏のブログをScrapboxに取り込んだ結果、何か違和感のあるものになったという話がされていた。

Tak.アウトライナー系のコンテンツを全部Scrapboxに退避させた。退避というのはScrapboxに移した」
……
Tak.「ある程度構造を持った状態のものをScrapboxに入れた時に、入れる前よりも辿っていくのが難しくなった」
……
Tak.「もともとのコンテンツのつくりがScrapboxっぽくない。それを無理矢理分割してScrapboxに入れているところがそもそも読みやすく感じない理由」
……
倉下 忠憲「このHappy OutliningとTak.さんの本館、どっちが魅力的かというと本館の方なんですけど、最初にあのページを見た時のワクワク感はあんまりこのプロジェクトには感じないですよね」
Tak.「Scrapboxって育てていくものだと思うんですよね。ここにはScrapboxの中で育ったコンテンツじゃないんですよ。違う所で育ったコンテンツを小分けにして入れているだけ。そういうものってScrapboxの魅力が感じられないというか」

 私個人の実体験としても、デライトで書いた文章をScrapboxにコピーしておくようなことを試したこともあったが、どうにも違和感が出てしまってやめてしまった。デライトでリンクしている部分も再現してコピーしたため、機能面では適合しやすく思われたのだが、それでもだめだった。

 まずもって文章というのは妙にセンシティブというか、些細なことによって印象が左右される。フォント、上下左右の文字の空間の取り方、それを取り囲む装飾などなどによって微妙に、場合によっては劇的に印象が変わってしまう。機能の些細な違いによっても適合しないのは当然のように思える。よしんば、データの構造すら違うものをほかのサービスに移植するのは、他の動物の臓器を人間に移植しようとするようなものなのかもしれない。

 『書くための名前のない技術 case 3 千葉雅也さん』にて千葉雅也氏は、文章のレイアウトが決まってやっと文章の結論が出ると言う。見た目や機能性だけの問題ではなく、そこから得られる結論すら、ツールによって変わってもおかしなことではない。


アウトライナーMarkdownFediverseに見る相互運用という理想論の実現例。

 個人知識管理サービス間で違うからこそ良いという見方もできる。
 再びTak.氏の事例になるが、氏が書籍を書く際、アウトライナー(おそらくDynalist?)からMicrosoftのWordへ文章を移植する工程があるらしい。Tak.氏の定義によればDynalistはプロセス型のアウトライナーであり、Wordはプロダクト型のアウトライナーとなる。つまりお互いに異なる性質を持っている。プロセス型のアウトライナーからプロダクト型のアウトライナーへ、書籍を書く途中でバトンタッチする工程を踏むことで、両者の良いところを発揮させている。しかし、そのバトンタッチの工程においてはかなりの労力が必要になる。なぜなら、両者の間でデータの構造が異なるため、単純なコピペでは構造が引き継がれないためだ。
 この事例から分かることは、個人知識管理サービス間の相性によって、その機能が異なっていたとしても良さを発揮できる可能性があるということだ。

 また、不完全ながら、Markdown形式による個人知識管理サービスの相互運用が可能な事例も存在する。LogseqとObsidianは互いにMarkdownを採用しており、さらに手元のPC内でファイルを残す形となっている。特殊な条件が整っていれば、個人知識管理サービスの滑らかな相互運用が可能となる可能性がある。

 相互運用の事例としてFediverseも紹介したい。Fediverseでは、異なる種類のマイクロブログサービスが相互に通信しあい、異なるサーバーで異なるソフトウェアが動く状況下であるにもかかわらず、その間でコミュニケーションが実現されている。サーバーの間では、ActivityPubを始めとした特定のプロトコルによって通信されている。
 
 上記3つの事例からは、データや通信の規格化が相互運用の実現に必要であることが示される。

 しかし、個人知識管理サービスというものがまだ一般に認知されておらず、どういったものだという認識も各々で異なっている。また、個人的に個人知識管理サービスというものはまだ、機能面において成長段階だと感じる。今この段階で規格化してしまう事は、その成長の重しとなりえるのではないかと危惧する。ただ、遠い未来のこととして規格化について議論を進め、共通認識を育むことは、個人知識管理サービスの相互の成長にとって有益となるはずだ。


ウェブブラウザという事例を見れば完全な(理想的な)相互運用は難しい。遠い桃源郷ガンダーラ ガンダーラ

 「IE!!!奴は死んだ!!!ウェブブラウザ相互運用黄金時代!!!」とはならなかった。新たな爪弾き者が見出されてしまっている。1990年にウェブブラウザというものができて長い時間がたっているにもかかわらず、完全な(理想的な)相互運用というものは実現されていない。
 これ理由として考えられるのは、企業がソフトウェアを開発している以上、同質化する動きがあるのと同様に、差別化する動きがあるためだ。
 つまり、文書を扱うソフトウェア同士の完全な(理想的な)相互運用というものが、性質としては実現困難であることが示されている。


手元のPCや、自分が管理するサーバで、個人知識管理サービスを運用したい。OSSとして。

 ここで視点を変えて、知識の存続を保証するにあたって、個人知識管理サービスの相互運用性を諦め、一つの個人知識管理サービスでやっていく方法を模索したい。
 もし、個人知識管理サービス(もといツール)が手元のPCで動いて、それがOSSだとどうだろう。サービスの値上げやサービスの終了におびえる必要は一旦なくなる。もしソフトウェアが古くなってきたとしても、自分で改修していくことができる。
 Logseqは上記の条件を満たす稀有な事例だ。

 ひとまず自分が生きている間の知識の保証は実現されたと言える。では、自分が死んだ後はどうだろうか?


アナログへの回帰・アナログへの蓄積

 個人知識管理ツールが手元のPCで動くことによって、生きているうちは知識が保証されることを上述した。しかし、次に、そこで記述した文章がそのままではどこにも行きつかないという問題が生じる。特に記述した人が死んだ後に文章が消え去っていくのは、記述者にとっても、ほかの人にとっても、余りに惜しい。どうにかして、死ぬ前に個人知識管理ツールで書いた文章を他の人に届け、遺せないだろうか。
 個人知識管理ツールを個人のPCで動かす以上、もはや機能の問題ではなくなってしまう。もしかしたら将来的に、文章を共有可能なdApps分散型アプリ)が出現するかもしれないが、現時点では、私の観測範囲では、そのようなものは開発されていない(事例があれば知りたい)。
 個人知識管理サービスで書いた内容を書籍化するのが現実的な解なのかもしれない。
 文章を書籍化し、一般に流通することで、多くの人に知識が届けられるうえに、国立国会図書館に所蔵されることによって長期にわたって保存される。


個人知識管理サービスでメモを貯めていって、書籍にまで成長するのか

 ただメモを貯めてもどこにも行き着かない(書籍にまで育たない)という仮説『第百十五回:Tak.さんとノート術と執筆術の違いについて』Tak.氏・倉下 忠憲氏の両者の対話によって示された。
 ただ漠然と、メモを書き溜めさえすれば書籍になるかというとそうはいかないだろうという感触が私もある。ではどうすればメモを書籍化できるだろうか。

 メモを書籍化するにあたって、ある種の題目に沿ったメモを一か所に集める必要がある。つまり、特定の属性を持ったメモの集合を作る必要がある。
 検索は、簡単に「特定の属性を持ったメモの集合」を作る手段の一つである。

 メモを書籍化することを目的としてメモを検索することを考えると、メモを検索結果から操作できると、書籍化のための操作がしやすい。
 検索結果からメモを、編集し、並び替え、検索結果から削除する。そういったことができれば、検索によって作られたメモの集合を書籍に近づけることが可能だ。

 検索結果からの操作についても、うちあわせCastでは言及されている。

 タグで検索して見つかりましたで終わりって感じがするんですよね。検索結果って、見つけられますけど、検索結果から操作できないじゃないですか。だから、案外意味ないんですよね。
 知的操作ってことを考えた時に#ほげほげがついているものを、集めて、この項目化に再配置するってことができるのであればまたちょっと違うかもしれない


 検索結果を操作することを考えた時、デライト検索機能である全知検索特異だ。
 輪郭メモ)の表題(知名)と、検索語の完全一致により、輪郭を探し出す全知検索において、輪郭の作成は検索結果の事前作成に他ならない。「この検索語で検索されたら、この輪郭の集合を表示してほしい」ということを事前に作りこむことになる。
 また、デライトでは、検索画面から輪郭を編集し、引き入れ・引き入れられを変更できるため、検索結果を検索された後に編集することができる。

 検索は集合を作る輪郭も集合を作る。この類似性相性の良さは決して偶然ではなく設計された物だろう。よく考えられている。


どれだけのメモを個人知識管理サービスで溜めればよいか

 多くの著作を残したことで有名なニクラス・ルーマンは9万枚のカードを書いたという事例を取れば、多くとも9万のメモがあれば十分だと考えられる。
 この9万という数にたじろぐかも知れないが、9万のメモはデジタルだとうっかり超えてしまえる数だ。ツイートはメモだとするならば、10万ツイートする人は少なくない。Twitterと類似したサービスのマストドンでは、マストドンチュートリアルは10万投稿とか言われている。10万投稿が簡単な数ではないことを使った冗談の類だが、それでも不可能な数ではないことを示している。

 ほかの事例を見れば、メモを書籍化するには数万のメモは不要だ。1万未満のメモでも書籍化が可能である。
 ツイートが書籍化した事例としてTestosterone氏がおり、『超筋トレが最強のソリューションである 筋肉が人生を変える超科学的な理由』は、彼がTwitterで投稿している内容と類似した内容が含まれる。そのTestosterone氏は2022年10月30日時点ではTwitterにて6,300 件の投稿をしている。


どんなメモを個人知識管理サービスで溜めればよいか

ノートはできるだけ抽象的に書く

アトミック・ノートも、自分の知識、アイデア、考えをできるだけ「汎用性が高いノート」としてまとめることを目指します。書いた文章は、できるだけ「普通」の、抽象的で汎用的な文章にする。そうすることで、書いた文章は様々な場面で応用しやすくなります。

 文章を抽象的に書くか、具体的に書くかという切り口は興味深い。

 筆者の五藤隆介氏は「文章を抽象的で汎用的にすると、多くの場面で応用しやすい」主張している(と私は読み取った)。この主張の対偶を取れば「応用しずらい文章は、具体的な文章である」となる。この主張とは異なる、「具体的な文章も、多くの場面で応用しやすい」ということを主張したい。

 具体的な文章、つまり出来事についてかかれた文章は後から意味付けがしやすい。したがって、具体的な文章は応用が利き、使いまわしができる。想像もつかない使われ方ができるため、具体的な文章を書き残すことには大いに効果がある。
 実例を上げれば、『アトミック・シンキング: 書いて考える、ノートと思考の整理術』の中で、携帯キャリアが牛丼が無料になるクーポンを配布していたことについて記載されている。

 実際に、とある携帯電話キャリアを契約していると牛丼が一杯無料になるというキャンペーンがありました。

 この出来事が「ノートと思考の整理術」と結びつくとは、誰も想像できないだろう。


 また、アトミック・シンキングでは「「事実」と「それ以外」を分けて書く」ことを勧めているが、こちらについては同意するところである。
 事実とそれ以外、すなわち具体的なことについて書いた文章と、抽象的なことを書いた文章とを分けることによって、それぞれが書籍の素材として使い回しがしやすくなる。

なぜ具体的なことについて書いた文章と、抽象的なことを書いた文章を分けると使い回しがしやすくなる??要検討。


最後に(まとめ)

 本文章では「個人知識管理サービスが出現しても書籍化が必要である」こと、「個人知識管理サービスに書いたメモから書籍化するにあたって、個人知識管理サービスに検索から編集する機能があれば書籍化の助けになり、具体的なことを書いたメモと抽象的なことを書いたメモを分ければ使い回し(書籍化)が容易になる」ことを示した。

 今後の課題としては、本文章を書いたt_w本人が書籍をまだ書いていないために、上記の機能や手法の有効性が実証されておらず、信用性に欠けることが挙げられる。

あれ

2022/10/26 14:53:00

 800字程度の税の作文すら書けなかったのに、『個人知識管理サービスの相互運用は実現され得るか(答. 完璧に相互運用するのは難しい)』みたいな長文を書けるようになったのは個人知識管理サービスを始めとしたツールに滅茶苦茶助けられている感じがある。そもそもパソコンじゃないとこんなの書けない。
 個人知識管理サービスは文章を書くための補助輪だと思っていたが、補助輪で爆走している状態になってきた。いや、もう補助輪じゃないな。動力輪という方がふさわしい。個人知識管理サービスは文章のエンジンといっても良い。
 文章が書けなかった人間が個人知識管理サービスを使うのは、ママチャリにF1のエンジンを積むようなものだ。小学生がF1を運転するようなものとも言える。どこかに無理が来ないか不安になる。炎上しないか怖い。書く文章メンタルが伴ってない。

Scrapboxをきれいな見た目にするときれいな文章しか書けなくなる『Scrapbox情報整理術』あれ文輪の公開設定『Scrapboxの面白さはなぜ伝わりづらいか』ScrapboxのエレベーターピッチなぜScrapboxとデライトは似ていると感じるのかデライトとScrapboxの違うところPupetteerScrapboxのインポート機能が使えるかもしれない いいねしたツイートを取得→jsonに変換→Scrapboxでインポート公開さえしなければいいので、いいねしたツイートをIFTTTからクラウドメモツールに飛ばせば良さそう Workflowyとか、Dynalistとか Pupetteerで無理やりScrapboxに送るよりも楽に実現できるはず。輪郭輪郭Scrapboxだけ検索するWebサービスあれ『Scrapboxは他人がカードを「くって」くれる』Scrapboxはページタイトルが変わってもリンクが切れないScrapboxの哲学あれ時間拘束する雑談は非同期的なコミュニケーションに置き換わっていくあれあれあれあれ書き検索Scrapboxには束ねて読む手段がないあれあれScrapboxプロジェクトScrapboxで何かを記憶したり理解するのは難しい井戸端Scrapboxは座標がないあれ基本的にScrapboxは独自記法を気にしなくても使えるようになっている2022年6月3日仕事あれ『ナレッジ共有サービス「Scrapbox」総ページ数1,000万突破』『まだscrapboxの先に何かある』あれあれScrapboxとデライトの比較量をこなさないと、Scrapboxの良さが見えてこない Scrapboxの総ページ数は900万でWikipediaの6.9倍Wikipedia の記事数と Scrapbox のページ数を比較した文章Scrapboxコミュニティのmemberを増やすためには何が必要なのか?ScrapboxファンがScrapboxを作っている会社に入ると楽しいNotaのScrapboxプロジェクトは2万7千ページ「資料に突撃なるほど、声を阻害しない割り込みだ」already exists. Merge PagesデライトからScrapboxへ転記するスクリプト倉下 忠憲「Scrapboxは座標がない」『Scrapboxでの考え方』一行毎に編集モードと閲覧モードを切り替える欠点『ScrapboxでKJ法』あれ「already exists. Merge Pages」は強すぎるPKM関連のSimilarWebデータ人様のScrapboxプロジェクトを読み漁ってたら脳みそ使いすぎて鼻血でそうあれ2 hop linkScrapboxとデライトの似ているところScrapboxの10000ページの壁あれScrapbox利用者のデライトに対する反応Scrapboxの複数人運用大変そうScrapboxは記法の入力補助が豊かなのもGoodScrapbox記法あれScrapboxとiPadのGboardが相性が悪いあれ『Re:Scrapboxは「ブログ」なのか?』Helpfeelあれ『t_wの輪郭』の、輪郭の順番を選べるようにしたいScrapbox導入のために、Scrapboxのエレベーターピッチを作成したいScrapboxの提案書を作りたいScrapboxをデライト風にCSSを変更Scrapbox発想術ただ、WorkflowyやDynalistだと保存したツイート同士が不意に結び付くことを期待できない。 Scrapboxだと、同じユーザだったり、話題だったりが勝手に結びついてくれる。自分で文章を書いてる途中に出てきてくれるのも助かる。反応用輪郭の小なり記号(<)の意味「(Scrapboxを)数百人で使ってる例はあったはず」Scrapboxのリダイレクト機能Scrapboxの総利用者数は23万人あれScrapboxのページ数の遷移あれScrapboxでは箇条書きが推奨されている認知科学者が開発したHookというアプリとScrapboxの相性が良いPCからTwitterを見ているときは、ブックマークレットを使ってScrapboxへ転送するのでそこまで問題じゃない。問題になるのはスマホで見ているとき。Scrapboxはちゃんと儲かっている編集モードと閲覧モードが切り替わる欠点あれ『Scrapboxを書く敷居を下げる』tweetスマホから使うのに丁度いい大きさあれScrapboxの提案書infoboxScrapboxの遠隔実在感ScrapboxのデータをObsidianに移植発表で表示しているScrapboxのページがリアルタイムで編集されていてヒヤヒヤする

KNS雑記

2023/3/5 21:40:00

KNSとは何か

 knowledge networking serviceの略であり、個人知識管理サービスSNSとが融合したサービスとなっている。SNSのように気軽に投稿できつつも、その投稿によって表現された知識が高度に管理可能なサービス。宇田川浩行氏によれば、「SNSの次」に来るサービス形態である。
 この文章では、このKNSについて雑多に書く。

KNSはすでに存在する

 KNSとして作られたデライト、Scrapboxの一部プロジェクト(井戸端アープラノート)など、すでにKNSは誕生している。

 井戸端やアープラノートに関しては、WikiであるScrapboxチャット的に用いることで知的交流を成している。

KNSの流行らなさ

 KNSは自己対話による面白さがある。故にKNSは他者を必要としない。必要とする度合いが低い。そのために、他の人を呼び込むことが少なくなり、広まるまでに時間がかかる。

KNSは「まとめ」と「言及」で駆動する

 KNSを通して、各種ウェブページをまとめ、さらにそれらに言及していくような使われ方が進んでいく。はてなブックマークに成り代わりTogetterに成り代わりSNSに成り代わる。そうして段階的に社会に浸透していく。
 そうした「外部サービス」としてKNSを見たとき、ウィジェット化が有用な機能として挙げられるだろう。KNSでまとめと言及をし、ウェブページの方でさらにKNS上のそれらが表示されれば、相互の流入が期待できる。
 そうして代替として普及しつつも、KNSの真価に触れた人にとっては、他では代替不可能なものとして確立されていく。

SNSの限界とその拡張、SNSのKNS化

 生物が単純な形態から複雑な形態へと進化したように、SNS上で交わされる話題の複雑化は当然のことながら生じる。
 Twitterではそれに対応するために、140字から280文字文字数制限を緩和した。ユーザーも自己リプライによって話題の複雑化に対処しようとしている。
 SNSのKNS化が進んでいる。タグや外部サービスによってまとめる機能が付与されていっている。つまり後付のまとめ機能でなんとかやりくりしている状態だ。
 しかし、そのやりくりも限界がある。抜本的な作り直しが必要になるときが来る。その時、既存のKNSが参考にされ、さらにSNSのKNS化が加速する。

2022年11月16日

  • ja.wikipedia.org: 135.4M (new)
  • dlt.kitetu.com: < 5K (+0%)
  • workflowy.com: 2.4M (+4%)
  • scrapbox.io: 2.2M (-4%)
  • notion.so: 141.8M (+20%)
  • roamresearch.com: 976.5K (-20%)
  • dynalist.io: 1.2M (-8%)
  • keep.google.com: 191.3M (+4%)
  • obsidian.md: 4.2M (+0%)
  • evernote.com: 27.9M (-3%)
  • docs.craft.do: 176.0K (+16%)

2022年6月16日の合計訪問者数

Evernoteが少し下がって(0.9倍)、Obsidianが少し伸びた(1.2倍)。
Craftが1.6倍に伸びている。新興メモアプリは伸びやすいのかもしれない。
Similarwebの最小表示訪問者数が変化して、5000からになっている。デライトの訪問者数が5000以下で寂しい。なかなか伸びないものだ。

合計訪問数の一覧

  • dlt.kitetu.com: < 5K
  • workflowy.com: 2.3M
  • scrapbox.io: 2.3M
  • notion.so: 118.2M
  • roamresearch.com: 1.2M
  • dynalist.io: 1.3M
  • keep.google.com: 184.3M
  • obsidian.md: 4.2M
  • evernote.com: 28.7M
  • docs.craft.do: 151.4K

2022年3月7日の合計訪問者数

先月から変化がない。四半期単位で見るぐらいがいいかもしれない。
Craftを追加してみた。

合計訪問数の一覧

  • dlt.kitetu.com: < 50K
  • workflowy.com: 2.4M
  • scrapbox.io: 2.3M
  • notion.so: 119.3M
  • roamresearch.com: 1.7M
  • dynalist.io: 1.1M
  • keep.google.com: 190.1M
  • obsidian.md: 3.4M
  • evernote.com: 33.1M
  • docs.craft.do: 93.7K

2022年2月16日の合計訪問数

 新興の中ではNotionの多さが目立つ。Notionはどんな施作を打ったらここまで伸びるのだろうか。Google Keepはさすがの知名度といったところだろうか。
 デライトは描出公開原則があるにもかかわらず少ない。コンテンツの増加とともに検索流入なども増えるだろうからこれから伸びるだろう。


合計訪問数の一覧

  • dlt.kitetu.com: < 50K
  • workflowy.com: 2.4M
  • scrapbox.io: 2.3M
  • notion.so: 119.3M
  • roamresearch.com: 1.7M
  • dynalist.io: 1.1M
  • keep.google.com: 190.1M
  • obsidian.md: 3.4M(2022年2月20日追加)
  • evernote.com: 33.1M(2022年2月23日追加)