Claude Codeにバグ修正を頼むとき、つい「エラーが出るので直してください」と書きたくなります。 急いでいるときほど、その一文で済ませたくなります。
ただ、バグ修正では最初の情報が少ないほど、Claude Codeは広く調べることになります。 関係しそうなファイルを探し、原因を推測し、直せそうな場所を変える。 便利ですが、初心者のうちは差分を追いきれません。
バグ修正の依頼では、症状だけでなく、再現手順と期待する動きを一緒に渡すことが大事です。 この記事では、Claude Codeにバグ修正を頼むときの手順を整理します。 エラー文の貼り方、画面不具合の伝え方、修正前に範囲を小さくする方法、修正後の確認までを、依頼文つきで見ていきます。
バグ修正を頼むときは、エラー文、再現手順、実際の動き、期待する動き、変更してよい範囲、確認方法を渡します。分からない項目は無理に埋めず、「不明なので調査して候補を出して」と書けば大丈夫です。
バグ修正は「直して」より先に状況を渡す
Claude Codeは、コードベースを読み、関係ファイルを探し、ファイルを編集し、必要ならコマンドも実行できます。 バグ修正にも向いています。
だからこそ、最初の依頼が雑だと作業が広がります。
たとえば、次の依頼だけでは情報が足りません。
エラーが出るので直してください。この依頼では、どの操作でエラーが出るのか、何が正しい状態なのか、修正後に何を確認すればよいのかが分かりません。 Claude Codeは調査から始められますが、読者側が結果を確認しにくくなります。
症状だけだと原因候補が広がりすぎる
「画面が白くなる」「保存できない」「テストが落ちる」だけでは、原因の候補が多すぎます。
画面が白くなる原因だけでも、フロントエンドの例外、APIのレスポンス形式、ルーティング、環境変数、ビルド設定などが考えられます。 保存できない場合も、入力値チェック、API、DB、権限、ネットワークのどこで止まっているのかで修正場所が変わります。
Claude Codeに広く探してもらうことはできます。 でも、最初から広く探すと、関係ないファイルまで読んだり、修正案が大きくなったりします。
バグ修正では、最初にこう伝えるほうが安全です。
ログイン画面でメールアドレスとパスワードを入力し、送信ボタンを押すと画面が白くなります。
期待する動きは、ログイン成功時にダッシュボードへ移動することです。
まず原因を調査し、変更が必要そうなファイルを挙げてください。
まだ編集はしないでください。これだけでも、調査の入口がかなり狭まります。
最初の依頼で伝える6つの情報
バグ修正を頼むときは、次の6つを入れると進めやすくなります。
| 項目 | 書くこと | 例 |
|---|---|---|
| エラー文 | 表示された文を省略せず貼る | TypeError: ... |
| 再現手順 | 自分が行った操作を順番に書く | ログイン画面を開く、入力する、送信する |
| 実際の動き | 起きている問題を書く | 画面が白くなる |
| 期待する動き | 正しい状態を書く | ダッシュボードへ移動する |
| 変更範囲 | 触ってよい場所、触らない場所を書く | 認証方式は変えない |
| 確認方法 | テストや手動確認を書く | npm test、同じ手順で再確認 |
最初から全部を完璧に書く必要はありません。 分からない項目は「不明」と書いて、Claude Codeに候補を出してもらいます。
tomoバグ修正の依頼文は、上手な文章でなくて大丈夫です。Claude Codeが同じ状態を作れる材料を渡す、という意識で書くと迷いにくくなります。
エラー文があるときは、そのまま貼る
エラー文があるなら、まずそれを貼ります。 自分で短く要約しすぎるより、出力をそのまま渡したほうが原因に近づきやすいです。
ただし、エラー文だけを貼って終わりにしません。 何をしたときに出たのかを一緒に書きます。
コマンドと出力をセットで渡す
ビルドやテストで落ちた場合は、実行したコマンドも書きます。
次のエラーを修正したいです。
実行したコマンド:
npm run build
エラー文:
[ここにエラー全文を貼る]
期待すること:
ビルドが成功することです。
作業の進め方:
1. まず原因を調査してください。
2. 修正が必要そうなファイルを挙げてください。
3. 最小限の変更で修正してください。
4. 修正後に `npm run build` を再実行してください。
やらないこと:
- エラーを隠すだけの変更はしない
- 関係ない整形変更はしない
- 新しいライブラリは追加しないこの形なら、Claude Codeは「どのコマンドで失敗したか」と「修正後に何を再実行するか」を理解できます。
エラー文を貼る前に、APIキー、トークン、パスワード、個人情報が混ざっていないかだけ確認してください。秘密情報が含まれる場合は、値を伏せてから渡します。
画面のエラーは操作手順も必要になる
ブラウザ上の不具合では、エラー文だけでは足りないことがあります。 どの画面で、何を入力し、どのボタンを押したかが必要です。
たとえば、次のように書きます。
ユーザー登録画面で不具合があります。
再現手順:
1. ユーザー登録画面を開く
2. メールアドレス欄を空のままにする
3. パスワードだけ入力する
4. 登録ボタンを押す
実際の動き:
エラーメッセージが出ず、送信中の表示のまま止まります。
期待する動き:
メールアドレス欄の下に「メールアドレスを入力してください」と表示したいです。
確認してほしいこと:
- 空欄のときにエラーが出る
- 入力したときは既存の送信処理が動く
- 見た目を大きく変えない画面の不具合では、正しい動きを人間が言葉にする必要があります。 Claude Codeはコードから意図を推測できますが、プロダクトとして正しい動きまでは決めきれないことがあるからです。
再現手順は、Claude Codeが同じ状態を作れる粒度で書く
再現手順は、バグ修正の地図です。
自分が行った操作を番号付きで書くだけで、Claude Codeが調査しやすくなります。 同時に、自分でも「本当に同じ手順で起きるのか」を確認できます。
期待する動きと実際の動きを分ける
再現手順を書くときは、実際の動きと期待する動きを分けます。
次の書き方だと、まだ曖昧です。
検索がうまく動きません。少し直すと、確認しやすくなります。
検索画面で不具合があります。
再現手順:
1. 検索画面を開く
2. キーワードに「invoice」と入力する
3. 検索ボタンを押す
実際の動き:
検索結果が0件になります。
期待する動き:
タイトルに「invoice」を含む記事が表示されることです。
補足:
同じデータは管理画面には存在しています。期待する動きは、Claude Codeにとって修正後のゴールです。 ここがないと、エラーが消えただけで正しい修正になっているか判断しにくくなります。
毎回起きるか、たまに起きるかを書く
不具合が毎回起きるのか、たまに起きるのかも書きます。
毎回起きるなら、Claude Codeは同じ手順で確認しやすいです。 たまに起きるなら、ログ、タイミング、入力値、ブラウザ、端末、ネットワーク状態などを見る必要が出てきます。
この不具合は毎回ではなく、5回に1回くらい起きます。
自分が確認した範囲では、保存ボタンを連続で押したときに起きやすいです。
まず原因候補を調べ、追加で必要なログや確認方法を提案してください。
まだ編集はしないでください。断続的な不具合では、いきなり修正に入るより、先に調査方法を決めるほうがよいです。 ログを増やす、テストを追加する、再現条件を絞る。 そのほうが、なんとなく直した修正になりにくくなります。
tomo「たまに壊れる」は、いちばん雑に直しにくいタイプです。頻度や起きやすい操作を書くだけでも、調査の向きがかなり定まります。
修正前に変更範囲を小さくする
バグ修正では、直すついでに広く整えたくなることがあります。 関数名を変える、周辺コードを整理する、見た目を少し変える。 慣れている人なら判断できますが、初心者のうちは混ぜないほうが安全です。
バグ修正の目的は、まず問題を直すことです。 読みやすくする作業や設計変更は、別の依頼に分けます。
触ってよいファイルと触らない場所を書く
分かる範囲で、触ってよい場所を書きます。 分からない場合は、先に候補を出してもらいます。
次の不具合を修正したいです。
不具合:
プロフィール編集画面で保存後のメッセージが表示されません。
触ってよい範囲:
- プロフィール編集画面
- 保存後メッセージの表示処理
触らないでほしい範囲:
- API仕様
- 認証処理
- データベース設計
- 画面全体のデザイン変更
まず関係しそうなファイルを調査し、変更候補を出してください。このように書くと、Claude Codeは「どこまで変えてよいか」を判断しやすくなります。
変更範囲が分からないときは、対象を無理に決めなくて構いません。
関係ファイルが分かりません。
まず調査して、変更が必要そうなファイルと、触らないほうがよいファイルを分けてください。
調査結果を出すまで編集しないでください。原因調査だけで止める頼み方もある
バグ修正を頼むとき、最初から編集まで進める必要はありません。
不具合の原因が分からないときは、調査だけで止めます。
次の不具合の原因を調査してください。
まだファイルは編集しないでください。
知りたいこと:
- 原因の候補
- 関係しそうなファイル
- 修正が必要そうな箇所
- 追加で確認すべきログやコマンド
- 先に私が判断すべきこと
調査後、修正案を2つまで出してください。
私が承認するまで編集に進まないでください。原因調査と編集を分けると、差分を小さくできます。 とくに、認証、決済、データ削除、本番環境に関係する不具合では、この進め方が向いています。
バグ修正のつもりで、認証方式、DB構造、API仕様まで変わると、別の問題が出やすくなります。変更範囲を小さくし、関係ないリファクタリングは混ぜないでください。
修正後は「動いたか」まで確認してもらう
バグ修正は、コードを書き換えたら終わりではありません。 同じ手順で問題が起きないことを確認して、初めて一区切りです。
Claude Codeに依頼するときは、修正後の確認まで含めます。
確認コマンドがあるなら先に伝える
プロジェクトに確認コマンドがあるなら、依頼文に入れます。
修正後に次を実行してください。
npm test
npm run build
もし失敗した場合は、失敗したコマンド、エラー文、追加修正が必要かを報告してください。確認コマンドが分からない場合も、そのまま書けます。
確認コマンドが分からないので、修正前に package.json を確認して、実行できそうなチェック方法を提案してください。Claude Codeは、プロジェクト内の設定ファイルを読んで候補を出せます。 ただし、外部サービスに接続するテストや、時間が長くかかるコマンドがあるかもしれません。 不安な場合は、実行前に説明してもらいます。
確認できないことも報告してもらう
Claude Codeがすべてを確認できるとは限りません。
たとえば、ログイン情報が必要な画面、外部API、決済、スマホ実機、管理画面などは、人間の確認が残ることがあります。 その場合は、「確認できなかったこと」を報告してもらいます。
作業後に、次の形式で報告してください。
- 変更したファイル
- 原因
- 修正内容
- 実行した確認コマンド
- 確認できたこと
- 確認できなかったこと
- 私が手元で確認すべき手順この報告形式を指定しておくと、最後に何を見ればよいか分かりやすくなります。 確認できなかったことを隠さず出してもらうのが、バグ修正ではかなり大事です。
そのまま使えるバグ修正依頼文
ここからは、実際に貼って使える依頼文です。 角括弧の中だけ、自分の状況に置き換えてください。
エラー文がある場合
次のエラーを修正してください。
実行した操作またはコマンド:
[例: npm run build を実行した]
エラー文:
[ここにエラー全文を貼る]
期待すること:
[例: ビルドが成功する]
関係しそうなファイル:
[分かれば書く。不明なら「不明。まず調査して候補を出してください」と書く]
作業の進め方:
1. まず原因を確認してください。
2. 修正が必要なファイルを特定してください。
3. 最小限の変更で修正してください。
4. 修正後に確認コマンドを実行してください。
やらないこと:
- エラーを隠すだけの変更はしない
- 関係のない整形変更はしない
- 新しいライブラリは追加しない
作業後に、原因、変更したファイル、確認結果を報告してください。画面の動きがおかしい場合
[画面名] の動きがおかしいので修正してください。
再現手順:
1. [最初の操作]
2. [次の操作]
3. [問題が起きる操作]
実際の動き:
[例: 保存ボタンを押すと、送信中のまま止まる]
期待する動き:
[例: 保存に成功したら完了メッセージを表示する]
触ってよい範囲:
[例: 対象画面とメッセージ表示処理]
触らないでほしい範囲:
- API仕様
- 認証処理
- データベース設計
- 画面全体のデザイン変更
確認してほしいこと:
- 同じ再現手順で問題が起きない
- 期待する表示になる
- 既存の正常系が壊れていない
作業後に、変更したファイル、確認したこと、確認できなかったことを報告してください。まず原因だけ調べたい場合
次の不具合の原因を調査してください。
まだファイルは編集しないでください。
不具合:
[起きている問題を書く]
再現手順:
1. [操作を書く]
2. [操作を書く]
3. [問題が起きる操作を書く]
期待する動き:
[正しい状態を書く]
調査してほしいこと:
- 原因の候補
- 関係しそうなファイル
- 修正が必要そうな箇所
- 追加で確認すべきログやコマンド
- 不明な点
調査結果を出したあと、私が承認するまで編集に進まないでください。修正後の確認まで頼む場合
次の不具合を修正し、修正後の確認まで行ってください。
不具合:
[起きている問題を書く]
期待する動き:
[正しい状態を書く]
編集してよい範囲:
- [対象ファイルや対象画面]
やらないこと:
- [例: 新しいライブラリは追加しない]
- [例: API仕様は変えない]
- [例: 関係のないファイルは編集しない]
確認してほしいこと:
- [例: npm test が通る]
- [例: npm run build が通る]
- [例: 同じ再現手順で問題が起きない]
確認できないことがあれば、理由と、私が手元で確認すべき手順を報告してください。
tomo迷ったら、まず原因調査だけで止めて大丈夫です。原因、変更候補、確認方法が見えてから修正に進むほうが、差分を読みやすくなります。
まとめ
Claude Codeにバグ修正を頼むときは、「直して」だけで始めないほうが安全です。 最初に状況を渡すほど、調査範囲を絞りやすくなり、修正後の確認もしやすくなります。
要点は次の通りです。
- エラー文は省略せず貼る
- 何をしたときに起きたかを書く
- 再現手順を番号付きで書く
- 実際の動きと期待する動きを分ける
- 変更してよい範囲、触らない範囲を書く
- 修正後の確認コマンドや手順を入れる
- 確認できなかったことも報告してもらう
バグ修正は、Claude Codeに任せるほど、最初の情報が効きます。 自分が見た症状を、Claude Codeが同じように追える形にする。 そのうえで、変更範囲を小さくし、確認方法まで頼む。
この順番を守るだけで、バグ修正は「何となく直してもらう作業」ではなく、自分でも確認できる作業になります。
