LLMがプレーン英語のアイデアをフルスタックアプリに変える方法

アイデアからアプリへ：ここで言う「翻訳」が意味すること

「プレーン英語のプロダクトアイデア」は通常、意図と希望の混ざったものとして始まります：誰のためか、どの問題を解くか、成功はどう見えるか。数文（「犬の散歩を予約するアプリ」）、粗いワークフロー（「顧客がリクエスト → 散歩者が承認 → 支払い」）、そしていくつかの必須条件（「プッシュ通知、評価機能」）があるだけかもしれません。アイデアについて話すには十分ですが、一貫して作るには不十分です。

人々がLLMにアイデアを「翻訳できる」と言うとき、有用な意味はこうです：あいまいな目標を具体的でテスト可能な決定に変えること。ここでの「翻訳」は単なる書き換えではなく、レビュー、議論、実装ができるように構造を付け加えることを指します。

LLMが素早く生成できるもの

LLMはコアの構成要素を最初のドラフトとして出すのが得意です：

• ユーザーロールと主要なジャーニー（例：顧客、提供者、管理者）
• 機能リストと受け入れ基準（“ユーザーはメールでパスワードをリセットできる” など）
• 画面一覧とUIフロー（Webとモバイル）
• 提案されるアーキテクチャ（フロントエンド、バックエンド、連携）
• データモデル（テーブル／コレクション、関係）
• APIアウトライン（エンドポイント、リクエスト／レスポンス形）

典型的な「成果物」はフルスタック製品の設計図のように見えます：管理向けやデスクトップ向けのWeb UI、外出先ユーザー向けのモバイルUI、認証やビジネスロジック、通知などのバックエンドサービス、そしてデータストレージ（DBとファイル／メディア保存）です。

それでも人間の判断が必要なこと

LLMは文脈依存のトレードオフを確実に選べません。正解はあなたが書いていない背景に依存するからです：

• 何が「成功」を意味し、どの指標が重要か？
• どんな制約があるか（予算、スケジュール、コンプライアンス、既存ツール）？
• どのエッジケースを今気にするか（後回しにするものは？）
• ユーザーが本当に好きになる最もシンプルなバージョンは何か？

モデルは選択肢やデフォルトを提案するシステムとして扱い、最終決断は人が下してください。

注意すべきリスク

失敗モードは予測可能です：

• あいまいさ：「速い」「安全」「簡単」といった語は定義なしでは実装できません。
• エッジケースの欠如：キャンセル、再試行、オフライン、返金、重複、悪用対策など。
• 過信：生成物は確信のある文体で出るが、前提が脆弱な場合がある。

「翻訳」の真の目的は前提を可視化することで、それがコードに固まる前に確認・修正・却下できるようにすることです。

ステップ1：プロダクトブリーフを明確にする

LLMに「Xのアプリを作って」と言って画面やAPI、データモデルまで出してもらう前に、設計の基準になる十分具体的なプロダクトブリーフが必要です。このステップはあいまいな意図を共有ターゲットに変える作業です。

問題と成功の測定方法から始める

問題文を1〜2文で書きます：誰が困っているか、何に困っているか、なぜ重要か。そして観測可能な成功指標を追加します。

例：「クリニックがフォローアップ予約を取るのにかかる時間を短縮する」。指標は平均予約時間、無断キャンセル率、セルフサーブで予約する患者の割合などが考えられます。

対象ユーザーと主要ユースケースを定義する

主要なユーザータイプを列挙し（システムに触れる全員ではなく主な人物）、各々のトップタスクと短いシナリオを記載します。

有用なプロンプトテンプレートは：「As a [role], I want to [do something] so that [benefit]。」です。MVPを説明するコアユースケースを3〜7件目標にします。

早期に制約を把握する（制約が全てを形作る）

制約はプロトタイプと出荷可能な製品の差です。含めるべき項目：

• プラットフォーム：Web、iOS、Android（およびオフライン要件）
• タイムラインと予算：どのトレードオフが許容されるか
• コンプライアンス／プライバシー：HIPAA、GDPR、データレジデンシー、監査ログ
• 連携：決済、カレンダー、SSO、CRM、メール／SMSプロバイダ

「完了（Done）」を定義する：MVPと以降

最初のリリースに何が含まれ、何を後回しにするかを明確にします。単純なルール：MVP機能は主要ユースケースをエンドツーエンドでサポートし、手作業のワークアラウンドが不要であること。

希望するなら、これを1ページのブリーフとしてまとめ、次のステップ（要件、UIフロー、アーキテクチャ）の「真実のソース」として保持してください。

ステップ2：プレーン英語を要件に変換する

プレーン英語のアイデアは、通常目標（「人がクラスを予約できるようにする」）、仮定（「ユーザーはログインするだろう」）、あいまいな範囲（「簡単にする」）が混在しています。LLMはこれらの乱れた入力をレビュ―・修正・承認できる要件に変えるのに有用です。

文をユーザーストーリーに変える

まず各文をユーザーストーリーに書き換えます。これにより誰が何をなぜ必要とするかが明確になります：

• As a new user, I want to sign up with email or Google so I can start quickly.
• As a returning user, I want to see my upcoming bookings so I can plan my week.

ストーリーがユーザータイプや利点を明記していなければ、まだあいまいです。

機能リストを作り優先順位をつける

次にストーリーを機能にまとめ、各機能を**必須（must-have）かあると良い（nice-to-have）**でラベル付けします。これにより設計・開発前のスコープ肥大を防げます。

例：「プッシュ通知」はnice-to-haveかもしれませんが、「予約をキャンセルできる」は通常must-haveです。

モデルがチェックできる受け入れ基準を書く

各ストーリーの下に単純でテスト可能なルールを追加します。良い受け入れ基準は具体的で観測可能です：

• Given 無効なメールを入力し、フォームを送信したとき、then インラインエラーが表示されアカウントは作成されない。
• Given 24時間以内にキャンセルした場合、確認すると席が解放され確認メッセージを受け取る。

早期にエッジケースを列挙する

LLMはしばしば「ハッピーパス」を想定します。次のようなエッジケースを明示的に要求してください：

• オフライン／低ネットワーク環境（キューイング、再試行挙動）
• 無効入力（空欄、サポート外ファイル形式）
• キャンセルと二重送信（冪等性、確認プロンプト）

この要件バンドルが、後の出力（UIフロー、API、テスト）を評価するための事実上のソースになります。

ステップ3：WebとモバイルのUIフローを設計する

プレーン英語のアイデアが「ユーザージャーニー」と「明確なナビゲーションでつながった画面群」に変わると、初めて構築可能になります。この段階では色を選ぶのではなく、人が何をどの順番で行い、成功がどう見えるかを定義します。

主要なユーザージャーニーをマップする

最初に重要なパスを列挙します。多くの製品では次の構成が使えます：

• オンボーディング：アカウント作成、メール／電話確認、初回設定
• コアタスク：アプリがユーザーの主な仕事を助ける（作成、検索、予約、追跡、共有）
• 支払い：価格表示、チェックアウト、領収書、サブスクリプション管理（該当する場合）
• サポート：FAQ、問い合わせフォーム、問題報告
• 設定：プロフィール、通知、プライバシー設定、サインアウト、アカウント削除

モデルはこれらのフローをステップバイステップで出力できます。あなたの仕事は何がオプションで何が必須か、どこでユーザーが安全に離脱して再開できるかを確認することです。

画面リスト（Web + モバイル）とナビゲーションを生成する

2つの納品物を要求してください：画面在庫（screen inventory）とナビゲーションマップ。

• Webは左サイドバー／トップナビで多くのオプションを見せる傾向があります。
• モバイルは通常タブやスタック画面を使い、1画面あたりの選択肢は少なくします。

良い出力は画面名を一貫して付け（例：「Order Details」 vs 「Order Detail」）、エントリーポイントを定義し、空の状態（結果なし、保存アイテムなし）も含めます。

フォームとバリデーションルール

要件をフォームフィールドに変換します：必須／任意、形式、制限、親切なエラーメッセージ。例：パスワードルール、支払い先住所のフォーマット、日付は未来である必要がある等。バリデーションはインライン（入力中）と送信時の両方で行うことを確認してください。

アクセシビリティの基本を取り入れる

読みやすい文字サイズ、明確なコントラスト、Webでの完全なキーボード操作、エラーメッセージは「どう直すか」を説明すること（単に「無効な入力」ではない）。すべてのフォームフィールドにラベルを付与し、フォーカス順が理にかなっていることも確認します。

ステップ4：アプリのアーキテクチャを提案する

「アーキテクチャ」とはアプリの設計図です：どの部分が存在し、それぞれが何を担当し、どうやって通信するか。LLMがアーキテクチャを提案したとき、あなたの役割はそれが今作れるだけシンプルかつ将来拡張しやすいかを確認することです。

デフォルトから始める：モノリスかモジュール型か？

ほとんどの新製品では**単一バックエンド（モノリス）**が出発点として正しいです：1つのコードベース、1つのデプロイ、1つのDB。開発が速く、デバッグしやすく、運用コストも低いです。

モジュラーモノリスは良い選択肢です：デプロイは一つでもモジュール（Auth、Billing、Projectsなど）に分けて境界をきれいにする。重いトラフィックや独立デプロイの必要が出てきた時点でサービス分割を検討します。

モデルが即座に「マイクロサービス」を推すなら、その選択理由を具体的に求めてください。将来の仮定で過剰設計するのは避けます。

コアコンポーネントを定義する（退屈で良い）

良いアーキテクチャ概要は必須要素を名前で挙げます：

• Auth & user management：サインアップ／ログイン、ロール、セッション／トークン
• Business logic layer：プロダクトのルール（価格設定、承認、制限）
• Data access：アプリがDBをどう読み書きするか
• Background jobs：インポート、レポート生成、定期タスクなどの長時間処理
• Notifications：メール／プッシュ／インアプリのテンプレートと設定

モデルは各部分がどこにあるか（バックエンド vs モバイル vs Web）と、クライアントがバックエンドとどうやってやり取りするか（通常はRESTかGraphQL）を明示すべきです。

技術スタックの前提を明示する

バックエンドフレームワーク、データベース、ホスティング、モバイルアプローチ（ネイティブかクロスプラットフォームか）などの基本を「前提（Assumptions）」として固定してください。そうしないと設計が曖昧になります。

過剰設計せずにスケールを見越す

大きな書き直しより小さな「逃げ道」が良いです：ホットリードのキャッシュ、バックグラウンドジョブのキュー、ステートレスなアプリサーバ。良いアーキテクチャ提案はこれらの選択肢を説明しながらv1は簡潔に保ちます。

ステップ5：データをモデリングする

プロダクトのアイデアには通常名詞が多く含まれます：「ユーザー」「プロジェクト」「タスク」「支払い」「メッセージ」など。データモデリングはLLMがそれらの名詞をアプリが何を保存すべきか、そしてどう繋がるかの共有図に変えるステップです。

名詞をエンティティとリレーションに変える

まず主要エンティティを列挙し、何が何に属するかを問い直します。

例：

• User は多くの Projects を作る
• Project は多くの Tasks を持つ
• Task は多くの Comments を持てる

次にリレーションと制約を定義します：タスクはプロジェクトなしで存在できるか、コメントは編集可能か、プロジェクトがアーカイブされたらタスクはどうなるかなど。

テーブル／コレクションと主要フィールドを作成する

次にモデルがファーストパスのスキーマ（SQLテーブルかNoSQLコレクション）を提案します。単純で、挙動に影響する決定事項に集中します。

典型的なドラフト例：

• users: id, email, name, password_hash/identity_provider_id, created_at
• projects: id, owner_user_id, name, status, created_at
• project_members: project_id, user_id, role
• tasks: id, project_id, title, description, status, due_date, assignee_user_id

重要：statusフィールド、タイムスタンプ、ユニーク制約（例：ユニークなメール）を早期に捕捉してください。これらは後のUIフィルタ、通知、レポーティングを左右します。

所有権、権限、マルチテナント分離

実際のアプリは誰が何を見られるかのルールが必要です。LLMは所有権を明示（owner_user_id）し、アクセスをモデル化（メンバーシップ／ロール）するべきです。マルチテナント製品ならtenant/organizationエンティティを導入し、必要箇所にtenant_idを付与します。

権限はロール（admin/member/viewer）か、権限（project:editなど）か、またはオブジェクトレベルのアクセスかを定義してください。

保持、削除、監査ログ

何をログに残し、何を削除するかを決めます。例：

• 監査イベント：「task created」「permission changed」「export performed」
• 保持ルール：個人データは要請で削除、請求書はX年間保存など
• ソフト削除 vs ハード削除：復旧可能にするか完全に削除するか

これらはコンプライアンスやサポート、請求時に後で問題にならないようにするための重要な決定です。

ステップ6：バックエンドAPIを生成する

バックエンドAPIはアプリの約束を現実のアクションに変える場所です：「プロフィールを保存する」「注文を表示する」「リスティングを検索する」。良い出力はユーザーの行動から出発し、明確なエンドポイント群に落とし込みます。

ユーザーの行動からCRUD＋検索へ

ユーザーがやり取りする主要なオブジェクト（Projects, Tasks, Messagesなど）を列挙し、それぞれに対してユーザーができる操作を定義します：

• Create: 新規作成
• Read: 単体取得または一覧取得
• Update: フィールド更新
• Delete: 削除／無効化
• Search/filter: キーワード、ステータス、日付で検索

これらは通常次のようなエンドポイントに対応します：

• POST /api/v1/tasks (create)
• GET /api/v1/tasks?status=open&q=invoice (list/search)
• GET /api/v1/tasks/{taskId} (read)
• PATCH /api/v1/tasks/{taskId} (update)
• DELETE /api/v1/tasks/{taskId} (delete)

リクエスト／レスポンス例（平易な説明＋JSON）

タスクを作る：ユーザーがタイトルと期限を送信する。

POST /api/v1/tasks
{
  "title": "Send invoice",
  "dueDate": "2026-01-15"
}

レスポンスはサーバー生成フィールドを含む保存済みレコードを返す：

201 Created
{
  "id": "tsk_123",
  "title": "Send invoice",
  "dueDate": "2026-01-15",
  "status": "open",
  "createdAt": "2025-12-26T10:00:00Z"
}

（上記のコードブロックは変更しないでください）

モバイルが扱えるエラーハンドリング

一貫したエラー体系を用意します：

• 400 バリデーションエラー（フィールド単位のメッセージ付き）
• 401/403 認証／権限エラー
• 404 見つからない
• 409 競合（重複、古い更新）
• 429 リクエスト過多（クライアントに再試行時間を通知）
• 500 想定外のエラー（汎用メッセージ＋リクエストID）

再試行には POST に対する冪等性キーを使うことを推奨し、「5秒後に再試行」などの明確な指示を含めます。

バージョニングと後方互換性

モバイルクライアントは更新が遅いので、バージョン付きのベースパス（/api/v1/...）を使い破壊的変更を避けます：

• 新しいオプションフィールドを追加する（名前変更・削除は避ける）
• 旧フィールドはデprecation期間中残す
• 変更は短いチェンジログエンドポイント（例：GET /api/version）で記載する

ステップ7：デフォルトでのセキュリティとプライバシー

セキュリティは「後でやる」仕事ではありません。LLMにアイデアを仕様化させるときは、安全なデフォルトを明示させて、最初のバージョンが誤って濫用されないようにします。

認証：ユーザーが自分を証明する方法

モデルに主要なログイン方法とフォールバック、そして問題発生時の挙動（アクセス喪失、疑わしいログインなど）を推奨させます。一般的な選択肢：

• メール＋パスワード（馴染みはあるがパスワードリセットや強度、漏洩対策が必要）
• マジックリンク／ワンタイムコード（パスワードリスクは低いがメール配信耐性と短いトークン有効期限が必要）
• ソーシャルログイン（早いが外部依存とアカウント連携ルールが必要）

セッション処理（短寿命のアクセストークン、リフレッシュトークン、デバイスのログアウト）や多要素認証対応の有無も指定させます。

認可：ユーザーが何をできるか

認証はユーザーを特定します。認可はアクセスを制限します。モデルには明確なパターンを選ばせます：

• ロール（Admin, Member, Viewer）による単純な管理
• パーミッション（例：project:edit, invoice:export）による柔軟な制御
• オブジェクトレベルのアクセス（ユーザーは所有または共有されたアイテムのみ読み書きできる）

良い出力は「プロジェクト所有者のみ削除可能、コラボレーターは編集可能、閲覧者はコメント可能」などのサンプルルールを含みます。

生成プランに含めたい具体的なセキュリティチェック

一般的な抽象ではなく次のような具体的対策をリストさせます：

• 入力検証とサニタイズを全エンドポイントで行う（クライアントを信用しない）
• レートリミット：ログイン、OTP／マジックリンク、コストの高いエンドポイントに対して
• シークレット管理：APIキーはコードに含めず、資格情報はローテーション、トークンをログに記録しない

また脅威チェックリスト（CSRF/XSS対策、安全なクッキー、ファイルアップロードの安全性）も要求してください。

プライバシーの基本：集めるデータは最小限に、説明は明確に

機能に真に必要なデータだけを最小限に収集し、必要最小期間だけ保持するようにデフォルトを設定します。

LLMに次のような平易な説明文を草案させます：

• 収集するデータとその目的
• データの保持期間
• ユーザーがデータを削除・エクスポートする方法

アナリティクスを追加するならオプトアウト（または法的に必要ならオプトイン）を用意し、設定やポリシーページに明記します。

ステップ8：モデルが作れるテスト戦略

良いLLMは要件を受け入れ基準に紐づくテスト計画に変えられます—ただしすべてを基準に紐づけることが重要です。

テストを受け入れ基準に直接マップする

機能リストと受け入れ基準をモデルに与え、各基準ごとにテストを生成させます。堅実な出力は次を含みます：

• ユニットテスト：ビジネスルール（価格計算、バリデーション、権限チェック）
• 統合テスト：API＋DBの挙動（注文作成が正しい行を永続化するか）
• エンドツーエンドテスト：重要なユーザージャーニー（サインアップ→オンボーディング→初回タスク完了）

テストが特定の基準に紐づかないなら、それは多分ノイズです。

実際のシナリオを反映したテストデータとフィクスチャ

LLMは現実の利用を模したフィクスチャも提案できます：乱れた名前、欠損フィールド、タイムゾーン、長文、ほぼ重複レコード、不安定なネットワークなど。

要求するもの：

• シードデータセット（小〜中）とエッジケース
• ユーザー、ロール、共通オブジェクトの再利用可能なファクトリ／フィクスチャ
• E2Eテスト全体で使う「ゴールデンパス」データセット

モバイルで忘れられがちなチェック

モデルにモバイル専用チェックリストを追加させます：

• オフラインモード（読み取り専用かキューイングされた書き込みか、競合解決方法）
• バックグラウンド/フォアグラウンド（状態復元、進行中リクエストの扱い）
• 権限プロンプト（カメラ、位置情報、通知）と拒否時の遷移

テスト生成にLLMを使うときのレビュー点

LLMはテストの骨子作成が得意ですが、次をレビューしてください：

• アサーション：実装の詳細ではなく結果を検証しているか？
• カバレッジ：401/403、422、タイムアウトなど失敗ケースを含むか？
• フレークのリスク：時刻に依存する待ち、ネットワーク依存、不安定なセレクタ

生成されたテストは速いテスト作成者として扱い、最終的なQA承認は人が行います。

ステップ9：デプロイ、リリース、モニタリング

モデルは多くのコードを生成できますが、ユーザーが恩恵を受けるのは安全に出荷され、運用で状態を監視できるときだけです。このステップは繰り返し可能なリリース手順を作ることに関するものです。

CIの基本（自動化すること）

プルリクエストごと、mainへのマージごとに実行されるシンプルなCIパイプラインを整備します：

• Lint/フォーマット：コードの一貫性と簡単なミスを検出
• 自動テスト（ユニット＋少数のE2Eハッピーパス）
• ビルド手順：
  • Webアプリのビルド
  • モバイルビルド（Android/iOS）
  • バックエンドのビルド／パッケージ

LLMがコードを書いたとしても、CIが変更後も動くかを教えてくれます。

環境：dev、staging、production

3つの環境を明確な目的で運用します：

• Dev：高速な反復、ローカルDB、デバッグログ
• Staging：本番に近い設定で最終検証用
• Production：実ユーザー向け、アクセス制限とログノイズ最小化

設定は環境変数とシークレットで扱い、コードに値を埋め込まないルールにします。

デプロイの概要

典型的なフルスタックアプリの場合：

• バックエンドホスティング：コンテナまたはマネージドサービスにデプロイしヘルスチェックを行う
• DBマイグレーション：バージョン管理されたマイグレーションをデプロイ時に実行し、可能なら巻き戻し可能にする
• モバイルリリース：まず内部ビルド（TestFlight／内部テスト）を配布し、その後段階的にApp Store／Play Storeへ

モニタリングと課題ワークフロー

3つの信号を計画します：

• ログ（何が起きたか）、メトリクス（どのくらい）、アラート（今対処すべきこと）
• 軽量なオンコールルール：アラートは実行可能でありノイズでないこと
• ユーザー向けの問題報告経路（アプリ内リンクや /support）がトリアージキューに入り、重大度、再現手順、ロールバック計画とともに扱われること

AI支援開発が本来の価値を出すのはここです：生成したコードをただ持っているだけでなく、それを製品として稼働させる運用まで回すこと。

LLM出力が間違いやすいところ（と修正方法）

LLMはあいまいなアイデアを一見フルプランに見えるものにできますが、きれいな文章で隠れたギャップを見落としがちです。よくある失敗は予測可能で、いくつかの習慣で防げます。

プロンプトが失敗する理由

弱い出力の原因はだいたい次の4点です：

• 文脈不足：モデルはあなたのユーザー、制約（予算・時間・スキル）、コンプライアンス要件、既存資産を知らない
• 矛盾する要件：「簡素に」と「すべてのエッジケースに対応」は相反する
• 隠れた前提：モデルがメール／パスワードログインを前提にしたり、「リアルタイム＝WebSocket」を想定したりする
• 優先順位未設定：スピード対コスト対品質のどれを重視するかがないと、一般的で適合しない回答になる

より良い出力を引き出す方法

モデルに具体的な材料を与えます：

• 事例：「Calendlyのようだが、オンサイトサービス向け」＋2–3のサンプルユーザーストーリー
• 制約：「Postgresを使う、AWSにデプロイ、MAUは1万を想定」
• 推論を見せることを強制：前提、未解決の質問、代替案を列挙させる：「決定事項と理由を示せ」

手戻りを減らすための「完了の定義」を追加する

納品物ごとにチェックリストを要求します。例：要件は受け入れ基準、エラー状態、ロール／権限、測定可能な成功指標を含めないと「完了」としない。

単一の真実のソースを保つ

仕様、APIノート、UI案が別のスレッドに散らばるとLLM出力はズレます。1つの生きたドキュメント（シンプルなMarkdownファイルでも良い）に次をリンクして保持してください：

• プロダクトスペック
• API契約（エンドポイント＋スキーマ）
• デザインノート（主要フローとエッジケース）

再度プロンプトするときは最新の抜粋を貼り付け「XとYのセクションだけ更新し、それ以外は変更しないで」と指示してください。

実装しながら進めるなら、生成物とリポジトリの整合を保てるワークフローが役立ちます（例：Koder.aiの“planning mode”のように、スペックをロックしてチャットスレッドからスキャフォールドを生成し、スナップショット／ロールバックで整合を保つ仕組み）。

実践的なウォークスルーと人間によるレビュー要所

ここでは「LLM翻訳」がエンドツーエンドでどう見えるかと、人間が速度を落として実際の判断を下すチェックポイントを示します。

短い例：アイデア→画面、データ、API

プレーン英語のアイデア：「オーナーがリクエストを投稿し、シッターが応募し、仕事完了後に支払いがリリースされるペットシッティングのマーケットプレイス」

LLMはこれを第一草案に変えられます：

• 画面：サインアップ/ログイン、リクエスト作成、リクエスト詳細（応募者一覧）、応募画面、アプリ内チャット、チェックアウト、ジョブ完了、評価/レビュー、管理者（紛争対応）
• データモデル：Users（role: owner/sitter）、PetProfiles、Requests（日時、場所、ステータス）、Applications、Messages、Payments、Reviews
• API：POST /requests, GET /requests/{id}, POST /requests/{id}/apply, GET /requests/{id}/applications, POST /messages, POST /checkout/session, POST /jobs/{id}/complete, POST /reviews

これは有用ですが「完了」ではありません。検証が必要な構造化された提案です。

人間がレビューする箇所（重要性の理由）

プロダクト判断：何が「応募」の有効条件か？オーナーがシッターを直接招待できるか？いつリクエストは「埋まった」と見なすか？これらのルールは全ての画面とAPIに影響します。

セキュリティ & プライバシーのレビュー：ロールベースアクセスの確認（オーナーが他のオーナーのチャットを読めないなど）、支払いの保護、データ保持（例：チャットはXか月後に削除）を定義。悪用対策（レートリミット、スパム防止、監査ログ）を追加。

パフォーマンス上のトレードオフ：何を速くする必要があるか（検索、チャットなど）。これがキャッシュ、ページネーション、インデックス、バックグラウンドジョブの設計に影響します。

イテレーションループ：フィードバック→要件→コード

パイロット後にユーザーが「リクエストを複製したい」「一部返金でキャンセルしたい」といった要求を出すかもしれません。それを要件に反映し、影響を受けるフローを再生成／修正し、テストとセキュリティチェックを再実行します。

保守性のために何を記録するか

「何を」だけでなく「なぜ」を残します：主要なビジネスルール、権限マトリクス、API契約、エラーコード、DBマイグレーション、リリースとインシデント対応の短いランブック。これが生成コードを半年後に理解するために重要です。