小さな project なら、coding agent は数ファイルを読めば作業を始められる。だが repository が大きくなり、変更頻度も上がると、問題はかなり現実的になる。agent が読んでいる code は本当に最新なのか。directory をまたぐ call relationship を見ているのか。前回 session で残した rule や fact はまだ使えるのか。毎回手で file を貼り、手で注意点を伝え、手で search させるなら、context management はすぐ肉体労働になる。

今日メモしておきたい proofofwork-agency/reporecall は、この痛点に向けた local tool だ。code indexing、hybrid search、call graph、auto-generated wiki、local memory、MCP tools、Claude Code hooks をまとめ、agent そのものを置き換えるのではなく、agent が回答を始める前に、より信頼できる、追跡可能な context を渡すことを狙っている。

2026-07-13 時点で GitHub repository API、README、release API、tags API、commits API、package.json から確認できる公開情報では、proofofwork-agency/reporecall は 36 stars、6 forks。主言語は TypeScript、license は MIT。repository 作成日は 2026-03-16 22:39:45 UTC、最近 push は 2026-07-09 17:01:30 UTC。default branch main の現在の最新 commit は f6cbaf20、commit time は 2026-07-09 17:01:27 UTC。GitHub Releases page の latest release は v0.8.0 で、公開時刻は 2026-07-09 12:59:54 UTC。Tags page の最新 tag は v0.8.1、package.json の version も 0.8.1 だ。

プロジェクト概要

項目内容
リポジトリproofofwork-agency/reporecall
位置づけcoding agent 向けの local context、memory、code topology layer
Stars36
Forks6
主言語TypeScript
ライセンスMIT
リポジトリ作成日2026-03-16 22:39:45 UTC
最近 push2026-07-09 17:01:30 UTC
最新 main commitf6cbaf20、2026-07-09 17:01:27 UTC
Latest GitHub releasev0.8.0
最新 tag / package versionv0.8.1 / 0.8.1
主な入口npm install -g @proofofwork-agency/reporecall、reporecall init、reporecall serve
キーワードlocal-first、MCP、hooks、hybrid search、call graph、memory、freshness

問題は search そのものではなく、context が信頼できるかどうか

Reporecall の quick start はかなり直接的だ。

npm install -g @proofofwork-agency/reporecall
reporecall init && reporecall serve

README が繰り返し強調しているのは、「model を賢くする」ことではなく、agent に checkable な context layer を渡すことだ。local code を index し、wiki と business context を生成し、local memory を維持し、MCP または CLI で search、explain、stats を公開する。Claude Code では hooks を core experience として扱い、UserPromptSubmit などのタイミングで route / compress された context を agent に自動注入する。

ここは実用的だ。多くの agent tool には search capability がある。だが難しいのは、agent がいつ search すべきか、何を search すべきか、そして search index が古くないかを必ず判断できるとは限らないことだ。Reporecall は freshness をかなり前面に出している。README によれば、各 result には indexedCommit、dirty file count が含まれ、index が empty または stale の場合は明示的な banner と refresh_context guidance が出る。

この「context state について正直であること」は、単に code snippet を増やすより重要だ。大きな repository では、間違った context は context がないことより危ない。stale index は、根拠がありそうに見えて実は古い変更案を agent に出させる。

MCP tool surface を六つに絞っている

Reporecall のもう一つの選択は、v0.8 以降に MCP surface を 6 tools へ縮めたことだ。search_context、search_code、explain_flow、memory、refresh_context、get_stats である。

これは「agent に大量の tools を渡す」より抑制的だ。coding agent の tool list が長くなるほど、選択コストは上がり、誤用もしやすくなる。Reporecall は local indexing、intent routing、hybrid retrieval、graph expansion、compression に複雑さを寄せ、外側には安定した入口だけを出す設計に見える。

日常的には、search_context は「この capability はどこに実装されているか」を聞く時に向き、explain_flow は file をまたぐ call path を追う時に向く。memory は project rule と fact を残すために使い、get_stats は現在の index が信頼できるかを確認する。これは chat UI ではなく、既存 agent に local code understanding layer を足す tool だ。

Lens は人間が見るための code map

MCP と CLI に加えて、Reporecall には人間が確認しやすい入口もある。

reporecall lens --serve --open

README は Lens を single-file HTML architecture dashboard と説明している。codebase topology、communities、hubs、wiki pages、product areas、business context を見られ、JSON export もできる。この方向は注目したい。agent memory tool の多くは model のためだけに働くが、Reporecall は少なくとも human-readable な observation surface を用意している。

team にはこれが効く。agent に index を使わせて回答させることもできるし、自分で Lens output を見て、tool が project structure を妥当に理解しているか確認できる。wiki、product areas、graph が明らかに外しているなら、より自動化された workflow に入れる前に気づける。

local-first だが、zero-cost ではない

Reporecall の local-first な姿勢は明確だ。README には zero cloud by default、external vector DB 不要、default で offline usable とある。company codebase では、repository を hosted service に預けるより受け入れやすい。reporecall explain --json、reporecall search、reporecall mcp --project .、reporecall lens --json のような scriptable output もあり、自分たちの process に接続しやすい。

ただし local-first は zero-cost ではない。project で daemon または indexing command を動かす必要があり、hooks と MCP config も理解する必要がある。大きな repository では indexing speed と memory usage も観察したい。README も、小さな greenfield project や grep と agent built-in tools で十分な場面では不要かもしれない、と率直に書いている。

Reporecall は「context infrastructure」と見るのがよいと思う。たまに agent に小さな file を直させるだけなら重く見える。だが、agent に unfamiliar codebase で cross-module な判断をさせることが多いなら、あるいは team が local rules、memory、code topology、freshness をまとめたいなら、価値が見えやすい。

向いている場面

第一の場面は、大きな repository や high-churn repository だ。code relationship が頻繁に変わり、手で context を貼ると critical path を漏らしやすい。

第二の場面は、coding agent が毎回回答する前に、route / compress された local evidence を読んでほしい場合だ。agent が自発的に search tool を呼ぶことだけに頼らない。

第三の場面は、team が local memory を欲しいが、それを freshness signal のない session summary の山にしたくない場合だ。Reporecall は少なくとも memory、indexed commit、dirty state を同じ trust contract の中に置いている。

第四の場面は、Codex、Claude Code、Cline、Aider など複数の agent に共通の code retrieval / explanation backend を持たせたい場合だ。それぞれの tool の中で project knowledge を別々に維持しない。

注意したいところ

第一に、project はまだ early stage だ。36 stars、6 forks で、作成日は 2026-03-16。最近の release と tag は活発だが、外部の利用例はまだ多くない。まず non-critical repository で試すのがよい。

第二に、README はかなり充実していて主張も明確だが、実際の効果は自分の codebase 次第だ。hybrid retrieval、call graph、wiki、product areas は、technology stack によって精度差が出る。

第三に、Claude Code hooks は特に強調されている体験だ。Codex や他の tool を主に使うなら、MCP と CLI surface により依存する。使えるが、体験の中心は少し変わる。

第四に、Releases page の latest は現在 v0.8.0 だが、tag と package version は v0.8.1 / 0.8.1 まで進んでいる。採用するなら version を明示的に pin し、npm package、tag、release note の整合を確認した方がよい。

まとめ

Reporecall が捉えているのは、coding agent workflow のかなり基本的な問題だ。context は「より多い text」だけではなく、source、freshness、topology、reusable memory を必要とする。

大きな repository で agent に何度も「まずこの file を見て」「この rule を忘れないで」「この index は古いかもしれない」と伝えているなら、proofofwork-agency/reporecall は試験リストに入れる価値がある。まだ小さい project だが、方向は明確だ。agent の code understanding layer を local に戻し、自分が何を知っていて、何を知らないのかを明示させる。