Obsidianを開かなくなった話——AIがファイルシステムの前に立つ時代に、情報管理Webアプリ"mado"を作った

以前、「Obsidianが最強のツールだと思う理由」と「Obsidian × Claude Codeで仕事もブログも全部管理してみた」という記事を書きました。タスクもナレッジもブログも、すべて1つのvaultに詰め込んで、Obsidianで管理する。そのワークフローを支えているのがClaude Codeだ、という話でした。

あれから数ヶ月が経ち、今の私のvaultの使い方は、少しだけ変わっています。

具体的に言うと、Obsidianをほとんど開かなくなりました。

vaultの中身は変わっていません。タスクもナレッジもノートも、同じフォルダにMarkdownファイルとして積み上がり続けています。でも、それを扱うための入口がObsidianではなくなったのです。

代わりに使っているのが、自分で作ったWebアプリ "mado" です。

この記事では、なぜ私がObsidianを開かなくなったのか、そしてなぜmadoというWebアプリを作ったのかを書きます。機能紹介の記事ではなく、mado というアプリに込めた思想そのもの の話です。結論を先に言っておくと、私はいま、こう考えています。

AIがファイルシステムの前に立つ時代が来た。

これからの情報管理は、人間がツールを使ってファイルを操作するものではなく、AIを窓口にしてファイルと対話するものになる。その確信が、このアプリを作る原動力でした。

頭の中には何もない

少し前から、自分の頭の中に"情報"がほとんど残らなくなっていることに気づきました。

今日やることも、先週調べた技術の要点も、思いついたアイデアも、自分の頭で覚えていません。全部、ローカルのMarkdownファイルに書かれています。

• 今日やるタスク → 10_Tasks/TASK.md
• 技術的な学び → 20_Knowledge/ 配下のmdファイル
• ちょっとしたメモ → 00_Inbox/ に放り込む
• Claude Code用の指示 → CLAUDE.md や .claude/ 配下

これはたまたまそうなっているのではなくて、意識的にそうしています。Claude Codeのようなエージェント型のAIツールを使い倒すには、指示もメモリもローカルファイルに残しておくのが一番効くからです。プロジェクトの方針、やりかけの作業、決定の経緯。これらが頭の中ではなくファイルにあるからこそ、AIは毎回きちんとそれを参照して仕事を進められる。

つまり私は、自分の仕事に必要な情報を、ほぼすべて外部化しているわけです。

ここで一つ、おかしなことが起きます。

情報がすべてファイルにあって、そのファイルをAIが常に読み書きしているということは、私よりもAIのほうが、私の状況をよく把握しているということです。

昨日どこまで進めたか。いま何のタスクが残っているか。このプロジェクトでどんな判断をしてきたか。私は忘れていても、ファイルに書いてある限り、AIは一瞬で取り出せる。自分の頭に聞くより、AIに聞いたほうが早くて正確なのです。

この状況になって初めて、「じゃあ情報の入口は誰であるべきか？」という問いが頭に浮かびました。

これまでの私は、vaultの入口として Obsidian を開いていました。ツールを開いて、ファイルを探して、必要なら編集して、閉じる。情報は常に自分の手元に引き寄せるものでした。

でも、自分よりAIのほうがファイルを把握しているなら、わざわざ自分が間に入る必要はないはずです。AIに「今日のタスクを整理して」と話しかけるだけで、ファイルから必要な情報を引っ張り出し、整理し、書き戻してくれる。そのほうが、自然で速い。

この気づきが、madoを作る出発点でした。

AIがファイルシステムの前に立つ

従来のツールと mado の違いを、ひとつの図で表現するなら、こうなります。

従来:  人間 → ツール → 情報
mado:  人間 ↔ AI ↔ mdファイル群

これまでの情報管理ツールは、人間とファイルの間に GUI を置いてきました。Obsidianも、Notionも、Evernoteも、構造は同じです。人間がツールを開いて、画面を操作し、ファイル（またはクラウド上のデータ）を動かす。ツールは人間の手の延長です。

mado が置こうとしているのは、その場所に AI です。

人間は AI に話しかける。AIが裏でファイルを読み、書き、整理する。人間は結果だけを受け取る。ファイルは存在し続けているけれど、ユーザーはそれを直接触る必要がない。AI がファイルシステムの前に立って、人間とファイルの間のレイヤーをまるごと引き受ける構造です。

大事なのは、これが単に「便利なAIアシスタント」の話ではないということです。GUIを残したままAI機能を追加するのと、AIそのものを入口にしてしまうのとでは、設計思想がまったく違います。前者はツールの改良で、後者はインターフェースの再定義です。

madoが大事にしているのは、後者のほうです。

この構造を成立させるために、madoには3つの信念があります。

1. データ主権はユーザーにある ファイルはクラウドではなく、ユーザーのローカルに置かれ続けます。AIはあくまでファイルを読み書きする代理人であって、情報を自分のサーバーに吸い上げることはありません。ファイルを別のツールで開いても、削除しても、ユーザーの自由です。

2. AIプロバイダーは入れ替え可能 Claudeでも、Geminiでも、将来出てくる別のモデルでも構いません。madoはアダプターパターンで設計されていて、LLMプロバイダーを差し替えられるようにしています。AIは入口のレイヤーであって、どのAIを使うかは本質ではないからです。

3. AIへの指示書はユーザーと一緒に育てる vault内の 90_System/PROMPT.md というファイルに、AIへの指示が書かれています。「このvaultではこういうルールで書く」「このタグはこういう意味」といった設定です。このファイルは最初から完成している必要はなくて、使いながらユーザーとAIが一緒に書き足していきます。長く使うほど、あなた専用のAIに育っていくイメージです。

この3つが揃って初めて、「AIがファイルシステムの前に立つ」という構造が、ユーザーにとって安心して使えるものになります。

なぜ"今"このアプリなのか

こういう構造のアプリを、私はなぜ今このタイミングで作ろうと思ったのか。

答えはシンプルで、エンジニアも非エンジニアも、日常的にAIを使う時代がついに来たと感じたからです。

少し前までは、AIを業務に組み込むというのは、どこか特別なことでした。「ChatGPTに聞いてみよう」が一部の先進ユーザーの行動で、大多数の人は使わないか、たまに思い出したように触るくらい。ましてや「AIに自分のファイルを読み書きさせる」なんて、一部のエンジニアの遊びでした。

でもいま、空気が明らかに変わっています。エンジニアはもちろんですが、非エンジニアの方でもChatGPTやGeminiを毎日触るようになってきた。社内でも「AIに聞いてから相談する」が普通になってきている。AIが日常の道具になりつつある、という実感があります。

私自身、エンジニアとは名乗っていますが、もうコードを自分で書くことはありません。すべてClaude Codeに指示を出して書いてもらっています。作業の中心は「何を作るかを言語化する」「AIの出力を検証する」の2つに移りました。AIは特別なツールではなく、自分の仕事そのものが AI 前提で組み立てられている状態です。

この状況を下支えしているのが、モデルの性能向上とコスト低下です。2〜3年前のAIだったら、今のワークフローは成り立たなかったと思います。当時のツール呼び出しはもっと不安定で、ファイルの読み書きを任せるにはリスクが大きすぎた。コストも、毎日何十回と使うには重すぎた。コンテキストも短くて、vault全体の文脈を持たせるのは無理でした。

でも今は違います。ツール呼び出しは実用に耐える精度になり、コストは個人が日常的に払える範囲に収まり、コンテキストは一つのvaultくらいなら平気で扱える。「AIを情報管理の入口に据える」という設計が、ようやく現実的になったのです。

だから私は、「AIがファイルシステムの前に立つ」という構造を、今のうちに形にしておきたいと思いました。誰かが先に作るのを待っていたら、自分が欲しかった形とは違うものが出てきてしまうかもしれない。自分のワークフローに最適なものは、自分で作るしかない。その決意が、madoの出発点です。

madoが何をするアプリか

ここからは、実際に mado がどんなアプリなのかを簡単に紹介します。

madoはWebアプリです。インストール不要で、ブラウザで開いて、ローカルのフォルダを選択するだけで使えます。アプリ本体はこちらで公開しているので、気になる方は先に覗いてみてください。

madoを開く

Chromeの「File System Access API」という機能を使っていて、選んだフォルダのMarkdownファイルを、ブラウザから直接読み書きできます。ファイルはローカルに置かれたままです。クラウドにアップロードもしません。

アプリを開くと、画面のほとんどがチャット欄です。設定、ファイル一覧、エディタ、検索。こういった機能をサイドバーやメニューに並べるのをやめて、すべてをチャットに集約しました。

ユーザーがやることは、話しかけるだけです。

「今日のタスクを整理して」
「先週調べた Function Calling のメモを見せて」
「このアイデアを新しいノートとして保存しておいて」
「プロジェクトAのタスクをステータス別に並べて」

こう打つと、AIが裏で適切なファイルを読み、書き、整理し、必要ならインラインでビューを描画して返してきます。

ここで言うインラインビューが、madoを作る上で一番こだわった部分です。チャットの中にそのままKanbanボードや、表形式のテーブル、シンプルなリスト、ノートのエディタが埋め込まれて表示されます。AIが「タスク一覧出して」という指示に対して、テキストで箇条書きを返すのではなく、操作可能なUIをその場に出してくれるというイメージです。

Kanbanでタスクのステータスを変えたいときは、カードをドラッグすれば書き換わります。ノートの中身をちょっと直したいときは、インラインエディタで直接編集できます。そのすべてが、ファイルへの書き込みとして即座に反映されます。

このインラインビューは、機能として後から足したものではなくて、madoを成立させるための最後のピースでした。というのも、私自身、AIとの会話だけで情報管理を完結させようとしたときに、どうしても残る需要があったからです。

• 「今あるタスクを視覚的に俯瞰したい」
• 「ちょっとした書き換えはAIを介さず直接やりたい」

こういう場面では、どうしてもObsidianを開いていました。madoがこのニーズをカバーできるようにならない限り、私はObsidianを手放せなかったのです。だからインラインビューを組み込みました。そしてこれが入ったタイミングで、私は本当にObsidianを開かなくなりました。

もう一つ大事な機能が、/skill-name という形でスラッシュコマンドを登録できるスキル機能です。よく使う定型プロンプトをスキルとして登録しておくと、チャット欄に /daily-review と打つだけで呼び出せます。Claude Codeを使っている方なら馴染みのある仕組みで、自分専用のAIワークフローを積み重ねていくためのものです。

私の1日は、チャット1行から始まる

madoを使った情報管理が、実際にどんな感じなのかを紹介します。

朝、仕事を始めるとき、私がやることは一つです。madoを開いて、こう打ちます。

今日のタスクを整理

これだけです。

そうすると、AIが 10_Tasks/ 配下のタスクファイルを洗い出して、未完了のものをピックアップし、今日やるべきものに優先度を付けて、10_Tasks/TASK.md に書き出してくれます。返ってくるのはチャット欄に埋め込まれたリストで、そのまま今日の行動計画として機能します。

この時点で、私はまだ"今日のタスク"を自分で思い出していません。頭の中でタスクを引っ張り出す前に、AIが外部記憶からそれを整理して目の前に並べてくれる。結果として、朝イチの思考負荷がぐっと軽くなります。

ここで起きていることを言語化すると、今日の状況を把握しているのはAIで、私はその要約を受け取っているという状態です。自分のタスクなのに、自分より先にAIが把握している。前のセクションで書いた「私よりAIのほうが私を把握している」は、毎朝この瞬間に実感しています。

日中は、タスクに進捗があったら適宜チャットします。

「○○のタスク完了。次のタスクの着手状況もアップデートして」
「新しく△△の調査が必要になった。タスクに追加して」
「このアイデア、メモに残しておきたい」

そのたびに、AIが該当のタスクファイルのステータスを書き換えたり、新しいタスクファイルを作ったり、00_Inbox/にメモを放り込んだりしてくれます。私がファイルを開くことはありません。

もう少し視覚的に状況を見たくなったら、

「プロジェクトAのタスクをカンバン表示して」

と打つと、チャットの中にカンバンボードが出てきます。そこでカードをドラッグすれば、裏のファイルも書き換わります。Obsidianでやっていたことが、全部チャットの中で完結するようになりました。

こうやって1日を振り返ると、Obsidianを開かなかった日が、気づけばずっと続いています。情報管理を「ツールを開いて行う作業」から「話しかけて済ませる行為」に変える。これがmadoのコンセプトの、一番わかりやすい現れかもしれません。

エンジニアだけのものじゃない

ここまで読んで、「それってClaude Codeで同じことできるじゃん」と思った方もいるかもしれません。正直、その指摘は半分正しいです。

Claude Codeをターミナルで起動して、vaultをプロジェクトとして開けば、AIに話しかけてファイルを操作するという体験は成立します。実際、私も mado を作る前はそうやって使っていました。なので、エンジニアからすると「Claude Codeでいいじゃん」と言われれば、そこまでです。

ただ、二つ補足させてください。

一つ目は、エンジニアにとってもインラインビューとインラインエディタは地味に便利だという話です。CLIのClaude Codeは文字ベースの応答が中心で、タスクをKanbanで俯瞰したいとか、ノートをその場でちょっと直したい、という用途にはどうしても弱い。madoならそれが同じチャットの流れの中でできます。毎日の情報管理に使うなら、この「地味な便利さ」は積み重なると効いてきます。

二つ目が、もっと大事な話です。それは、非エンジニアにはClaude CodeというCLIツールは遠すぎる、ということです。

「ターミナルを開いて、Claude Codeをインストールして、vaultディレクトリに移動して、claudeを起動して……」この時点で、多くの非エンジニアは脱落します。技術そのものの問題ではなくて、導入の体験が、日常の道具としてのハードルを超えてしまっているのです。

でも、AIがファイルシステムの前に立つこの新しい情報管理の形は、エンジニアだけのものであっていいはずがない。非エンジニアの方こそ、ファイル管理の細かいルールに煩わされず、AIに話しかけて済ませる運用と相性がいいはずです。

だからmadoは、あえて Webアプリ にしました。インストールも、環境構築もいりません。ブラウザで開いて、フォルダを選ぶ。それだけで「AIがファイルシステムの前に立つ」世界に入れます。APIキーを用意する必要はありますが、そこさえ越えれば、あとはチャットで話しかけるだけ。Claude Codeを使ったことがなくても、Markdownが何かよく分からなくても、「AIに聞いたらファイルが整理されていく」という体験だけは提供できる。

エンジニアには Claude Code にはない便利さ を、非エンジニアには Claude Code への入り口 を。同じアプリが、両方の層に別の意味で届くように設計しています。

それでも、書くときはObsidianを開く

最後に、正直な話を書いておきます。

madoを作って、Obsidianを開かなくなったと言いましたが、100%使わなくなったわけではありません。いまも、自分で長い文章を書くとき——たとえばこのブログ記事を書くときのような場面では、Obsidianを普通に開きます。

理由は単純で、創作にはGUIのほうが向いているからです。書いては削り、段落を入れ替え、表現を何度も直す。この試行錯誤の粒度は、AIを介した会話のテンポには合いません。自分の手で、自分のリズムで、画面を見ながら書き直す。そのための道具として、Obsidianはやっぱり最強だと思っています。

なので、madoが引き受けているのは、あくまで "情報管理"のレイヤー です。タスクを並べる、ナレッジを整理する、ちょっとしたメモを放り込む。こういう「ルーチン的にファイルを動かす作業」を、AIに任せるためのアプリ。

創作そのものまで奪う気はありません。

情報管理と創作は、見た目は似ていても、求められる思考のモードが違います。madoで楽にするのは前者、後者は引き続き自分の手でやる。この線引きをしているからこそ、madoは道具として使いやすい形に収まっていると思っています。

これからの情報管理

長く書いてきましたが、madoが示したいのは一つのことだけです。

AIが情報と人間の間のレイヤーに立つ時代が来た。ならば、そのレイヤーを前提にしたツールがあっていいはずだ、という提案です。

ツールを開いて、ファイルを探して、編集して、閉じる。こういう "自分で情報を取りに行く" 形は、自分の頭の中に情報が残っている時代の習慣だと思います。でも、今の私のように情報が全部外部化されていて、しかもAIが常にそれを読めるなら、入口は人間じゃなくていい。AIが代わりに立って、話しかけるだけで済むほうが自然です。

この構造は、慣れるとびっくりするほど快適です。Obsidianを開かなくなった数ヶ月のあいだ、生活の負荷が目に見えて減りました。頭の中に何もなくていい、というのは、想像以上に心地いいものでした。

madoはまだ発展途上のアプリですが、「AIがファイルシステムの前に立つ」という発想そのものは、これから確実に広がっていくと確信しています。エンジニアでも、非エンジニアでも、AIを日常的に使う人にとって、情報との付き合い方は確実に変わります。

その未来に向けて、自分なりの答えを一つ置いておきたくて、madoを作りました。

もし興味が湧いたら、ぜひ一度触ってみてください。フォルダを選んで、話しかけるだけです。それだけで、情報管理の景色が少し変わります。

madoを試してみる

※Chrome最新版での利用を想定しています（File System Access APIを使用）。APIキーはブラウザのlocalStorageに保存され、サーバーには送信されません。