ファイルシステムが注目される理由

 (madalitso.me)
36 ポイント 投稿者 GN⁺ 2026-03-09 | 1件のコメント | WhatsAppで共有
  • 最近、AIエージェントのエコシステムでファイルシステムが再び注目され、データベースとは異なる持続的なコンテキスト管理の手段として浮上
  • LLMのコンテキストウィンドウは持続的な記憶ではなく、消えていくホワイトボードに近く、ファイルシステムはこれを最もシンプルに解決する永続的な保存手段
  • Claude Code、Cursor などはファイルベースのコンテキスト保存によって長期記憶を実現しており、CLAUDE.md、aboutme.md のようなファイルがエージェントのアイデンティティや環境情報を保持する役割を担う
  • ファイルシステムベースのコンテキスト管理が重要なテーマとして浮上し、LlamaIndex・LangChain・Oracle・Archil など主要企業が関連する記事や製品を相次いで発表
  • CLAUDE.md、AGENTS.md、.cursorrules などエージェント用コンテキストファイルが乱立する中、Anthropic の Agent Skills（SKILL.md）フォーマットが Microsoft・OpenAI・GitHub・Cursor などに採用され、相互運用性を確保
  • ETH Zürich の研究によれば、コンテキストファイルはむしろタスク成功率を下げ、推論コストを20%以上増加させる可能性があり、最小限の要件だけを記述すべき
  • ファイルは特定のアプリに依存せず、AIエージェント時代にツール間の切り替え・ワークフローの結合・継続性の維持を可能にするオープンなインターフェースとして位置づけられている

Everyone is talking about files : あらゆる場所でファイルが語られている

コンテキストウィンドウは記憶ではない

  • 人間の記憶には長期保存・選択的想起・不要情報の忘却機能が含まれるが、LLM のコンテキストウィンドウは常に消され続けるホワイトボードに近い
  • Claude Code 使用時に "context left until auto-compact" の通知が近づくと、エージェントが蓄積したコードベース・好み・意思決定事項などのコンテキストは圧縮されたり失われたりする
  • ファイルシステムはこれを最もシンプルな方法で解決する。記録をファイルに書き、必要なときに再び読む
    • CLAUDE.md はプロジェクトに関する永続的コンテキストを提供
    • Cursor は過去のチャット履歴を検索可能なファイルとして保存
    • aboutme.md ファイルは、好み・スキル・作業スタイルを含む持ち運び可能な身元記述子として機能し、API の調整なしにアプリ間を移動できる

ETH Zürich の研究: コンテキストファイルの逆説

  • ETH Zürich の最近の論文は、リポジトリレベルのコンテキストファイルが実際にコーディングエージェントのタスク完了に役立つかどうかを評価
  • 結果は直感に反していた。複数のエージェントとモデルにわたり、コンテキストファイルはかえってタスク成功率を下げ、推論コストは20%以上増加
    • コンテキストファイルを受け取ったエージェントは、より広く探索し、より多くのテストを実行し、より多くのファイルを巡回したが、実際に修正が必要なコードに到達するのは遅れた
    • ファイルが、エージェントが過度に真面目に従うチェックリストのように機能
  • 論文の結論は「コンテキストファイルを使うな」ではなく、不要な要件がタスクを難しくし、コンテキストファイルには最小限の要件だけを書くべきということ
  • 問題はファイルシステムという永続レイヤー自体ではなく、CLAUDE.md を 2,000語のオンボーディング文書のように書く慣行にある

ファイルフォーマットこそが API — しかし、どのファイルか？

  • 現在、CLAUDE.md、AGENTS.md、copilot-instructions.md、.cursorrules などが併存しており、エージェントに永続的なファイルシステムベースのコンテキストが必要だという点には合意があるものの、ファイル名と内容フォーマットは未合意
  • Dan Abramov のソーシャルファイルシステムの記事での中心的な設計は、AT Protocol がユーザーデータを個人リポジトリ内のファイルとして扱い、アプリ同士が「ポスト」とは何かに合意する必要なく、ドメイン名ベースのネームスペースで衝突を防ぐというもの
    • すべてのアプリのデータベースは派生データ、すなわちすべてのユーザーフォルダのキャッシュされた具体化ビューになる
  • Anthropic は Agent Skills をオープン標準として発表し、SKILL.md フォーマットを Microsoft、OpenAI、Atlassian、GitHub、Cursor が採用
    • Claude Code 用に書いたスキルが Codex や Copilot でも動作する — ファイルフォーマットこそが API
  • NanoClaw は軽量な個人用AIアシスタントフレームワークで、「機能ではなくスキル」というモデルを採用
    • Telegram サポートが必要なら、Telegram モジュールではなく /add-telegram スキル（Markdown ファイル）が Claude Code に統合方法を教える
    • スキルはファイルなので、持ち運び可能で、監査可能で、組み合わせ可能 — MCP サーバーやプラグインマーケットプレイスは不要
  • これが調整なき相互運用性である。2つのアプリが Markdown を読めればコンテキスト共有が可能で、SKILL.md フォーマットを理解すれば機能共有が可能になり、提携契約や標準化団体の会議がなくてもファイルフォーマット自体が調整の役割を果たす

ボトルネックの移動

  • 従来のデータアーキテクチャはストレージがボトルネックだという前提で設計されていたが、処理能力がストレージ I/O を上回るようになり、ストレージとコンピュートの分離（S3 + 一時的コンピュートクラスター）へとパラダイムが転換
  • AIエージェントでも同様の現象が起きている。ボトルネックはモデル性能やコンピュートではなくコンテキスト
    • モデルは十分に賢いが、忘れやすい
    • ファイルシステムは、エージェントが実行されるまさにその場所（開発者のマシン、環境、データがすでに存在する場所）で永続的コンテキストを管理する最も効果的な方法

ファイルシステムはすでにグラフである

  • Twitter では、「ファイルシステムを使いながらエージェントにグラフは不要だと言う人は、自分がグラフを使っている事実を否認しているだけだ」という指摘
    • ファイルシステムはディレクトリ・サブディレクトリ・ファイルから成るツリー構造、つまり有向非巡回グラフ（DAG）
    • エージェントが ls、grep、ファイルの読み込み、参照の追跡を行うとき、すでにグラフを走査している
  • Oracle の記事の Richmond は最も鋭い区別を提示する。ファイルシステムはインターフェースとして勝ち、データベースは基盤レイヤーとして勝つ
    • 同時アクセス、大規模なセマンティック検索、重複排除、鮮度の重み付けなどが必要になると、結局は独自インデックスを構築することになり、それは事実上データベース
  • ファイルインターフェースは普遍的で LLM がすでに理解しているため強力であり、データベースベースの基盤レイヤーは実運用に必要な保証を提供するため強力
  • 未来はファイル対データベースではなく、ファイルが人間とエージェントが相互作用するインターフェースであり、その下にユースケースに合った基盤レイヤーが位置する構造

これはパーソナルコンピューティングの再定義である

  • ファイルシステムは AI 時代にパーソナルコンピューティングの意味を再定義し得る
    • データ・コンテキスト・好み・スキル・記憶がユーザー所有のフォーマットで存在し、どのエージェントでも読め、特定アプリケーションにロックインされない構造
    • aboutme.md は今日の OpenClaw/NanoClaw でも、明日の新しいツールでも機能
    • スキルファイルは持ち運び可能で、プロジェクトコンテキストはツールを越えて維持される
  • これは、すべてが閉じた SaaS アプリと独占的データベースへ移る前に、パーソナルコンピューティングが本来目指していた姿でもある
    • ファイルは本来のオープンプロトコルであり、AIエージェントがコンピューティングの主要インターフェースになるにつれて、ツール切り替え・ワークフロー結合・アプリケーション間の継続性維持を誰の許可もなく可能にする相互運用レイヤー
  • ただし理想主義的な側面もある。オープンフォーマットの歴史には、文書上は勝利しても実際には失敗した標準が数多くある
    • 企業には、自社のコンテキストファイルを微妙に異なるものにして乗り換えコストを維持する誘因が強い
    • CLAUDE.md と AGENTS.md と .cursorrules が1つの汎用フォーマットにならず併存していること自体が、断片化がデフォルトであることを示している
    • ETH Zürich の論文は、フォーマットが存在しても良いコンテキストファイルを書くのは難しく、悪いコンテキストファイルは存在しない場合よりも悪いことを思い出させる
  • Dan Abramov の核心的メッセージ:

    私たちの記憶・思考・設計は、それを生み出したソフトウェアより長く生き残らなければならない

    • これは技術的主張ではなく価値の問題であり、ファイルシステムがこの役割に適しているのは最高の技術だからではなく、すでにユーザーのものになっている唯一の技術だからである

関連記事

1件のコメント

 
GN⁺ 2026-03-09
Hacker News の反応

  • ファイルは、ユーザーがデータを直接所有できるようにする根源的な自由の形だと思う
    これは機密性・完全性・可用性における主権を可能にする
    デジタルの自由の中核的な柱として、FOSSライセンスと同等に認識されるべきだ

    • LLMの推論能力のおかげで、いまやファイル構造を心配しなくてよくなった
      自然言語そのものがファイル内に存在し、可読性がそのまま仕様になる
      読みやすい文章を書ける人なら誰でもファイルに書けて、REPLのように即座に実行できる
    • だからこそ、Appleのような大手テック企業がファイルという概念をなくそうとしているのが不快だ
      データをアプリに縛り付けて独立して存在できなくし、インポート／エクスポートも難しくしている
      私はこうした問題を解決するために、バックアップからデータを細粒度のファイル単位で抽出し、個人用デジタルライブラリへ移すツールを作っている
      不変データは保管だけで十分だが、変更可能なデータを再び「生きた」形にしてアプリで編集可能にするのが最大の課題だ
    • 設定ファイルはWindows Registryのような中央ストアよりはるかに優れていると思う
      一時的な変更や共有がしやすく、設定の意味も明確に定義される
      Windowsがファイルを三流市民のように扱う点が気に入らない

  • SaaSの観点から見ても同じ考えだ
    コードが一時的でドメイン特化であればあるほど、データ（ファイル）は標準的で退屈なほど安定的であるべきだ
    特定のアプリでしか読めないフォーマットは技術的負債であり、最終的にはプロジェクトを壊す
    JPEGのように1995年のファイルでも今なお開けるのは、ソフトウェアに従属していないからだ

    • 10年以上使っている自分の写真管理システムでは、ファイルシステムとEXIFを信頼できる唯一の情報源としている
      何度も検証されてきた正しいアプローチだ
      Google PhotosやImmichのような抽象化レイヤーは便利さのために過ぎず、核心はファイルにある
      仕事でもmarkdownやcsvファイルで研究と文書を管理している
      elodie プロジェクトのリンク
    • 最近の写真管理の問題は、編集・タグ・アルバム情報がすべて外部メタデータとして保存される点だ
      プラットフォームを移ると編集履歴がすべて消えてしまう
      元に戻す機能は便利だが、こうした変更が移植可能になるよう標準化されてほしい

  • Bell LabsのPlan 9に触れたい
    Plan 9 from Bell Labs

    • 私はagencというエージェント・オーケストレーターを作っている
      Claudeに先行研究を尋ねたらPlan 9を挙げてきたが、まさに今われわれに必要な概念がそれだ
      エージェント権限の最小化という哲学は、企業のセキュリティモデルと同じだ
      ただPlan 9の登場が早すぎただけだ
    • 新しいファイルシステムとしてはGeFSを見てみる価値がある

  • Plan 9とUNIXが正しかったことをあらためて実感する
    最も強力なインターフェースは、ファイルシステム上のテキストファイルだ
    いまこそ9p2026を作り直す時だ
    ただし記事の基本概念の一部は間違っている — ファイルシステムはツリーではなく、循環可能なグラフだ

    • Plan 9の中核機能が何なのか、FUSEで実現できるのか、それとももっと深い魔法が必要なのか気になる

  • 私にも深く共感できる話だ
    この1年で、10以上のSaaSから個人データをひとつのディレクトリ構造へ移した
    整理されたファイルシステムは単一ユーザーにとって十分で、データの断片化をなくしてくれる
    今後は、ファイルシステムを不透明にせずに安全なマルチユーザー書き込みを支援する新しいデータベースが登場しそうだ
    検索におけるQMDの役割に近い感じがする

  • いまはAI活用がまだ未成熟な段階にある
    本番システムは一貫性があり拡張可能なデータ構造の上で動くだろうが、それを作るエージェントはファイルシステムベースの技術を使うことになるだろう
    UIはデスクトップから離れ、音声・視覚インターフェースへ進化していくと思う
    たとえばビデオ通話で表情や声の調子を読み取り、より多くの文脈を得るような形だ

    • 最近見たAIデモ動画では、音声と身振りから文脈を抽出してテキスト化し、その後LLMに入力していた
      完全なマルチモーダルではないが、とても興味深かった
    • それでもテキスト入力はなくならない気がする
      書くことは思考を整理させ、話し言葉のように即興的ではない
      音声認識（STT）がどれだけ良くなっても、人間の知能は依然として書くことを中心に機能する

  • ファイルは見つけられるときにだけ役に立つ
    つまり検索とインデックスが不可欠だが、規模が大きくなると壊れ始める
    だから「エージェントが扱う知識ベースの大きさ」が核心的な問いになる
    私はこのテーマを「a good agentic KB」で第一原理から分析してみた

  • コードベースのようによく整理された複数ファイルでは、コーディングエージェントは情報をうまく見つけられる
    しかし散らかったデータは、ファイルシステムで構造化するのがはるかに難しい
    ベクトルDBで意味ベース検索をするより複雑だ
    コードベースはDRY原則のおかげで自然にグラフ構造を保つが、非コードデータはそうではない
    だからファイルシステムが長期的に良いコンテキスト構造だという点には同意するが、まだ検索を完全に置き換えるには至っていない

  • ファイルシステムはひどい抽象化だと思う
    ディレクトリツリーという意識的な構造にファイルをぶら下げなければならないのは非効率的だ
    関係モデルや一意識別子ベースの構造のほうが優れていると思う

    • ファイルシステムの利点は変更の局所性を保てることだ
      あるブランチでの変更が別のブランチに影響しない
      一方、データベースはUPDATEやDELETEが全体に影響し得るので危険だ
      だから現代のOSのように、ツリー構造の上にDBインデックスを載せる折衷案が理想的だ
    • NTFSは内部的にMFTデータベースを使っている
      ファイル名をb+treeでインデックスし、ファイルデータもMFTに保存する
      ディレクトリは単に「directory=true」という属性を持つ行にすぎない
      WinFSのような完全な関係型アプローチは性能問題で失敗し、Skydriveがその位置を置き換えた
    • ほとんどのファイルシステムでは、ファイルはinodeで一意に識別され、複数のリンクから参照できる
      この点はよく忘れられているように思う
    • UUIDは人間には不透明だが、エージェントにとっては完全に区別可能な識別子だ
      結局はS3スタイルのblobストレージに優れたインデックスを載せ、ディレクトリはタグのようにオンデマンド生成される方向へ向かう気がする
      「Q3関連の資料はこのディレクトリにある」といったグルーピング機能だけが残るような形だ