CRUDアプリ向けVibeコーディングプロンプト：フルスタックのコピペセット

このプロンプトセットが作るもの（平易な説明）

このプロンプトセットは、完全に動作するCRUDアプリを生成するよう設計されています：ユーザーが使う画面、リクエストを処理するAPI、そしてデータを保存するPostgreSQLデータベースです。ログインと役割ベースのアクセスも含まれるので、異なるユーザーが異なることを見たり実行したりできます。

CRUDはアプリに必要な日常的な4つの操作です：

• Create（作成）：新しいレコードを追加する（顧客やタスクなど）
• Read（閲覧）：一覧を見て個別アイテムを開く
• Update（更新）：既存の項目を編集する
• Delete（削除）：項目を削除する（通常は確認ステップあり）

フロントエンドでは、予想可能な一連の画面ができます：一覧ページ、詳細ページ、新規作成フォーム、編集フォーム、それにログインページと基本的なナビゲーション。バックエンドでは、それらの画面に対応するエンドポイント（list, get by id, create, update, delete）と、それを支えるPostgresテーブルおよび簡単なバリデーションができます。

プロンプトの品質はモデル選択より重要です。モデルは指定した内容しか実行できません。プロンプトが曖昧だと、フィールド名がずれる、ルートが足りない、認証が不完全、APIとUIが噛み合わない、などが起きます。精密なプロンプトは契約のように働き、UI、API、DBが同じ名前とルールで一致します。

開始前にいくつか決めておくとビルドが一貫します：

• メインのエンティティと6～12のフィールド（名前、型、必須か任意か）
• 役割（例：admin、manager、viewer）とそれぞれの権限
• 基本ルール（誰が編集できるか、ソフトデリートかハードデリートか、必須フィールド）
• 初日に必要な「ハッピーパス」画面
• 制約（ユニークなフィールド、日付範囲、ステータスの値）

Koder.aiを使っている場合、この一連の会話でReact UI、Go API、PostgreSQLスキーマが手を煩わせずに揃った状態で出力されます。

準備ワークシート：プロンプト前に決める少数の詳細

良いCRUDビルドは少数の決定から始まります。事前に書き出しておくと、プロンプトが明確になり、画面が正しく表示され、APIがDBと一致します。

まずは1つのコアエンティティから始めてください。これはアプリが日常的に管理する「物」です（Item、Customer、Appointment）。2つ目のエンティティは、本当に初日から必要な場合のみ追加します（例：ItemがCategoryを必要とする場合）。3〜4個も始めると、関係の整理に時間を取られて動くアプリを作る時間が減ります。

エンティティのフィールドは型と例を付けて書きます。例はラベル、フォーマット、バリデーションを導くため重要です。

• Field: type - example (notes)
• name: text - "Paper towels" (required, 2-80 chars)
• quantity: number - 24 (min 0)
• reorder_date: date - 2026-02-01 (optional)
• status: enum - "in_stock" | "low" | "out" (default in_stock)

次に、役割と権限を平易な言葉で列挙します。具体的にしておきましょう。多くのアプリでは2〜3の役割で十分です：

• Admin: ユーザー管理、全レコードのフルCRUD
• Manager: レコードのCRUD、ユーザー管理は不可
• Viewer: 閲覧のみ

最後に、5〜10のサンプルレコードを作成してください。これが現実的なUIラベル、ドロップダウンの選択肢、妥当なデフォルト値を導きます。例（在庫）："Hand soap, qty 6, reorder_date 2026-01-20, status low"。

Koder.aiでビルドするなら、このワークシートを最初のプロンプトに貼っておくと、プラットフォームが画面、認証、PostgreSQL対応APIの整合性を保てます。

ベースプロンプト：ビルド全体のルールを設定する

まず「ルール」を1つ作り、UI、API、DB全体で一貫性を保ち、後で機能を追加したときのやり取りを減らします。

コードを書く前に短いプランを要求してください。モデルに画面名とルート、テーブル、APIエンドポイントを列挙させ、前提条件（どの役割があるか等）を明示させます。前提は無断で変えないように指示してください。

ここにコピペ可能なベースプロンプトがあります：

You are building a complete full-stack CRUD app.

Tech targets (do not change):
- Frontend: React web app
- Backend: Go REST API
- Database: PostgreSQL

Before writing any code, produce a short plan (max 25 lines) that includes:
1) Screens + key UI components
2) Routes/navigation
3) Roles and permissions
4) PostgreSQL tables (with columns and relationships)
5) API endpoints (method + path) for auth and CRUD

Assumptions:
- If any detail is missing, make a reasonable default and list it under “Assumptions”.
- Keep assumptions consistent across UI, API, and DB. If you must change an assumption, stop and ask.

Rules:
- Use simple, boring CRUD first. No “nice to have” features unless asked.
- Include input validation, basic error messages, and loading states.
- Use clear names that match across layers (same field names in UI, API, and DB).

Non-goals (do NOT implement):
- Payments, subscriptions, invoices
- Complex workflows/approvals
- Multi-tenant org hierarchy
- Real-time chat/notifications

Now ask me 5 clarifying questions max. If I answer “default”, proceed with your assumptions.

具体例：プランでrole: admin|memberを選んだなら、後で勝手にmanagerを出してこないようにします。このプロンプトは、モデルが停止してあなたの承認を待つように促します。

コピペ可能プロンプト：画面とナビゲーション

良い画面はまずページマップから始まります。データベースやAPIを要求する前に以下のプロンプトを使って画面とルート名を安定させてください。多くのビルドが崩れる原因はここにあります。

プロンプト1：ページ一覧とユーザーフロー

You are building a full-stack CRUD app UI. Start by proposing a complete page list and user flows.

App concept (1 sentence): <PASTE YOUR APP CONCEPT>
Entities (list): <ENTITY_1>, <ENTITY_2>
Roles: <ROLE_1>, <ROLE_2> (include an Admin role)

Deliverables:
1) A table of pages with: Route, Page name, Who can access, Primary actions, Empty state behavior.
2) Key user flows (bullets): sign up, sign in, create record, edit, delete, search/filter, admin manages users.
3) Route naming rules: kebab-case paths, consistent singular/plural, no duplicates.
4) Component naming rules: PascalCase, one top-level page component per route.
Ask me 5 questions max only if needed.

回答を受け取ったら、その名前をロックしてください。後でルート名を変えるとAPIやテストがずれてしまいます。

プロンプト2：ナビゲーションと良く動くフォーム

Using the approved page list and route names, generate:

A) Navigation
- A simple top nav for desktop and a compact mobile menu.
- Show which items appear for each role.
- Add a clear "You do not have access" page and redirect rules.

B) Page skeletons
For each page, create a minimal UI with:
- A visible page title and short helper text.
- Loading state, empty state, error state.
- A primary button for the main action.

C) Accessible forms
For all create/edit forms:
- Labels tied to inputs, required markers, inline validation errors.
- Disable submit while saving, show a spinner, prevent double submits.
- Toast or inline success message after save.

D) Consistent action names
Use these verbs exactly: list, view, create, update, delete.
Use these UI actions: onCreate, onUpdate, onDelete, onSearch.

UIが複雑すぎる場合は、レイアウトを1つ、テーブルスタイルを1つ、フォームパターンを1つにまとめるよう要求してください。

コピペ可能プロンプト：認証と役割

予測可能な結果を得るには、ユーザーのログイン方法、セッションの持続時間、各役割ができることを明確にしてください。以下はシンプルなメール＋パスワードとセッションベースのアプローチを想定したプロンプトです。

まずこれを貼って、ログイン、ログアウト、セッション処理を生成させます：

Implement authentication for this app.

Requirements:
- Add UI screens: Login, Logout action, and a simple “My account” page that shows the logged-in user email and role.
- Use email + password login.
- Session handling: keep the user logged in across refresh; include a clear “Log out” button.
- API endpoints: POST /auth/login, POST /auth/logout, GET /auth/me.
- Show friendly error messages for wrong password, unknown email, and locked/disabled accounts.

Security (keep it simple):
- Password rules: minimum 12 characters; must include at least 1 letter and 1 number.
- Store passwords securely (hash + salt). Never store plain text.
- Basic protections: rate-limit login attempts per email/IP and return generic error text that doesn’t reveal which part was wrong.

Deliverables:
- Working UI flows + backend endpoints.
- Seed one default admin user for local testing and tell me the credentials.
- Add clear comments explaining where to change password rules and session duration.

次に役割と保護ルールを追加します。テストしやすい小さな権限セットを維持してください：

Add role-based access control (RBAC) with these roles: admin, manager, viewer.

Rules:
- admin: can create, edit, delete, and manage users/roles.
- manager: can create and edit records, cannot delete, cannot manage users.
- viewer: read-only.

Enforcement:
- Protect both routes (screens) and API endpoints. Do not rely on the UI alone.
- If a user lacks permission, show a “Not allowed” page in the UI and return HTTP 403 from the API.

Deliverables:
- A simple “Users” admin screen to list users and change roles.
- A clear table (in text) mapping each route + API endpoint to required role.
- Add automated checks or middleware so every protected endpoint enforces the rules.

簡単な手動チェック：\n\n- 各役割でログインして、見えるものとできることを確認する。\n- 制限されたアクション（削除など）を試して403が返るかを確認する。\n- ログアウトがセッションをクリアし、アプリがログイン画面に戻ることを確認する。

Koder.aiを使うなら、認証とRBACの変更は1つのスナップショットにまとめておくと、権限が絡んだときに巻き戻しが簡単です。

コピペ可能プロンプト：PostgreSQLスキーマとデータモデル

良いスキーマプロンプトは2つの役割を果たします：テーブル関係を明確にして（画面とAPIが一致するように）、”ほぼ正しい”データベース（インデックス、タイムスタンプ、ロールマッピングが欠けている）を防ぎます。

貼る前に2つのトグルを決めてください（1行ずつ）：

• Primary keys: uuid or bigserial
• Soft delete: yes（deleted_atを使う） or no（ハードデリート）

このプロンプトをまず貼ってデータモデルをロックします：

You are building the PostgreSQL data model for a full-stack CRUD app.

Domain: <DESCRIBE YOUR APP IN 1 SENTENCE>
Core entities: <LIST 3-6 ENTITIES>

Rules:
- Use PostgreSQL.
- Choose primary key type: <uuid|bigserial>.
- Timestamps: every table must have created_at and updated_at.
- Soft delete: <yes|no>. If yes, add deleted_at and default queries should ignore deleted rows.
- Define users, roles, and permissions storage:
  - users table (email unique, password_hash, status)
  - roles table (name unique)
  - user_roles join table (user_id, role_id) with unique(user_id, role_id)
- For each core entity: define columns, types, required vs optional, and relationships.
- Call out any many-to-many relationships and introduce join tables.
- Propose indexes for common lookups (foreign keys, email, name/search fields).

Output:
1) A short ERD description in plain English.
2) The final table list with columns and constraints.
3) The index list with rationale.

次に、このプロジェクトに合わせたマイグレーションやセットアップ手順を生成するために以下を貼ります：

Now generate the actual database setup for this project.

Requirements:
- Provide SQL migrations (up and down) for all tables, constraints, and indexes.
- Ensure foreign keys and on-delete behavior are explicit.
- Include extensions you rely on (for example uuid generation), but only if needed.
- Add a seed migration for: one admin user, one admin role, and the user_roles link.

Output:
- migrations/ file names in order
- contents of each up/down migration
- brief notes on how to apply migrations in the project

不明点があれば「SQLを書く前に関係やフィールドについて最大5つまで質問して」と1行追加してください。

コピペ可能プロンプト：GoのCRUD API（Postgres対応）

バックエンドがいつも中途半端になる場合、このプロンプトは基礎（ルート、バリデーション、ページネーション、役割チェック）を強制します。

そのままコピペして、プレースホルダ（RESOURCE, FIELDS, ROLES）を置き換えてください。

You are building the backend API in Go for a Postgres-backed CRUD resource.

Resource
- RESOURCE name (singular/plural): <Item/items>
- Table: <items>
- Primary key: <id UUID>
- Fields (name, type, required?, rules):
  - <name TEXT required, 2..80 chars>
  - <qty INT required, min 0>
  - <status TEXT optional, one of: active, archived>
- Ownership: <tenant_id UUID required> and <created_by UUID required>

Auth and roles
- Roles: <admin, manager, viewer>
- Authorization rules:
  - Every endpoint must check role and tenant_id.
  - admin: full access
  - manager: create, read, update, list; cannot delete
  - viewer: read and list only

API requirements
1) Implement REST endpoints:
- POST /api/items
- GET /api/items/{id}
- PUT /api/items/{id}
- DELETE /api/items/{id}
- GET /api/items

2) Define request/response JSON shapes for each endpoint, including examples.

3) Validation
- Return 400 with field-level errors (clear messages) when invalid.
- Return 401 if no auth, 403 if role not allowed, 404 if not found in tenant.

4) List endpoint
- Support filtering by: <status>
- Support sorting by: <created_at,name> with order asc/desc
- Support pagination: page, page_size; return total, page, page_size, items.

5) Data access
- Use database/sql (or pgx) with parameterized queries only.
- Include migrations SQL for the table and indexes (tenant_id + created_at).

Deliverables
- Go code: routes, handlers, DTOs, validation helpers, repository layer
- SQL: migration(s)
- Notes: any assumptions

生成後は一度整合性を確認してください：ステータスコードがエラーボディと一致している、listが安定した並び順を返す、各ハンドラが役割とテナント所有権を確認している、など。

Koder.aiを使う場合、バックエンドはGo、DBはPostgreSQLに固定しておくと、エクスポートしたコードが期待するスタックに合致します。

ステップバイステップ：生成、実行、検証

UI、API、DBのすべてを生成したら、厳密な検証モードに切り替えます。目的は画面を鑑賞することではなく、エンドツーエンドが動くことを証明することです：UI - 認証 - 役割 - Postgres - API - UI。

簡単な検証手順

1. アプリを起動してホーム画面を読み込みます。ナビが動き、プレースホルダデータが見えないことを確認してください。空白ページなら、最初に見えるエラーメッセージ（UIトースト、コンソール、サーバーログ）を記録します。

2. 各役割（Admin、Manager、Viewer）についてテストアカウントを作り、ログインとログアウトを行います。アプリのどこかに役割が見える（プロフィールメニュー、設定、バッジ等）ことを確認してください。

3. 1つのCRUD画面を選んで完全なサイクルを行います：レコードを作成し、ページをリロードしてから編集し、削除します。重要なのは永続性です：リロード後にレコードがPostgresにある内容を反映していること。

4. 意図的に禁止された操作を試します。最も権限の低い役割で管理者専用画面にアクセスしたり、制限されたアクション（削除など）を呼び出したり、編集できないレコードを編集しようとします。結果は明確であるべきです：UIでブロックされるか、APIが403を返してデータ変更が起きないか。

5. 基本的なエッジケースを試します：空の一覧、非常に長い名前、必須フィールドの欠落、不正なフォーマット（メール、日付）。アプリが親切なバリデーションを表示し、クラッシュしないことを確認してください。

Koder.aiを使っているなら、最初の成功したエンドツーエンドCRUDテストの直後にスナップショットを取ってください。DBスキーマ、認証ルール、共有コンポーネントに触れる前の安全な戻しポイントになります。

よくあるプロンプト失敗とその直し方

多くの「壊れた」ビルドは実際には壊れていません。UI、API、DBを一緒に動かすための制約が不足しているだけです。

1) 一度に多くを要求しすぎた

画面、認証、役割、スキーマ、あらゆるエッジケースを一度に要求すると、アプリは不整合になりやすい（ルートが一致しない、モデルがずれる、ページが未完成）。

直し方：レイヤーごとに分け、コードを書く前に生成物を再掲させてください。Koder.aiではこれが複数エージェントの整合に効きます。

2) 役割が曖昧でチェックが抜ける

「adminとuserだけ」としか言わないと、UIにラベルはあってもサーバー側での認可が実装されないことがあります。

直し方：リソースごとに（create, read, update, delete）というアクション単位で権限を定義し、すべてのエンドポイントでサーバー側の強制を要求してください。

3) フィールド型が足りないとUIとDBがずれる

フィールドを「price」「date」「status」などだけで説明すると、フォームはテキスト入力になり、Postgresは数値や日付、enumを期待することがあります。

直し方：フィールドの型、null許可、デフォルト、制約を指定し、共通のバリデーションルールを要求してください。

4) ローディングとエラーステートがないとUIが壊れて見える

ローディングやエラーステートがないと、リクエスト失敗がフリーズのように見えます。

直し方：各画面にローディングスピナー、空状態、目に見えるエラーメッセージを要求してください。

5) 名前が途中で変わる

途中で「Projects」を「Workspaces」に変えるとルート、ハンドラ、テーブル名が壊れることが多いです。

直し方：初めに用語集をロックしてください。変更する場合は、リネームプラン（検索/置換、マイグレーション）を要求してモデルに任せないでください。

何かが外れたらこの修復プロンプトを使ってください：

Audit the current app and list mismatches between: (1) routes, (2) API endpoints, (3) database tables/columns, (4) UI form fields.
Then propose a minimal patch plan.
Rules: do not invent new names, do not add new features, keep existing behavior, and update tests if present.
Output: a checklist of changes, then apply them.

不整合が続く場合、多くは「単一の真実のソース」が欠けています。1行で追加してください：“The Postgres schema is the source of truth; UI and API must match it exactly.”

完了前のクイックチェックリスト

時間をかけて仕上げる前に、アプリが本物のプロダクトのように振る舞うか素早く確認します。ここで多くのフルスタックCRUDアプリが失敗します：画面、ルール、データの細かな不一致です。

• 画面がエンティティ仕様と一致している：一覧、詳細、作成、編集の各画面が定義したエンティティ名とフィールドリストを正確に使っている。\n- 役割が曖昧でない：役割ごとの許可/拒否テーブルを書き、UIとAPIが同じルールを強制している。\n- APIレスポンスが一貫している：ステータスコード、エラー形、ページネーション形を1つに決め、すべてのエンドポイントが従っている。\n- DB制約がフォームバリデーションと一致している：DBがユニークなメールや非null名を要求するなら、送信前に検証し、APIが拒否したときに明確なメッセージを表示する。\n- 作成/編集/削除がリロード後も残る：作成してリロード、編集してリロード、削除してリロードして期待通りであること。

具体的なテスト：最低権限の役割で削除などブロックされるべき操作を試し、それが成功したらAPIポリシーをまず修正し、次にUIを合わせてください。

現実的な例：シンプルな在庫トラッカー

小さなITチームがノートPC、モニタ、アダプタを貸し出す管理用の例を想像してください。何が利用可能か、誰が何を借りているか、返却予定日を追跡する必要があります。これは役割、いくつかの画面、実際のデータベースを必要とするので良いテストケースです。

記入済み準備ワークシート

これをそのまま準備ステップの入力として使ってください（コピーして名前を調整してもよい）：

App name: IT Equipment Loans
Goal: Track inventory and loans. Staff can request items. Admin approves and records check-out and return.
Roles:
- admin: manage inventory, approve/deny requests, edit any loan, see all
- staff: browse inventory, create a request, see own requests/loans
- viewer: read-only access to inventory and aggregate loan status
Core screens:
- Login
- Inventory list + item detail
- Request item (staff)
- Admin requests queue
- Loans list (filter: active/overdue)
Data rules:
- An item can have 0 or 1 active loan at a time
- Due date required for approved loans
- Overdue if due_date < today and not returned
Sample data:
- Items: MacBook Pro 14 (MBP-014), Dell 27 Monitor (MON-227), USB-C Dock (DOC-031)
- Users: alice(admin), ben(staff), carla(viewer)

貼る順序

アプリが一貫するように、次の順でプロンプトを貼ってください：

1. ベースプロンプト（グローバルルール、スタック、命名、エラーハンドリング）\n2) 画面とナビゲーション（Inventory、Requests、Loans、Admin queue）\n3) 認証と役割（admin、staff、viewerの権限）\n4) PostgreSQLスキーマとシードデータ（items、loans、requests、users）\n5) Go CRUD API（ルートとバリデーションがルールと一致するように）

良い結果例：staffが“MBP-014”をリクエストし、adminが承認して期限日を設定すると、在庫一覧はそのアイテムを貸出中として借用者名を表示する、という流れです。

もしビルドがほぼ正しいが少し違う場合は、一度に1つだけ直してください：権限を厳密にする（viewerは編集ボタンを絶対に見ない）、“1アイテムにつき1つのアクティブローン”ルールを再確認、あるいはフィールド名をUIラベルとDBカラムが一致するようにリネームするなど。

次のステップ：安全に拡張し、プロンプトセットを再利用する

基礎が動いたら、次の変更は小さなリリースのように扱ってください。1つの機能を選び、「完了」の定義を書き、次にそのためのプロンプトを投げます。

多くのアプリで合理的な順序：\n\n- 監査ログ: どのユーザーがいつ何を変更したかを記録し、管理者のみが見る画面を追加する。\n- ファイルアップロード: レコードにドキュメントや画像を添付し、メタデータをPostgresに保存して認証でアクセス制御する。\n- シンプルな通知: アプリ内のアラート（例：在庫少、コメント追加）を表示し、既読にするアクションを提供する。\n 変更でビルドが壊れたら、一度ロールバックして小さなプロンプトで再適用してください。Koder.aiを使うなら、スナップショットとロールバックはDBスキーマ、認証ルール、共有コンポーネントに触れる前の安全網になります。

Planning Modeは機能が複数レイヤーに跨るときに有用です。まずプラン（画面、APIエンドポイント、DB変更、役割）を再掲させ、あなたが承認してからコードを生成させることで、UIが返さないフィールドを期待する、APIが存在しないカラムに書き込む、という不一致を防げます。

プラットフォーム外で作業を続けるなら、ソースコードをエクスポートして通常のワークフローで変更してください。プロンプトセットをレポジトリの「ビルド手順」として残しておくと、後で再現したり新しいメンバーのオンボーディングに便利です。

Koder.ai上で構築する場合、このプロンプトセットはReact + Go + PostgreSQLの既定に適合し、スナップショットを使って安全に反復できます。

最後に、次のプロジェクト用に再利用可能なテンプレートプロンプトを保存してください。安定した部分（スタック、CRUDルール、認証と役割の慣習、Postgresパターン）は残し、ドメイン固有名詞だけ差し替えることで、プロンプトが一度きりの実験ではなく再現可能なレシピになります。