FAVA Trails：AIエージェントのためのGitネイティブな共有メモリ（MCP）

向いている人

FAVA Trails（Federated Agents Versioned Audit Trail）は、MCP経由でAIエージェントに提供されるGitネイティブなメモリシステムです。エージェントが生み出した考え・意思決定・観察は、YAML frontmatter付きのMarkdownファイルとして、自分自身が管理するGitデータリポジトリに書き込まれます。他人のサーバー上のブラックボックスには置かれません。「ドラフト」と「全エージェントに見える観察」の2層が昇格ゲートで分かれており、エージェントが普段見るのはメモリツールだけで、バージョン管理コマンドには直接触れません。バージョン管理の詳細はエンジンがリポジトリ内で処理し、履歴はすべてコミット記録として遡って確認できます。

• 向いている人：複数のエージェントで作業メモリを共有し蓄積したいチームや個人。たとえばエンジニアリング調査の結論や、セッションをまたぐ意思決定の文脈を、再利用可能な観察として保存したい場合。メモリがバージョン管理され、追跡可能で、いつでもファイルとして直接確認できることを望むユーザー。すでにGitで資産を管理しており、データリポジトリをもう1つ維持しても構わない人。
• 前提条件：手元の環境でpipによるインストールができること。設定ではデータリポジトリのパス FAVA_TRAILS_DATA_REPO を指定すること。ドラフトを全エージェントに見える観察へ昇格させるには、OpenRouter API keyの設定が必須です。
• よく検討を：データリポジトリを維持したくない、またはOpenRouter keyを取得したくないユーザーは慎重に。エージェント間でメモリを共有する中核の経路は、この2つに同時に依存しています。
• 不明な点：エビデンスには、対応する具体的なMCPクライアント、OSとPythonのバージョン要件、ストレージエンジンJujutsu（JJ）を別途インストールする必要があるかは記載されていません。

3分で初めて試す

推奨される主経路は1つだけです。PyPIからエンジンをインストールし、MCPクライアントのサーバー設定に登録します。前提は2つ：データリポジトリとして使う場所を先に決めること（設定の FAVA_TRAILS_DATA_REPO がそこを指します）、そして昇格のステップまで進めるならOpenRouter API keyが必要です。

最初のステップ、このApache-2.0ライセンスのステートレスなMCPサーバーをインストールします：

pip install fava-trails

次のステップ、公式の登録スニペットをクライアント設定に追加し、リポジトリのパスを実際の場所に置き換えます：

"fava-trails": {
  "command": "fava-trails-server",
  "env": {
    "FAVA_TRAILS_DATA_REPO": "/path/to/fava-trails-data",
    "OPENROUTER_API_KEY": "sk-or-v1-..."
  }
}

3つ目のステップ、エージェントに最も影響範囲の小さい書き込みを1回実行させます。save_thought で観察を1件、ドラフトとして保存します。

save_thought(trail_name="myorg/eng/my-project", content="My finding about X", source_type="observation")

成功のサイン：データリポジトリの drafts/ ディレクトリにこのドラフトが出現します。操作の性質を踏まえてください：このステップはローカルへの書き込みであり、ファイルは自分のリポジトリに置かれます。読み取り専用のクエリではありません。ドラフトの削除や取り消しについて公式の説明はなく、初回は無害な内容を書いてください。エンジン側では、Jujutsu（JJ）がストレージエンジンとしてGitと並行（colocateモード）で動き、リポジトリは通常のGitリポジトリのままなので、このステップでバージョン管理コマンドに触れる必要はありません。また、OpenRouter API keyの位置づけにも注意してください。この公式設定テンプレートにすでに登場しており、公式の表ではさらに、propose_truth に必須で、Trust GateのLLMレビューをOpenRouter経由で支えると説明されています。初回の体験はドラフトのステップで止めてよく、ついでに昇格する必要はありません。

ユースケース

ケース1：調査の結論をプロジェクトのメモリとして残す。シナリオ：エージェントが調査を終えたばかりで、その結論を後のセッションで再利用する価値がある。やり方：save_thought をtrail_name、content、source_typeの引数で呼び出します。上の公式サンプル呼び出しをそのまま使えます。期待できる結果：drafts/ にドラフトファイルが生成され、内容は自分のリポジトリにのみ置かれ、他のエージェントにはまだ見えず、誰にも影響しません。ドラフトは通常のファイルなので、リポジトリ内で直接開いて確認できます。

ケース2：確認済みのドラフトを共有観察へ昇格し、検索で確認する。シナリオ：ある観察が検証済みで、以降のすべてのエージェントが参照できるようにしたい。やり方：まずOpenRouter API keyが有効かを確認し、propose_truth(trail_name="myorg/eng/my-project", thought_id=thought_id) でドラフトを observations/ へ昇格してから、recall(trail_name="myorg/eng/my-project", query="X") で検索します。期待できる結果：recallが昇格済みの考えを見つけ、同じデータリポジトリに接続した他のエージェントも同じクエリで見つけられます。確認ポイント：昇格結果は全エージェントに見え、公式には取り消しの説明がないため、実行前に内容が共有に適するかを確認してください。変更をリモートへpushするのは別の独立した操作で、sync ツールまたは jj git push を改めて呼び出す必要があります。

利用の境界

• 読み書きの性質：save_thought はデータリポジトリにドラフトを作成し、propose_truth はドラフトを全エージェントに見える observations/ へ昇格します。どちらも書き込みです。recall は昇格済みの考えを検索します。書き込みは自分のリポジトリ内で行われ、昇格もまずローカルに反映されます。リモートへのpushは sync MCPツールまたは jj git push で別途行う必要があり、同期するかどうかはあなたが決めます。公式には取り消し・削除の経路がなく、書き込みをいつでも戻せる操作とは考えないでください。
• 認証情報と設定：FAVA_TRAILS_DATA_REPO がデータリポジトリの場所を指定し、OPENROUTER_API_KEY は昇格時のLLMレビューで使われます。両方とも公式設定テンプレートのenvセクションに記載され、公式ドキュメントは後者が propose_truth に必須であると明示しています。このkeyがないときに save_thought と recall が動くかは、エビデンスに記載がありません。
• 実行環境とデータの置き場所：ストレージエンジンはJujutsu（JJ）で、Gitと並行してcolocateモードで動作します。リポジトリは通常のGitリポジトリのままで、GitHubとCI/CDには通常のコミットが見えます。すべての内容は、YAML frontmatter付きのMarkdownファイルとして、あなたが管理するリポジトリに保存されます。
• 未確認の項目：容量のクォータ、複数リポジトリの規模上限、プライバシーとデータ保存地域の詳細は、エビデンスに記載がありません。Trust Gateレビューの判定基準と失敗時の扱いも同様に不明で、jjを自分でインストールする必要があるか、対応クライアントとPythonのバージョンも未説明です。「説明が見当たらない」ことを「リスクがない」と解釈せず、書き込む内容は「自分のリポジトリに長く残る」と想定して評価してください。