コーディング用プロンプトの書き方10パターン — AI を最大限に活かすプロンプトエンジニアリング

なぜコーディング用プロンプトに「型」が必要なのか

「AI にコードを書かせたけど、期待通りの結果にならない…」 その原因の多くは、プロンプトの書き方にあります。型を使うだけで、AIの出力品質は劇的に向上します。

AIコーディングアシスタント（Claude Code、GitHub Copilot、Cursor など）の出力品質は、プロンプトの質に大きく左右されます。曖昧な指示を出すと曖昧な結果が返り、具体的な指示を出すと具体的な結果が返ります。プロンプトの基本的な考え方についてはプロンプトエンジニアリング実践ガイドも参考にしてください。

プロンプトの質と出力品質の関係

曖昧なプロンプト → 動くけど微妙なコード → 手直しに時間がかかる
具体的なプロンプト → 期待通りのコード → すぐに使える

コーディング用プロンプトの基本構造

良いコーディングプロンプトには、以下の4要素が含まれています。

要素	説明	例
コンテキスト	背景情報、技術スタック	「TypeScript + React のプロジェクトで」
タスク	具体的にやってほしいこと	「ログイン機能を実装してください」
制約条件	守ってほしいルール	「Zustand を使い、any型は使わない」
出力形式	期待する出力の形	「テスト付きで、ファイルごとに分けて」

---

パターン1: バグ修正プロンプト

型

以下のバグを修正してください。

## 症状
[何が起きているか]

## 期待される動作
[本来どうなるべきか]

## 再現手順
1. [手順1]
2. [手順2]
3. [手順3]

## エラーメッセージ（あれば）
[エラーログやスタックトレース]

## 関連ファイル
[ファイルパス]

実例

以下のバグを修正してください。

## 症状
ユーザープロフィール画面で、画像アップロード後にプレビューが更新されない。
ページをリロードすると正しく表示される。

## 期待される動作
画像アップロード後、リロードなしでプレビューが新しい画像に更新される。

## 再現手順
1. /profile にアクセス
2. 「画像を変更」ボタンをクリック
3. 新しい画像を選択してアップロード
4. アップロード成功のトーストが表示されるが、プレビューは古い画像のまま

## エラーメッセージ
コンソールにエラーなし

## 関連ファイル
src/components/ProfileImageUploader.tsx
src/hooks/useProfile.ts

💡 Tips: バグ修正プロンプトでは「再現手順」と「期待される動作」を明確にすることが最も重要です。AIはこの差分から原因を推測します。

---

パターン2: リファクタリングプロンプト

型

以下のコードをリファクタリングしてください。

## 対象
[ファイルパスまたはコード]

## 現状の問題点
[なぜリファクタが必要か]

## リファクタの方針
[どのようにリファクタしたいか]

## 制約
- [変更してはいけないこと]
- [維持すべきインターフェース]

実例

以下のコードをリファクタリングしてください。

## 対象
src/services/orderService.ts

## 現状の問題点
- 1つの関数が200行を超えている
- 注文作成、在庫確認、決済処理、通知送信が1つのcreateOrder関数に混在
- ユニットテストが書けない構造

## リファクタの方針
- 単一責任の原則に基づいて関数を分割
- 各ステップを独立した関数に切り出す
- 依存性注入パターンを使いテスタブルにする

## 制約
- createOrder 関数の引数と戻り値の型は変えない
- 既存のAPIレスポンスに影響を与えない
- 段階的にリファクタ可能な形にする

---

パターン3: 新機能実装プロンプト

型

以下の新機能を実装してください。

## 機能概要
[何を実装するか]

## ユーザーストーリー
[誰が、何のために、何をしたいか]

## 技術要件
- [使用する技術・ライブラリ]
- [データ構造]
- [API設計]

## 受け入れ基準
- [ ] [基準1]
- [ ] [基準2]
- [ ] [基準3]

## 参考
[既存の類似機能、デザインモック等]

実例

以下の新機能を実装してください。

## 機能概要
ブログ記事の「いいね」機能

## ユーザーストーリー
読者として、気に入った記事に「いいね」を押して、著者にフィードバックを伝えたい。

## 技術要件
- フロント: React + Zustand
- API: Next.js Route Handlers
- DB: Prisma + PostgreSQL
- 認証なし（IPベースのレート制限で重複防止）
- リアルタイム更新不要（ページリロードで反映でOK）

## 受け入れ基準
- [ ] 記事ページに「いいね」ボタンが表示される
- [ ] クリックするとカウントが+1される
- [ ] 同じIPから同じ記事への重複いいねは24時間に1回まで
- [ ] いいね数がDBに永続化される
- [ ] ボタンにはアニメーションがある

---

パターン4: テスト生成プロンプト

型

以下のコードに対するテストを書いてください。

## テスト対象
[ファイルパスまたはコード]

## テストフレームワーク
[使用するフレームワーク]

## テスト方針
- [カバーしたいケース]
- [エッジケース]
- [モックの方針]

## 含めるべきテストケース
1. [正常系: xxx]
2. [異常系: xxx]
3. [境界値: xxx]

実例

以下のコードに対するテストを書いてください。

## テスト対象
src/utils/dateFormatter.ts

## テストフレームワーク
Vitest

## テスト方針
- 各フォーマッターの正常系を網羅
- タイムゾーンの影響を考慮
- nullやundefinedの入力をテスト
- モック: Date.now() を固定値にモック

## 含めるべきテストケース
1. 正常系: 日付文字列 → フォーマット済み文字列
2. 正常系: Dateオブジェクト → フォーマット済み文字列
3. 異常系: null入力 → デフォルト値を返す
4. 異常系: 不正な日付文字列 → エラーをスロー
5. 境界値: 年末年始（12/31 → 1/1）
6. 境界値: 閏年（2/29）

---

パターン5: コードレビュープロンプト

型

以下のコードをレビューしてください。

## レビュー観点
1. [バグの可能性]
2. [セキュリティ]
3. [パフォーマンス]
4. [可読性]
5. [テスタビリティ]

## コンテキスト
[このコードの役割、変更の背景]

## 特に確認してほしい点
[懸念している箇所]

実例

以下のコードをレビューしてください。

## レビュー観点
1. SQLインジェクションのリスクがないか
2. N+1クエリが発生していないか
3. エラーハンドリングが適切か
4. TypeScriptの型が正しく使われているか

## コンテキスト
ユーザー検索APIの新規実装。フロントエンドのオートコンプリート機能から呼ばれる。
リクエスト頻度は高い（キーストロークごと、ただしdebounce 300ms あり）。

## 特に確認してほしい点
- 検索クエリのサニタイズが十分か
- 高頻度アクセスに耐えるパフォーマンスか

---

パターン6: API設計プロンプト

型

以下の要件でAPIを設計してください。

## 機能
[APIが提供する機能]

## エンドポイント一覧
[想定しているエンドポイント]

## 設計方針
- [RESTful / GraphQL]
- [認証方式]
- [バージョニング]

## 考慮事項
- [ページネーション]
- [レート制限]
- [エラーレスポンス形式]

実例

以下の要件でREST APIを設計してください。

## 機能
ブログ記事のCRUD API

## エンドポイント（想定）
- 記事一覧の取得
- 記事詳細の取得
- 記事の作成
- 記事の更新
- 記事の削除
- 記事の検索

## 設計方針
- RESTful
- JWT認証（作成・更新・削除のみ）
- バージョニング: URLパス方式（/api/v1/）

## 考慮事項
- カーソルベースのページネーション
- レート制限: 認証あり100req/min、認証なし20req/min
- エラーレスポンス: RFC 7807 準拠
- レスポンスにはHATEOASリンクを含める

---

パターン7: DB スキーマ設計プロンプト

型

以下の要件でデータベーススキーマを設計してください。

## 要件
[管理したいデータの概要]

## エンティティ
[想定するテーブル/コレクション]

## 制約
- [DB: PostgreSQL / MySQL / MongoDB]
- [ORM: Prisma / TypeORM / Drizzle]
- [パフォーマンス要件]

## クエリパターン
[よく実行されるクエリの種類]

実例

以下の要件でPostgreSQLスキーマをPrisma形式で設計してください。

## 要件
ECサイトの商品管理システム

## エンティティ
- 商品（products）
- カテゴリ（categories）— 階層構造あり
- 商品画像（product_images）— 1商品に複数画像
- 在庫（inventory）— SKU単位
- レビュー（reviews）

## 制約
- PostgreSQL 16 + Prisma
- 商品数: 最大10万件
- ソフトデリート対応
- 多言語対応（将来）

## クエリパターン
- カテゴリ別の商品一覧（ページネーション付き）
- 商品の全文検索
- 在庫数での絞り込み
- レビューの平均スコアでのソート

---

パターン8: エラーハンドリング設計プロンプト

型

以下のアプリケーションのエラーハンドリング戦略を設計・実装してください。

## アプリケーション
[アプリの概要]

## 現状の問題
[今のエラーハンドリングの課題]

## 要件
- [ユーザーへのエラー表示]
- [ログ記録]
- [リトライ戦略]
- [エラー通知]

実例

Next.js App Router のエラーハンドリング戦略を設計・実装してください。

## アプリケーション
SaaS型のプロジェクト管理ツール（Next.js 15 + TypeScript）

## 現状の問題
- try-catch が各所にバラバラに書かれている
- エラーメッセージがユーザーに分かりにくい
- エラーログが構造化されていない
- APIエラーのレスポンス形式が統一されていない

## 要件
- グローバルエラーバウンダリ（error.tsx）の実装
- カスタムエラークラスの階層設計
- API Route での統一エラーレスポンス
- Sentry へのエラー送信
- ユーザー向けの分かりやすいエラーメッセージ
- リトライ可能なエラーの自動リトライ（最大3回、指数バックオフ）

---

パターン9: パフォーマンス最適化プロンプト

型

以下のパフォーマンス問題を分析・改善してください。

## 問題
[何が遅いか、具体的な数値]

## 計測結果
[Lighthouse、プロファイラ等の結果]

## 技術スタック
[使用している技術]

## 制約
- [変更可能な範囲]
- [UXへの影響を最小限に]

実例

以下のページのパフォーマンスを改善してください。

## 問題
トップページの表示が遅い

## 計測結果（Lighthouse）
- FCP: 3.1秒
- LCP: 5.4秒
- TBT: 920ms
- CLS: 0.12
- バンドルサイズ: 1.8MB（gzip後380KB）

## 技術スタック
Next.js 15, React 19, Tailwind CSS, Framer Motion, 画像20枚

## 制約
- デザインの大幅変更は不可
- Framer Motionのアニメーションは維持したい
- 画像の品質は許容範囲内で最適化OK

---

パターン10: ドキュメント・コメント生成プロンプト

型

以下のコードにドキュメント/コメントを追加してください。

## 対象
[ファイルパスまたはコード]

## ドキュメント形式
[JSDoc / TSDoc / PHPDoc / docstring]

## 含めてほしい情報
- [関数の説明]
- [パラメータの説明]
- [戻り値の説明]
- [使用例]
- [注意事項]

実例

以下のTypeScriptモジュールにTSDocコメントを追加してください。

## 対象
src/utils/validation.ts

## ドキュメント形式
TSDoc

## 含めてほしい情報
- 各関数の目的と動作説明
- パラメータの型・説明・制約
- 戻り値の説明
- 使用例（@example）
- スローする可能性のあるエラー（@throws）
- バリデーションルールの具体的な条件

---

AIツール別のプロンプトの書き分け

各ツールの特徴と最適なプロンプト

ツール	特徴	プロンプトのコツ
Claude Code	プロジェクト全体を把握、対話的	ファイルパスを具体的に指定、段階的に依頼
GitHub Copilot	エディタ統合、補完が得意	コメントでの指示、関数シグネチャの先行記述
Cursor	Cmd+K でインライン編集	選択範囲を明確に、変更の意図を簡潔に
ChatGPT	汎用的、会話が得意	コード全体をペースト、背景情報を丁寧に

Claude Code 向けのコツ

# コンテキストが豊富なプロンプト
claude "src/api/auth.ts のlogin関数にレート制限を追加してください。
既存のrateLimiterミドルウェア（src/middleware/rateLimiter.ts）を再利用し、
ログイン失敗時は5回/15分で制限をかけてください。
テストも追加してください。"

# CLAUDE.mdでルールを事前定義
# → プロンプトにルールを毎回書く必要がなくなる

GitHub Copilot 向けのコツ

// Copilot はコメントで指示すると補完精度が上がる

// ユーザーのメールアドレスをバリデーションする関数
// - RFC 5322 準拠
// - 日本語ドメインは非対応
// - 最大長は254文字
function validateEmail(email: string): boolean {
  // ← ここでCopilotが補完を提案
}

Cursor 向けのコツ

# Cmd+K でインライン編集する際のプロンプト例

# シンプルで具体的に
"この関数にエラーハンドリングを追加"

# 変更の意図を明確に
"try-catchで囲み、カスタムエラーをスロー"

# 制約を伝える
"既存のErrorHandlerクラスを使って"

---

プロンプト改善のチェックリスト

プロンプトを書いたら、送信前にこのチェックリストで確認しましょう。

基本チェック

• コンテキストが含まれている（技術スタック、ファイルパス）
• タスクが明確で具体的
• 制約条件を明記している
• 期待する出力形式を指定している

品質チェック

• 曖昧な表現を使っていない（「いい感じに」→「パフォーマンスを20%改善」）
• 必要な情報が不足していない
• 複数のタスクを1つのプロンプトに詰め込んでいない
• 「なぜ」そうしたいのかの背景を含めている

応用チェック

• エッジケースへの言及がある
• テストの要否を明記している
• 既存コードとの整合性に触れている
• 段階的に依頼する構成になっている（大きなタスクの場合）

---

よくあるアンチパターンと改善例

アンチパターン1: 曖昧すぎるプロンプト

# Bad
"認証機能を作って"

# Good
"JWT ベースのログイン・ログアウトAPIを実装してください。
技術スタック: Express + TypeScript + Prisma + PostgreSQL
エンドポイント: POST /api/auth/login, POST /api/auth/logout
トークン有効期限: アクセストークン15分、リフレッシュトークン7日"

アンチパターン2: 情報が多すぎて焦点がぼやける

# Bad（1つのプロンプトに全部詰め込む）
"認証機能、ユーザー管理、プロフィール編集、パスワードリセット、
2FA、OAuth連携、セッション管理を全部実装してください"

# Good（段階的に依頼）
"まず JWT 認証の基盤を実装してください。
次のステップで個別機能を追加していきます。
Phase 1: ログイン・ログアウト（今回）
Phase 2: パスワードリセット（次回）
Phase 3: OAuth連携（その次）"

アンチパターン3: ネガティブ指示だけ

# Bad（何をしてほしいか不明確）
"any型を使わないで、console.logを入れないで、
var を使わないで、==を使わないで"

# Good（ポジティブな指示に変換）
"TypeScriptの strict モードに準拠してください。
- 明示的な型定義を使用
- ロギングは既存のloggerユーティリティを使用
- const/let を使用（varは不可）
- 厳密等価演算子（===）を使用"

---

まとめ — 良いプロンプトは「具体的・構造的・段階的」

コーディング用プロンプトの品質を上げるために、以下の3原則を意識しましょう。

原則	実践方法
具体的	技術スタック、ファイルパス、数値目標を明記
構造的	型（テンプレート）を使い、必要な情報を漏れなく伝える
段階的	大きなタスクは分割して、1つずつ依頼する

この記事で紹介した10パターンのテンプレートを手元に置いておけば、AIコーディングアシスタントの出力品質が確実に向上します。最初は型をそのまま使い、慣れてきたら自分のプロジェクトに合わせてカスタマイズしていきましょう。AIによるコード補完をさらに使いこなしたい方は、AIコード補完のコツもあわせてご覧ください。