Claude Codeでファイルシステムをデータベース化する実践

中島聡氏の週刊メルマガ「Life is beautiful」2026年4月7日号を読んで、手が止まりました。

Claude Codeをソフトウェア開発以外の、生活全般の情報管理に使っている人がいる。タスクリスト、名刺情報、日々のメモ——あらゆるデータをファイルシステムに保存し、Claude Codeにその読み書きを任せている。中島氏はこの使い方に衝撃を受け、MulmoClaudeというプロトタイプを公開しました。

自分もClaude Codeを毎日使っていますが、この話を読んで気づいたのは、自分が半年かけて育ててきたObsidian Vault + Claude Codeの運用が、まさにこの「ファイルシステムをデータベースとして使う」アプローチそのものだったということです。

「ファイルシステムがデータベース」とはどういうことか

従来のアプリケーション開発では、データの保存にはデータベースを使います。PostgreSQL、MySQL、Firebase——スキーマを定義して、CRUD操作を実装して、UIからアクセスする。この構成は堅牢ですが、大きなコストも伴います。

• スキーマ設計が必要（データ構造を事前に決めなければならない）
• CRUD APIの実装が必要（データの出し入れをコードで書く）
• UIの構築が必要（人間がデータを操作するためのインターフェイス）

ファイルシステムをデータベースとして使うアプローチでは、これらが全部不要になります。なぜなら、Claude Codeが自然言語でファイルの読み書きを行うからです。

「この人の名刺情報を保存して」と言えば、適切なディレクトリにMarkdownファイルが作られる。「先週のタスクの進捗を見せて」と言えば、関連ファイルを読んで要約してくれる。スキーマ定義もAPI実装もUI構築も、全てClaude Codeが吸収しています。

自分のObsidian Vault運用が、まさにそれだった

自分は約4,000ファイルのObsidian Vaultを運用しています。Claude Codeのワーキングディレクトリにこのvaultを指定し、カスタムスラッシュコマンドで様々な自動化を組んでいます。

具体的にどんなことをしているか:

情報収集の自動化

/daily-digest コマンドで、PubMed医学論文 + Tech/Biz RSSフィードを毎日取得しています。Claude Codeがフィードを読み、重要度をトリアージし、Obsidianのノートとしてファイルに書き出します。/digest-newsletter ではGmailのメルマガも同様に処理します。

ここで起きていることを分解すると:

1. 外部APIからデータを取得する（fetchスクリプト）
2. データを分析・分類する（Claude Codeの判断）
3. 結果をファイルに保存する（Markdownとして書き出し）

データベースもWebアプリも一切使っていません。Markdownファイルがそのままデータストアであり、ObsidianのUIがそのままビューワーです。

メモリシステム

Claude Codeには ~/.claude/projects/ 配下にメモリファイルを書き込む仕組みがあります。自分はこれを積極的に使い、プロジェクトの状況、フィードバック履歴、外部リソースへの参照をファイルとして蓄積しています。

会話のたびにメモリファイルが読み込まれるので、「先週話した○○の件」のような文脈が自動的に引き継がれます。これは従来なら専用のCRMやプロジェクト管理ツールが担っていた機能です。

Zettelkastenワークフロー

読んだ本やYouTube動画の内容を、LiteratureNoteとしてvaultに蓄積しています。/youtube-note コマンドで動画のURLを渡すと、内容を取得して構造化されたノートが自動生成されます。

ノート同士のリンクはObsidianのバックリンク機能で管理し、知識のネットワークが自然に育っていきます。ここにもデータベースは登場しません。

SaaSが不要になる領域

中島氏はメルマガの中で「こんなClaude Codeの使い方をされては、SaaSビジネスには出番がありません」と書いていました。

この指摘は半分正しく、半分は言い過ぎだと自分は考えます。

SaaSが不要になる領域: 個人のタスク管理、メモ、情報整理、日記、学習ノート——つまり「自分だけが使うデータ」の管理です。Notion、Evernote、Todoist、Google Keepのようなツールが担っている領域の一部は、Claude Code + ファイルシステムで十分に代替できます。

実際、自分はObsidian + Claude Codeの組み合わせで、以下のSaaSを使わなくなりました:

• RSSリーダー → /daily-digest で代替
• メルマガ管理アプリ → /digest-newsletter で代替
• 読書ノートアプリ → Zettelkastenワークフローで代替

SaaSが引き続き必要な領域: 複数人でのコラボレーション、リアルタイム同期、権限管理、大規模データの集計——これらはファイルシステムだけでは解決できません。SlackやGitHub、Supabaseのようなサービスは、別の価値を提供しています。

MulmoClaudeのアプローチ

中島氏のMulmoClaudeは、この「ファイルシステムをデータベースとして使う」考え方をさらに一歩進めています。

MulmoChatという既存のGUIチャットアプリがあり、これまではOpenAIやAnthropicのAPIにリクエストを送っていました。ストレージはブラウザのlocalStorageを使う仮実装でした。

MulmoClaudeでは、APIの代わりにローカルのClaude Codeにリクエストを送ります。Claude Codeがファイルシステムにアクセスできるため、データの永続化が自然に実現します。「GUI Chat Protocol」という共通プロトコルを使うことで、GUIとCLIの切り替えも透過的です。

これは「AIネイティブなパソコンのインターフェイスはどうあるべきか」という問いへの一つの回答です。スキーマを設計する代わりに、AIがファイル構造を自律的に決める。CRUD APIを書く代わりに、自然言語でデータを操作する。

実践で見えた課題

半年運用してきた中で、この「ファイルシステムDB」アプローチの限界も見えています。

検索性能: ファイル数が4,000を超えると、grep やObsidianの検索だけでは目的の情報にたどり着きにくくなります。ベクトル検索やセマンティック検索がほしくなる場面があります。

構造の一貫性: Claude Codeがファイルを作成するとき、ディレクトリ構造やfrontmatterのフォーマットが微妙にブレることがあります。テンプレートとバリデーションの仕組みで対処していますが、RDBのスキーマ制約ほどの強制力はありません。

コンテキストウィンドウの制約: Claude Codeが一度に読み込めるファイル数には限りがあります。vault全体を俯瞰するような操作は、サブエージェントに分割するなどの工夫が必要です。

これらは技術的に解決可能な課題で、ベクトルDB（ChromaDB等）との連携や、MCPサーバーによるファイル操作の拡張で改善できる見込みです。

ファイルシステムDBを始めるなら

この記事を読んで試してみたいと思った方に、最小構成を提案します。

1. Obsidianをインストールして空のvaultを作る
2. Claude Codeのワーキングディレクトリにそのvaultを指定する
3. CLAUDE.mdに「このvaultはMarkdownベースの知識管理システムです」と書く
4. 日々の作業で「これメモしておいて」「昨日のメモを見せて」とClaude Codeに話しかける

最初は構造を決めすぎないことが重要です。Claude Codeが自然に作るディレクトリ構造やファイル名を観察し、必要に応じてCLAUDE.mdのルールを育てていく。この「構造の進化」が、スキーマ設計の事前決定よりも柔軟で、実態に即したデータ管理を実現します。

Anthropicの最新の発表によれば、AnthropicのARRは300億ドルを突破しました。Claude Codeの利用者は急増しており、この「ファイルシステムをAIに任せる」というパラダイムは、ソフトウェア開発者だけでなく、情報を扱う全ての人にとっての新しい選択肢になりつつあります。

あなたの日常の情報管理で、データベースやSaaSに頼っている部分はどこですか。その一部は、ファイルとAIだけで十分かもしれません。