全自動コードリファクタリング

ファイル間の依存関係を理解し、1 つの指令でプロジェクト全体をバッチリファクタリング —— 変数名を変更するのではなく、真の構造レベルのリファクタリング

従来のリファクタリングがどれだけ苦痛か、あなたならわかるはず

手動リファクタリング = 残業 + 祈り

関数名を変更すると、100 個のファイルで全体検索置換が必要。完了後も漏れがないか心配になり、テストを実行して 3 箇所で破壊発見、また二分探索で原因調査。プロジェクトが大きいほど動かしたくなくなり、技術負債が積み重なり、誰もそのコードに触りたくなくなります。クラス分割やモジュール抽出みたいな大手術のことはいいません。手動で行えば、最低 1 週間かかります。

OpenClaw がこの問題を解決する方法

プロジェクト全体をスキャンしたら、ファイル間の依存関係を理解

OpenClaw は現在開いてるファイルだけを見るのではありません —— プロジェクト全体ディレクトリを読込、import チェーン、関数呼び出し関係、型定義、モジュール依存関係を分析してから変更を行います。変更完了後は自動でテストを実行して既存機能に破壊がないか確認します。「このプロジェクトをクラスから Hooks に変更してください」と指示すれば、残りは AI がやります。

すぐに使えるプロンプト

これ 3 つのプロンプトは最も一般的なリファクタリングシナリオをカバーしているので、そのままコピペできます。

プロジェクトを Class Component から React Hooks にリファクタリング ゴールデン指令
現在のプロジェクト内のすべての React Class Component ファイルを分析してください。

次のリファクタリングタスクを実行してください:
1. 各 class component を関数コンポーネント + Hooks に変換
2. this.state / this.setState → useState
3. componentDidMount / componentWillUnmount → useEffect
4. 再利用可能なロジックをカスタム Hook に抽出
5. props インターフェースを変更しないまま、親コンポーネントが修正不要に
6. 既存テストを実行して破壊がないことを確認

各ファイルの変更を別々にリストアップし、何を変更したか、なぜこのように変更したのかを説明してください。
このプロンプトは Claude Opus で最高の効果が得られます。this 参照とライフサイクルのマッピングを正確に追跡できます。ファイル数が多いプロジェクトはディレクトリごとにバッチで実行することをお勧めします。
プロジェクトのエラーハンドリングパターンの統一 高度なテクニック
プロジェクト内のすべてのエラーハンドリングコードを分析してください。

現在の状態の監査:
- すべての try-catch ブロック、.catch() 呼び出し、エラーコールバックを見つけて
- 矛盾している部分をリストアップ(エラーを無視するもの、console.log だけするもの、上に投げるもの)

統一スキーム:
1. 統一された AppError クラスを作成(code, message, cause を含む)
2. グローバルエラーハンドリングミドルウェアを作成
3. すべてのビジネスロジックレイヤーで AppError を使用、new Error を直接スロー しない
4. API レイヤーは { success: false, error: { code, message } } という統一形式で返す
5. 変更後のファイルリストと diff を提供

このプロンプトは AI に先に監査させてから変更させるので、無闇な変更を避けられます。プロジェクトのエラーハンドリングが混乱している場合に適しています。
JavaScript プロジェクトを TypeScript に移行 ゴールデン指令
この JavaScript プロジェクトを TypeScript に移行したいです。

以下の手順で実行してください:
1. プロジェクト構造を分析し、tsconfig.json を生成(strict モード)
2. エントリーファイルから始めて、依存関係の順序で逐個 .js → .ts/.tsx に移行
3. すべての関数パラメータと戻り値に型注釈を追加
4. any の使用を最小限にして、できるだけ具体的な型を使用
5. サードパーティライブラリの @types パッケージをインストール
6. types/ ディレクトリを作成して共通型定義を保管
7. tsc --noEmit を実行して通過確認、型エラーなし

各ファイルの変更を要約してリストアップしてください。一部の場所で any を必ず使う必要がある場合は、理由を説明してください。
JS から TS への移行は最も一般的な移行です。このプロンプトは AI に依存関係の順序で移行させるので、ランダムな移行によるエラーが出ません。

推奨設定

リファクタリングタスクはこの設定で実行することをお勧めします。AI をより慎重で可制御にします。

skill_config — コードリファクタリング専用
# .openclaw/skill_config.yaml
refactor:
  model: claude-opus-4-6      # リファクタリング首選 Opus、ファイル間の理解が最強
  context_depth: full         # プロジェクト構造全体を読込
  safety:
    dry_run: true              # 先にプレビュー確認後に書込
    run_tests: true            # 変更完了後自動テスト
    backup: true               # 変更前にバックアップ
  ignore:
    - node_modules/
    - dist/
    - "*.min.js"

OpenClaw vs Copilot —— リファクタリング能力比較

OpenClaw リファクタリング
  • プロジェクト全体の依存グラフを理解し、1 箇所変更したら全参照自動更新
  • ファイル間バッチ名前変更、共通モジュール抽出、巨大ファイル分割
  • 変更完了後自動テスト実行、問題あれば即座にロールバック
  • カスタムリファクタリング規則とブラックリスト対応
VS
Copilot リファクタリング
  • 主に現在のファイル内の補完と修正提案
  • ファイル間のリファクタリングは手動でファイルを逐個開く必要がある
  • 組込テスト検証プロセスなし
  • IDE のリファクタリング機能に依存し、IDE プラグインの能力に制限

より詳しい比較 👉 OpenClaw vs Copilot · OpenClaw vs Cursor

実践場景:大規模プロジェクトのリファクタリング

10 万行の React プロジェクトを Class から Hooks に移行
3 年物の古いプロジェクトで、200 個以上の class component があり、チームは Hooks に移行したいけど誰も手をつけたくない。手動移行には 3 ヶ月必要と予測。
OpenClaw スキーム
AI にプロンプトでモジュール単位にバッチ移行させ、各バッチ完了後テスト実行。全体 2 日で完了、本番環境バグゼロ。AI が this バインディング、ライフサイクルマッピング、ref 変換などの誤りやすい部分を正しく処理できるのが重要。
従来スキーム
手動でファイルごとに変更。50 番目のファイルに到達する頃から漏れが出始め、this バインディング喪失がランタイムエラーになります。最終的に 2 ヶ月かかり、本番に十数個のバグが残りました。
結論:プロジェクトレベルのリファクタリングは AI が最も価値を発揮するシナリオです —— 速くなるのではなく、規模の圧倒的な違い。

リファクタリングシナリオはどのモデルを使用するか

リファクタリングはモデルのコード理解能力を最も要求するので、ここケチらないでください。

  • Claude Opus 4.6 —— 大規模リファクタリング首選、ファイル間依存追跡が最強
  • GPT-4o —— 中小規模リファクタリングで十分、速度更に速い
  • DeepSeek V3.2 —— 予算制限時の代替案、効果も悪くない

いくつかの経験

💡 大規模プロジェクトは一度に全部変更しないでください —— モジュール単位でバッチリファクタリング、各バッチ完了後テスト実行確認、次のバッチへ。
⚠️ リファクタリング前にテストカバレッジが十分か確認してください。テストがないコードは AI で変更完了後もあってるかどうか確認できない。
ℹ️ dry_run モードを先に使ってプレビュー確認。問題ないと思ったら AI に実際にファイルに書込させます。
この記事は役に立ちましたか?