Claude Codeでバグ修正を効率化する方法

作成日 2026.04.28
その他

Claude Codeを使うと、エラー調査、原因特定、修正案の作成、テスト追加、再発防止策の整理までを効率化できます。この記事では、バグ修正をClaude Codeに任せるときの進め方、プロンプト例、Git差分の確認、ログの渡し方、テスト実行、CLAUDE.mdの使い方、チーム運用の注意点まで実務向けにまとめます。

1. バグ修正時のルール

Claude Codeとは

Claude Codeは、Anthropicが提供しているAIコーディング支援ツールです。

ターミナル、IDE、デスクトップアプリ、ブラウザから使うことができ、コードベースを読み取り、ファイル編集、コマンド実行、Git操作、開発ツール連携などを行えます。

バグ修正では、次のような作業に向いています。

・エラーメッセージの原因調査
・スタックトレースの読み取り
・関連ファイルの特定
・再現手順の整理
・修正方針の提案
・実際のコード修正
・テストコードの追加
・既存テストの実行
・修正差分のレビュー
・再発防止策の整理

Claude Codeは「コードを書かせるツール」としてだけでなく、「バグの原因を一緒に探す開発パートナー」として使うと効果が出やすくなります。

バグ修正でClaude Codeを使うメリット

バグ修正で時間がかかるのは、コードを書く作業よりも、原因を特定する作業です。

特に次のような場面では、Claude Codeが役立ちます。

・どのファイルを見ればよいかわからない
・スタックトレースが長くて読みづらい
・既存コードの仕様がわからない
・影響範囲が広そうで不安
・修正したが別の箇所が壊れそう
・テストをどう書けばよいかわからない
・過去の実装意図が読み取りにくい

Claude Codeに調査、仮説、修正、テストの流れを任せることで、手作業の調査時間を減らせます。

ただし、最終判断は人間が行う必要があります。

特に、業務仕様、金額計算、権限管理、契約処理、個人情報の扱いなどは、AIの修正案をそのまま採用せず、人間が必ず確認します。

まずはClaude Codeを起動する

対象プロジェクトのディレクトリに移動して、Claude Codeを起動します。

cd your-project
claude

まだインストールしていない場合は、環境に応じてインストールします。

macOS、Linux、WSLの場合です。

curl -fsSL https://claude.ai/install.sh | bash

Windows PowerShellの場合です。

irm https://claude.ai/install.ps1 | iex

起動後、プロジェクト全体を確認させたい場合は、最初に次のように依頼します。

このプロジェクトの構成を確認してください。
主要なディレクトリ、フレームワーク、テストコマンド、ビルドコマンドを把握してください。
まだファイルは変更しないでください。

最初から修正させるのではなく、まず構成を把握させるのが安全です。

バグ修正の基本フロー

Claude Codeでバグ修正を効率化する場合、次の流れが使いやすいです。

バグの内容を伝える
再現手順を伝える
エラーログやスタックトレースを渡す
原因調査だけを依頼する
修正方針を出させる
人間が方針を確認する
修正を依頼する
テストを追加させる
テストを実行する
Git差分を確認する
再発防止策を整理する

重要なのは、いきなり「直して」と依頼しないことです。

先に原因調査と修正方針を出させることで、間違った方向に大きく修正されるリスクを減らせます。

最初に原因調査だけを依頼する

バグ修正で失敗しやすいのは、原因が曖昧なままコードを書き換えることです。

まずは原因調査だけを依頼します。

以下のバグの原因を調査してください。
まだコードは変更しないでください。

バグ内容:
ログイン後にマイページへ遷移すると、500エラーになります。

再現手順:

/login にアクセス
正しいメールアドレスとパスワードを入力
ログイン成功後、/mypage に遷移
500エラーが発生

期待する動作:
マイページが正常に表示される

確認してほしいこと:

関連しそうなファイル
エラーの原因候補
最も可能性が高い原因
修正方針
追加すべきテスト

コードはまだ変更しないでください。

このように「まだコードは変更しない」と明記すると、調査フェーズと修正フェーズを分けられます。

エラーログを渡して原因を絞り込む

バグ修正では、エラーログやスタックトレースをそのまま渡すと原因特定が速くなります。

以下のエラーログをもとに、原因を調査してください。
まだ修正はしないでください。

エラーログ:
TypeError: Cannot read properties of undefined (reading ‘name’)
at UserProfile (/src/components/UserProfile.tsx:42:18)
at renderWithHooks
at updateFunctionComponent

発生条件:

ログイン直後のみ発生
ページをリロードすると正常表示される
新規登録直後のユーザーで発生しやすい

確認してほしいこと:

undefinedになっている可能性がある値
初期表示時のデータ取得タイミング
修正方針
テスト観点

ログを渡すときは、次の情報もセットで渡すと精度が上がります。

・何をしたら起きたか
・毎回起きるか
・特定ユーザーだけか
・本番だけか、開発環境でも起きるか
・直近で変更した箇所
・期待する動作
・実際の動作
・エラー全文

再現手順を明確にする

再現手順が曖昧なまま修正すると、別の問題を直してしまう可能性があります。

Claude Codeには、再現手順の整理も依頼できます。

以下の情報から、バグの再現手順を整理してください。
不足している確認項目も挙げてください。

現象:
問い合わせフォームで送信ボタンを押すと、たまに二重送信される。

わかっていること:
- スマホで発生しやすい
- PCではまだ再現していない
- 通信が遅いときに起きやすい
- サンクスページには遷移する
- 管理者宛メールが2通届くことがある
出してほしいもの:
- 再現手順
- 原因候補
- 確認すべきファイル
- 修正方針
- テスト観点
  
  再現条件が曖昧な場合は、Claude Codeに「調査チェックリスト」を作らせるのも有効です。
  
  このバグを再現するための確認チェックリストを作成してください。
  ブラウザ、端末、通信状態、入力内容、連打、戻るボタン、リロードなどの観点を含めてください。
  
  修正前に影響範囲を確認する
  
  バグ修正では、対象箇所だけを見て直すと、別の機能に影響することがあります。
  
  修正前に影響範囲を確認します。
  
  このバグを修正する前に、影響範囲を調査してください。
  まだコードは変更しないでください。
  
  確認してほしいこと:
  - 関連するコンポーネント
  - 関連するAPI
  - 同じ関数を使っている箇所
  - 既存テストの有無
  - 修正によって壊れる可能性がある機能
  - 影響が小さい修正方針
    
    特に、共通関数、認証処理、メール送信処理、決済処理、DB更新処理は影響範囲が広くなりやすいです。
    
    Claude Codeに関連箇所を検索させることで、見落としを減らせます。
    
    修正方針を複数出させる
    
    バグ修正には、応急処置と根本修正があります。
    
    Claude Codeには、複数の修正案を出させると判断しやすくなります。
    
    このバグの修正方針を3案出してください。
    まだコードは変更しないでください。
    
    それぞれについて、以下を比較してください。
    - 修正内容
    - メリット
    - デメリット
    - 影響範囲
    - 実装コスト
    - 再発防止効果
    - おすすめ度
      
      たとえば、本番障害中なら応急処置を優先する場合があります。
      
      一方で、時間に余裕があるなら根本修正の方がよい場合があります。
      
      Claude Codeに比較させることで、場面に合った判断がしやすくなります。
      
      コード修正を依頼する
      
      修正方針を確認したら、実際の修正を依頼します。
      
      修正方針は「案2」で進めてください。
      
      条件:
      - 影響範囲を最小限にしてください
      - 既存の命名規則に合わせてください
      - 不要なリファクタリングはしないでください
      - バグ修正に関係ないファイルは変更しないでください
      - 修正後に変更内容を要約してください
        
        ポイントは、「ついでの改善」をさせないことです。
        
        Claude Codeは、関連箇所を見つけるとリファクタリングまで提案することがあります。
        
        バグ修正では、差分を小さくする方がレビューしやすく、安全です。
        
        今回の目的はバグ修正のみです。
        コード整理や大規模なリファクタリングは行わないでください。
        必要最小限の差分にしてください。
        
        テストを追加してから修正を確認する
        
        バグ修正では、同じ問題が再発しないようにテストを追加することが重要です。
        
        Claude Codeには、バグを再現するテストを先に作らせることもできます。
        
        このバグを再現するテストを先に追加してください。
        まだ実装コードは変更しないでください。
        
        条件:
        
        現在のコードでは失敗するテストにしてください
        
        バグの再現条件がわかるテスト名にしてください
        
        既存のテストスタイルに合わせてください
        
        テスト追加後、どのコマンドで実行するか教えてください
        
        その後、修正を依頼します。
        
        追加したテストが通るように、実装を修正してください。
        修正は必要最小限にしてください。
        修正後、関連テストを実行してください。
        
        この流れにすると、単にエラーが消えただけでなく、再発防止にもつながります。
        
        テストコマンドをClaude Codeに確認させる
        
        プロジェクトによって、テストコマンドは異なります。
        
        まずClaude Codeに確認させます。
        
        このプロジェクトで使われているテストコマンドを確認してください。
        package.json、README、Makefile、CI設定などを見て、実行すべきコマンドを整理してください。
        まだテストは実行しないでください。
        
        確認後、必要な範囲だけテストを実行します。
        
        今回の修正に関係するテストだけを実行してください。
        失敗した場合は、原因を調査して報告してください。
        勝手に大きな修正はしないでください。
        
        よく使うコマンドの例です。
        
        npm test
        npm run test
        npm run test:unit
        npm run lint
        npm run typecheck
        npm run build
        
        PHPの場合の例です。
        
        composer test
        vendor/bin/phpunit
        vendor/bin/pint
        composer analyse
        
        Laravelの場合の例です。
        
        php artisan test
        vendor/bin/phpunit
        vendor/bin/pint
        php artisan config:clear
        
        WordPressテーマやプラグインの場合は、プロジェクトごとに構成が異なるため、READMEやcomposer.json、package.jsonを確認させるのが安全です。
        
        Git差分を確認する
        
        Claude Codeが修正した後は、必ずGit差分を確認します。
        
        git diff
        
        Claude Codeにも差分レビューを依頼します。
        
        今回の修正差分を確認してください。
        
        確認してほしいこと:
        
        バグ修正に関係ない変更が含まれていないか
        
        影響範囲が広すぎないか
        
        既存仕様を壊していないか
        
        テストが十分か
        
        セキュリティ上の問題がないか
        
        追加で人間が確認すべき点
        
        差分が大きすぎる場合は、Claude Codeに小さく戻すよう依頼します。
        
        差分が大きすぎます。
        今回のバグ修正に必要な変更だけに絞ってください。
        リファクタリング、整形のみの変更、無関係な命名変更は戻してください。
        
        バグ修正では、差分が小さいほどレビューしやすくなります。
        
        CLAUDE.mdにバグ修正ルールを書く
        
        毎回同じ注意をするのは手間です。
        
        プロジェクトのルートにCLAUDE.mdを置いて、バグ修正時のルールを書いておくと便利です。
        
        バグ修正時のルール
        
        Claude Codeは、バグ修正時に以下のルールを守ってください。
        
        基本方針
        
        いきなりコードを変更しない
        
        まず原因調査を行う
        
        修正方針を提示してから実装する
        
        バグ修正に関係ないリファクタリングは行わない
        
        差分は必要最小限にする
        
        既存の命名規則、設計、ディレクトリ構成に合わせる
        
        既存仕様を推測で変更しない
        
        修正前に確認すること
        
        再現手順
        
        エラーログ
        
        影響範囲
        
        関連ファイル
        
        既存テスト
        
        同じ関数やコンポーネントを使っている箇所
        
        修正後に行うこと
        
        関連テストを実行する
        
        lintを実行する
        
        typecheckを実行する
        
        git diffを確認する
        
        変更内容を要約する
        
        人間が確認すべき点をまとめる
        
        禁止事項
        
        無関係なファイルを変更しない
        
        大規模なリファクタリングを勝手に行わない
        
        仕様を推測で変更しない
        
        テストを通すためだけに不自然な実装にしない
        
        エラーを握りつぶすだけの修正にしない
        
        CLAUDE.mdを整備しておくと、毎回の指示が短くなります。
        
        Hooksで修正後のチェックを自動化する
        
        Claude Codeでは、Hooksを使って特定のタイミングでコマンドを実行できます。
        
        バグ修正では、ファイル編集後に自動でフォーマットやlintを走らせる運用が便利です。
        
        たとえば、ファイル編集後にPrettierを実行する設定です。
        
        {
        “hooks”: {
        “PostToolUse”: [
        {
        “matcher”: “Edit|Write”,
        “hooks”: [
        {
        “type”: “command”,
        “command”: “npx prettier –write .”
        }
        ]
        }
        ]
        }
        }
        
        TypeScriptプロジェクトなら、修正後に型チェックを実行する運用も考えられます。
        
        {
        “hooks”: {
        “PostToolUse”: [
        {
        “matcher”: “Edit|Write”,
        “hooks”: [
        {
        “type”: “command”,
        “command”: “npm run typecheck”
        }
        ]
        }
        ]
        }
        }
        
        ただし、Hooksは便利な反面、コマンドを自動実行するため注意が必要です。
        
        特に、外部から取得したリポジトリや、信頼できない設定ファイルが含まれるプロジェクトでは、危険なコマンドが実行されないように確認します。
        
        本番障害時の使い方
        
        本番障害時は、焦って大きな修正を入れないことが重要です。
        
        Claude Codeには、応急処置と恒久対応を分けて考えさせます。
        
        本番障害が発生しています。
        まずは原因調査と応急処置案を出してください。
        まだコードは変更しないでください。
        
        状況:
        
        本番で500エラーが発生
        
        影響範囲は注文完了画面
        
        直近で決済処理を変更
        
        ロールバックも検討中
        
        出してほしいもの:
        
        原因候補
        
        確認すべきログ
        
        影響範囲
        
        応急処置案
        
        ロールバック判断の材料
        
        恒久対応案
        
        本番障害では、以下のように明確に指示します。
        
        今回は本番復旧を優先します。
        大規模な設計変更は行わず、影響範囲が最小の応急処置を提案してください。
        恒久対応は別タスクとして整理してください。
        
        障害対応後は、再発防止策も作らせます。
        
        今回のバグについて、再発防止策を整理してください。
        
        出してほしいもの:
        
        原因
        
        直接原因
        
        根本原因
        
        検知できなかった理由
        
        追加すべきテスト
        
        追加すべき監視
        
        レビュー観点
        
        今後の改善タスク
        
        バグ報告文を作成する
        
        Claude Codeは、修正だけでなく、バグ報告文やPR説明文の作成にも使えます。
        
        修正後に、次のように依頼します。
        
        今回のバグ修正について、Pull Requestの説明文を作成してください。
        
        含める内容:
        
        問題の概要
        
        原因
        
        修正内容
        
        影響範囲
        
        テスト結果
        
        人間が確認すべき点
        
        出力例です。
        
        概要
        
        ログイン直後にマイページで500エラーが発生する問題を修正しました。
        
        原因
        
        ユーザー情報の取得完了前に、profile.nameを参照していたため、profileがundefinedの場合にエラーが発生していました。
        
        修正内容
        
        profileが未取得の場合のガード処理を追加
        
        ローディング中の表示を追加
        
        新規登録直後のユーザー向けテストを追加
        
        影響範囲
        
        マイページ表示処理
        
        ログイン直後の画面遷移
        
        テスト
        
        npm run test
        
        npm run typecheck
        
        npm run lint
        
        確認事項
        
        新規登録直後のユーザーでマイページが正常表示されること
        
        既存ユーザーで表示内容が変わっていないこと
        
        PR説明文を毎回整えるだけでも、レビューの負担はかなり下がります。
        
        よく使うバグ修正プロンプト集
        
        原因調査用です。
        
        このバグの原因を調査してください。
        まだコードは変更しないでください。
        関連ファイル、原因候補、最も可能性が高い原因、修正方針を整理してください。
        
        影響範囲確認用です。
        
        この修正の影響範囲を確認してください。
        同じ関数、同じコンポーネント、同じAPIを使っている箇所を探し、壊れる可能性がある機能を整理してください。
        
        最小修正用です。
        
        今回の目的はバグ修正のみです。
        無関係なリファクタリングは行わず、必要最小限の差分で修正してください。
        
        テスト追加用です。
        
        このバグを再現するテストを追加してください。
        現在の実装では失敗し、修正後に成功するテストにしてください。
        既存のテストスタイルに合わせてください。
        
        差分確認用です。
        
        git diffの内容を確認し、今回のバグ修正に不要な変更が含まれていないかレビューしてください。
        セキュリティ、影響範囲、テスト不足も確認してください。
        
        PR文作成用です。
        
        今回の変更内容をPull Requestの説明文としてまとめてください。
        概要、原因、修正内容、テスト結果、確認事項に分けてください。
        
        Claude Codeに任せすぎると危険なケース
        
        Claude Codeは便利ですが、すべてのバグ修正を任せきるのは危険です。
        
        特に注意が必要なのは、次のようなケースです。
        
        ・決済処理
        ・売上計算
        ・請求金額の計算
        ・契約情報の更新
        ・個人情報の取り扱い
        ・認証、認可
        ・管理者権限
        ・メール送信
        ・ファイル削除
        ・データベースのマイグレーション
        ・本番データの一括更新
        ・外部API連携
        
        これらは、少しの修正ミスが大きな事故につながる可能性があります。
        
        Claude Codeには調査や修正案の作成を任せても、最終的な確認は人間が行います。
        
        特に、データを削除する処理や、本番DBを変更する処理は慎重に扱います。
        
        データ削除、マイグレーション、本番DB更新に関わる変更は、実行前に必ず確認を求めてください。
        勝手に実行しないでください。
        
        チームで使うときの運用ルール
        
        チームでClaude Codeを使う場合は、ルールを決めておくと混乱しにくくなります。
        
        おすすめのルールは以下です。
        
        ・バグ修正前に原因調査を必須にする
        ・修正方針をPRに書く
        ・AIが修正した箇所は人間が必ず確認する
        ・テストなしのバグ修正は原則避ける
        ・Criticalな処理は2名以上で確認する
        ・CLAUDE.mdをチームで管理する
        ・無関係なリファクタリングを禁止する
        ・AIの指摘や修正をそのまま信用しない
        ・本番障害時は応急処置と恒久対応を分ける
        ・セキュリティ関連の修正は専門担当者が確認する
        
        チーム運用では、Claude Codeを「勝手に直してくれる存在」ではなく、「調査と修正案を高速化する補助者」として扱うのが安全です。
        
        バグ修正後に必ず確認するチェックリスト
        
        Claude Codeでバグを修正した後は、次の項目を確認します。
        
        ・バグは再現しなくなったか
        ・同じ原因の別バグが残っていないか
        ・修正差分は最小限か
        ・無関係なファイルを変更していないか
        ・既存仕様を壊していないか
        ・エラーを握りつぶしていないか
        ・テストを追加したか
        ・関連テストは通ったか
        ・lintやtypecheckは通ったか
        ・ログに機密情報が出ていないか
        ・PR説明文に原因と修正内容を書いたか
        ・人間が確認すべき点を整理したか
        
        このチェックをClaude Codeに依頼することもできます。
        
        今回のバグ修正について、リリース前チェックを行ってください。
        
        確認項目:
        
        修正差分は最小限か
        
        バグは再発しにくいか
        
        テストは十分か
        
        セキュリティ上の問題はないか
        
        既存仕様への影響はないか
        
        人間が確認すべき点は何か
        
        まとめ
        
        Claude Codeを使うと、バグ修正の調査、原因特定、修正、テスト追加、PR説明文作成までを効率化できます。
        
        特に効果が出やすいのは、エラーログの読み取り、関連ファイルの調査、影響範囲の確認、テスト不足の洗い出しです。
        
        ただし、いきなりコードを書き換えさせるのではなく、まず原因調査、次に修正方針、最後に実装という順番で進めることが重要です。
        
        CLAUDE.mdにバグ修正ルールを書き、必要最小限の差分で修正し、テストとGit差分を必ず確認することで、安全に効率化できます。
        
        Claude Codeは、バグ修正を丸投げするための道具ではなく、原因調査と修正作業を速く、正確に進めるための開発補助ツールとして使うのが現実的です。

Claude Codeでバグ修正を効率化する方法

Claude Codeとは

バグ修正でClaude Codeを使うメリット

まずはClaude Codeを起動する

バグ修正の基本フロー

最初に原因調査だけを依頼する

エラーログを渡して原因を絞り込む

再現手順を明確にする

修正前に影響範囲を確認する

修正方針を複数出させる

コード修正を依頼する

テストを追加してから修正を確認する

テストコマンドをClaude Codeに確認させる

Git差分を確認する

CLAUDE.mdにバグ修正ルールを書く

バグ修正時のルール

基本方針

修正前に確認すること

修正後に行うこと

禁止事項

Hooksで修正後のチェックを自動化する

本番障害時の使い方

バグ報告文を作成する

概要

原因

修正内容

影響範囲

テスト

確認事項

よく使うバグ修正プロンプト集

Claude Codeに任せすぎると危険なケース

チームで使うときの運用ルール

バグ修正後に必ず確認するチェックリスト

まとめ

Linuxでシェルスクリプトを使った運用自動化の実践例｜日常業務を効率化するための具体パターンを詳しく整理 2026.04.27

Claude Codeでリファクタリングを自動化する方法 2026.04.30