「バグを直して」と「このバグを直して」では、AIの修正範囲と副作用はどう変わるか

比べたいのは「文の長さ」ではなく「指す力」

先に、何を比べるのかをはっきりさせておきます。この実験で変えるのは、依頼文が「どのバグか」をどこまで特定しているかという一点です。丁寧さや文章量そのものを比べるわけではありません。

依頼文は次の三段階で用意します。

• 条件A：「バグを直してください。」とコード全体だけを渡します。どのバグかは書きません。
• 条件B：コード全体に加えて、症状と再現手順を書きます。「このバグ」が何を指すのかを特定する条件です。
• 条件C：条件Bに、期待する動作と「それ以外は変えないでください」という範囲の指定を足します。

題名の二つの言い方に対応するのはAとBです。Cは、特定に加えて範囲まで縛ると差がさらに出るかを見るための任意の条件で、省いても実験は成立します。

見たい指標は三つです。主なバグが直ったか、変更がどこまで及んだか（修正範囲）、直したはずのない場所が壊れていないか（副作用）。この三つを、同じコードに対する複数回の出力で比べます。

準備：バグ入りの小さなゲーム

比較の土台になるコードを用意します。次の「まとあて」は、10秒の間に出る的をクリックして数を競う最小のゲームです。単独のHTMLとして保存すればブラウザで動きます。

<!doctype html>
<meta charset="utf-8">
<title>まとあて</title>
<button id="start">スタート</button>
<p>スコア: <span id="score">0</span> / 残り: <span id="time">10</span></p>
<button id="target" hidden>●</button>
<script>
let score = 0, time = 10, timer = null;
const $ = id => document.getElementById(id);
function show() {
  const t = $("target");
  t.hidden = false;
  t.style.position = "absolute";
  t.style.left = Math.floor(Math.random() * 300) + "px";
  t.style.top = (80 + Math.floor(Math.random() * 200)) + "px";
}
function tick() {
  time--;
  $("time").textContent = time;
  if (time <= 0) { clearInterval(timer); $("target").hidden = true; }
}
$("start").onclick = () => {
  time = 10;
  $("time").textContent = time;
  show();
  timer = setInterval(tick, 1000);
};
$("target").onclick = () => {
  score++;
  $("score").textContent = score;
  show();
};
</script>

このコードには、読めば分かる問題が二つあります。

一つ目が、実験で「直してほしいバグ」として扱う主バグです。一度遊んだあとに再びスタートしても、score が0に戻りません。前回の得点から加算が続きます。

二つ目は、あえて直しを依頼しない近傍の問題です。スタートボタンを連打すると setInterval が複数走ります。timer は最後の一つしか保持しないため、clearInterval で止まるのも最後の一つだけです。古いタイマーは動き続け、残り時間が速く減ったり、0を下回ったりするはずです。この点は、元のコードを自分で動かして確かめてください。

この二つ目が実験の肝です。依頼文が曖昧なほど、AIが依頼されていない問題まで直しに行くかどうかが見えやすくなります。

実験の前に、次の二つを済ませておきます。

1. 上のコードを orig.html として保存し、ブラウザで開いて二つの問題を再現します。再現できないコードでは、修正の成否を判定できません。
2. 使うAIの種類（チャット型か、ファイルを直接編集するエージェント型か）と、モデル名・設定をメモしておきます。後で条件をそろえるための記録です。

手順：三つの依頼文を同じ条件で出す

依頼文は、実験の前に文面を固定して書き出しておきます。その場の思いつきで言い換えると、条件の差が曖昧になるためです。

条件Aの依頼文

バグを直してください。（コード全体を貼る）

条件Bの依頼文

次のコードの、このバグを直してください。症状：一度遊んだあとにスタートを押し直しても、スコアが0に戻らず、前回の得点から増え続けます。再現手順：スタートを押し、的を3回クリックして10秒待ちます。もう一度スタートを押すと、スコア表示が3のままです。（コード全体を貼る）

条件Cの依頼文

条件Bの文面に続けて：期待する動作は、スタートを押した時点でスコアが0に戻り、表示も0になることです。それ以外の挙動、見た目、変数名、コメントは変更しないでください。

実施の手順は次のとおりです。

1. 条件ごとに新しい会話を開き、依頼文を貼って送ります。同じ会話の中で続けて試さないでください。前の依頼文や修正が文脈に残り、条件が混ざります。
2. 返ってきたコードを a1.html、b1.html のように、条件の記号と通し番号で保存します。
3. 各条件を5回ずつ繰り返します。一度の出力だけでは、偶然の揺れと条件の効果を区別できません。
4. 応答に付いた説明文（何をどう直したか）も、コードと一緒に保存します。説明が実際の変更と一致しているかも観察の対象になります。
5. 全部がそろってから、まとめて評価します。途中で評価を始めると、見た結果が次の依頼文の書き方に影響します。

記録の取り方

評価では、コードの差分と動作確認の両方を使います。差分は、エディタの比較機能か、ターミナルの diff -u orig.html a1.html で取れます。

記録は1回の出力につき1行、次のような表にします。

• A-1、変更行数：、触った関数：、主バグ：直った／未、近傍の別問題：直した／触らず、無関係な変更：あり（内容）／なし、動作確認1〜4：○×○×、説明と実際の一致：一致／不一致

各列の取り方を説明します。

• 変更行数：diff で追加・削除された行数の合計です。空白だけの違いが多い場合は、空白を無視するオプションで数え直し、どちらの数も控えます。
• 触った関数：show、tick、二つのクリック処理のうち、差分に含まれたものを書き出します。
• 近傍の別問題：スタート連打による二重タイマーに対処する変更が入ったかどうかです。
• 無関係な変更：変数名の変更、整形、コメントの追加、乱数の範囲の変更、見た目の変更など、依頼にも二重タイマーにも関係しない差分を、内容ごとに書きます。

動作確認は、出力したコードをブラウザで開いて、次の4項目を毎回同じ順で行います。

1. スタートを押し、的を3回クリックして10秒待ちます。スコアが3で、的が消えれば合格です。
2. もう一度スタートを押します。スコア表示が0に戻れば合格です。
3. 的を2回クリックします。スコアが2になれば合格です。
4. 遊んでいる最中にスタートを連打し、残り時間が1秒ごとに1ずつ減るかを見ます。この項目は元のコードでは合格しないはずなので、直したかどうかの目安にします。

項目1と3は、直したことで元の動作が壊れていないか（副作用）を見る確認です。項目2は主バグの確認、項目4は近傍の問題の確認にあたります。

結果の読み方と起こりやすい誤り

集まった表の読み方を、判断の形で示します。具体的な数値は、実際に行った人の手元で決まるものです。

修正範囲を見る：条件ごとに、変更行数と触った関数の数を並べます。Aの変更が、BやCより目に見えて大きかったり、回ごとのばらつきが大きかったりすれば、特定が修正範囲を絞る方向に働いたと読めます。差が小さければ、このくらいの短いコードでは、特定の有無が範囲にあまり効かないとも読めます。コードが長くなれば結果が変わる可能性があるので、その場合は同じ手順でコードを長くして再度確かめます。

副作用を見る：動作確認の項目1と3が不合格の回がどの条件に多いかを数えます。変更が小さいのに壊れた場合と、変更が大きいのに壊れなかった場合は、分けて記録してください。「範囲が広い＝副作用が多い」と決めつけず、実際に壊れた回数で判断します。

近傍の問題の扱い：二重タイマーを直した出力を、良い結果と見るか、依頼外の副作用と見るかは、実験を始める前に決めておきます。公開前のゲームなら歓迎できる変更ですが、他人のコードを預かって修正する場面では、頼まれていない変更は確認の負担になります。基準を後から決めると、結果に合わせて評価を動かしてしまいます。

説明との一致を見る：説明文に書かれていない変更が差分に含まれている回は、そのぶん確認の手間が増えます。変更行数が同じでも、説明と差分が一致するかどうかで、読む側の負担は変わります。

起こりやすい誤りは次のとおりです。

• 会話を使い回す：先に述べたとおり、前の文脈が残って条件の差を見えなくします。必ず新しい会話を使ってください。
• 5回の結果を断定に使う：回数が少ないので、出るのは統計的な結論ではなく傾向です。「Aでは必ず広く直す」といった言い切りは避け、「この設定では、A条件の5回中何回で」という範囲で書き留めます。
• 条件を途中で変える：モデルや設定、コードの貼り方（改行や全体か一部か）を条件の間で変えると、差の原因が特定できません。
• 主バグの説明が答えを含みすぎる：条件Bに「score = 0 を追加してください」と書くと、特定ではなく指示になります。比べたいのは症状の特定であって、修正方法の指定ではありません。
• 動作確認を目で済ませる：コードを読んで合格と判断せず、実際にブラウザで操作してください。AIの説明が正しそうに見えても、動かすと違うことがあります。

次の行動

まず orig.html を保存し、二つの問題を自分の目で再現するところから始めてください。次に、条件AとBだけを3回ずつ回してみれば、自分の使うAIとの相性は十分つかめます。慣れたら、自作ゲームの実際のバグで同じ表を作ってみてください。投稿前の表示確認の段階で直したい箇所が見つかったとき、依頼文をどう書くかの指針になります。