Blog

AI Agent時代にローカルファイルシステムを再設計する: KCSという知識空間の提案

Published · May 1, 2026

Topics

agent

filesystem

knowledge

kcs

AI Agentを使っていると、モデルの賢さに驚く一方で、かなり早い段階で別の壁にぶつかります。

それは、ローカルファイルシステムがAIにとってあまりにも扱いづらいという壁です。

LLMの性能は毎年上がっています。コード生成も、推論も、長文読解も、数年前とは別物です。それでも、AI Agentに自分のPC内の資料、PDF、画像、Officeファイル、過去のメモ、研究ノート、作業履歴を横断的に扱わせようとすると、急に体験が悪くなります。

問題はAIだけではありません。むしろ、AIがアクセスする側の知識空間の設計が古いままなのではないか、というのがこの記事で述べたい意見です。

私はこの問題意識から、KCS（Knowledge Content Store）というプロジェクトを考えています。

GitHubリポジトリはこちらです。

https://github.com/ttokunaga-ja/kcs

KCSを一言でいうと、Local-first knowledge archive, powered by frontier AIです。

データはローカル、計算は最強のAIを使う。

技術的にはGit inspiredなcontent-addressed object storeとsnapshot DAGを持ち、ローカルファイル空間をAI Agentが探索しやすい知識アーカイブへ変換する仕組みです。ただし、Gitの知識管理版を全部入りで作ることが目的ではありません。

KCSが最初に狙うのは、後述する3点です。Evidence Pointer、Markdown正規化、時間旅行可能なCAS。この3つに絞って、「探せなかったファイルがすぐ見つかる」「根拠が死なない」を実現したいと考えています。

ローカルファイルシステムは人間向けに見えて、人間にも厳しい

現在のローカルファイルシステムは、基本的には「ファイル名」と「フォルダ階層」に強く依存しています。

これは一見すると自然です。人間はフォルダを作り、名前を付け、分類して保存します。

しかし実際には、すぐに破綻します。

最終版.pdf
最終版_修正.pdf
最終版_本当の最終版.pdf
2024資料
新しいフォルダ
スクショ 2026-05-01 13.42.10.png
meeting_notes.txt
memo.md

このような状態は、誰のPCにもあります。

ファイル名は曖昧で、フォルダ分類はその時点の気分に依存し、後から探すときには自分でも文脈を忘れています。さらにPDF、Word、PowerPoint、画像、スクリーンショット、音声、動画などが混ざると、検索可能性は一気に落ちます。

つまりローカルファイルシステムは、構造化された知識空間ではなく、保存された断片の置き場に近いのです。

エンジニアの世界では当たり前の常識が、普通のファイル空間にはない

興味深いのは、エンジニアはこの問題をすでに別の場所でかなり解決していることです。

たとえばGitには、現代の知識管理に必要な重要な性質がいくつもあります。

変更履歴が残る
どの時点の状態にも戻れる
差分が見える
commitによって意味のある単位で保存できる
hashによって内容を識別できる
branchやtagで文脈を分けられる
remoteに同期できる
変更理由をcommit messageとして残せる

これはエンジニアにとっては日常です。

しかし、ローカルファイルシステム全体を見ると、こうした常識はほとんど存在していません。

PDFを少し修正しても、画像を加工しても、PowerPointを更新しても、「何が、いつ、なぜ変わったのか」は自然には残りません。ファイル名で頑張るか、クラウドストレージのバージョン履歴に頼るか、手作業で別名保存するしかありません。

コードの世界では当たり前の履歴、差分、再現性、参照可能性が、知識ファイルの世界では当たり前ではない。

ここに大きな断絶があります。

AI Agent時代には、この断絶が最大の障壁になる

AI Agentは、単発のチャットよりも一段深く、ユーザーの環境に入り込んで作業します。

コードを書くAgentなら、リポジトリを読み、ファイルを編集し、テストを実行し、差分を確認できます。これはGitとテキストファイルの相性が良いから成立しています。

一方で、日常の知識ファイルはどうでしょうか。

過去のPDF資料から根拠を探す
画像やスクリーンショットの内容を含めて検索する
複数のOffice文書に散らばった情報を統合する
昔削除したファイルも含めて調べる
ある時点の資料状態に戻って確認する
「この結論の根拠になった原文」を辿る

こうしたことをAI Agentに頼もうとすると、現在のファイルシステムは弱すぎます。

AIは賢くなっているのに、AIが読むべき知識空間が、検索しづらく、履歴も弱く、意味単位に分解されておらず、根拠を安定して指せない。

その結果、Agentは毎回その場でファイルを読み直し、PDFを再解釈し、ファイル名とフォルダ構造から文脈を推測することになります。これは遅く、不安定で、再現性がありません。

私の感覚では、AI Agent時代の本当のボトルネックは「モデルがまだ少し賢くないこと」よりも、モデルに渡す知識空間が設計されていないことにあります。

AI Agent FriendlyはHuman Friendlyでもある

ここで強調したいのは、AI Agentにとって扱いやすい知識空間は、同時に人間にとっても扱いやすいということです。

Agent Friendlyというと、「AIのために特殊なデータ構造を作る」という話に聞こえるかもしれません。しかし実際には、AIが困るポイントの多くは、人間も日々困っているポイントです。

ファイル名を思い出せない
どのフォルダに保存したか忘れる
同じような資料が複数あり、どれが最新かわからない
PDFや画像の中身まで検索できない
いつ、何が、なぜ変わったのか追えない
ファイルごとに見た目や形式が違い、読むまでに時間がかかる

AI Agentが検索しやすいように、ファイル名ではなく内容、chunk、embedding、履歴、関係性で探せるようにする。これはそのまま、人間が検索するときにも効きます。

「あのファイル名なんだっけ」と思い出すのではなく、「あの会議で話した予算の話」「去年の研究計画で使った評価指標」「この画像に写っていたエラー文」のように、記憶に近い言葉で探せるようになる。

AIのために知識空間を整えることは、人間のために知識空間を整えることでもあります。

必要なのは、AI性能の向上だけではなく知識空間の再設計

もちろん、AIモデルの性能向上は重要です。

しかし、モデルがどれだけ賢くなっても、入力される知識が散らかっていて、履歴がなく、根拠を指せず、検索できず、復元できないなら、Agentの能力はそこで頭打ちになります。

Webの世界では、Googleが検索体験を大きく変えました。WebページはURLを持ち、リンクされ、クロールされ、インデックスされ、検索可能になりました。

一方で、ローカルファイル空間はまだそこまで到達していません。

自分のPCの中には、人生や仕事や研究の重要な知識が大量にあるにもかかわらず、それらはWebほど検索しやすくなく、Gitほど履歴管理されておらず、AI Agentが扱うにはあまりにも非構造です。

だから私は、次に必要なのは「さらに強いAI」だけではなく、AIが読むためのローカル知識空間の再設計だと考えています。

近い領域の先行者と、KCSの賭け

似た領域には先行者が多くいます。

たとえば、Perkeepはcontent-addressed personal storage、git-annexは大容量ファイル管理、Obsidian + Smart Connectionsはvault内の意味検索、KhojやAnythingLLMはlocal-firstなAIチャット、DEVONthinkは文書管理、Microsoft Recallは画面snapshot検索に近い領域を扱っています。

冒頭で述べた3点を、既存ツールとの違いとして整理すると次のようになります。

Evidence Pointer: pathではなく、commit / raw_hash / tool_profile_hash / chunk_hash / spanで根拠を指す。ファイル移動、リネーム、削除でも根拠が死なない。
Markdown正規化を共通中間表現にする: 全ファイル種別をNormalized Markdownに変換し、人間とAIが同じビューを使う。Markdownはrawからの読み取り専用ビューとして扱う。
Content-addressed local archive + time-travel search: ファイルをCAS objectとして保存し、削除済み、過去版、移動済みファイルにも検索が届く。

それぞれの既存ツールは、この一部を実現しています。PerkeepはCASですが検索体験が弱い。KhojはAI検索ができますが、過去版に強く戻れるわけではない。Recallは時間旅行的ですが、ファイル原本の根拠へ戻る設計ではありません。

この3点を一貫して提供するlocal-firstなレイヤーはまだ空いている、というのがKCSの賭けです。

KCSでやりたいこと

KCSは、この問題に対する私の提案です。

KCSでは、ローカルフォルダの中に .kcs/ という隠しディレクトリを置き、そのフォルダの知識を管理します。ただし、親 .kcs/ が子フォルダ以下を無制限に再帰取り込みする設計ではありません。

各 .kcs/ は基本的に、その .kcs/ が置かれたフォルダ自身が直接持つファイルを管理します。子フォルダに別の .kcs/ がある場合、そのサブツリーは独立したscopeとして扱います。

横断検索のためのregistryやaggregatorは、あくまで検索キャッシュです。registryが壊れても各.kcs/を読み直せば再構築できますが、.kcs/自体が消えると復旧不能です。この分離により、検索の便利さとデータの正本性を両立します。

.kcs/ は、ただの検索インデックスではなく、次のようなobject storeとartifact群として扱います。

raw object
chunk object
embedding object
tree object
commit object
generated Markdown artifact
search index / cache

つまり、ファイルを単に「今のパスにあるもの」として見るのではなく、content-addressedな知識アーカイブとして保存します。

この考え方はGitから多くを学んでいますが、KCSの中心はGitの再実装ではありません。中心にあるのは、AIと人間が同じ根拠へ戻れるEvidence-grounded archiveです。対象はソースコードだけではなく、PDF、Office文書、画像、Markdown、テキスト、将来的には音声や動画も含めたローカル知識全体です。

Git型の全部入りナレッジ管理は目指しません。Knowledge Graph、Agent navigation、GUIはMVPでは捨てます。最初は「探せなかったファイルがすぐ見つかる」「根拠が死なない」の2点に振り切ります。

Markdownを共通表現にする

KCSでは、PDFやOffice文書や画像のような検索しづらいファイルを、まずMarkdownを中心とする統一テキスト表現へ変換します。

これは単なる変換ではありません。

AI Agentが扱いやすい形へ、ローカル知識を正規化する工程です。

同時に、これは人間が読むための正規化でもあります。

たとえばPDFの本文、見出し、表、画像中の文字、Office文書の構造などを、可能な限りMarkdownとして表現します。そのうえでchunkに分け、embeddingを作り、検索インデックスに接続します。

そうすると、元の形式がPDFでもWordでもPowerPointでも画像でも、検索結果としては同じMarkdownベースの書式で内容を確認できます。毎回アプリを開き直したり、ページをめくったり、スクリーンショットを拡大したりする前に、まず統一されたテキスト表現で概要をつかめる。

これはAI Agentだけでなく、人間にとっても大きな価値があります。

重要なのは、元ファイルを捨てるのではなく、raw objectとして保持し、Markdown artifactやchunk objectと対応づけることです。

AIが回答したときに、「どの原文の、どの時点の、どの範囲を根拠にしたのか」まで戻れるようにしたい。

また、Markdownは正本ではなくraw objectからの読み取り専用ビューとして扱います。

原本ファイルはraw objectとしてcontent-addressedに保持され、Markdownはそこから生成された派生物です。Markdown自体にはcontent hashを持たせません。LLMベースのMarkdownizeは非決定的で、同じrawからでもモデルやプロンプトや実行環境によって微妙に表現が揺れる可能性があるからです。

identityは(raw_hash, tool_profile_hash)の組で決まります。これにより、AdapterのLLMが変わって再生成Markdownに揺れが出ても、Evidence Pointerの安定性を脅かしません。Evidenceはraw側に根を張っています。

同じファイルが更新されたら、差分だけMarkdownizeする

ファイルが更新された場合、Markdownize Adapterには新rawだけを投げ直すのではなく、新raw + 旧raw + 旧Markdown + 変更ヒントを一緒に渡し、軽微な変更なら部分更新で返してもらう設計にしています。

理由は2つあります。

LLM APIのコストを抑えるため。PDF 100ページのうち1ページだけ変わったのに全ページを再Markdownizeするのは割に合わない。
全文再生成による表記ゆれを抑え、unit_id、chunk、Evidence Pointerの安定性を高めるため。

これはMarkdownize Adapterがincremental_update capabilityを宣言した場合のみ発動します。未対応Adapterは常にfull modeで呼ばれるので、後方互換も保てます。

Evidence Pointerが重要になる

AI Agentを実用するうえで、根拠を安定して指せることは非常に重要です。

ただファイルパスを指すだけでは弱いです。

ファイルは移動します。名前も変わります。中身も更新されます。削除されることもあります。

そこでKCSでは、Evidence Pointerをpathではなく、次のような情報の組み合わせとして扱います。

commit
tree
raw_hash
tool_profile_hash
chunk_hash
path_at_commit
span

これにより、Agentが参照した根拠を、後から同じ状態で辿れるようにします。

AIの回答に対して「それはどの資料のどこに書いてあるのか」と聞いたとき、現在のファイルパスではなく、当時のsnapshotとcontent hashに基づいて戻れることが重要です。

フォルダローカルな`.kcs/`

KCSでは、.kcs/を知識スコープのルートに1つだけ置くのではなく、基本的には各フォルダに生成されるフォルダローカルな管理単位として考えています。

これは、知識の境界がプロジェクトやフォルダごとに変わるからです。

仕事の資料、研究ノート、個人メモ、開発プロジェクト、契約書類などは、それぞれ異なる文脈とアクセス範囲を持ちます。すべてを単一の巨大インデックスで管理するより、フォルダごとの.kcs/があり、それらを必要に応じて横断検索できる方が自然だと考えています。

同時に、デフォルト検索ではindexed scope全体を対象にし、オプションで現在フォルダや配下scopeに制限できるようにします。

このあたりは、Gitのrepository感覚と、OS全体検索の感覚の中間にある設計です。

KCSはlocal-firstであってoffline-firstではない

もう1つ重要なのは、KCSはlocal-firstであって、offline-first原理主義ではないということです。

local-firstとは、「データの主権はあなたのマシンにある」という意味です。「すべての計算をオフラインで動かすべき」という意味ではありません。

MarkdownizeやEmbeddingには、Gemini、Claude、GPTのようなfrontier AIを使うのが既定です。データはローカルに置き、計算は最強のAIを使う。これがKCSの基本姿勢です。

ただし、KCS coreがユーザーの明示的な許可なしにファイル内容をネットワーク越しのAPIへ送ることはありません。オンラインAPI Adapterを使う場合は、対象scope、送信対象、network opt-inをユーザーが明示する前提です。

検索・復元・履歴の参照はオンライン依存にしません。既存snapshotやartifactは、ネットワークが遮断されていても探索・復元できる。これがKCS coreの最低保証です。

完全なローカル運用は、ローカルLLM Adapterを選んだユーザーの選択肢として残します。ただし、それをKCSのデフォルトとはしません。Prepare、Markdownize、Embedding、Summary、Classification、RerankなどはAdapterとして差し替え可能にし、用途やポリシーに応じてオンラインLLM API、ローカルLLM、決定論的なライブラリ実装を選べるようにします。

重要なのは、知識アーカイブの正本が特定のAIサービスに閉じ込められないことです。

AI AgentにとってのKCS

KCSがあると、AI Agentはローカルファイル空間をただのファイルツリーとしてではなく、履歴付きの知識空間として扱えます。

たとえばAgentは、次のような問いに答えやすくなります。そしてこれは、そのまま人間が自分の知識を探すときの問いでもあります。

このテーマについて過去に何を書いたか
似た内容の資料はどこにあるか
この結論の根拠はどのファイルのどの箇所か
先月時点ではこの資料はどうなっていたか
削除された資料を含めると何が言えるか
あるフォルダ配下だけで検索すると何が見つかるか
このノートと関連する画像やPDFは何か

これは単なる全文検索ではありません。

BM25、Vector Search、Snapshot DAG、Evidence Pointerを組み合わせた、Agent向けの知識基盤です。

さらに、人間にとっては「ファイル名に頼らない検索」「変更履歴を辿れる知識管理」「形式に依存しないMarkdownビュー」を得ることになります。

今のOS検索では、検索結果にファイル名が並び、結局どれを開けばよいのかを人間が判断する場面が多いです。KCSでは、検索対象をファイルそのものではなく、正規化された内容、chunk、snapshot、根拠ポインタとして扱います。

そのため、「最新のファイルを探す」だけではなく、「この情報がいつ追加されたのか」「前の版ではどう書かれていたのか」「似た説明が別の資料にもあるのか」まで追えるようになります。

ローカルファイルシステムを「保存場所」から「知識空間」へ

今のローカルファイルシステムは、保存場所としては十分に成熟しています。

しかし、AI Agentの時代には、それだけでは足りません。

必要なのは、ファイルを保存する場所ではなく、知識を探索し、根拠を辿り、履歴を復元し、意味単位で再利用できる空間です。

それはAI Agentのためだけのものではありません。

人間にとっても、ファイル名とフォルダ階層だけに頼る時代から、内容、履歴、関係性、統一されたMarkdown表現で知識を扱う時代へ移るということです。

エンジニアはGitによって、コードに対してそれを実現してきました。

次は、ローカルの知識ファイル全体に対して、同じような恩恵を広げるべきではないでしょうか。

私はKCSを、そのための実験として設計しています。

最初のターゲットユーザーとMVP

KCS MVPの最初の対象は、明確に絞っています。

大量のPDF、Markdown、コード、画像、研究資料を扱う
開発者、研究者、技術者
GitやCLIに抵抗がない
AI検索を試したいが、クラウド丸投げは嫌

GUIはMVPでは持ちません。最初はCLI + 構造化APIのみです。

一般ユーザー向けへの展開は、技術者層で「探せなかったファイルがすぐ見つかる」「根拠が死なない」を確立した後の段階です。これは、思想は近くても日常体験差を出せず一般化しなかった先行ツールの轍を意識した判断でもあります。

また、KCSは要素が多いプロジェクトです。CAS、snapshot DAG、FTS、vector、graph、agent navigation、classificationなど、広げようと思えばいくらでも広がります。

だからこそ、MVPではEvidence基盤、検索、履歴にコミットし、自動分類、Knowledge Graph、Agent APIは後のphaseに回します。コア実装規模はripgrep以下、テストを除いて11kから16k LOC程度を上限の目安にします。

綺麗な設計を完璧に作るより、まず「探せなかったファイルがすぐ見つかる」を届けることを優先します。

まとめ

この記事で言いたかったことは、次の5つです。

ローカルファイルシステムは、AI Agentが扱う知識空間としては弱い
エンジニアの世界では当たり前の履歴、差分、hash、復元性が、一般的なファイル空間には存在していない
AI性能を上げるだけでなく、AIが読む知識空間そのものを再設計する必要がある
AI AgentにとってFriendlyな知識空間は、人間にとっても検索しやすく、読みやすく、履歴を追いやすい
KCSの最初のMVPは開発者、研究者、技術者向け。一般ユーザー向け展開はその後の段階

KCSはまだ設計段階のプロジェクトです。

ただ、AI Agentが本当に個人の知識や仕事の文脈を扱うようになるなら、こうしたlocal-firstな知識アーカイブはかなり重要になるのではないかと考えています。

GitHubリポジトリも公開しています。