coding agent を長く使っていると、かなり具体的な摩擦に当たる。Model が code を書けないのではなく、「なぜその変更にしたのか」をすぐ忘れる。昨日、architecture choice について agent と議論して決めたのに、今日新しい session を開くと、また別案を最初から出してくる。さらに、実装担当と review 担当のように二つの agent を同時に走らせると、「誰がどこを触っているのか」「その task は本当に終わったのか」を共有する場所もない。

今日見るのは fagemx/edda。この問題を local primitive に寄せた project だ。Workspace の横に .edda/ を置き、append-only、hash-chained な SQLite ledger に decisions、notes、session digests、tasks、verdicts、command outputs を記録する。同時に per-user store で claims や heartbeat のような live coordination state を扱う。Claude Code、Cursor、Codex、OpenClaw に対応し、MCP server も提供している。

GitHub repository API、README、Cargo.toml、release page、tags、latest commit、LICENSE を 2026-09-04 18:06 Asia/Shanghai 時点で確認すると、fagemx/edda は 36 stars、2 forks。主要言語は Rust、GitHub API の license field は Apache-2.0、README と Cargo.toml は MIT OR Apache-2.0 としている。Default branch は main、repository 作成日は 2026-02-19 11:08:05 UTC、latest push は 2026-09-04 10:01:01 UTC。最新 commit は 9de7662、commit time は 2026-09-04 10:00:47 UTC、message は docs(cli): dispatch networked Codex via edda, not the plugin sandbox (#861)。最新 GitHub Release は v0.4.0、published time は 2026-09-02 05:38:34 UTC。Cargo.toml の workspace version も 0.4.0 だ。

プロジェクト概要

項目内容
リポジトリfagemx/edda
位置づけcoding agent 向け local decision memory と multi-agent coordination ledger
Stars36
Forks2
主要言語Rust
ライセンスMIT OR Apache-2.0
作成日2026-02-19 11:08:05 UTC
Latest push2026-09-04 10:01:01 UTC
最新 commit9de7662、2026-09-04 10:00:47 UTC
最新 Releasev0.4.0、2026-09-02 05:38:34 UTC
インストールcurl install script、Homebrew、cargo install edda、GitHub Releases binary
キーワードagent memory、decision tracking、hash chain、local-first、MCP、multi-agent

session boundary を問題にしている

多くの agent memory は、最終的に Markdown file、summary、または vector memory になる。それ自体が悪いわけではない。ただ、「何が起きたか」と「なぜその判断を採用したか」が一つの文章に押し込まれやすい。Edda の見方は event log に近い。Decision には rationale があり、task completion には receipt が必要で、verdict や ratify も過去の記録を書き換えるのではなく別 event として残る。

これは長期 project で効く。たとえば、ある module は single-writer に保ち、Postgres JSONB は入れない、と決めたとする。次の session が始まったとき、agent は古い chat transcript 全体を読み直さなくても、Edda が注入する context からその decision を見られる。しかも、それはただの prose ではなく、time、scope、reason を持つ structured event として query できる。

README は boundary も明確にしている。Core loop に LLM は不要だ。Record、retrieve、hash chain、session-start injection は local で動く。Optional LLM assist は long transcript からの decision extraction、session-end digest、pattern correlation に使われ、EDDA_LLM_API_KEY と daily budget で有効にする。Key を設定しなければ、この部分の egress は発生しない。

multi-agent では memory が coordination になる

Edda が面白いのは、「次の session が前の session を覚える」だけではないところだ。第二層の Fleet は、複数 agent が同時に働くときの coordination を扱う。誰がどの path を claim しているのか。どの task が進行中なのか。Done と言っている task に receipt はあるのか。どの plan phase が human verdict を待っているのか。

これは普通の TODO list より agent workflow に近い。Agent が「終わった」と言うだけでは事実にならない。少なくとも確認できる evidence を残すべきだ。Phase の承認も、その場の会話だけでなく、特定の SHA に pin された verdict として記録したい。複数 session が同じ path を触るなら、開始前に claim intersection を見せてほしい。

Claims は現時点では default advisory だ。Edda は conflict を記録して表示するが、それだけで強制 lock にはならない。README では EDDA_ENFORCE_OFFLIMITS=1 または bridge.enforce_offlimits=true によって、Claude Code hook が peer-claimed path への write を拒否できると説明している。この default は現実的だ。まず coordination state を見えるようにし、強い enforcement は明示的な選択にしている。

v0.4.0 は runtime と recovery に寄っている

最新 release v0.4.0 は、この project の方向を見るのにちょうどいい。Multi-agent conductor runtime が追加され、edda conduct run --agent <claude|pi|codex> で選んだ host を起動できる。edda dispatch は single-turn agent command として、Codex session-to-thread continuity、budget reporting、cross-process recovery を強調している。

もう一つの中心は gate と recovery だ。Release notes では、plans が AWAITING_VERDICT で止まり、edda phase approve または edda phase reject で再開できること、phases が owned write surfaces を宣言し、それが coordination claims になることが説明されている。Task execution 側にも scoped leases、unfinished-attempt reconciliation、Windows scheduler launch manifest validation が入り、中断された work を静かに失うのではなく、再び状態に戻す方向へ進んでいる。

派手な demo にはしにくいが、agent orchestration では重要なところだ。本当に困るのは、controller が死に、child process は残り、task state は stdout、chat transcript、git branch に分散している場面だ。誰が現場を復元するのか。Edda はそれを event、heartbeat、claim、receipt、verdict に落とそうとしている。

local-first の利点と代償

Local-first は Edda の大きな売りだ。外部 SaaS は不要で、状態を特定の agent vendor の private memory に閉じ込めない。.edda/ledger.db、ledger blobs、branches、drafts、patterns、actors、policy、config は local に置かれ、MCP server はその能力を client に渡すだけだ。

この設計は個人開発者、小さな team、Claude Code、Codex、Cursor を行き来する人に向いている。異なる tool が同じ ledger を読み書きできれば、「なぜそうしたか」が一つの chat window に閉じなくなる。

ただし代償もある。まず project は若く、stars は 36 だ。活発ではあるが、広く検証された infrastructure ではない。次に、Rust workspace は現在 rust-version = "1.91" を要求している。2026 年 9 月時点でもかなり新しい toolchain なので、古い CI pin のままでは試す前に toolchain 対応が必要になる。さらに、README は today の two-tier authority が workflow convention であり、完全な cryptographic identity / access-control boundary ではないと説明している。Security isolation として扱うべきではない。

向いている人

一つ目は、agent を本物の project に長く参加させている人だ。主な痛点が「毎 session、過去の判断を説明し直すこと」なら、Edda の Layer 1 だけでも試す価値がある。

二つ目は、複数 agent を同時に走らせる人だ。たとえば一つが実装し、一つが review し、もう一つが test を補う。必要なのは memory だけではなく、claims、task receipts、phase gates、peer heartbeat のような recoverable work state になる。

三つ目は、agent output を audit しやすくしたい人だ。Hash chain は agent を自動的に正しくするものではない。それでも、「record は改ざんされていないか」「その decision はいつ出たのか」「誰が何を done と主張したのか」を追える形にする。

Caveats

第一に、project はまだ速く動いている。v0.4.0 の release notes は長く、latest push も今日だ。Maintenance が活発なのは良いが、interface と workflow は今後も変わる可能性がある。重要 repository に入れる前に、まず非 critical な repo で試したい。

第二に、Edda は agent hooks と強く結びつく。Claude Code、Codex、Cursor、OpenClaw の bridge は価値の源泉であり、同時に troubleshooting point でもある。Hook injection、PATH、permission、workspace detection の問題はそのまま体験に影響する。

第三に、coordination enforcement は default では hard lock ではない。Advisory default は多くの個人 workflow には扱いやすいが、同時 write を強く防ぎたいなら、明示的に有効化して bridge の動作を確認する必要がある。

第四に、Edda が扱うのは agent memory / coordination であり、code understanding、search、refactor engine ではない。CodeSage、Serena、language server、test tool、review process などは別途必要になる。

まとめ

fagemx/edda の価値は、agent memory を「context を少し増やすこと」だけにしていない点にある。Decision、reason、task、receipt、heartbeat、claim、verdict を、disk に残り、query でき、復元できる engineering events として扱う。この視点は、multi-agent development が普通になりつつある今の流れにかなり合っている。

まだ early project であり、hooks と local ledger という作法も受け入れる必要がある。それでも、複数の coding agent が同じ repository を順番に、または並行して触り始めているなら、Edda は一度まじめに試す価値がある。少なくとも、問いは正しい。Agent は code を書くだけでなく、なぜ書いたのか、誰が書いているのか、何をもって完了とするのかを記録できるべきだ。

プロジェクトアドレス：https://github.com/fagemx/edda