TL;DR
- Claude Code は「タスク丸投げ」より「構造化した指示」の方が 3 倍以上アウトプット品質が上がる
- CLAUDE.md によるコンテキスト常駐化・サブエージェント分割・差分レビューの 3 つが特に効果大
- 本記事では実務で繰り返し使えるプロンプトパターンを 7 つ体系化した
はじめに
Anthropic が 2025 年に GA した Claude Code は、ターミナル上で動く自律 AI コーディングエージェントだ。VS Code 拡張や Cursor とは異なり、シェル・Git・ファイルシステムに直接アクセスしながらタスクを完遂する設計になっている。
しかし「凄そうだけど指示の仕方がわからない」「なんか期待と違うアウトプットが返ってくる」という声をよく聞く。そこで本記事では、実務レベルで何度も使って精度が上がったプロンプトパターンを 7 つに整理した。
対象読者は Claude Code をすでに導入済みで、もっとうまく使いたい中〜上級エンジニア だ。基本セットアップの説明は省略する。
Pattern 1: 「ゴール → 制約 → 禁止事項」の 3 段構成
問題: 「○○を実装して」だけでは Claude Code が解釈を広げすぎて、不要な依存を追加したり、既存コードを大幅に書き換えたりする。
パターン:
## Goal
<1 行で何を達成するか>
## Constraints
- 変更してよいファイル: src/api/users.ts のみ
- 使用ライブラリ: 既存の package.json の範囲内
- レスポンス型は既存の UserResponse 型を流用
## Do NOT
- テストファイルを変更しない
- 型定義を削除しない
- console.log を残さない
なぜ効くか: Claude Code は「やっていいこと」より「やってはいけないこと」を先に把握すると変更スコープを絞る傾向がある。特に Do NOT セクションはゼロショットより一貫して精度が上がる。
Pattern 2: CLAUDE.md によるプロジェクト知識の常駐化
Claude Code はリポジトリルートに CLAUDE.md があると、セッション開始時に自動で読み込む。ここにプロジェクト固有の知識を書いておくと、毎回「このプロジェクトは〜」と説明する手間が省ける。
CLAUDE.md の最小構成テンプレート:
# Project Overview
<プロジェクトの目的を 3 行で>
# Architecture
- フレームワーク: Next.js 14 App Router
- DB: PostgreSQL + Drizzle ORM
- 認証: Auth.js v5
# Conventions
- コンポーネントは server component を default にし、必要な時だけ `"use client"` を付ける
- API ルートは src/app/api/ 配下に配置
- エラーは Result 型 (neverthrow) で統一・例外を throw しない
# File Structure
src/
├── app/ # Next.js App Router
├── components/ # 共通 UI
├── lib/ # ビジネスロジック
└── types/ # 型定義
# Testing
- Vitest + Testing Library
- `pnpm test` でローカル実行
- `pnpm test:coverage` でカバレッジレポート
ポイント: CLAUDE.md は 50 行以内 を目安に保つ。長くなるほど重要箇所が埋没する。詳細な仕様は別ファイルに切り出して @import で参照するのが効果的。
Pattern 3: 差分 (diff) 前提のレビュー依頼
コード生成後に「レビューして」と指示するより、diff を渡してレビューさせる方が精度が高い。
# 先に diff を作っておく
git diff main HEAD > /tmp/review.patch
# Claude Code に投げる
cat /tmp/review.patch | claude "
以下の diff をレビューしてください。
観点:
1. バグの可能性 (特に null/undefined アクセス)
2. パフォーマンス上の問題
3. セキュリティ (SQLインジェクション・XSS等)
4. 型の不整合
各問題は severity: [critical/major/minor] で分類し、
具体的な行番号と修正案を示してください。
レビューが不要な diff は「問題なし」とだけ出力してください。
"
コツ: 「全体的に問題ないか見て」という漠然とした依頼より、観点を明示する方が actionable なフィードバックが返る。
Pattern 4: サブタスク分割による精度向上
大きなタスクを一度に投げると、Claude Code は途中で迷走しやすい。タスクを明示的に分割して順序を指定すると品質が安定する。
以下のタスクを順番に実行してください。
各ステップ完了後に「Step N 完了」と報告してから次に進んでください。
Step 1: src/lib/payment.ts の既存コードを読んで、
現在の型定義と処理フローを要約してください (コードは変更しない)
Step 2: Step 1 の要約を踏まえ、以下の仕様変更の影響範囲を列挙してください
仕様変更: 支払い方法に "bank_transfer" を追加する
Step 3: Step 2 で列挙したファイルのみを変更し、実装してください。
変更後は TypeScript コンパイルエラーがゼロであることを確認してください
Step 4: 追加した "bank_transfer" に対応する Vitest テストを 1 件書いてください
なぜ効くか: Claude Code はコンテキストウィンドウの後半になると初期の指示を「忘れがち」になる。ステップ報告を挟むことで 中間チェックポイント を作り、脱線を防ぐ。
Pattern 5: TDD ドリブン実装 (テストを先に書かせる)
「実装してからテストを書いて」より「テストを書いてから実装させる」方が Claude Code の仕様理解が深まる。
以下の仕様に基づいて、まず Vitest のテストケースだけを書いてください。
実装は書かないでください。
仕様:
- 関数名: calculateDiscount(price: number, memberType: "general" | "premium" | "vip"): number
- general: 割引なし (price をそのまま返す)
- premium: 10% 割引
- vip: 20% 割引
- price が負の値の場合は Error をスロー
- 小数点は Math.floor で切り捨て
テストケースは境界値 (0円・1円・負の値) を必ず含めてください。
テストが揃ったら次のプロンプトで実装を依頼する:
先ほど書いたテストがすべてパスするように calculateDiscount を実装してください。
`pnpm test src/lib/discount.test.ts` を実行して全件グリーンになったら完了です。
Pattern 6: エラーログを「そのまま」貼り付ける
エラーの説明を自分で要約して渡すより、ログをそのまま貼る方がはるかに診断精度が高い。
以下のエラーが本番環境で発生しています。
原因を特定して修正案を提示してください。
---
TypeError: Cannot read properties of undefined (reading 'userId')
at getUserProfile (src/lib/users.ts:47:32)
at async ProfilePage (src/app/profile/page.tsx:12:18)
at async renderWithHooks (node_modules/react-dom/...)
---
関連ファイル: src/lib/users.ts, src/app/profile/page.tsx
修正する前に、まず「なぜこのエラーが起きているか」の仮説を 2〜3 個挙げてください。
最も可能性の高い仮説を選んだ上で修正してください。
ポイント: 「まず仮説を挙げてから」という一文を加えると、Claude Code が自分で推論ステップを踏むため、修正の見当外れが減る。
Pattern 7: リファクタリングの「変更しない部分」を明示する
既存コードのリファクタリングを頼むと、意図せずインターフェースや型が変わってしまうことがある。これを防ぐパターン:
以下のコードをリファクタリングしてください。
## 変更してよい
- 関数内の実装詳細
- 変数名・コメント
- 重複ロジックの抽出
## 絶対に変えてはいけない
- 関数のシグネチャ (引数・戻り値の型)
- エクスポートしている名前
- 外部から観測できる振る舞い (= 既存テストは全件パスのまま)
リファクタリング完了後に `pnpm test` を実行し、
グリーンのスクリーンショット相当のテスト出力を貼ってください。
7 パターンのまとめ
| # | パターン名 | 主な効果 |
|---|---|---|
| 1 | ゴール → 制約 → 禁止事項 | 変更スコープの限定 |
| 2 | CLAUDE.md 常駐化 | コンテキスト説明コストの削減 |
| 3 | diff レビュー | 精度の高いコードレビュー |
| 4 | サブタスク分割 | 長大タスクの脱線防止 |
| 5 | TDD ドリブン | 仕様の明確化・品質担保 |
| 6 | エラーログ直貼り | 診断精度の向上 |
| 7 | 変更禁止範囲の明示 | リファクタリング時の安全性確保 |
これらは単体でも効くが、組み合わせることで相乗効果が出る。たとえば「CLAUDE.md (Pattern 2) + サブタスク分割 (Pattern 4) + TDD (Pattern 5)」は大きな機能追加を安全に進める鉄板セットになっている。
おわりに
Claude Code は「自律エージェント」という性質上、良い指示を与えるほど良い結果を返す、という正の相関が強い。本記事のパターンを土台に、自分のプロジェクト・チームの慣習に合わせてカスタマイズしていただければ幸いだ。
コメント欄で「このパターンも効いた」「うまくいかなかった」など、ぜひ知見を共有してほしい。
参考リンク
✍️ 本記事の著者: 合同会社ジモラボ
ジモラボは、八王子を拠点に AI を活用した SaaS を多数開発しています。本記事の技術検証もそうした開発過程の副産物です。
- 🌐 公式サイト: https://locallab.jp
- 🔍 AI SEO 最適化 SaaS: lookupai.jp
- 📺 YouTube: @locallab_llc
- ✉️ お問い合わせ: info@locallab.jp
興味を持っていただけたら、ぜひ各 SNS のフォローもお願いします!