コードレビューグラフの使用方法: Codex と Claude Code に PR 影響分析を追加する

code-review-graph は、AI コードレビュー中にウェアハウス全体を繰り返し読み取る問題を軽減することを目的としたローカルファーストコードナレッジグラフツールです。 Tree-sitter を使用して関数、クラス、インポート、呼び出し、継承、関係を解析し、結果をプロジェクト内の SQLite データベースに保存し、MCP、CLI、スキル、フックを介して Codex、Claude Code、Cursor などの AI プログラミングツールに提供します。

これは、大規模なリポジトリ、モノリポジトリ、ファイル間 PR に特に適しています。関数が変更されると、グラフは呼び出しと依存関係に沿った影響範囲を計算し、どの呼び出し元、テスト、実行フローが検査に値するかを AI に伝えることができます。

簡単な結論

Python 3.10 以降が必要です。
インストール後にcode-review-graph installを実行します。このツールは、インストールされている AI プログラミングプラットフォームを検出し、対応する MCP 構成を書き込みます。
code-review-graph build を初めて実行します。その後、update、watch、またはプラットフォームフックを使用して、マップを段階的に保守できます。
データはデフォルトでプロジェクトの .code-review-graph/ に保存され、コアの構成とクエリではソースコードを外部サービスに送信する必要はありません。
単純な単一ファイルの変更では、必ずしもトークンが保存されるわけではありません。ファイル間の呼び出し、テストの影響、および大規模なウェアハウスのレビューは、マップの価値をより適切に反映できます。

コードレビューグラフをインストールする

プロジェクトの依存関係の汚染を避けるために、独立した Python ツール環境を使用することをお勧めします。

1

pipx install code-review-graph

pip を直接使用することもできます。

1

pip install code-review-graph

分析する必要がある Git リポジトリに入ったら、次を実行します。

1
2
3


code-review-graph install
code-review-graph build
code-review-graph status

install は、Codex、Claude Code、Cursor、Windsurf、Zed、Continue、OpenCode、Gemini CLI、GitHub Copilot などのサポートされているプラットフォームを検出し、適切な MCP 構成とプラットフォームルールを生成します。完了後、エディタまたはAIプログラミングツールを再起動する必要があります。

1 つのプラットフォームのみを構成する場合は、名前を指定できます。

1
2
3
4


code-review-graph install --platform codex
code-review-graph install --platform claude-code
code-review-graph install --platform cursor
code-review-graph install --platform gemini-cli

uvx、pip、または pipx を使用してインストールする場合、install は実際のエントリを識別し、対応する構成を生成するために最善を尽くします。 MCP の起動に失敗した場合は、まずターミナルで直接実行できることを確認する必要があります。

1
2


code-review-graph --help
code-review-graph status

コードレビューのコンテキストをどのように絞り込むか

合成プロセスは次のように簡略化できます。

1

代码仓库 -> Tree-sitter AST -> SQLite 图谱 -> 影响半径 -> 最小审查文件集

グラフ内のノードには関数、クラス、ファイル、インポートが含まれ、エッジは呼び出し、継承、テストカバレッジなどの関係を表します。 PR がファイルを変更した後、ツールは以下を検索します。

どの関数とクラスが直接変更されるか。
どの呼び出し元または依存関係が影響を受ける可能性があるか。
どの実行フローがこれらのノードを通過するか。
対応するテストがあるかどうか、およびテスト範囲にギャップがあるかどうか。
AI レビューのために読む価値のあるファイルはどれですか。

こうすることで、AI はファイル名検索のみに依存する必要がなく、デフォルトでリポジトリ全体をスキャンする必要もありません。これにより、モジュール間の呼び出しや不慣れなコードベースの場合、単にモデルに PR diff をスローするよりも間接的な影響を特定しやすくなります。

一般的なコードナレッジグラフとアーキテクチャ分析について学びたい場合は、[CodeGraph ローカルコードナレッジグラフチュートリアル] (/ja/2026/05/23/codegraph-local-code-knowledge-graph-ai-coding-agent/) と [Graphify のクロードコードグラフワークフロー] (/ja/2026/05/21/safishamsi-graphify-ai-code-knowledge-graph/) を比較できます。 code-review-graph は、変更の影響、リスクスコアリング、PR レビューに重点を置いています。

コーデックスまたはクロードコードで使用される

インストールと構成が完了したら、AI アシスタントにタスクを直接依頼できます。

1

Build the code review graph for this project

このプロジェクトでは、よく使用される 3 つのスラッシュコマンドも提供します。

1
2
3


/code-review-graph:build-graph
/code-review-graph:review-delta
/code-review-graph:review-pr

実際のレビュープロセスは次のとおりです。

ウェアハウスのルートディレクトリで code-review-graph status が正常であることを確認します。
コードを変更するか、レビューするブランチに切り替えます。
code-review-graph update を実行して、変更された部分を更新します。
Codex または Claude Code で review-delta または review-pr を実行します。
まず影響範囲、リスク関数、テストギャップを調べ、AI に必要なソースコードを読み取らせます。
最後に、グラフの結果をテストの置き換えとして使用するのではなく、プロジェクトの元のテストを実行します。

CLI には、対応する毎日のコマンドも用意されています。

1
2
3
4
5
6


code-review-graph build
code-review-graph update
code-review-graph status
code-review-graph watch
code-review-graph detect-changes
code-review-graph visualize

watch は継続的な開発に適しています。 detect-changes は現在の変更を分析するために使用されます。 visualize は、コードコミュニティ、ハブ、ブリッジ、例外結合を簡単に表示できるインタラクティブな HTML 図を生成します。

どの MCP ツールを最初に呼び出す必要がありますか?

このプロジェクトは、さまざまな MCP クエリツールを提供します。日常会話では完全なマップを一度に取得する必要はありません。最小限のコンテキストから始めることをお勧めします。

目的	提案ツール
まずはミニマリストの入り口を手に入れましょう	`get_minimal_context_tool`
変更の範囲を表示する	`get_impact_radius_tool`
レビューに必要なコンテキストを取得する	`get_review_context_tool`
クエリ呼び出し元、テスト、インポート、または継承	`query_graph_tool`
影響を受ける実行フローを表示する	`get_affected_flows_tool`
リスクとテストのギャップを確認する	`detect_changes_tool`
全体的なアーキテクチャを理解する	`get_architecture_overview_tool`

MCP ツールが表示されない場合は、[MCP ツール呼び出し失敗のトラブルシューティングガイド] (/ja/2026/07/08/mcp-tool-call-failure-troubleshooting-faq/) を参照して、設定ファイルの場所、コマンドが PATH にあるかどうか、作業ディレクトリとエディタが再起動されているかどうかを重点的に確認してください。

地図を最新の状態に保つ

最初の build の後は、毎回リポジトリ全体を再構築する必要はありません。増分更新は手動で行うことができます。

1

code-review-graph update

以下の監視を継続することもできます。

1

code-review-graph watch

サポートされているプラットフォームフックを有効にすると、ファイルの保存またはコミット時に増分更新をトリガーできます。公式 README に記載されている例では、変更された少数のファイルのみを再解析する場合、約 2,900 ファイルのプロジェクトを 2 秒で更新できますが、実際の時間はリポジトリのサイズ、言語、ディスク、後処理能力によって異なります。

ビルドファイル、ベンダー、または大きなディレクトリがすでに Git によって追跡されているが、グラフに入りたくない場合は、リポジトリのルートディレクトリに .code-review-graphignore を作成できます。

1
2
3
4


generated/**
*.generated.ts
vendor/**
node_modules/**

Git リポジトリでは、ツールはデフォルトでインデックス範囲として git ls-files を設定するため、Git によって追跡されず、.gitignore によって除外されたファイルには通常インデックスが作成されません。

GitHub に接続して PR リスクチェックを行うアクション

code-review-graph は GitHub Actions でも実行できます。公式の README の現在の例は次のとおりです。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17


name: Code Review Graph

on:
  pull_request:

permissions:
  contents: read
  pull-requests: write

jobs:
  review:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v7
      - uses: tirth8205/[email protected]
        with:
          github-token: ${{ secrets.GITHUB_TOKEN }}

アクションは CI ランナーでローカルに構成およびクエリを実行し、リスク関数、影響を受ける実行フロー、およびテストギャップを PR に書き込みます。正式に採用する前に、ウェアハウスの最新リリースまたは README を確認し、明確なバージョンを修正し、長期間古くなっている可能性のあるサンプルバージョンをコピーしないでください。

チームが結果を観察したいだけの場合は、最初にワークフローにコメントを付けることができます。誤検知率と速度が許容範囲内であることを確認した後、fail-on-risk をマージゲートとして有効にすることを検討できます。

トークン節約ベンチマークを正しく理解する方法

公式英語版 README の報告によると、6 つの実際のオープンソースリポジトリの問題ごとのテストでは、「コードコーパス全体を読み取る」というベースラインと比較して、トークン削減の中央値は約 82 倍、範囲は約 38 ～ 528 倍でした。 528 回という数字は、単一の最良のサンプルから得られたものであり、通常のプロジェクトでは達成できる結果ではありません。

これらの数字を読む際の注意点:

ウェアハウスの完全な読み取りは理想的な上限です。成熟したエージェントは、まず少数のファイルを検索し、次に読み取ります。
単一ファイルの小規模な変更の場合、グラフによって返されるエッジ、影響範囲、および構造の概要は、差分を直接読み取るよりも大きくなる可能性があります。
分析に影響を与えるリコールベンチマークの中には、同じグラフから得られたグラウンドトゥルースを使用するものがありますが、これは循環性があり、上限とみなされる必要があります。
検索の並べ替え、JavaScript、Go の実行フロー検出にはまだ改善の余地があることがわかっています。
グラフは、依存関係が欠落するリスクを軽減するために、影響を受ける可能性のある一部のファイルを過剰に報告する傾向があります。

したがって、チームのコスト予算に「最大 528 倍」と記入しないでください。より信頼性の高い方法は、独自のリポジトリ内の PR の同じバッチを比較することです。AI によって実際に読み取られたファイルの数、コンテキストの長さ、誤検知、誤検知、およびレビュー時間を記録します。

一般的な問題のトラブルシューティング

AI はインストール後に MCP ツールを認識できません

最初のチェック:

1
2


code-review-graph --help
code-review-graph status

次に、指定したプラットフォームのインストールを再実行し、ツールを再起動します。

1

code-review-graph install --platform codex

仮想環境を使用してインストールした場合、AI ツールの起動時に同じ Python 環境が見つからない可能性があります。通常、グローバル CLI エントリポイントとしては、pipx または uvx の方が適しています。

グラフの結果には新しいコードは含まれていません

最初の実行:

1
2


code-review-graph update
code-review-graph status

また、新しいファイルが Git によって追跡されており、.gitignore または .code-review-graphignore によって除外されていないことも確認します。必要に応じて、完全な build を実行します。

小規模な PR にはより多くのコンテキストが含まれます

これは、グラフ構造のメタデータによって生じる固定オーバーヘッドです。 1 行のみ変更し、依存関係がない変更の場合は、diff を直接読み取る方が高速です。 AI に最初に get_minimal_context_tool を呼び出しさせ、ファイル間の影響が見つかった場合にのみ完全なレビューコンテキストを展開させることができます。

安全にアンインストールする方法

最初に削除するコンテンツをプレビューします。

1

code-review-graph uninstall --dry-run

確認後に実行します。

1

code-review-graph uninstall

統合を削除するだけでプロットデータは保持したい場合は、次を使用します。

1

code-review-graph uninstall --keep-data

どのプロジェクトが適しているか

より適したもの:

ファイル間呼び出しが多数ある大規模なコードベース。
モノレポ、多言語ウェアハウス、複数人によるコラボレーションプロジェクト。
Codex、Claude Code、または Cursor を頻繁に使用して PR を確認します。
呼び出し元を追跡し、ギャップと実行フローをテストする必要がある。
コアコードグラフが外部クラウドデータベースに依存しないようにします。

必ずしも次のことを行う必要はありません。

少数のファイルのみを含む小規模なプロジェクト。
主にドキュメントまたは構成の変更をレビューします。
各変更は単一の独立したファイルに制限されます。
チームにはインデックスを維持し、誤検知に対処する意欲がありません。

概要

code-review-graph AI コードレビューに、継続的に更新される構造インデックスのレイヤーを追加します。これは、Codex や Claude Code などのツールが、「関連性があると思われるファイルの検索」から「呼び出し、依存関係、およびテストの関係に沿った変更の影響の分析」に移行するのに役立ちます。

実際に使用するには、一般的な PR から始めます。つまり、インストール、フレーム化、増分レビューの実行を行い、その結果を手動レビューと実際のテストと比較します。ファイル間の影響を確実に特定し、無関係な読み取りを減らすことができる場合は、最初にすべてを有効にするよりも、ウォッチ、フック、または GitHub アクションをプラグインした方がメリットを評価しやすくなります。

プロジェクトアドレス: tirth8205/code-review-graph