Article

Claude Codeへの依頼前に確認するチェックリスト：漏れをなくして精度を上げる

Claude Codeへ依頼する前に確認すべき7つのポイントを整理したチェックリストです。目的・対象ファイル・制約・検証手段・禁止事項を一度見直すだけで、やり直しや修正ループを減らせます。

This article is not published in this language yet, so the Japanese version is shown instead.

依頼前に30秒確認するだけで、修正ループが減る

Claude Codeへの依頼は、プロンプトを入力して送信するだけで動き始めます。しかし「とりあえず投げてみる」を繰り返していると、何度も修正指示を出す羽目になったり、期待と違う方向に実装が進んだりしがちです。

依頼品質が低いと何が起きるかを先に整理しておきます。

期待した動作にならず、追加で「○○を直して」「○○はやめて」と2〜3回修正指示を出す
指示していない余分なリファクタリングや依存追加が走る
テストを書いてほしかったのに書かれなかった、またはその逆
秘密情報が含まれたファイルを意図せず参照させてしまう

Claude Codeの公式ベストプラクティスでは「verify its work（自分の仕事を検証できるようにする）」「provide specific context（具体的なコンテキストを渡す）」「avoid common failure patterns（よくある失敗パターンを避ける）」の3点が最重要とされています。このチェックリストはその3点を実際の依頼前作業に落とし込んだものです。

依頼前にかかる時間は30秒以下です。それで修正ループが1〜2回減るなら、十分な投資対効果があります。

7項目チェックリスト

以下の7項目を依頼前に確認してください。すべてを満たす必要はありませんが、1つでも欠けていると修正が増えやすい項目です。

1. 目的が1文で言えるか

「何をしてほしいか」を1文で言える状態になっているか確認します。言えない場合は依頼文が曖昧になっています。

✅ 「src/api/user.tsのgetUserById関数に、存在しないIDを渡したとき404エラーを返す処理を追加してほしい」
❌ 「ユーザーAPIをいい感じに直して」

目的が1文で言えると、Claude Codeも的外れな実装をしにくくなります。詳しい依頼文の構造はClaude Codeに伝わるプロンプトの基本構造を参照してください。

2. 対象ファイルを明示しているか

Claude Codeは指示がなければ自分でファイルを探しますが、大きなリポジトリでは探索に時間がかかり、コンテキストも消費します。また、意図していないファイルを変更するリスクも上がります。

@記法で対象ファイルを直接指定するか、依頼文にパスを書きましょう。

✅ 「@src/api/user.ts のgetUserById関数を修正してほしい」
❌ 「ユーザー取得のAPIを直して」

関連するファイルが複数ある場合は2〜5件程度に絞って指定するのが目安です。全部渡すとコンテキストが膨らんで精度が下がります。

3. 完了条件が具体的か

何をもって「完了」とするかを書かないと、Claude Codeは自分なりの完了条件で動きます。テスト通過なのか、特定のコマンドが成功することなのか、スクリーンショットで目視確認なのかを明示します。

✅ 「実装後に npm test を実行して全テストが通ることを確認してほしい」
✅ 「ブラウザでhttp://localhost:3000/profileにアクセスして表示が崩れていないことを確認してほしい」
❌ 「ちゃんと動くようにして」

完了条件は依頼文に検証コマンドとして直接埋め込むのが最もシンプルです。完了条件の詳しい書き方はClaude Codeの成功率を上げる制約条件と受け入れ条件の作り方を参照してください。

4. 禁止事項を書いているか

「やってほしくないこと」を書かないと、Claude Codeは善意で余計なことをします。よくある例を挙げます。

スコープ外のリファクタリングをする（「ついでに」が多い）
新しいnpmパッケージを追加する
既存のテストを書き換える
型定義ファイルや設定ファイルを変更する

これらを防ぐには禁止事項を依頼文かCLAUDE.mdに書いておきます。

✅ 「既存のテストコードは変更しないこと。npmパッケージの追加は行わないこと。」

特に「インライン編集だけ」「このファイルだけ」という制約は、指定しないと拡散しやすいです。

5. 秘密情報が含まれていないか

@でファイルを指定するとき、その中に.envのAPIキーやデータベースのURL、認証トークンなどが含まれていないか確認します。

チェックすべきファイル例：

.env / .env.local / .env.production
~/.aws/credentials
~/.ssh/id_rsa（秘密鍵）
config/secrets.yml

これらはCLAUDE.mdのdeny ruleで読ませないよう設定しておくのが恒久対応です。詳しくはClaude Codeに秘密情報を渡さないための実践ルールを参照してください。

6. タスクサイズが適切か

1つの依頼に詰め込みすぎると、Claude Codeの精度が落ちます。目安として次の条件を超えると分割を検討します。

指標	分割を検討する目安
変更対象ファイル	5ファイルを超える
予想作業時間	30分〜1時間を超える
独立した完了条件	2つ以上ある

「ユーザー登録機能の追加」は大きすぎます。「バリデーションの追加」「DBへの保存処理」「レスポンス形式の調整」のように細かく分解しましょう。タスク分解の詳しい方法は大きな開発タスクをClaude Codeに渡す前の分解方法を参照してください。

7. Plan Modeを使うべきか判断しているか

変更が複数ファイルにまたがる、アーキテクチャに関わる、自分がそのコードに不慣れな場合は計画フェーズを先に入れます。

✅ 計画を立ててから実装してほしい場合は先に「計画だけ作って」と依頼する
✅ または --permission-mode plan で起動してから依頼する

1ファイルの小さな修正や、変更内容が自明な場合はPlan Modeは省いて構いません。「変更内容を1文で説明できるか？」がPlan Mode不要の目安です。

コピペで使える依頼文テンプレート

上記7項目を網羅した依頼文のテンプレートです。必要ない項目は削除して使ってください。

目的:
  [何をしてほしいか、1文で]

対象ファイル:
  @[ファイルパス1]
  @[ファイルパス2]（必要な場合）

完了条件:
  - [検証コマンドまたは確認方法]

制約:
  - [変更してよいファイルの範囲]
  - [使ってよいライブラリ/使ってはいけないライブラリ]

禁止事項:
  - スコープ外のリファクタリングは行わない
  - npmパッケージを追加しない
  - 既存テストコードを変更しない

補足情報:
  [背景や関連する仕様（あれば）]

このテンプレートは.claude/prompts/request.mdなどに保存して@でインポートすると、毎回書き直さずに済みます。

依頼タイプ別：確認の優先順位

すべてのチェックを毎回フルで行う必要はありません。依頼タイプによって確認が重要な項目は異なります。

依頼タイプ	最優先チェック	次点
バグ修正	対象ファイル・完了条件	禁止事項
新機能追加	タスクサイズ・Plan Mode判断	禁止事項・完了条件
リファクタリング	禁止事項・完了条件	対象ファイル
テスト追加	完了条件	禁止事項
調査・分析	目的・タスクサイズ	対象ファイル

バグ修正では「どのファイルの何がおかしいか」と「直ったとみなす条件」が最重要で、禁止事項はそれほど厳密でなくて構いません。一方、リファクタリングは「やってはいけないこと」を明確にしないと拡散しやすいです。

よくある失敗と対処

修正を2回以上出してしまった場合

同じ問題で修正指示を2回以上出した場合は、コンテキストが失敗パターンで汚染されています。/clearでコンテキストをリセットして、今回学んだ制約を加えた依頼文を作り直すのが近道です。

# セッション内でのコンテキストリセット

インタラクティブセッション中は /clear と入力してコンテキストをリセットします。

「いい感じに」という指示を出してしまった場合

「いい感じに改善して」「きれいにして」など形容詞だけの指示は、Claude Codeが自分の判断基準で動きます。期待と大幅にずれたり、余計な変更が混入したりします。依頼文を見直して、何をどう変えてほしいかを具体化してください。

依頼外の変更が入ってきた場合

「確認してから変更する」旨を依頼文に入れるか、Plan Modeを使って計画確認フェーズを先に設けます。またはCLAUDE.mdにスコープ外の変更を行わないルールを書いておくのが恒久対応です。

CLAUDE.mdに入れておくと便利な共通ルール

チームや個人のリポジトリ共通で適用したい制約はCLAUDE.mdにまとめておくと、毎回の依頼文に書かなくて済みます。

## 依頼への対応ルール

- 依頼された範囲を超えるリファクタリングは行わない
- npmパッケージの追加は依頼文で明示された場合のみ行う
- 既存テストコードは依頼文で明示された場合のみ変更する
- 変更を加える前にPlan Modeで計画を示す（複数ファイルにまたがる場合）
- 実装後は [検証コマンド] を実行して完了を確認する