Rekal:AI coding の判断を Git と一緒に team で覚える
AI coding tool で失われやすいのは code そのものではなく、code を今の形へ持ってきた判断の過程だ。ある案をなぜ却下したのか、ある edge case をなぜ単純化できないのか、refactor が実際に何を解決したのか。そうした情報は閉じた conversation と一緒に消えやすい。後から来た人、あるいは次に開いた agent は diff から推測するしかなく、すでに検討した分岐をまた歩くことになる。
今日見るのは rekal-dev/rekal-cli、Rekal だ。この問題を developer がすでに持つ infrastructure に戻す。Git commit 時に AI coding session を capture し、secret redaction と home-path anonymization の後で repository の .rekal/ data に保存する。work が default branch に merge された後、team memory は専用 orphan branch を通じて Git push/fetch で運ばれる。Retrieval と embedding は local で行われ、追加の memory SaaS、vector database、account は要らない。
GitHub repository page、README、LICENSE、default branch の commit feed、release page を 2026-09-09 18:15 Asia/Shanghai 時点で確認すると、rekal-dev/rekal-cli は 186 stars、2 forks。主要言語は Go、license は Apache-2.0。repository 作成日は 2026-02-24 23:20:14 UTC、latest push は 2026-08-04 09:23:27 UTC。最新 commit は aace7a2、時刻は 2026-08-04 09:23:27 UTC、message は docs: changelog and pin for 1.0.2 (#87)。最新 GitHub Release は v1.0.2、published time は 2026-08-04 09:36:00 UTC。
プロジェクト概要
| 項目 | 内容 |
|---|---|
| リポジトリ | rekal-dev/rekal-cli |
| 位置づけ | AI coding session の判断を Git で同期できる team memory にする |
| Stars | 186 |
| Forks | 2 |
| 主要言語 | Go |
| ライセンス | Apache-2.0 |
| 作成日 | 2026-02-24 23:20:14 UTC |
| Latest push | 2026-08-04 09:23:27 UTC |
| 最新 commit | aace7a2、2026-08-04 09:23:27 UTC |
| 最新 Release | v1.0.2、2026-08-04 09:36:00 UTC |
| 導入方法 | installer または Releases の single-file binary |
| キーワード | Git、agent memory、CLI、local-first、semantic search |
保存するのは code index ではなく「なぜ」
Rekal の切り口は一般的な repository RAG と異なる。RAG が答えるのは code が今どうなっているかで、Rekal が残そうとするのは、なぜ A を選び B を捨てたのかという conversation だ。README の例は日常的だ。後の session が webhook retry を考える時、fixed delay は recovery 中に混雑を起こすため exponential backoff with jitter にした、という以前の結論を直接 query できる。commit message だけから理由を逆算する必要がない。
Data は二層になっている。raw で append-only の session ledger が長期の source で、full-text、semantic、graph retrieval 用の index.db は捨てて再作成できる derived index だ。この分離には実務上の利点がある。index の rebuild は記録済み conversation を変えず、重い embedding 作業も background に回せるため、通常の commit を待たせない。
すべての履歴を agent に押し込む設計でもない。query は既定で短い verdict、candidate session、さらに開ける turn を返し、agent は必要な時だけ完全な reasoning を drill into する。context window が貴重な coding workflow では、増え続ける MEMORY.md を無差別に inject するより、制御しやすい retrieval interface になる。
Git で運び、merge 済みの work だけを team context にする
rekal init は対象 repository に .rekal/、post-commit/pre-push hooks、対応する agent の skill/rules marker、そして rekal/<email> という orphan transport branch を作る。この branch は project code と common ancestor を持たないため、通常の history、merge、working tree に混ざらない。team member が rekal sync を実行すると、remote の Rekal branches を local index に取り込める。
重要な制約は「default branch に merge された work だけを同期する」ことだ。Local では feature branch の session 全体を保持できるが、merge 前の spike や未完成の experiment は自動的に teammate へ流れない。これは「context を失う」と「未確定の chat まで全部同期する」の間に明確な境界を置く。review 済みの判断については、Git 自体がすでにある配布と permission の経路になる。
Local-first で、privacy の境界も workflow に置く
README によると transcript は database に書かれる前に pattern と entropy を使う secret redaction、home path の anonymization を受ける。embedding と query も既定では machine 内で完結する。ただしこれは best-effort redaction であり、sensitive な session を repository に入れても安全だという証明ではない。team は commit と sync を許容する内容を引き続き確認する必要がある。
それでも方向性には現実的な価値がある。agent の context を覚えさせるためだけに hosted memory service を運用しなくてよく、team の全 session を third-party API へ送る必要もない。すでに Git hosting と access control があり、offline でも recall したい project なら、別の vector database を立てるより軽い出発点になる。
Install と最初の一歩
Project は installer を提供し、Releases から対応 platform の binary も取得できる。README の最短経路は次の通りだ。
curl -fsSL https://raw.githubusercontent.com/rekal-dev/rekal-cli/main/scripts/install.sh | bash
cd your-project
rekal init
git commit -m "…"
rekal "なぜ batching をやめた?"
より慎重にするなら installer を download して読んでから実行する。Release には checksums.txt があり、shasum -a 256 -c checksums.txt で検証できる。Initialization は hooks と検出した agent instruction file を変更するため、まず小さな repository で試し、diff を review するのがよい。
向く人と、見落としたくないコスト
Codex、Claude Code、Cursor、Copilot、Gemini、Kiro、OpenCode をすでに頻繁に使い、同じ architecture discussion が session ごとに繰り返される team には試す価値がある。特に time zone をまたぐ協業、長寿命の repository、diff だけでは理由が読めない判断が多い project で、context を個人の記憶ではなく query できる asset にできる。
Cost も具体的だ。現行 README の support 範囲は Apple Silicon macOS と Linux x86-64/arm64。single binary は download が約 170 MB、disk が約 200 MB で、embedding model、inference engine、database、full-text extension を同梱するためだ。1.0 には入ったが stars と forks はまだ少ない。critical ではない repository で hooks、storage size、redaction rule、team の Git flow との相性を検証してから広げたい。
まとめ
Rekal の面白さは「agent に長期 memory がある」と言うことではなく、memory の所有、配布、取り外しを team が慣れた Git workflow に置いた点にある。session は commit 時に保存され、merge 済みの work だけが共有され、index は rebuild でき、raw record は追跡できる。agent と人間が昔の決定を繰り返し議論するのを減らしたいが、新しい cloud context platform は増やしたくないなら、小さな project で実測する価値がある。