ゲームのバグをAIに直してもらうプロンプト：エラー文の渡し方

なぜエラー文の渡し方が結果を左右するのか

AIへの質問を「人に相談するとき」に置き換えると整理しやすくなります。「動きません」とだけ言われた人は、何も確認せずに答えを出せません。一方「ブラウザのコンソールに〇〇というエラーが出て、△△のボタンを押したときだけ起きます」と伝えられれば、問題の範囲が一気に絞れます。

AIも同じです。モデルは確率的に「最もありそうな回答」を生成するため、文脈が薄いと一般論や無関係な候補を返しやすくなります。エラー文・再現条件・関連コードの三点セットを渡すと、モデルが参照できる文脈が具体的になり、的外れな推測が減ります。

もう一つの理由はトークン（入力の長さ）の使い方です。コード全体を貼ると、関係のない部分にモデルの注意が分散します。問題に直接関係する箇所だけを渡すほうが、短い入力で精度の高い回答が得られます。

渡すべき四つの要素

バグ修正の依頼に必要な情報は四つです。順番も重要で、上から順に書くと読みやすくなります。

1. 何をしようとしていたか（目的の一文）

「〇〇ボタンを押したらスコアが1増える処理を実装しています」のように、そのコードが達成しようとしている動作を一文で書きます。AIはコードの意図を知らないため、ここを省くと「意図通りに動いているが要件が違う」ケースと「バグで壊れている」ケースを区別できません。

2. エラー文の全文（省略しない）

ブラウザの開発者ツール（DevTools）のコンソールに表示されるエラーは、必ず全文をコピーします。「TypeError: Cannot read properties of undefined」のような種別と、その後に続く「at 関数名 (ファイル名:行番号)」の行も含めてください。行番号があると、モデルは問題の発生箇所を特定できます。

エラーが複数行にわたる場合も省略しないことが原則です。スタックトレース（エラーが起きるまでの呼び出し経路）は、一見冗長に見えても問題の連鎖を示しているため、切り捨てると診断精度が落ちます。

エラーが出ていない「動作がおかしい」系のバグでは、期待する動作と実際の動作をそれぞれ一文で書きます（例：「スコアが2増えるはずが4増える」）。

3. 再現手順（何をしたときに起きるか）

「このゲームでバグが出ます」ではなく「ページ読み込み直後に〇〇ボタンを2回押すと発生します」のように、操作手順を具体的に書きます。常に起きるのか、特定の条件のときだけなのかも添えてください。

再現性のないバグ（たまにしか起きない）は、その旨を正直に伝えます。AIは「たまにしか起きないなら非同期処理の競合かもしれない」といった方向で候補を絞れます。

4. 関連コードの抜粋

エラーが発生している関数、またはエラー文に行番号が示されているブロックを貼ります。関係のない関数や変数宣言は省いてかまいません。

コードはかならずコードブロック（```で囲む形式）で貼ります。多くのチャットUIはこの形式でシンタックスを保持するため、モデルが構造を正確に読みやすくなります。コードが長い場合は「関数全体」ではなく「エラーが起きている関数と、それを呼び出している箇所」の二か所に絞ると効果的です。

実際のプロンプトの型

四つの要素をどう並べるか、テンプレートとして使える型を示します。

【目的】
スコアカウンターをインクリメントするボタンを実装しています。

【エラー文】
Uncaught TypeError: Cannot set properties of null (setting 'textContent')
    at updateScore (game.js:34)
    at HTMLButtonElement.<anonymous> (game.js:12)

【再現手順】
ページを読み込んでから「+1」ボタンをクリックすると発生します。

【関連コード】

function updateScore(newScore) {document.getElementById('score-display').textContent = newScore;}

document.getElementById('increment-btn').addEventListener('click', () => {score++;updateScore(score);});

このエラーの原因と修正方法を教えてください。

この型のポイントは「依頼の文を最後に置く」ことです。文脈を先に積み上げてから「何をしてほしいか」で締めると、モデルが情報全体を参照した上で回答を生成しやすくなります。

回答が的外れだったときの再質問の仕方

一度目の回答がずれていた場合、「違います」とだけ返すのは最もコストの高い返し方です。何がどう違ったかを一文で補足し、追加の文脈を渡します。

よくあるパターンと対処を整理すると次のようになります。

• 修正後も同じエラーが出る：修正したコードをそのまま貼り直し「同じエラーが再現します」と伝える。AIは前の会話を覚えているため、差分から問題を再診断できます。
• 別のエラーが出た：新しいエラー文を全文貼る。「修正後に新しいエラーが出ました」と一言添えます。
• 回答がコードを返さず説明だけだった：「修正後のコードを全文で返してください」と明示します。説明重視の回答を返すモデルは、明示的に求めないとコードを省くことがあります。
• 外部ライブラリの関数についての誤解がある：使っているライブラリ名とバージョンを追記します。同名の関数が複数のライブラリに存在するケースでは、特定が重要です。

渡してはいけない情報・注意点

ゲーム全体のコードを丸ごと貼るのは、多くの場合逆効果です。モデルの注意が分散するだけでなく、チャットUIのトークン上限に引っかかって途中で切れることもあります。また、未公開ゲームの全コードを商用APIのチャットに貼ることには、利用規約上の考慮が必要な場合があります。個人情報や認証キーが含まれていないかも確認してから貼ってください。

エラーのスクリーンショット画像だけを渡して「直してください」とするのも非効率です。画像からテキストを読み取るモデルもありますが、行番号や長いスタックトレースは画像では正確に伝わりにくく、テキストで貼る方が確実です。

次の行動

まずは直近で詰まっているバグのエラー文をコンソールから全文コピーし、この記事の四要素テンプレートに当てはめてAIに渡してみてください。うまく動くようになったゲームは、アソバースにHTMLまたはZIPで投稿して公開できます。修正のサイクルを短くするほど、完成までの時間も縮まります。