Repo Graph

repo-graph

AI コーディングアシスタントのための構造グラフメモリです。 コードベースをマッピングし、構造をたどり、必要なものだけを読み取ります。

repo-graph は、コードベースのエンティティ、関係、フローを示すマップを LLM に提供するため、すべてを先に読むことなく、適切なファイルを見つけられます。

コードベース全体を LLM のコンテキストウィンドウに詰め込んだり（あるいは正しく推測してくれることを期待したり）する代わりに、repo-graph は何が存在し、どのようにつながり、エントリーポイントがどこにあるかを示す軽量なグラフを構築します。LLM はグラフを照会して必要最小限のファイルを見つけ、それだけを読み取ります。

手作業で行うのが特に難しい場面、つまり、大規模なリポジトリ、複数の言語にまたがるモノレポ、機能の経路がファイル、スタック、サービスの境界を越えるマルチサービスシステムで、最も効果を発揮します。単一言語の小規模なプロジェクトなら、モデルはファイルをそのまま読めます。最適な用途については、特に適したケースをご覧ください。

ワンクリックでインストール：

または、ターミナルでコマンドを 1 つ実行するだけで、使用中のすべてのエージェントを設定できます：uvx mcp-repo-graph install（インストールをご覧ください）。

---

0.5.2 へのアップグレード

ほとんどの方は何もする必要はありません。 uvx と pip install mcp-repo-graph は、新しいエンジン（glia 0.5.1、厳密に固定）を取得します。.glia/graph/ にあるキャッシュ済みのグラフは新しい形式になっているため、各リポジトリで最初に起動したときに一度だけ再構築されます。その後は通常どおりです。

同じリポジトリで glia 独自の CLI フック（glia install-hooks）も実行している場合に限り、対応が必要です。v0.5.1 タグから CLI も再インストールしてください。CLI とサーバーで異なるバージョンの glia を使っていると、コミットのたびに互いのキャッシュを再構築します。

repo-graph の pre-commit フックを使って キャッシュをコミットするチームも同様です。次のコミットで新しい形式のキャッシュが一度だけ再追加されます。また、サーバーで glia 0.5.0 エンジンを使い続けている人は、アップグレードするまで読み込みのたびにキャッシュを再構築します（uv ツールとしてインストールした場合は uv tool upgrade mcp-repo-graph を実行してください）。

改善点：より豊かなグラフ（マウントされた Go ルートにプレフィックスが含まれ、フロントエンドのエンドポイントがベース URL を通じて対応付けられ、解決できる呼び出しが大幅に増加）、read で WebSocket／gRPC／GraphQL クライアントが接続するホストを表示、長時間のセッション中にサーバーのメモリ使用量が徐々に増えなくなりました。

⚠️ 0.5.0 へのアップグレード

エンジンパッケージの名前が repo-graph-py から glia-py に変更されました。 uvx または pip install mcp-repo-graph でインストールしている場合、何もする必要はありません。新しいエンジンは自動的に取得されます。

エンジンを 直接インポートしている場合に限り、対応が必要です：

- import repo_graph_py as rg
+ import glia_py as rg

同じリリースで、ほかにも3点変更されています：

• 結果は JSON 文字列ではなく、Python オブジェクトになりました。 find、resolve、blast_radius、 cross_stack_trace、governing_docs は {"results": [...], "absence": {...}} の dict を返します。 結果に対して json.loads(...) を使っていた場合は、削除してください。
• find_node と find_nodes_by_qname は廃止されました。 両方を置き換える関数として、find(query, top_k) を使います。
• グラフキャッシュの場所が .ai/repo-graph/ から .glia/graph/ に変わりました。自動的に再構築されるため、古いディレクトリは削除できます。新しいディレクトリは自身を無視するため、git status に表示されることはありません。

6つの MCP ツール（orient、find、impact、trace、read、refresh）に変更はないため、エージェントの設定を変更する必要はありません。詳細は 0.5.0 リリースノートをご覧ください。

デモ

https://github.com/user-attachments/assets/a1e4171b-b225-40d4-9210-39453e14b76a

https://github.com/user-attachments/assets/fc3191e5-fc35-4bd7-8372-72af55995883

同じバグ、同じモデル、同じプロンプトで、唯一の違いは repo-graph がインストールされているかどうかです。

タスク： Go + Angular のモノレポにある、逆向きの比較演算子を修正します。

(以前のエンジンで記録したもので、このリポジトリは566ノード／620エッジとしてマッピングされていました。glia 0.5.1 エンジンは同じコードからはるかに多くの情報を抽出し、3,466ノード、6,869エッジになります（2026-10-02測定）。そのため、現在モデルに渡されるグラフは動画内のものより豊富です。トークン数と時間は記録時の実測値をそのまま掲載しています。)

	repo-graph なし	repo-graph あり
使用トークン数	75,308	29,838
修正までの時間	4分36秒	約30秒
調査したファイル数	約15（grep、read、grep、read…）	2（trace の検索 + ハンドラーファイル）
結果	バグを発見して修正	バグを発見して修正

トークン数は2.5分の1。速度は約9倍。同じく正しく修正。

テストの実施方法

比較を公平にするため、どちらの実行でも同じ条件を使用しました。

• 同じモデル：Claude Opus、100％（Haiku へのルーティングなし）
• 同じプロンプト：「最近作成されたグループは閉鎖済みとして表示され、古いグループはオープンとして表示されています。これは逆です。新しいグループはメンバーが参加できるよう、オープンであるべきです。バグを見つけて修正してください。」
• 新しいコンテキスト：各実行は、以前の会話がない状態で /clear から開始
• 他のツールなし：両方の実行で CLAUDE.md、プラグイン、フック、その他すべての MCP サーバーを削除し、repo-graph がインストールされているかどうかだけを変数としました
• ヒントなし：プロンプトに記載されているのは症状であり、場所ではありません。Claude は自力で group_controller.go:57 を見つける必要があります

repo-graph がない場合、Claude はキーワードで grep し、ファイルを読み、再び grep し、さらにファイルを読んで、最終的にバグを絞り込みます。repo-graph がある場合は、Claude が trace("groups") を呼び出すと、該当するハンドラー関数とファイルが正確に返され、それを読んで修正します。

FastAPI、Gin、Hono、NestJS の事前生成済みの例をご覧ください。インストールせずに確認できる、実際のグラフ出力です。

問題点

コードを扱う LLM は、コンテキストの大半をコードの把握に費やしてしまいます。

• 結局関係のないファイルを読む
• 異なる言語のコンポーネント間のつながりを見落とす
• 機能の開始地点や、どこに影響するのかがわからない
• 5 個で済むところで 50 個のファイルを読み込む

これはコストがかかり、時間もかかるうえ、コードベースが大きくなるほど悪化します。

repo-graph による解決方法

repo-graph はコードベースを一度スキャンし、次の要素からなるグラフを構築します。

• エンティティ：モジュール、パッケージ、クラス、関数、ルート、サービス、コンポーネント
• 関係：インポート、呼び出し、処理、定義、包含、スタックをまたぐ HTTP 通信
• フロー：エントリーポイントからデータ層までのエンドツーエンドの経路

その後、LLM が次のことを行える 6 つの MCP ツールを公開します。

1. 全体像を把握する — 「このリポジトリにはどの言語が含まれていますか？主な機能は何ですか？グラフで把握できていないのはどこですか？」
2. たどる — 「ルートからデータベースまで、ログインのフローをたどってください」／「UserService と payments API 間の最短経路は何ですか？」
3. 範囲を絞る — 「このバグに関係するノードはどれですか？」／「この修正に必要なファイルだけを挙げてください」
4. 影響を評価する — 「この関数を変更した場合の影響範囲はどれくらいですか？」／「ここにデッドコードはありますか？」

LLM は、何千行も読む代わりに、数百トークンで構造的なコンテキストを得られます。

最適な用途

repo-graph が真価を発揮するのは、コードベースが大きい、または複雑に入り組んでいて、モデルが一度に把握しきれない場合です。その効果は次の3つの要素に応じて高まります。

• 規模 — 関連ファイルを読むだけでコンテキストの上限を超えるほどのファイル数があること。
• 複雑さ — ルール、間接参照、レイヤーがあり、「そのまま読めばいい」という方法が通用しないこと。
• 境界をまたぐ広がり — 答えが複数のファイル、言語、サービスにまたがり、テキスト検索では関連付けられないこと。

特に適しているケース：

• モノレポ — 言語の境界を越えて、フロントエンドからバックエンドを呼び出すケースです。repo-graph は HTTP 呼び出しと、その呼び出し先のルート、さらにその背後にあるハンドラーを関連付けます。両側に共通の文字列がないため、テキスト検索ではできないことです。--repo にモノレポのルートを指定すると、すべてのプロジェクトを網羅する単一のグラフが作られます。 (上記のデモはまさにこのケースです。1つのリポジトリに Go と Angular があります。)

  他のツールは fetch／axios と Express、Fastify、Koa のルートを関連付けます。ここで異なるのは対応範囲です。同じ関連付けを、単一のグラフ内で Go、Python、Java、C#、Rust、PHP、Ruby などの間でも実行でき、gRPC、GraphQL、WebSocket、キュー、イベントも同じように扱えます。この幅広さはそれらのツールとのベンチマークで測定されていないため、実測された優位性ではなく、設計上の違いと捉えてください。

• マルチサービス／ポリレポシステム — サービスを1つのディレクトリ配下に置き、--repo にそのディレクトリを指定すると、1回の呼び出しでサービス境界をまたいで機能を追跡できます。

• 大規模な単一コードベース — コードの把握そのものにコストがかかる、数千のファイルからなるコードベースです。

• 不慣れなコードやレガシーコード — どこが何に触れているか、まだ把握できていない場合です。

効果が見込めないのは、小規模で、単一言語かつタスクが明確なリポジトリです。モデルがファイルをそのまま読めるため、この場合は grep のほうが有効で、グラフは余分な処理になります。また、トークン数を減らす目的だけで使うのも避けてください。MCP レイヤーのコストはターンごとに一定のため、簡単なタスクではかえってコストが増えることがあります。トークン削減の効果が表れるのは、上記のデモのような grep と読み込みを繰り返す悪循環を防げた場合だけです。確実に得られるのは、コンテキストに収まらないほど大きい、または相互のつながりが強いコードに対して、数回の呼び出しで正確かつ網羅的に、境界をまたいだ答えを得られることです。ご自身やモデルのコンテキストに収まらないコードが対象です。（MCP レイヤーを使いたくない場合は、省略して、エンジンを直接呼び出してください。）

MCP を使わずに使用する

MCP サーバーを使う方法なら設定不要ですが、グラフは MCP サーバーに限定されません。エンジンは通常の Python ホイールとして提供されています。pip install glia-py を実行すれば、グラフを構築し、スクリプトや独自のツールから同じ回答プリミティブを直接呼び出せます。ターンごとの MCP コストは一切かかりません。

import glia_py as rg

g = rg.load_from_gmap(rg.default_gmap_dir("."), ".")   # builds it if there's no cache yet

g.find("checkout")                              # ranked, located nodes for a name
g.blast_radius(["checkout", "Cart.add"], "both")  # many seeds, one walk, one ranking
g.cross_stack_trace("notifications")            # feature path across the stack, mechanism-labelled
g.resolve(open("error.log").read())             # stacktrace / test / diff → the nodes that matter
g.coverage()                                    # where extraction is partial (grep those)

これらはそれぞれ通常の Python オブジェクトを返します。検索結果は {"results": [...], "absence": {...}} という辞書、coverage() はリストを返します。results が空の場合、absence にその理由が示されるため、スクリプトは推測するのではなく、それに応じて処理を分岐できます。

同じグラフ、同じ答えを、コンテキストにツールスキーマを含めずに利用できます。MCP サーバーがラップしているものと同じ Rust エンジン（glia）を使っており、glia-py はその公開済みホイールです。CI チェック、バッチ分析、または独自のエージェントへのグラフの組み込みに適しています。

対応言語

言語	検出条件	抽出する内容
Go	go.mod	パッケージ、関数、HTTP ルート（gin/echo/chi/stdlib）、インポート
Rust	Cargo.toml	クレート、モジュール、構造体、トレイト、関数、ルート（Actix/Rocket/Axum）
TypeScript	tsconfig.json / package.json	モジュール、クラス、関数、インポート関係
React	package.json 内の react	コンポーネント、フック、コンテキストプロバイダー、React Router のルート、fetch/axios 呼び出し、フロー
Angular	package.json 内の @angular/core	コンポーネント、サービス、ガード、DI インジェクション、HTTP 呼び出し、機能フロー
Vue	package.json 内の vue	SFC、コンポーザブル、Vue Router のルート、fetch/axios 呼び出し
Python	pyproject.toml / setup.py / requirements.txt	パッケージ、モジュール、クラス、関数、ルート（Flask/FastAPI/Django）
Java/Kotlin	pom.xml / build.gradle	パッケージ、クラス、ルート（Spring/JAX-RS/Ktor/WebFlux/Micronaut）
Scala	build.sbt	パッケージ、オブジェクト／クラス／トレイト、ルート（Play/Akka HTTP/http4s）
Clojure	project.clj / deps.edn	名前空間、defn/defprotocol/defrecord、ルート（Compojure/Reitit）
C#/.NET	.csproj / .sln	名前空間、クラス、ルート（ASP.NET/Minimal API）
Ruby	Gemfile / .gemspec	ファイル、クラス、モジュール、Rails のルート
PHP	composer.json	名前空間、クラス、インターフェース、ルート（Laravel/Symfony）
Swift	Package.swift / .xcodeproj	ファイル、型（class/struct/enum/protocol/actor）、Vapor のルート
C/C++	CMakeLists.txt / Makefile / meson.build	ソース、ヘッダー、クラス、構造体、列挙型、名前空間、インクルード
Dart/Flutter	pubspec.yaml	モジュール、クラス、ウィジェット、go_router/shelf のルート
Elixir/Phoenix	mix.exs	モジュール、関数、Phoenix ルーターのスコープとルート
Solidity	.sol files / foundry.toml / hardhat.config.*	コントラクト、インターフェース、ライブラリ、イベント、継承
Terraform	.tf files	モジュール、リソース、変数、出力、モジュールのソース
SCSS	.scss files present	ファイル単位の肥大化分析

言語をまたいで動作する抽出器：

• スタック横断 HTTP：フロントエンドの fetch/axios 呼び出しを、呼び出し先のバックエンドルートおよびその背後のハンドラーにリンクします
• WebSockets：パスごとに対応付けたハンドラーとクライアント（gorilla、ブラウザー、Python、Java、C#）
• gRPC：.proto からサービス、メソッド、メッセージ型を抽出し、クライアントスタブとサーバー実装も抽出します
• GraphQL：リゾルバーと、それらを呼び出すオペレーション
• キュー：コンシューマーとプロデューサー（Celery、Dramatiq、BullMQ、Sidekiq、Oban、NATS）。定数からトピックを解決します
• イベント：イベントの発行元とハンドラー
• Cron ジョブ：スケジュールされたエントリーポイント
• ページナビゲーション：フロントエンドのルートと、それらをつなぐリンク（NAVIGATES_TO）
• データソース：DB／キャッシュ／キュー／Blob／検索／メールのクライアントと、それぞれにアクセスするコード
• データエンティティ：共有スキーマと、それを読み書きするコード
• CLI エントリーポイント：Python click、JS commander/yargs、Go cobra、Rust clap、Java picocli、C# System.CommandLine および Spectre
• コントラクト：OpenAPI / AsyncAPI / Pact のオペレーションを、それを実装するルートにリンクします
• 依存性注入：コンストラクターインジェクションを、注入される対象に紐付けます
• 設定キー：キーの定義場所と、それを読み取るすべての場所
• インフラ：Terraform および Kubernetes のリソース
• ドキュメント：ドキュメントのセクションを、それが管理するシンボルにリンクします（read が governed by として表示する内容）
• テスト：各テストがカバーするコード

1 つのリポジトリで複数の言語が検出されることがあります（例：Go のバックエンド + Angular のフロントエンド + SCSS）。それぞれのノードとエッジが、単一の統合グラフに追加されます。

インストール

1つのコマンド

uvx mcp-repo-graph install

インストール済みのAIコーディングエージェント（Claude Code、Claude Desktop、 Cursor、Windsurf、VS Code、Codex、Gemini CLI、opencode、Kiro）を検出し、それぞれの MCP 設定を書き込み、エージェントの指示ファイルに短い使用方法を追加します。これにより、エージェントは grep する前にグラフを参照するようになります。エージェントが対応している場合は、自動許可も設定するため、repo-graph のツールを呼び出すたびに確認を求められることはありません。

このコマンドは安全に再実行できます。また、uvx mcp-repo-graph uninstall を実行すると、グラフデータはそのまま残して、設定、指示、権限をすべて元に戻します。

uvx mcp-repo-graph install --agents all          # every supported agent, not just detected
uvx mcp-repo-graph install --scope user          # your global config, not this project
uvx mcp-repo-graph install --dry-run             # show what it would write, change nothing
uvx mcp-repo-graph install --yes                 # no prompt (scripts and CI)
uvx mcp-repo-graph install --print-config cursor # print one agent's config, write nothing

クライアントごとの手動設定

自分で接続したい場合は、パッケージ名がそのまま実行コマンドになります。 uvx mcp-repo-graph を実行するだけで動作します。事前の pip install は不要で、PATH に追加するものもありません。これは VS Code、Cursor、MCP レジストリが内部で使用しているものと同じコマンドです。

要件： Python 3.11 以降。uvx を使う場合は uv も必要です。Rust エンジン用のビルド済みホイールは Linux（x86_64、aarch64）、macOS（Intel と Apple Silicon）、Windows（x86_64）向けに提供されているため、Rust ツールチェーンは不要です。

Claude Code

claude mcp add repo-graph -- uvx mcp-repo-graph --repo .

（--repo . は現在のプロジェクトをグラフの対象にします。固定するには絶対パスを指定してください。）

VS Code

1つのコマンドでユーザー設定にサーバーを追加できます。

code --add-mcp '{"name":"repo-graph","command":"uvx","args":["mcp-repo-graph","--repo","${workspaceFolder}"]}'

または、MCP ギャラリーの項目にある インストール をクリックするか、手動で .vscode/mcp.json に追加してください（下記を参照）。

Cursor／任意の MCP クライアント — 手動設定

クライアントの MCP 設定（.mcp.json、.cursor/mcp.json、 .vscode/mcp.json、または ~/.claude.json）に以下を追加してください。

{
  "mcpServers": {
    "repo-graph": {
      "command": "uvx",
      "args": ["mcp-repo-graph", "--repo", "/path/to/your/project"]
    }
  }
}

永続的にインストールしたい場合は、pip install mcp-repo-graph（または uv tool install mcp-repo-graph）を実行すると、PATH に mcp-repo-graph／repo-graph コマンドが追加されます。その後、上記の設定で "command": "mcp-repo-graph" を使用してください。

--repo には Git URL も指定できます。 まだクローンしていない公開リポジトリも指定でき、浅いクローンを作成してマッピングします（git が必要です）。

uvx mcp-repo-graph --repo https://github.com/org/repo

クイックスタート

1. 対象リポジトリを初期化する（任意）

uvx --from mcp-repo-graph repo-graph-init --repo /path/to/your/project
# or, if installed:  repo-graph-init --repo /path/to/your/project

これにより、グラフを生成し、.mcp.json と CLAUDE.md の指示ファイルを書き込み、AI アシスタントが repo-graph を使えるように準備します。上記のワンライナーを使った場合は、この手順を省略できます。サーバーは初回接続時にグラフを構築します。

2. 使用する

AI アシスタントが6つのツールすべてにアクセスできるようになります。回答できる質問の例：

• 「このコードベースは何をしていますか？」 → orient ツール
• 「チェックアウトの流れを追跡して」 → trace ツール
• 「UserService を変更したら何が壊れますか？」 → impact ツール
• 「このバグに関係するノードはどれですか？」／「スタックトレースがあります。どこを見ればよいですか？」 → find ツール
• 「その関数のソースを表示して」 → read ツール
• 「グラフのコンテキスト全体を低コストで提示して」 → orient full=true
• 「大規模なリファクタリングの後に再構築して」 → refresh ツール

3. 最新状態の維持（自動）

グラフは自動的に最新状態を保ちます。サーバーの実行中はリポジトリを監視し、保存後すぐに増分再構築を行います。そのため、編集直後に構造について質問しても、手動で refresh しなくても変更が反映されます。さらに、グラフはコールドスタート時に自動修復されます。キャッシュされた .gmap が古い、旧形式、または存在しない場合、エンジンが再構築して書き戻すため、アシスタントの接続時にグラフが古いままになることはありません。

監視はデフォルトで有効です。無効にするには REPO_GRAPH_WATCH=0 を設定してください（コールドスタート時の更新は引き続き行われます）。監視には watchdog パッケージが必要ですが、依存関係として同梱されています。

チームメイトや CI でも使えるように、キャッシュを事前に作成してコミットしたい場合は、pre-commit フックを自動で追加できます。

uvx mcp-repo-graph install --agents none --git-hook

これにより、マーカーで囲まれた pre-commit フックがインストールされ、コミットのたびにグラフを更新して .glia/graph/ をステージします。uvx mcp-repo-graph uninstall を実行すると、フックを削除できます。

ヒント： グラフのディレクトリは自分自身を無視するため（.glia/graph/.gitignore）、フックが git add -f でステージしない限り、git status に表示されることはありません。フックを使わない場合も、監視とコールドスタート時の更新によってローカルのグラフは最新状態に保たれます。

MCP ツールリファレンス

repo-graph は6 つのツールを公開します。各ツールは自然な動詞 1 つで表され、Rust エンジンのプリミティブを基盤としています。

ツール	パラメーター	説明
orient	seed (任意)、full、budget	リポジトリに対する最初の呼び出しです。ノード／エッジの数、検出された種類、エントリーポイントを示し、どの言語／エッジのリンクが不足しているかを指摘する盲点の注記も含みます（その箇所を意識して grep できます）。seed=<node> → 範囲を絞ったマップ、full=true → リポジトリ全体の詳細マップ
find	query、expand、kind、top_k、budget	任意のテキストから、関連するノードを順位付けして返します。シンボル／キーワードのほか、貼り付けたスタックトレース／失敗したテスト ID／差分（関係するコードに解決されます）も指定できます。expand=true にすると周辺の近傍ノードに展開します。各行に path:line が含まれます
impact	nodes (カンマ区切り)、direction、depth、live_only、top_k、budget	影響範囲を示します。変更が影響する対象（forward）、または依存先／利用元（backward）を、順位付けされた位置情報付きの閉包として返します。各行にはエッジの理由 via が付き、エンジンが到達不能と判断した場合は ⊘ が表示されます（デッドコードの可能性があります）。複数のノードを渡すと、差分全体の影響範囲を確認できます
trace	from_node、to_node (任意)、depth、budget	引数 1 つの場合：機能をスタック全体にわたって追跡し、各ホップにその仕組み（呼び出し／HTTP／キュー／イベント）を示します。サービスをまたぐホップにはその旨が表示されます。引数 2 つの場合：2 つのノード間の最短経路を返します
read	node (カンマ区切り)、context_lines、budget	グラフの行範囲に基づき、ファイルから切り出したノードの正確なソースと、context: のフッター（HTTP メソッド、スタックをまたぐ呼び出し元またはクライアントの接続先、対象テスト、関連ドキュメント）を返します。カンマ区切りで指定すると、順位付けされたノードをまとめて読み取れます
refresh	repo_path (任意)、full	グラフを再構築します（デフォルトでは増分更新で、変更されたファイルのみを再解析します）。repo_path で別のパスまたは git URL を対象にできます。full=true を指定すると、クリーンな状態から再解析します。通常の編集はファイルウォッチャーが自動で取り込みます

ほとんどのツールは budget（最大文字数）も受け付けるため、小規模モデルのコンテキストウィンドウに収まる結果を返せます。

エンジンが、完全で、順位付けされ、位置情報付きで、稼働中のものに絞り込まれた結果を 1 回の呼び出しで返すプリミティブ（find、blast_radius、cross_stack_trace、resolve、coverage）を備えたため、以前の 13 個からこの 6 個に統合しました。ツールが少なければ、ターンごとに固定でかかるオーバーヘッドとエージェントの混乱を減らせます。

分からないときは、そのことを伝えます

ほとんどのツールは、空のクエリに対して何も返しません。そのためアシスタントは、「そのエッジは存在しない」のか「確認できなかった」のかを推測する必要があります。0.5.0 以降、結果が空の場合は構造化された不在として返されます。理由、その理由が**事実（FACT）かヒューリスティック（HEURISTIC）**か、そして結果が空だった仕組みに関して部分的な抽出があるものが示されます。

  No answer (no_edges, FACT): no carry edge touches `backend::server::server` in this graph;
  `backend::server::server` is a container: structural IMPORTS/CONTAINS/DEFINES are not carry
  edges, so seed a symbol inside it
    looked over: CALLS
    blind spots (grep to confirm):
      ⚠ CALLS (*): calls through reflection, dynamic dispatch, or higher-order indirection are
        not resolved — verify: grep the callee name
    searched 26 nodes

orient も同じ盲点をあらかじめ提示するため、モデルは情報の欠落を鵜呑みにせず、grep するタイミングが分かります。

測定結果。 FastAPI、Gin、Hono、NestJS から 14 個のシンボルを選びました。いずれもグラフにはエッジがないものの、実際には呼び出し元が存在するケースです。同じエージェントに同じタスクを与え、違いは空の回答が理由を説明するかどうかだけです。構造化された不在によって、同一タスクのコストは約 3 分の 1になり、対応する 28 組すべてで、ターン数は同じでした。回答が空である理由を伝えると、エージェントは再クエリをやめます。正確性は変わりませんでした。 Sonnet 5 は全 56 回で「削除しても安全ではない」と回答しました。エージェントによる稼働中コードの削除を防げると期待していたなら、それを裏付ける証拠はなく、慎重なモデルについては反証となる証拠がいくらかあります。ハーネスと生データは bench/absence/ にあります。モデルは 1 つ、n=14、独自のハーネスによる結果です。傾向を示すデータとして扱ってください。

0.5.0 ではさらに、差分全体に対する impact を 1 回の呼び出しで実行できます（解決できない名前は破棄せず報告します）。trace では、区別されたスタック横断パスを順位付けして返します。また、宣言されたコンポーネントやサービスが単に「クラス」として扱われないよう、役割を考慮したラベルも追加されました。

仕組み

mcp-repo-graph は、Rust エンジンの glia をラップする薄い Python MCP サーバーです。

1. 解析 — 各言語の tree-sitter パーサーが、生のノードと未解決の参照を抽出します
2. 抽出 — 横断的な抽出器が、HTTP ルート、データソース、CLI エントリーポイント、gRPC サービス、キューコンシューマーを追加します
3. 解決 — グラフビルダーがリポジトリ内の参照を解決し、グラフ間リゾルバーがスタックをリンクします（フロントエンドの HTTP 呼び出し → バックエンドのルートなど）
4. 保存 — マージされたグラフは .glia/graph/ に、ゼロコピーのシャーディングされた .gmap（rkyv + mmap）とマニフェストとして保存されます
5. 提供 — MCP サーバーがグラフをメモリに読み込み、6 つのツールを公開します

Rust エンジンは独立した glia リポジトリにあります。mcp-repo-graph は MCP 用の薄いラッパーです。

レイアウトの検出

repo-graph はプロジェクトを自動的に検出します — go.mod、package.json、pyproject.toml、Cargo.toml、 pom.xml、build.gradle、composer.json、pubspec.yaml、mix.exs、Package.swift、 CMakeLists.txt などに対応しています。モノレポのルートを --repo に指定すると、その下にあるすべてのプロジェクトが 1 つのグラフにまとめられます。

また、不要なディレクトリも自動的に除外します。node_modules、vendor、.venv、site-packages、ビルド出力 （dist、target、.next、.nuxt、.angular、coverage）およびハッシュ化されたバンドルディレクトリは、 ファイルごとに解析されず、単一のリージョンアンカーにまとめられます。また、.gitignore も適用されます。

注記： 以前のバージョンでは、skip: / roots: キーを使う config.yaml による回避策が説明されていました。 これは Python 時代の機能であり、Rust エンジンは読み込みません — お持ちの場合は無視されています。 自動検出でレイアウトが認識されない場合は、リポジトリの構成を添えて issue を作成してください。 誰にも見えない設定ファイルを用意するより、そのほうが役立ちます。

グラフデータ形式

生成されたファイルは、対象リポジトリ内の .glia/graph/ に保存されます。

• repo-<id>.gmap：グラフ本体。シャーディングされたゼロコピー rkyv 形式です（読み込み時に mmap されます）
• manifest.json：形式のバージョン、リポジトリのラベル、ルート、解析エラーを記録します。これにより、ウォームロードでも新規生成時と同じ結果になります
• parse_cache.bin：ファイルごとのコンテンツハッシュ付き解析キャッシュです。差分ビルドでは編集されたファイルのみを再解析します
• .gitignore：このディレクトリ自体を無視するため、git status に表示されません

ディレクトリ全体が再生成されます。削除すると、次回の呼び出し時に再構築されます。

エンジンには 36 種類のエッジカテゴリがあります。よく目にするのは、CALLS、IMPORTS、 CONTAINS、DEFINES、USES、HANDLED_BY、HTTP_CALLS、IMPLEMENTS、INHERITS_FROM、 INJECTS、ACCESSES_DATA、TESTS、DOCUMENTS、NAVIGATES_TO と、チャネル関連のもの （GRPC_CALLS、QUEUE_FLOWS、WS_CONNECTS、EVENT_FLOWS、GRAPHQL_CALLS、RPC_CALLS）です。 49 種類のノードがあります。どちらの一覧もエンジンに基づいているため、orient は常に実際に使用しているバージョンの 種類を報告します。

プライバシーポリシー

repo-graph はお使いのマシン上で動作し、コードをそのマシン内に保つように設計されています。全文はこちらです：PRIVACY.md。

• テレメトリー／アナリティクス： ありません。トラッキング、更新確認、外部への情報送信は行いません。
• データの収集と共有： ありません。ソースコードやグラフデータが repo-graph、その作者、または第三者に送信されることはありません。
• ローカル処理と保存： スキャンとグラフ構築はローカルで行われます。グラフはプロジェクトの .glia/graph/ ディレクトリにキャッシュされ、デバイス内に保持されます。
• ネットワークアクセス — ユーザーが開始する次の 2 つの場合のみ：
  1. インストール — uvx／pip が PyPI からパッケージとビルド済みエンジンの wheel をダウンロードします。
  2. Git URL のターゲット — --repo に Git URL を渡すと、repo-graph はユーザーが指定した URL に対して git clone を実行します。repo-graph やその作者に何かが送信されることはありません。ローカルの --repo パス（デフォルト）ではネットワーク呼び出しは一切ありません。
• データの保持： ローカルキャッシュは削除するまで保持されます。完全にユーザーの管理下にあります。
• お問い合わせ先： GitHub の issue

ライセンス

MIT

サポート

repo-graph が時間の節約に役立った場合は、コーヒーをごちそうしていただけると幸いです。

buymeacoffee.com/polycrisis