ファイルはアプリを越えるからそうした
Steph Angoの「File over app」は、デジタル情報システムにおける有望な思想を提示しています。
In the fullness of time, the files you create are more important than the tools you use to create them. Apps are ephemeral, but your files have a chance to last.
(長い目で見れば、それらを作成するために使ったツールよりも、作成したファイルの方が重要です。アプリはいつか消えてなくなりますが、ファイルには長く残る可能性があります)
まったくその通りでしょう。
実際のところは、そこまで消えたツールはたくさんありません。EvernoteもWorkFlowyもなんならDynalistさえもいまだに使えます。皆さんも、ライフハック元年（それがいつなのかはさておき）から使い続けているツールってあるんじゃないでしょうか。わりとツールの寿命って長いのです。
とは言え、自分とそのツールの相性のようなものが変わってしまうことはいつでも起こりえます。そういうときに気楽にツールを乗り換えられることが「データの所有権を持つ」ということであり、ファイルがアプリを越えている、という状態でもあるでしょう。
だとしたら、それを可能性としてでなく、現実の権能として行使していきたいところです。言い換えれば、そのような思想を支えるツールがあるならば、あっけらかんと別のツールに乗り換えることを、現実的に行えるようになりたいものです。
というわけで、Obsidianで扱っていたmdファイルのほとんどを、Textboxという自作ツールに移しました。
移行の手順
移行はものすごく簡単でした。ObsidianもTextboxも、データはmdファイルで扱っており、フロントマターの仕組みも同じです。
つまり、Obsidian用のフォルダから、Textbox用のフォルダにmdファイルを移動させるだけ。極端なことを言えば、Finderを開いて、ファイルをドラッグさせるだけで「移行」は終了です。
TextboxはNode.jsでローカルサーバーを立てて、index.htmlからフォルダーの中身を閲覧するものなので、Obsidianのような純粋なアプリとは違っていますが、使っている感じはほとんど同じ。違いは見た目をCosenseに寄せていることくらいです。
このTextboxについてもまた紹介していきますが、とりあえずローカルのmdファイルをいい感じに表示させるもので、新規作成や編集なども行えます。Obsidianでできることの一部を取り出し、Cosenseでできることをがっちゃんこして、私しか必要としていない機能をトッピングしたら、はい完成、といった具合。
生成AIの登場によって、こうした自作ツールの開発がかなり身近なものになりました（簡単とまでは言えませんが）。でもって、個人的に思うのは、ノートツールやエディタは、それぞれの人の「手さばき」に合わせたもの方がいいだろうな、ということ。データベース系はむしろ規格化が主眼なので「手さばき」という属人性から離れて検討された方がよい側面が多いと思いますが、ノートやエディタなどの「プロセスの真っ最中」を扱うツールは、使い手との関係性がけっこう大切です。
だからこそ、情報をこんな風に簡単に移動できることは嬉しいわけです。
なんだったら、このフォルダでObsidianを開けば、両方のツールを並行して使うこともできます。そのような使い方もまた、「File over app」という思想の実践ではあるでしょう。
生成AIによる拡張
というわけで、mdファイルへの賛美があるわけですが、先ほど言及した生成AIの登場によって、「プレーンテキストだけが最強」という構図が崩れていることには注目していいでしょう。
たとえばごく単純に、あるツールのデータをエクスポートして、それを自分が使うツールに変換するためのスクリプトなら生成AIがほぼ一発で書いてくれるはずです。それを実行すれば、Finderでファイルをドラッグするより簡単に移行できるかもしれません。
もっと言えば、MCPサーバーが提供されているなら、上記のような移行作業を生成AIのエージェントに任せることもできます。もともとのデータの形式がどうであれ、それが「デジタル情報」であるならば、移動は容易になりつつあるのです。
もちろん、インターネットへのアクセス、生成AIエージェントのトークン数、といった外部的な要因がからむので、純粋なテキストファイルがローカルのパソコン内に保存されているという状態とまったく同一とまでは言えません。
それでも以前よりも「単一のツールに閉じこめられている」という感覚は薄れてきているのではないかと推測します。
むしろ生成AI時代では、データがどの形式で保存されているか以上に、どの形式で「出力」できるのかがツールとして問われるようになるのかもしれません。対ユーザー向けのインターフェースとは別口のインターフェースデザインです。
OKFという提案
そんな中で、GoogleがOpen Knowledge Format（OKF）なる形式を提案しています。
LLM-wiki のように知識をmdファイルで扱う場面が増えているけども、書式が一定していないので、ここらで整えておく？ という提案です。具体的には、以下のプリンシパルがあります。
Just markdown
Just files
Just YAML frontmatter
Obsidianを使っている人であればおなじみの原理です。ファイルベースで記述はマークダウンで、メタ情報はYAML形式のフロントマターを使う。その意図は以下のように記述されています。
Anyone can produce, without an SDK
Anyone can consume, without an integration
Survives moving between systems, organizations, and tools
Lives in version control alongside the code it describes
Is readable by humans and parseable by agents: the same file, no translation layer
プレーンテキストベースなので、GitHubなどでも扱いやすいし、ある組織から別の組織に受け渡すのも簡単。さらに、人間と生成AIの両方が読める。たしかに便利そうです。
その上で、最初の二行に注目してみると、「SDKがなくても誰でも作れる」「統合しなくても誰でも使える」という点が挙がっています。この「誰でも」は、組織の内外というニュアンスもありますし、人間と生成AIを問わず、というニュアンスもあるでしょう。
ここで「インデックス」が少し問題になります。
たとえば、Obsidianを使っているなら、多くの場合他のノートへのリンクはwikiリンク形式を使っていると思います。
[[hoge]]という記法ですね。ポイントは、vault内のどの場所にあっても、このシンプルな記法が使えるということです。つまり、倉下忠憲の活動.mdが、index.mdと同じ階層にあっても、その子フォルダにあってもまったく同じように[[倉下忠憲の活動]]というリンクは機能します。
一方で、OKFが提案するリンクの形はマークダウン形式のリンクです。つまり、 [倉下忠憲の活動](倉下忠憲の活動.md) のような形式です。この場合、ファイル名は相対パスとして記述されます。つまり、rashitaというフォルダに入っているときは [倉下忠憲の活動](rashita/倉下忠憲の活動.md) となるのです。
Obsidianは賢いので、wikiリンク形式を使うかマークダウン形式を使うかは選択できます。設定を変更すれば、他のページのリンクは以下のように挿入されます。
wikiリンクを普段使いしている人間からすると明らかにこちらの方が面倒なのですが、ポイントはSDKやintegrationなしで、という部分です。
ファイルパスが付与されていない場合、ツールのアシストがないと「そのファイルがどこにあるのか」を探さなければなりません。一方で、相対パスが記述されていなら、ダイレクトにそこにアクセスすればOKなわけです。
つまり、ファイルのインデックスを参照しない、あるいは検索結果を見てからファイルを決定するという情報的統合を行わないというシチュエーションにおいては、マークダウン形式の相対パス方式が内部リンクにおいてもより効果を発揮すると言えます。
そうすると、よりラディカルにファイルをアプリから越えさせるためには、リンクはマークダウン形式で相対パスを記述する方が適していると言えるのかもしれません。もちろん、サブフォルダを作らずすべてをフラットに並べれば「探す」ことはなくなるわけですが、2000以上のファイル群を生成AIにフラットに読ませるのはおそらく合理的ではなく（人間ならなおさらです）、むしろサブフォルダをチャンクとして利用することで、構造を作るほうがよいでしょう。
とは言えこれは、あくまで「よりラディカルに」考えた場合であって、ファイルのインデックスを併用することを考慮すればwikiリンク形式でも「生成AIに使わせる」こと自体は可能です。ただそれが、自分のテリトリーを越えて使いやすいとまでは言えなくなる、というだけの話です。
ややこしいデジタルツール
アナログツールの場合、書いたらその媒体に「定着」するので、情報の移動については別の領域の検討になりました。しかし、デジタルツールはそもそもが移動可能であり、それはファイルから別のファイルというだけでなく、あるツールから別のツールへ、ある組織から別の組織へ、といった広がりを持った「移動」の概念になっています。
だから考えることがいっぱいあるわけです。
あくまで個人の用途で、それ以上に広げるつもりはない、という場合ならOKFのようなフォーマットをそこまで意識する必要はないでしょう。しかし、大きめの組織でナレッジを扱う場合なら、情報の「移動可能性」はより強く意識された方がいいかもしれません。
もちろん、どういう場合であっても、一度作成したデジタルデータは、あとから簡単に変換できます。その意味で、意識しつつも、あまり悩みすぎず、実際にやってみて感触を確かめながら調整していく、というおなじみのアプローチがよさそうです。
FlowyもなんならDynalistさえもいまだに使えます。皆さんも、ライフハック元年（それがいつなのかはさておき）から使い続けているツールってあるんじゃないでしょうか。わりとツールの寿命って長いのです。
とは言え、自分とそのツールの相性のようなものが変わってしまうことはいつでも起こりえます。そういうときに気楽にツールを乗り換えられることが「データの所有権を持つ」ということであり、ファイルがアプリを越えている、という状態でもあるでしょう。
だとしたら、それを可能性としてでなく、現実の権能として行使していきたいところです。言い換えれば、そのような思想を支えるツールがあるならば、あっけらかんと別のツールに乗り換えることを、現実的に行えるようになりたいものです。
というわけで、Obsidianで扱っていたmdファイルのほとんどを、Textboxという自作ツールに移しました。
移行の手順
移行はものすごく簡単でした。ObsidianもTextboxも、データはmdファイルで扱っており、フロントマターの仕組みも同じです。
つまり、Obsidian用のフォルダから、Textbox用のフォルダにmdファイルを移動させるだけ。極端なことを言えば、Finderを開いて、ファイルをドラッグさせるだけで「移行」は終了です。
TextboxはNode.jsでローカルサーバーを立てて、index.htmlからフォルダーの中身を閲覧するものなので、Obsidianのような純粋なアプリとは違っていますが、使っている感じはほとんど同じ。違いは見た目をCosenseに寄せていることくらいです。
このTextboxについてもまた紹介していきますが、とりあえずローカルのmdファイルをいい感じに表示させるもので、新規作成や編集なども行えます。Obsidianでできることの一部を取り出し、Cosenseでできることをがっちゃんこして、私しか必要としていない機能をトッピングしたら、はい完成、といった具合。
生成AIの登場によって、こうした自作ツールの開発がかなり身近なものになりました（簡単とまでは言えませんが）。でもって、個人的に思うのは、ノートツールやエディタは、それぞれの人の「手さばき」に合わせたもの方がいいだろうな、ということ。データベース系はむしろ規格化が主眼なので「手さばき」という属人性から離れて検討された方がよい側面が多いと思いますが、ノートやエディタなどの「プロセスの真っ最中」を扱うツールは、使い手との関係性がけっこう大切です。
だからこそ、情報をこんな風に簡単に移動できることは嬉しいわけです。
なんだったら、このフォルダでObsidianを開けば、両方のツールを並行して使うこともできます。そのような使い方もまた、「File over app」という思想の実践ではあるでしょう。
生成AIによる拡張
というわけで、mdファイルへの賛美があるわけですが、先ほど言及した生成AIの登場によって、「プレーンテキストだけが最強」という構図が崩れていることには注目していいでしょう。
たとえばごく単純に、あるツールのデータをエクスポートして、それを自分が使うツールに変換するためのスクリプトなら生成AIがほぼ一発で書いてくれるはずです。それを実行すれば、Finderでファイルをドラッグするより簡単に移行できるかもしれません。
もっと言えば、MCPサーバーが提供されているなら、上記のような移行作業を生成AIのエージェントに任せることもできます。もともとのデータの形式がどうであれ、それが「デジタル情報」であるならば、移動は容易になりつつあるのです。
もちろん、インターネットへのアクセス、生成AIエージェントのトークン数、といった外部的な要因がからむので、純粋なテキストファイルがローカルのパソコン内に保存されているという状態とまったく同一とまでは言えません。
それでも以前よりも「単一のツールに閉じこめられている」という感覚は薄れてきているのではないかと推測します。
むしろ生成AI時代では、データがどの形式で保存されているか以上に、どの形式で「出力」できるのかがツールとして問われるようになるのかもしれません。対ユーザー向けのインターフェースとは別口のインターフェースデザインです。
OKFという提案
そんな中で、GoogleがOpen Knowledge Format（OKF）なる形式を提案しています。
LLM-wiki のように知識をmdファイルで扱う場面が増えているけども、書式が一定していないので、ここらで整えておく？ という提案です。具体的には、以下のプリンシパルがあります。
Just markdown
Just files
Just YAML frontmatter
Obsidianを使っている人であればおなじみの原理です。ファイルベースで記述はマークダウンで、メタ情報はYAML形式のフロントマターを使う。その意図は以下のように記述されています。
Anyone can produce, without an SDK
Anyone can consume, without an integration
Survives moving between systems, organizations, and tools
Lives in version control alongside the code it describes
Is readable by humans and parseable by agents: the same file, no translation layer
プレーンテキストベースなので、GitHubなどでも扱いやすいし、ある組織から別の組織に受け渡すのも簡単。さらに、人間と生成AIの両方が読める。たしかに便利そうです。
その上で、最初の二行に注目してみると、「SDKがなくても誰でも作れる」「統合しなくても誰でも使える」という点が挙がっています。この「誰でも」は、組織の内外というニュアンスもありますし、人間と生成AIを問わず、というニュアンスもあるでしょう。
ここで「インデックス」が少し問題になります。
たとえば、Obsidianを使っているなら、多くの場合他のノートへのリンクはwikiリンク形式を使っていると思います。
[[hoge]]という記法ですね。ポイントは、vault内のどの場所にあっても、このシンプルな記法が使えるということです。つまり、倉下忠憲の活動.mdが、index.mdと同じ階層にあっても、その子フォルダにあってもまったく同じように[[倉下忠憲の活動]]というリンクは機能します。
一方で、OKFが提案するリンクの形はマークダウン形式のリンクです。つまり、 [倉下忠憲の活動](倉下忠憲の活動.md) のような形式です。この場合、ファイル名は相対パスとして記述されます。つまり、rashitaというフォルダに入っているときは [倉下忠憲の活動](rashita/倉下忠憲の活動.md) となるのです。
Obsidianは賢いので、wikiリンク形式を使うかマークダウン形式を使うかは選択できます。設定を変更すれば、他のページのリンクは以下のように挿入されます。
wikiリンクを普段使いしている人間からすると明らかにこちらの方が面倒なのですが、ポイントはSDKやintegrationなしで、という部分です。
ファイルパスが付与されていない場合、ツールのアシストがないと「そのファイルがどこにあるのか」を探さなければなりません。一方で、相対パスが記述されていなら、ダイレクトにそこにアクセスすればOKなわけです。
つまり、ファイルのインデックスを参照しない、あるいは検索結果を見てからファイルを決定するという情報的統合を行わないというシチュエーションにおいては、マークダウン形式の相対パス方式が内部リンクにおいてもより効果を発揮すると言えます。
そうすると、よりラディカルにファイルをアプリから越えさせるためには、リンクはマークダウン形式で相対パスを記述する方が適していると言えるのかもしれません。もちろん、サブフォルダを作らずすべてをフラットに並べれば「探す」ことはなくなるわけですが、2000以上のファイル群を生成AIにフラットに読ませるのはおそらく合理的ではなく（人間ならなおさらです）、むしろサブフォルダをチャンクとして利用することで、構造を作るほうがよいでしょう。
とは言えこれは、あくまで「よりラディカルに」考えた場合であって、ファイルのインデックスを併用することを考慮すればwikiリンク形式でも「生成AIに使わせる」こと自体は可能です。ただそれが、自分のテリトリーを越えて使いやすいとまでは言えなくなる、というだけの話です。
ややこしいデジタルツール
アナログツールの場合、書いたらその媒体に「定着」するので、情報の移動については別の領域の検討になりました。しかし、デジタルツールはそもそもが移動可能であり、それはファイルから別のファイルというだけでなく、あるツールから別のツールへ、ある組織から別の組織へ、といった広がりを持った「移動」の概念になっています。
だから考えることがいっぱいあるわけです。
あくまで個人の用途で、それ以上に広げるつもりはない、という場合ならOKFのようなフォーマットをそこまで意識する必要はないでしょう。しかし、大きめの組織でナレッジを扱う場合なら、情報の「移動可能性」はより強く意識された方がいいかもしれません。
もちろん、どういう場合であっても、一度作成したデジタルデータは、あとから簡単に変換できます。その意味で、意識しつつも、あまり悩みすぎず、実際にやってみて感触を確かめながら調整していく、というおなじみのアプローチがよさそうです。