ハクソク

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

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

207日前原文(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箇所もっと適用すべきところがあったよ。」みたいなコメントになる。これらのツールはまあまあだけど、問題の一部しか解決できないってことは理解しておこう。

└

Geminiだとそんなに高くないよ。無料のキーがあって、1日あたりのリクエスト数も十分あるし、差分と関連するコードベースのバンドルをアップロードすれば、この動作を無料で得られるよ。少人数のチームで1日10〜20のPRがあればね。個人のキーでこれを実行できればいいけど。

└

Premiseはすごいね。diffエントロピーを見て似たようなことをするツールがあるのかな。

└

正直、どの部分のコードが最も頻繁に変更されるか、過去のバグと相関があるかを示すシンプルなデータ駆動型ヒートマップがあれば、レビューアーにとってもっと信頼できるシグナルになると思う。最初はそう思ったけど、今はそれが良いヒューリスティックだとは思えないな。多分、みんなが注意深く見たりするところだと思う。推測だけど、リグレッションは「ホットスポット」では起こりにくいんじゃないかな。でも、これはただの直感だよ。レビューが良くてバグ報告もたくさんあるオープンソースプロジェクトがたくさんあるから、誰かがそれをテストしたら面白いかもね。

数ヶ月前に取り組んだ低複雑度のRust PRで試してみたけど、かなり良い感じだったよ。ハイライトの位置を変えた方がいいかも（例えば、x.y.z() -> x.w.z()は多くのケースでy/wをハイライトすべきだと思う）。大体は、じっくり見ないといけないエリアに目を引く感じ。共働者のPRでほとんど見えないタイプミスを見つけたのも面白かった。 https://0github.com/geldata/gel-rust/pull/530 いくつかの削除を注意が必要としてフラグを立ててるみたいだけど、結構無視されてる気がする。これは、期待されるトークンと実際のトークンの距離を測る何かを使ってるのかな？ EDIT: ああ、ただのLLMプロンプトなのかな？期待されるトークンと実際のトークンがヒートマップを生成するアプローチを見てみたいな。

└

聞けて嬉しい！ > 「これは、期待されるトークンと実際のトークンの距離を測る何かを使ってるの？」 メインの実装はこのファイルにあるよ: https://github.com/manaflow-ai/cmux/blob/main/apps/www/lib/s... EDIT: うん、ただのLLMプロンプトだね、ハハ。今はシンプルなプロンプトだけど、どのトークンが幻覚的かを直接見るアプローチを試してみたいと思ってる。このアイデアの論文を探してみるつもり。期待されるトークンと実際のトークンの「距離」に似たようなものかも。

なんでGithubで自分の代わりに行動するためにサインインしてフルアクセスを許可しなきゃいけないの？ cmux-agentはあなたのGithubアカウントへのアクセスが必要だよ： GitHubのアイデンティティを確認する あなたがアクセスできるリソースを知る あなたの代わりに行動する あなたのメールアドレスを見る これについて問題を報告しようと思ったけど、リポジトリでの問題報告が無効になってるみたい。ちょっと怪しいと思う。

└

公開リポジトリはサインインしなくても見れるはずだよ。インコグニートモードでこのリンク試してみたけど、問題なさそう？ 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

リポジトリでログの問題を無効にしてるよ ごめん、知らなかった。今すぐオンにするね。編集： https://github.com/manaflow-ai/cmux/issues は大丈夫そう？

└

アプリを初めて起動したときに、他のものを見る前にGitHubでログインするように求められるよ。

└

GitHubの混乱だね。議論を見てみて: https://github.com/orgs/community/discussions/37117 簡単に言うと、GitHubにはoauthアプリと「GitHubアプリ」があるんだ。GitHubアプリは新しいモデルで、特定のリポジトリにインストールできるから、アカウントに広くアクセスする必要がない。GitHubはこれを使うことを推奨してるよ。ただし、一つ注意点があって、GitHubはこれらのアプリを「ユーザーの代理で行動できる」ように設計してるんだ。たとえアプリが「メールアドレスだけ」を求めていても、その「権限」を持ってしまうんだよね。だから、怖いポップアップが出るんだ。これを解決する唯一の方法は、フローを「複雑にする」ことだと思う。もし https://codeinput.com（私のアプリ）に行って、GitHubでログインをクリックすると、メールアドレスだけを求めるあまり怖くないポップアップが出るよ（これはoauthアプリだから！）。ただし、ログイン後に「認証＋インストール」の手続きを再度やらなきゃいけないのが面倒なんだけどね！だから、ユーザーに必要なステップを説明するためのオンボーディングステップを作らなきゃいけなかったんだ。

こういうツールをどうやって作るのか、誰か教えてくれない？自分はクラシックなJava/C#のバックエンド開発とSQLの経験があるんだ。ちょっとSpring Bootを使ったマイクロサービスもやってる。今は午後8時半で、Reactのチュートリアルを見ながら現代のウェブサイトの作り方を理解しようとしてるんだけど、useStateやuseRefとかね。で、cmuxみたいなツールを作るには自分の経験がどう活かせるの？本当に理解したいんだけど。cmuxのコードベースを一行ずつ見ていくのが答えなの？それともcmuxのバグの問題にPRを出してみて、時間が経てば理解できるようになるのかな？

└

あなたのチームに新しく入った人で、Pythonと少しSQLしか使ったことがなくて、JavaやSpring Bootには触れたことがない人には何を勧める？

└

高レベルで言うと、GitHub APIを叩いて、コードをLLMに渡して、結果をウェブアプリに表示する感じかな。ウェブアプリを学びたいなら、まずはドキュメントから始めてみて。例えば、公式のReactドキュメントとか、もし知らなければバニラJavaScriptを学ぶのもいいよ。GitHub APIを叩いて、ターミナルにJSONを表示するような小さな部分から始めてみて。LLMにプロジェクトをスキャフォールドしてもらうようにプロンプトを出して、出てくる問題をデバッグしてみるのもいいかもね（問題は出てくるけど）。

└

もし役に立つものを作りたいなら、CLIだけのバージョンを作るのが一番早いと思うよ。理論的にはヒートマップを表示したり、CLI形式でタスクマネージャーを作ったりできるしね。JavaやC#のバックグラウンドも役立つはず。Claude CodeやCodexを使って、上手にプロンプトを作ることを学ぼう。cmuxの90%以上と0github.comはLLMによって書かれたものだよ。ほとんどは、LLMに何かを実装してもらって、それが動くかテストして、動かなかったらログを書いてもらって、そのログをLLMに貼り付けるって感じ。アーキテクチャの選択についてはgpt-5-proに聞いてみて、どんな技術や依存関係を使うべきかを相談してみて。もしReactを学ぶのが目的なら、公式の入門ドキュメントを読むことをおすすめするよ。結構いいから。

└

コーディングの経験は十分あるから、もっと「問題解決」の練習が必要だね。クレイジーなアイデアを考えて、それを最後までやり遂げることが大事だよ。それに、これはただのLLMの薄い層で、実際の品質は疑わしいから。リアルな仕事をすることを学ぼう。魔法の機械が学びやスキルの構築を肩代わりしてくれることはないからね。

0github.comのドメイン名を長く維持するのは難しいと思うよ。すぐに新しいのを探し始めた方がいいんじゃないかな。

└

なんで？

明確な指標を持つべきだよ、ChatGPTじゃなくて。ChatGPTはこのタスクに関連する大規模なデータセットで訓練されてないから。