code-review-graph

現時点の証拠から見ると、code-review-graph は「技術チームが試す価値のある AI 向け文脈圧縮レイヤー」と判断するのが妥当で、すでに広く実証済みの成熟したコードレビュープラットフォームとは言いにくいです。注目度の証拠は GitHub Trending 系の言及や X 上の複数の転載投稿が中心で、強い関心を示しています。一方、使い勝手を支える証拠は公式 GitHub リポジトリ、少数の Zhihu チュートリアル、実演投稿が中心で、サンプルはまだ限られます。したがって、大規模リポジトリ、PR レビュー、AI 補助読解には有望だが、効果は各チームの実コードで検証すべき、というのが慎重な評価です。

実際の役割は、人間のコードレビューを自動で置き換えることでも、SAST や SonarQube、従来型の品質管理ダッシュボードになることでもありません。より正確には、Claude Code のような AI コーディング支援のための「リポジトリ単位の検索・依存関係剪定レイヤー」です。証拠では、Tree-sitter を使ってローカルに永続的なコードグラフを作り、変更や質問に本当に関係するファイルだけを絞り込む仕組みが示されています。X 投稿やリポジトリ説明には 30 以上の言語対応、約 2,900 ファイル規模の高速インデックス、blast radius 分析もありますが、これらは主にワークフローや実演能力の説明であり、本番での安定成果を保証するものではありません。

導入ハードルとコストについては、「オープンソース、ローカル実行、pip で導入、開発者が自前で組み込む前提」という理解が証拠に最も合います。公式価格、ホスト型サービス料金、API 従量課金は提示証拠内で確認できないため、確定情報として書くべきではありません。token 削減については、Zhihu 記事で 208,821 行相当を約 2,495 tokens に圧縮し、約 82 倍から 93 倍削減したというコミュニティ実演がありますが、これはあくまで実演や限定的な実測です。どのリポジトリでも同じ結果になる保証とは見なせません。実際のコストと効果は、コード構造、使うモデル、MCP/CLI の流れ、グラフ更新頻度に左右されます。

向いているのは、Claude Code や近い AI コーディングツールを中〜大規模リポジトリで日常的に使い、無関係な文脈を減らしたい開発者やプラットフォームチームです。向いていないのは、Web 完結のワンクリック製品、監査・準拠レポート、設定なしで全ロジック不具合を自動発見する体験を求める組織です。SNS 上の共通認識は「token 節約」「文脈汚染の削減」「大規模リポジトリ向き」に集中しています。