ハクソク

世界を動かす技術を、日本語で。

ファイルは人間とエージェントが相互作用するインターフェースです

46日前原文(madalitso.me)

概要

  • AIエージェント分野でファイルシステムの再評価が進行中
  • ファイルによる永続的な文脈管理の重要性と課題
  • 標準化やフォーマットの分断問題
  • ファイル vs データベースの役割分担の現状
  • 個人コンピューティングの未来とファイルシステムの価値

AIエージェントとファイルシステムの再発見

  • かつてベクターデータベース企業で「AI用途に特化したデータベース」の必要性を伝える仕事を担当
  • 現在、AIエージェント業界でファイルシステム活用への関心が急速に高まっている状況
  • LlamaIndexの「Files Are All You Need」やLangChain、Oracleなどがファイルシステムとデータベースの比較・活用を議論
  • Jerry Liu（LlamaIndex）は「多機能エージェントより少数ツール＋ファイルシステム」の時代を指摘
  • Karpathyは「Claude Codeが成功する理由はローカル環境で動作し、ユーザーデータや文脈に直接アクセスできる点」と分析
  • 実際のAI活用の大半がコーディングエージェントであり、CLIツールとしてのClaude Codeが商業的にも成功

文脈ウィンドウと記憶の違い

  • LLMのコンテキストウィンドウは「記憶」ではなく、ホワイトボードのような一時的なもの
  • Claude Codeの「context left until auto-compact」通知が示すように、文脈が圧縮・消失する不安
  • ファイルシステムは「書き残し・後から読み返す」ことで永続的な文脈を実現
  • CLAUDE.mdやaboutme.mdなど、エージェントが読める文脈ファイルが普及
  • しかし、ETH Zürichの論文によると「文脈ファイルがタスク成功率を下げ、推論コストを増加させる」場合も
    • エージェントがファイルを過剰に参照し、目的達成が遅延
    • 文脈ファイルは最小限・必要十分な要件に絞るべきとの結論

ファイルフォーマットの標準化とAPI化

  • 現在、CLAUDE.mdやAGENTS.md、copilot-instructions.mdなど多様な文脈ファイル形式が乱立
  • Dan Abramovの「ソーシャルファイルシステム」論は「ファイルフォーマット＝API」の考え方を強調
    • 各アプリが自分の形式をネームスペースで管理し、競合を回避
    • データベースは各アプリの「フォルダの派生データ」として機能
  • エージェント文脈ファイルも「統一」より「共存と非衝突」が重要
  • AnthropicのSKILL.md形式は、MicrosoftやOpenAIなど複数社が採用するオープン標準へ
  • NanoClawは「スキル＝ファイル」として、ポータブル・監査可能・合成可能な仕組みを実現
  • MarkdownやSKILL.mdを理解できれば、パートナーシップや標準化会議不要で機能共有が可能

ボトルネックの変化とファイルvsデータベース

  • 従来は「ストレージがボトルネック」だったが、現在は「文脈がボトルネック」
  • モデル自体は十分賢いが「記憶力が弱い」ため、ファイルシステムが永続的文脈管理に有効
  • ファイルシステムはインターフェースとして優秀だが、同時アクセス・大規模検索・重複排除等ではデータベースが必要
  • ファイル＝人間とエージェントの窓口、データベース＝基盤という棲み分けが現実的

ファイルシステムと個人コンピューティングの未来

  • ファイルシステムは「個人コンピューティング」の再定義をもたらす可能性
    • データや文脈、スキル、記憶がユーザー所有のフォーマットで保存
    • aboutme.mdはどのAIエージェントでも利用可能
    • スキルファイルやプロジェクト文脈がツール間で持ち運び可能
  • ファイルは「オープンプロトコル」として、アプリ間の相互運用性レイヤーに
  • 標準化や相互運用の理想と現実のギャップも存在
    • CLAUDE.mdやAGENTS.mdなどの分断
    • 良い文脈ファイルを作る難しさ、悪いファイルは逆効果という課題
  • Dan Abramovの「記憶や設計はソフトウェアの寿命を超えるべき」という価値観
  • ファイルシステムは「最良の技術」ではなく「すでにあなたのもの」である点が最大の強み

Hackerたちの意見

同じようなことを感じてたけど、ちょっと違う視点からね。SaaSの話。コードは一時的で特定のドメインに特化しがちだけど、データ（ファイル）はつまらない標準に従うべきだと思う。今の問題は、特定の短命なアプリを作って、そのアプリだけが読める形式にデータをロックしちゃうこと。普遍的なフォーマットを使わないと、システムは脆弱になるよね。1995年のJPEGも開けるのは、ファイルが作成に使ったソフトに依存してないから。マイナーな形式や独自形式を使うのは、結局プロジェクトを潰す技術的負債になるだけ。ファイルか、忘れるかだね。
└
10年以上使ってる写真管理システムは、ファイルシステムとEXIFを全ての写真ライブラリの真実の源としてるんだ。これが正しいアプローチだって何度も証明されてる。抽象化（昔のGoogleフォト、今のImmich）はその上に構築されるべきだけど、これらの独自データベースは便利さのためだけ。仕事では、著者と同じような体験をしてて、Claude Codeのために全てがマークダウンとCSVファイルになってる（研究や文書作成用に）。
└
最近の写真管理でイライラするのは、主要な写真ライブラリアプリやクラウドサービスが、すべての編集やタグ、アルバムを外部で保存することだよね。写真をトリミングしたり、撮影日時を変更したりしても、元のファイルには手を加えず、外部のメタデータが作成されるだけ。だから、プラットフォームを移動するたびに、これらの編集やアルバムが消えちゃうんだよね。トリミングやフィルターを元に戻せるのは便利だけど、業界全体で標準化して、こういう変更が持ち運べるようになってほしいな。
すごく共感する。去年、約10個のSaaSシステムから個人データを一つのディレクトリ構造に移したんだ。エージェントは人間よりも断片化に高いコストを払ってる。よく整理されたファイルシステムは、その断片化を解消してくれる。これで一人プレイには十分だと思う。低いマルチプレイヤー（安全な書き込みとか）シナリオを可能にする新しいデータベースが出てくるんじゃないかな。QMDが検索に対してやってるように。
ここでの裏の影響はBash()だと思う。ファイルシステムの関連性は、エージェントをオペレーティングシステムに置いて、完全な能力を与えることにちょっと偶然的に関係してる。
参考までに: ベル研究所のPlan 9。
└
今、エージェントオーケストレーターを作ってるんだけど（宣伝: https://github.com/mieubrisse/agenc）、Claudeに過去の事例について聞いてみたんだ。そしたらPlan 9が出てきて、びっくりしたよ。これが今必要なものだと思う。エージェントの権限を最小限に抑えることを、企業がやってるのと同じように考える必要があると確信してるから。Plan 9はちょっと早すぎたね。
└
新しいデバイスのファイルシステムについては、GeFSをチェックしてみて。
中間でのロスト効果がどれくらいあるのか、特にポストコンパクションの「シーディング」を最適化するためのツールがあるのか気になる。オープンスペックで直面した問題の一つは、コンパクション後や新しいセッションを開始する際に、すでに約50kトークンからスタートしちゃうこと。実際のコーディングが始まる前に、中間でのロストタイプの影響を受けやすくなってると思う。
コードベースに似たファイルがいくつかあって、よく整理されてると、コーディングエージェントやハーネスは情報を見つけるのが得意だよね。彼らは明らかにそれらをトレーニングしてるから、どんどん良くなる。課題は、エージェントが使えるように雑なデータをファイルシステムとして構造化すること。これは、セマンティッククエリのためにベクターデータベースをクエリするよりもずっと難しい。エージェントを使ってきたコードベースは何年もかけて手入れされてきたし、DRYのような原則があって、答えを一つの場所に置くようにしてる…システム内の全てのアクターがそれを維持するために投資してるんだ。雑なデータにはこれが当てはまらないから、著者の言うことには賛成だけど、時間をかけて文脈を持つためにはファイルシステムが良い構造だとしても、非コードデータに対してはまだ検索を置き換えてないよね。
脱線: ファイルシステムはひどい抽象化だよね。儀式的なファイルツリー、枝がディレクトリで、特定の枝にファイルをクリスマスオーナメントみたいにぶら下げなきゃいけない。リレーショナルの方がいい。ユニークな識別子があればなお良し。データストアを整理するためのもっといい方法がたくさんあるよ。
└
俺もずっと考えてたんだけど、UUIDってさ、俺たちには全然わからないよね。でもエージェントにとっては、2つのUUIDは昼と夜のように全然違うんだよね。最適なファイルシステムって、S3スタイルのブロブストレージに良いインデックスがあって、全てのデータの場所がちょっとわかる感じなのかな？ディレクトリが解決する一つのことは、グルーピングの仕組みとしてすごく優れてるってこと。「Q3のデータはこのディレクトリに全部ある」って感じで、ファイルがUUIDだけになって、ディレクトリ構造が必要に応じて作られる世界に向かってる気がする、タグみたいに。
└
ほとんどのファイルシステムでは、ファイルはinodeで一意に識別されていて、複数のファイルから参照できるんだ。なんでみんなリンクのことを忘れちゃうの？
└
NTFSにはデータベース、MFTがあるよ。ファイル名などの属性をインデックスできる、b+treeだね。ファイルの$DATAもMFTに配置されるけど、収まらない場合はNTFSが仮想クラスタ番号（MFTの属性が増える）を割り当てて、ファイルのディスク上のデータ構造を指すようにするんだ。全てのファイルは行と列のあるテーブルで表現される。「ディレクトリ」は、単に行に「directory = true」っていう特別な属性があるだけ（簡略化）。階層は人間のためのものだよ。多くのファイルシステムと同様に、NTFSも回復やロールバックのためのログを含んでる。リレーショナルではないけど、リレーショナルである必要もないよね。ファイルについて知っておくべきことを全部含むのに、なんで複数の「テーブル」が必要なの？MicrosoftはWinFSを試したけど、伝統的なファイルシステムじゃなかった（普通のNTFSボリュームの上にあったMSSQLデータベースのBLOBストレージだった）。パフォーマンスは悪くて、Skydriveがそれに取って代わった（MSFTの見解では）。
└
ファイルシステムには、変更がローカリティを保つという特性があるんだ。一つの枝に対する変更は、他の枝には影響しない（リンクを除いて）。データベースにはこの特性がないから、UPDATEやDELETEは条件によってはどの行にも影響を与える可能性がある。これが強力だけど、怖いところでもあるよね。ファイルを削除するたびに、クエリを間違えたらrm -rf /になるなんて嫌だ。最良の妥協点は、現代のOSが持っているものだと思う。ファイルを保存するための木構造と、その上にクエリ用のデータベースインデックスがある感じ。
またしてもPlan9とUNIXが正しかったことがわかったよ。最も強力で、共通のインターフェースは、ファイルシステム上に露出したテキストファイルなんだ。さあ、9p2026を作り直そう。だけどこの記事は基本的なことを完全に間違えてるね。ファイルシステムは完全なグラフであって、厳密な木構造じゃないし、絶対に非循環的でもない。
└
それで、Plan 9のキラーフィーチャーって何なの？FUSEで追加できるのか、それとももっと深い魔法があるのかな？
この文章は、今のAIの使い方の未熟さを表してると思う。生産レベルのシステムは、ファイルシステムのスキルを持ったエージェントによって書かれるかもしれないけど、生産システム自体は一貫性があってスケーラブルなデータ構造の上で動くことになるだろうね。一方で、AIエージェントのUIは、ほぼ確実にデスクトップコンピュータから音声/視覚インターフェースに進化していくと思う。エージェントは、トーンやボディランゲージを使って、君との間のバンド幅を増やすことができるから、ズームコールからもっとコンテキストを得るかもしれない。
└
書いたプロンプトはなくならないと思うよ。書くことで思考を整理できるし、話すのは、うーん、あ、待って、違う、ちょっと待って、っていうのとは違うからね。書いたものは送信する前に戻って修正できるし。話し言葉でプロンプトを受けた人は、必ず「待って、違う、もう一度やり直して」ってなるから。STTは確実に良くなるだろうし、もうかなり良いけど、テキストが完全になくなるとは思えない。人間の知性（HI）は、話すことだけが唯一のインターフェースになるようには機能しないからね。
└
最近、トーンやボディランゲージから文脈の手がかりを得ようとしているAI企業の動画を見たよ。彼らはそれをテキストに変換して、LLMに入力しているみたいだから、ネイティブのマルチモーダルではないけど、すごく面白いと思った。