ウェブ · COURSE
レガシーコード移行を /goal で完走する
大規模な API 置換・フレームワーク移行を、検証可能な完了条件で自律実行。
audience
ウェブ部・DevOps
duration
90分
lessons
5 章
reviewed
2026.05
先に読むとよい
達成目安
全 5 レッスンを読み、コース完了マークを付ける
未完了
クイズ 3 問に挑戦し、正答率 80% 以上
未挑戦
コース構成
このコースで学ぶこと
- 01
なぜレガシー移行は止まるのか
数百 call site の置換は心理的負担が大きく、後回しになる。/goal で完走条件を渡せば自走させられる。
「getUserById_v1 を全箇所 getUser({id}) に置換する」のような移行は、技術的には簡単だが、量が多く飽きる。途中で別の作業が割り込むと、半端な状態で放置されることに。
Claude Code の `/goal` で完走条件(grep で空、テスト全 green)を渡せば、Claude が自律的に最後まで進めてくれます。
- 02
移行プロジェクトの設計
4 つを最初に決める:(1) 完了条件、(2) 触る範囲、(3) 触らない範囲、(4) 中断条件。
- **完了条件**: 例『grep -r "getUserById_v1" src/ の結果が空、かつ npm test exits 0』
- **触る範囲**: src/api/**, src/lib/**
- **触らない範囲**: apps/legacy/, infra/, .github/
- **中断条件**: テストが赤になった / 50 turn を超えた / 想定外の API が出てきた
- 03
/goal の条件文を書く
暴走防止と完走条件を 1 つの文に詰める。
text/goal すべての getUserById_v1 呼出を getUser({id}) に置換完了。 以下を満たすこと: 1. `grep -r 'getUserById_v1' src/` の出力が空 2. `pnpm test` が exit 0 3. `pnpm typecheck` が exit 0 以下に該当したら停止して人間に報告: - 50 turn を超えた - テストが 3 ターン連続で赤い - apps/legacy/, infra/, .github/ への変更が必要になった - 関数シグネチャの変更が必要になった出力イメージ/goal 実行中の進捗表示[goal] 進行中 — turn 18/50 ✅ grep -r 'getUserById_v1' src/ … 残り 6 箇所(開始時 41 箇所) ✅ pnpm test … 142 passed ⏳ pnpm typecheck … 未確認 直近の変更: src/api/○○.ts — 呼出 3 件を getUser({id}) に置換 src/lib/○○.ts — import を更新 …(完走まで継続) - 04
実行中の観察と介入
走り出したら放置できるが、要所で観察を。
- 別ターミナルで `git log --oneline` を眺める
- 10 ターンに 1 回、状況を `/goal` で確認(status 表示)
- テストが落ちたターンは詳しく読む(連鎖故障の早期発見)
- 想定外の変更要求があれば即 `/goal clear` で止める
- 05
完走後の振り返りと PR 化
走り終わったら『何が変わったか』をまとめて 1 つの PR に。
/goal の詳細text> /goal が完走しました。振り返りをまとめて: 1. git diff main..HEAD --stat で変更概要 2. 主要な変更パターンを 3 つに分類 3. 想定外だった点・追加で発生した修正 4. テストカバレッジの変化(before/after) 5. PR 本文ドラフト(タイトル + 説明 + テスト計画) 最後に、この移行作業を Skill 化できる部分があれば提案して。理解度チェック
Q1./goal でレガシー移行を自走させるときに、最初に決めるべきことは?
Q2./goal でレガシー移行を回す際、AI に任せてはいけない判断はどれか?
Q3./goal を本番ブランチで安全に走らせるための事前準備として正しいのは?