TL;DR
- Claude Code は「何を頼むか」でアウトプット品質が 3 倍変わる
- 実装・レビュー・リファクタ・テスト生成それぞれに特化したプロンプトパターンがある
- 本記事では実務 15 場面の「使えるプロンプト」を具体例付きで紹介する
はじめに
Claude Code(Anthropic 提供の CLI 型 AI コーディングアシスタント)を使い始めたものの「なんとなく指示している」状態のまま、微妙な回答を繰り返し修正している——そんな経験はありませんか。
Claude Code はプロンプトの設計次第で 返答の具体度・コードの正確性・ファイル操作の安全性 が大きく変わります。本記事では実務でそのまま使えるプロンプトパターンを 4 カテゴリ×15 パターン に整理しました。
前提環境: Claude Code (Anthropic 公式) / モデルは claude-3-5-sonnet / プロジェクトに
CLAUDE.mdあり
カテゴリ A:実装系 (5 パターン)
A-1. 「最小動作例を先に出してもらう」パターン
NG な頼み方:
axum で JWT 認証を実装して
推奨:
axum 0.8 + tower-http を使い、Authorization: Bearer <JWT> を検証する
最小構成の middleware を実装してください。
要件:
- HMAC-SHA256 署名検証のみ (RS256 は不要)
- 検証失敗時は 401 JSON を返す
- まず 50 行以内の最小動作コードを示し、その後で拡張ポイントを説明してください
なぜ効くか: "最小構成を先に" と明示することで、Claude が完全実装を一気に出そうとする傾向を抑制できます。小さいコードは レビューしやすく・差し込みやすい。
A-2. 「コンテキストを構造で渡す」パターン
## 現在の状況
- フレームワーク: Next.js 15 (App Router)
- 言語: TypeScript 5.5
- 認証: NextAuth v5 (beta)
- DB: PostgreSQL + Prisma 5
## やりたいこと
`/app/dashboard/page.tsx` で、ログイン済みユーザーのみ
閲覧できるサーバーコンポーネントを実装したい。
## 制約
- `use client` は使わない
- middleware.ts にロジックを書かない (既存の middleware と競合するため)
- session 取得は auth() ヘルパーを使う
## 期待するアウトプット
完成した page.tsx のコードのみ (説明は最後に 3 行で)
ポイント: 「状況 / やりたいこと / 制約 / 期待するアウトプット」の 4 段構成は Claude の回答精度を高める定番フレームです。
A-3. 「型定義を先に合意する」パターン
まず実装前に、以下の関数の TypeScript 型シグネチャだけを提案してください。
実装は型シグネチャに OK を出した後で書いてください。
関数の目的:
- API から受け取った snake_case の JSON を camelCase に変換する
- ネストされたオブジェクト・配列も再帰的に変換する
- 変換前後で型安全性を保つ
型シグネチャのみ → 私が確認 → 実装 という順番で進めましょう
なぜ有効か: 型を先に合意することで「動くけど型がひどい」コードを防げます。Claude は型定義フェーズで考慮漏れを指摘してくることも多い。
A-4. 「エラーを丸ごと渡す」パターン
以下のエラーが発生しています。原因と修正方法を教えてください。
## エラーメッセージ
Error: Cannot find module '@/lib/auth' or its corresponding type declarations.
at Object. (/app/api/users/route.ts:3:1)
## 関連ファイル構成
app/
api/
users/
route.ts ← エラー発生
lib/
auth.ts ← このファイルは存在する
tsconfig.json
## tsconfig.json の paths 設定
```json
{
"compilerOptions": {
"baseUrl": ".",
"paths": {
"@/*": ["./src/*"]
}
}
}
推測ではなく、このエラーが起きる具体的な原因を特定してください。
**ポイント**: エラー文・ファイル構成・関連設定を同時に渡すと、Claude が「たぶんこれ」ではなく「これが原因」と断定的に答えられます。
---
### A-5. 「段階的に難しくする」パターン
Rust で非同期 HTTP クライアントを実装します。
以下の順番で段階的に実装を進めてください。
Step 1: reqwest を使い GET リクエストを送るだけの 20 行
Step 2: Step 1 に timeout と retry (3回・exponential backoff) を追加
Step 3: Step 2 に rate limiter (token bucket) を組み込む
まず Step 1 だけ実装してください。
**なぜ有効か**: 一度に全部頼むと Claude は「最終形」を想定して長いコードを出します。段階的に頼むと各ステップのコードが短くレビューしやすい。
---
## カテゴリ B:コードレビュー系 (4 パターン)
### B-1. 「観点を指定したレビュー」パターン
以下のコードを 3 つの観点でレビューしてください。
観点 1: セキュリティ (XSS・CSRF・SQL インジェクション等)
観点 2: パフォーマンス (N+1 クエリ・不要な再レンダリング等)
観点 3: 可読性 (命名・責務の分離・コメントの過不足)
重大度を 🔴 致命的 / 🟡 改善推奨 / 🟢 提案 の 3 段階で付けてください。
// ここにコードを貼る
---
### B-2. 「レビューコメントの文章を生成する」パターン
以下のコードの問題点について、GitHub PR のレビューコメントとして
使える文章を生成してください。
条件:
- 指摘は建設的な口調 (否定形を避ける)
- 問題の説明 + 改善案のコードを含める
- 日本語・敬語不要・エンジニア同士の口語体
コード:
def get_user(user_id):
conn = psycopg2.connect("host=localhost dbname=app user=admin password=secret")
cur = conn.cursor()
cur.execute(f"SELECT * FROM users WHERE id = {user_id}")
return cur.fetchone()
---
### B-3. 「差分レビュー」パターン
以下の変更前→変更後のコード差分をレビューしてください。
変更の意図: N+1 クエリを解消するためにクエリを集約した
変更前
for order in orders:
user = User.objects.get(id=order.user_id)
print(user.name)
変更後
user_ids = [o.user_id for o in orders]
users = {u.id: u for u in User.objects.filter(id__in=user_ids)}
for order in orders:
print(users[order.user_id].name)
確認してほしい点:
- 意図通りに N+1 は解消できているか
- user_id が存在しない場合の KeyError リスクはあるか
- より Pythonic な書き方があるか
---
### B-4. 「セキュリティ専門レビュー」パターン
以下のコードに対して、OWASP Top 10 の観点からセキュリティレビューを行ってください。
各脆弱性について:
- 該当する OWASP カテゴリ番号
- 攻撃シナリオの具体例
- 修正コード
問題がない項目は「問題なし」とだけ記載してください。
// ここにコードを貼る
---
## カテゴリ C:リファクタリング系 (3 パターン)
### C-1. 「段階的リファクタリング計画を立てる」パターン
以下のファイルをリファクタリングしたいのですが、
一気に書き換えると動作確認が難しくなります。
以下の情報をもとに「安全にリファクタリングするための手順」を
5 ステップ以内で提示してください。
現状の問題:
- 1 ファイル 600 行
- 関数 1 つに 150 行の処理が詰まっている
- テストがない
目標:
- 責務を 3-4 クラスに分割
- 各クラスは単体テスト可能な設計にする
制約:
- 既存の外部 API インターフェースは変えない
- 本番稼働中なので壊せない
ステップは「このステップを踏めば常に動く状態を保てる」順序にしてください。
---
### C-2. 「命名リファクタ」パターン
以下のコードの変数名・関数名・型名をリファクタリングしてください。
ルール:
- 省略は禁止 (tmp, val, d, obj 等は使わない)
- 動詞始まりの関数名 (get / fetch / update / handle 等)
- boolean は is / has / can / should で始める
- 変更後のコードと、変更一覧表 (旧名 → 新名) を両方出してください
const d = await getData();
const tmp = d.filter(x => x.flag);
function proc(items: any[]) { ... }
---
### C-3. 「パフォーマンス特化リファクタ」パターン
以下の React コンポーネントのパフォーマンスを改善してください。
現在の問題:
- 親が再レンダリングするたびに子も全て再レンダリングされている
- リスト件数が 500 件を超えると FPS が落ちる
試したこと:
- React.memo を付けたが効果がなかった
以下の観点で原因特定と改善策を提示してください:
- なぜ React.memo が効かなかったのか
- useMemo / useCallback で改善できる箇所
- 仮想スクロール (react-window 等) が必要になる閾値
// ここにコードを貼る
---
## カテゴリ D:テスト生成系 (3 パターン)
### D-1. 「境界値を網羅したテスト生成」パターン
以下の関数に対して Jest のユニットテストを生成してください。
要件:
- 正常系 3 ケース
- 異常系 (バリデーションエラー) 3 ケース
- エッジケース (境界値・空配列・null 等) 3 ケース
- 各テストケースにコメントで「何を確認しているか」を書く
function calcDiscount(price: number, memberType: 'gold' | 'silver' | 'normal'): number {
if (price < 0) throw new Error('Price must be non-negative');
const rate = { gold: 0.2, silver: 0.1, normal: 0 }[memberType];
return Math.floor(price * (1 - rate));
}
---
### D-2. 「モック戦略を指定したテスト生成」パターン
以下のサービスクラスのテストを書いてください。
モック方針:
- 外部 HTTP リクエスト (axios) は jest.mock でモック
- DB アクセス (Prisma) はインメモリ実装を使う (jest.mock は使わない)
- 時刻依存処理は jest.useFakeTimers() で固定
テスト対象:
- sendNotification() のみ (他のメソッドは今回スキップ)
- 成功時・HTTP エラー時・タイムアウト時の 3 ケースを書く
// ここにコードを貼る
---
### D-3. 「E2E テストシナリオ設計」パターン
以下のユーザーストーリーをもとに Playwright の E2E テストシナリオを設計してください。
ユーザーストーリー:
「ユーザーはカートに商品を追加し、クレジットカードで決済できる」
出力してほしいもの:
- ハッピーパスのシナリオ (正常系)
- 決済エラー時のシナリオ (カード番号不正)
- 在庫切れ時のシナリオ
形式:
- Playwright の test() ブロックを使う
- page.getByRole() / page.getByTestId() を優先する (XPath は禁止)
- 決済部分は Stripe Test Mode のカード番号 4242... を使う
---
## おまけ:CLAUDE.md に書くと捗る設定
Claude Code は **プロジェクトルートに `CLAUDE.md` を置く**ことで、毎回プロンプトで説明しなくてもプロジェクト固有のルールを記憶させられます。
```markdown
# CLAUDE.md
## 技術スタック
- Node.js 22 / TypeScript 5.5
- Next.js 15 (App Router)
- テスト: Vitest
- スタイル: Tailwind CSS v4
## コーディング規約
- 関数は 30 行以内に収める
- `any` 型は使用禁止
- コメントは「なぜ」を書く (「何を」はコードを読めばわかる)
## 実装時のデフォルト
- エラーハンドリングは Result 型パターンを使う
- ログは console.log 禁止・logger.ts の関数を使う
- 環境変数は env.ts を通して取得する (process.env 直読み禁止)
## テスト
- ユニットテストは __tests__/ ではなく同階層に .test.ts で置く
- テストカバレッジ目標: 80%
これを書いておくだけで「毎回 TypeScript 5.5 です」「any 禁止にしてください」と伝える手間が省けます。
まとめ
| カテゴリ | 重要なコツ |
|---|---|
| 実装 | 最小例 → 拡張の順・型シグネチャを先に合意 |
| レビュー | 観点と重大度を指定・OWASP 等フレームワークを活用 |
| リファクタ | 段階的手順を先に設計・命名改善は一覧表付きで |
| テスト | 境界値・モック方針・カバレッジ目標を明示 |
Claude Code の真価は「何を求めているか」を明確に伝えたときに発揮されます。本記事のパターンをそのままコピーして使い、自分のプロジェクトに合わせてカスタマイズしてみてください。
参考リンク
- Claude Code 公式ドキュメント
- Anthropic プロンプトエンジニアリングガイド
- CLAUDE.md のベストプラクティス (公式)
- Playwright 公式ドキュメント
- OWASP Top 10 (2021)
✍️ 本記事の著者: 合同会社ジモラボ
ジモラボは、八王子を拠点に AI を活用した SaaS を多数開発しています。本記事の技術検証もそうした開発過程の副産物です。
- 🌐 公式サイト: https://locallab.jp
- 🔍 AI SEO 最適化 SaaS: lookupai.jp
- 📺 YouTube: @locallab_llc
- ✉️ お問い合わせ: info@locallab.jp
興味を持っていただけたら、ぜひ各 SNS のフォローもお願いします!