ハクソク

世界を動かす技術を、日本語で。

HNに表示: コードレビュー用のヒートマップ差分ビューアを作成しました

2025年10月30日原文(0github.com)

概要

0github.comは、GitHubのプルリクエスト差分をヒートマップで可視化するツール。 各行やトークンごとに「人間の注目が必要な度合い」を色分け表示。 従来のPRレビューBotとは異なり、「バグかどうか」だけでなく「再確認すべき箇所」も強調。 LLM（gpt-5-codex）を活用し、JSONデータを解析して色付け。 オープンソースでMITライセンス、誰でも利用・導入可能。

0github.comによるPRヒートマップ可視化ツール

  • 0github.com は、GitHubプルリクエストの差分（diff）をヒートマップで色分け表示
  • 各 行・トークン ごとに「どれだけ人間の注目が必要か」を可視化
  • 一般的な PRレビューBot と異なり、「バグかどうか」だけでなく「再確認すべき箇所」も強調
    • 例： ハードコーディングされた秘密情報
    • 例： 不自然な暗号モード
    • 例： 複雑なロジック
    • 例： 可読性の低いコード
  • 利用方法： github.com を 0github.com に置き換えてアクセス
  • 例：https://0github.com/manaflow-ai/cmux/pull/666 https://0github.com/stack-auth/stack-auth/pull/988 https://0github.com/tinygrad/tinygrad/pull/12995 https://0github.com/simonw/datasette/pull/2548

技術的仕組み

  • プルリクエストを 個別ファイル ごとに分割
  • 各ファイルの差分を gpt-5-codex などのLLMに渡し、各行をアノテーション
  • LLMの出力を JSONデータ構造 として受け取り、ヒートマップに変換
  • 色の濃い黄色ほど「要注目度」が高い箇所を示す
  • ハイライト部分にマウスオーバーすると、 LLMによる説明 をポップアップ表示
  • 左上のスライダーで「レビューすべき閾値」の調整が可能

オープンソース・導入情報

  • MITライセンス で公開、誰でも利用・導入可能

  • リポジトリ：https://github.com/manaflow-ai/cmux

    • ドキュメント や サンプル も充実
    • カスタマイズや自社CI/CDパイプラインへの組み込みも容易

まとめ

  • 0github.com は、コードレビューの効率化・品質向上に寄与
  • 「もう一度見ておくべき箇所」をAIが自動で強調
  • チーム開発やセキュリティレビューにも有用な新しいPR差分可視化ツール

Hackerたちの意見

これめっちゃクールだね！特に大きなPRに対してすごく役立ちそう。スライダーの代わりに、色のヒートマップをクリックできて、それが何のためのものか（閾値じゃなくてラベル）を示してくれたらいいな。基本的な考えは分かるけど、一目で処理するにはちょっと多すぎる気がする。これを常に使うことにならない限りね。

└

現在、強調表示された単語にマウスを乗せるとツールチップが表示されるけど、モバイルでも見えるようにしないとね。ホバー以外でラベルを表示する方法を考えてるのかな？

PRをレビューする時に、今のワークフローで欠けてるなって感じることだよ。特に大きなAI生成のPRが増えてる今、ほとんどのレビュアーは興味のあるポイントを見てると思う。もしこれが過去のレビューを見て、スタイルを学んでくれたら面白いな。これって確認すべきコミットで合ってる？ https://github.com/manaflow-ai/cmux/commit/661ea617d7b1fd392...

└

https://github.com/manaflow-ai/cmux/blob/main/apps/www/lib/s... このファイルがほとんどのロジックを持ってるよ。リンクしたコミットには他の実験がたくさんあるね。> 過去のレビューを見てスタイルを学ぶ。私たちもこの方向性に興味があって、レビューを自動的に好みに合わせるDSPyシステムを設定することを考えてるよ。

https://0github.com/stack-auth/stack-auth/pull/988 自分のPRがHacker Newsに載るのを見るのはすごく楽しい！これ素晴らしいね。多分、閾値は0%に設定したままにするつもりだから、もう少しグラデーションのバリエーションがあるといいな。赤-黄-緑とか？それと、PRを作る前にAI生成のコードにこれを使うことはできるのかな？IDEでCodexやClaudeのコード編集をレビューするのに結構時間がかかってるんだ。

└

そうだね、グラデーションや色を設定できるようにしたいよね。どんな形が一番理にかなうと思う？CLIコマンドで差分を表示するか、HTMLで表示するのがいいかな？

ちょっとキャッシュを追加してみたら？例のPRの一つをクリックしたら、ずっと読み込み中になっちゃった...

└

うわ、もうキャッシュがあるはずなのに。今見てるよ。

└

修正をプッシュしたよ、今は動くはず！

面白い方向性だけど、何が重要かを推測するにはちょっと高くつく気がする。LLMが単一のPR差分からプロジェクト特有のコンテキストを本当に捉えられるかは分からないな。正直、どの部分のコードが最も頻繁に変更されるか、過去のバグと相関があるかを示すシンプルなデータ駆動型ヒートマップの方が、レビュアーにとって信頼できるシグナルを提供すると思う。

└

うん、正直今のところこれを運用するのはかなり高くつくよね。 > 「LLMが単一のPR差分からプロジェクト特有のコンテキストを本当に捉えられるかはわからない。」 もっと高価なアプローチも試したけど、VMにリポジトリをクローンしてCodexにコードベースを探索させて、コードを実行してからヒートマップデータ構造を返すってやつだった。レイテンシーとコストの問題で今は見送ってるけど、LLMがプロジェクトのコンテキストを得るために再検討するつもり。蒸留技術でコストが少しは助けになると思うけど、まだ十分に実験してないから確実な答えはないな。遊んでみるのが楽しみ！ > 「どの部分のコードが最も頻繁に変更されるか、過去のバグと相関があるかを考えられる方法がある。」 もしかしてもっとシンプルなアプローチを見逃してるかな？でも過去のバグに基づく条件付けはいいと思う。

└

PRをレビューする時に考慮しているコードの大部分は、差分には含まれてないんだよね。これってよくある経験だと思う。PRにないコードやファイルにコメントしたくなること、どれだけ多いか考えてみて。ほとんどのPRでそうなるよ。無駄なコメントとして現れたり、「この行じゃなくて、XYZはどう？」とか「ここを3箇所置き換えたけど、実は2箇所もっと適用すべきところがあったよ。」みたいなコメントになる。これらのツールはまあまあだけど、問題の一部しか解決できないってことは理解しておこう。

Hacker Newsで議論の続きを見る