Bike OutlinerとLogseq OG
2026-01-03
Written by sosuisen
Logseqについて、今後どう使ってゆこうか、場合によっては自分でアプリを作る必要もあるだろうか？ということをいろいろ考えてるなか、Bike Outlinerに触れてみると新鮮な発見があったのでノートを書いておこうと思います。
背景
えっと、Logseq自体は毎日便利に使っております。これがないと日常のことも仕事のほうでも大変困ります。しいて悩みをいえば処理が重いことで、そこは回避策を取りながらだましだまし使っています。この問題には根本的な修正が必要であるため、Logseqはデータベースを中心とする新しい仕組みへと改造が進んでいまして、今ではこのデータベース版がLogseqと呼ばれています。一方、従来通りMarkdownファイルへデータを保存する方式のLogseqは、Logseq OGと呼ばれています。（なお、問題の詳細については YUさんが順序立てて分析しておられます）。 Logseq OGのどこが好きなのか？
さて、2つのLogseqが存在することは、わたしにとってLogseq OGのどこが好きなのか？を改めて考えるきっかけとなりました。
データベース版は確かに速いんですよ。New TagとPropertyを用いたデータの整理もLogseqの志向してきたことにマッチしています。Logseqの背景にある気持ちって、たぶん、アウトラインとネットワーク構造を持ったデータ集合を構築できて、そこから強力な問い合わせ言語を用いてデータを取り出して、任意の見た目で表示できると気持ちがいい！ということだと思うんですよね。
あと、あまり表に出ないところで興味深いのは、Clojureで統一された世界観です。Logseqの開発言語はLisp方言のClojureScriptです。加えて、Logseqに採用された問い合わせ言語Datalogは、Prolog風の論理プログラミングをClojureの文法で書く言語です。Datalogの作者はClojureの生みの親と同じRich Hickeyで、Clojureの世界では広く知られた問い合わせ言語です。そして、データベース版ではついにClojureScriptでもプラグインを書けるようになりました。Emacs LispがEmacsを持続的に拡張しているように、ClojureがLogseqをノートツールあるいは個人知識管理プラットフォームとして持続的に広げてくれるかもしれない、という期待がわたしにはあります。
それはそうとして、自分がLogseq OGについて好きだったのは、やはりデータがOS標準のファイルシステムに保存されることだったかなぁ、とも思いました。OS標準であるというのはそれだけで強固な共通規格の上にあって、例えばMarkdownファイルを通常の手順で開くことのできるアプリはたくさんあります。個人的には、LogseqのPC間のデータ共有はDropbox経由で、モバイルからの利用はGitHub経由でやってきたので、ちょっとの工夫でいろいろできることを実感してきました。このデータの取り回しに関するライトな感覚を伴わなかったら、たぶんわたしの好きなLogseqではない、別のアプリなんじゃないかなぁ、とも思っています。
Bike Outlinerの面白いところ
わたしの好きなLogseq OGの特徴を挙げると、アウトライナーでオフラインファーストでファイルへ保存ということだと思います。先日、同様の特徴を持つアウトライナーに Bike があるよと倉下さんに教えて頂いたので、Bikeを使ってみることにしました。 https://gyazo.com/ef08f36cd1c09085e9fe86f2ae214cc4
（左：Bike Outlinerアプリとアウトライン。右：同じデータをVS Codeで開いたもの）
まず、アウトライン構造の観点で違いを見てゆきます、Logseqにはアウトラインが明示的にページ分割されるという特徴があります（これは公式に言及されているようRoam Researchから継承した考え方です）。この特徴にオフラインファーストの考えを組み合わせた結果、Logseq OGはページ単位でファイルを保存する方式を取っています。
一方で、Bikeはシンプルなアウトライナーに徹しています。アウトライナー／オフラインファースト／ファイルへ保存という点は同じですが、1つのファイルとして保存された1つの巨大なアウトラインを高速に処理することに力点を置いています。そして、 そうであるにも関わらず、複数のファイルで複数のアウトラインを持てるようにも作られている点が面白いと思いました。
OS標準機能への委譲
アウトライナーとしての力点の違いは、実装方式の違いにあらわれています。Logseq OGは全てのファイルをアプリが管理して、ファイルを横断する検索やページ間のリンクによるネットワーキングがアプリの機能として提供されます。一方、BikeではそれらがOS標準のファイルシステムと検索機能に任されています。Bikeはファイルを管理しません（これは先日倉下さんから教わった通りでしたが、Logseqに慣れていると最初は戸惑って何が起こっているか判りませんでした）。Windowsのメモ帳が.txtファイルを開いて編集するアプリであるように、Bikeは.bikeファイルを開いてそれを編集するアプリです。
Bikeでは、1つのアウトラインを1つのBike形式（拡張子は.bike）のファイルとして保存するのが基本です。Bike形式はHTML標準に準拠したドメイン固有言語（DSL）であるため、一般的なツールで読み書きできます。
複数の.bikeファイル間でリンクを貼る場合には、 bike:// から始まるURLで特定のファイル内の特定のRow（Bikeではアウトラインを構成する1項目をRowと呼びます）を参照するリンクを張ることができます。bike://vVQvmhCz/NSのようなカスタム URL schemeで始まるURLは、アプリ間の緩やかな連携のためよく利用されるもので、LogseqやObsidianでも同様のことができます。Bikeではリンクの全てにこの仕組みを用いますが、ノートアプリでは一般にアプリ間でリンクしたい場合にのみ用います。
ここでBikeがOS側へ機能を委ねる様子を確認しましょう。LogseqやObsidianはアプリ側で全ファイルを把握しているため、カスタム URL schemeを用いたアプリ間のリンク（いわゆるディープリンク）を簡単に処理できます。しかし、Bikeはファイルを管理しておらず、ユーザは.bikeファイルの名前や場所を自由に変更できるため、探し出すには工夫が必要となります。
Bikeの実装が独特であるのは、macOSの標準検索機能であるSpotlightのAPIを利用することで、.bikeファイルの名前や置き場所（つまりファイルパス）が変わってもディープリンクが変わらない点にあります。LogseqやObsidianでは全てのファイルパスを管理してリンクが切れないようにしていますが、BikeはこれをOS側へ委譲しています。一般に、ファイルパスに依存したリンクは切れやすいですが、Bikeでは各ファイルへ独自に与えたID（rootid）をSpotlightのインデックスとしているため、ファイルパスが変わってもIDで探せるようになっているのです。
OS側へ委譲したことによる制限としては、異なるボリューム（別のSSDなど）への移動には対応できないこと、セキュリティサンドボックスの都合で、ファイルは同じフォルダにまとめておいた方が良い、という点はあります。加えて、macOSに依存するため、Bikeを他のOSへ移植できないという制約もあります。しかし、BikeがmacOS専用アプリであるのは、OS標準の機能を前提として、アウトライナーとして必要な機能だけを磨き上げる開発ポリシーのためと考えられます。
先ほどは、データをOS標準のファイルシステムへ保存することの良さに触れました。Bikeからは、頼れるところはOS側に頼るという考えをより一層強く感じます。
Markdownであることの苦労
Logseq OGやObsidianはMarkdown形式のファイルでデータを保存します。Markdownの採用される場面は年々広がって、昨年はWindowsのメモ帳やiPhoneのメモでも対応されるようになりました。Markdownは方言の多さが課題で、大筋はCommonMarkによる標準化の試みに沿うか、デファクト的な広がりを見せるGFMが使われますが、インラインでのメタデータの記述方法にはまだ収束する気配がありません。ただ、ヘッダにメタデータを書く記法としてYAML Front Matterは広まりました。Logseqの場合、保存されるMarkdownにはブロックIDやアウトラインの折りたたみ状態（collapsed）を示す独自のインラインメタデータが含まれています。
BikeはMarkdownの取り扱いに慎重であるように見えます。開発中のBike 2.0では新たにMarkdown形式でのエクスポートも可能となっています。現状、ファイルのrootidをFront Matterとして持たせている以外のメタデータがないため、Row単位で参照するためのID情報は失われています。Markdownへ複雑なデータ構造を記録したい場合、どこまで一般的な記法から逸脱させるかは設計上の難所です。Bike 2.0は開発中のため、Markdownに対する最終的な対応がどうなるかはまだ判りません。
おわりに
以上ではLogseq OGの今後の使い方や自作アプリのあり方について検討するために、技術的な側面からBikeの特徴に触れました。Logseq OGにおけるOS標準のファイルシステムの利用に魅力を感じていたので、さらにもう一歩踏み込んだ選択肢として、BikeのようにOS側へ機能委譲する考え方もあると思いました。これはもっと一般化するとUnix哲学における《一つのことをうまくやるプログラムを書く》と等しいのかもしれません。そうすると、アウトラインをうまくやるアプリとネットワーキングをうまくやるアプリがどちらも独立しかつ開かれた存在としてあるという形も、取り得るように思われました。わたしは既にLogseqとObsidianの間でカスタム URL Schemeを使ったアプリ連携をしていることもあって、その点でもBikeのやり方にはしっくりくる点が多かったですね。
データ形式としてのMarkdownに難があることはわたしにとっても古くからの課題です。個人的には独自のインラインメタデータよりはFront Matterへ分離することを好みます。その理由として大きいのは、わたしがデータの多くをGitHubで管理しており、GitHubのMarkdownレンダラーがFront Matterを解釈できるということです。最近の思いつきとしては、URLのText fragmentsのように、アウトライン項目の同定はIDベースでなくもっと緩やかな（ページ内の全文検索的な）方法で良いかもしれないとも考えています。というのも、Logseqのようにページで分割されたアウトラインは、ページにさえIDを与えていればその先の探索はローカルなもので済むためです。