FUSEがあれば全てが手に入る – エージェントにファイルシステムを通じてあらゆるものへのアクセスを提供する

95日前原文(jakobemmerling.de)

概要

エージェントにシェルとファイルシステム付きのサンドボックス環境を提供する最新トレンドの解説
FUSEを活用し、任意のデータベースやAPIを仮想ファイルシステム化する実装パターンの紹介
メール管理エージェントを例に、実際のファイルシステム設計と操作方法を具体的に説明
ファイルシステム抽象化の利点と、エージェントへのアクセス方法のポイント整理
実装例・デモを通じ、現実的な運用・同期・拡張の考慮点までカバー

エージェント × サンドボックス型ファイルシステムの潮流

Turso’s AgentFSやAnthropic’s Agent SDKなど、主要AIラボがサンドボックス＋ファイルシステム環境を活用したエージェント開発を強化
Bashツールによる操作統合で、複雑なツール群を一元化し直感的な操作連鎖を実現
プラン・一時ファイルや長文コンテキスト管理など、ファイルシステム特有の新しいパターンが自然発生
既存領域への適用課題として、データ同期・編集反映・部分的なファイル表示などの設計が必要

ファイルシステム化の現実的な課題

メール管理やGoogle Driveのような既存プラットフォームを仮想ファイルシステムにマッピングする際の悩み
- いつ・どの範囲でファイルをコピー/同期するか
- エージェント・人間による編集の反映タイミング
- フォルダ/ファイルの段階的表示・長文履歴管理
API＋DB＋オブジェクトストレージをサンドボックスFSに落とし込む具体的なパターンの不足

FUSEによる「何でもファイルシステム化」パターン

**FUSE（Filesystem in Userspace）**により、Linuxカーネル外で任意のデータ構造を仮想ファイルシステムとして公開
必要なインターフェース：lookup, open, read, write, readdir, create, unlinkなど
高水準言語バインディングも充実し、C言語不要で実装可能
アーキテクチャ例
- 従来：UI→バックエンド→DB
- エージェント経由：サンドボックス内でFUSEマウント→DBクエリと連携
- ファイルシステムはエージェント向けのUIレイヤーとして機能

メール管理エージェントのファイルシステム設計例

仮想レイアウト例
- workspace/
  - Inbox/
  - Starred/
  - Needs_Action/
  - Orders/2026/Feb/
  - Customers/Returns/
  - Sent/
readdir実装でフォルダ内メール・サブフォルダを動的リスト化
read実装でメール本文やメタ情報をファイル内容として返却
**仮想フォルダ（Starred/Needs_Action）**はシンボリックリンク活用で実現
- フラグ付きメールを自動で反映
- symlink/unlink操作による属性変更も可能
設計のポイント：ファイルシステムの直感的な意味付けと、過剰抽象化回避のバランス調整

実装・運用上の注意点

Docker環境でFUSEマウントをテスト、DB直結で同期ズレなし
必要なデータのみ都度ロード、全件プリロード不要
macFUSEなど他OSでも動作可能だが、Linux/Dockerが手軽

エージェント連携とプロンプト設計

Anthropic Agent SDKなどと連携し、Bash/Read/Globツールを提供
ファイルシステム構成や操作ルールをシステムプロンプトで明示
- 例：「ファイル名は必ずクォート」「mvでフォルダ移動」「ln -sでスター付与」など
ユーザーへの説明は自然言語で要約し、システム操作語は使わない

実際のエージェント応答例

「Inbox内のメールを一覧表示して」と指示→lsコマンドで取得、件名＋送信者＋日付で自然言語要約
「特定メールの内容を読んで」「スターを付けて」「フォルダを移動して」なども直感的に対応可能

まとめ：ファイルシステム抽象化の利点と応用

エージェント設計におけるファイルシステム抽象化は、ツール設計・データ整理・長文文脈管理に大きなメリット
FUSE活用で既存DBやAPI資産を柔軟に仮想FS化
現実的な運用には、設計バランス・同期方法・セキュリティ・拡張性の考慮が不可欠
ドメインごとに最適なFSマッピングを設計することが、エージェントの使いやすさと拡張性の鍵

Hackerたちの意見

個人的には、実際のファイルシステムにはcgroupsやnamespacesを通じてビューを提供するだけでいいと思う。LLMのためにファイルシステムとしてデータベース抽象を実装するのは、ただの間接的な層を追加するだけのように感じる。LLMには、いくつかのビューやクエリ、ストアドプロシージャを書かせて、適切なアクセス権限を与えればいいんじゃないかな。LLMはデータベースやメールを使うのにFUSE層なんて必要ないし、権限やビューで不適切なことをするのを防げる。アクセスと権限は本来あるべきところに置いて、FUSE層には置かない方がいいし、クロスプラットフォームで展開したいときに面倒なライセンス問題に悩まされるような変な抽象を維持する必要もない。あと、簡略化したFUSEの抽象は、実装が本当に包括的でない限り、世界の状態に正確にマッピングされないから、その状態を正確に扱うためには直接やり取りした方がいいかもね。

└

ファイルへの遠すぎるマッピングはあまり意味がないっていうのには同意だな。メールの例は、実際の世界からのインスピレーションというよりは、アプローチの柔軟性を示すためのものだと思う。実際のファイルシステムとデータベース内の非ファイルなものとの間にはギャップがあって、アプリケーションの表現をファイルシステムにマッピングするのが役立つ場合がある。基本的に、ユーザーがさまざまな目的でファイルをアップロードしてそれを扱うプラットフォーム（例えばGoogle DriveやNotionなど）では、ファイルをエージェントにファイルシステムを通じて表現する方が、モデルがトレーニング中に見たことのない自作ツールよりも直感的で強力なインターフェースになる。

└

自分の経験では、LLMはSQLが得意だよ。

おかえり、Plan9！

└

ずっと残ってるよ :p （Plan9のアクティブなフォークがまだあると思うし、Plan9自体がLinuxのいくつかの機能に影響を与えたって聞いたことがある）

└

さらに言うと、9Pプロトコルもあるよね。https://en.wikipedia.org/wiki/9P_(protocol) これの最もメインストリームな使い方は、Windows Subsystem for Linux (WSL)での利用かもしれない。

最近FUSEにちょっとハマってるんだ。友達のアイデアを盗んで、既存の非CoWファイルシステムにCoW機能を追加する方法を考えて、ext4用のFUSEドライバーをハックしてる。FUSEを学ぶために、まずはマウントできるファイルシステムを作ることから始めたんだ。Cassandra用のFUSEドライバーを書いたり、CouchDB用のFUSEドライバーを書いたり、Base64エンコーディングでJSONファイルを書くだけのもの用のFUSEドライバーも作った。どれもあまりパフォーマンスが良くなくて、コードがひどいから公開してないんだけど（学習用プロジェクトだったし）、FUSEはすごく楽しくて書きやすいと思ったよ。みんなもぜひ遊んでみてほしい。

└

gitのためにFUSEフロントエンドを書くのは特にやりがいがあるよ。gitは内部的にファイルシステムのように整理されてるからね。

実際にこれを実装しようとしたこともあるけど、結果的に本当に悪いアーキテクチャになっちゃった。ファイルシステムを抽象化するのは、基本的なユースケースを超えるとあまり良くない。例えば、メールを探す必要があると想像してみて。grep（FUSE経由）を使うと、たくさんのファイルを開くことになって、APIにアクセスすることになって遅くなる。これを最適化することはできるし、最初の取得後はキャッシュも効くけど、方法自体が遅い。代わりに既存のAPIを利用すれば、何百万倍も速い。FUSE経由で検索のように機能する特別なファイルを作ることもできるけど、それは変だし、モデルがそんなにマイナーなものにうまく対応できるとは思えない。実際にこのアイデアをRustで実装して試してみたけど、結局はダメだったから捨てちゃった。

└

> grep（FUSE経由）を使うと、たくさんのファイルを開くことになって、APIにアクセスすることになって遅くなる。これはPOSIXファイルシステムインターフェースの制限だね。もしgrep()システムコールがあれば、検索をファイルシステムに委任できて、全文検索インデックスを使ったり、リモートサーバーで実行したりできるかもしれない。

└

> 抽象としてのファイルシステムは、基本的な使い方を超えると実際にはあまり良くないよね。例えば、メールを探す必要があると想像してみて。FUSEやMCP[1]エージェントとは関係ないけど、このシナリオはnmh[0]をメールクライアントとして使ってた時を思い出させる。nmh[0]が魅力的な理由の一つは、awkやfind、grep、sedなどを使ってメール処理をスクリプト化できることなんだよね。0 - https://www.nongnu.org/nmh/ 1 - https://en.wikipedia.org/wiki/Model_Context_Protocol

自分のLLM/エージェントフレームワークでは、仮想ファイルシステムの抽象化を選んで、仮想ファイルシステムのマウントや権限設定のためのヘルパーを実装したよ。: https://github.com/rescrv/claudius/blob/main/src/agent.rs#L1...

先月はFUSEマウントを作ってたんだけど、今は他に何ができるか考えずにはいられない。

コメントしてるほとんどの人に同意するな。これは目的がはっきりしない抽象化に見えるから、あまり良くないと思う。特に、REST APIのラッパーとしてFUSEを使うのは非効率的で冗長だよ。LLMはAPI仕様がどんな形式でもcurlを使ってもっと効果的に扱えるからね。

それか、ストレージコンビネーターみたいなものを実装するのもアリだよ。[1][2] 基本的にはファイルシステムのような抽象化だけど、ファイルシステムは必要ないんだ。もちろん、ストレージコンビネーターをファイルシステムとしてエクスポートしたり、ストレージコンビネーター経由でファイルシステムにアクセスすることもできるよ。[1] https://dl.acm.org/doi/10.1145/3359591.3359729 [2] https://2019.splashcon.org/details/splash-2019-Onward-papers...

みんな、コンピュータで複数のユーザーを実行できることを忘れちゃったの？ファイルの権限を正しく設定すれば、エージェントはそれを読めないんだよ。エージェントは、マルチユーザーのコラボレーションのために設計されたUnixベースのコンピュータで使われるんだから、シンプルな解決策を選べばいいのに。

└

30歳未満の人たちは、複数のユーザーで1台のコンピュータを共有できるってことを覚えてると思う？昔は家に「ホームコンピュータ」や「PC」が1台だけあって、ユーザーや権限について学んだよね。あの頃のユーザーじゃなかったり、管理作業をちょっとでもやったことがなければ、2026年にはこれを知らないかもね。

これに関して、全てのLLMエージェントが「全てはファイル」という制約に従う仕様をまとめたよ。FUSEファイルシステムをそのように使ってる。あと、過剰設計になってるか、技術的負債を抱える可能性がある部分を説明するための制限文書も作成した。 https://github.com/jimmc414/AgentOS

ハクソク