リファクタリングをClaudeに任せる方法【安全な改善手順】

なぜリファクタリングにClaude Codeを使うのか

リファクタリングは:

• 動作を変えずにコードを改善する作業
• 影響範囲の把握が難しい
• ミスすると既存機能が壊れる

Claude Codeを使うと:

• 影響範囲を自動で分析
• 一貫した変更を適用
• テストで安全性を確認

リファクタリングの基本フロー

1. 現状分析（Plan Mode）
2. 改善方針の確認
3. テストの追加（先にテスト）
4. リファクタリング実行
5. テストで確認
6. コミット

実践: 安全なリファクタリング

STEP 1: 現状分析

まずPlan Modeで現状を把握:

/plan

src/lib/api.ts をリファクタリングしたい。
まず現状を分析して:
- どんな関数があるか
- どこから呼ばれているか
- 問題点は何か

STEP 2: 改善方針の確認

Claudeが分析結果を報告したら:

以下の方針でリファクタリングして:
- 共通処理をユーティリティ関数に抽出
- エラーハンドリングを統一
- 型定義を厳密に

ただし、まだ実行しないで。方針だけ教えて。

STEP 3: 先にテストを追加

リファクタリング前にテストを書く:

リファクタリング対象の関数のテストを先に書いて。
現在の動作を保証するテスト。

テストがあれば、リファクタリング後に動作確認できます。

STEP 4: リファクタリング実行

/implement

方針通りにリファクタリングを実行して。
小さい単位でコミットしながら進めて。

STEP 5: テスト実行

テストを実行して、全部通るか確認して。

よくあるリファクタリングパターン

パターン1: 関数の抽出

Before:

async function fetchUsers() {
  const res = await fetch('/api/users', {
    headers: { 'Authorization': `Bearer ${getToken()}` }
  })
  if (!res.ok) throw new Error('Failed to fetch')
  return res.json()
}

async function fetchPosts() {
  const res = await fetch('/api/posts', {
    headers: { 'Authorization': `Bearer ${getToken()}` }
  })
  if (!res.ok) throw new Error('Failed to fetch')
  return res.json()
}

Claudeへの指示:

API呼び出しの共通処理を抽出して。
認証ヘッダーとエラーハンドリングを共通化。

After:

async function apiFetch<T>(endpoint: string): Promise<T> {
  const res = await fetch(endpoint, {
    headers: { 'Authorization': `Bearer ${getToken()}` }
  })
  if (!res.ok) throw new Error(`Failed to fetch ${endpoint}`)
  return res.json()
}

const fetchUsers = () => apiFetch<User[]>('/api/users')
const fetchPosts = () => apiFetch<Post[]>('/api/posts')

パターン2: 型定義の強化

Claudeへの指示:

このファイルの型定義を強化して:
- anyを排除
- 適切な型を定義
- 型ガードを追加

パターン3: コンポーネントの分割

Before: 500行の巨大コンポーネント

Claudeへの指示:

このコンポーネントを適切な単位に分割して。
- ロジックはカスタムフックに
- UIは小さいコンポーネントに
- 再利用可能な部分を特定

パターン4: 命名の改善

Claudeへの指示:

このファイルの変数名・関数名を改善して。
- より意味が明確な名前に
- 一貫した命名規則で
- 略語は避ける

大規模リファクタリング

複数ファイルにまたがるリファクタリングの場合:

Phase 1: 影響範囲の特定

UserServiceクラスをリファクタリングしたい。
このクラスを使っているファイルを全て洗い出して。

Phase 2: 段階的に実行

以下の順序でリファクタリングして:
1. まずインターフェースを定義
2. 新しい実装を作成（古い実装は残す）
3. 呼び出し側を一つずつ移行
4. 古い実装を削除

各ステップ完了後にコミット。

Phase 3: 検証

リファクタリング前後で:
- 全テストが通ること
- パフォーマンスが劣化していないこと
を確認して。

安全のための原則

原則1: 小さく、頻繁にコミット

変更は小さい単位でコミットして。
1つのコミット = 1つの改善。

原則2: テストファースト

リファクタリング対象のテストを先に書いて。
テストがない状態でリファクタリングしない。

原則3: 動作変更とリファクタリングを分ける

❌ 「リファクタリングついでに機能も追加」
✅ 「まずリファクタリング、次に機能追加」

原則4: レビューを依頼

リファクタリング完了。
変更内容をレビューして、問題があれば指摘して。

リファクタリングすべきサイン

以下の症状が見られたらリファクタリングを検討:

このファイルで以下の問題を探して:
- 重複コード
- 長すぎる関数（50行以上）
- 深すぎるネスト（3段階以上）
- 曖昧な命名
- any型の使用
- コメントで説明が必要な複雑な処理

次のステップ

リファクタリングの方法をマスターしました！

次は、テスト駆動開発（TDD）をClaude Codeで実践する方法を学びましょう。

→ テスト駆動開発 with Claude Code

まとめ

• リファクタリング前にPlan Modeで分析
• 先にテストを書いてから改善
• 小さい単位でコミット
• 動作変更と構造改善は分ける
• Claudeに影響範囲を分析させる
• 完了後はレビューを依頼