Gortex - AI coding agent のためのローカルコードグラフエンジン
AI coding agent は小さな repository では賢く見えます。数個の file を読み、symbol を grep し、call site を開けば、それなりに良い提案ができます。しかし repository が大きくなると、問題は別の形になります。Agent は同じ file を何度も読み、長い context に source code を詰め込み、text search から call relationship を推測します。Token は消費されますが、code structure を本当に理解できるとは限りません。
今日紹介する zzet/gortex は、この問題を local code graph として扱おうとする tool です。Repository を index し、symbol、file、reference、call chain、cross-repo relationship を graph として構築し、それを CLI、MCP Server、HTTP API、Web UI から利用できるようにします。
公開時点の GitHub page では、およそ 104 stars、7 forks。主な言語は Go、license は Apache-2.0 です。Repository は 2026-04-06 に作成され、現在も active に更新されています。GitHub releases page では、latest release は v0.41.0、公開日は 2026-06-07 です。
プロジェクト概要
| 項目 | 内容 |
|---|---|
| Repository | zzet/gortex |
| 位置づけ | Local code graph / code intelligence engine |
| Stars | 約 104 |
| Forks | 7 |
| 主な言語 | Go |
| License | Apache-2.0 |
| Latest release | v0.41.0 |
Agent の code context 問題を扱う
多くの agent workflow の基本動作は、まだかなり素朴です。Keyword を search し、file を開き、context を読み、次の keyword を search します。単発の bug fix には十分でも、architecture understanding、impact analysis、cross-module refactoring では安定しにくい。
Gortex の考え方は、先に code を queryable graph に変えることです。README では、symbol lookup、call chain、impact range、dataflow、clone detection、refactoring support、code action などが挙げられています。Agent は毎回 plain text から「この function はどこで呼ばれるのか」を推測するのではなく、graph により狭い情報を問い合わせられます。
これは source code を読まなくてよいという意味ではありません。より正確には、Gortex は source code を読む前に使うと効きます。関連する symbol、call chain、change radius を先に絞り込み、その後で具体的な file を確認するための tool です。
Remote index ではなく local-first
Gortex の README は、外部 database や model download なしで始められる local tool であることを強調しています。Indexing、query、daemon は local machine または team の管理する environment で動きます。
この boundary は重要です。多くの team は AI に code を読ませたい一方で、private repository 全体を third-party indexing service に渡したいとは限りません。Gortex の local model は、developer machine や CI 内部に置く code structure cache に近いものです。Code がある場所に index も置く、という考え方です。
もちろん、local-first には運用責任もあります。Install、upgrade、resource usage、security policy を自分たちで見る必要があります。README には macOS、Linux、Windows PowerShell 向けの install path があり、verification にも触れられています。ただし実際の team では、まず non-critical repository で試し、index speed、memory usage、agent behavior を確認するのが現実的です。
MCP が最も注目すべき interface
Gortex は CLI、HTTP API、Web UI、MCP Server を提供しています。AI coding workflow で特に重要なのは MCP Server です。
CLI は人間が手で query するのに向いています。Web UI は graph と relationship を探索するのに向いています。HTTP API は自前 tool との integration に向いています。一方で MCP は、agent が coding session の中で structured tool を直接呼べるようにします。たとえば symbol definition、call chain、impact range、より小さな context package を要求できます。
README では Claude Code、Cursor、Windsurf、VS Code/Copilot、Codex CLI、Gemini CLI、Zed、Aider など、複数の agent / editor environment への integration が挙げられています。この方向は重要です。Agent tooling は「model にもっと text を渡す」方向から、「model により狭く、検証しやすい tool を渡す」方向へ移りつつあります。
Multi-repo と contract analysis が面白い
単一 repository の symbol indexing だけなら、Gortex は多くの code search tool と重なります。より面白いのは、cross-repo workspace と API contract analysis です。
README で説明されている contract detection は、HTTP route、gRPC、GraphQL、message topic、WebSocket event、environment variable、OpenAPI file などを対象にしています。Gortex は provider と consumer の関係を normalize し、multi-repo graph の中で扱おうとします。
これは microservice や multi-package monorepo で実用的です。現実の impact analysis は、単に「この function はどこで呼ばれるか」では終わりません。「この API route を変えると、どの service、script、frontend call に影響するか」を見る必要があります。Tool がこの relationship を evidence つきで出せるなら、agent は refactoring や review で current repository だけを見る失敗を減らせます。
Web UI は agent 判断の校正に使える
Gortex は backend-only tool ではありません。Code knowledge graph を可視化する Web UI も提供しています。日常作業で毎回開くものではないかもしれませんが、agent tool を導入するときには実用的な意味があります。人間が agent の使った context を校正できるからです。
Agent が「この変更は A と B だけに影響する」と言ったとき、Web UI や CLI で関連 node、edge、call chain を見直せます。Tool が black box ではなく、構造化された理解を表に出すため、review を具体的な evidence に寄せやすくなります。
使う前に見るべき境界
Gortex はまだ若い project です。Release は頻繁で、version も 0.x です。試用や段階的な導入には向きますが、最初から critical release process を完全に依存させるには早いでしょう。
README にある performance や token saving の数字は project 側の benchmark や example であり、私は local で再測定していません。実際の効果は repository language、code style、agent が MCP tool を本当に使うか、prompt、team workflow に左右されます。Cost-saving switch としてではなく、structured context tool として扱う方が安全です。
また、code graph tool には accuracy boundary があります。Static analysis は dynamic language、runtime registration、reflection、framework convention、generated code、cross-process call に弱い場合があります。Gortex は多くの language と contract type を扱いますが、graph query の結果は review clue であり、最終事実ではありません。
向いている team
私は Gortex をまず次の場面で試します。
- Repository が大きく、agent が同じ file を何度も読み直す。
- Team が MCP を使っている、または agent に structured tool を接続したい。
- Cross-repo、cross-service、API contract level の impact analysis が必要。
- Code structure index を local または self-managed environment に置きたい。
- Natural language answer だけでなく、Web UI や CLI で agent の code understanding を校正したい。
Project が小さい場合や、主な課題が test 不足と engineering process の未整備である場合、Gortex は最初の優先順位ではありません。まず test、type check、CI を整える方が直接効くことが多いです。
まとめ
zzet/gortex の価値は、AI coding agent の context gathering を「もう少し file を読む」から「local code graph を query する」方向へ進めることです。Symbol、call chain、impact analysis、MCP、HTTP API、Web UI をひとつの tool にまとめており、agent workflow を本気で調整している team には評価する価値があります。
魔法ではありませんし、人間の review を置き換えるものでもありません。それでも、大きな repository で agent が検索し続け、同じ file を読み直し、call relationship を見落とす問題を感じているなら、Gortex のような local code graph engine は実験リストに入れる価値があります。