業務システムの改修を担当していて、AIコーディングエージェント（人間の指示なしにコードを自律的に読み書きするツール）に大規模なコードベースを触らせることに不安を感じているなら、この話は関係があります。
Claude Code、Cursor、Codexのようなツールは、局所的な関数編集は得意です。ただし呼び出し関係全体を把握しないまま変更を加えることがあります。この問題は「dependency blindness（依存関係の盲点）」と呼ばれ、数十万行規模の業務システムほど深刻になりがちです。
GitNexusは、この盲点を解消するために開発されたオープンソースのコードインテリジェンスエンジンです。開発者はAbhigyan Patwari氏で、サーバーを一切使わずにリポジトリをナレッジグラフ（コード要素の関係性を図構造で表現したもの）に変換する点が特徴です。
GitNexusが解決しようとしている問題
エンタープライズのコードベースでは、1つの関数を修正すると呼び出し元・呼び出し先・継承関係にあるクラスまで影響が波及することが珍しくありません。
たとえば決済処理の共通関数を1つ変更しただけで、注文管理・在庫管理・請求書発行の3つのモジュールに影響が出るケースを想像してください。人間のエンジニアならgrepやIDEの参照検索で追跡できますが、AIエージェントが同じ配慮なしに編集すると、見えないところで既存機能を壊すリスクがあります。
GitNexusはこの「影響範囲（blast radius）」をAIエージェントに事前確認させる仕組みを提供します。コードを書き換える前に、依存関係のクエリを投げて安全性を確かめてから作業できる設計です。
技術的な仕組みを段階的に見る
GitNexusの中核は、Tree-sitter（複数のプログラミング言語に対応した構文解析ライブラリ）を使ったソースコード解析です。関数呼び出し・クラスの継承・モジュールのimport文・実行パスを読み取り、AST（抽象構文木、コードの構造を木構造で表現したもの）ベースのナレッジグラフを構築します。
このグラフ構築とパース処理は、すべてローカル環境かブラウザ内で完結します。ソースコードが外部サーバーやサードパーティのデータベースに送信されることはありません。金融・医療・官公庁系のシステムなど、ソースコードの外部送信自体がセキュリティポリシー上NGな現場でも検討しやすい設計です。
もう1つの柱がMCP（Model Context Protocol、AIツールが外部データソースやツールと標準化された方法でやり取りするための規格）への対応です。GitNexusはMCPサーバーとして動作し、Claude Code・Cursor・Kiroといったツールからリポジトリ構造をプログラム的に問い合わせられます。これにより、AIエージェントがコード編集の前に「この関数を消したら何が壊れるか」を機械的に確認できるようになります。
従来のRAG（Retrieval-Augmented Generation、生成前に関連情報を検索して補完する手法）は、ベクトル類似度によるテキスト検索が中心でした。この方式は文章としては似ているコードを拾えても、実際の呼び出し関係までは保証できません。GitNexusはASTパースとグラフ検索を組み合わせることで、正確な呼び出し階層をAIモデルに渡す点が異なります。
利用方法はブラウザとCLIの2通りが用意されています。
# ブラウザで即座に試す場合
# https://gitnexus.vercel.app にアクセス
# ローカルCLIで実行する場合
npx gitnexus関連技術との違いを整理する
コードの依存関係を可視化する手法自体は新しくありません。Javaの世界ではEclipseのCall Hierarchy機能、静的解析ではSonarQubeの依存関係グラフなど、既存ツールも同様の目的を持っています。
GitNexusが異なるのは、これらの解析結果をAIエージェントが「実行前に問い合わせるAPI」として使える点です。従来の静的解析ツールは人間が画面で確認するためのものでした。GitNexusはMCP経由でエージェントのワークフローに組み込むことを前提に設計されています。
またベクトル検索ベースのRAGとの使い分けも整理しておく価値があります。自然言語での質問応答（「このAPIの使い方を教えて」等）にはベクトル検索が向いていますが、「この関数を削除した場合の影響範囲は」といった構造的な問いにはグラフベースの検索の方が精度が出やすい領域です。両者は排他的な選択肢ではなく、併用を検討する余地があります。
業務システムの現場での確認ポイント
実際に検討する場合、以下の点を確認しておくと判断しやすくなります。
- 対応言語: 使用中の言語がTree-sitterのパーサー対応範囲に含まれるか、GitHubリポジトリのREADMEで確認する
- リポジトリ規模: モノレポや数十万行級のコードベースで、グラフ構築にかかる時間とメモリ消費を試しておく
- MCP対応クライアント: 現在使っているAIコーディングツールがMCPサーバー接続に対応しているか確認する（Claude Code、Cursor、Kiroは対応例として挙げられています）
- セキュリティポリシーとの整合: ローカル完結型とはいえ、社内のツール導入承認プロセスに沿った確認が必要か
導入を検討する場合は、まず小規模なリポジトリか、業務コードの一部を切り出したサンプルでnpx gitnexusを実行し、生成されるグラフの粒度が実務の判断に耐えるか試してみるのが現実的な進め方です。ブラウザ版であればインストール不要で挙動を確認できるため、社内稟議の前段階の検証にも使いやすい構成になっています。
まとめ
GitNexusは、AIコーディングエージェントが陥りがちな依存関係の見落としを、ナレッジグラフとMCP連携で補う仕組みです。
重要な点を整理すると次の3つになります。
- サーバー不要でローカル完結、ソースコードを外部に出さない設計
- MCPサーバーとして動作し、AIエージェントが編集前に影響範囲を問い合わせられる
- ベクトル検索中心のRAGでは拾いにくい正確な呼び出し階層をグラフで補完する
既存の大規模コードベースにAIエージェントを本格導入する前に、まずは小さなリポジトリでnpx gitnexusを試し、生成されたグラフが自社のコード構造をどこまで正確に捉えているか確かめてみてください。