コンポーネント分離設計タスク

あなたはReact/Next.js App Routerのシニアアーキテクトです。以下の画面仕様・要件を分析し、コンポーネント分離設計を行ってください。

インプット情報

画面名

{画面名を記載}

画面の目的

{この画面が達成すべきビジネス目的を1-3文で記載}

ワイヤーフレーム/画面構成

{ASCII図、Figmaリンク、または画面構成の説明}

例：
┌─────────────────────────────────────────┐
│  Header（ロゴ、ナビ、ユーザーメニュー）    │
├───────────┬─────────────────────────────┤
│           │  パンくずリスト              │
│  Sidebar  ├─────────────────────────────┤
│  (メニュー) │  検索バー + フィルター       │
│           ├─────────────────────────────┤
│           │  データテーブル              │
│           │  （ページネーション付き）     │
├───────────┴─────────────────────────────┤
│  Footer                                 │
└─────────────────────────────────────────┘

機能要件

{機能1の説明}
{機能2の説明}
{機能3の説明}

データ要件

データ	ソース	更新頻度
{データ名}	{API/DB/静的}	{リアルタイム/ページロード時/ユーザー操作時}

ユーザーインタラクション

操作	トリガー	期待する挙動
{操作名}	{クリック/入力/等}	{結果}

非機能要件（該当するものを選択）

SEO対応必須
初期表示速度重視
リアルタイム更新
オフライン対応
アクセシビリティ（WCAG 2.1 AA）

既存コンポーネント（再利用可能なもの）

コンポーネント名	カテゴリ	配置先
{既存コンポーネント}	{UI/Form/等}	{パス}

API仕様（該当する場合）

エンドポイント	メソッド	用途
{endpoint}	{GET/POST/等}	{説明}

出力指示

以下の順序で分析・出力を行ってください。

Step 1: コンポーネント候補の洗い出し

画面構成から識別できるすべてのコンポーネント候補を列挙してください。

出力フォーマット:

## コンポーネント候補一覧

| # | コンポーネント名 | 責務概要 | 再利用性 | インタラクティブ |
|---|-----------------|----------|----------|-----------------|
| 1 | {Name}          | {責務}   | {高/中/低} | {あり/なし}     |

Step 2: 6カテゴリ分類

各コンポーネントを以下の判定基準で分類してください。

判定フロー:

ルーティング対応か？ → Route Components
shadcn/uiに存在するか？ → UI Components
フォーム入力専用か？ → Form Components
レイアウト・構造のみか？ → Layout Components
ビジネスロジックを含むか？ → Feature Components
アプリ全体で再利用するか？ → Shared Components

出力フォーマット:

## コンポーネント分類結果

| コンポーネント名 | カテゴリ | 配置先 | Server/Client | 分類理由 |
|-----------------|----------|--------|---------------|----------|
| {Name}          | {カテゴリ} | {パス} | {Server/Client} | {理由} |

Step 3: 依存関係マップ

コンポーネント間の依存関係を明示してください。

出力フォーマット:

flowchart TD
    subgraph Route ["Route Components"]
        Page[page.tsx]
    end
    subgraph Feature ["Feature Components"]
        F1[FeatureComponent]
    end
    subgraph Shared ["Shared Components"]
        S1[SharedComponent]
    end
    subgraph UI ["UI Components"]
        U1[Button]
    end
    
    Page --> F1
    F1 --> S1
    F1 --> U1

Step 4: 状態管理設計

画面全体の状態管理戦略を決定してください。

出力フォーマット:

## 状態管理マップ

| 状態 | スコープ | 管理方法 | 配置コンポーネント |
|------|----------|----------|-------------------|
| {状態名} | {ローカル/URL/グローバル} | {useState/nuqs/Zustand/TanStack Query} | {コンポーネント名} |

Step 5: 6カテゴリ別コンポーネント生成プロンプト出力

分類結果に基づき、各カテゴリのコンポーネントに対して整形済みの生成プロンプトを出力してください。

重要な出力ルール:

該当コンポーネントが存在するカテゴリのみ出力
各プロンプトは独立して使用可能な完全な形式
{}のプレースホルダーは具体的な値に置換済み
1カテゴリに複数コンポーネントがある場合、それぞれ個別のプロンプトを出力

出力テンプレート

UI Components（該当する場合）

# UI Component生成依頼

## コンポーネント情報
- **名前**: {具体的なコンポーネント名}
- **配置先**: `components/ui/{component-name}.tsx`
- **基本境界**: Client Component

## 要件
### 機能概要
{分析結果から導出した具体的な説明}

### Variants
| variant名 | 説明 | スタイル概要 |
|-----------|------|-------------|
| {variant} | {説明} | {スタイル} |

### Sizes
| size名 | 説明 |
|--------|------|
| {size} | {説明} |

## 制約条件
- [ ] shadcn/uiの既存コンポーネントを確認し、存在する場合は拡張のみ行う
- [ ] ビジネスロジックを含めない
- [ ] CVA（class-variance-authority）でvariantsを定義
- [ ] forwardRefでref転送に対応
- [ ] aria属性を適切に設定

## 出力要求
1. コンポーネント実装（.tsx）
2. 型定義（Props Interface）
3. Storybook（.stories.tsx）
4. 使用例コメント

## 参考：既存のshadcn/uiコンポーネント
{関連する既存コンポーネント}

Form Components（該当する場合）

# Form Component生成依頼

## コンポーネント情報
- **名前**: {具体的なコンポーネント名}
- **配置先**: `components/forms/{component-name}.tsx`
- **基本境界**: Client Component（'use client'必須）

## 要件
### 入力仕様
| プロパティ | 型 | 必須 | 説明 |
|-----------|-----|------|------|
| {prop}    | {type} | {✅/❌} | {説明} |

### バリデーションルール
| ルール | 条件 | エラーメッセージ |
|--------|------|-----------------|
| {rule} | {condition} | {message} |

### 状態
- [x] disabled
- [x] loading
- [x] error表示
- [x] ヒントテキスト

## 制約条件
- [ ] Zodスキーマを定義
- [ ] React Hook FormのController/registerと連携可能な設計
- [ ] aria-invalid, aria-describedbyでアクセシビリティ対応
- [ ] エラーメッセージのID連携

## 出力要求
1. コンポーネント実装（.tsx）
2. Zodスキーマ定義
3. Props Interface
4. Storybook（default, error, disabled, loading状態）
5. React Hook Formとの連携例

Layout Components（該当する場合）

# Layout Component生成依頼

## コンポーネント情報
- **名前**: {具体的なコンポーネント名}
- **配置先**: `components/layouts/{component-name}.tsx`
- **基本境界**: Server Component

## 要件
### レイアウト構造

{分析結果から導出したASCII図}


### Slots
| slot名 | 説明 | 必須 |
|--------|------|------|
| {slot} | {説明} | {✅/❌} |

### レスポンシブ対応
| ブレークポイント | 挙動 |
|-----------------|------|
| mobile (<768px) | {挙動} |
| tablet          | {挙動} |
| desktop         | {挙動} |

## 制約条件
- [ ] Server Componentとして実装
- [ ] childrenでClient Componentを受け入れ可能
- [ ] Tailwind CSSでレスポンシブ対応
- [ ] Suspense境界の配置箇所を明示

## 出力要求
1. コンポーネント実装（.tsx）
2. Props Interface
3. Storybook
4. 使用例

Shared Components（該当する場合）

# Shared Component生成依頼

## コンポーネント情報
- **名前**: {具体的なコンポーネント名}
- **配置先**: `components/shared/{component-name}.tsx`
- **基本境界**: {Server/Client}

## 要件
### 機能概要
{分析結果から導出した説明}

### Props設計
| プロパティ | 型 | 必須 | デフォルト | 説明 |
|-----------|-----|------|-----------|------|
| {prop}    | {type} | {✅/❌} | {default} | {説明} |

### 使用箇所
1. {画面/コンポーネント}: {文脈}

## 制約条件
- [ ] 特定のfeatureに依存しない
- [ ] 必要なデータはすべてPropsで受け取る
- [ ] 軽量なロジックのみ
- [ ] APIコール禁止

## 出力要求
1. コンポーネント実装（.tsx）
2. Props Interface
3. Storybook
4. 単体テスト

## Server/Client判定理由
{理由}

Feature Components（該当する場合）

# Feature Component生成依頼

## コンポーネント情報
- **名前**: {具体的なコンポーネント名}
- **配置先**: `features/{feature-name}/components/{component-name}.tsx`
- **関連ファイル**:
  - hooks: `features/{feature-name}/hooks/use-{hook}.ts`
  - actions: `features/{feature-name}/actions/{action}.ts`
  - types: `features/{feature-name}/types.ts`

## 要件
### 機能概要
{分析結果から導出したビジネス機能の説明}

### データ要件
| データ | ソース | 取得方法 |
|--------|--------|----------|
| {data} | {source} | {method} |

### 状態管理
| 状態 | スコープ | 管理方法 |
|------|----------|----------|
| {state} | {scope} | {method} |

### API連携
| エンドポイント | メソッド | 用途 |
|---------------|----------|------|
| {endpoint}    | {method} | {purpose} |

### イベント
| イベント | トリガー | 処理内容 |
|---------|----------|----------|
| {event} | {trigger} | {action} |

## 制約条件
- [ ] Server ActionsでMutation実装
- [ ] TanStack QueryでQuery実装
- [ ] エラーハンドリング実装
- [ ] Foundation層コンポーネントを活用

## 出力要求
1. コンポーネント実装（.tsx）
2. カスタムフック
3. Server Actions
4. 型定義
5. Zodスキーマ（フォームの場合）
6. Storybook（MSWモック）
7. 単体テスト

## エラーハンドリング方針
| エラー種別 | 表示方法 |
|-----------|----------|
| バリデーション | フィールド直下 |
| API 4xx | Toast通知 |
| API 5xx | エラーバウンダリ |

Route Components（該当する場合）

# Route Component生成依頼

## コンポーネント情報
- **パス**: `app/{route-path}/`
- **ファイル構成**:
  - `page.tsx`
  - `layout.tsx`（{必要/不要}）
  - `loading.tsx`
  - `error.tsx`
- **基本境界**: Server Component

## 要件
### ルート情報
| 項目 | 値 |
|------|-----|
| URLパス | `/{path}` |
| 動的セグメント | {あれば記載} |
| 認証要否 | {要/不要} |

### データフェッチ
| データ | 取得方法 | キャッシュ戦略 |
|--------|----------|---------------|
| {data} | {method} | {strategy} |

### SEO/Metadata
| 項目 | 値 |
|------|-----|
| title | {title} |
| description | {description} |

### 子コンポーネント配置
| コンポーネント | カテゴリ | Suspense |
|---------------|----------|----------|
| {component}   | {category} | {✅/❌} |

## 制約条件
- [ ] Server Componentとして実装
- [ ] async/awaitで直接データフェッチ
- [ ] Suspense境界を適切に配置
- [ ] generateMetadataでメタデータ動的生成

## 出力要求
1. page.tsx
2. layout.tsx（必要な場合）
3. loading.tsx（Skeleton UI）
4. error.tsx
5. generateMetadata関数

## Suspense設計

{具体的なSuspense境界の配置図}

最終チェックリスト

出力完了後、以下を確認してください：

すべてのコンポーネントが6カテゴリのいずれかに分類されている
Server/Client境界が明確に決定されている
状態管理戦略が一貫している
依存関係に循環がない
各生成プロンプトが独立して実行可能