PRD・設計
PRD・設計の参考。手順は 設計章。事例16件は下の折りたたみ。
セッションの進め方（Plan・検証・記録）は エージェント運用 — 6つの基本 と 運用章 が正本。
docs 配下の PRD
docs/PRD-workflow.md
ツール別（メモ）
Cursor / Claude Code / Codex ごとの PRD 作成の進め方。
| Cursor（IDE） | Claude Code（CLI） | Codex | |
|---|---|---|---|
| 進め方 | Agent / Composer から docs/prd/ へ直接作成・編集 | ターミナルで claude、会話でドラフト作成 | codex CLI / IDE / クラウドタスク |
| 永続ルール | .cursor/rules/ 等 | CLAUDE.md / ~/.claude/CLAUDE.md | AGENTS.md / ~/.codex/AGENTS.md |
| コンテキスト | @docs/PRD-workflow.md や関連ファイルを添付 | パス指示、URL、必要なら MCP | 同上 + /init、PR で @codex |
| 再利用 | ルール・プロンプトテンプレ | .claude/skills/ に PRD Skill | .agents/skills/ に PRD Skill |
置き場所
単一機能・エピック・ドラフトのパス例。
| 種別 | パス例 |
|---|---|
| 単一機能 | docs/prd/<機能スラッグ>.md |
| エピック | docs/prd/<名前>/README.md |
| ドラフト | docs/prd/drafts/yymmdd-概要.md → 確定後に移動 |
フロー（5段階）
- 起票 — Issue 等へのリンクをPRDに必ず残す。
- ドラフト — メタ・背景・ゴール/非ゴール・ユーザー・機能/非機能・受け入れ条件・メトリクス・リスク。
- レビュー — PM・開発。コメントはPRまたはファイル上で残す。
- 承認 — ステータスと承認日を更新。
- 実装連携 — 実装PRにPRDパスを記載。詳細設計は別ドキュメント（API/DB等）へ。
設計書との切り分け
PRDは「何を・なぜ・誰のために」。API・DB・クラス設計は別ファイル。design-document-format.mdc を参照。
AI 開発手法
フロントエンドにおける AI 統合
マイクロフロントエンドとモジュールフェデレーション
大規模チームでは、独立してデプロイ可能なフロントエンドスライスを組み合わせるマイクロフロントエンドアーキテクチャが成熟してきた。チームが互いに踏み込まずに高速に動けると同時に、ユーザーには統合された体験を提供できる。AI ツールはマイクロフロントエンド間のインターフェース設計に特に有効だ。
型安全フルスタックワークフロー
TypeScript がフロントエンドの事実上の標準になり、クライアントとサーバーの境界が曖昧になる中、バックエンドの処理・入力チェック・DB スキーマを共有型で表現するパターンが普及した（tRPC・Zod・Drizzle の組み合わせが代表例）。AI ツールはこの型情報を理解した上でコードを生成するため、型エラーが少ない。
AI ファーストなコンポーネント設計
AI は人間の直感や歴史的コンテキストを持たないため、フロントエンドは 解釈可能性と予測可能性を優先して設計する必要がある。コンポーネントの責務を明確に分離し、props の型を明示し、副作用を局所化することで AI ツールの理解精度が上がる。
バックエンドにおける AI 統合
バックエンドは 2026 年に「受動的な部品」から「AI が判断・処理も担う層」へ変わりつつある。自動スケーリング、異常検知、スマート認証などが標準的な構成要素になってきた。
サーバーレス AI 推論
推論ワークロードをサーバーレスで処理するパターンが広まっている。リクエストごとにスケールし、アイドル時のコストがかからず、GPU インスタンスを常時維持する必要がない。AWS Lambda on Graviton・GCP Cloud Run・Cloudflare Workers AI などが代表的な実装プラットフォームだ。
API 設計の AI 対応
LLM やエージェントが API を呼び出すユースケースが増えた結果、AI ファースト API 設計が求められるようになった。エラーメッセージの自己記述性向上、OpenAPI スキーマによる自動ドキュメント、ストリーミングレスポンス対応（Server-Sent Events）、ツール定義との親和性が設計上の考慮点だ。
AI 開発における品質管理
AI 特有のリスクと対策。
| リスク | 対策 |
|---|---|
| もっともらしい誤回答による誤実装 | 生成されたコードのロジックを必ず理解してからマージする |
| 古い API / 非推奨パターンの使用 | CLAUDE.md・rules ファイルに現在の推奨パターンを明示する |
| セキュリティ脆弱性の混入 | AI 生成コードも SAST・コードレビューの対象に含める |
| テストなしの実装 | テスト作成も AI に依頼し、テスト通過を実装完了の条件にする |
| 理解なきマージ | diff を必ず読む。理解できないコードはマージしない |
アーキテクチャ選択の考え方
AI ツールはアーキテクチャの提案はできるが、最終的な判断は人間が行う必要がある。以下は 2026 年時点で実証されているアーキテクチャ判断の指針だ。
モノリス vs マイクロサービス: 初期は単一サービスで始め、チームが成長し境界が明確になってから分割する（Majestic Monolith からの段階移行）。AI ツールはモノリスの特定機能を別サービスに切り出す作業に有効だ。データベース選択: トランザクション整合性が必要なら PostgreSQL、スキーマレスな柔軟性が必要なら MongoDB、RAG（検索で外部知識を LLM に渡す方式）用のベクトル検索には pgvector か専用ベクトル DB を追加する。フロントエンド フレームワーク: Next.js（React エコシステム・SSR 重視）、SvelteKit（パフォーマンス・軽量重視）、Nuxt.js（Vue エコシステム）が 2026 年の主要選択肢。
DDD / クリーンアーキテクチャ
位置づけ — 採用判断の正式な置き場はプロジェクトの ADR・docs/・rules。AI 開発フロー本体とは別。
つのレイヤの違い
AI 協働・設計・検証の役割分担。
| 観点 | AI 協働（フロー正式な置き場） | 設計（本メモ） | 検証 |
|---|---|---|---|
| 役割 | AI 出力の範囲・禁止・進め方 | 責務分割・不変条件・層境界 | 仕様・ルールとの整合確認 |
| 正式な置き場 | .cursor/rules/ 等 + Plan | docs/<feature>/02_design.md + ADR | テスト / CI / レビュー |
| 典型タイミング | Phase 1 → 全 Phase | Phase 3 設計 | Phase 4〜4、PR 前 |
DDD とは
ドメイン駆動設計 (DDD) — ビジネスの複雑さをコードに反映させる設計思想。Entity / Value Object / Aggregate / Domain Service / Repository 等で業務知識と不変条件を表現する。
- 向く: ドメインルールが複雑、長期運用、チームで用語を共有したい
- 向かない: CRUD 中心・短期 PoC・ドメインが薄い管理画面
クリーンアーキテクチャとは
層と依存方向を固定する構成。Interface → Application → Domain ← Infrastructure のように、内側（Domain）が外側に依存しないことを徹底する。
- Domain: 業務ロジック（他レイヤ非依存）
- Application: ユースケース 運用
- Interface: HTTP / CLI 等
- Infrastructure: DB・外部 API 実装
用語・レイヤ詳細は 用語集 — 設計概念 を参照。
採用時の docs 追記（Phase 3 プロンプト追記用）
Phase 3 の設計プロンプトに、採用する場合のみ以下を足す。
【02_design.md 追記 — DDD / クリーンアーキ採用時】
- DDD を適用する範囲 (Entity / VO / Aggregate / Domain Service / Repository)
- クリーンアーキテクチャの層境界と依存方向
- 主要クラス/関数の責務 (新規/変更)
- エラー設計 (業務例外と技術例外の分離)
- トランザクション境界・並行制御方針
【04_tech_decisions.md 追記】
- DDD / クリーンアーキをどこまで採るか、その理由
- 採用しなかった選択肢 (Vertical Slice / モノリス CRUD 等)
他の設計スタイル
DDD + クリーンアーキがデフォルトではない。Vertical Slice・モジュラモノリス・CRUD モノリス等を ADR で選んでよい。AI フローは「選んだ方針を rules と docs に書き、AI に毎回渡す」ことに専念する。
プロジェクト事例一覧
技術設計・実装パターンの参考事例（16件）。各事例は初期表示で開いています。
| ジャンル | プロジェクト | 概要 | ロール例 |
|---|---|---|---|
| 🤖 AIオペレーター | AIオペレーター導入 | コンタクトセンター向け AI 代替・自動化（PoC→本番） | バックエンドエンジニア · インフラエンジニア |
| 🤖 AIオペレーター | 音声予約（IVR×AI） | Amazon Connect・Lambda・ノーコード IVR 中継 | バックエンドエンジニア · インフラエンジニア |
| 🧠 LLM・RAG | LLM／RAG基盤構築 | 社内向け RAG・エージェント基盤の設計・構築 | バックエンドエンジニア · データサイエンティスト |
| 🏦 銀行・証券 | 大手ネット銀行 | 銀行系コーディング・品質・コンプライアンス重視 | バックエンドエンジニア |
| 🏦 銀行・証券 | 証券 クラウド移行 | 証券基幹の AWS/Azure 移行・Strangler Fig | インフラエンジニア · バックエンドエンジニア |
| 🏦 銀行・証券 | 保険会社 DX推進 | 保険基幹のモダナイゼーション・テックリード | バックエンドエンジニア · インフラエンジニア |
| 💳 Fintech | Fintech AI | 金融×AI・予測モデルと API | データサイエンティスト · バックエンドエンジニア |
| 💳 Fintech | 決済システム（Java） | 決済基盤のクラウドネイティブ化 | バックエンドエンジニア |
| 🏢 ERP | ERP刷新（Odoo） | Odoo による業務システム刷新 | バックエンドエンジニア |
| ⚡ SaaS | SaaS EM／テックリード | プロダクト技術方針とチームマネジメント | バックエンドエンジニア · フロントエンドエンジニア |
| 🏦 銀行・証券 | 金融系インフラ Terraform | IaC・セキュリティ・FinOps | インフラエンジニア |
| 🔧 インフラ | SRE／DevOps（Kubernetes） | K8s・ArgoCD・CI/CD・SLO | インフラエンジニア · バックエンドエンジニア |
| 📊 機械学習 | 機械学習 MLOps | 推薦エンジン・MLOps パイプライン | データサイエンティスト · バックエンドエンジニア |
| ⚡ SaaS | 広告代理店（Go） | RTB・低レイテンシ Go API | バックエンドエンジニア |
| 📡 通信 | 通信キャリア 5G | 5G 関連バックエンド・高可用 | バックエンドエンジニア · インフラエンジニア |
| ⚡ SaaS | 外資系 Python バックエンド | グローバルチーム向け Python API | バックエンドエンジニア |