Claude Codeに最初に渡すべき指示テンプレート集
はじめに
Claude Codeを初めて使う人が陥りやすい落とし穴は、曖昧な指示を出してしまうことです。Claude Codeに全部任せると危ない理由では問題を説明しました。本記事では、安全かつ効果的な指示を出すためのテンプレートを、実務的な例を交えて紹介します。
テンプレート1：シンプルなファイル編集
対象ファイル: src/utils/helper.ts のみ
実装内容:
- formatDate() 関数を追加
- 入力: Date オブジェクト
- 出力: "2026-06-22" 形式の文字列
- パラメータなし
他のファイルは変更しないでください。
実装完了後、変更内容を説明してください。
ポイント：
- ファイルを明確に指定
- 関数の入出力を定義
- 「他のファイルは変更しない」と明示
テンプレート2：テストコード追加
対象ファイル:
- src/utils/helper.ts（追加のみ）
- tests/utils/helper.test.ts（作成または追加）
タスク:
helper.ts に getInitials(name: string): string 関数を追加。
- 入力：フルネーム
- 出力：大文字イニシャル（最大3文字）
- 例：「Tanaka Yuki」→「TY」
対応するテストケースを tests/ に追加してください。
実装前に、変更計画を出してください。
ポイント：
- テストとソースを一緒に明示
- 具体的な例を提示
- 計画確認のステップを挟む
テンプレート3：リファクタリング（小規模）
対象ファイル: src/services/auth.ts のうち、login() 関数のみ
現在の問題:
login() が 60 行で長い。エラーハンドリング部分を extractErrorMessage() 関数に分離したい。
要件:
- extractErrorMessage() は同じファイル内に新しく作成
- login() の機能は変わらない（既存テストで検証可能）
- git diff で変更が明確に見えること
実装前に変更計画を確認させてください。
実装後に git diff を実行して確認します。
ポイント：
- 範囲を明確に限定
- 「既存テストで検証可能」と明記
- diff 確認ステップを含める
テンプレート4：複数ファイル・計画確認必須
スコープ: 全体
背景: src/api/ 内で複数の関数が同じ HTTP エラーハンドリングをしているため、重複を削除したい。
ステップ1（まずこれだけ実行）:
src/api/ 内のファイル一覧を確認し、
- エラーハンドリングの重複部分
- 共通化できる部分
- リスク（破壊的変更の可能性）
を分析して、改善計画を提示してください。
実装はしないでください。計画だけ出してください。
ポイント：
- 複雑なタスクは計画と実装を分離
- 「実装はしないでください」と明示
- 人間が計画を審査するステップを設ける
テンプレート5：ドキュメント追加
対象ファイル: README.md のみ
タスク:
セットアップの説明セクションに、新しい環境変数 REDIS_URL の設定手順を追加。
- 存在するセクション構造を保持
- 他の説明は変更しない
- 日本語で、初心者にもわかりやすく
実装例がない場合は実装例を src/config.ts から抽出して含める。
完了後、変更内容を簡潔に説明してください。
ポイント：
- ドキュメント編集も「対象ファイル限定」
- トーン・audience を指定
- 既存構造の保持を強調
避けるべき指示パターン
❌ 悪い例1：「このプロジェクト全体をモダナイズしてください」 ✅ 改善：「src/components/Button.tsx を React Hooks に移行してください。他のコンポーネントは変更しないでください」
❌ 悪い例2：「エラーハンドリングを改善してください」 ✅ 改善：「src/api/users.ts の fetchUser() 関数が404の場合、エラーメッセージを “User not found” に統一してください」
❌ 悪い例3：「テストを追加してください」 ✅ 改善：「src/utils/validator.ts の isEmail() 関数に対するテストを tests/utils/validator.test.ts に5ケース追加してください。テストケース：正常系、空文字、不正形式、長すぎる、スペース含む」
まとめ
安全で効果的な Claude Code の使い方は、git diff で確認できる小さな変更を積み重ねることです。
最初の指示は：
- スコープを明確に：対象ファイル、関数、セクションを限定
- 入出力を定義：何を入れて何が出てくるか
- 計画確認のステップを挟む：いきなり実装させない
- 人間の確認を組み込む：git diff 、単体テスト、動作確認
これらのテンプレートを参考に、タスク分解に基づいた指示を実践してください。