レビュー対象の規模は？
│
├─ 大規模（10+ファイル、500+行）──→ ✅ サブエージェント並列レビュー
│
├─ 中規模（4-9ファイル、100-500行）─→ ✅ 直接レビュー（全観点）
│
├─ 小規模（1-3ファイル、100行以下）─→ ✅ 直接レビュー（軽量）
│
├─ 特定観点のみ ───────────────────→ ✅ 該当観点のみレビュー
│
└─ PoC・プロトタイプ ──────────────→ ❌ スキップ可

┌──────────────────────────────────────────────────────────────┐
│ 1. 準備フェーズ                                              │
│    └── レビュー対象のスコープ確認                            │
├──────────────────────────────────────────────────────────────┤
│ 2. 並列レビューフェーズ（サブエージェント起動）              │
│    ├── Security Reviewer   → セキュリティ観点                │
│    ├── Architecture Reviewer → アーキテクチャ観点            │
│    ├── Test Reviewer       → テスト観点                      │
│    └── Performance Reviewer → パフォーマンス観点             │
├──────────────────────────────────────────────────────────────┤
│ 3. 統合フェーズ                                              │
│    └── 結果を統合し、優先順位付け                            │
├──────────────────────────────────────────────────────────────┤
│ 4. フィードバックフェーズ                                    │
│    └── Must / Should / Nice to have で整理して出力           │
└──────────────────────────────────────────────────────────────┘

    ┌─────────────────────────────────────────────────────────────┐
    │                                                             │
    ▼                                                             │
┌────────┐   ┌────────┐   ┌────────┐   ┌────────┐   ┌────────┐  │
│準備    │──→│第一印象│──→│詳細    │──→│コンテ  │──→│フィード│  │
│        │   │        │   │レビュー│   │キスト  │   │バック  │  │
└────────┘   └────────┘   └────────┘   └────────┘   └────────┘  │
                                                        │        │
                                                        ▼        │
                                                   ┌────────┐   │
                                                   │承認判断│───┘
                                                   └────────┘

## [優先度] タイトル

### 現状
[問題のあるコード]

### 問題点
[なぜ問題なのか]

### 修正案
[推奨する修正方法]

### 理由
[修正のメリット]

## [Must] SQLインジェクションの脆弱性

### 現状
query = f"SELECT * FROM users WHERE email = '{email}'"

### 問題点
ユーザー入力を直接SQL文に埋め込んでおり、SQLインジェクション攻撃の危険性があります。

### 修正案
user = db.query(User).filter(User.email == email).first()

### 理由
ORMを使用することでセキュリティリスクを排除し、型安全性も向上します。

## [Good] エラーハンドリングが素晴らしい

具体的な例外を捕捉し、適切なログを出力し、
ユーザーにわかりやすいエラーメッセージを返している点が良いです。
このパターンを他の箇所でも参考にさせてください。

# ❌ Bad: Routerにビジネスロジック
@router.post("/users")
async def create_user(data: UserCreate):
    if not data.email or "@" not in data.email:
        raise HTTPException(400, "Invalid email")
    return await db.create(data)

# ✅ Good: Service層に委譲
@router.post("/users")
async def create_user(
    data: UserCreate,
    service: UserService = Depends(get_user_service)
):
    return await service.create_user(data)

# ✅ 外部キーはINTEGER + ON DELETE CASCADE
user_id = Column(Integer, ForeignKey("users.id", ondelete="CASCADE"))

# ❌ user_uuidを外部キーに使用しない

# ✅ 完全な型ヒント
def get_user_by_id(self, user_id: int) -> Optional[User]:
    return self.repository.get(user_id)

# ❌ Anyの使用は避ける

// ✅ Good: 明確な型定義
interface User {
  id: number;
  email: string;
  name: string;
}

function getUser(id: number): Promise<User> { ... }

// ❌ Bad: anyの使用
function getUser(id: number): Promise<any> { ... }

// ✅ Good: 適切なエラーハンドリング
async function fetchUser(id: number): Promise<User> {
  try {
    const response = await fetch(`/api/users/${id}`);
    if (!response.ok) {
      throw new Error(`HTTP error! status: ${response.status}`);
    }
    return await response.json();
  } catch (error) {
    console.error('Failed to fetch user:', error);
    throw error;
  }
}