Findyの爆速開発を支えるAIフレンドリーなIssue生成カスタムコマンド

こんにちは。

ファインディ株式会社でテックリードマネージャーをやらせてもらってる戸田です。

現在のソフトウェア開発の世界は、生成AIの登場により大きな転換点を迎えています。

GitHub CopilotやClaude Codeなど生成AIを活用した開発支援ツールが次々と登場し、開発者の日常的なワークフローに組み込まれつつあります。

2025年はSpec Driven DevelopmentやAI-DLCなどといった新しい開発手法が注目を集める年になりました。

ファインディでも新しい開発手法への取り組みを進めており、その一環として要件定義、設計、タスク分解、Issue作成までのフローを自動化しました。

そこで今回は、自動化したフローの内容と仕組みを実現したカスタムコマンドについて紹介します。

それでは見ていきましょう！

背景と課題
既存の開発手法の検討
解決策: AIフレンドリーなIssue
カスタムコマンドの仕組み
カスタムコマンド作成のコツ
まとめ
採用情報

背景と課題

機能追加の要件から、設計、タスク分解、Issue作成までを行う必要があります。これらを生成AIに任せたいところですが、必要とされる事前知識が多くハードルが高いという課題がありました。

システム全体を把握できていないと適切な設計が難しいケースもあります。また、生成AIに対して効果的な依頼を作成するには明確で簡潔なステップ構造にすることが重要です。

つまり明確な要件を定義して、生成AIが正しい方法と手順を理解して実行できるように、設計図や指示書をAIフレンドリーな形で用意する必要があったのです。

既存の開発手法の検討

2025年はSpec Driven DevelopmentやKiroといった新しい開発手法が注目を集めました。これらは要件定義から実装まで一貫した自動化を目指すアプローチです。

私たちもこれらの手法を検討しましたが、タスク分解とPull requestの粒度に対する考え方に課題を感じました。

Spec Driven Developmentでは、システム全体の仕様を詳細に定義してから実装に進みます。これは大規模な機能開発や新規プロジェクトでは有効ですが、仕様の粒度やSpec/Taskの部分が大きくなりがちです。その結果、実装を進めると大きな変更を含むPull requestが作られることになり、コードレビューの負担が増大する傾向があります。

どちらにも利点がありますが、私たちはレビューの品質とチーム全体の開発速度を重視して、タスク分解と粒度に重点を置いたアプローチが必要だと考えました。

解決策: AIフレンドリーなIssue

この課題を解決するため、システムの現状を把握して、必要な要件をタスク分解してIssueに切り出すカスタムコマンドを構築しました。

重要なのは、Pull requestとタスクの粒度を維持しつつ、生成AIが理解しやすく精度の高いIssueを自動生成することです。この一連の流れをカスタムコマンドで自動化しました。

Issueが作成されたら、その内容や手順が正しいのかどうかチェックして、問題なければそのまま生成AIに渡して実装を進めてもらうようになります。

カスタムコマンドの仕組み

概要とフロー

今回紹介するカスタムコマンドは要件とコードベースを元に、要件の明確化、設計、タスク分解、Issue作成までを自動化します。

特徴的なのはインタラクティブな形式を採用している点です。曖昧な部分や不明点があれば、その都度生成AIが質問を投げかけてきます。人間は質問に答えながら生成AIとの対話を通じて要件を明確化していきます。

このプロセスを経て、生成AIが設計を行い、タスク分解を実施し、最終的にGitHubのIssueを自動で作成します。人間が行うのは作成されたIssueのレビューだけです。

Issueのレビューが完了したら、そのIssueをそのまま生成AIに渡して実装を進めてもらいます。Pull requestの粒度を意識した形でIssueが作成されるため、後続のコードレビューの負担も軽減されます。

このカスタムコマンドの全体フローは次のようなイメージです。

全体のシーケンス図

これら全てのフローを実行するために必要なカスタムコマンドやSkill、Sub Agentを社内Pluginとして開発組織全体に展開しています。

ステップ1: 要件の理解

まずは実現したい要件を生成AIが理解するところから始めます。このステップのフローは次のようなイメージです。

要件理解のシーケンス図

カスタムコマンドを実行して実現したい要件をパラメータ経由で伝えます。この段階では要件がある程度曖昧でも問題ありません。

❯ /plugin:feature-breakdown 複数ユーザーの新規登録を一括で実行する機能を追加したい 

⏺ I'll help you break down the bulk user registration feature into implementation tasks and create GitHub issues. Let me start by creating a TODO list for all phases.

⏺ Phase 1: 要件の理解

  初期リクエスト: 複数ユーザーの新規登録を一括で実行する機能を追加したい

要件の中に曖昧な内容があれば生成AIが確認のための質問を投げかけてきます。対話を通じて徐々に要件を明確にしていきます。

今回は追加したい機能を具体的にするために生成AIから幾つかの質問が投げかけられました。解答を選択式にすることで、スムーズに要件を明確化できます。

  この機能について、以下の点を明確にさせてください。

────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
←  ☐ 対象ユーザー  ☐ 入力形式  ☐ 認証フロー  ☐ エラー処理  ✔ Submit  →

この一括登録機能は誰が使うことを想定していますか？

❯ 1. 管理者（AdminUser）のみが使用
     管理画面から管理者が実行する機能として実装。一般ユーザーは使用できない。
  2. 組織の管理者（Org内の特定ロール）
     組織内の権限を持つユーザーが自組織のメンバーを一括登録できる。
  3. 一般ユーザーも使用可能
     全ユーザーが利用可能な機能として実装。
  4. Type something.

解答を選択式にするためにClaude CodeのToolの AskUserQuestion を利用するようにプロンプトに明記すると便利です。 AskUserQuestion は情報を収集または曖昧さを明確にするために、ユーザーに複数選択肢の質問をします。

一通りの質問に回答すると生成AIが要件を整理してくれます。ここまでの選択で要件を理解することができました。認識にズレがなければこのまま次のステップに進みます。何かしらに誤りがあった場合、この段階で軌道修正もできます。

⏺ User answered Claude's questions:
  ⎿  · この一括登録機能は誰が使うことを想定していますか？ → 管理者（AdminUser）のみが使用
     · ユーザーデータの入力形式はどのようなものを想定していますか？ → CSV/TSVファイルのアップロード
     · 登録時のユーザー認証フローはどうしますか？ → 確認メール送信（既存フロー準拠）
     · 登録処理中のエラーハンドリングはどうしますか？ → 部分成功を許可

⏺ ありがとうございます。要件を整理します。

⏺ 理解した要件

  機能: 複数ユーザーの新規登録を一括で実行する機能

  要件の詳細:
  - 対象ユーザー: 管理者（AdminUser）のみが使用可能
  - 入力形式: CSV/TSVファイルのアップロード（email, name, org_id等のカラム）
  - 認証フロー: 確認メール送信（既存の単一ユーザー登録フローと同じ）
  - エラー処理: 部分成功を許可（成功したユーザーは登録、失敗したユーザーはエラーレポートで返す）

ステップ2: コードベースの探索

次に、要件を実現させるために既存のコードベースがどうなっているのかを理解する必要があります。

次のようなフローでコードベースを探索していきます。

コード探索のシーケンス図

既存のコードベースを理解するため、Claude Codeの公式Pluginであるfeature-dev にある code-explorerエージェントを活用します。このエージェントはプロジェクトの構造やパターンを自動的に分析して実装に必要な情報を収集します。feature-devプラグインをインストールするだけでcode-explorerエージェントを利用できるようになります。

要件を分割して複数のcode-explorerエージェントを並列で起動します。各エージェントが特定の観点からコードベースを探索して必要な情報を収集します。

⏺ Phase 2: コードベースの探索

  既存のコードとパターンを理解するため、複数のcode-explorerエージェントを並列で起動します。

  Running 3 feature-dev:code-explorer agents… (ctrl+o to expand)
   ├─ Explore user registration architecture · 12 tool uses · 29.1k tokens
   │  ⎿  Search: **/models/admin*.py
   ├─ Explore admin API patterns · 12 tool uses · 27.6k tokens
   │  ⎿  Read: main.py
   └─ Explore CSV and file handling · 10 tool uses · 17.0k tokens
      ⎿  Search: **/api/routes/**/*.py
     ctrl+b to run in background

⏺ Excellent! Now let me read the critical files identified by the code-explorer agents to deepen my understanding.

⏺ Read(src/api/routes/user/users.py)
  ⎿  Read 60 lines

⏺ Read(src/api/routes/user/users.py)
  ⎿  Read 60 lines

⏺ Read(src/api/routes/admin/orgs.py)
  ⎿  Read 70 lines

⏺ Read(src/api/routes/user/orgs/teams.py)
  ⎿  Read 60 lines

⏺ Read(src/services/email/email_service.py)
  ⎿  Read 132 lines

今回は複数のユーザー登録を一括で実行する機能を追加したいので、既存のユーザー登録処理や管理者用APIのパターン、CSVファイルの取り扱い方法などを中心にコードベースを探索しているようです。

要件を実現させるために必要なコードベースの情報が揃ったようなので、次のステップに進みます。

ステップ3: 要件の明確化

次は入力した要件とコードベースの情報を元に、要件を更に明確化していきます。

既存コードと要件を精査して曖昧な内容が残っていれば、追加で質問が投げかけられます。対話を繰り返すことで実装に必要な情報を揃えていきます。

⏺ Phase 3: 明確化のための質問

  コードベースの調査結果から、以下の点について確認させてください。


────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
 ☐ CSV Columns 

CSVファイルにはどのような情報を含めますか？

❯ 1. 必須情報：メール、名前、ロール (Recommended)
     email, first_name, last_name, roleの4カラム。GitHubアカウントはオプション
  2. 必須情報：メールと名前のみ
     email, first_name, last_nameの3カラム。ロールはデフォルトでmember
  3. メールアドレスのみ
     emailの1カラムだけ。他の情報は後から追加
  4. Type something.

このステップではエラーハンドリングやエッジケースなど、細かい点についての要件を明確化します。

⏺ Phase 3: 明確化のための質問

  コードベースの調査結果から、以下の点について確認させてください。
                                                                                                 
⏺ User answered Claude's questions:
  ⎿  · CSVファイルにはどのような情報を含めますか？ → 必須情報：メール、名前、ロール (Recommended)


────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
 ☐ Duplicate Emails 

既存ユーザー（同じメールアドレス）がいた場合、どう処理しますか？

❯ 1. スキップして結果に記録 (Recommended)
     既存ユーザーは登録せず、skipped_emailsリストとして返す
  2. エラーとして返す
     既存ユーザーがいたらエラー情報を返し、その行を登録しない
  3. 情報を更新する
     既存ユーザーの名前やロールをCSVの値で更新
  4. Type something.

ここまでで要件と既存コードの変更内容が明確化されました。次のステップで設計に進みます。

ステップ4: 設計

設計フェーズでは、Claude Codeの公式Pluginであるfeature-dev にある code-architectエージェントを活用します。

このエージェントは設計方針を提案してくれます。開発者は提案された選択肢の中からプロジェクトに最適な実装方針を選ぶことができます。この選択により実装の方向性が確定します。

設計に関するフローは次のようなイメージになります。

設計のシーケンス図

今回は最小構成、クリーンアーキテクチャ、実用的バランスの3つのアプローチでcode-architectエージェントを並行稼働して最適な設計方針を提案してもらいました。

⏺ Phase 4: アーキテクチャ設計

  それでは、3つの異なるアプローチでアーキテクチャ設計を行います。

⏺ Running 3 feature-dev:code-architect agents… (ctrl+o to expand)
   ├─ Design minimal change approach · 3 tool uses · 10.1k tokens
   │  ⎿  Search: send_invite_user_email
   ├─ Design clean architecture approach · 4 tool uses · 10.1k tokens
   │  ⎿  Search: src/services/**/*.py
   └─ Design pragmatic balance approach · 0 tool uses
      ⎿  Initializing…
     ctrl+b to run in background

⏺ 3 feature-dev:code-architect agents finished (ctrl+o to expand)
   ├─ Design minimal change approach · 20 tool uses · 25.2k tokens
   │  ⎿  Done
   ├─ Design clean architecture approach · 26 tool uses · 41.0k tokens
   │  ⎿  Done
   └─ Design pragmatic balance approach · 0 tool uses
      ⎿  Done

⏺ Perfect! Now I have three comprehensive architecture designs. Let me present them to the user for selection.

⏺ 3つのアーキテクチャアプローチが完成しました。それぞれの特徴を整理してご提案します。

  3つのアプローチ比較

  1. 最小変更アプローチ (Minimal Change)

  特徴:
  - CSV処理をルートハンドラに直接実装（約150行の単一ファイル）
  - 既存パターンを最大限活用（teams.pyの部分成功パターン）
  - 新規作成ファイル: 2個（エンドポイント + テスト）

  メリット:
  - 最速で実装可能（2 PR、~650行）
  - シンプルで理解しやすい
  - 既存コードとの整合性が高い

  デメリット:
  - ルートハンドラが長くなる（~150行）
  - CSV処理ロジックの再利用が困難
  - 将来の拡張（Excel対応など）に追加実装が必要

  タスク数: 2個

  ---
  2. クリーンアーキテクチャアプローチ (Clean Architecture)

  特徴:
  - サービス層を導入して責務を分離
    - Parser（CSV解析）
    - Validator（バリデーション）
    - UserImportService（オーケストレーション）
  - 新規作成ファイル: 7個

  メリット:
  - 将来の拡張が容易（Excel, JSON対応）
  - テストが容易（各層を独立してテスト可能）
  - ビジネスロジックの再利用性が高い
  - 保守性が高い

  デメリット:
  - 初期実装に時間がかかる（6 PR、~730行）
  - 抽象化により複雑さが増す
  - シンプルなCSV処理に対してはオーバーエンジニアリングの可能性

  タスク数: 6個

  ---
  3. 実用的バランスアプローチ (Pragmatic Balance)

  特徴:
  - サービス層を導入するが、Parser/Validatorは分離しない
  - UserImportServiceで一元管理
  - 新規作成ファイル: 5個

  メリット:
  - 適度な抽象化で保守性を確保
  - 実装速度とコード品質のバランスが取れている
  - 将来の拡張もある程度対応可能

  デメリット:
  - クリーンアーキテクチャほどの柔軟性はない
  - 最小変更アプローチほどシンプルではない

  タスク数: 5個

  ---


────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
 ☐ Approach 

どの実装アプローチを採用しますか？

  1. 実用的バランス (Recommended)
     開発速度と品質のバランス。サービス層を導入しつつもシンプルさを維持。タスク数: 5個
  2. 最小変更
     最速で実装。ルートハンドラに直接実装。既存パターンを最大限活用。タスク数: 2個
❯ 3. クリーンアーキテクチャ
     保守性と拡張性を重視。Parser/Validatorを分離し、将来の複数フォーマット対応を考慮。タスク数: 6個
  4. Type something.

様々な設計方針ごとにメリット、デメリットなどが提示されます。要件やプロジェクトの方針にもよりますが、今回はクリーンアーキテクチャを選択します。設計方針が決まったので次のタスク分解のステップに進みます。

ステップ5: タスク分解

確定した設計方針を元に実装に必要なタスクを洗い出して分解します。

今回のカスタムコマンドで特に重要なのは、Pull requestやIssueの粒度を考慮することです。今回のカスタムコマンドの調整により、レビューしやすく適切な粒度でマージしやすい最適な粒度に分解してくれます。

Pull requestやIssueの粒度に関するガイドラインはSkillに切り出しています。 Sub AgentやSkillに切り出すことにより、タスク分解の品質を継続的に改善できるだけでなく、カスタムコマンドの一連の流れのコンテキストを適切に管理できるようになります。

今回はクリーンアーキテクチャを選択しており、最初に各種共通処理の作成とリファクタを行い、その後にAPIを追加するというタスクの分け方になっているようです。

⏺ 承知しました。クリーンアーキテクチャアプローチで進めます。

  それでは Phase 5 に進んで、task-breakdown Skillを使ってタスク分解を評価・調整します。

⏺ Skill(task-breakdown)
  ⎿  Successfully loaded skill

⏺ Task Breakdown Skillがロードされました。それでは、Phase 4で得たクリーンアーキテクチャアプローチのタスク分解を評価します。

  code-architectが提案したタスク分解

  以下は、クリーンアーキテクチャアプローチで提案された6つのタスクです：

  Task 1: [Data] ドメインモデルの追加

  - 変更ファイル:
    - CREATE: src/services/user_import/models.py
    - CREATE: src/services/user_import/__init__.py
    - CREATE: tests/services/user_import/test_models.py
  - 概要: ImportRow, ValidationError, CreatedUser, ImportResult モデルを作成
  - 依存関係: なし

  Task 2: [Logic] CSVパーサーの実装

  - 変更ファイル:
    - CREATE: src/services/user_import/parser.py
    - MODIFY: src/services/user_import/__init__.py
    - CREATE: tests/services/user_import/test_parser.py
  - 概要: CSVParserインターフェースとDefaultCSVParserを実装
  - 依存関係: Task 1（ImportRowモデルが必要）

  Task 3: [Logic] バリデーターの実装

  - 変更ファイル:
    - CREATE: src/services/user_import/validator.py
    - MODIFY: src/services/user_import/__init__.py
    - CREATE: tests/services/user_import/test_validator.py
  - 概要: UserDataValidator（ビジネスルール検証）を実装
  - 依存関係: Task 1（ImportRow, ValidationErrorモデルが必要）

  Task 4: [Logic] ユーザーインポートサービスの実装

  - 変更ファイル:
    - CREATE: src/services/user_import/user_import_service.py
    - MODIFY: src/services/user_import/__init__.py
    - CREATE: tests/services/user_import/test_user_import_service.py
  - 概要: UserImportService（オーケストレーション層）とメール連携
  - 依存関係: Task 1, 2, 3（すべてのコンポーネントが必要）

  Task 5: [API] 管理者用一括登録エンドポイント

  - 変更ファイル:
    - CREATE: src/api/routes/admin/user_import.py
    - MODIFY: main.py
    - CREATE: tests/api/routes/admin/test_user_import.py
  - 概要: POST /api/v1/admin/users/import エンドポイントの実装
  - 依存関係: Task 1, 2, 3, 4（サービス層全体が必要）

  ---
  Task Breakdown Skillによる評価

  1. タスクの粒度チェック

  Task 1: ドメインモデル
  - ファイル数: 3個 ✅ (理想的)
  - 行数: ~80行 ✅ (適切)
  - 評価: 適切なサイズ

  Task 2: CSVパーサー
  - ファイル数: 3個 ✅ (理想的)
  - 行数: ~100行 ✅ (適切)
  - 評価: 適切なサイズ

  Task 3: バリデーター
  - ファイル数: 3個 ✅ (理想的)
  - 行数: ~120行 ✅ (適切)
  - 評価: 適切なサイズ

  Task 4: ユーザーインポートサービス
  - ファイル数: 3個 ✅ (理想的)
  - 行数: ~180行 ✅ (適切)
  - 評価: 許容範囲だが、メール連携部分を分離できる可能性あり

  Task 5: APIエンドポイント
  - ファイル数: 3個 ✅ (理想的)
  - 行数: ~100行 ✅ (適切)
  - 評価: 適切なサイズ

  2. 密結合の識別

  ✅ 密結合が適切に保たれているもの:
  - Task 1: モデル定義 + テスト （実装とテストが同一PR）
  - Task 2: Parser実装 + テスト （実装とテストが同一PR）
  - Task 3: Validator実装 + テスト （実装とテストが同一PR）
  - Task 4: Service実装 + テスト （実装とテストが同一PR）
  - Task 5: APIエンドポイント + ルーティング + テスト （API完全性が保たれている）

  ❌ 潜在的な密結合の問題: なし

  3. 独立性の検証

  独立してrevertできるか？
  - Task 1: ✅ 他のタスクに影響なし（モデルのみ）
  - Task 2: ✅ Task 1に依存するが、独立して削除可能
  - Task 3: ✅ Task 1に依存するが、独立して削除可能
  - Task 4: ⚠️ Task 2, 3に依存するため、revert時は順序が重要
  - Task 5: ✅ Task 4に依存するが、独立して削除可能（ルーター登録を削除するだけ）

  各PRマージ後、アプリケーションは正常動作するか？
  - Task 1マージ後: ✅ モデルのみ追加、既存機能に影響なし
  - Task 2マージ後: ✅ パーサーのみ追加、既存機能に影響なし
  - Task 3マージ後: ✅ バリデーターのみ追加、既存機能に影響なし
  - Task 4マージ後: ✅ サービス層のみ追加、APIエンドポイントがないため既存機能に影響なし
  - Task 5マージ後: ✅ 新規エンドポイント追加、既存機能に影響なし

  4. 依存関係の整理

  Task 1 (モデル)
  ├── Task 2 (Parser) ← Task 1に依存
  └── Task 3 (Validator) ← Task 1に依存
      └── Task 4 (Service) ← Task 2, 3に依存
          └── Task 5 (API) ← Task 4に依存

  並列実装可能なタスク:
  - Task 2とTask 3は並列実装可能（どちらもTask 1にのみ依存）

  5. 推奨事項

  現在のタスク分解は非常に良好です。以下の理由から、このまま進めることを推奨します：

  良い点:
  1. ✅ 各タスクのサイズが適切（3-10ファイル、100-200行）
  2. ✅ 実装とテストが密結合として同一PRに含まれている
  3. ✅ 各タスクが独立してrevert可能
  4. ✅ 依存関係が明確で、並列実装の余地もある
  5. ✅ 各PRマージ後もアプリケーションは正常動作する

  最終判断: 現在のタスク分解をそのまま採用

  ---

ここまでで要件を正しい方法と手順で実現するために必要な準備が整いました。最後のステップをこれらを元にIssueを作成していきます。

ステップ6: Issue作成

最後のステップで、分解したタスクを元にGitHubのIssueを自動で作成します。

作成前には確認ステップを踏み、認識がズレていないか最終チェックを行います。問題がなければ、そのままIssueを作成してSub Issueの紐付けとrelationshipの設定まで完了させます。

これにより親Issueと子Issueが適切に構造化された状態で、すぐに実装に取り掛かれるようになります。

GitHubのIssueを作成する処理もSub Agentに切り出しています。Issueを作成するために必要な情報量が多く、すぐにコンテキストが肥大化してしまうからです。そのためIssue作成専用のSub Agentを用意して必要な情報だけ渡してIssueを作成する形にしています。

⏺ Phase 7: GitHub Issueの作成

  github-issue-creator agentを起動してGitHub issueを作成します。

⏺ plugin:github-issue-creator(Create GitHub issues)
  ⎿  Done (25 tool uses · 117.1k tokens · 8m 35s)                                                                                                                                                                                                                                                  

⏺ ✅ Feature Breakdown 完了！

  GitHub Issueの作成が完了しました。以下が作成されたIssueです。

  📋 親Issue

  #1 - Feature: 複数ユーザーの一括登録機能
  https://github.com/Findy/Example/issues/1

  📦 子Issue（実装タスク）

  1. #2 - [Data] ドメインモデルの追加 + テスト
  https://github.com/Findy/Example/issues/2
  依存関係: なし
  2. #3 - [Logic] CSVパーサーの実装 + テスト
  https://github.com/Findy/Example/issues/3
  依存関係: #2
  3. #4 - [Logic] バリデーターの実装 + テスト
  https://github.com/Findy/Example/issues/4
  依存関係: #2
  4. #5 - [Logic] ユーザーインポートサービスの実装 + テスト
  https://github.com/Findy/Example/issues/5
  依存関係: #2, #3, #4
  5. #6 - [API] 管理者用一括登録エンドポイント + テスト
  https://github.com/Findy/Example/issues/6
  依存関係: #5

  ---
  📊 Issue構造

  📋 #1 Feature: 複数ユーザーの一括登録機能
  ├── 📦 #2 [Data] ドメインモデルの追加 + テスト
  │   ├── ⚙️  #3 [Logic] CSVパーサーの実装 + テスト
  │   └── ⚙️  #4 [Logic] バリデーターの実装 + テスト
  │       └── ⚙️  #5 [Logic] ユーザーインポートサービスの実装 + テスト
  │           └── 🔌 #6 [API] 管理者用一括登録エンドポイント + テスト

  ---
  🎯 次のステップ

  1. 実装開始: #2から順番に実装してください
  2. 並列実装可能: #3と#4は#2完了後、並列で実装可能です
  3. 進捗管理: 親Issue #1で全体の進捗を確認できます
  4. PRの作成: 各Issueごとに1つのPRを作成してください

  ---
  📝 設計サマリー

  採用アーキテクチャ: クリーンアーキテクチャ
  - Parser層（CSV解析）
  - Validator層（ビジネスルール検証）
  - Service層（オーケストレーション）
  - API層（HTTPハンドリング）

  主な技術要素:
  - CSVパース: Python標準ライブラリ csv.DictReader
  - バリデーション: Pydantic + カスタムロジック
  - トランザクション: ユーザー単位のコミット
  - メール送信: 既存のEmailService再利用
  - エラー処理: 部分成功パターン

  受入基準:
  - テストカバレッジ90%以上
  - 各PRは3-10ファイル、200-500行の変更
  - すべてのPRは独立してrevert可能

  Feature Breakdown コマンドの全フェーズが完了しました！

これで要件の策定から適切な粒度でのIssue作成までの一連の流れが完了しました。Issueの内容をチームでレビューして、実装を生成AIに任せましょう。適切な粒度でタスクが分解されているので、Pull requestの粒度も適切になり、レビューの負担が大幅に軽減されます。