Claude Codeでデバッグ・コードレビューを効率化する

デバッグこそClaude Codeの真価が出る場面

コードを書く時間より、バグを探す時間の方が長い——これは多くの開発者の実感でしょう。Claude Codeはプロジェクト全体のファイルを横断的に読めるため、人間が1つずつファイルを追いかけるよりも圧倒的に速くバグの原因を特定できます。

このレッスンでは、デバッグとコードレビューの具体的な進め方を実践例で解説します。

最もシンプルで効果的な方法は、エラーメッセージをそのまま貼り付けることです。

このエラーを修正して:

TypeError: Cannot read properties of undefined (reading 'map')
  at UserList (src/components/UserList.tsx:15:22)

Claude Codeは該当ファイルを読み、エラーの原因を特定し、修正案を提示します。スタックトレースが含まれていれば、関連するファイルも自動で確認してくれます。

エラーメッセージだけでは原因が特定しにくい場合、再現手順を添えると精度が上がります。

ログインページでメールアドレスを入力して送信ボタンを押すと、画面が真っ白になる。コンソールには何も出ない。

サーバーログやビルドログが長い場合も、そのまま渡してしまいましょう。

以下のビルドログからエラーの原因を特定して:

[ログをペースト]

Gitの差分をClaude Codeにレビューさせることができます。

mainブランチとの差分をレビューして。バグの可能性、パフォーマンスの問題、セキュリティリスクの観点で

Claude Codeが git diff を実行し、変更箇所を分析して問題点を指摘します。

gh pr diff 42 の内容をレビューして

GitHub CLIと組み合わせることで、PRの差分を直接取得してレビューできます。

レビューで特に確認したい観点がある場合は、明示的に伝えます。

以下の観点でレビューして:
- SQLインジェクションの可能性
- 未処理のエラーケース
- N+1クエリの有無
- 命名規則の統一

大規模なリファクタリングを一度にやると、既存の動作を壊すリスクがあります。Claude Codeでも段階的に進めるのが安全です。

1回目: src/utils/api.ts のリファクタリング案を出して（まだ変更しないで）
2回目: その案で進めよう。テストが通ることを確認しながら進めて
3回目: リファクタリング前後でテスト結果が同じか確認して

リファクタリング前に既存の動作を保証するテストを書いておくと安全です。

src/utils/api.ts の現在の動作に対するテストを書いて。リファクタリング後も同じ結果になることを確認できるように

Claude Codeの強みは、プロジェクト全体を俯瞰できることです。人間が1ファイルずつ追いかけると時間がかかるバグも、Claude Codeなら関連ファイルを一気に走査して原因を突き止めます。

ユーザーが商品をカートに入れても、決済画面で数量が0になるバグがある。カート追加から決済画面表示までのデータフローを追跡して原因を特定して

このような指示を出すと、コンポーネント → ストア → API → コンポーネントの流れを自動で追跡してくれます。

Claude Codeは1つのターミナルから複数のサブエージェントを並列で動かすことができます。大規模プロジェクトのレビューでは、ディレクトリごとに分担させると高速です。

ただし注意点があります。サブエージェントの出力をそのまま信頼すると、事実と異なる指摘が混ざることがあります。最終的な判断は人間が行う、というルールを徹底してください。

CLAUDE.mdにデバッグ関連の情報を書いておくと、毎回の説明が不要になります。

# デバッグ
- テスト実行: npm test
- E2Eテスト: npx playwright test
- ログ確認: logs/ ディレクトリ
- DB接続: .env.local の DATABASE_URL

テストの実行コマンドとログの場所を書いておくだけで、Claude Codeが自律的にテストを走らせて結果を確認するようになります。

Claude Codeを使ったデバッグとコードレビューのポイントは3つです。エラーメッセージはそのまま貼る。レビュー観点は明示的に伝える。大きな修正は段階的に進める。これだけで、バグ修正とレビューの時間を大幅に短縮できます。