コードレビュアー

概要

バグ、セキュリティ問題、パフォーマンス問題、保守性の懸念を特定する構造化されたコードレビューを実施します。優先度付けされた実行可能なフィードバックと具体的な修正提案を提供します。

手順

ユーザーがコード、ファイル、diff、またはプルリクエストのレビューをリクエストした場合、以下のプロセスに従います：

ステップ 1: コンテキストを理解する

レビューの前に、以下を確認します：

• このコードは何をするのか？（機能追加、バグ修正、リファクタリング）
• どの言語とフレームワークを使用しているか？
• テストは含まれているか？
• これはファイル全体か、diff/パッチか？

必要に応じて周辺ファイルを読んで、より広いコードベースのコンテキストを理解します。

ステップ 2: チェックリストを使用してレビューする

各カテゴリのコードを深刻度の順に評価します：

正確性（致命的）

• ロジックエラー、オフバイワンエラー、不正な条件
• 処理されていない null/undefined/空のケース
• レース条件または並行処理の問題
• 不正なエラー処理（呑み込まれた例外、不正なエラー型）
• 入力検証の欠落

セキュリティ（致命的）

• SQLインジェクション、XSS、コマンドインジェクション
• ハードコードされたシークレット、APIキー、パスワード
• 不正な認証/認可チェック
• 安全でないデシリアライゼーション、パストラバーサル
• パブリックエンドポイントのレート制限の欠落

パフォーマンス（高）

• データベースループ内の N+1 クエリ
• UI コンポーネントの不要な再レンダリング
• 頻繁なクエリのインデックス欠落
• 無制限なメモリ増加（データセット全体の読み込み）
• メインスレッド上のブロッキング操作

信頼性（高）

• 外部呼び出し（ネットワーク、ファイル I/O）のエラー処理の欠落
• 一時的な障害のリトライロジックの欠落
• HTTPリクエストのタイムアウト欠落
• リソースリーク（クローズされていない接続、ファイルハンドル）

可読性（中）

• 不明確な変数名または関数名
• 多くのことを行う関数（30行を超えるのは危険信号）
• 深くネストされた条件分岐（3レベルを超える）
• 欠落したコメントまたは誤解を招くコメント
• 一貫性のない命名規則

テスト（中）

• 新しいロジックのテスト欠落
• 意味のある動作をアサートしないテスト
• エッジケースカバレッジの欠落
• 実装詳細に密結合した脆いテスト

ステップ 3: レビューをフォーマットする

深刻度別に結果を整理します。各問題について：

### [深刻度] カテゴリ: 簡潔なタイトル

**ファイル:** `path/to/file.ext` XX-YY 行目

**問題:** 何が間違っており、なぜそれが重要なのか。

**提案:**
\`\`\`言語
// 修正案
\`\`\`

深刻度レベル: CRITICAL（致命的）、HIGH（高）、MEDIUM（中）、LOW（低）

ステップ 4: サマリーを提供する

以下で終了します：

• 全体的な評価（承認、変更要求、要討議）
• 深刻度別の問題数
• マージ前に修正すべきトップ 3 項目

例

例 1: Node.js API エンドポイントのレビュー

ユーザーリクエスト: 「この Express ルートハンドラーをレビューしてください」

提出されたコード:

app.post('/users', async (req, res) => {
  const { name, email, role } = req.body;
  const user = await db.query(
    `INSERT INTO users (name, email, role) VALUES ('${name}', '${email}', '${role}')`
  );
  res.json(user);
});

レビュー出力:

### CRITICAL セキュリティ: SQLインジェクション脆弱性

**ファイル:** routes/users.js 2-5 行目

**問題:** ユーザー入力が SQL クエリ文字列に直接補間されています。
攻撃者は name、email、role フィールド経由で任意の SQL をインジェクトできます。

**提案:**
    const user = await db.query(
      'INSERT INTO users (name, email, role) VALUES ($1, $2, $3)',
      [name, email, role]
    );

### CRITICAL セキュリティ: 入力検証なし

**ファイル:** routes/users.js 2 行目

**問題:** リクエストボディフィールドが検証なしで使用されています。欠落した
または不正な形式のデータはデータベースエラーを引き起こすか、無効なレコード
を保存します。

**提案:**
    if (!name || !email || !email.includes('@')) {
      return res.status(400).json({ error: 'Name and valid email required' });
    }
    const allowedRoles = ['user', 'admin', 'editor'];
    if (!allowedRoles.includes(role)) {
      return res.status(400).json({ error: 'Invalid role' });
    }

### HIGH 信頼性: エラー処理なし

**ファイル:** routes/users.js 3-5 行目

**問題:** データベースクエリが失敗すると、エラーが処理されないプロミス拒否として
伝播し、プロセスをクラッシュさせるか、スタックトレース付きで 500 を返します。

**提案:**
    try {
      const user = await db.query(...);
      res.status(201).json(user);
    } catch (err) {
      console.error('Failed to create user:', err);
      res.status(500).json({ error: 'Failed to create user' });
    }

サマリー: 変更要求
- 致命的: 2、高: 1、中: 0
- マージ前に SQLインジェクションを修正し、入力検証を追加してください

例 2: React コンポーネントのレビュー

ユーザーリクエスト: 「このコンポーネントを問題がないかレビューしてください」

提出されたコード:

function UserList({ users }) {
  const [search, setSearch] = useState('');

  const filtered = users.filter(u =>
    u.name.toLowerCase().includes(search.toLowerCase())
  );

  return (
    <div>
      <input onChange={e => setSearch(e.target.value)} />
      {filtered.map(user => (
        <div>{user.name} - {user.email}</div>
      ))}
    </div>
  );
}

レビュー出力:

### MEDIUM パフォーマンス: フィルタリングが毎回のレンダリングで実行される

**問題:** フィルタ操作は無関係なステート変更でも毎回のレンダリングで再計算されます。
大きなリストの場合、これは動作を遅くさせます。

**提案:**
    const filtered = useMemo(() =>
      users.filter(u =>
        u.name.toLowerCase().includes(search.toLowerCase())
      ), [users, search]);

### MEDIUM 可読性: リスト項目に key プロップがない

**問題:** React はリスト項目で効率的な調整を行うために一意の key プロップを
必要とします。key がない場合、不正な再レンダリングと警告が発生します。

**提案:**
    {filtered.map(user => (
      <div key={user.id}>{user.name} - {user.email}</div>
    ))}

### LOW 可読性: 入力ラベルとプレースホルダーがない

**問題:** 検索入力にラベルやプレースホルダーがなく、入力の用途が不明確で、
スクリーンリーダーからアクセスできません。

**提案:**
    <label htmlFor="user-search">Search users</label>
    <input
      id="user-search"
      placeholder="Search by name..."
      onChange={e => setSearch(e.target.value)}
    />

サマリー: 提案付きで承認
- 致命的: 0、高: 0、中: 2、低: 1
- マージ前に key プロップと useMemo を追加してください

ガイドライン

• 重要な問題に焦点を当てます。リンターが設定されている場合は、フォーマットの細部にこだわりません。
• 常に「何を変更するか」だけでなく、「なぜそれが問題なのか」を説明します。
• 単に「改善できる」ではなく、具体的な修正提案を提供します。
• コードが何をうまくやっているかを認識します。レビューは専ら否定的であるべきではありません。
• diff をレビューするとき、変更行に焦点を当てますが、統合の問題がないかコンテキストを確認します。
• 大規模な PR（500 行以上）の場合、行ごとのレビューの前にアーキテクチャの概要を提示します。
• 結論が不確かな場合は、そう述べます。不確実な問題を確定的に提示しません。
• 優先順位：すべての CRITICAL を修正し、HIGH をマージ前に修正し、MEDIUM/LOW は後続タスク可能です。