ボタンの色を直してほしいだけだったのに、返ってきたコードでは、なぜかページの構成まで変わっている。頼んでいない場所が"改善"されていて、しかも前より悪い。差し戻すと、また別の場所が変わって・・・。
AIに直しを頼むと、頼んでいない場所まで書き換えられる。これは初心者から上級者まで、全員が遭遇する現象です。この講のゴールは、変えてほしいことと同じ熱量で、変えないでほしいことを伝えられるようになることです。
リフォームにたとえます。
「台所を明るくしてください」とだけ伝えて業者に任せたら、どうなるか。腕のいい業者ほど、よかれと思って踏み込みます。壁を抜いて開放的にしました、ついでに配線も新しくしました・・・。そして、抜かれた壁が、実は建物を支える柱を兼ねていたら。
事故の原因は、業者の腕ではありません。壊してほしくない柱を、先に伝えなかったことです。リフォームの依頼には本来、2つの情報が要ります。変えてほしいこと。そして、触らないでほしいこと。
AIへの修正依頼も、まったく同じです。AIには、頼まれた箇所を直すついでに、目に入った「改善できそうな箇所」へ手を伸ばす癖があります。悪意ではなく、そういう働き者なのです。だから、任せる側が柱を指定します。「ボタンの色を変えて。ただし、文章とページの構成には触らない」。この後半・・・守るものの指定があるだけで、返ってくるものの安全性がまるで違います。
もう1つ、順序を入れ替える手もあります。作らせる前に、影響範囲を聞くのです。「この変更で影響が出る場所を、先に列挙して」。工事の前に、どの壁に響くかを図面で確認するのと同じです。列挙された範囲が思ったより広ければ、その変更自体を考え直せる。作らせてから気づくより、一往復ぶん安上がりです。
自分のプロジェクトの柱がどこかは、実は第2部までで調べてあります。どのファイルが本体か（第7講）。どこに鍵とお金と権利が関わっているか（第8講）。どの機能が動いていることが大事か（第2講の一覧表）。守るものを言える人とは、自分の建物のことを分かっている人なのです。
自分のプロジェクトの「柱のリスト」を作ります。
紙に、触ってほしくないものを書き出してください。観点は3つです。
自分の一枚なら、3行で終わるかもしれません。それでいいのです。次にAIへ修正を頼むとき、この3行を指示の末尾に貼る。「ただし、以下には触らないでください」。たった一言の前置きで、あなたの依頼はリフォーム事故の大半を免れます。
そのまま貼って使えます。
3つ目は、受け取りのときの検収です。AIは、聞けば正直に申告します。聞かなければ、静かな"改善"が混ざったままになります。
返ってきたコードを、何が変わったか見ずに丸ごと差し替えること。
修正のたびに、AIはコード全体を出し直してくることがあります。それを毎回まるごとコピーして上書きする運用は、手軽ですが危険です。指定外の変更が混ざっていても、気づく機会が一度も無いからです。こうして、動いていた機能が静かに壊れ、気づくのは何日も後になります。第13講のセーブがあれば戻れますが、今度は「どのセーブ地点までは無事だったのか」を探す羽目になる。
差し替える前に、何が変わったのかを確認する。自分で全部読めなくても、質問例3で申告させれば済みます。検収してから、受け取る。工事の引き渡しと同じ順番です。