RAGは「それなりに動く」だけだった

ドキュメント検索にRAG（Retrieval-Augmented Generation）を使っている開発チームは多い。でも正直なところ、RAGは「クエリに似たチャンクを引っ張ってくる」だけで、答えが複数ページにまたがっていたり、正確な構文が必要だったりすると途端に使い物にならなくなる。

ドキュメントツール「Mintlify」のエンジニアリングチームは、そのRAGの限界を正面から認めて捨てた。そして代わりに**バーチャルファイルシステム（ChromaFs）**を構築した。このアプローチがAIエージェント設計の考え方として非常に示唆に富んでいる。

エージェントはファイルシステムで育つ

そもそも、なぜファイルシステムなのか。

AIエージェントが自律的にドキュメントを探索するとき、grep、cat、ls、find というUNIXの基本コマンドさえあれば事足りる。各ドキュメントページをファイル、各セクションをディレクトリとして扱えば、エージェントは自分で構造を辿りながら必要な情報を探し当てられる。これはRAGの「クエリ→チャンク返却」という受動的な仕組みとは根本的に違う。

エージェントが能動的に探索する——これがポイントだ。

本物のサンドボックスでは使い物にならなかった

「じゃあ本物のコンテナ環境を与えればいいじゃないか」と思うかもしれない。Mintlifyも最初はそのアプローチを試みた。Daytonaなどのサンドボックスを使ってGitHubリポジトリをクローンする方式だ。

しかし結果は散々だった。

  • P90起動時間：約46秒（ユーザーがローディングスピナーを眺め続ける時間）
  • コスト試算：年間7万ドル超（月85万会話 × 1vCPU/2GiB RAM × 5分セッションの概算）

フロントエンドで「ユーザーが待っている」状況で46秒は死刑宣告に等しい。インフラコストも非現実的だ。

ChromaFs：シェルの幻想を作り出す

Mintlifyが取った解決策は「本物のファイルシステムは要らない、シェルの幻想を作ればいい」という発想の転換だった。

ChromaFsの仕組みはシンプルかつ巧妙だ：

  • 既存のChromaDBを再利用: RAG向けにすでにインデックス・チャンク化されていたドキュメントDBをそのまま活用
  • just-bash（Vercel Labs製）上に構築: TypeScriptでbashを再実装したライブラリ。IFileSystemインターフェースをプラガブルに提供
  • UNIXコマンドをDBクエリに変換: grep → ChromaDBのメタデータクエリ、ls → インメモリのディレクトリツリー参照
  • ファイルツリーはgzip圧縮JSONで保持: __path_tree__という特殊ドキュメントとしてChromaに格納し、初期化時に展開

結果として達成したのが以下のパフォーマンス改善だ：

指標 サンドボックス方式 ChromaFs

P90起動時間 約46秒 約100ms

1会話あたりコスト 約$0.0137 $0（DB再利用）

検索方式 ディスクスキャン DBメタデータクエリ

46秒が100ミリ秒に。460倍の高速化だ。

実務への影響——日本のエンジニアが今日から考えるべきこと

1. RAGの「とりあえず動く」で止まっていないか確認する

社内ドキュメント検索やナレッジベースにRAGを導入している企業は多い。しかし「チャンク返却」モデルの限界——複数ページにまたがる情報、正確な構文の取得——に直面しているなら、このアーキテクチャ転換は真剣に検討する価値がある。

2. エージェントに「探索する手段」を与える設計を意識する

RAGは「教える」アーキテクチャ、ファイルシステムは「探索させる」アーキテクチャだ。AIエージェントに自律的な行動を求めるなら、ツールセット（grep/cat/ls相当の操作）を与える設計が本質的に合っている。

3. 既存インフラの再利用を先に考える

Mintlifyの肝は「新しいインフラを作らず、すでにあるChromaDBを賢く再利用した」点だ。コスト削減の多くは新規投資ではなく既存資産の見直しから生まれる。

4. ユーザー体験が要件を決める

「46秒待てますか？」という問いに「待てない」と判断したからこそ、この設計変更が生まれた。技術選択はユーザー体験の要件から逆算すべきで、技術の都合をユーザーに押しつけてはいけない。

筆者の見解

この事例、正直かなりアツい。

いま一番面白いのはハーネスループの設計——エージェントが自律的に判断・実行・検証を繰り返す仕組みを作ること——なのだが、そのループを成立させるには「エージェントが探索できる環境」が不可欠だ。ChromaFsはまさにそれを実現している。

RAGは所詮「人間がクエリを投げてチャンクが返ってくる」受動的な仕組みで、エージェントが自律的にループを回す世界には根本的にミスマッチだ。Mintlifyはそれを正しく見抜いた。

「エージェントにはgrep、cat、ls、findで十分」という洞察も素晴らしい。複雑なツールチェーンを渡してエージェントを混乱させるより、UNIXの枯れた道具を仮想的に与えるほうが遥かにシンプルかつ強力——これは多くのエージェント設計にも応用できる考え方だ。

日本の現場でドキュメントAIを検討しているチームはいくつかいるだろうが、RAGを「とりあえず動く」で入れて満足しているところが大半だと思う。正直もったいない。技術的な優位性は「どう取ってくるか」ではなく「どう探索させるか」の設計にかかっている。ChromaFsのコード自体はオープンに公開されているので、まず読んで試してみることをガンガン勧める。

出典: この記事は We replaced RAG with a virtual filesystem for our AI documentation assistant の内容をもとに、筆者の見解を加えて独自に執筆したものです。