0github - コードレビューのためのヒートマップベースDiffビューア

 (0github.com)
6 ポイント 投稿者 GN⁺ 2025-11-01 | 1件のコメント | WhatsAppで共有
  • コード変更（diff）内の各行とトークンを色で区別し、レビューが必要な度合いを可視化するツール
  • 単純なバグ検出ではなく、**「もう一度見直す価値のある部分」**を強調するよう設計
  • GitHub Pull Request URL の github.com を 0github.com に置き換えるだけですぐに利用可能
  • 内部的にはリポジトリを VM に複製し、gpt-5-codex を実行して JSON 構造の分析結果を生成

概要

  • このツールは、コードレビューの過程で変更されたコードの各部分がどの程度注意深くレビューされるべきかをヒートマップ形式で表示
  • 色は人間の注意の必要度を基準に割り当てられ、単純なエラー検出とは異なるアプローチを取る

動作方式

  • ユーザーは GitHub Pull Request URL のドメインを github.com から 0github.com に変更してアクセス
  • システムは該当リポジトリを仮想マシン（VM）に複製し、各 diff に対してgpt-5-codex モデルを実行
  • モデルが生成したJSON データ構造をパースして、色付きヒートマップに変換

分析基準

  • 単に「バグかどうか」ではなく、ハードコードされた秘密値、異常な暗号化モード、複雑なロジックなど、
    人が再確認する必要のある部分を強調

関連記事

1件のコメント

 
GN⁺ 2025-11-01
Hacker Newsのコメント

  • 慣れ親しんだコードベースなら、「LLMありがとう、でもこっちのほうが分かっているから不要」と思う。
    逆に慣れていないコードなら、そもそも自分はそのレビューを承認したりマージしたりしない。
    それでも、こうした 創造的なLLM活用 は興味深い試みだ。

    • 実際に試してみた。Laravel PR #57499をランダムに選んだが、60%設定ではテストコードだけが強調され、重要な変更は見落としていた。
      削除されたコードもまったく表示されず、変更されていない行だけがハイライトされていた。
      誠実な試みではあったが、結果は期待外れ

  • なぜGitHub上で自分の代わりに行動する権限まで要求するのか疑問だった。
    cmux-agent がGitHubアカウント全体へのアクセス権を要求してきた。
    issueを登録しようとしたが、リポジトリでissue機能が無効化されていた。少し 怪しい感じ がした。

    • 公開リポジトリならログインなしでアクセスできるはずだ。
      シークレットモードで サンプルPR、stack-auth、tinygrad、datasette を試したが、問題なく動作した。
      issue無効化の件は知らなかったが、今は issueページ が正常になっている。
    • GitHubの構造的な問題だ。関連ディスカッション を見ると、OAuth AppとGitHub Appでは権限モデルが異なる。
      GitHub Appは特定のリポジトリにだけインストールできるが、それでも依然として「ユーザーの代わりに行動する」権限を含んでいる。
      だからあの怖いポップアップが表示される。
      自分のアプリ codeinput.com はOAuth Appなのでメールアドレスだけを要求するが、ログイン後にもう一度インストール手順を踏む必要があり、複雑な認証フロー になってしまう。
    • アプリを最初に起動するとGitHubログインを求められる。その前は何も見られない。

  • 方向性は面白いが、コストに見合う効果 がやや微妙だ。
    LLMが単一のPR diffだけでプロジェクトの文脈を理解するのは、まだ難しい。
    むしろ過去のバグや変更頻度に基づく データ駆動のヒートマップ のほうが信頼性は高そうだ。

    • Geminiの無料キーを使えば1日のリクエスト量は十分なので、小規模チーム（1日10〜20 PR）なら大きなコストにはならない。
      個人キーで実行できるなら、なお良さそうだ。
    • diffの エントロピー を分析する似たようなツールがあるのか気になる。
    • 以前こちらでも、リポジトリをVMに複製してCodexに探索させる実験をしたことがあるが、レイテンシとコスト の問題で中止した。
      Distillationでコストを下げられそうだが、まだ実験中だ。
      過去のバグとの相関を、LLMなしで計算する方法があるかどうかも考えている。
    • コードレビューでは、diffに含まれていない行に言及することがよくある。
      こうしたツールで解決できるのは、結局 問題の一部分だけ だ。
    • コード変更が頻繁な箇所が、必ずしもバグの多い場所とは限らない。
      むしろ人々がより注意深く見ている領域である可能性もある。
      オープンソースのデータを基に検証してみると面白そうだ。

  • 自分のPR がHNに載っていてうれしかった。
    0%しきい値にして 色のグラデーション をもっと細かく調整できるとよさそうだ。
    PR作成前に、AIが作ったコードをこのツールで事前レビューできるのかも気になる。

    • 色やグラデーションは設定可能にする予定だ。
      CLIやHTMLでdiffをレンダリングするコマンド形式がよいか、意見を聞きたい。
    • こういうツールを使うことで、結局 自分でコーディングする時間より長くかかるかもしれない

  • 0github.com というドメイン名は長く維持するのが難しそうだ。早めに別ドメインを探したほうがよさそう。

    • なぜそう思うのか気になる。

  • 巨大なPRでは特に役立ちそうだ。
    スライダーの代わりに色ごとにクリックして意味をすぐ確認できるとよい。
    今はひと目で把握しにくいが、頻繁に使えば慣れてきそうだ。

    • 現在はハイライトされた単語にマウスを載せると ツールチップ が表示される。
      モバイルでも見えるよう改善する予定だ。ほかにもっとよい表示方法があるか気になる。

  • シンプルなRust PRに適用してみたが、かなりうまく動いた。
    ただ、ハイライト位置をもう少し細かく調整できるとよい。
    同僚のPRでほとんど見えないタイプミスを見つけたのは印象的だった。
    試したPRのリンク
    削除されたコードの一部は表示されるが、多くの部分は無視されている。
    もしかして トークン間の距離 を計算する方式なのだろうか。

    • 実装は このファイル にある。
      今のところ単純なLLMプロンプトベースだ。
      将来的には 幻覚トークン検出 の方式へ発展させられるかもしれない。関連論文を探してみるつもりだ。

  • 最近はAIが作った大型PRが多く、こういうツールの必要性を感じている。
    レビュアーの スタイルを学習 して、カスタマイズされたレビューを提供できるとよさそうだ。
    このコミット で合っているか確認中だ。

    • 主なロジックは このファイル にある。
      DSPyシステムで、レビュアーの 好みに合わせた自動レビュー を実験している。

  • 実際のところ、こういうツールが不要なくらい 適切なサイズのPR を作ることのほうが重要だ。
    最近はAIが書いたPRをレビューし、さらには自分のコメントにAIが返信してくることまである。
    結局、レビュアーもAIに置き換えられる時代が来そうだ。

  • サンプルPRをクリックしたが、ずっと読み込み中のままだ。キャッシュ が必要に見える。

    • すでにキャッシュはあるはずだが、確認中だ。
    • 修正完了。今は正常に動作する。