要約

この無料の AI コードレビューツールは、ルールベースの事前チェッカーです。git diff かスニペットを貼り付けると、追加された行を 13 個のルールで検査します。対象は、ハードコードされた秘密情報、文字列で組み立てた SQL、握りつぶされた例外、無効化されたテスト、デバッグ出力の残りです。大きすぎる変更やテストの不足も指摘し、行番号付きの 0〜100 点のスコアを返します。すべてブラウザ内で動き、AI モデルは使いません。人がレビューする前に、機械的な問題を取り除くためのツールです。

PR レビューの前に、差分を自分で確認する

git diff の出力かコードを貼り付けるだけで、無料の AI コードレビュー風チェッカーがブラウザ内で動きます。秘密情報の直書き、安全でない SQL、握りつぶされた例外、残ったデバッグコード、大きすぎる変更を検出し、プルリクエストに 100 点満点のスコアを付けます。AI モデルは使わず、ルールベースで判定します。

差分をチェック
モニターに並べて表示されたコード差分をレビューするエンジニア

事前チェッカー（差分）

統一形式の diff またはコードを貼り付けてください。差分を検出した場合は、追加された行のみをチェックします。貼り付けた内容がブラウザの外に送信されることはありません。

--/100
コードを貼り付けて開始
まだチェックしていません。
    仕組み

    チェッカーが見るもの、無視するもの

    追加された行だけを見る

    統一形式の diff を貼り付けると、チェッカーはハンクヘッダーを読み、新しいファイルの行番号を数え、あなたが追加した行だけをスキャンします。削除された行と変更されていない文脈行は指摘の対象になりません。古いコードのせいで責められることはありません。

    重大度で重み付けしたスコア

    ルールは 3 段階に分かれています。high は 15 点減点: ハードコードされた秘密情報、eval、文字列で組み立てた SQL、無効化された TLS 検証。medium は 7 点: 握りつぶされた例外、単独実行のテスト、innerHTML、400 行の差分。low は 2 点: TODO、デバッグ出力、コメントアウトされたコード。各ルールは最大 3 回までカウントされます。

    サイズとテストのチェック

    追加行が 200 行を超えると分割を促す通知が出て、400 行を超えるとより強い通知になります。根拠は、SmartBear が Cisco のデータで示した「レビュアーが一度に 200〜400 行を超えると、レビューの質が下がる」という知見です。テストファイルがない、追加行 50 行超の差分にも指摘が付きます。

    使い方

    貼り付けからクリーンな PR まで 4 ステップ

    1. 1

      差分を貼り付ける

      git diff main...HEAD、またはコミット前なら git diff --staged を実行し、出力を貼り付けてください。通常のスニペットでも使えますが、ファイル名とテストファイルの判定は失われます。

    2. 2

      high の指摘から読む

      赤い項目は、レビュアーが必ず引っかかる問題です。コミットに入ってしまった鍵は、行を削除しても履歴に残ります。削除するだけでなく、必ずローテーションしてください。

    3. 3

      残りは直すか、理由を書く

      各指摘には一行の修正案が付いています。誤検出であれば、PR の説明にその旨を書いてください。レビュアーが同じ質問をする手間が省けます。

    4. 4

      チェックリストをコピーする

      コピーボタンを押すと、指摘が Markdown のチェックリストになります。PR 本文に貼り付ければ、レビュアーは既に確認済みの項目を把握できます。

    事前チェックの理由

    レビューの最初の 30 秒を console.log の発見に使うべきではない

    同僚からのプルリクエストを開くと、お決まりの流れが分かるはずです。差分をスクロールし、消し忘れたデバッグ出力、チケットのない TODO、スキップされたテスト、エラーを握りつぶす catch ブロックを見つけます。どれも人間が判断する必要はありません。必要なのは、リクエストを出す前に走るチェックリストです。 このツールが埋めるのはその隙間です。レビュアーの注意力には限りがあります。SmartBear が Cisco のレビューを調べた研究では、人が 60〜90 分で 200〜400 行をレビューするとき欠陥の発見率は保たれますが、それを超えると低下します。機械的な指摘に費やす一分は、人にしか答えられない問いに使えたはずの一分です。このアプローチは正しいか、設計に合うか、半年後にも意味を持つか。 レビュアーの代わりにはなりませんし、そう見せかけることもしません。安価な指摘を先に取り除き、人のレビューを本当に面白い部分から始められるようにするだけです。

    • レビュー依頼を出す前に、機械的な指摘を検出する
    • 各指摘に、差分のハンクヘッダーから取った行番号を付ける
    • ブラウザ内で動くため、社内の非公開コードを貼り付けても安全
    ノートパソコンの前で、コードの変更について話し合う 2 人のエンジニア
    FAQ

    チェッカーについてのよくある質問

    これは AI コードレビューツールですか、それとも linter ですか？
    厳密にはどちらでもありません。ルールベースの事前チェッカーです。コードを読むモデルはなく、何かを生成することもありません。13 個のパターンルールが追加された行をスキャンし、レビュアーが最初の 30 秒で指摘するもの、つまり秘密情報、文字列で組み立てた安全でない SQL、握りつぶされた例外、残ったデバッグ出力を探します。推測する AI レビューは、推測しないチェックリストより悪いと考えるため、そのように正直に表記しています。
    コードはブラウザの外に出ますか？
    出ません。チェックはこのページの JavaScript で実行されます。アップロードも API 呼び出しも、アカウント作成もありません。記録されるのは、ツールが使われたという匿名のイベントだけで、テキストボックスの内容は含まれません。
    200〜400 行とテストファイルのルールはどこから来ていますか？
    サイズのしきい値は、SmartBear による Cisco のレビューデータの研究に従っています。この研究は、一度にレビューする行数を 200〜400 行以内にすることを推奨しています。小さな変更のルールは、Google が公開しているエンジニアリングのプラクティス（小さな CL）に従っています。テスト不足のルールは当サイト独自の規則です。テストファイルがなく、追加行が 50 行を超える差分に指摘を付けます。レビュアーが実際によく尋ねる質問だからです。
    スコアはどのように計算されますか？
    100 点から始まり、各指摘の重大度に応じて減点されます。high は 15 点、medium は 7 点、low は 2 点です。各ルールは最大 3 回までしかカウントされないため、ノイズの多いルールひとつでスコアが 0 になることはありません。これは作業の優先順位を付けるための目安であり、コード品質の指標ではありません。100 点は「どのルールにも引っかからなかった」という意味で、「コードが正しい」という意味ではありません。
    見逃すものは何ですか？
    理解を必要とするものすべてです。誤ったビジネスロジック、競合状態、不適切な抽象化、将来の変更に耐えられない API などです。正規表現ルールには誤検出もあります。たとえば、偽のパスワードを含むテストフィクスチャなどです。指摘はすべて判定ではなく、答えるべき問いとして扱ってください。
    どの言語に対応していますか？
    ルールはテキストパターンなので、JavaScript、TypeScript、Python、Java、Go、そして多くの C 系言語で動きます。一部のルールは言語固有です。bare except は Python、System.out.println は Java、InsecureSkipVerify は Go 向けです。統一形式の git diff を貼り付けると、行番号はハンクヘッダーから取得されます。
    無料ですか？
    はい。登録も不要です。レビュー中にリポジトリの他の部分についても答えがほしい場合、たとえば「この関数を呼んでいるのは誰か」「この設定値はどこで読まれているか」といった問いには、codebasechat が役立ちます。

    リポジトリ全体を見ながらレビューする

    差分が示すのは何が変わったかであり、何に影響するかではありません。codebasechat は、コードベースに関する質問に自然な言葉で答えます。承認する前に、変更された関数を誰が呼び出しているかを確認できます。

    codebasechat を無料で試す