code-review

コードレビュー

このスキルを使うと、AI エージェントがソースファイル、変更一式、またはプルリクエストに対して、体系的かつ包括的なコードレビューを実施できます。エージェントは、正確性、セキュリティ、パフォーマンス、可読性、保守性など複数の品質観点からコードを検証し、具体的なコード行にひも付けた、実行可能なフィードバックを含む詳細なレビュー報告を作成します。

ワークフロー

1. 入力を解析し、コンテキストを把握します。 入力が単一ファイル、ディレクトリ、プルリクエストの差分のいずれであるかを判断します。プルリクエストの場合は差分を取得し、ベースブランチを特定して、変更行のみをレビューします。レビューをプロジェクトの標準に沿って調整できるよう、関連する設定ファイル（リンター設定、スタイルガイド、型定義など）を読みます。

2. 変更の意図を理解します。 コミットメッセージ、PR の説明、周辺コードを読み、作成者が何を意図していたのかを把握します。レビュー担当者は、コードが目的を達成しているかを判断する前に目標を知る必要があるため、これにより誤検出を防げます。続行する前に、変更内容を 1 文で要約します。

3. 正確性とバグを確認します。 変更された関数をすべて確認し、データフローを追跡します。null または undefined の参照、オフバイワンエラー、不正なブール論理、未処理のエラー経路、並行コードの競合状態、リソースリーク（開いたままのファイル、データベース接続、解放されていないロック）を探します。空の入力、最大値、予期しない型などのエッジケースが処理されていることを確認します。

4. セキュリティを評価します。 一般的な脆弱性のパターンを確認します。具体的には、サニタイズされていないユーザー入力（SQL インジェクション、XSS）、ハードコードされた秘密情報や認証情報、安全でない暗号処理、過度に許可されたファイルやネットワークへのアクセス、認証または認可チェックの欠落などです。依存関係の追加をすべて指摘し、既知の CVE がないか確認します。

5. パフォーマンスとスケーラビリティを評価します。 アルゴリズムの計算量に関する問題（大きなコレクションに対するネストしたループ、ループ内で繰り返されるデータベースクエリ、上限のないメモリ増加）を特定します。不要な割り当て、キャッシュの機会の見落とし、非同期コンテキストでのブロッキング呼び出しがないか確認します。想定されるデータ量を踏まえ、コードがスケールするかを検討します。

6. 可読性と保守性を確認します。 名前の明確さ、関数の長さ、コードの重複（DRY 原則への違反）、プロジェクトのスタイルガイドへの準拠を評価します。公開関数に docstring または型注釈があることを確認します。マジックナンバーが名前付き定数に置き換えられていること、複雑なロジックに説明コメントが付いていることを確認します。

レビューチェックリスト

エージェントは、以下の各カテゴリに照らしてすべての変更を評価します。

カテゴリ	確認する項目
バグ	null 参照、オフバイワン、ロジックエラー、未処理の例外
セキュリティ	インジェクション、XSS、ハードコードされた秘密情報、認証の欠落、安全でない依存関係
パフォーマンス	O(n²) のループ、N+1 クエリ、不要な割り当て、ブロッキング I/O
可読性	不明瞭な名前、長い関数、ドキュメントの欠落、一貫性のない書式
DRY	コピー＆ペーストされたコードブロック、抽出すべき重複ロジック
エラー処理	握りつぶされた例外、リトライの欠落、不明瞭なエラーメッセージ
テスト	新しいロジックのテスト不足、既存テストの破損、エッジケースの未テスト

使い方

次の入力を 1 つ以上指定してください。

• ファイルパス — ファイル全体をレビューする単一のソースファイルです。
• ディレクトリパス — エージェントがディレクトリ内のすべてのソースファイルをレビューします。
• プルリクエストの URL — 例：https://github.com/user/repo/pull/42。エージェントが差分を取得し、コンテキスト内で変更行のみをレビューします。
• 差分またはパッチのテキスト — 統一形式の差分をそのまま貼り付けたものです。
• 重点領域（任意） — 例：「セキュリティに重点を置く」または「パフォーマンスのみ確認する」のように、レビュー範囲を絞ります。

例

例 1 — Python 関数のレビュー

次のファイル src/auth.py があるとします。

import hashlib

def authenticate(username, password, db):
    query = f"SELECT password_hash FROM users WHERE username = '{username}'"
    row = db.execute(query).fetchone()
    if row is None:
        return False
    stored_hash = row[0]
    input_hash = hashlib.md5(password.encode()).hexdigest()
    return input_hash == stored_hash

エージェントは次のレビューを作成します。

## Review: src/auth.py — authenticate()

### Critical — SQL Injection (line 4)
The query uses f-string interpolation with `username` directly in the SQL
string. An attacker can pass `' OR '1'='1` as the username to bypass
authentication entirely.

**Fix:** Use parameterized queries.
- row = db.execute(query).fetchone()
+ row = db.execute(
+     "SELECT password_hash FROM users WHERE username = ?", (username,)
+ ).fetchone()

### Critical — Weak Hashing Algorithm (line 9)
MD5 is cryptographically broken and unsuitable for password hashing. It is
vulnerable to rainbow table attacks and can be brute-forced in seconds on
modern hardware.

**Fix:** Use bcrypt or argon2 with a per-user salt.
- input_hash = hashlib.md5(password.encode()).hexdigest()
+ import bcrypt
+ return bcrypt.checkpw(password.encode(), stored_hash.encode())

### Warning — Timing Attack (line 10)
Direct string comparison of hashes with `==` leaks information through
timing differences. Use a constant-time comparison function.

**Fix:**
- return input_hash == stored_hash
+ import hmac
+ return hmac.compare_digest(input_hash, stored_hash)

### Info — Missing Type Annotations
Adding type hints improves readability and enables static analysis:
  def authenticate(username: str, password: str, db: Connection) -> bool:

**Summary:** 2 critical, 1 warning, 1 info. This function must not be
deployed until the SQL injection and hashing issues are resolved.

例 2 — プルリクエストの差分のレビュー

src/api/orders.js の PR 差分があるとします。

@@ -12,6 +12,20 @@ const express = require("express");
 const router = express.Router();

+router.get("/orders", async (req, res) => {
+  const userId = req.query.userId;
+  const orders = await db.query("SELECT * FROM orders WHERE user_id = $1", [userId]);
+  const enriched = [];
+  for (const order of orders.rows) {
+    const items = await db.query("SELECT * FROM order_items WHERE order_id = $1", [order.id]);
+    order.items = items.rows;
+    enriched.push(order);
+  }
+  res.json(enriched);
+});

エージェントは次の内容を作成します。

## Review: src/api/orders.js — GET /orders

### Warning — N+1 Query (lines 18-21)
Each order triggers a separate SELECT for its items. For a user with 200
orders this executes 201 database queries. This will degrade significantly
under load.

**Fix:** Use a single JOIN or a batched IN query:
  const items = await db.query(
    "SELECT * FROM order_items WHERE order_id = ANY($1)",
    [orders.rows.map(o => o.id)]
  );
  // Then group items by order_id in application code.

### Warning — Missing Authorization Check (line 14)
The endpoint reads `userId` from the query string without verifying that
the authenticated user is allowed to view that user's orders. Any user
can read any other user's order history by changing the query parameter.

**Fix:** Validate that `req.user.id === userId` or that the requester
has an admin role before executing the query.

### Info — SELECT * Usage (lines 16, 19)
Selecting all columns returns data the client may not need (e.g.,
internal timestamps, soft-delete flags). Specify only the required columns
to reduce payload size and avoid leaking internal fields.

**Summary:** 0 critical, 2 warning, 1 info.

ベストプラクティス

• ファイルだけでなく、差分をレビューします。 変更された行とその直近のコンテキストに焦点を当てます。新しい変更と関係しない限り、既存の問題へのコメントは避けます。
• 重大度を明確に分類します。 Critical／Warning／Info のレベルを使用し、マージ前に修正が必要な点と提案事項を作成者が把握できるようにします。
• 曖昧な批判ではなく、具体的な修正案を提示します。 「改善できるかもしれません」と伝えるのではなく、置き換え用のコードスニペットや具体的なリファクタリング手順を示します。
• 各レビューの範囲を絞ります。 ファイルに多数の問題がある場合は、影響の大きい上位 5〜7 件を優先します。作成者を圧倒すると、何も修正されない可能性が高まります。
• 良いパターンにも言及します。 作成者が特にすっきりした抽象化を行った場合や、エッジケースに適切に対応した場合は、その点を指摘します。肯定的なフィードバックは、良い習慣を定着させます。
• コードと併せてテストも確認します。 新しいロジックにテストがない場合は、その点を指摘します。テストがある場合は、正常系だけでなく、変更された動作も実際に検証していることを確認します。

エッジケース

• 生成コードまたはベンダー提供コード： コードジェネレーター、プロトコルバッファーコンパイラー、またはベンダー提供の依存関係によって生成されたファイルは、通常、レビュー対象から除外します。エージェントは、明示的に指示されない限り、一般的な生成コードのパターンに一致するファイルをスキップします。
• 大規模な差分（>1000 行）： 非常に大きなプルリクエストを徹底的にレビューするのは困難です。エージェントは作成者に警告して PR の分割を提案し、リスクが最も高いファイルから確認します。
• 言語固有の慣用表現： ある言語では慣用的なパターン（例：Go の明示的なエラー返却）が、別の言語ではコードの問題に見えることがあります。エージェントは検出した言語に応じて判断基準を調整します。
• コンテキストが不完全： リポジトリ全体にアクセスできずに差分をレビューする場合、エージェントは型定義、設定、上流の呼び出し元を確認できないことがあります。その場合は、前提を明記します。
• スタイルのみの変更： PR に書式設定や名前変更のみが含まれる場合、エージェントは意味上の違いがないことを確認し、完全なレポートではなく短い承認を作成します。