なぜ AI Agent は仮想ファイルシステムを採用し始めたのか

2026 年上半年、Coding Agent の作り方を見ると、どこでも同じパターンが見えます。モデルがホストのファイルシステムを直接読み書きするのではなく、チームはその間に仮想ファイルシステム（VFS）を挟みます——Cursor のサンドボックスツールや Claude Code のワークスペース抽象から、OpenHands、E2B、Modal 上のリモートサンドボックスまで。Agent はディスクと governable な API 層を介してやり取りします。

これは単なるマウントポイントの違いではありません。VFS は隔離、Token 予算、スナップショット、監査可能な変更という 4 つの役割を同時に担います。本記事では、2026 年に VFS がデフォルトになった理由、Memory 層との組み合わせ方、チームが選ぶ実装、iOS / クロスプラットフォーム開発者が VFS サンドボックスを クラウド Mac ビルド環境につなぐ方法を解説します。

* 一般的な monorepo 実験とベンダー推奨に基づく。repo 構成により異なります。

Agent 仮想ファイルシステムとは？

従来の IDE プラグインは LLM に read_file("/Users/...") を呼ばせます——パスがそのまま権限です。Agent VFS はモデルとストレージの間に制御 APIを挟みます：

• ls / tree：要約を返し、ツリー全体をコンテキストに載せない
• grep / glob：行単位ヒット付きのパターン検索
• read：Token 予算付きの範囲読み取り
• write / patch：構造化 diff
• snapshot / rollback：タスク単位のチェックポイント

モデルから見ればファイルツリーは同じですが、プラットフォームは各 I/O で計測・スロットル・監査・パス拒否ができます。「repo をコンテナに clone して bash を回す」とは違います。

2026 年に普及した理由

3 つの圧力が同時にかかり、VFS は最適化からデフォルトアーキテクチャになりました。

セキュリティ：Agent はマシンを所有してはいけない

Agent がシェル実行、設定編集、パッケージインストールを行うと、プロンプト注入 1 回が RCE に直結し得ます。2025–2026 年の「Agent が repo を消した」「誤って ~/.ssh を編集した」といった事例を受け、製品はサンドボックスをデフォルトにしました：

• パス許可リスト：プロジェクトルートと /tmp 配下のみ
• ネットワーク egress 制御：npm/pip はプロキシ経由、任意の内部 curl はブロック
• 認証情報の隔離：API キーは VFS 外、ゲートウェイが注入

VFS は単一の強制ポイント——各ツールに if path.startswith を散らすよりクリーンです。

Token：コンテキストは無料のディスクではない

AI プログラミングの実際の月額コストで示したように、10 万行の monorepo をプロンプトに詰め込むと 1 回あたり数ドルかかります。VFS は「コードを所有する」を「必要なときだけ取得する」に変えます：

1. grep "class FooBar" で場所を特定
2. read path:42-80 で関数を読む
3. patch は diff のみ返す

これは DeepSeek、Claude Code、Cursor の選び方を補完します：入る ≠ 入れるべき。VFS はプロダクトレベルの Token 経済です。

スナップショット：ロールバックと再現性

10 ファイル編集後にビルドが壊れる——ユーザーは「5 分前に戻したい」と言います。各 write 前の VFS スナップショット（オーバーレイ FS、git stash など）はタスク状態をバージョン管理します。次の場面で重要です：

• チームで共有するクラウド Agent セッション
• PR を無人で直す CI ボット
• モデルが何を変えたかコンプライアンスに示す必要がある企業

Memory は嗜好を覚え、VFS スナップショットは今回の実行で何が変わったかを覚えます——時間軸が違います。

誰が何を使っているか

共通点：モデルは生の open() システムコールを持たない——スキーマ付きツール呼び出しのみ。だから Claude Code Skills は安全に能力パックを配布できます：Skills が許可パス/ツールを宣言し、VFS が強制します。

VFS と Memory 層

VFS を Mem0、Zep、TencentDB Agent Memoryと混同しないでください：

成熟したスタックは3 層：VFS は「今編集しているもの」、Memory は「このユーザーが常に望むもの」、実 macOS は「コンパイルして出荷できるか」。

実装の比較

自前で VFS を作るなら、10 万ファイルで grep <2 秒とアトミック patchを優先。多くのチームは下に git worktree、上に VFS をポリシー + Token ラッパーとして載せる——実用的な MVP です。

iOS / クロスプラットフォーム開発者向けの実践パス

Flutter / React Native チームは、VFS サンドボックス内で flutter build が通れば出荷準備完了だと思いがちです。実際は：

1. VFS サンドボックス：Agent が Dart/Swift を編集、ユニットテスト実行、PR 文を下書き
2. Memory：テスト端末 UDID、TestFlight のみ、前回プロファイル期限切れ
3. クラウド Mac：実 xcodebuild、アーカイブ、App Store Connect アップロード

RN / Flutter の iOS 実機デバッグと App Storeを参照。Apple のツールチェーンはハードウェアと macOS に縛られます。VFS は安全なコード編集、Zilmac クラウド Macは Apple 環境でコンパイル・出荷するビルドを担います。

推奨パイプライン：ローカルまたはクラウド VFS サンドボックスで feature ブランチを完了 → Memory がビルド制約を記録 → webhook がクラウド Mac CI を起動 → 失敗ログのサマリーが次の Agent セッション用に Memory へ書き戻し。

推奨事項とアンチパターン

推奨プラクティス

• デフォルト deny-all のパスポリシー；ディレクトリは明示的に許可
• N KB を超えるツール出力は VFS ファイルへ；コンテキストにはサマリー + パスのみ
• タスク終了時、未マージの重要 diff を Memory または issue に同期
• ビルドと署名は VFS と物理的に分離——Agent がプロビジョニングプロファイルに触れない

アンチパターン

• ❌ VFS をビジネスデータの JSON DB にする——Memory か本物の DB を使う
• ❌ Agent に node_modules 全体を read させる——Token のブラックホール
• ❌ スナップショットなしの薄いホストパスラッパー——ロールバック不能
• ❌ VFS が Xcode を置き換えると期待する——署名と実機デバッグは依然 macOS が必要

FAQ

Agent VFS と Docker マウントの違いは？

Docker は実パスセマンティクスを保ちます。Agent VFS は Agent API に加え Token 予算、スナップショット、許可リストを足します——コンテナではなく抽象化層です。

Memory があれば VFS は不要？

いいえ——役割が違います。Memory はセッション横断の嗜好とタスク履歴、VFS は単一タスク内のコードツリー読み書きとツール出力バッファです。上の表を参照。

VFS は Xcode プロジェクトディレクトリを置き換えられる？

署名とビルドには不可ですが、Agent がコードを編集する安全性は大きく向上します。実用的な組み合わせ：VFS サンドボックス + クラウド Mac ビルド。

カスタム Agent 用の VFS はどう選ぶ？

プロトタイプは git worktree；本番は隔離要件で選ぶ——OpenHands、E2B、またはカスタムゲートウェイ。grep 性能、スナップショット、マルチテナント隔離をベンチマーク。