FUSE AI Agents 2026：信頼性の高い推論のための Plan/Scratch
2026年1月24日Ollie @puppyone
要点
- plan.md、scratch.md、decisions.json、trace.log によるロングコンテキストの外部化は、マルチステップ推論を安定させ、デバッグを日常化する。
- FUSEベースのマウントにより、エージェントは標準的なPOSIXセマンティクス（ls/grep/mv/append）で動作し、専用ツールラッパーを減らし再現性を高める。
- MCPはエンタープライズシステムへの標準ブリッジ、ファイルシステムは統一されたローカルワークスペースを提供し、両者でガバナンス可能で観測可能なワークフローを実現する。
- ローカルファースト/オンプレのデプロイはコンプライアンスとデータ居住に合致し、タスク別マウントとパスレベルACLで最小権限を強化できる。
- ベンチマークはまだ黎明期。パフォーマンス主張は仮説として扱い、評価方法とオブザーバビリティを優先する。
ロングコンテキストではなぜファイルが一時的なプロンプトに勝つか
計画・中間成果物・決定がファイル（plan.md、scratch.md、decisions.json、trace.log）に記録されると、トークン窓内で薄れていく記憶ではなく、推論の「真実の源」になる。ファイルはバージョン管理、diff、チェックポイントを提供する。計画の変遷を振り返り、悪いブランチをロールバックし、既知の状態から実行を再現できる。ファイルシステムは監査できるエージェントの作業記憶であり、推測するしかない見えないプロンプトスレッドではない。
Jakob Emmerlingの2026年初頭のエッセイは「ファイルシステムファースト」エージェントの概念的なケースを述べ、メールをディレクトリとして扱うパターンやPOSIXのread/write/list/moveを自然なエージェント動作として示している。「FUSE is All You Need – Giving agents access to anything via filesystems」を参照。ガバナンスされたコンテキスト層の重要性は How LLM Agent Architectures Work で議論した。
実務上の利点は再現性。decisions.json や trace.log のようなファイルは「何が起きたか・なぜか」の決定論的トレースを提供する。またエンジニアとエージェントの協働を改善する—人間が plan.md を読み、セクションを編集し、エージェントに続行させられる。専用ツールは不要。
実行例 — マルチリポジトリのエンジニアリング知識と plan/scratch ワークフロー
具体例：/workspace/repoA、repoB/docs、patterns、plans/plan.md、scratch/scratch.md、logs/trace.log、state/decisions.json。エージェントは慣れ親しんだPOSIX操作（ls、grep、mv/cp、echo >>、diff/patch）を使う。ライフサイクル：(1) plan.md を目的と制約で作成・ロード。(2) scratch.md で反復：スニペットを試し、発見を記録し、ブロッカーをメモ。(3) decisions.json に決定と理由・タイムスタンプを記録。(4) trace.log にアクションとエージェントアクションIDを記録。(5) 検証済み成果物をスクラッチから適切なリポディレクトリに昇格し、MCP経由でPRをオープン。複数リポのエンジニアリング知識に有効な理由は、エージェントが「ファイルで考え」、専用アダプタなしでリポ横断で動作できるから。ファイルシステムが一つの抽象化を提供し、MCPサーバーが標準インターフェースで外部システム（Issueトラッカー、CI、ドキュメントストア）を公開する。
FUSE AIエージェントとMCP連携の実装パターン
- SQLiteバックのローカル専用FUSE：開発マシンと小規模パイロット向け。AgentFS提案（Penberg）。
- DBバック仮想FS（ローカルはSQLite、のちにSupabase等）：Turso「AgentFS FUSE」ノート。
- オブジェクトストアバックのAgentFS：大規模組織向け、ストレージを分離しキャッシュ付き仮想FSをマウント。
MCPは外部ツール（Issueトラッカー、CI、ドキュメントストア、内部サービス）への標準ブリッジとして扱う。参照：MCP1周年仕様、MCP認可更新、Anthropic MCPでのコード実行、JetBrains MCPドキュメント。
ガバナンス、サンドボックス、コンプライアンス
ファイルシステムファーストは無制限ではない。最小権限で設計：タスク別マウント、パスレベルACLと監査ログ、OSレベル制御（SELinux、AppArmor、Landlock）。ローカルファースト/オンプレはデータ居住とコンプライアンスに有利。MCPスコープをファイルシステム層と同じ最小権限モデルに合わせる。
オブザーバビリティと評価
POSIXトレース、コアメトリクス（成功率、レイテンシ、再現性、監査可能性）、ベンチマーク方法：ファイルシステムファーストのエージェントとAPI/MCPのみのツールチェーンをマルチステップのエンジニアリングタスクで比較。エージェントの「コンテキスト層」：Building a RAG Model That Scales。
制限とAPIが有利な場合
FUSEはユーザー空間の仲介を追加し、CPUとレイテンシが増える。ストリーミングやトランザクション領域では直接SDK/APIが有利なことがある。ハイブリッド：ファイルシステムで plan/scratch/state、MCPで構造化・トランザクション呼び出し。
コンテキストベースの位置づけ
開示：Puppyoneは自社製品です。
ガバナンスされたコンテキストベースは、構造化「Know-How」（JSON/Graph）による企業知識の保存、ハイブリッドインデックスと決定論的検索、Dockerによるローカルデプロイでこのアーキテクチャを支えられる。Puppyoneのコンテキストベース。How Agentic Process Automation Is Transforming Enterprise Operations in 2026。
次のステップとリソース
小規模から始める：2リポでローカルFUSEマウントとplan/scratch、PR/Issue用MCPコネクタ、POSIXトレース。最小権限マウントとパスレベルACLを早めに定義。参照：FUSE is All You Need、AgentFS（Penberg）、Turso AgentFS FUSE、MCP周年、Anthropic MCP、JetBrains MCP。
よくある質問
Q1: FUSEのオーバーヘッドはエージェントのパフォーマンスに大きく影響しますか？
FUSEは多少のレイテンシを加えるが、エージェントのワークロードは典型的に読み中心でバースト書き。カーネルのページキャッシュで初回読み込み後のオーバーヘッドは軽減される。Tursoのパイロットでは cross-repo grep などのエンジニアリングタスクでレイテンシ <10 ms—LLM推論に比べて無視できる。trace.logによる決定論的トレーサビリティとplan.mdチェックポイントからの再現可能なワークフローにより、5〜15%のレイテンシトレードオフは妥当。
Q2: インフラ大改造なしでファイルシステムファーストのパイロットを始めるには？
2リポに閉じたタスク（例：認証フローのドキュメント化）を選ぶ。それらのリポと空の plans/、scratch/、logs/ だけをfusepyまたはfuse-tursoでローカルにマウント。エージェントに plan.md を初期化、scratch.md で反復、trace.log に書き込ませる。GitHub PR用の最小MCPコネクタを追加。すべて開発者ラップトップで実行し、2週間以内に再現性とデバッグの利得を検証。本番変更は不要。
Q3: いつファイルシステムファーストを避けて直接APIを使うべきか？
高頻度ストリーミング（リアルタイム市場データ）、ACIDクリティカルなトランザクション（決済）、ステートレスな単一ステップタスク（URL要約）では避ける。これらはサブミリ秒のレイテンシやネイティブなトランザクション保証を求め、FUSEでは提供できない。ハイブリッドが有効：ファイルシステムで plan/scratch/state、レイテンシに敏感な呼び出しはスコープ付きMCPツール経由。経験則：明日 git diff plan.md で決定を監査したいなら、ファイルシステムファーストに価値がある。