エラー文をそのまま貼る場合と、言葉で説明する場合

何を比べるのか

確かめる問いは次の二つです。

1. エラーが出る不具合で、エラー文の貼り付けは、症状の説明より「根本から直す」確率を上げるか。
2. エラーが出ない不具合で、「エラーは出ていません」という一言を含めた説明は、何も説明しない場合と比べて何を変えるか。

「直った」だけを見ると差が出にくい点に注意してください。エラー文が出る不具合には、エラーを握りつぶして見かけ上は静かにする直し方もあります。そのためこの実験では、直ったかどうかに加えて、原因の場所を直したかどうかも別に採点します。

比べる条件は、プロンプトのうち一行だけを入れ替えて作ります。コードの貼り付け方と依頼文の1行目は全条件で共通にします。

準備：わざと壊したゲームを用意する

次のHTMLを bug.html として保存し、ブラウザで開いてください。10秒間タップ数を数えるだけの最小のゲームで、不具合を二つ仕込んであります。

<!doctype html>
<meta charset="utf-8">
<title>バグ入りクリックゲーム</title>
<button id="tap">タップ</button>
<p>スコア: <span id="score">0</span></p>
<p>残り: <span id="time">10</span> 秒</p>
<p id="msg"></p>
<script>
let score = "0";
let time = 10;
const tapBtn = document.getElementById("tap");
const scoreEl = document.getElementById("score");
const timeEl = document.getElementById("time");
const msgEl = document.getElementById("message");
tapBtn.addEventListener("click", () => {
  if (time <= 0) return;
  score = score + 1;
  scoreEl.textContent = score;
});
const timer = setInterval(() => {
  time -= 1;
  timeEl.textContent = time;
  if (time === 0) {
    clearInterval(timer);
    msgEl.textContent = "終了! スコア " + score;
  }
}, 1000);
</script>

仕込んだ不具合は次のとおりです。

• 不具合1（エラーが出る）：HTML側の要素のidは msg ですが、JavaScript側は message で探しています。見つからないので msgEl は null になり、10秒後に終了表示を書き込む行でエラーになります。コンソールには「Uncaught TypeError: Cannot set properties of null (setting 'textContent')」のような一行が出ます。文言はブラウザによって異なるので、必ず自分の環境に出た文字列をそのまま使ってください。
• 不具合2（エラーが出ない）：score の初期値が数ではなく文字列の "0" なので、タップすると足し算ではなく文字の連結になります。スコアは 1, 2, 3 ではなく 01, 011, 0111 と並びます。コンソールは静かなままです。

実験の前に、この二つを自分の目で確認してください。タップして表示を見て、10秒待って、コンソールを開いて赤い一行を確かめます。この確認ができていないと、後で「直ったかどうか」を判定できません。

その他に必要なものは、使うAIのチャット画面、記録用の表計算シートまたはメモ、時計だけです。

手順：共通の骨組みに、差分を一行足す

すべての条件で、プロンプトは次の形にします。

次のHTMLゲームの不具合を直してください。

（bug.html の全文）

（ここに条件ごとの一行）

不具合1の条件

• A：エラー文のみ、差分の一行：「コンソールに次のエラーが出ます：（自分の環境のエラー文をそのまま）」
• B：言葉のみ、差分の一行：「10秒たっても「終了!」の文字が出ません。」
• C：両方、差分の一行：AとBの二行を続けて書く
• D：最小、差分の一行：「動きません。」

不具合2の条件

エラー文が存在しないので、貼る条件は作れません。代わりに、説明の詳しさを変えます。

• E：詳しい症状、差分の一行：「タップするとスコアが 1, 2, 3 ではなく 01, 011, 0111 と並びます。コンソールにエラーは出ていません。」
• F：あいまい、差分の一行：「スコアがおかしいです。」
• G：原因を推測、差分の一行：「スコアの計算が間違っている気がします。」

Gは、書き手が推測を混ぜたとき、AIがその推測に引っ張られるかを見るための条件です。実際に推測が外れていたらどうなるかを見たいときは、原因ではない箇所（たとえば「タイマーの計算が間違っている気がします」）を指す版も加えてみてください。

実施のルール

• 各条件を5回ずつ行います。不具合1は4条件で20回、不具合2は3条件で15回です。
• 1回ごとに必ず新しい会話を始めます。同じ会話を続けると、前の修正案が次の回に影響します。
• 返ってきた修正案は、そのまま bug.html に反映して試します。自分で手直ししてから試してはいけません。
• 一度で直らなかった場合に限り、追加の返信を一回だけ許します。その内容は、起きたことを一行で伝えるだけにし、何と書いたかも記録します。

記録の取り方

1回の試行につき、シートに1行を作ります。列は次のとおりです。

• 条件、内容：A〜G、記入のしかた：記号
• 回、内容：1〜5、記入のしかた：数字
• 直ったか、内容：○／×、記入のしかた：10秒待って「終了! スコア N」が出るか（不具合1）、1, 2, 3 と増えるか（不具合2）
• 根本か、内容：○／×、記入のしかた：不具合1ならidの食い違いを直したか。不具合2なら初期値または加算の型を直したか
• 変更行数、内容：数字、記入のしかた：元のコードとの差分の行数
• 余計な変更、内容：あり／なし、記入のしかた：頼んでいない箇所の書き換えや、機能の追加があるか
• ついで修正、内容：あり／なし、記入のしかた：伝えていない側の不具合まで直したか
• 追加返信、内容：0／1、記入のしかた：一度で直らず返信した場合は1

「根本か」の判定には注意が必要です。たとえば不具合1で、if (msgEl) のような確認を足してエラーを消す直し方は、コンソールは静かになりますが終了表示は出ません。この場合は「直ったか」が×、「根本か」も×として記録してください。逆に、idを合わせる代わりにJavaScript側を "msg" に変えるのも、HTML側を message に変えるのも、どちらも根本修正です。

差分の行数は、エディタの比較機能やテキスト比較ツールで数えると正確です。目視で数えるときは、5回分を通して同じ基準で数えてください。

結果の読み方

5回ずつの小さな実験なので、1回の差で結論を出さず、条件ごとの「○の数」を並べて傾向として読みます。判断の目安を、あらかじめ決めておきます。

不具合1（A〜D）

• AとBで「直ったか」の数が同じでも、「根本か」の数に差があれば、伝え方は修正の質に効いていると読めます。どちらが上かは、実際の数字で判断します。
• Aで「余計な変更」や「変更行数」が目立って多い場合は、エラー文が示す行（終了表示を書く行）の周辺だけを直そうとしている可能性があります。エラー文の行番号と、原因のid定義の行が離れていることが、そこにどう関わるかを見てください。
• Bで根本修正が多い場合は、「終了の文字が出ない」という症状から、AIがコード全体を読んで原因を探していると考えられます。
• CがAとBのどちらよりも安定して良いなら、両方を書く手間に見合う価値があります。差がなければ、手間を省いてよい根拠になります。
• Dが他と近い成績なら、このコードは小さすぎて伝え方の差が出にくいと読めます。その場合は後述の発展を試してください。

不具合2（E〜G）

• EとFの差が、症状を具体的に書く価値の目安です。数字の例（01, 011）がAIに原因の見当を付けさせているかを、返ってきた説明文から確かめてください。
• Gで「根本か」が下がるなら、推測の混入が誘導になっています。推測を外した版も試した場合は、AIが推測を疑って別の原因を探したか、推測どおりに直したかを見ます。

ついで修正

片方の不具合だけを伝えたのに、もう一方まで直る頻度も読み取れます。「ついで修正」が多ければ、AIは伝えた内容よりもコード全体を点検しています。その場合、伝え方による差は小さくなりがちです。

起こりやすい誤り

• 会話を引き継いでしまう：同じ会話の中で条件を切り替えると、前に直したコードが残り、比較になりません。1回ごとに新しい会話にします。
• エラー文を整形してしまう：貼る前に余計な部分を削ったり、日本語に訳したりすると、条件Aの中身が変わります。ブラウザに出た文字列をそのまま貼ります。エラーが複数行にわたる場合の扱いも、全回で揃えてください。
• 説明に答えを混ぜる：条件Bに「idが違うかも」と書けば、説明ではなくヒントになります。症状に徹するのが条件Bです。
• 採点基準が回ごとに揺れる：「根本か」の線引きは、実験を始める前に紙に書いて固定します。後から基準を変えると、数字の意味が変わります。
• AIの出力が毎回違うことを忘れる：同じプロンプトでも結果は変わります。1回の成功や失敗に意味を持たせず、5回の並びで見ます。
• 自分の環境の差を無視する：ブラウザの種類やバージョンでエラー文が変わります。ブラウザを途中で変えないでください。

発展：コードを大きくする

条件の差が出なかった場合は、コードが小さすぎるのかもしれません。自分が作りかけのゲームや、機能を足して長くしたバージョンで同じ実験をします。エラーの出る行と原因の行が離れるほど、条件Aと条件Bの違いが見えやすくなるはずです。ただし、これは予想であって確かめた結果ではありません。実験で確かめてください。

次の行動

まず bug.html を保存して、不具合1と2の症状を自分の目で確かめてください。次に、条件AとBだけ、それぞれ1回ずつ新しい会話で試し、返ってきた修正の中身（どの行を直したか）を見比べます。差が気になったら、記録表を作って5回ずつに広げてください。自作ゲームの投稿前に表示を確認する段階でも、同じ観点で不具合の伝え方を見直せます。