diffreview：Macでコード差分に指摘を書き、AIへMarkdownで返す

対象はCezar Halmagean氏のchalmagean/diffreviewです。GitHub APIのリポジトリ作成日時は2026年11月2日4:38 JST、最初のコミットは4:39 JST。Hacker Newsでの紹介は同日15:41 JSTでした。作成日時を厳密な一般公開時刻と同一視せず、紹介時点でソースを利用できることを確認しています。確認時点で番号付きのGitHub Releaseはありません。

この記事で確認した版はコミットa99b0d8ffc54b0e843b6b5f03e598d898b7d39b9です。検索で見つかるgaojude/diffreviewは別のリポジトリなので、ダウンロード先や導入手順を混ぜないでください。以下の説明はchalmagean版だけを対象とします。

READMEが示す流れは、Gitの作業フォルダーで起動し、行・行の範囲・ファイル全体へコメントし、最後にまとめを付けて提出するものです。提出したレビューはMarkdownとして標準出力に出ます。標準出力とは、コマンドが結果の文章を返す出力先のことです。GitHubのPRへ自動投稿するという意味ではありません。

出力に何が含まれるかはMarkdown生成処理で確認できます。コメントをファイルごとにまとめ、行番号と選択したコード片を付ける構造です。「説明した行とAIが直した行が違う」という食い違いを減らす使い方が考えられます。ただし、実際の修正精度や作業時間が改善したという比較実測はしていません。

Git取得処理では、通常起動と--baseで別の比較を行っています。見える差分の範囲を知らないまま「全部レビューした」と判断しないことが重要です。

HEADは現在のコミット、共通祖先は二つのブランチが分かれる前に共有しているコミットです。ブランチ比較は「現在のファイル全部をmainと比較」することと同じではありません。レビューの途中で編集やコミットが進む場合も、どの時点を見たのかを記録しておくと、指摘の行番号を照合しやすくなります。

この違いは、使い捨てのGitリポジトリで確かめました。example.txtへ変更をコミットした後、同じファイルへ未コミットの行を追加し、note.txtを未追跡のまま置く例です。共通祖先からHEADへの比較にはコミット済みの行だけが現れ、未コミットの行はHEADとの差分へ、note.txtは未追跡一覧へ現れました。存在しない参照名の解決も失敗することを確認しました。これはGitの比較範囲の教材実験であり、diffreviewの画面や出力の実測ではありません。

要件はPackage.swift、導入方法はREADME、利用許諾はLICENSEを参照しました。MacのOSが新しくても、実際に選ばれているSwiftが新しいとは限りません。今回はツールチェーンの追加や切替、アプリの常設インストール、Claudeの設定変更は行っていません。

このエラーを避けるためにソースの必要版だけを書き換えても、動作互換性を確認したことにはなりません。組織の開発環境の管理者とSwift 6の利用可否を確認し、条件がそろうまで導入を保留する判断もできます。

以下は公式手順を基にした試用案です。今回GUIまで成功した手順ではありません。自分に権限のある公開可能なサンプルだけを使い、最初から顧客のソースコードを開かないようにします。

1. 1chalmagean/diffreviewのREADMEとソースを確認する。対象MacでmacOS、Swift、Gitの条件を満たすかを確認し、利用するコミットを記録する。
2. 2条件を満たした環境で公式手順に従いソースを取得し、swift build -c releaseでビルドする。まず生成された実行ファイルを使って試し、常設先への配置はその後に判断する。
3. 3公開可能なサンプルのGit作業フォルダーで、通常起動か--baseによる比較かを選ぶ。未追跡ファイルに含まれる内容も確認する。 常設先へ配置していない場合は、サンプルの作業フォルダーに移動したうえで、ビルドした実行ファイルを絶対パスで起動します。
4. 4差分の行をクリックして指摘を書く。複数行は同じファイル内でShiftを使って範囲を選び、ファイル全体の指摘にはComment on fileを使う。
5. 5Finish reviewで要約を書き、Submit reviewでMarkdownを受け取る。まずはAIへ直結せず、出力を自分で読んで範囲と内容を確認する。保存するなら、レビュー対象のリポジトリとは別の場所にすると生成物が次の未追跡差分へ混ざるのを避けられる。
6. 6許可されたAIへ必要な部分だけを渡し、修正後の差分とテスト結果を再確認する。レビューの提出とコードの正しさの確認は別の作業として扱う。

キーボード操作や下書き保存の説明はREADMEにあります。下書きはGit管理ディレクトリ内のdiffreview/comments.jsonへ保存され、提出時には消す実装です。保存処理と提出処理を確認しました。途中で閉じた場合と提出した場合の違いを理解し、必要なレビュー本文は受け取った側で保存してください。 また、再開時には前回の比較対象に付けたコメントが残っていないかを確認し、今回の差分と合わない指摘をそのまま提出しないようにします。

同梱のコマンド定義は、diffreviewの出力を読み、その指摘へ対応するようClaudeに依頼するものです。ローカルの差分ビューアーを使うことと、レビュー本文やコードをクラウドAIへ送らないことは同義ではありません。コード片が出力されるため、送信先の契約・社内規則に沿って扱う必要があります。

差分に現れる未追跡ファイルも見落とさないでください。無視設定されていない設定ファイルや一時メモが対象に入る可能性があります。画面を開いた時点で自動的にすべてがAIへ送られるという説明ではありませんが、提出・連携前に情報の範囲を確認する理由になります。

READMEは、Claudeのコマンド実行の待ち時間に注意し、長いレビュー用にタイムアウト設定を変更する例を示しています。その例は他のBashコマンドの既定待ち時間にも影響すると作者が明記しています。個人の全プロジェクトへ設定をコピーする前に影響を確認し、最初は手動でレビューを受け渡す方法も検討してください。ここではClaude側の現在のタイムアウト値や連携完走を実測していません。

例えば、AIが送料計算の条件を変えたとします。「直して」だけより、期待する条件と確認したいケースを一緒に書くほうが、変更後に何を見るかを決めやすくなります。以下は架空の業務例で、diffreviewが生成した実測出力ではありません。

金額・境界条件・例外のように、人が業務上の意味を確認しやすい変更から試す用途が考えられます。逆に大きな設計変更やセキュリティの判断は、行コメントだけで終えず、周辺コード・設計資料・テストまで確認してください。

同じ作業は既存のエディターや差分ツールでも行えます。本ツールを追加する価値は、Macの独立した画面で指摘をまとめ、Markdownを別の作業へ渡したいかどうかで判断できます。今回確認した版では構文強調表示は未実装とREADMEに記載されています。

試用時の記録にはdiffreviewレビュー受け渡しチェックシート（TXT）を使えます。空の教材であり、自動レビューや設定変更を実行するものではありません。確認日：2026年11月2日JST。製品のGUI・日本語品質・AIによる修正結果は未検証です。