Claude Codeを使ったバグ修正ワークフローの自動化：再現からテストまで一気通貫

「また同じようなバグか」——エンジニアの時間はもっと大切なことに使えるはずだ

開発現場で働いたことがあれば、一度はこう思ったことがあるはずだ。「このバグ、スタックトレースを見れば原因は明らかなのに、修正して、テスト書いて、PRを出してレビューを依頼して——それだけで半日消えた」と。特に型エラー・nullポインター参照・未定義変数の参照・APIの戻り値の型ミスマッチといったバグは、原因特定から修正まで「考える時間」より「手を動かす時間」の方が長い。

正直に言うと、こういった「原因が特定しやすいバグ」の修正こそ、Claude Codeによる自動化が最も力を発揮する領域だ。バグレポートを受け取ってから再現・原因特定・修正コード生成・テスト追加・PR作成までをClaude Codeが担い、人間のエンジニアは生成されたPRをレビューするだけ——このワークフローを実現することで、バグ対応の作業時間を半分以下に削減できる。あるスタートアップでは、週あたりのバグ対応時間が15時間から6時間に減り、浮いた時間を新機能開発に充てられるようになったという事例がある。

自動化が効果的な対象は「スタックトレースが明確な例外エラー・型エラー・nullポインター参照・未定義変数の参照」だ。これらは原因の所在が明確で、修正パターンも限定的なため、AIが高い精度で対処できる。一方、ロジックのバグ・複雑な状態管理の問題・パフォーマンス劣化は依然として人間の深い判断が必要で、無理に自動化しようとすると誤った修正が入るリスクがある。最初は「自動化できるバグの種類」を絞ることが、信頼できるシステムを作る上で重要だ。

このワークフローを導入したチームの反応で一番多いのは「最初は半信半疑だったが、実際にPRが自動で上がってきたのを見て驚いた」という声だ。理屈ではわかっていても、実際に動くのを見るまでは信じられない——それがClaude Codeによるバグ修正自動化の現実だ。

GitHub IssueとClaude Codeを繋ぐ——トリガー設計が全ての出発点

バグレポートの自動処理はGitHub Actionsでトリガーを設定するところから始まる。bugラベルが付いたIssueが作成または更新されたときに、ワークフローが自動起動する設定を.github/workflows/auto-bugfix.ymlに書く。

ワークフローが起動したら、まずIssueの内容・スタックトレース・再現手順・関連ファイルパスを抽出してClaude Code APIに送信する。ここで重要なのは「コンテキストの質」だ。スタックトレースだけを渡すより、エラーが発生したファイルの該当コードも一緒に渡す方が、Claude Codeの修正精度が大幅に上がる。GitHub APIで関連ファイルの内容を取得してIssueの情報に付加する処理を事前に入れておくといい。

Claude Code APIを使う場合はclaude --print --allowedTools "Read,Edit,Bash"の形式でツール使用権限を明示的に付与する。Read・Edit・Bashツールへのアクセス権があれば、リポジトリ内のコードの読み取り・修正・テスト実行が可能になる。APIキーはGitHub Secretsで管理し、ワークフローファイルにはハードコードしないこと——これは安全運用の絶対条件だ。

実行時間には余裕を持たせておくことをおすすめする。Claude Codeがリポジトリを解析して修正を生成するプロセスには、コードベースの規模によって1〜5分かかる場合がある。GitHub Actionsのタイムアウトを短く設定しすぎると、処理が途中で切れてしまう。最初はtimeout-minutes: 15程度を設定しておき、実際の処理時間を確認してから調整するといい。

テスト自動追加とPR生成——「修正した」で終わらせない設計

バグを修正するだけで終わりにしてはいけない。同じバグが将来また発生しないことを保証するリグレッションテストを、修正と同時に追加することが品質の長期維持につながる。Claude Codeにこの「テスト追加まで含めた修正」を一気にやらせることが、このワークフローの真の価値だ。

Claude Codeへの指示には「修正後、この不具合が再発しないことを確認するユニットテストを追加してください。テストは失敗するケース（バグが存在する状態）と成功するケース（修正後の状態）の両方を含めてください」というプロンプトを入れておく。この指示があることで、修正コードとテストコードがセットで生成され、修正の妥当性をテストで証明できる状態になる。

修正とテストが生成されたら、GitHub APIを使って自動的にブランチを作成してコミットし、PRを開く。PRのタイトルと説明文も自動生成させる。「fix: [Issue #XX] nullポインター参照エラーを修正（UserService.getById）」のような形式でタイトルを生成し、説明文には「修正内容・影響範囲・追加したテストケースの説明」を含める。これだけでレビュアーが短時間でPRの内容を把握できる。

生成されたPRには「AI自動生成」ラベルを付けて通常のレビュープロセスに乗せること。人間のレビュアーは「修正コードが正しいか」「副作用がないか」「テストケースが適切か」を重点的に確認する。AIが生成したコードだからといって信頼しきらず、必ずレビューを経るという文化を守ることが、この自動化を長期的に安全に運用する鍵だ。

精度を上げ続けるプロンプト設計——3ヶ月で別物になる

バグ修正自動化の精度は、システムプロンプトの質に大きく依存する。最初の1ヶ月は精度が60〜70%程度でも落ち込まなくていい。週次でレビュアーからの「AIの修正が正しかったか」「テストが適切だったか」のフィードバックを収集し、プロンプトを改善するサイクルを回すことで、3ヶ月後には80〜90%以上の精度に達するケースがほとんどだ。

プロジェクト固有の情報をシステムプロンプトに詰め込むことが精度向上の近道だ。使用している言語・フレームワーク・テストライブラリ・コーディング規約・よく使うユーティリティ関数のパターンを記載しておくと、生成されるコードがプロジェクトのスタイルに合ったものになる。「修正箇所以外のコードは変更しない」「既存のテストを壊さない」「any型を使わない」といったプロジェクト固有の制約も明示しておくこと。

過去の修正成功事例をfew-shotとしてプロンプトに追加することも効果的だ。「このIssueの内容から、こういうコードの修正とテストを生成した」という実例が3〜5件あるだけで、Claude Codeの出力がプロジェクトの文脈に即したものになる。最初は精度が低くても、修正事例が蓄積されるほど自動化の精度が上がる——このフライホイールが回り始めると、バグ修正ワークフローは開発チームの強力な武器になる。