はじめに
コードを書くのは楽しい。AIと一緒だと、なお楽しい。
でも、「AIに任せすぎて考えるのをやめた」瞬間に、事故は起きます。
この記事が役立つ方
- AIエージェントと開発している方
- Cursorなどでリファクタを進めている方
- 「やっちまった」経験があるすべてのエンジニア
（※環境はWindows、ツールはCursorを使っています。）
終わりの始まり
Vibeに任せてアイデアを形にするのは楽しいものです、
しかし次第に、複雑な実装・過剰なデバッグログ・使われない関数が増え、
「流石に散らかりすぎ、片づけないと・・・」と思う時があります。
指示 : 現在のローカルソースを正として新規に出直したい。リポジトリは一掃したい
現在のソース一式をGitHubに上げたい。
リポジトリは https://github.com/○○○○/△△△△
リファクタで大幅に修正したのでリポジトリの既存ファイルは一掃したい。
提案 : どういうわけか「現在のフォルダを、どこかから持ってきたリファクタ後ファイルに差し替えてプッシュする」と解釈
ご要望ありがとうございます。
以下の手順で、現在のローカルソース一式をGitHubリポジトリ（○○○○/△△△△）に「既存ファイルを一掃」した上でアップロードできます。
# 既存ファイルを全削除
git rm -r --cached *
Remove-Item -Recurse -Force * -Exclude .git
# 新しいソース一式を配置（既に配置済みなら不要）
# すべてのファイルをステージ
git add -A
# コミット
git commit -m "リファクタ後の全ファイル差し替え"
# プッシュ
git push origin main
(雰囲気に身を任せて)「はいはい進めて」
＼ Remove-Item -Recurse -Force * -Exclude .git ／
気づいた時には遅し。ローカルファイル昇天。
もちろんゴミ箱なんて救済措置ありません。
復活への道のり
しかし奇跡的に、以下の幸運が重なっていました：
- 作業前コピーを保存していた
- リファクタ作業はエージェント主導で行っていたため、チャット履歴にほぼ全ての変更が記録されていた
この履歴をうまく活用すれば、コードの再構築は可能かもしれない。そう踏んで、復旧プロジェクトがスタートしました。
Step1. チャットログ取得
まずはCursorのチャット履歴を保存。
- チャット画面右上「･･･」→「Export Chat」でチャット履歴を保存
（複数ある場合は、すべて保存します）
Step2. リファクタ指示書の作成
次に、この履歴を使ってリファクタ指示書（REFACTOR_PLAN.md）を作成。
別環境のLLMに履歴を渡して、自動生成させます。
指示書作成のプロンプト例:
# ROLE
あなたは〈プロジェクト名〉のリードアーキテクト兼リファクタリングコンサルタントです。
# GOAL
添付する **履歴ファイル**（コード差分・コミットメッセージ・エラーログを含む）を精査し、
1. **リファクタ要件・設計一覧**
2. **リファクタ進行表（マイルストーン）**
3. **エラー & 修正履歴の要約**
を **マークダウン形式** で生成してください。
# OUTPUT FORMAT
- すべて日本語。
- 見出し構成
- `## リファクタ要件・設計一覧`
- `## リファクタ進行表`
- `## エラー & 修正履歴`
- **表は使用しない**。箇条書き（`-`）またはタスクリスト（`- [ ]`）で展開すること。
- `### Phase N: <目的を一言で>` の小見出しを付ける。
- 作業フェーズを区切って管理する。各フェーズには下記を必ず含める。
1. **改修タスク**（タスクリスト）
2. **動作確認タスク**（`- [ ] VERIFY:` で始める）
- フェーズの粒度は「動作確認 → 次フェーズ開始」が自然に回る単位で分割。
- 各要件は「目的 → 具体的な改修ポイント → 想定リスク」の順で簡潔に。
- 進行表は着手順序を上から。依存関係があれば `<依存: ...>` を添える。
- 参考コード片が必要な場合はバッククオートで囲み、**5行以内** に要約。
- あいさつや解説など余計な文章は不要。
- 「マイルストーン（1日以内）」等の作業期間ラベルは出力しない。
## 出力例
=== EXAMPLE START ===
## リファクタ要件・設計一覧
- **AuthService**: 認証ロジックとトークン発行を分離し、単一責任を徹底
- 目的: テスト容易性向上
- 改修ポイント: `auth.py` → `auth/service.py` + `auth/token.py`
- 想定リスク: 既存 API 互換性
## リファクタ進行表
- [ ] 現行テストの失敗ケース抽出
- [ ] `AuthService` 分割 <依存: テスト整備>
...
## エラー & 修正履歴
- **Exception: NullPointerException**
- 発生箇所: `UserRepository.java:42`
- 原因: DB接続のライフサイクル不一致
- 修正: DI コンテナで接続プールを管理
=== EXAMPLE END ===
ここに、エクスポートした履歴ファイルを添付し、指示書を出力します。
これにより、作業手順が明確な「リファクタ指示書」が完成しました。
作成した REFACTOR_PLAN.md は、Cursorから参照できる場所に配置しておきます。
Step3. 復活の呪文を唱える（Cursorのカスタムエージェント）
いよいよ実作業。
Cursor上に新しく「カスタムエージェント」を設定。
あなたはプロジェクトのリファクタリング支援エージェントです。
以下のルールに従って、Cursor 上での一貫したリファクタ作業をサポートしてください。
1. **REFACTOR_PLAN.md** を常に参照し、該当フェーズ番号を明示する
2. 各修正は **小さなコミット単位** で実行し、コミットタグを必ず提案する
3. 修正前後の **検証ポイント**（ユニットテスト or 手動動作確認）を毎回提示し、確認完了後に次のフェーズへ進む
4. **ドキュメント更新**（README や REFACTOR_PLAN.md への反映漏れ）がないか必ずチェックする
5. 過去のエラー対応履歴（モジュール未検出／JSON構文エラー／重複INSERT 例外など）を踏まえ、
同じ問題が再発しないよう事前に注意点を明示する
カスタムエージェントを選択したら、先程のREFACTOR_PLAN.md を選択します。
あとはエージェントがコーディングを再現してくれます。
学びとTips
✅ 良かったこと
- チャット履歴は最強のタイムマシン
- 実装目的や背景まで含めて記録されていたため、指示が少なくても再現可能
⚠️ 気をつけるべきこと
- 依存関係や設定周りは「別途、明示的に指示しないと実装されない」ことが多い
- 静的解析や人間のレビューと併用すべき
💡 使えるTips
- 「リファクタ支援プロンプト」はテンプレ化しておくと便利
-
.chat.jsonや.mdで履歴を構造化しておくと後々助かる
あとがき：開発環境における「保険」としてのLLM活用
「よそ見運転、ダメ。ゼッタイ。」
でも、事故は避けられないかもしれない。
その時に備えて、履歴を残す文化と、復旧の手順を持っておくことが、未来の自分を救います。
いまやAIは単なる補助ツールではなく、「開発プロセスの記録者」であり「復元装置」にもなり得ます。その力を活かすも殺すも、使う側の設計力と習慣次第。
皆さんも、事故から学べるVibe Coding、始めてみませんか？