AIに設計を書かせるだけで、理解負債と実装漏れが激減した話

## プロンプト（コピーして使用）

このプロジェクトで新機能を開発するためのデザインドキュメントを生成してください。既存の実装やドキュメントと同じ思想・用語・構成で設計すること。

【必須の事前読み込み】
- **アーキテクチャ・規約の把握**: プロジェクト内の次のようなドキュメントを探して読み、レイヤー構成・ディレクトリルール・コーディング規約を把握すること。
  - ルートの README.md、CONTRIBUTING.md、ARCHITECTURE.md、docs/ 配下
  - エージェント用のルール（CLAUDE.md、.cursorrules、docs/development.md など）
  - レビュー観点をまとめたファイル（.claude/review.md、.github/pull_request_template.md など）
- **既存の設計・PRスタイルの把握**: 既存のデザイン書・PR説明・設計サンプルがあれば参照し、セクション構成・トーン・用語に合わせること。
  - 例: docs/design/, .local/pr/, design/, 過去のPR説明のテンプレート など

【入力情報】
以下のいずれかを渡してください：
- 機能の概要・背景・要件（箇条書きや短文で可）
- チケットやPRDの要約
- 「〇〇のような機能を追加したい」という説明

【出力形式】
日本語で、以下のセクションを含む Markdown のデザインドキュメントを出力すること。該当しないセクションは「該当なし」または「なし」と簡潔に記載すること。プロジェクトにフロントエンドやDBがない場合は、そのセクションは省略または「該当なし」でよい。

## 必須セクション

1. **概要**
   機能を2〜3文で説明し、ビジネス上の目的を書く。

2. **背景・課題**
   なぜこの機能が必要か。現状の不足や問題を具体的に書く。

3. **目的・スコープ**
   本機能で「やること」の範囲を明確にする。スコープ外も書く（任意だが推奨）。

4. **修正後／実装後の動作**
   ユーザーまたは利用者から見た振る舞い（画面・API・CLI 等の利用イメージ）。Before/After があるとよい。

5. **実装方針**
   技術的なアプローチの要約。複雑なフローがあれば mermaid の sequence 図で記述する。

6. **サーバー／API 設計**（サーバー側やAPIを扱う場合）
   プロジェクトのアーキテクチャドキュメントで定義されているレイヤー・用語に従い、以下を書く：
   - **レイヤー配置**: どのレイヤー（例: Controller/Handler、Service/UseCase、Repository/DataAccess など、プロジェクトの用語に合わせる）をどのディレクトリ・モジュールに置くか
   - **委譲方針**: どの処理をどのレイヤーに置くか（プロジェクトの責務の分け方に準拠）
   - **認可・認証**: 必要な場合、どのように行うか（プロジェクトの仕組みに合わせる）
   - **新規・変更するAPI**: メソッド・パス・役割・リクエスト/レスポンスの概要・想定するエラーケース
   - プロジェクトで定められているURL・ルーティングのルール（例: ハイフン区切り）に従うこと

7. **フロントエンド／クライアント設計**（フロントエンドやクライアントアプリを扱う場合）
   プロジェクトのルーティング・状態管理・コンポーネント構成の規約に従い、以下を書く：
   - **配置**: どのルート・ディレクトリ配下に置くか。URL・パスのルール
   - **ページ／画面構成**: どのコンポーネントでデータ取得・副作用（API呼び出し等）を行うか。プロジェクトの慣例に合わせる
   - **共有モジュール**: 既存の domains/、hooks/、lib/ 等の利用・追加の要否
   - **フォーム・バリデーション**: フォームやスキーマの置き場所・分離のルール（プロジェクトの慣例に合わせる）
   - **多言語・アクセシビリティ**: プロジェクトで求められている場合はその方針
   - **UIコンポーネント**: 共通コンポーネントの利用ルール（プロジェクトで定められていればそれに従う）

8. **データベース・スキーマ変更**（永続化層やDBを扱う場合）
   変更がない場合は「なし」。ある場合は以下を書く：
   - 使用しているORM・マイグレーションの種類に合わせて、モデル/テーブル/カラム/リレーションの追加・変更を記述
   - カラム・テーブル削除など後方互換のない変更がある場合、プロジェクトの「安全なデプロイ手順」に言及する（存在すれば）
   - 必要に応じて mermaid の ER 図で周辺モデルとの関係を記述
   - 命名規則（テーブル名・カラム名・ID の採番ルールなど）はプロジェクトの規約に合わせる

9. **変更予定ファイル（主要なもの）**
   新規・変更が見込まれるファイルをパスで列挙し、それぞれ1行で役割を書く。

10. **テスト方針**
    プロジェクトのテスト戦略（単体・結合・E2E の役割、配置、ツール）に合わせて書く：
    - どの層・どのシナリオをどの種類のテストでカバーするか
    - プロジェクトで定められているアサーション・モックのルールがあればそれに言及

11. **レビュー観点**
    実装時にレビュアーに特に見てほしい点（レイヤー責務、認可、破壊的変更、セキュリティ、パフォーマンスなど）。

【制約】
- 既存の実装・ドキュメントと同じ思想で設計すること。プロジェクトのアーキテクチャ・ディレクトリルール・命名・テスト方針を逸脱しないこと。
- 出力は日本語とし、技術用語は**このプロジェクトで使われている用語**（レイヤー名、フレームワーク名、ディレクトリ名など）に合わせること。