コードを生み出すプロンプトテンプレート

使い捨てのプロンプトからは使い捨てのコードが生まれます。精密なプロンプトからは実際にマージできるものが生まれます。この差はほぼ常に具体性にあります。曖昧な指示からは曖昧な出力が生まれます。

以下の10のレシピは、Claude Code がレビューに出せる品質の作業を生み出すために必要な詳細を組み込んでいます。各レシピにはプロンプト、それが機能する理由、他のスタックへの入れ替え例、構造なしで似たものを使おうとした人が陥る失敗パターンが付いています。

プロジェクトスキャフォールディング

フルスタックWebアプリ

claude "Create a React app with TypeScript and Tailwind CSS. It's a todo app with localStorage persistence. Include: add, edit, delete, mark complete, and filter by status (all/active/completed). Use a single TodoContext for state management. Make it mobile-responsive with min-width 320px support."

機能する理由: 技術スタック、ストレージの選択、すべてのCRUD動詞、状態モデル、サポートする最小画面サイズがすべて書かれています。Claude が推測をやめるため、後で取り除く必要のあるものが返ってくることがありません。

入れ替え例:

• Next.js: 「React app」を「Next.js 15 app using App Router and Server Components where possible」に変更
• Vue: React/TypeScriptスタックを「Vue 3 with Composition API and TypeScript」に置き換え
• より充実したスターター: 「Include dark mode toggle, keyboard shortcuts (Ctrl+N for new, Delete to remove), and export/import as JSON」を追加

よくある失敗: 単純な「create a todo app」では Claude が自分で良さそうに見えるデフォルトに頼り、ほとんどの場合リポジトリに合わない結果になります。「見栄えを良くして」はTailwindを名指しするより悪いです。なぜなら好みはスペックではないからです。

返ってくるもの: 3〜5つのファイル。React コンポーネントツリー、コンテキストプロバイダー、Todoモデルの TypeScript インターフェース、フレキシブルな Tailwind レイアウト。npm run devで初回から動作します。

認証付きAPIバックエンド

claude "Build an Express.js REST API with JWT authentication. Include: user registration (POST /auth/register), login (POST /auth/login), and a protected endpoint (GET /auth/me). Hash passwords with bcrypt (12 rounds). Use middleware for token verification. Add Zod validation for request bodies. Return consistent JSON error responses with status codes. Include a health check endpoint at GET /health."

機能する理由: ルートを書き出すことで Claude が独自に考案するのを防ぎます。bcryptのラウンド数、バリデーションライブラリ、エラーの形状を指定することで、出力がすでにプロジェクトのコードのように見えます。後処理は不要です。

入れ替え例:

• Fastify: 「Express.js」を「Fastify with @fastify/jwt plugin」に置き換え
• Prisma: 「Use Prisma with PostgreSQL. Include a User model with id, email, passwordHash, createdAt fields」を追加
• セッション: 「JWT authentication」を「express-session with Redis store for session management」に変更

よくある失敗: エラーハンドリングの行をスキップすると Claude はハッピーパスだけを書きます。登録とログインはきれいな入力では動作しますが、不正な入力では壊れます。

データベースとデータ層

スキーマ生成

claude "Create a PostgreSQL schema for a multi-tenant SaaS app. Tables needed: organizations, users (belongs to organization), projects (belongs to organization), and tasks (belongs to project, assigned to user). Include: UUID primary keys, created_at/updated_at timestamps on all tables, proper foreign keys with ON DELETE CASCADE, a unique constraint on user email per organization, and indexes on all foreign key columns. Add 5 sample INSERT statements per table for testing."

機能する理由: 「マルチテナント」という言葉が分離パターンを伝えます。UUIDキー、タイムスタンプ、カスケードルール、ユニークメールの制約範囲を指定することで、最も一般的なレビューの指摘を排除します。サンプル行を要求することで、スキーマがエラーなしで実際にロードされることを確認します。

入れ替え例:

• MySQL: 「PostgreSQL」を「MySQL 8.0 using InnoDB engine」に置き換え
• Prismaマイグレーション: 「Format as Prisma schema instead of raw SQL, and generate the initial migration」を追加
• 監査ログ: 「Include an events table with a JSONB payload column, indexed with GIN, for audit logging」を追加

テスト

完全なテストセットアップ

claude "Set up Vitest with React Testing Library for this TypeScript React project. Create: a test for the Button component that checks rendering, click handling, disabled state, and loading state. An integration test for the LoginForm that mocks the auth API call, fills the form, submits, and verifies redirect on success and error message on failure. Add a test utility file with a renderWithProviders function that wraps components in the app's context providers. Add test and test:coverage scripts to package.json."

機能する理由: テストプロンプトは「このコンポーネントのテストを書いて」という読み方をすると失敗します。ここではユニットテストに4つの名前付きケース、インテグレーションテストに2つのエンドツーエンドフローが含まれています。共有ヘルパーファイルはほとんどの人がスキップする部分で、将来のテストを一貫したものに保つ部分です。

入れ替え例:

• Playwright E2E: フレームワークを「Set up Playwright for end-to-end testing. Include a test that navigates to the login page, fills credentials, submits, and verifies the dashboard loads」に置き換え
• APIテスト: 「Set up Supertest with Vitest for the Express API. Test the /auth/register endpoint with valid data, duplicate email, and missing required fields」

返ってくるもの: 設定ファイル、通過する2〜3つのテストファイル、共有ユーティリティファイル、更新されたpackage.jsonスクリプト。npm testが即座にグリーンになります。

リファクタリング

コンポーネント分解

claude "This UserDashboard component is 400 lines long. Refactor it by: extracting the stats cards into a StatsGrid component, the activity feed into an ActivityFeed component, and the sidebar navigation into a DashboardNav component. Keep the data fetching in UserDashboard and pass data down as props. Create TypeScript interfaces for all props. Preserve all existing functionality and don't change any CSS class names."

機能する理由: リファクタリングプロンプトにはガードレールが必要です。「このコンポーネントをリファクタリングして」では Claude が好きなものを移動でき、動作が静かに変わってしまいます。どの子コンポーネントを抽出するか、フェッチングをどこに残すか、どのCSSクラスを維持するかを指定することで、新しいコードがUIやテストを壊すことなくアプリに落とし込まれます。

入れ替え例:

• カスタムフック: 「Extract the data fetching logic into a useUserDashboard custom hook. Return the loading state, error state, and all data objects. Keep the component purely presentational」
• Zustandマイグレーション: 「Move the local useState calls into a Zustand store. Export typed selectors for each piece of state. Keep the component renders identical」

デバッグ

構造化されたバグ調査

claude "Users report that the checkout form submits twice on slow connections. Investigate: check the form's onSubmit handler for missing event.preventDefault() or missing disabled state during submission. Check if the submit button lacks a loading/disabled state. Check for React StrictMode double-render issues. Check if the API call has retry logic that could cause duplicates. Propose a fix and add an idempotency safeguard."

機能する理由: ほとんどのデバッグプロンプトは「このバグを修正して」と読めます。それでは Claude は推測、grep、一度に修正しようとし、大抵は最初の説得力のある仮説に飛びつきます。このバージョンは二重送信の4つの可能性の高い根本原因を渡し、順番に調べるよう求めます。

入れ替え例:

• 遅いページ: 「The dashboard takes 8 seconds to load. Investigate: check for N+1 queries in the API, unnecessary re-renders in React components, unoptimized images, and missing database indexes. Measure the time each fix saves」
• 認証切れ: 「Users are getting logged out randomly. Check: JWT expiration handling, refresh token rotation, cookie settings (SameSite, Secure, HttpOnly), and whether concurrent requests race on token refresh」

コードレビューと品質

PR前レビュー

claude "Review the changes in this branch for a PR. Check for: security issues (SQL injection, XSS, exposed secrets), missing error handling on async operations, TypeScript type safety (no 'any' types, proper null checks), accessibility on any new UI components (ARIA labels, keyboard navigation), and performance concerns (unnecessary re-renders, missing useMemo/useCallback). Format findings as a list with severity (critical/warning/info) and file location."

機能する理由: 「このコードをレビューして」では表面的なコメントしか得られません。5つのレビュー軸と出力形式を指定することで、すぐにアクションを取れるレポートが得られます。

入れ替え例:

• バックエンドのみ: アクセシビリティと再レンダリングを「N+1 queries, missing rate limiting, and improper error propagation」に変更
• セキュリティパス: 「Focus exclusively on security: check all user inputs, authentication boundaries, authorization checks, sensitive data handling, and dependency vulnerabilities」

機能開発

垂直スライスビルド

claude "Add a comment system to blog posts. Requirements: comments stored in a PostgreSQL comments table with id, post_id, author_name, content, created_at. API endpoints: GET /posts/:id/comments and POST /posts/:id/comments with Zod validation. React component showing threaded comments with a reply form. Optimistic UI update on new comment submission. Rate limit to 5 comments per minute per IP. Include the database migration."

機能する理由: プロンプトがスライス全体をカバーしています。テーブル、API、UIが一つのリクエストで。楽観的レンダリング、レートリミット、マイグレーションファイルを指定することで、Claude が機能を一つの完成したユニットとして書きます。テスト時にギャップが露呈する3つの疎な断片としてではなく。

入れ替え例:

• リアルタイム: 「Add WebSocket support so new comments appear for all viewers without refreshing」
• モデレーション: 「Include an isApproved boolean field and an admin endpoint to approve/reject comments」

インフラとDevOps

CI/CDパイプライン

claude "Create a GitHub Actions workflow for this TypeScript monorepo. On push to main: run TypeScript type checking, run Vitest tests, build the Next.js app, and deploy to Vercel. On pull request: run type checking and tests only, post a preview deployment link as a PR comment. Cache node_modules between runs using pnpm lockfile hash. Fail fast if any step errors."

機能する理由: パイプラインプロンプトにはブランチルールを最初に書く必要があります。mainで実行するものとPRで実行するものを分け、キャッシュキーを指定し、プレビュー動作を名指しすることで、ワークフローが最初のプッシュで正しく機能します。「ああ、あとこれも追加して」を3ラウンド繰り返す必要がありません。

入れ替え例:

• Docker: 「Build and push a Docker image to GitHub Container Registry on main, tagged with the git SHA and 'latest'」
• マイグレーション: 「Add a step that runs Prisma migrations against the staging database before deployment, with a rollback step if deployment fails」

設定と環境

設定監査

claude "Audit this project's configuration. Check: tsconfig.json has strict mode enabled and proper path aliases. ESLint config catches unused imports, consistent formatting, and React hook dependency warnings. Package.json has correct scripts for dev, build, test, and lint. Environment variables are validated at startup (not just process.env access scattered through code). Flag any configuration that could cause silent failures in production."

機能する理由: 設定のバグは最悪の種類です。静かに失敗するか、特定の条件下でだけ失敗します。このプロンプトは重要な4つの面を Claude に指定し、本番環境での障害モードについて直接尋ねます。

使用原則

10のレシピが機能する理由は3つあります。これらは盗む価値があります。

形状を伝える、ゴールだけでなく。 「APIを作って」はゴールです。「これらのルートにZodバリデーションと一貫したエラーレスポンスを持つExpressエンドポイントを作って」は形状です。Claude は形状から逆算してそれに合わせて構築します。

制約を最初に書く。 書かない制約はコイントスになります。スタック、エラーハンドリング、スタイリング、ブラウザサポート、データベースエンジン。重要なら書いてください。書かなければ Claude が適切に見えるものを選びます。

退屈な要件を書き留める。 レートリミット。冪等性。ローディング状態。エラーバウンダリー。アクセシブルなラベル。これらはデモと実際のコードを分ける行であり、ほとんどのプロンプトが省いてしまう部分です。それらに少し余分な言葉を使うことで、後の何時間もの手直しが節約できます。

自分のライブラリを構築する

10のレシピはほぼすべてのプロジェクトに登場するパターンをカバーしています。ただし、あなたのコードベースには独自の形状と独自の難所があります。見返りは自分のテンプレートライブラリを維持することから生まれます。Claude Code の実行で良いものが生まれたら、プロンプトを保存してください。うまくいかなかった場合は、スペックのどの部分が欠けていたかを把握して追加します。