audit-code-review

コードレビューのスキル

自由度：混合 — フェーズ 1～2 の判断 [HIGH freedom]； レビュー前の Git／ドキュメント確認は必須 [LOW freedom — run exactly]。

この PR または指定された差分をレビューします。リポジトリ全体に関わるアンチパターンは audit-code-quality を参照してください。 一括変換のセマンティクスは audit-codemod-safety を参照してください。

推論の進め方

1. 観察 — 該当する差分と周辺のファイルを引用します（該当行だけではなく）
2. 解釈 — これをマージすると、何が壊れたり、漏洩したり、重複したりするでしょうか？
3. 分類 — ブロッキング／提案／軽微な指摘／称賛
4. 重大度 — セキュリティ、データ損失、既存機能の破壊はブロッキングです

作業例

観察： 新しい GET /api/invoices/:id が、userId 条件なしで Invoice.findById(id) を返しています（この差分の app/api/invoices/[id]/route.ts）。 解釈： 認証済みのユーザーなら誰でも、別のユーザーの請求書を読み取れます。 分類： ブロッキング（IDOR）。 重大度： 致命的 — マージ前に必ず修正が必要です。 指摘： [id]/route.ts | 所有者チェックを追加 | ブロッキング

レビュー前の確認 [LOW freedom — run exactly]

コードをレビューする前に：

1. 関連ドキュメントを読む

README.md (project conventions)
src/[domain]/@_[domain]-README.md (domain-specific patterns)
CONTRIBUTING.md (code standards)

2. 変更全体を把握する

PR またはコミットをレビューする場合：

git log --oneline -10 # recent context
git diff <base>..HEAD --stat # files changed
git diff <base>..HEAD # full diff

特定のファイルをレビューする場合は、変更された行だけでなく、コンテキストを把握するためにファイル全体を読んでください。

3. 重複した実装がないか確認する

Grep と SemanticSearch を使って、以下を確認します。

• このコードは既存の機能と重複していませんか？
• 拡張すべき既存のコンポーネント／サービスはありませんか？
• コードベースで確立されたパターンに従っていますか？

4. 本番環境への影響を確認する（Sentry）

変更がエラーの発生しやすいコードに関わる場合は、関連する Sentry の問題が存在するか確認します。

sentry:search_issues
{
 "organizationSlug": "<ORG_SLUG>",
 "query": "issues related to <component or function being changed>",
 "projectSlugOrId": "<PROJECT_SLUG>",
 "regionUrl": "<REGION_URL>",
 "limit": 10
}

これにより、変更対象のコードに既知の本番環境の問題があるか、この変更が問題を修正するのか、または問題を新たに引き起こすリスクがあるのかが分かります。

5. 最新のベストプラクティスを調べる（複雑なパターンの場合）

検証したいパターンをコードが使用している場合：

firecrawl:firecrawl_search
{
 "query": "<framework> <pattern> best practice <current year>",
 "limit": 5,
 "sources": [{ "type": "web" }]
}

---

レビュープロセス [HIGH freedom]

フェーズ 1：全体的な評価

行単位のレビューに入る前に：

• この変更の目的は何ですか？
• アーキテクチャ上、このアプローチは妥当ですか？
• よりシンプルな代替案はありますか？
• 新たな依存関係が追加されますか？ それらは正当化されていますか？

フェーズ 2：詳細レビューのチェックリスト

正確性

• 想定されるすべての入力に対してロジックが正しい
• 変更が PR／タスクの要件を満たしている — 要件の欠落、中途半端な実装、または気付かれないまま範囲が狭められている場合は、ブロッキングの指摘です
• エッジケースに対応している（null、空、オーバーフロー、並行アクセス）
• 明らかなバグがない（オフバイワン、演算子の誤り、await の欠落）
• エラー処理が十分かつ適切である
• 非同期コードが競合状態とクリーンアップに対応している（AbortController など）

セキュリティ

• SQL インジェクションの脆弱性がない（ユーザー入力を使った生のクエリ）
• XSS の脆弱性がない（dangerouslySetInnerHTML、innerHTML）
• ハードコードされた秘密情報や認証情報がない
• ユーザー向けのすべてのエンドポイントに入力検証がある
• 認証／認可が適切に確認されている（UI レベルだけではない）
• ログやエラーメッセージに機密データが含まれていない

パフォーマンス

• N+1 クエリがない（一括処理、Eager Loading）
• 不要なループや計算の繰り返しがない
• 適切なデータ構造を使っている（Map と Object、Set と Array）
• メモリリークがない（イベントリスナーがクリーンアップされ、サブスクリプションが解除されている）
• React：不要な再レンダリングがない（適切な場合は memo、useMemo、useCallback を使用）
• データベース：クエリがインデックスを使用し、テーブル全体のスキャンを回避している

可読性

• 明確で説明的な名前（関数、変数、型）が使われている
• 関数のサイズが適切である（単一責任）
• コメントが「何を」ではなく「なぜ」を説明している（自明でない制約のみ）
• プロジェクトの既存のスタイルと一貫している

保守性

• DRY — 共有すべきロジックが重複していない
• 単一責任 — 各関数／コンポーネントが一つのことだけを行う
• マジックナンバーやマジック文字列がない（定数またはユニオン型を使用する）
• 型が具体的である（any や範囲が広すぎるユニオン型がない）
• 依存関係が適切で最小限である

テスト

• テストが変更内容を網羅している（正常系＋エッジケース）
• テストが独立しており、決定的である
• 不安定なテスト（タイムアウト、競合状態）を導入していない
• テスト名が期待される動作を説明している

重複の防止

• コンポーネントが重複していない（src/components/ を確認済み）
• サービスやフックが重複していない
• 既存のパターンを重複させず、拡張している
• 2 回以上使用する共有ロジックをユーティリティ／フックに切り出している

---

フィードバック形式

重大度レベルを使用してください。

### Critical (must fix before merge)
**[File:Line]** — [Description]
Why: [Impact if not fixed]
Fix: [Specific suggestion]

### Suggestion (recommended improvement)
**[File:Line]** — [Description]
Why: [Benefit of the change]
Alternative: [How to improve]

### Nitpick (optional, non-blocking)
**[File:Line]** — [Description]

### Praise (good patterns to reinforce)
**[File:Line]** — [What's done well and why]

---

ブロッキングと非ブロッキング

ブロッキング（必ず修正）

• セキュリティの脆弱性
• データ破損のリスク
• 既存機能の破壊
• 重大なエラーハンドリングの欠如
• パフォーマンスの低下（測定可能なもの）
• 型安全性への違反（any、未チェックのキャスト）

非ブロッキング（提案）

• より適切な命名や整理
• エッジケースのテスト不足
• ドキュメントの不足
• 軽微なパフォーマンス改善
• リンターでカバーされていないスタイル上の好み

---

よく指摘するパターン

TypeScript/JavaScript

// BLOCK: any types
const data: any = response;

// BLOCK: unhandled promises
fetchData(); // missing await or .catch()

// BLOCK: implicit type coercion in conditions
if (value) // when value could be 0 or ""

// SUGGEST: magic strings
if (status === 'active') // use a constant or union type

React

// BLOCK: missing key in lists
{items.map(item => <Item {...item} />)}

// BLOCK: stale closure in useEffect
useEffect(() => {
 setInterval(() => console.log(count), 1000); // captures stale count
}, []);

// SUGGEST: inline object creation in props
<Component style={{ margin: 10 }} /> // new object each render

データベース

-- BLOCK: SQL injection vector
WHERE name = '${userInput}'

-- SUGGEST: missing index
SELECT * FROM orders WHERE user_id = ? -- is user_id indexed?

-- SUGGEST: SELECT *
SELECT * FROM users -- select only needed columns

---

報告前の自己批評 [自由度低 — 省略しないでください]

1. 根拠がある — 「もっと良くできる」ではなく、diff の File:Line を示す
2. 再現可能 — 該当箇所だけでなく、ファイル全体を読む
3. 重大度に妥当性がある — ブロッキングはセキュリティ／データ損失／破壊／重大なエラーハンドリングの欠如に限る
4. 適切な担当先である — リポジトリ全体に関する問題 → audit-code-quality、一括変換 → audit-codemod-safety
5. 誤った安全判定がない — リンターでカバーされるスタイルはブロッキングではない

レビュー返信テンプレート

## Code Review: [PR Title / File]

### Summary
[1-2 sentence overall assessment — is this ready to merge?]

### Critical (blocking)
[List any must-fix findings]

### Suggestions (recommended)
[List recommended improvements]

### Praise
[Highlight good practices — reinforces positive patterns]

### Questions
[Clarifying questions about intent or design decisions]

### Research Notes
[If patterns were verified via Firecrawl/Context7, note what was confirmed]

---

指摘事項に該当するもの

ブロッキングの指摘事項とは、正確性に関するバグ、セキュリティ上の欠陥、データ損失につながる経路、変更で主張されていることと実際の動作との食い違いです。提案や細かな指摘は、上記のフィードバック形式に従ってください。各指摘には該当行、影響、修正方法を記載します。リンターまたはコードベース独自の規約ですでにカバーされているスタイルは、どの重大度でも指摘事項には該当しません。該当箇所を判断する前に周辺のコードを読み、意図が不明確な場合は推測せず、「質問」セクションで確認してください。