4
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

既存コードに機能を足すとき、AIに「全部書き直し」をさせないための頼み方

4
Posted at

この記事について

一度動いたアプリに後から機能を足すとき、AIに雑に頼むと「既存コードをまるごと書き直した版」が返ってきて、動いていた部分まで壊れることがあります。

この記事では、未経験者が既存コードへの機能追加をAIに頼むときに、変更範囲を最小限に抑えてもらうための依頼の仕方と、安全に試すためのgit運用をまとめます。

なぜ「全部書き直し」が返ってくるのか

AIは、渡された情報の範囲でしか状況を判断できません。既存コードの構造や「なぜこう書いてあるか」を伝えずに「検索機能を付けて」とだけ頼むと、AIは自分の考える"きれいな完成形"を一から提示しがちです。その結果、既存の変数名・状態管理・スタイルなどが総取り替えになり、動いていた部分まで影響を受けます。

頼み方1: 既存コードと「変えないでほしい範囲」を明示する

❌ 「検索機能を付けて」
✅ 「下記が今の一覧表示コードです(コード貼付)。
   この既存の構造・変数名・stateの持ち方はできるだけ変えずに、
   検索で絞り込む機能だけを追加したい。
   追加・変更が必要な箇所を、差分(どこに何を足すか)の形で教えてください。」

ポイントは3つです。

  • 既存コードを実際に貼る(AIに現状を渡す)
  • 「変えないでほしい範囲」を明示する(構造・変数名・stateなど)
  • 「差分の形で」と出力形式を指定する(全文書き直しを防ぐ)

頼み方2: 一度に1機能だけ頼む

「検索とソートとページングを付けて」とまとめて頼むと、変更範囲が広がり、レビューも大変になります。まず検索だけ、動いたらソート、という順で1つずつ頼む方が、各ステップで動作確認でき、問題の切り分けも簡単です。

git運用: 機能追加はブランチを切ってから

機能追加の前に、作業用のブランチを切っておくと、既存の動いている状態(main)を汚さずに試せます。

# 動いている状態を必ずコミットしてから
git add .
git commit -m "search機能の追加前の状態"

# 機能追加用のブランチを作って移動
git switch -c feature/search
# (ここでAIと一緒に検索機能を実装・動作確認)

git add .
git commit -m "一覧に検索機能を追加"

うまくいったら main に取り込みます。

git switch main
git merge feature/search   # マージ済みなので、後片付けは git branch -d feature/search でOK

もし途中で「やっぱりこの実装は失敗だった」となったら、その変更を捨ててから main に戻れば、動いていた状態に一瞬で戻れます。

⚠️ ここが未経験者のハマりどころです。feature/search で編集した内容をコミットも破棄もしないまま git switch main すると、その変更が main 側に持ち越されたり、競合する場合は error: Your local changes would be overwritten で切り替え自体が拒否されます。「失敗したから放置して戻ろう」がそのままだと、戻ったつもりで変更が残っている、という事故になります。

失敗した変更を捨てて元に戻る場合は、先に変更を破棄します。

git restore .                 # 未コミットの変更を捨てる(残しておきたいなら git stash)
git switch main               # これで安全に戻れる
git branch -D feature/search  # 失敗ブランチを削除(未マージなので大文字-Dで強制削除)

ブランチは"失敗しても元に戻れる作業場"として使えるので、機能追加のような「壊すのが怖い作業」と特に相性が良いです。ポイントは、ブランチを切り替える前に「コミットする」か「捨てる(restore/stash)」かをはっきりさせることです。

動作確認まではAIに任せきりにしない

差分をもらって適用したら、必ず自分で動かして確認します。AIの提案が既存コードと噛み合わず、エラーになることもあります。その場合はエラーメッセージをそのまま渡せば直りますが、「AIが出したから正しいはず」と確認をスキップすると、壊れたまま次に進んでしまいます。

まとめ

既存コードへの機能追加をAIに頼むときは、(1)既存コードを貼る、(2)変えない範囲を明示する、(3)差分の形で頼む、(4)1機能ずつ頼む、の4点で変更範囲を最小化できます。さらに作業用ブランチを切っておけば、失敗しても動いていた状態に戻れます(ただし切り替え前に、変更をコミットするか捨てるかを必ずはっきりさせること)。「壊すのが怖い」を仕組みで解消するのがコツです。


※ Qiita 読者の方には易しすぎる内容なので、プログラミング未経験の知り合いへの紹介や、社内研修・後輩育成の参考としてどうぞ。

未経験から Next.js + Supabase + Claude Code で Webアプリを作って公開するまでを体系化した教材があります。

4
0
1

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
4
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?