Files.md と『第二の脳』の解体 — PKM が再び小さくなる理由
Files.md と『第二の脳』の解体 — PKM が再び小さくなる理由
5月第 2 週の Hacker News 1 位に上った Files.md は、なぜ自らを「Obsidian の代替」と称しつつ Obsidian の哲学そのものを拒否するのか。同じマークダウンを扱う道具が真逆の未来を描くとき、私たちは何を選ぶべきか。
導入 — 「第二の脳」という約束の亀裂
5月 14日、Hacker News のトップに一行が立った。「Show HN: Files.md — Open-source alternative to Obsidian。」24 時間で 518 ポイント、269 コメント。Obsidian 代替カテゴリは毎週ひとつふたつ登場してきたが、この記事が 1 位まで上った背景には別の理由がある。README 冒頭の一文、「あなたは自分のファイルを所有すべきだし、そのファイルを開くソフトウェアも所有すべきだ(you should own your files, and the software that opens them)。」そのあとに、より重い一文が続く。「この道具は意図的に機能を制限し、道具自体を弄る時間ではなく実際に考える時間へとユーザーを戻す。」
この記事の作者 zakirullin は、5年間自分と友人で使ってきた道具を 5月に公開した。コードベースは Go バックエンド(56%)+ JavaScript フロントエンド(28%)+ CSS(13%)とシンプルだ。ビルドシステムもない。web/index.html を直接開くだけでよい。依存関係はリポジトリ内に vendoring されている。MIT ライセンス。README のどこかに Joan Westenberg のエッセイ「私は私の第二の脳を削除した(I deleted my second brain)」が引用されている。「システムが育つほど、私は思考の作業をどんどん先送りした(the more my system grew, the more I deferred the work of thought)。」
この引用が決定的だ。Files.md は単なる Obsidian のオープンソース代替ではなく、過去 5 年で PKM(Personal Knowledge Management)コミュニティが固めてきた「第二の脳」というメタファそのものに正面から反対する宣言である。同じマークダウンファイルを扱いながら、Files.md は Obsidian と正反対の道を指す。そしてこの正反対は、5月 13日に扱った Memory.md パターン — Claude Code に直接 Obsidian のマークダウンとして note を書かせるパターン — とも正反対だ。
本稿はこの正反対の構造を追う。まず Files.md が正確に何を作らないと決めたのか。次になぜ 5 年ぶりに PKM のミニマリズムの流れが戻ってきたのか。最後に AI 時代に「道具を小さく保つ」という決定が何を意味するのか。
本文 1 — Files.md が作らないと決めたもの
Obsidian の魅力はプラグインエコシステムにあった。2020 年代初頭に Obsidian が急速に採用された理由は、Logseq よりシンプルかつ Notion より自由だったからだが、それを決定的に固めたのは 1,700 を超えるコミュニティプラグインだ。Dataview でノートを SQL のようにクエリし、Templater で新規ノートを自動生成し、Excalidraw で手書き図解を描き、Smart Connections のような AI プラグインでノート間の意味的つながりを自動で見つける。5月 13日に見た manchan のワークフロー — Claude Code が毎朝 8 時に Obsidian のノートを自動整理して Wikilinks と Callouts を埋める — もこの生態系の上にある流れだ。
Files.md はこのすべてを真正面から拒否する。README に記された設計原則は短くて断固としている。
- 1 つのノートに 1 つのアイデア
- 構造は最小限
- リンクは手で直接張る
- ノートを再読し、実際に理解するために時間を使う
- 「高度なテンプレートではなく自分の脳を使う必要がある(you’ll have to use your brain, not advanced templates)」
この原則は Obsidian の真逆だ。Obsidian のユーザーがよく陥る罠は、ノートの収集自体が仕事になることである。Dataview クエリを整え、テンプレートを整備し、グラフビューの色を調整する時間が膨らむのに、そのノートが実際の思考につながらない。Westenberg のエッセイが指摘する問題はこれだ。「システム自体が思考の代替物として機能する。」
zakirullin は HN コメントで自分の哲学を一文に書いた。「あなたは自分のファイルを平文で所有すべきだけでなく、そのファイルを開くソフトウェアまで所有すべきだ。そうすればあなたのファイルと道具は、完全にあなたの所有のもと、時間とともに一緒に育っていける(So that your files and tools can grow together, fully under your ownership, through the ages)。」この文は PKM 道具の二つの層を区別している。上層はファイルだ。Obsidian のマークダウンは平文なのでユーザーが所有する。しかし下層、そのファイルを開くソフトウェア自体はユーザーが所有していない。Obsidian はクローズドソースで、価格の変更、ライセンスの変更、サービス終了のリスクが常に残る。HN の himata4113 がコメントに書いた一文、「この記事を見て初めて Obsidian がオープンソースではないと気づいた(this made me realize that obsidian is not opensource)」は、このリスクがユーザー意識の表面に頻繁には浮かばないという事実を示している。
Files.md はその第二の層までユーザーが所有するように作る。シンプルな Go バックエンドと JavaScript フロントエンドは意図的だ。コードを LLM が読んで修正しやすいよう小さく保つ構造である。zakirullin は同じコメントで「このアプリは LLM でユーザーのニーズに合わせて簡単に調整できるよう書かれている(the app can be easily tweaked for your own needs via an LLM — code is optimized for that)」と書いた。これが核心だ。AI がノートを自動で埋めるのではなく、AI がノート道具自体をユーザーの手に合わせて整える。二つのパターンは正反対の方向を向く。
本文 2 — なぜ 5 年ぶりに PKM ミニマリズムが戻ってきたか
PKM 道具の歴史は振り子運動に近い。2015 年頃 Evernote が頂点にあったとき、ユーザーはすべてを一箇所に集めるミニマリズムに魅了された。2018 年頃に Roam Research が登場し、非方向性グラフ、bidirectional links、daily notes のような新しいパターンが標準になった。2020 年に Obsidian がそのパターンをローカルマークダウンへ移して急拡大した。その後 5 年間で PKM 道具はどんどん複雑になった。Notion はデータベースを豊かにし、Logseq は outliner を深掘りし、Obsidian はプラグインで無限に拡張可能なプラットフォームになった。
2025 年から振り子が逆方向に揺れ始めた信号があちこちに見えた。Joan Westenberg のエッセイがその信号の決定版だった。あの記事は単なるノート道具の使用後感想ではなく、「第二の脳」というメタファ全体への批評だった。Westenberg の論点は二つだ。第一に、情報の収集・分類・連結という行為自体は思考の代替にならない。第二に、システムが複雑化するほどシステム自体が仕事になる。その結果、システムの中に閉じ込められている間、実際の思考は減っていく。
この診断が、5 年ぶりに戻ってきたミニマリズム潮流の出発点だ。しかし興味深いのは、今回のミニマリズムが単純に昔の Evernote 時代に戻るわけではないという点である。違いは AI の登場が作る。AI がノートを自動分類・連結・要約する時代になると、ユーザーは二つの選択肢を持つことになった。ひとつは AI にその作業を丸ごと任せて、自分はより大きな道具の上でより少なく働く道だ。5月 13日に見た日本 Qiita の manchan ワークフローがその道だ。毎朝 launchd が回る間に Claude が Obsidian のノートを自動整理しておく。もうひとつは AI にその作業を任せず、ノート道具自体を小さくして思考の表面を露出させる道だ。Files.md がその道である。
この二つの選択肢は表面上は真逆だが、同じ診断から出発する。PKM システムが思考を代替してはいけない、という診断だ。第一の道はその診断を自動化で解く。システム管理にかかる認知コストを AI へ預け、ユーザーはその上で思考に集中する。第二の道はその診断を節制で解く。システム自体を小さくし、その中で起きることをユーザーが直接統制できるようにする。
どちらが正しいかは人によって異なる。だが分岐点ははっきりしている。第一の道は LLM の信頼性と価格が下がり続けるという前提の上にある。第二の道はその前提と無関係に、ユーザーが道具のすべての層を統制できるべきだという価値の上に立つ。zakirullin の一行、「ファイルと道具が時間とともに一緒に育つべき」は、第二の道の核心を正確に表現する。道具の未来を外部会社の価格政策に委ねないということだ。
ここで韓国コミュニティの位置を簡単に押さえておく。韓国では Notion の占有率が圧倒的に高い。PKM 道具の本格的な議論は Obsidian ユーザーが一定数に達した 2023 年頃から始まったが、「第二の脳」というメタファが PKM コミュニティの中で固まったことは日本や英語圏ほど強くなかった。だから韓国ではこの振り子運動が英語圏ほど鮮明には見えない。しかし 5月に入って Claude Code と Memory.md パターンが韓国の開発者コミュニティへも流れ込み始めたことで、日本側で起きた両極化 — AI 自動化派とミニマリズム派の分岐 — が韓国でも近く起きる。
本文 3 — AI 時代に「道具を小さく保つ」ことが持つ重さ
Files.md の README には追加の一行メモがある。「Golang seems to be great fit for this kind of software.」小さい道具を小さく保つために Go を選んだという意味だ。Go はコンパイラがひとつのバイナリにまとめてくれ、依存を vendoring しやすく、LLM がコードを読んで修正するのにも安定している。JavaScript の依存地獄 — 1 パッケージを入れると数百の transitive 依存が付いてくる — を避けるための選択である。この決定は単なる技術選定ではない。道具が小さくなければユーザーが道具全体を手の中に握れない、という哲学から出る決定だ。
この哲学は AI 時代に新しい重さを得る。LLM がコードベースを読んで修正してくれる時代に、コードが小さくシンプルなほど、ユーザーが LLM で自分の道具を整える作業が容易になる。100 万行の Electron アプリは LLM が一目で理解しづらいが、10 万行の Go コードベースなら、ユーザーが Claude Code の 1 セッション内で自分の必要に合わせて改修できる。zakirullin が「コードが LLM に最適化されている」と書いたのは、この差を意識した結果だ。Files.md のような道具は、ユーザーが自分の道具を自分の脳の拡張にできる出発点を作る。その上にユーザーが Claude Code で自分の環境に合わせて道具を育てていく流れが可能になる。
この流れは AI 時代のソフトウェア消費の新パターンを示しているかもしれない。これまでの SaaS モデルは「ユーザーが一社の作った道具を借りる」構造だった。AI がコードを扱える時代には「ユーザーが一社の作ったシンプルな道具を出発点として自分の道具へ育てていく」構造が可能になる。Files.md のような小さなオープンソース道具が自らを「alternative to Obsidian」と称するのはここに理由がある。単純な代替ではなく、ユーザーの手の中で育つ道具の種苗だ。
この種苗パターンが PKM 領域を超えてどこまで広がるかは開かれた問いである。5月に入り類似の流れが他領域でも見える。メールクライアント、カレンダー、タスク管理のような個人生産性道具の領域で小さいオープンソースプロジェクトが次々に登場している。その一部は zakirullin のメモに似た一行を README に書き入れている。「このコードは LLM が読んで修正しやすいようにシンプルに書かれている。」
もちろん、このパターンがすべての領域に適用できるわけではない。セキュリティが決定的な道具、データ整合性が重要な道具、外部システムとの連携が多い道具は、ユーザーが LLM で簡単に改修できるシンプルな形に保つのが難しい。しかし個人生産性道具 — ノート、タスク、日記、習慣管理、家計簿のような — の領域では「小さく LLM フレンドリーなオープンソースのコア + ユーザーが整える変形」というパターンが次の四半期の標準になる可能性が見える。
Anthropic の 5月 18日 Stainless 買収と同じ週に Files.md が HN 上位に上ったのは偶然ではない。両者は同じ大きな流れの 2 つの面を見せる。大企業は SDK・MCP・ツール呼び出し仕様などのインフラを自社内に集約する。個人ユーザーはそのインフラの縁で、自分が統制できる小さな道具で環境を整える。この 2 つの流れがうまく噛み合えば、「大企業が標準インフラを作り、個人がその上で小さな道具を育てる」という新しい分業構造が固まる。うまく噛み合わなければ、大企業がインフラのゲートを閉じ、個人の小さな道具はその中で生き残れない。5月の 2 つの出来事は、その分岐点に私たちが立っているという信号だ。
結論 — 道具を小さく保つという決定
冒頭の二つの問いに戻ろう。Files.md はなぜ自らを「Obsidian の代替」と称しつつ Obsidian の哲学そのものを拒否するのか。同じマークダウンを扱う道具が真逆の未来を描くとき、私たちは何を選ぶべきか。
第一の問いへの答えは言葉遊びではない。「alternative」は同じ場所に入る代替という意味だが、Files.md はその場所から正反対の方向を指す。Obsidian がプラグインで拡張する道を行ったなら、Files.md は機能を減らしてユーザーの脳の仕事を道具に押し付けない道を行く。Obsidian がクローズドソースでユーザーが道具自体を所有しない構造なら、Files.md はオープンな MIT ライセンスにシンプルなコードベースで、ユーザーが道具全体を手のうちに置けるようにする。同じマークダウンファイルの上で、2 つの道具は真逆の PKM の未来を描く。
第二の問いへの答えは人それぞれだ。毎朝 launchd が回る間に Claude が Obsidian ノートを整理しておくワークフローが合う人はその道を行けばよい。道具自体を手のうちに置き、自分の脳でノートを整理する道が合う人は Files.md のような道具を選べばよい。どちらが本質的に優れているわけでもない。両者は同じ診断 — PKM システムが思考を代替してはいけない — から出発して別の道を行く。
ただしこの記事が強調したい一点がある。AI 時代に道具を小さく保つという決定は単なるミニマリズムではなく、ユーザーが自分の道具のすべての層を手の中に置けるようにする戦略である。 Files.md の 5,000 行の Go コードベースは、ユーザーが Claude Code の 1 セッション内で自分の必要に合わせて整えられるサイズだ。100 万行の Electron アプリではそれが不可能になる。AI がユーザーの道具を整える協力者になり得る時代において、道具のサイズは単なる美学ではなく、ユーザー自律性の単位になる。5月の Files.md は、その単位を再び小さい方向へ動かそうという提案だ。
出典: