AIが書いたコード，レビューが追いつかない人へ．差分の理解を助けるツールまとめ

はじめに

中部大学 機械知能研究室（研究室HP）に所属し，コンピュータビジョン（CV）分野の研究をしている者です．

最近は生成AIの発展により，実装をAIに任せることが増えました．生成AIに指示を出すとコードが一瞬で生成され，次々とプルリクエスト（PR）が立てられるようになります．一方で，その差分が意図どおりかを確かめるのは人間であるため，レビューが追いつかなくなってきました．

そこで今回は，AIが書いた差分を人間が理解するのを助けるツールを，課題とあわせて紹介します．

後半では，AIが書いた同じプルリクエスト（PR）を3つのツールで実際に読み，次の3点を確かめた結果も紹介します．

• 全体像をつかめるか
• 変更の範囲が分かるか
• 仕様の抜けに気づけるか

1. AIに実装を任せると，何が課題になるのか

数字で見る現状

Sonarが2026年1月に公開した開発者調査（回答者1,100人以上）から，2つの数字を紹介します[1]．

• コミットされるコードの42%を，AIが書いている
• 38%の開発者が，AIのコードのレビューは同僚のコードより手間がかかると答えている

書く作業はAIが肩代わりしてくれます．その分，確かめる作業が人間に集まっています．

AIのコードがレビューしにくい4つの理由

私は，AIが書いた差分には次の4つの読みにくさがあると考えています．（）内は，後半で試したPRで実際に見られた例です．

1. 量が多く，速い
   差分がまとめて返ってくるので，1行ずつ読む時間が取れません．（指示は4行でしたが，返ってきたのは6ファイル，+119行の差分でした）
2. 重要な数行が，機械的な変更に埋もれる
   同じ形の変更が並ぶと，本当に考えるべき箇所が目立ちません．（119行の大半はCLIのオプション追加と文書で，中心は18行の関数だけでした）
3. 前提が差分に残らない
   AIは指示を満たすコードを書きますが，「何を前提にしたか」は書かれません．書かれていても，正しいかは確かめられていません．（「モデルの出力はメートル」という前提は，実際には一部のモデルにしか当てはまりませんでした）
4. 説明が自信を持って書かれている
   コミットメッセージやPRの説明は，言い切りの形で書かれます．読む側は，それを信じたくなります．（「書き出すファイルも同じ単位になる」と書かれていましたが，一部の出力形式では成り立ちませんでした）

人間がレビューで確かめたいこと

こうした差分を前にして，人間がまず知りたいことは次の3つです．

確かめたいこと	関係する理由
何のための変更で，全体はどうなっているか	1（量が多い）
どこに時間を使えばよいか	2（埋もれる）
前提は正しいか．仕様の抜けはないか	3（前提が残らない），4（説明を信じてしまう）

この3つを，人間が全部の行を読まずに確かめられるようにしたい．それが，レビュー支援ツールに期待する役割です．

2. なぜ生成AIに直接聞かず，ツールを使うのか

差分をそのままチャット形式の生成AIに貼り，「説明して」と頼む方法もあります．手軽ですが，上の課題を考えると足りない点があります．

なお，この記事で紹介するツールの多くも，中身は生成AIです．違うのは，AIに「どう読ませるか」と「結果をどう見せるか」です．

	チャットに差分を貼る	レビュー支援ツール
読ませ方	聞き方しだい．前提を疑うかどうかも聞き方による	読む手順が決まっている（例：主張を「確かめる対象」として読む）
根拠	どこまでがコードで確かめたことか，自分で見直す必要がある	行番号の検証や，根拠の強さのラベルが付くものがある
結果の形	毎回変わる	決まった形で出る．AIを使わない図なら毎回同じ
共有	自分の画面の中だけ	PRに付けば，チーム全員が同じものを見られる

特に大きいのは，実装したAIに聞いても，同じ前提で読んでしまうことです．後半で試したPRでは，実装したClaude Codeは，PRの説明で相対深度のモデルに触れていませんでした．一方，ツアー型のツール（diff-tour）にツアーを書かせたところ，書き手は同じClaude Codeなのに，その抜けを指摘しました．今回の結果を見る限り，差を生んだのはモデルではなく，読ませ方だと考えています．

ただし，チャット形式のAIに直接聞く方法とは，実際には比べていません．ここに書いたのは，今回の結果とツールの仕組みから考えた理由です．

3. レビューを助けるツールの紹介

差分の理解を助けるツールを，4つに分類しました．

分類	対象	何をするか	主に効く課題	ツールの例
PR差分型	PRの差分	PRに要約や図，指摘をコメントする	全体像，時間を使う場所	CodeRabbit，Greptile，PR-Agent
ツアー型	PRの差分	差分を読む順番に沿って解説する	時間を使う場所，前提と仕様の抜け	diff-tour
リポジトリ全体型	リポジトリ全体	Wikiや構成図を作る	変更の前提となる全体の構造	DeepWiki，Google Code Wiki，GitDiagram
静的解析型	関数・ファイル	AIを使わずに，構文から図を作る	特定の関数の構造の確認	CodeVisualizer

次に各カテゴリごとに詳しくみていきます．なお，費用はすべて2026年10月時点のものです．★は，後半で実際に試したツールです．

3.1 PR差分型：PRを開くと要約が付いている

PRに自動で要約や図，指摘を投稿するタイプです．PRを開いた時点で全体像が分かるので，レビューの入口として使いやすいです．一方，PRの差分を中心に見るので，差分の外にある前提までは確かめないことがあります．

★CodeRabbit

• 何をするか：PRにAIのレビューを自動で投稿します．変更の要約（Walkthrough），シーケンス図，マージのリスク，マージ前のチェックなどが付きます．
• 仕組み：GitHubなどにCodeRabbitのアプリ（GitHub App）を導入すると，PRごとにレビューが投稿されます．
• 費用：今回は，14日間の試用期間中にAdvancedプランで使いました（支払いはなし）．試用期間のあとも使う場合，Advancedプランを月払いにすると月額90ドル／ユーザーです（管理画面の見積もり）．料金ページの表示額は月額72ドル／ユーザーでした．公開リポジトリは無料です[2]．

Greptile

• 何をするか：AIがPRをレビューします．レビューの深さを3段階から選べます．
• 費用：Starterは無料（1人まで），Proは月額30ドル／シートです．

PR-Agent

• 何をするか：/describe（説明），/review（レビュー），/improve（改善案）などのコマンドで，PRを説明・レビューします．
• 費用：オープンソース（MITライセンス）です．使うLLMの費用は別にかかります．

3.2 ツアー型：差分を「読む順番」に沿って解説する

差分を，ベテランが読む順番に沿って1ステップずつ解説するタイプです．どこに時間を使うかを示し，前提を問いの形で確かめていくので，仕様の抜けに気づきやすくなります．代わりに，作るのにも読むのにも時間がかかります．

★diff-tour

• 何をするか：gitの差分を「ツアー」にして，ターミナルで1ステップずつ読ませます[3]．答えの前に問いを出すステップもあります．
• 仕組み：手元のLLMのCLI（Claude Code，Codex CLI，Gemini CLIなど）が，読み取り専用の権限でツアーを書きます．ツールは，ツアーが参照するファイルと行番号を検証し，画面のコードはgitから読み込みます．各説明には「確かめた」「読み取れる」「シニアの見方」のラベルが付き，根拠の強さが分かります[3]．
• 費用：ツール自体はMITライセンスで無料です．ツアーの作成には，自分のLLMの利用枠を使います[3]．

3.3 リポジトリ全体型：変更の前提になる全体像をつかむ

リポジトリ全体のWikiや構成図を作るタイプです．PRの差分は扱いませんが，初めて触るリポジトリで「この変更はどこに効くのか」を考える土台になります．

DeepWiki

• 何をするか：リポジトリ全体のWikiとアーキテクチャ図を自動で作ります．
• 費用：公開リポジトリは無料です．非公開リポジトリには，Devinのアカウントが必要です．
• 今回は，非公開リポジトリではDevinへの登録が必要で，インデックスの作成にも時間がかかるため，試していません．

Google Code Wiki

• 何をするか：Geminiでリポジトリの文書と図を作り，コードの変更に合わせて更新します．Wikiを使って質問に答えるチャットも付きます．
• 費用：公開プレビュー中で，公開リポジトリが対象です．

GitDiagram

• 何をするか：GitHubのURLの hub を diagram に変えるだけで，リポジトリの構成図ができます．
• 費用：無料です（MITライセンス）．GitHubのトークンを渡せば，非公開リポジトリにも使えます．

3.4 静的解析型：AIを使わずに，構造を正確に見る

構文を解析して図を作るタイプです．AIを使わないので，図はコードの事実として正確で，毎回同じ結果になります．ただし，その値が何を意味するか，仕様として正しいかは分かりません．

★CodeVisualizer

• 何をするか：VS Codeの拡張です．関数のフローチャートと，ファイル間の依存関係のグラフを作ります[4]．
• 仕組み：Tree-sitterで構文を解析し，図にします．解析は手元で行い，コードを外部に送りません．AIでラベルを付ける機能もありますが，既定ではオフです[4]．
• 費用：無料です（MITライセンス）[4]．

4. 同じPRで試してみた

ここからは，★の3つのツールで，AIが書いた同じPRを読んだ結果を紹介します．

題材

Depth Anything 3 に，推論結果の距離の単位（m／mm）を切り替える機能を，Claude Codeで追加しました．指示文は次のとおりです（全文）．

mainから feature/unit-switch ブランチを作成し、次の機能を実装してください。

推論結果の距離の単位を、メートルとミリメートルから選べるようにしてください。
APIとCLIの両方から指定できるようにしてください。

実装が終わったら、コミットしてpushし、mainへのPRを作成してください。

できたPRは，1コミット，6ファイル（api.py，cli.py，services/backend.py，services/inference_service.py，docs/API.md，docs/CLI.md），+119 −2 でした．

PRのブランチで，unit=m と unit=mm の両方で推論しました．どちらもエラーなく，npzとglbを出力できました．mmの深度は，mのおよそ1000倍（最大値で 56.4892 → 56492.3）でした．指示どおりには動いています．

私が意図していた仕様は次のとおりです．この仕様はAIには見せていません．

分類	項目
変える値	深度（depth），カメラの並進
変えない値	内部パラメータ，回転
見落としやすい箇所	gs出力での scale_factor による割り戻しとの整合
見落としやすい箇所	相対深度のモデルでmmを指定したときの警告
見落としやすい箇所	npzに単位の情報を保存すること

実行環境は，GPUがRTX 4090，モデルはDA3NESTED-GIANT-LARGE-1.1です．評価は◎・○・△・×の4段階で，私1人がつけました（5章）．

ライセンス：Depth Anything 3 のコードは Apache 2.0 です．モデル DA3NESTED-GIANT-LARGE-1.1 は CC BY-NC 4.0 です（リポジトリのREADMEのモデル一覧で確認）．

4.1 CodeRabbit

リポジトリにCodeRabbitを導入し，初期設定（Review profile: CHILL）のまま使いました．

• Walkthroughは，変更を「変換（api.py）」「伝達（inference_service.py，backend.py）」「CLIとドキュメント」の3層に分けて表で説明していました．6ファイルの役割がすぐに分かります．レビューの手間の目安は3/5（Moderate），約20分でした．
• 説明の内容は正確でした．「深度とカメラの並進を変換」「ガウシアンは scale_factor を更新」は，意図した仕様と一致します．
• 一方で，シーケンス図は distance_unit の受け渡しの流れだけでした．どこで何を変換するかは描かれていません．変えない値にも触れていませんでした．
• 指摘コメントは0件，Merge Riskは「Minimal」でした．Pre-merge checksは5件すべてに通過の印が付いていました．ただし，実際に判定したのは Title check と Docstring Coverage の2件だけです．残りの3件（Description Check，Linked Issues check，Out of Scope Changes check）は，スキップされても通過の印が付いていました．
• 元のリポジトリにあったCLIの不具合（未定義の変数 reference_view_strategy で落ちる）は，「このPRが原因ではない」と正しく区別していました．

4.2 diff-tour

v0.5.0（Linux）を1行のコマンドでインストールしました．ツアーを作るのに専用のコマンドはありません．リポジトリで tour を実行すると変更の一覧が出るので，feature/unit-switch を選ぶだけです[3]．初回だけ，表示する言語とツアーを書くLLMを選びます．今回の書き手はClaude Code（Proプランの利用枠）です．

ツアーは17ステップ（6章）で，作成に約9分かかりました．READMEの目安（2〜5分）より長めです．費用はAPI価格に換算して約2.21ドルでした（Proプランの枠内なので請求はなし）．

ツアーは，コミットメッセージを「確かめる対象」として扱うところから始まります．

次に，6ファイルを「中心（api.py）」「機械的（cli.py など）」「文書」に分け，時間を使う場所を示します．4ステップ目は値が流れる順の図で，CodeRabbitのシーケンス図と違い，「どこで変換するか」まで描かれていました．

問い1：gs_videoでカメラとガウシアンはずれないか（6・7ステップ目）

nestedのモデルでmmを選ぶと，カメラの並進と scale_factor は1000倍されますが，ガウシアンは元のままです．6ステップ目は，これでカメラとガウシアンがずれないかを問うだけのステップです．

7ステップ目の答えは「ずれない」でした．ツアーは差分の外の da3.py と gs.py を読み，gs_videoが「並進÷scale_factor」でガウシアンの空間に戻していることを示します．分子と分母を同じく1000倍するので，関係は崩れません．これを数値の表で確かめていました．

問い2：APIの既定のモデルでmmを指定すると（10・11ステップ目）

10ステップ目の問いは，APIの既定のモデル（da3-large）で distance_unit="mm" を指定したとき，深度はミリメートルになるか，です．

11ステップ目の答えは「ミリメートルではない」でした．ツアーは差分の外のREADMEとモデルのコードを読み，メートルを返すのはnestedのモデルだけだと示します．変換の関数は，この区別を見ずに1000倍します．その結果，da3-large では単位のない相対値の1000倍が，警告もなく「mm」として書き出されます．ツアーはこれを必須の指摘にしていました．

この指摘は，私がコードで確かめた範囲では正しいものでした．CLIの既定のモデルはnestedなので問題は出ませんが，APIの既定は da3-large です．

ほかに，npzに単位の記録がないことも提案として挙げていました．16ステップ目では，指摘を重さ（必須・良い点・提案・問い）ごとに表にまとめています．

4.3 CodeVisualizer

• src/depth_anything_3 全体の依存関係のグラフは，ファイル同士のimportの関係を描いたものです．今回の変更はimportをほとんど変えていないため，グラフは変更前とほぼ同じでした．差分を表示する機能もないので，拡大してファイル名を読めたとしても，どこが変わったのかは分かりません．全体を1枚に収めると，ノードが小さすぎてファイル名も読めませんでした．
• 変換の関数 _convert_distance_unit のフローチャートには，4つの分岐が正確に表れました（Code Metricsは行数18，分岐4など）．ノードをクリックすると，該当する行に移動できます．
• 一方で，「どの値が距離か」「なぜ scale_factor があるときはガウシアンを変えないのか」は，図からは分かりません．2つの仕様の抜けも，図からは読み取れませんでした．

5. 比較と使い分け

比較

観点	CodeRabbit	diff-tour	CodeVisualizer
全体像のつかみやすさ	◎	◎	△
変更範囲の分かりやすさ	○	◎	×
コードへの辿りやすさ	○	◎	◎
説明の信頼性	○	◎	◎（事実）／×（意味）
手軽さ・費用	○（数分，試用期間）	○（作成に約9分，Proの枠でAPI換算約2.21ドル）	◎（数秒，無料）
仕様の抜け（相対深度のモデル）	気づかず	「必須」として指摘	気づけない
仕様の抜け（npzの単位）	気づかず	「提案」として指摘	気づけない

AIは，指示どおりに動くコードを書きました．しかし，仕様の抜けが2つありました．CodeRabbitは指摘0件，リスク最小と判定し，diff-tourはその2つを見つけました．CodeVisualizerの図は正確でしたが，意味の判断はできませんでした．

使い分けのおすすめ

1章の「人間がレビューで確かめたいこと」に合わせると，次の順で使うのがよいと考えています．

1. 全体像は，PR差分型でつかむ：CodeRabbitなら，PRを開くだけで要約が付きます．どのファイルが何の役割かを最初に把握できます．ただし，非公開リポジトリで使い続けるには有料プランが必要です．月払いだと，最も安いEssentialsでも月額30ドル／ユーザー，今回試したAdvancedは月額90ドル／ユーザーで，学生が個人で払うには高いと感じます．公開リポジトリなら無料です．
2. 重要な変更は，ツアー型で前提から確かめる：diff-tourは時間と利用枠を使いますが，差分の外まで読み，前提の誤りを問いの形で示してくれます．
3. 気になる関数は，静的解析型で構造を確認する：CodeVisualizerなら，分岐の構造を正確に，すぐに見られます．意味の判断は人間が行います．

初めて触るリポジトリなら，その前にリポジトリ全体型で構造をつかんでおくと，変更の前提を考えやすくなるはずです（今回は試していません）．

まとめ

• 課題：AIの差分は，量が多く，重要な箇所が埋もれ，前提が残らず，説明は自信を持って書かれています．人間が全部の行を読まずに確かめる手段が必要です．
• なぜツールか：チャットに貼るだけでは，読ませ方も根拠の見せ方も聞き方しだいです．ツールは，読む手順と根拠の見せ方が決まっています．
• ツールの選び方：全体像はPR差分型，前提の確認はツアー型，関数の構造は静的解析型が向いています．
• 試した結果：今回のPRでは，2つの仕様の抜けに気づいたのはツアー型のdiff-tourだけでした．書き手は実装と同じClaude Codeで，差を生んだのは読ませ方だと考えています．

AIが書いた差分のレビューに悩んでいる方の参考になれば幸いです．

参考文献

紹介のみのツールの出典は，3章のリンク先です（2026年10月閲覧）．

1. Sonar, "Sonar Data Reveals Critical Verification Gap in AI Coding," 2026. https://www.sonarsource.com/company/press-releases/sonar-data-reveals-critical-verification-gap-in-ai-coding/
2. CodeRabbit, "Pricing." https://www.coderabbit.ai/pricing （2026年10月閲覧）
3. init-co-jp, "diff-tour," GitHub. https://github.com/init-co-jp/diff-tour （2026年10月閲覧）
4. DucPhamNgoc08, "CodeVisualizer," GitHub. https://github.com/DucPhamNgoc08/CodeVisualizer （2026年10月閲覧）