03. AIにリファクタリングを依頼するプロンプト

品質チェックで直したい箇所が見えてきたら、次はコードの整理（リファクタリング）です。

ただし、リファクタリングはバイブコーディングで最も事故が起きやすい作業でもあります。「このコードを綺麗にして」と丸投げすると、AIは親切心から動作まで変えてしまい、動いていたはずの機能が静かに壊れます。

この記事では、動作を変えずにコードだけを整理させるための、範囲の切り方と指示の書き方を扱います。

この記事のサブコンテンツ

リファクタリングの鉄則：動作を変えない
依頼する前に必ずやる3つの準備
目的別プロンプトテンプレート
Spec Kitを使ったリファクタリング
やってはいけない依頼の仕方
リファクタリング後の検証手順
まとめと次のステップ

1. リファクタリングの鉄則：動作を変えない

リファクタリングの定義は、「外から見た振る舞いを変えずに、内部の構造だけを改善すること」です。

この「動作を変えない」を毎回明示的に伝えないと、AIは高確率で次のことをします。

ついでにバグを直す（直したつもりで別の挙動になる）
ついでに機能を足す（頼んでいない）
ついでにライブラリを増やす（依存が膨らむ）
ついでに変数名を全部変える（差分が読めなくなる）

どれも善意ですが、リファクタリングと機能変更が混ざると、壊れたときに原因を切り分けられなくなります。

2. 依頼する前に必ずやる3つの準備

① コミットしておく

これが最重要です。リファクタリング前の状態がコミットされていれば、何が起きても git restore で戻せます。

git status
git add .
git commit -m "chore: リファクタリング前の作業状態を保存"

② 現在の動作を書き出しておく

「壊れていないこと」を確認するには、壊れていない状態が何かを先に決めておく必要があります。

リファクタリング前の動作（これが変わったら失敗）:
- 習慣を追加するとリストの末尾に表示される
- チェックすると背景が薄い緑になり、文字に取り消し線が入る
- アプリを再起動しても、追加した習慣とチェック状態が残る
- 空文字では追加できない

③ 範囲を1つに絞る

「アプリ全体を綺麗にして」は失敗します。1回のリファクタリングで触るのは1ファイル、多くても2〜3ファイルにしてください。

3. 目的別プロンプトテンプレート

① 肥大化したファイルを分割する

【タスク: リファクタリング（責務の分離）】

以下のファイルが肥大化し、UIとロジックが混ざって読みにくくなっています。

### 絶対に守ること
- 外から見た動作を一切変えないこと。バグ修正も機能追加もしないこと。
- 既存の props 名・関数名・エクスポート名は変更しないこと。
- 新しいライブラリを追加しないこと。

### やってほしいこと
1. データ操作のロジックを `hooks/` 配下のカスタムフックに切り出す。
2. 画面固有のUIパーツを `components/` 配下に切り出す。
3. 切り出した結果、元のファイルがどうなるかを示す。

### 出力形式
- 変更後のファイル構成を先に一覧で示してください。
- そのうえで、ファイルごとに変更後の全文を出してください。
- 最後に「動作が変わっていないと言える根拠」を箇条書きで説明してください。

### 対象コード
[ここにファイルの内容を貼り付ける]

② 重複したコードをまとめる

【タスク: リファクタリング（重複の解消）】

以下の複数ファイルに、似たようなコードが繰り返し現れています。

### 絶対に守ること
- 動作を変えないこと。
- 「似ているが意図が違う」箇所を無理に共通化しないこと。
  共通化すべきでないと判断した場合は、その理由を説明してください。

### やってほしいこと
1. 本当に共通化すべき箇所だけを特定し、共通関数・共通コンポーネントに切り出す。
2. 切り出した先の置き場所（ファイルパス）も提案する。

### 対象コード
[ここに複数ファイルの内容を貼り付ける]

③ 型を厳しくする

【タスク: リファクタリング（型の厳格化）】

コード内に `any` や暗黙の any が残っています。

### 絶対に守ること
- 実行時の動作を変えないこと。型注釈の追加と型定義の整理のみ行うこと。
- 型を通すために `as` でのキャストや `@ts-ignore` を使わないこと。
  どうしても必要な場合は、その理由をコメントで明記すること。

### やってほしいこと
1. `any` を具体的な型に置き換える。
2. 複数箇所で使われている型を `types/` に切り出す。
3. 変更後に `npx tsc --noEmit` が通ることを確認する。

### 対象コード
[ここにファイルの内容を貼り付ける]

4. Spec Kitを使ったリファクタリング

コーディング編で導入した Spec Kit は、リファクタリングにもそのまま使えます。規模が大きいときほど有効です。

/speckit.specify

既存コードの構造を整理する（動作は変更しない）。

### この作業のゴール
- `app/(tabs)/index.tsx` に集中しているロジックを、UIとデータ操作に分離する。
- 分離後も、アプリの外から見た動作は現在とまったく同じであること。

### 変更してはいけないこと
- 画面の見た目、遷移、保存されるデータの形式。
- 既存コンポーネントの props のインターフェース。

### 完了の条件
- `npx tsc --noEmit` が通る。
- 実機で「追加・チェック・削除・再起動後の復元」が現在と同じように動く。

そのまま /speckit.plan → /speckit.tasks → /speckit.implement と進めます。タスクが小さく分割されるので、途中で壊れてもどのタスクが原因かすぐ分かるのが利点です。

/speckit.analyze は主に仕様・計画・タスク間の整合性を確認するために使います。実装の振る舞いが変わっていないことは、このコマンドだけでは確認できません。差分レビューと、次節のテスト・実機確認を行ってください。

5. やってはいけない依頼の仕方

悪い依頼	何が起きるか	代わりにこう書く
「このコードを綺麗にして」	基準がないので、AIの好みで全面書き換えされる	「UIとデータ操作を分離して。動作は変えないで」
「アプリ全体をリファクタリングして」	差分が巨大になり、レビューも切り戻しも不可能になる	「`hooks/useHabits.ts` だけを対象に」
「ついでにバグも直して」	リファクタリングと修正が混ざり、原因の切り分けができなくなる	先にリファクタリングを完了・コミットしてから、別途バグ修正を依頼する
「もっと良い書き方にして」	流行りのライブラリを勝手に導入されることがある	「新しいライブラリを追加せず、標準機能の範囲で」

6. リファクタリング後の検証手順

リファクタリングは「終わった」ではなく「壊れていないことを確認した」で完了です。

# 1. 型が通るか
npx tsc --noEmit

# 2. Lintが通るか
npx expo lint

# 3. テストがあれば実行する
npm test

# 4. 変更内容を自分の目で読む
git diff

git diff は飛ばさないでください。差分が想定より大きいときは、その時点で何かがおかしいというサインです。

そのうえで、準備段階で書き出した「リファクタリング前の動作」を実機で1つずつなぞります。すべて同じように動けば成功です。

問題がなければ、リファクタリングだけを独立したコミットとして残します。

git add hooks/useHabits.ts app components
git diff --cached
git commit -m "refactor: 習慣一覧のUIとデータ操作を分離（動作変更なし）"

機能変更と混ぜずにコミットしておくと、あとで不具合が出たときにこの変更だけを切り戻せます。

7. まとめと次のステップ

リファクタリングでAIに事故を起こさせない鍵は3つです。先にコミットする、動作を変えないと明示する、範囲を1ファイルに絞る。

コードが整理できたら、次はいよいよ実害に直結するテーマです。次の記事では、漏れたら取り返しのつかない「04. APIキーや秘密情報を漏らさないための基本」に進みましょう。