Claude Code 在大規模プロジェクトには長年の問題がある：ファイルツリーのスキャン、ファイル内容の読み取り、コード参照の検索を何度も繰り返す。会話ごとに token が水道水の如く流れていく。
Codegraph の思路は直接的——プロジェクト構造を事前に知識グラフとして構築し、ローカルに保存しておき、Claude は毎回読み直すのではなく直接クエリする。
コア思路
従来の Claude Code ワークフロー：
- 質問を受け取る
- ディレクトリ構造を読む
- ディレクトリに基づいてどのファイルを読むか決定
- 特定のシンボル参照を検索
- 繰り返し迭代
Codegraph はこれをこう変える：
- プロジェクト初期化時にインデックスを構築（一度だけ）
- Claude がグラフを直接クエリ、ファイル関係とシンボル参照を取得
- 繰り返しスキャンと検索をスキップ
最近のコミットが面白い：「refactor: Remove semantic search and vector embedding functionality」。著者はセマンティック検索とベクトル埋め込みを削除し、純粋な構造化知識グラフへ移行した。この選択は検討に値する。
セマンティック検索は聞こえはいいが、コードシナリオでは実際的ではない。コードの関係は決定的だ——関数 A が関数 B を呼び出す、クラス C がクラス D を継承する。これらの関係に「セマンティック類似度」で判断する必要はない——グラフを直接クエリすればいい。ベクトル検索を削除することで、複雑さとメンテナンスコストを削減し、token 消費も下げた。
実測データ
プロジェクトドキュメントの主な收益：
- より少ない token：モデルにファイル内容を繰り返し送信する必要なし
- より少ないツール呼び出し：グラフクエリで一度到位、多ラウンド検索不要
- 100% ローカル：すべてのインデックスデータはローカルに保存、外部サービス不使用
256 回のコミット、18 時間前も更新あり。最近 Rust resolver の workspace crate resolution サポートを追加中、言語カバレッジの拡大を示す。現在サポートされている言語は一つ以上（CLAUDE.md に Svelte language support が言及されている）。
適用シナリオ
特に適す：
- 大規模コードベース（数千ファイル以上）
- Claude Code で頻繁にクロスファイル分析が必要なシナリオ
- API 呼び出しコストに敏感なチーム
あまり必要ない：
- 小規模プロジェクト（数十〜数百ファイル——Claude Code ネイティブのツール呼び出しで十分速い）
- プロジェクト構造が極端に頻繁に変化するシナリオ（インデックス再構築が必要）
他方案との比較
Cline にも独自のコンテキスト管理メカニズムがあるが、それは汎用的で、コード構造に特化した最適化はない。Codegraph の差別化はここにある——一つのことだけやる：コード構造をグラフに変え、Agent のクエリを速くする。
この思路は正しいか？大方向は問題ないと思う。コード理解の核心は関係を理解すること、「セマンティクス」を理解することではない。知識グラフは関係の表現に天然的に適している——汎用テキストよりコードシナリオでの使用の方が合理的だ。
1300 以上の star、11 件の open issues、29 件の PR。プロジェクトは活発な開発期にあるが、安定リリース段階にはまだ至っていない。使いたいなら、まず小規模プロジェクトで試してみるのがいい。
主要ソース：