code-review-pro

Code Review Pro

重要な問題を見つけ、それぞれの根拠を示し、修正方法を提示します。実際にある問題を短くまとめたリストのほうが、可能性にすぎない問題を長々と並べるより有益です。

ワークフロー

1. 範囲を決めます。 レビュー対象を決めます。貼り付けられたスニペット、特定のファイル、作業ツリーの差分（git diff、git diff --staged）、またはベースブランチとの差分（git diff main...HEAD）です。差分をレビューする場合は、変更された行を確認しつつ、呼び出し方がわかる程度に周辺のコードも読みます。

2. 判断する前にコンテキストを把握します。 言語、フレームワークとバージョン（package.json、pyproject.toml、go.mod などを確認）、コードへの到達経路（HTTP ハンドラー、ジョブ、CLI、ライブラリ）、信頼できない入力、リポジトリの規約（リンター、CLAUDE.md、既存のパターン）を特定します。あるフレームワークではバグになるパターンも、別のフレームワークでは安全な場合があります。たとえば React は JSX のテキストをエスケープするため、XSS が発生するのは dangerouslySetInnerHTML、href の値、生の HTML の挿入箇所です。

3. references/checklist.md を使い、優先順位に沿ってレビューします。

   1. セキュリティ
   2. 正しさとエッジケース
   3. パフォーマンス
   4. 保守性と規約

4. 報告する前に、すべての指摘を検証します。 候補ごとにデータフローをたどります。入力元はどこか、攻撃者や実際のユーザーが入力を制御できるか、上流ですでに検証やエスケープが行われていないかを確認します。テストでカバーされているかも確認します。コードを実行できる場合は、小さなテストやスクリプトでバグを再現します。裏付けられない指摘は取り除き、残りには信頼度を付けます。

5. 以下の形式で優先順位を付けてレポートを作成します。 重大度の高いものから記載します。同じ問題が繰り返し発生している場合は、すべての場所をまとめて1件の指摘にします。

重大度

• Critical - 現時点で悪用可能、またはデータの損失・破損を引き起こします。ユーザー入力によるインジェクション、認証の迂回、コード内のシークレット、実データに対するアクセス制御の不備などが該当します。
• High - 現実的な状況で発生する可能性が高いバグや脆弱性です。共有状態の競合、認可チェックの欠落、ユーザー向けの経路での無制限なクエリ、失敗を隠すエラーの握りつぶしなどが該当します。
• Medium - 現状は正しく動作していますが、脆弱な状態です。信頼された呼び出し元の背後での入力検証の欠落、小規模なデータに対する N+1 クエリ、状態の所有者が不明瞭であることなどが該当します。
• Low - スタイル、命名、小規模な簡素化です。報告は多くても数件にとどめ、リンターやフォーマッターがすでに検出する問題は省きます。

出力形式

# Code Review: [scope]

**Verdict**: [Ship / Ship after fixes / Do not ship] - [one sentence why]
**Findings**: [n] critical, [n] high, [n] medium, [n] low

## Critical

### 1. SQL injection in user search (`src/api/users.ts:42`)
**Category**: A05:2025 Injection | **Confidence**: High
**Evidence**: `q` comes from `req.query` and is interpolated into the SQL string; no validation upstream.
**Impact**: Any caller can read or modify arbitrary tables.

Current:
```ts
const rows = await db.query(`SELECT * FROM users WHERE name LIKE '%${q}%'`);
```

Fix:
```ts
const rows = await db.query("SELECT * FROM users WHERE name LIKE $1", [`%${q}%`]);
```

## High
...

## Medium
...

## Low
- `utils/date.ts:10` - [one line]

## What is solid
[Two or three specific things done well, so the author knows what to keep.]

## Not reviewed
[Files, paths, or concerns outside scope or that could not be verified.]

悪いレビューにつながる落とし穴

• 呼び出し元を読まずに報告する。 「検証が足りない」と思われる場合も、上位レイヤーですでに検証されていることがあります。指摘する前に確認します。
• 一般論に終始する。 「エラー処理を追加することを検討してください」は指摘ではありません。どの呼び出しが例外をスローし、ユーザーに何が表示され、どのような状態が残るのかを具体的に示します。
• スタイルを重大度として扱う。 行の長さ、括弧の位置、個人的な好みが Low より上の重大度になることはありません。
• 古いルールを適用する。 使用中のバージョンに照らして確認します。React Compiler が有効な場合、useMemo／useCallback に関する助言は変わります。また、現在は多くの Node API に組み込み機能（fetch、crypto.randomUUID、node:test）が含まれています。
• コンパイルできない修正を提示する。 すべての「Fix」ブロックは、リポジトリで使われている言語とバージョンで有効なものでなければなりません。不確かな場合は、その旨を伝えます。
• 指摘を並べすぎる。 指摘が15件を大きく超えると、重大な問題が埋もれてしまいます。細かな問題は1行にまとめます。