Claude Codeへの頼み方は、毎回ゼロから考える必要はありません。
調査だけ頼むとき、バグを直してほしいとき、新しいツールを作りたいとき、READMEを整えたいとき。それぞれで、入れるべき情報は少し違います。
No.7では、指示文に何を書くかを整理しました。目的、対象、作業範囲、やらないこと、完了条件です。この記事では、そこから一歩進んで、そのまま貼って使える依頼文テンプレートを用途別にまとめます。
この記事は考え方の説明ではなく、作業場で使う型の一覧です。角括弧の中を自分の内容に置き換えて使ってください。
依頼文は用途ごとに分ける
Claude Codeに頼む作業は、大きく分けると次の3つです。
- 調査する
- 計画する
- 編集する
この3つを混ぜると、Claude Codeがどこまで進んでよいのか曖昧になります。調査だけのつもりだったのに、ファイル編集まで進む。計画だけ見たかったのに、実装まで始まる。こういうズレが起きます。
まず「調査」「計画」「編集」を選ぶ
貼る前に、まず自分が頼みたい作業を1つ選びます。
| やりたいこと | 選ぶ依頼 | 最初の一文 |
|---|---|---|
| 原因を知りたい | 調査 | まだ編集せず、原因を調査してください。 |
| どう直すか見たい | 計画 | まず実装計画だけを出してください。 |
| 小さく直したい | 編集 | 次の範囲で修正してください。 |
| 新しく作りたい | 計画から作成 | まず計画を出し、問題なければ実装してください。 |
| 文章を整えたい | ドキュメント化 | 読み手に合わせてREADMEを整理してください。 |
迷ったら、編集から入らず調査か計画を選びます。差分が大きくなる前に止められるからです。
調査だけ頼むテンプレート
調査依頼では、最初に「編集しない」と書きます。Claude Codeは原因を見つけると、そのまま直そうとすることがあります。調査と編集を分けたいときは、ここを曖昧にしません。
不具合の原因を調べる
エラーは出ているが、どこを直せばよいか分からないときのテンプレートです。
[起きている不具合] の原因を調査してください。
まだファイルは編集しないでください。
削除、移動、設定変更、パッケージ追加も行わないでください。
状況は次の通りです。
- 何をしたか: [例: ログインフォームで送信ボタンを押した]
- 起きたこと: [例: 画面が白くなった]
- 期待すること: [例: ログイン成功時はダッシュボードへ移動する]
- 自分が確認したこと: [例: ブラウザを再読み込みしても変わらなかった]
- エラー文: [分かれば貼る。なければ「なし」]
- 関係しそうなファイル: [分かれば書く。分からなければ「不明」]
調査で見てほしいことは次の通りです。
- 原因の候補
- 関係しそうなファイル
- 修正が必要そうな箇所
- 追加で確認すべきログやコマンド
- いま分かっていないこと
コマンド実行が必要な場合は、実行前に目的を短く説明してください。
調査結果を出したあと、まだ実装には進まないでください。この依頼では、最後にも「まだ実装には進まない」と入れています。調査だけで止めたいときは、しつこいくらいでちょうどよいです。
関係ファイルを探す
どのファイルを見ればよいか分からないときに使います。
[やりたい変更] に関係しそうなファイルを探してください。
まだファイルは編集しないでください。
探してほしい内容は次の通りです。
- 画面や機能の入口になっているファイル
- 状態管理やAPI呼び出しに関係しそうなファイル
- 共通コンポーネントとして使われていそうなファイル
- テストがある場合は、その場所
出力は次の形式にしてください。
- ファイルパス
- そのファイルの役割
- 今回の作業と関係しそうな理由
- 編集候補に入れるべきかどうか
分からないものは推測で決めず、「不明」と書いてください。
調査後、編集には進まないでください。ファイル名が分からないまま編集を頼むと、作業範囲が広がります。先に探してもらうほうが安全です。
既存コードの流れを説明してもらう
初めて触るコードでは、先に流れを説明してもらいます。
[対象の機能] の処理の流れを説明してください。
まだファイルは編集しないでください。
知りたいことは次の通りです。
- ユーザー操作から処理が始まる場所
- 呼び出される主な関数やコンポーネント
- APIやデータ保存に進む場合の流れ
- エラー時の処理
- 変更するなら注意すべき場所
説明は、初心者にも追えるように、処理順で書いてください。
必要なら関係ファイルを読んで構いません。
ただし、ファイル編集、削除、移動、設定変更はしないでください。コードを読まずに修正へ入るより、最初に流れを言葉にしてもらうほうが確認しやすくなります。
計画だけ頼むテンプレート
計画依頼では、実装前に「何を変えるか」を出してもらいます。複数ファイルにまたがる変更や、新規作成では特に役立ちます。
小さな修正の計画を出す
小さな修正でも、どこを触るか見てから進めたいときに使います。
[やりたい修正] を進めたいです。
まず実装計画だけを出してください。
まだファイル作成、ファイル編集、削除、移動、コマンド実行はしないでください。
目的は次の通りです。
- [例: 保存後に成功メッセージを表示して、ユーザーが完了を分かるようにする]
対象は次の範囲です。
- 画面: [例: プロフィール編集画面]
- 関係しそうなファイル: [例: `src/pages/ProfileEdit.tsx`。不明なら「調査して候補を出す」]
- 変更してよい範囲: [例: UI表示とメッセージ表示だけ]
やらないことは次の通りです。
- [例: API仕様は変えない]
- [例: 認証処理は触らない]
- [例: 新しいライブラリは追加しない]
計画には次を含めてください。
- 読むべきファイル
- 変更が必要そうなファイル
- 具体的な変更内容
- 影響が出そうな箇所
- 実装後の確認方法
- 不明点や、先に私へ確認したいこと
計画を出したあと、私が承認するまで実装に進まないでください。複数ファイルにまたがる変更を見積もる
変更が大きくなりそうなときは、見積もりから始めます。
[変更したい内容] は複数ファイルに影響しそうです。
まず作業範囲を見積もってください。
まだファイルは編集しないでください。
確認してほしいことは次の通りです。
- 変更が必要そうなファイル一覧
- それぞれのファイルで行う作業
- 影響しそうな画面や機能
- 既存テストがあるか
- 追加または更新したほうがよいテスト
- 作業を小さく分けるなら、どの順番がよいか
出力は、次の形にしてください。
1. 今回の作業範囲
2. 変更候補ファイル
3. リスクが高い箇所
4. 小さく進める場合の手順
5. 最初に実装するならどこから始めるか
この時点では実装に進まないでください。大きい変更は、いきなり始めるより分割案を出してもらいます。
新規作成の前に作業範囲を決める
新しいツールや画面を作る前のテンプレートです。
Claude Codeで新しい [作りたいもの] を作りたいです。
まず実装計画だけを出してください。
まだファイル作成、ファイル編集、コマンド実行はしないでください。
作りたいもの:
[例: Markdown本文を貼ると、文字数、見出し数、コードブロック数を数える小さなWebツール]
使う人:
[例: 自分だけ。社内共有はまだしない]
使う場面:
[例: ブログ記事を公開する前に、本文量をざっくり確認したい]
最初の版で必要な機能:
- [例: テキストを貼り付ける入力欄]
- [例: 文字数を表示する]
- [例: H2とH3の数を表示する]
- [例: コードブロック数を表示する]
- [例: 入力内容をクリアするボタン]
今回は入れない機能:
- 保存機能
- ログイン
- サーバー連携
- データベース
- 外部API
- 複雑なデザイン
計画には次を含めてください。
- 作成するファイル
- 画面に置く要素
- 処理の流れ
- ローカルで動かす方法
- 完成後の確認方法
- 今回あえて入れないもの
計画を出したあと、私が承認するまで実装に進まないでください。バグ修正を頼むテンプレート
バグ修正では、症状、期待する動き、確認方法を入れます。エラー文があるなら、そのまま貼ります。
エラー文がある場合
次のエラーを修正してください。
エラー文:
[ここにエラー文を貼る]
状況:
- 何をしたか: [例: `npm run build` を実行した]
- 起きたこと: [例: TypeScriptのエラーでビルドが止まった]
- 期待すること: [例: ビルドが通る]
- 関係しそうなファイル: [分かれば書く。不明なら「調査して候補を出す」]
作業の進め方:
1. まず原因を確認してください。
2. 修正が必要なファイルを特定してください。
3. 最小限の変更で修正してください。
4. 修正後に確認コマンドを実行してください。
やらないこと:
- エラーを隠すためだけの変更はしない
- 型を安易に `any` にしない
- 関係のない整形変更はしない
- 新しいライブラリは追加しない
作業後に、変更したファイル、原因、修正内容、確認結果を報告してください。エラー文がある場合は、説明し直すより貼ったほうが早いです。
画面の動きがおかしい場合
画面の不具合は、再現手順を入れます。
[画面名] の動きがおかしいので修正してください。
再現手順:
1. [例: ログイン画面を開く]
2. [例: メールアドレスとパスワードを入力する]
3. [例: 送信ボタンを押す]
起きていること:
[例: 送信後に画面が白くなる]
期待すること:
[例: 成功時はダッシュボードへ移動し、失敗時はエラーメッセージを表示する]
対象:
[例: ログイン画面に関係するファイル。不明なら調査して候補を出す]
やらないこと:
- 認証方式そのものは変えない
- API仕様は変えない
- デザイン全体を作り替えない
- 関係のないファイルは編集しない
完了条件:
- 再現手順で同じ問題が起きない
- 失敗時のエラー表示が確認できる
- 成功時の動きが確認できる
確認できるコマンドや手順があれば実行し、結果を報告してください。画面の不具合では「期待すること」を必ず書きます。壊れている状態だけだと、正しい状態が分からないからです。
修正後に確認まで頼む
修正と確認を同じ依頼に入れると、報告が読みやすくなります。
次の不具合を修正し、修正後に確認まで行ってください。
不具合:
[例: 入力エラーがあるとき、どの項目が問題なのか表示されない]
期待する動き:
[例: 必須項目が空の場合、該当項目の下にエラーメッセージが表示される]
編集してよい範囲:
- [例: `src/components/SignupForm.tsx`]
- [例: 必要な場合のみ、同じ画面で使っている型定義]
やらないこと:
- API呼び出しの処理は変更しない
- バリデーションルール自体は変更しない
- 新しいライブラリは追加しない
- 関係のない整形変更はしない
確認してほしいこと:
- エラーがある場合にメッセージが出る
- エラーがない場合に既存の送信処理が動く
- 既存の見た目から大きく変わらない
作業後に、変更したファイル、確認した内容、確認できなかったことを報告してください。
tomo「修正して」だけだと、確認の基準が曖昧になります。確認してほしいことまで書くと、Claude Codeの最後の報告も判断しやすくなります。
新規作成を頼むテンプレート
新規作成は、短い依頼ほど大きくなります。最初の版では、入れない機能をはっきり書きます。
1ファイルHTMLツールを作る
ブラウザで直接開ける小さなツールを作るテンプレートです。
ブラウザで直接開ける、1ファイルHTMLの小さなツールを作ってください。
作りたいもの:
[例: Markdown本文を貼ると、文字数、見出し数、コードブロック数を数えるツール]
使う人:
[例: 自分だけ]
使う場面:
[例: ブログ記事を公開する前に、本文量をざっくり確認したい]
必要な機能:
- [例: テキストを貼り付ける入力欄]
- [例: 文字数を表示する]
- [例: H2とH3の数を表示する]
- [例: コードブロック数を表示する]
- [例: 入力内容をクリアするボタン]
今回は入れない機能:
- 保存機能
- ログイン
- サーバー連携
- データベース
- 外部API
- npmやビルド環境
- 複雑なデザイン
技術スタック:
`index.html` だけで動く形にしてください。
CSSとJavaScriptも同じファイル内に書いてください。
作業場所:
[例: 現在のフォルダに新規作成する]
既存ファイルがある場合は上書きせず、先に確認してください。
作業後に報告してほしいこと:
- 作成したファイル
- ブラウザで開く方法
- 動作確認した内容
- 次に機能追加するなら触る場所1ファイルHTMLは、最初の練習に向いています。環境構築で詰まりにくいからです。
ReactやViteで小さく作る
Reactを使う場合でも、最初から広げすぎないようにします。
React + Viteで小さなWebアプリを作ってください。
作りたいもの:
[例: 今日やるタスクを追加して、完了チェックできる小さなタスク管理アプリ]
最初の版で必要な機能:
- タスクを追加できる
- タスクを一覧で見られる
- タスクを完了済みにできる
- 完了済みタスクを削除できる
今回は入れない機能:
- ログイン
- サーバー保存
- データベース
- 通知
- ドラッグ操作
- 複数ユーザー対応
- ルーティング
- 状態管理ライブラリ
作業場所:
[例: 現在のフォルダが空である前提で作る]
空でない場合は、作業を止めて既存ファイルの一覧と確認事項を出してください。
実装前に、作成予定ファイルと起動コマンドを提示してください。
問題がなければ、そのまま実装に進んでください。
作業後に報告してほしいこと:
- 作成または変更したファイル
- 起動コマンド
- ブラウザで確認するURL
- 今回あえて入れなかったものReactを使うと、フォルダやファイルが増えやすくなります。入れない機能を書いて、初回版を小さく保ちます。
作りすぎを防ぐ制約を入れる
計画が大きくなったときに使う差し戻し文です。
計画が初回版としては大きいです。
今回は [今回の目的] だけに絞ってください。
次のものは外してください。
- [例: ログイン]
- [例: 保存機能]
- [例: CSV出力]
- [例: ダークモード]
- [例: テスト追加]
ファイル数も最小限にしてください。
最初に動く形を優先し、あとから足せる機能は入れないでください。
次の条件で計画を出し直してください。
- 作成するファイルは [例: 1ファイル / 3ファイル以内]
- 外部ライブラリは追加しない
- ローカルで動作確認できる
- 完了条件を3つ以内にする
まだ実装には進まないでください。Claude Codeが出した計画は、削ってから使えます。最初の提案をそのまま通す必要はありません。
リファクタリングを頼むテンプレート
リファクタリングは、動きを変えないことが大事です。目的と対象を絞らずに頼むと、広い変更になりやすいです。
動きを変えずに整理する
[対象ファイル] をリファクタリングしてください。
ただし、外から見える動きは変えないでください。
目的:
[例: 1つのコンポーネントが長くなっているので、読みやすく整理したい]
対象:
[例: `src/components/UserSettingsForm.tsx`]
やってよいこと:
- 関数や小さなコンポーネントへの分割
- 重複している処理の整理
- 変数名の分かりやすい変更
- コメントが必要な箇所の補足
やらないこと:
- UIの見た目を変えない
- API呼び出しの仕様を変えない
- バリデーションルールを変えない
- 新しいライブラリを追加しない
- 対象外ファイルを広く編集しない
完了条件:
- 既存の動きが変わらない
- ファイルの責務が読みやすくなる
- 確認できるテストやビルドが通る
作業後に、何を分けたか、動きを変えていないことをどう確認したかを報告してください。対象ファイルを限定する
どこまで触ってよいかを強く絞るテンプレートです。
次のファイルだけを対象にリファクタリングしてください。
対象ファイル:
- [例: `src/components/ProfileForm.tsx`]
必要がない限り、他のファイルは編集しないでください。
他のファイルの変更が必要だと判断した場合は、編集前に理由を説明して止まってください。
目的:
[例: フォーム内の条件分岐が読みにくいので、処理を整理したい]
やってよいこと:
- 関数の抽出
- 条件分岐の整理
- 分かりにくい変数名の変更
やらないこと:
- 画面の見た目を変更しない
- 入力項目を増減しない
- APIや型定義を変更しない
- テスト以外の別ファイルを編集しない
確認方法:
[例: `npm test` が通ること。テストがない場合は、確認できる範囲を報告すること]対象を限定すると、差分レビューがかなり楽になります。
変更前後の確認を頼む
リファクタリング前後で動きが変わっていないことを確認しながら進めてください。
対象:
[例: `src/components/SearchPanel.tsx`]
目的:
[例: 検索条件の組み立て処理を読みやすくしたい]
作業手順:
1. まず現在の処理の流れを短く説明する
2. 変更方針を出す
3. 最小限のリファクタリングを行う
4. 確認できるテストやビルドを実行する
5. 変更前後で変わっていない動きを報告する
やらないこと:
- 検索仕様を変えない
- 表示項目を変えない
- 新しい依存関係を追加しない
作業後に、変更した理由と確認結果を報告してください。ドキュメント化を頼むテンプレート
READMEや仕様メモは、読む人を指定すると書きやすくなります。
READMEを整える
社内の開発メンバーが、このリポジトリを初めて触るときに迷わないREADMEへ整理してください。
対象:
`README.md`
まず読んでほしいファイル:
- `README.md`
- `package.json`
- 必要なら設定ファイル
追加または整理したい内容:
- このプロジェクトの目的
- ローカル起動手順
- よく使うnpm scripts
- 環境変数が必要な場合の説明
- 開発時の注意点
やらないこと:
- 実際には存在しないコマンドを書かない
- 推測で環境変数名を作らない
- README以外のファイルを編集しない
- 大げさな宣伝文にしない
編集後に、変更した内容と確認したファイルを報告してください。READMEは「誰が読むか」で内容が変わります。社内メンバー向けなのか、公開リポジトリ向けなのかを必ず書きます。
仕様メモを作る
[対象機能] の仕様メモを作ってください。
目的:
[例: 今後の修正時に、処理の流れと注意点をすぐ確認できるようにする]
読んでほしい範囲:
- [例: `src/pages/Billing.tsx`]
- [例: `src/lib/billing.ts`]
- [例: 関係するテストファイル]
書いてほしい内容:
- 機能の目的
- 画面上の主な操作
- 処理の流れ
- APIや外部サービスとの関係
- エラー時の動き
- 変更時に注意すること
やらないこと:
- コードは編集しない
- 推測で仕様を書かない
- 分からない点を断定しない
出力はMarkdownでお願いします。
分からない点は「未確認」として分けてください。仕様メモは、コードを直す前の整理にも使えます。
コードから使い方を説明してもらう
[対象ファイルまたは機能] の使い方を説明してください。
まだファイルは編集しないでください。
知りたいこと:
- このコードが何をするものか
- どこから呼び出されているか
- 主要な引数や戻り値
- よくある使い方
- 変更すると影響しそうな場所
説明は、初めてこのリポジトリを見る開発者向けに書いてください。
必要なら関係ファイルを読んで構いません。
出力は次の形にしてください。
1. 概要
2. 処理の流れ
3. 主なファイル
4. 変更時の注意点
5. 未確認の点
tomoドキュメント化は、あとで自分が読むためにも効きます。Claude Codeに説明させてから修正へ進むと、作業の地図ができます。
テンプレートを貼る前に直す場所
テンプレートは、そのまま貼るだけでは足りません。最低限、次の3つを直します。
角括弧を残さない
[例: ...] のまま送ると、Claude Codeが例を本物の条件として扱うことがあります。
貼る前に、角括弧の部分は必ず自分の内容へ置き換えます。分からない場合は、無理に埋めず「不明」と書きます。
関係しそうなファイル: 不明。まず調査して候補を出してください。このほうが、適当なファイル名を書くより安全です。
やらないことを1つは入れる
やらないことは、毎回1つは入れてください。
今回は新しいライブラリを追加しないでください。今回は認証処理には触らないでください。今回はREADME以外のファイルを編集しないでください。作業の境界線があると、差分が大きくなりにくいです。
確認方法を入れる
確認方法がある場合は、依頼文に入れます。
修正後に `npm test` を実行し、結果を報告してください。ブラウザで開く手順と、画面上で確認した内容を報告してください。確認方法が分からない場合も、そう書けます。
確認方法が分からないので、作業前に確認候補を出してください。依頼文テンプレートは育てて使う
テンプレートは、一度作って終わりではありません。自分のプロジェクトでよく使う文に少しずつ寄せていきます。
よく使う文は保存する
何度も使う依頼文は、メモとして保存しておくと楽です。
- 調査だけ
- バグ修正
- README整理
- 1ファイルHTML作成
- リファクタリング
毎回ゼロから書くより、前にうまくいった文を直して使うほうが安定します。
プロジェクト共通ルールはCLAUDE.mdへ寄せる
毎回書くルールは、プロジェクト共通のメモへ寄せると楽になります。
たとえば、次のような内容です。
- 明示的に依頼されない限り、コミットは作成しない
- 変更後は `npm run check` を実行する
- 新しいライブラリを追加する前に理由を説明する
- README以外のドキュメントを作る場合は、先に配置場所を確認するただし、何でも詰め込みすぎると読まれにくくなります。毎回本当に必要なルールだけに絞ります。
用途に合う型を選ぶ
Claude Codeへの依頼文は、毎回うまい文章にする必要はありません。
必要なのは、用途に合う型を選ぶことです。
- 原因を知りたいなら、調査だけ頼む
- 方針を見たいなら、計画だけ頼む
- 小さく直したいなら、対象と完了条件を絞る
- 新しく作りたいなら、入れない機能を書く
- READMEや仕様メモは、読む人を指定する
テンプレートは、Claude Codeに丸投げするための文ではありません。作業の幅を決めて、自分が確認できる大きさにするための文です。
迷ったら、まず調査。次に計画。最後に編集。この順番に戻せば、Claude Codeの作業は扱いやすくなります。
