codegraph

CodeGraph

AI エージェントと開発者のための、クロス言語コードインテリジェンス。

CodeGraph はコードベースのセマンティックグラフ（関数、クラス、インポート、呼び出しチェーン）を構築し、42 個の MCP ツール、VS Code 拡張機能、JetBrains IDE プラグイン、永続メモリレイヤーを通じて公開します。tree-sitter を介して 38 言語を解析します。AI エージェントは、ファイルを grep する代わりに、構造化されたコード理解を得られます。

クイックスタート

MCP サーバー（Claude Code、Cursor、あらゆる MCP クライアント）

~/.claude.json（または MCP クライアントの設定）に追加します。

{
  "mcpServers": {
    "codegraph": {
      "command": "/path/to/codegraph-server",
      "args": ["--mcp"]
    }
  }
}

サーバーは現在の作業ディレクトリを自動的にインデックス化します。

VS Code 拡張機能

VSIX をインストールします。

code --install-extension codegraph-0.21.0.vsix

どのプラットフォームでも同じ VSIX を使用できます。 解析エンジンは同梱されていません。初回の有効化時に、拡張機能はお使いのプラットフォーム向けにビルドされたエンジンのダウンロードを提示し、公開済みのチェックサムと照合して検証したうえで、~/.codegraph/bin にインストールします。JetBrains プラグインも同じ場所を使用するため、1 回のダウンロードで両方を利用できます。 お使いの権限で実行されるネイティブバイナリのため、ダウンロードは自動ではなく、ユーザーに確認してから行われます。 ダウンロードを見送った場合は、準備ができたときにコマンドパレットから CodeGraph: Download Analysis Engine を実行してください。

エンジンが用意されると、拡張機能は自動的に起動し、すべてのツールを Copilot の言語モデルツールとして登録します。

JetBrains IDE

IntelliJ IDEA、PyCharm、GoLand、Android Studio などの IDE ファミリー向けプラグインは、LSP を介して同じエンジンを利用します。Code Vision、Symbols および Memories のツールウィンドウ、グラフパネル、AI Assistant へのワンクリック MCP 登録を備えています。 エンジンの解決またはダウンロードは VS Code 拡張機能と同じ方法で行い、~/.codegraph/bin を共有します。

→ jetbrains/README.md で、利用できる機能、エンジンの解決順序、ソースからのビルド方法をご覧ください。

AI エージェント向けルール

AI コーディングエージェント（Claude、Cursor、Windsurf、Codex、Cline）に、grep や複数ファイルの読み込みに頼る前に CodeGraph MCP ツールを使うよう指示する、事前設定済みのルールファイルです。自然言語の意図を適切な codegraph_* ツールに対応付けます。

→ codegraph-ai/codegraph-rules-for-agents

セットアップは cp <agent>/codegraph.md ~/<agent>/ です（エージェントごとに 1 行です。ルールリポジトリの README をご覧ください）。

GitHub Action — CI での PR レビュー

ワークフローをリポジトリに追加すると、すべての PR に対して、影響範囲、テストの不足、古くなったドキュメント、推奨レビュアーを含むコードグラフ分析のコメントを自動投稿できます。グラフのみで実行されるため（埋め込みや ONNX モデルは不要）、高速で API キーも必要ありません。組み込みの GITHUB_TOKEN のみで動作します。

.github/workflows/codegraph-pr.yml をリポジトリにコピーします。中核となる実行コマンドは 1 つです。

codegraph-server --graph-only \
  --run-tool codegraph_pr_context \
  --tool-args '{"baseBranch":"main","format":"markdown"}'

投稿可能な Markdown コメントが出力されます。--graph-only フラグは埋め込み生成をスキップします（インデックス作成が 10～50 倍高速になります）。--run-tool は MCP の stdio ハンドシェイクなしで 1 つのツールを実行して終了するため、スクリプトでの利用に最適です。

---

0.21 へのアップグレード

各プロジェクトは、0.21 で初めて開いたときにバックグラウンドで 1 回再埋め込みされます。 保存されるベクトルに、それを作成したモデルと設定が記録されるようになりました。0.20.1 以前のインデックスにはその情報が記録されていません。 処理中もキーワード検索は引き続き利用できます。

アップグレード後は、--watch デーモンを再起動してください。 起動したままのデーモンは、0.21 が読み込まないベクトルを書き込み続けます。また、デーモンに接続したセッションでは、再起動するまでセマンティック検索を利用できません。

getUserById のように単語が連結された識別子も、単語に分割された形式で埋め込まれるようになりました。 これは主に、TypeScript、Java、C# などの camelCase を使う言語での自然言語検索に役立ちます。 以前の動作を維持するには、--split-identifiers=false を指定してください。

--full-body-embedding=false が有効になりました。0.20.1 では、このフラグは常に有効でした。

---

設定

MCP サーバーのフラグ

フラグ	デフォルト	説明
--workspace <path>	current dir	インデックス対象のディレクトリ（複数プロジェクトの場合は繰り返し指定できます）
--exclude <dir>	—	除外するディレクトリ（繰り返し指定できます）
--embedding-model <model>	bge-small	bge-small（384d、高速）、jina-code-v2（768d、6 倍低速）、granite-97m（384d、32K ctx、約 3 倍低速）、または static（model2vec、256d — インデックス作成が約 100 倍高速、ONNX 不要。ローカルモデルディレクトリが必要です。下記を参照）
--full-body-embedding	true	より良いセマンティック検索と重複検出のため、関数本体全体（約 50 行）を埋め込みます。値を指定します。--full-body-embedding=false で無効になります
--split-identifiers	true	単語がつながっている識別子について、単語に分割した形式も埋め込みます。そのため、getUserById は「get user by id」としても埋め込まれます。すでに _ または - で区切られている名前は、同じ単語にトークン化されるためそのままになります。先頭または末尾の区切り文字は何も区切らないため、_handleClick は handleClick と同様に分割されます。値を指定します。--split-identifiers=false にすると、リリース 0.20.1 までと同様に未加工の名前を埋め込みます
--max-files <n>	5000	インデックス対象の最大ファイル数
--profile <name>	all	公開する MCP ツールの範囲を指定したサブセットに絞り込みます（下記を参照）
--graph-only	off	埋め込みの生成をスキップし、グラフを構築して構造関連ツールのみを提供します。ONNX モデルを読み込まず、インデックス作成は 10〜50 倍高速になります。セマンティック検索とメモリツールは利用できません。CI や一度限りのグラフクエリ向けです。
--run-tool <name>	—	一度限りのモードです。インデックスを作成し、単一のツールを実行して結果を出力し、終了します。MCP ハンドシェイクは行いません。--tool-args '<json>' と組み合わせてください。

--split-identifiers と --full-body-embedding はどちらも、各シンボルの埋め込み元となるテキストを変更します。異なるテキストから作成されたベクトル同士は、相互にランク付けできません。 そのため、プロジェクトに保存されたベクトルには、作成時の設定（次元が異なるモデルを使う --embedding-model を含む）が記録され、設定が異なるプロセスでは無視されます。 この 3 つの設定のいずれかを変更すると、手動で再インデックスする必要はなく、バックグラウンドで再埋め込みが行われます。 プロジェクトを読み取るセッションと同じフラグを指定して --watch を実行してください。双方で再埋め込みが競合することなく、同じベクトルセットを共有できます。 0.20.1 以前からのアップグレードでの影響については、0.21 へのアップグレードを参照してください。

--embedding-model static — model2vec による高速インデックス作成

Static（model2vec）埋め込みは、ONNX トランスフォーマーをトークン→ベクトルのルックアップテーブルに置き換えます。インデックス作成は約 100 倍高速（このリポジトリの 5,873 個のシンボルの埋め込みに、BGE では約 3.4 分かかるのに対し、約 1 秒で完了）で、ONNX ランタイムも 1.5 GB の RAM 要件もありません。 検索は引き続き**ハイブリッド方式（BM25 + セマンティック）のため、エンドツーエンドの品質はBGE の約 90％**です。 モデルはどのクライアントにも同梱されていません。~/.codegraph/static_models/jina-code-static-256、または CODEGRAPH_STATIC_MODEL が指す場所にローカルモデルディレクトリ（config.json + tokenizer.json + model.safetensors）が必要です。

• npm から @astudioplus/codegraph-mcp をインストールすると、デフォルトの場所にモデルがダウンロードされます（ベストエフォートです。スキップするには CODEGRAPH_SKIP_MODEL_FETCH=1 を設定してください。ダウンロードに失敗してもインストールは失敗しません）。
• それ以外の場合は、scripts/fetch-static-model.sh でビルド済みモデルを取得するか、任意のセンテンストランスフォーマー（デフォルトは Apache-2.0 ライセンスの Jina-Code）から、CPU で約 30 秒かけて独自のモデルを蒸留できます：python scripts/distill_static_model.py。
• デフォルトの場所にあるモデルには、IDE の設定は不要です。どちらの IDE クライアントも CODEGRAPH_STATIC_MODEL を未設定のままにして、エンジンによる解決に任せます。別の場所に保存されたモデルを使用するには、VS Code では codegraph.staticModelPath を、JetBrains では 設定 → ツール → CodeGraph → 埋め込み → Static model directory を設定します。各クライアントは、そのパスを CODEGRAPH_STATIC_MODEL として渡します。

CODEGRAPH_SKIP_MEMORY_CHECK — 埋め込みモデルの RAM チェックを強制的に回避する

ONNX モデルを読み込む前に、サーバーは利用可能なメモリを確認し、約 1.5 GB 未満の場合は OOM キルを避けるためにモデルの読み込みをスキップします（代わりにグラフのみで動作します）。 CODEGRAPH_SKIP_MEMORY_CHECK=1（true／yes も使用できます）を設定すると、 このチェックを回避し、常にモデルを読み込みます。

マシンに十分な空き RAM があるのに、埋め込みが無効になっている場合に使用してください。 利用可能なメモリが 0 MB と検出された場合は、検出の失敗として扱われ、モデルは読み込まれます（macOS は再利用可能なメモリを非アクティブ／投機的ページに保持し、一部のメモリ読み取りツールでは空きとしてカウントされないためです）。そのため、このオーバーライドは主に、報告された値が低いものの誤っている場合に使用します。 MCP モードとワンショットの --run-tool モードの両方で機能します。

--profile — MCP ツールの範囲を絞り込む

全 42 ツールを利用できるのは便利ですが、エージェントのプロンプトコンテキストのコストが増加します。プロファイルを使うと、必要な範囲だけを利用できます（CODEGRAPH_TOOL_PROFILE 環境変数でも設定できます）。

プロファイル	ツール	使用する場面
all (デフォルト)	すべてのツール（コミュニティ版＋Pro）	通常のセッション
core	8 — 検索＋シンボル情報＋AI コンテキスト	検索だけが必要な、やり取りの多いエージェントセッション
graph	17 — 呼び出し元／呼び出し先／依存関係／影響分析／トラバース／PR コンテキスト	リファクタリング＋構造解析
memory	14 — codegraph_memory_* とドキュメントツール	メモ作成／ナレッジベースのワークフロー
security	Pro のセキュリティツールのみ（コミュニティ版では空）	Pro のセキュリティ監査

VS Code の設定

codegraph.* 設定の説明は、それらを読み込む拡張機能の横にまとめて記載しています。

→ vscode/README.md — 設定

全文の埋め込みはデフォルトで有効です。関数の本文テキストは解析時に取得されるため、I/O のオーバーヘッドはありません。

組み込みの除外設定（常にスキップ）では、次の 3 カテゴリにわたる約 47 個のディレクトリが対象になります。

• ビルド／キャッシュ: node_modules、target、dist、build、out、.git、__pycache__、vendor、.venv、venv、.tox、.pytest_cache、.mypy_cache、.ruff_cache、.next、.nuxt、.svelte-kit、.parcel-cache、.npm、.yarn、.pnpm-store、.cache、.cargo、.bundle、.gradle、DerivedData、Pods、xcuserdata、cmake-build-*
• IDE／IaC の状態: .idea、.vscode-test、.fleet、.terraform、.terragrunt-cache、.serverless
• 機密性の高い認証情報ディレクトリ: .aws、.ssh、.gnupg、.kube、.docker

さらに、バイナリアーカイブ、ネイティブライブラリ、OS メタデータ、シークレットファイルの拡張子（*.pem、*.key、*.p12、*.pfx、*.crt、*.gpg、*.kdbx、id_rsa などの SSH キーの慣例名など）を対象とするグロブパターンもあります。認証情報を誤って埋め込まないための多層防御です。

インデックス作成でファイルが 1 つも生成されなかった場合や、ほかに問題がある場合は、 docs/troubleshooting.md を参照してください。

---

ツール

コミュニティ版には 42 個のツールがあり、CodeGraph Pro ではさらに 27 個（うち 17 個はセキュリティアナライザー）を利用できます。

コード分析（11）

ツール	説明
get_ai_context	主要なコンテキスト取得ツールです。 意図（説明／変更／デバッグ／テスト）を認識し、トークン数を調整します。ソース、関連シンボル、インポート、兄弟要素、デバッグのヒントを返します。
get_edit_context	編集前に必要な情報をすべて取得します。ソース、呼び出し元、テスト、メモ、Git 履歴を返します。
get_curated_context	自然言語のクエリ（「認証はどのように機能しますか？」など）に対して、コードベース全体のコンテキストを取得します。
analyze_impact	影響範囲を予測します。変更、削除、名前変更によって何が壊れるかを示します。
analyze_complexity	循環的複雑度を内訳（分岐、ループ、ネスト、例外、早期リターン）とともに示します。
find_circular_deps	ファイル間の循環インポート／依存関係チェーンを検出します。
find_hot_paths	推移的な呼び出し元の数で順位付けした、最も多く呼び出される関数を示します。
find_dead_imports	使用されていないインポート、つまりインポートされているものの参照されていないモジュールを検索します。
get_module_summary	ディレクトリの概要（ファイル数、関数、言語の内訳、複雑度の高い関数の上位）を示します。
search_by_pattern	関数本体、シグネチャ、名前、ドキュメント文字列を対象に正規表現検索を行います。
search_by_error	特定のエラー型をスロー、キャッチ、または処理する関数を検索します。

コードナビゲーション（13）

ツール	説明
symbol_search	名前または自然言語でシンボルを検索します（BM25 とセマンティック検索のハイブリッド）。
get_callers / get_callees	これを呼び出すのは何か？ これは何を呼び出すのか？（推移的な深さを指定可能）
get_detailed_symbol	シンボルの詳細情報（ソース、呼び出し元、呼び出し先、複雑度）を取得します。
get_symbol_info	簡易メタデータ（シグネチャ、可視性、種類）を取得します。
get_dependency_graph	深さを指定して、ファイル／モジュールのインポート関係を取得します。
get_call_graph	関数の呼び出しチェーン（呼び出し元と呼び出し先）を取得します。
find_by_imports	モジュールをインポートしているファイルを検索します。
find_by_signature	パラメーター数、戻り値の型、修飾子で検索します。
find_entry_points	メイン関数、HTTP ハンドラー、CLI コマンド、イベントハンドラーを検索します。
find_implementors	ops 構造体のコールバックとして登録されている関数をすべて検索します。
find_related_tests	指定された関数を実行するテストを検索します。
traverse_graph	エッジ／ノード型のフィルターを使って、グラフをカスタムにたどります。

インデックス作成（3）

ツール	説明
reindex_workspace	ワークスペースの全体または差分インデックスを再作成します。
index_files	インデックスをすべて再作成せずに、特定のファイルを追加／更新します。
index_directory	既存のデータとともに、ディレクトリをグラフに追加します。

メモリ（7）

セッションをまたいで AI コンテキストを保持します。デバッグの知見、アーキテクチャ上の決定事項、既知の問題などを保存します。

ツール	説明
memory_store / memory_get / memory_search	メモリを保存、取得、検索します（BM25 とセマンティック検索）。
memory_context	ファイル／関数に関連するメモリを取得します。
memory_list / memory_invalidate / memory_stats	メモリの一覧表示、無効化、監視を行います。

Tempera と組み合わせると効果的です。Tempera は、プロジェクト間で応用できるデバッグ戦略や解決策を記録するエピソード記憶システムです。CodeGraph のメモリツールはプロジェクト単位のメモを保存し、Tempera はプロジェクトをまたいで活用でき、時間とともに改善される BKM（最良の既知の手法）を記録します。

PR／変更分析（1）

ツール	説明
pr_context	1 回の呼び出しで PR をレビューします。 ベースブランチとの差分を Git で取得し、グラフから変更された関数を見つけ、影響範囲（呼び出し元）、テストカバレッジと不足箇所、影響を受けるモジュール、差分を考慮した変更分類（シグネチャか本体か）、古いドキュメントへの警告、複雑度、コミットメッセージのヒント、git blame に基づく推奨レビュアーを報告します。

ドキュメント（7）

永続的なプロジェクトドキュメント — 設計ドキュメントをインデックス化して意味検索し、コードが設計に合致しているか検証し、コードグラフからアーキテクチャドキュメントを生成します。

ツール	機能
index_markdown	ローカルの .md ファイル（ARCHITECTURE.md、API_DESIGN.md など）を永続ドキュメントストアにインデックス化します。見出しツリーに基づいて分割し、末端ノードの埋め込みを作成します。
search_docs	インデックス化されたドキュメントを意味検索し、見出しパスのパンくずリストとともに一致したセクションを返します
list_doc_sources	インデックス化されたすべてのソースファイルを一覧表示します
remove_doc_source	ソースファイルからインデックス化されたチャンクをすべて削除します
verify_design	ドキュメント内の主張をコードグラフと相互参照します。direction=forward（ドキュメント→コード）、reverse（コード→ドキュメント）、または both を指定します
design_gaps	ドキュメントに記述されているものの、まだコードに存在しない識別子を見つけ、仕様から TODO リストを作成します
generate_architecture_doc	実際のコードグラフ（モジュール、ホットパス、複雑度、循環依存）から、構造化された ARCHITECTURE.md を自動生成します

すべてのツール名には codegraph_ が接頭辞として付きます（例：codegraph_get_ai_context）。特定のシンボルを対象とするツールでは、uri と line、または symbol_search の結果に含まれる nodeId を指定します。

---

使用例

設計ドキュメントをインデックス化して検索する：

codegraph_index_markdown(path: "/projects/myapp/docs/ARCHITECTURE.md")
codegraph_search_docs(query: "how does the auth module handle JWT refresh?")

コードが設計に合致しているか確認する：

codegraph_verify_design(source: "/projects/myapp/docs/ARCHITECTURE.md", direction: "forward")
// → "132/132 identifiers verified, 0 gaps"

ドキュメントに記述されているものの、まだ実装されていない内容を見つける：

codegraph_design_gaps(source: "/projects/myapp/docs/API_DESIGN.md")
// → "4 of 12 identifiers not found in code: PaymentService, RefundHandler, ..."

コードグラフからアーキテクチャドキュメントを生成する：

codegraph_generate_architecture_doc(scope: "src/", topN: 5)
// → Markdown with modules, complexity hotspots, hot paths, circular deps

デバッグで得た知見を今後のセッションのために保存する：

codegraph_memory_store(kind: "debug_context", title: "Nginx body size limit",
  content: "The /upload endpoint fails on payloads > 1MB...",
  problem: "API returns 500 on large uploads",
  solution: "Increase nginx client_max_body_size to 10M",
  agentSource: "claude")

グラフ圧縮の統計情報と設計ドキュメントの補足を含む AI コンテキストを取得する：

codegraph_get_ai_context(uri: "file:///projects/myapp/src/auth.rs", line: 42, intent: "modify")
// → Code context + graphStats: {entitiesInGraph: 13555, entitiesTraversed: 47, entitiesKept: 8}
// → design_context section from indexed docs mentioning "auth"

PR をレビューする — 影響範囲、テストの不足、古くなったドキュメント、レビュアーを一度に確認します：

codegraph_pr_context(baseBranch: "main")
// → "PR changes 4 files (+263/-77, 12 functions). 37 direct callers, 8 tests, 3 untested. Risk: medium."
// → test_gaps: [refresh_token, revoke_session] — functions with 0 test callers
// → stale_docs: ["auth.rs described in ARCHITECTURE.md > Authentication — doc may need updating"]
// → suggested_reviewers: [{author: "anvanster", lines_owned: 3200}]
// → commit_hint: "feat(mcp): <describe the change>"

やり取りの多いセッションで、ツールの範囲を絞る：

codegraph-server --mcp --profile=core  # Only 8 tools: search + symbol info + AI context

---

CodeGraph Pro

CodeGraph Pro で利用できる追加ツール：

ツール	機能
scan_security	セキュリティ脆弱性スキャン：40 以上の危険な関数パターン、ソースからシンクへの汚染追跡、HTTP エンドポイントの認証カバレッジ（7 つの言語／フレームワーク）、アーキテクチャ層の違反、弱い暗号方式、ハードコードされたシークレット
analyze_coupling	モジュール結合度のメトリクスと不安定性スコア
find_unused_code	信頼度スコア付きのデッドコード検出
find_duplicates	重複／類似関数の検出
find_similar / cluster_symbols / compare_symbols	埋め込みベースのコード類似性分析
cross_project_search	インデックス化されたすべてのプロジェクトを横断検索
mine_git_history / mine_git_history_for_file / search_git_history	Git 履歴のマイニングとセマンティック検索
security_control_flow	関数内のすべての実行経路をマッピングします。「認証チェックを通らずに戻る可能性はありますか？」
security_trace_data_flow	変数の生成から破棄までを追跡します。「ユーザー入力はこの SQL クエリに到達しますか？」
security_generate_sbom	8 種類のロックファイル形式から CycloneDX SBOM を生成
security_audit_deps	依存関係の OSV 脆弱性チェック
security_check_unchecked_returns / _resource_leaks / _misconfig / _input_validation / _error_exposure	CWE Top 25 の約 80％をカバーする 5 種類のヒューリスティック分析ツール
security_scan_iac	Docker／Kubernetes／Terraform の設定ミスをスキャン
security_check_licenses	ロックファイルのライセンスポリシー適用（コピーレフトの検出）
security_check_secrets_entropy	シャノンエントロピーを利用したハードコードされたシークレットの検出
security_detect_injection	SQL／XSS／コマンド／パス／デシリアライゼーション／テンプレートインジェクションを重点的に検出（20 パターン）
security_check_search_path	信頼できない検索パス／DLL ハイジャックの検出（CWE-426/CWE-427）
security_check_crypto	暗号の誤用：弱い暗号方式／ハッシュ／PRNG／キー、固定 IV、タイミング漏えいを引き起こす比較（CWE-208/326-330/338/916、35 パターン）
security_export_sarif	検出結果を SARIF 2.1.0 として集約（GitHub Code Scanning、GitLab SAST）

横断的な機能（すべての security_check_* ツール）：

• include_tests / treat_as_production — テスト／サンプル／ベンダー提供コードを優先的にスキップ
• check_compile_gates — C/C++ の検出結果で、#ifdef X 内にあり、X が CMake/Cargo/Makefile で定義されていないものには DEFENSIVE_GATED_OFF の印が付きます
• 25 種類の抑制マーカー（# nosec、// NOLINT、// codeql[ignore]、# rubocop:disable など）を行単位および関数単位で尊重
• スキャンごとのテレメトリブロック：path_filter（調査／一致／スキップ）＋ compile_gate（ゲートにより無効化された件数）

---

言語

tree-sitter で解析される 38 言語 — 関数、クラス、インポート、コールグラフ、複雑度メトリクス、依存関係グラフ、シンボル検索、影響分析：

カテゴリ	言語
システム	C、C++、Rust、Zig、Objective-C
JVM	Java、Kotlin、Scala、Groovy、Clojure
Web／スクリプト	TypeScript/JS、Python、Ruby、PHP、Perl、Lua、Elixir、Elm
Web／スタイル	CSS
モバイル	Swift、Dart
関数型	Haskell、OCaml、Julia、Erlang、Elm、Clojure
エンタープライズ	C#、COBOL、Fortran、Go
ブロックチェーン	Solidity
シェル／設定	Bash、Dockerfile、HCL/Terraform、TOML、YAML
ハードウェア	Verilog/SystemVerilog、Tcl
データサイエンス	R、Julia

HTTP ハンドラーの検出：Python（FastAPI/Flask/Django）、TypeScript（NestJS）、Java（Spring/JAX-RS）、Go（stdlib/Gin/Echo/Fiber）、C#（ASP.NET）、Ruby（Rails）、PHP（Laravel/Symfony）。

コミュニティ版とフルビルドの違い： COBOL、Fortran、Perl、Dart、Zig、R は --features extra-languages を指定した場合にのみコンパイルされます。デフォルトのコミュニティ版バイナリには 含まれません。これらの利用状況はテレメトリでゼロであり、tree-sitter の文法を追加すると 約 25 MB 増加するためです（COBOL のパーステーブルだけで 30 MB あります）。それ以外の 32 言語は 常に利用できます。

---

アーキテクチャ

MCP Client (Claude, Cursor, ...)   VS Code Extension   JetBrains Plugin
        |                                  |                  |
    MCP (stdio)                       LSP Protocol       LSP Protocol
        |                                  |                  |
        └───────────┐               ┌──────┴──────────────────┘
                    ▼               ▼
            ┌─────────────────────────────┐
            │       codegraph-server      │
            ├─────────────────────────────┤
            │  38 tree-sitter parsers     │
            │  Semantic graph engine      │
            │  AI query engine (BM25)     │
            │  Memory layer (RocksDB)     │
            │  Docs store (RocksDB+HNSW)  │
            │  Full-body embeddings (BGE) │
            │  HNSW vector index          │
            └─────────────────────────────┘

1つの Rust バイナリで MCP と LSP の両方のプロトコルに対応します。

• インデックス作成：毎秒約60ファイル。FNV-1a コンテンツハッシュを使い、ファイル変更時に差分インデックスを作成します。
• 永続化：グラフと埋め込みベクトルは ~/.codegraph/graph.db（RocksDB）に永続化されます。再起動時は再解析も再埋め込みも行わず、すぐに起動します。
• クエリ：100ミリ秒未満。インデックス作成時にファイル間のインポートと呼び出しを解決します。
• 埋め込みベクトル：関数本体を解析時に取得する完全な本体データを使用するため、ディスク I/O はゼロです。ベクトルはグラフとともに RocksDB に保存されます。初回実行時にモデルを自動ダウンロードします。

---

対応プラットフォーム

エンジンはネイティブバイナリで、初回実行時にお使いのプラットフォーム向けにダウンロードされます。

プラットフォーム	アーキテクチャ
macOS	Apple Silicon（arm64）および Intel（x64）
Linux	x64 および arm64
Windows	x64（ARM 版 Windows では、エミュレーションを使って x64 ビルドを実行します）

Linux では glibc 2.30 以降 および GCC 11 以降の libstdc++（GLIBCXX_3.4.29）が必要です。 後者が実際の必須条件であり、前者を満たしても後者が満たされるとは限りません。エンジンに組み込まれている ONNX Runtime は GCC 11 でビルドされているためです。

動作する環境	動作しない環境
SLES 15 SP4	Ubuntu 20.04
Ubuntu 22.04 以降	Debian 11
Debian 12 以降	RHEL / CentOS 8
RHEL 9 以降	Amazon Linux 2
Amazon Linux 2023

Linux のどちらのアーキテクチャでも、必要条件は同じです。エンジンが次のようなメッセージを表示してすぐに終了する場合、

version `GLIBCXX_3.4.29' not found (required by codegraph-server)

ディストリビューションの C++ ランタイムがエンジンの要件を満たしていません。より新しい libstdc++（たとえば RHEL 8 の gcc-toolset-11）をインストールすれば、ディストリビューションをアップグレードせずに解決できます。

---

ソースからのビルド

git clone https://github.com/codegraph-ai/codegraph
cd codegraph
cargo build --release -p codegraph-server    # Rust server
cd vscode && npm install && npm run esbuild  # VS Code extension
npx @vscode/vsce package                     # VSIX

rustup（rust-toolchain.toml で固定された Rust バージョンをインストールします）、Node.js 18 以降、VS Code 1.90 以降が必要です。

---

プロジェクトを支援する

CodeGraph は無料のオープンソースプロジェクトで、単独の開発者がメンテナンスしています。 作業時間の節約に役立った場合は、GitHub でのスポンサーをご検討ください。プロジェクトの継続と成長を支える助けになります。

---

ライセンス

Apache-2.0