目次

GitNexusを試してみることにした理由

最近、Claude Codeと組み合わせて使えそうなツールを探していて、GitNexusというものを見つけました。

GitNexusは、リポジトリ内のコードを解析して、ファイルや関数の関係、呼び出し経路、処理フローなどをグラフ化してくれるツールです。Claude CodeやCursorなどとMCP経由で連携することもできるようで、「既存プロジェクトをAIに理解させる用途ではかなり便利そうだな」と思い、実際に試してみました。

先に感想を書いてしまうと、GitNexusを入れたことでClaude Codeが劇的に賢くなった、という感じではありませんでした。一方で、プロジェクト全体をWikiとして自動生成する機能はかなり良く、既存システムの全体像を把握したり、引き継ぎ資料を作ったりする用途では便利そうです。

今回は、実際に開発中のプロジェクトへGitNexusを入れてみて、Claude Codeとの連携、Wiki生成、バグ検出まで試してみました。

GitNexusとは

GitNexusは、GitHubなどのリポジトリを解析して、コード同士の関係を知識グラフとして作成するツールです。

普通にClaude Codeを使っている場合でも、Claudeは必要に応じてファイルを検索したり、関数の呼び出し元を調べたりできます。GitNexusを使うと、そうした情報をあらかじめ解析しておき、

  • 「この関数を変更したらどこに影響するのか」
  • 「この処理はどこから呼ばれているのか」
  • 「この機能はどのファイルをまたいで動いているのか」

といった情報をClaude CodeがMCP経由で参照できるようになります。イメージとしては、Claude Codeに新しい能力を追加するというより、プロジェクト全体の「地図」を先に作って渡しておく感じです。

Claude Codeで使うならCLI版が良さそう

GitNexusにはWeb版もありますが、今回はClaude Codeと組み合わせて使いたかったのでCLI版を使いました。プロジェクトのルートで、

npx gitnexus analyze

を実行すると、リポジトリ内のコードが解析されます。今回試したプロジェクトでは、

  • 852 nodes
  • 2,244 edges
  • 29 clusters
  • 67 flows

という結果になりました。解析には約172秒かかっています。この時点で、ファイルや関数、呼び出し関係などがGitNexusのグラフに登録されます。

解析結果は基本的にプロジェクト内の、.gitnexus/に保存されます。そのため、一度Claude Codeを終了して翌日に起動し直しても、同じプロジェクトであればGitNexusの解析結果を再利用できます。毎回Claude Codeがゼロからプロジェクト全体を解析し直す必要がない、というのは確かに便利です。

解析結果には上限がある

最初に解析した時、少し気になるログが出ました。

truncation: entryPointsUnexplored=77, calleesDropped=120, processesDropped=48

さらに、67 flows reported, but whole flows are MISSINGという警告も出ています。

重要: 最初は「無料版だから解析数に制限があるのかな」と思いました。調べてみると、これは有料・無料の違いではなく、GitNexus側が処理量を抑えるために設けている上限でした。GitNexusには実行フローを追跡する際の深さや分岐数などに制限があり、大きなプロジェクトではすべての処理フローを生成しない場合があります。今回も852ノードすべてが解析されていないわけではなく、コードグラフを作った後に生成される「代表的な処理フロー」の一部が省略されていただけでした。

--embeddings 0を指定すると5万ノードのEmbedding上限を解除できますが、これは実行フロー側の制限とは別物です。このあたりは少し分かりにくいところでした。

GitNexusを入れるとClaude Codeは賢くなるのか

ここが一番気になっていたところです。GitNexusを使う前から、私はClaude Codeにかなりの量のプログラム修正やデバッグをさせています。GitNexusを入れれば、

  • 「今までより明らかにバグを見つけるようになる」
  • 「複雑な修正でもミスが減る」

という変化があるのか試してみました。

実際、GitNexusを入れた状態では、Claude Codeが修正前に影響範囲を調べることができます。たとえば、「この関数を変更するとどこが壊れる可能性があるか」という調査を、grepや全文検索だけではなく、GitNexusのグラフを使って確認できます。この点は確かに便利です。

ただ、普段からClaude Codeを使っている人であれば、Claude自身もファイルを検索しながらかなり丁寧にコードを追ってくれます。そのため、使ってみた感覚としては、「GitNexusを入れたらClaude Codeが別物になった」というほどではありませんでした。どちらかというと、Claude Codeが既存コードを調査する時の補助資料が増えた、という印象です。

GitNexusでバグを探させてみた

せっかくなので、実際にGitNexusの解析結果を使って、プロジェクト内の不具合を探させてみました。今回使ったシステムはまだ完全に完成しているわけではなく、実際に人間が操作すると「ここはちょっとおかしいな」と感じる部分も残っています。

まずGitNexusの構造チェックを実行し、その後PDGも追加しました。PDGは、簡単に言えばプログラム内でデータがどこからどこへ流れているのかを追跡するための情報です。Claude CodeにはGitNexusのtaint分析を使って、

  • コードインジェクション
  • パストラバーサル
  • SQLインジェクション
  • XSS

などの危険なデータフローがないか調べてもらいました。結果は0件でした。

もちろん「0件だから絶対安全」という意味ではありません。GitNexus自身にも、closureやコールバック内部、DOM操作など、完全には追跡できないケースがあります。そこでClaude Codeが追加で実コードを確認しました。

実例: innerHTMLを使っている箇所やSQL周りなどを調べた結果、1か所だけ気になる実装が見つかりました。サーバー側で、ユーザーが入力したIPアドレスをそのままエラーメッセージに含めてJSONで返している部分です。ただし、呼び出し側ではその文字列をinnerHTMLではなくtextContentで表示していたため、現在の実装ではXSSにはなりません。つまり「今は実害がないけれど、将来表示側の実装が変わると少し危ない」という非常に軽微な問題でした。

今回の結果だけを見ると、GitNexusを入れたことで今まで見つけられなかった重大なバグが発見できた、ということはありませんでした。GitNexusの解析を手掛かりにしてClaude Codeが追加調査を行い、軽微な問題を1件見つけた、という程度です。

人間が操作して分かる不具合は当然見つからない

今回使ったシステムには、実際にユーザーとして操作すると違和感を覚える部分がまだあります。プログラムとしては正常に動いていても、

  • 「この画面遷移はちょっと変だな」
  • 「ここでこの操作をすると使いにくい」
  • 「仕様上は間違っていないけれど、実際の業務では困る」

というタイプの不具合です。こうしたものはGitNexusでは見つけられません。GitNexusが解析しているのは、あくまでコードの構造や呼び出し関係、データフローです。ユーザーがシステムを操作した時にどう感じるかまでは分かりません。このタイプの問題を見つけるには、実際に人間が操作するか、Playwrightなどを使ってE2Eテストを行う方が向いています。

Wiki生成機能はかなり良かった

今回試した中で、個人的に一番良かったのはWiki生成機能です。GitNexusで解析したプロジェクトから、システム全体のWikiを自動生成できます。

生成されたWikiを見てみると、単にファイル一覧を並べただけではありませんでした。システムの目的や主要な機能、各モジュールの役割、処理の流れなどが文章としてまとめられています。今回のシステムでは、厚生労働省のストレスチェック制度に関する仕様まで理解した上で、各機能をかなり自然に説明していました。

これなら、開発者が久しぶりに自分のプロジェクトを触る時にも便利です。他の人に引き継ぐ場合も、「まずこのWikiを読んでください」と言えるレベルの資料になります。個人的には、Claude CodeとのMCP連携よりも、こちらの方がGitNexusの良さを分かりやすく感じました。

Wikiはどうやって生成しているのか

Wiki生成にはLLMが使われています。今回の実行ログを見ると、

Spawning: cmd.exe /c claude -p --output-format text --no-session-persistence
Model: default

となっていました。つまり、Anthropic APIを別途契約して使っているわけではなく、PCに入っているClaude Code CLIをGitNexusが呼び出していました。今回のWiki生成では、claude -pが16回ほど実行されています。

重要: 「GitNexusのWiki生成は完全無料」と書くと少し違います。別途Anthropic APIの料金が発生しているわけではありませんが、Claude Codeの利用枠は消費しています。Claude Codeの契約内で使っているので、追加のAPIキーやAPI課金が不要だった、という表現が正確です。これはClaude Codeを普段から使っている人には結構うれしいところだと思います。

一番気になったのは解析結果が古くなること

GitNexusを使っていて、少し怖いと思ったのがここです。GitNexusは一度解析すると、その時点のコード構造を.gitnexusに保存します。当然、その後コードを変更すると、GitNexusの解析結果と実際のソースコードに差が出てきます。

警告: そのままClaude Codeが古いグラフを参照すると、「この関数を呼んでいるのはこの3か所です」とGitNexus上では表示されているのに、実際には新しく4か所目が追加されている、という状態も起こり得ます。影響範囲調査をするために入れたツールなのに、解析結果が古ければ、その情報自体がバグの原因になる可能性があります。

GitNexusにはインデックスが古くなったことを検知して再解析を促す仕組みがありますが、基本的には自分で再度、npx gitnexus analyzeを実行する必要があります。今回のプロジェクトでは解析に約3分かかりました。開発初期で毎日のようにファイル構成や処理が変わっている状態だと、これを何度もやるのは少し面倒です。

アンインストールしてもCLAUDE.mdの記述は自動で消えない

もう一つ気になったのが、GitNexusを一度使うと、CLAUDE.md や AGENTS.md にGitNexus用の指示が自動で追加される点です。npx gitnexus analyzeを実行すると、<!-- gitnexus:start -->から<!-- gitnexus:end -->というマーカーで囲まれたセクションが追記され、その中に「編集前にimpact分析を行う」「コミット前にdetect_changesで確認する」といった、Claude CodeにGitNexusを使わせるための指示が書き込まれます。

ここで少し面倒なのが、GitNexusをやめた時の後始末です。普通なら、

  • .gitnexus フォルダを削除する
  • gitnexus clean でインデックスを消す
  • gitnexus uninstall でMCP設定を削除する

あたりを実行すれば元に戻りそうに思います。

警告: ところが、これらを実行しても、CLAUDE.md や AGENTS.md に追加されたGitNexus用のセクションは自動では削除されません。そのため、GitNexus本体やMCP設定を消したあとでも、CLAUDE.md 側には「GitNexusを使う」という指示だけが残る状態になります。Claude Codeはプロジェクト内のCLAUDE.mdを参照して動くので、GitNexusを削除したあとも、存在しないGitNexusツールを前提に判断しようとする可能性があります。

完全に元に戻したい場合は、<!-- gitnexus:start -->から<!-- gitnexus:end -->までのブロックを、自分で削除する必要があります。analyze --skip-agents-mdを付ければ、今後CLAUDE.mdやAGENTS.mdへのGitNexus用セクションの更新を止めることはできます。ただし、すでに書き込まれている内容まで削除してくれるわけではありません。「少し試してみよう」くらいのつもりで導入しても、やめる時にはリポジトリ内の設定ファイルを手動で戻す必要がある、という点は覚えておいた方がよさそうです。

完成に近いプロジェクトの方が向いているかもしれない

実際に使ってみて、GitNexusは開発初期から入れるより、ある程度完成したプロジェクトに入れる方が使いやすい気がしました。開発初期は、ファイルが増える、関数が増える、設計が変わる、画面構成も変わる、ということが頻繁に起きます。GitNexusの解析結果もすぐ古くなります。そのたびに再解析しないといけません。

一方で、ある程度完成して大きな変更が少なくなったシステムなら、一度解析しておけば長く使えます。Wikiを作っておけば、数か月後に自分がもう一度触る時にも役立ちます。大規模な修正をする時だけ再解析して、Claude Codeに影響範囲を確認させる、という使い方もできます。この使い方ならGitNexusのメリットの方が大きそうです。

最初は、「GitNexusをClaude Codeに入れたら、もっとバグを見つけられるようになるのでは」と期待していました。今回試した範囲では、そこまで劇的な変化は感じませんでした。GitNexusなしでもClaude Codeはかなりコードを読んでくれます。普段からClaude Codeにデバッグや修正を任せている人であれば、GitNexusを入れたから急に修正品質が何段階も上がる、というものではなさそうです。

一方で、プロジェクト全体の構造を解析する、関数やファイルの関係を見る、変更時の影響範囲を調べる、既存システムからWikiを作る、といった用途では便利です。特にWikiは、コードを開発者向けの資料に変換してくれるという点で分かりやすい価値がありました。GitNexusはバグ検出ツールというより、コードの地図を作るツールだと思っておいた方が期待値としては合っていそうです。

しばらく使ってみるけれど、常用するかはまだ分からない

GitNexusを試す前は、Claude Codeのコード理解能力をかなり強化してくれるツールなのではと思っていました。実際に使ってみると、そこまで単純ではありませんでした。

Claude Codeの調査を補助してくれるのは確かですが、GitNexusなしでもClaude Codeはかなり優秀です。しかもGitNexusの解析結果を最新に保つという運用が増えます。更新を忘れると、古い解析結果をClaude Codeに見せることになるため、場合によっては逆効果になる可能性もあります。

現時点では、開発中のすべてのプロジェクトへ必ず入れたい、とは思っていません。ただ、ある程度完成したプロジェクトを整理したい場合や、大きな既存システムを引き継いだ場合にはかなり役立ちそうです。特にWiki生成は気に入りました。

今後しばらく実際の開発でも使ってみて、GitNexusあり・なしでClaude Codeの調査時間や修正精度にどの程度差が出るのか、もう少し見てみようと思います。ちなみにWrangler auth profileのように、地味だけど後から効いてくる系のツール設定は他にもいくつか試しています。用途に応じたAIツールの使い分けについても、今回のGitNexusのように実際に試してから判断するようにしています。