エラーが出たとき、メッセージをまるごとコピーして、生成AIに「直して」とだけ送る。たぶん、いちばん最初にやる頼み方だと思います。そして、返ってきた答えがなんだかぼんやりしていて、試しても直らない。そんな経験のある人に向けて書いています。
直らない原因は、AIの賢さ不足ではないことが多いです。たいていは、AIに渡している情報が足りていません。エラーメッセージという結果だけを見せて、そこに至るまでの事情を伝えていないと、AIは前後を想像で埋めるしかなく、その想像がずれると的外れな修正が返ってきます。逆に言えば、何を一緒に渡すかを変えるだけで、返ってくる答えはかなり変わります。
この記事では、初心者がまず覚えておくと直答率の上がる「型」と、そのままコピペして空欄を埋めれば使える例文を並べます。後半では、エラーの種類ごとの渡し方、直らなかったときの頼み直し方、大量のログの渡し方まで広げます。
対象は生成AIをデバッグに使い始めた人です。ここで挙げるテンプレは特定のツール専用ではなく、ChatGPT・Claude・Gemini など主要なモデルで共通して使えます。コードや環境の具体例は、書き方を示すためのもので、自分の状況に置き換えて読んでください。
先に要点：一緒に渡すと答えが変わる6つ
先に要点だけ。AIにエラー修正を頼むとき、一緒に渡すと答えが変わる情報は、次の6つです。
| 渡すもの | なぜ要るか |
|---|---|
| エラーメッセージの全文 | 最終行だけだと、原因の場所までは分からない |
| やろうとしていたこと | 何が「正しい動作」かをAIが知らない |
| 関連するコード | 推測ではなく、実物を見て直せる |
| 実行環境 | 言語やバージョンで、正しい直し方が変わる |
| すでに試したこと | 同じ失敗を、もう一度提案されずに済む |
| してほしいこと | 修正だけか、理由の説明も要るか |
このあと、ひとつずつ、弱い頼み方と強い頼み方を並べて見ていきます。最後に、返ってきた修正をそのまま貼り戻す前の確かめ方も置きます。
貼る前に、消しておくもの
具体的な頼み方に入る前に、ひとつだけ。エラーやコードをAIに貼るときは、貼ってはいけないものを先に消します。これは習慣にしておくと安全です。
消す対象は、おもに次のものです。
- API キーやトークン、パスワード、データベースの接続情報
- 自分や他人の個人情報（メールアドレス、氏名、電話番号など）
- 社内だけの URL や、公開していないドメイン
エラーメッセージやスタックトレースには、こうした情報が紛れていることがあります。とくに設定ファイルや環境変数まわりのエラーは要注意です。貼る前に、鍵やパスワードは xxxxx などのダミーに置き換える。これだけで、うっかりの流出をかなり防げます。置き換えたことは、AIに一言伝えておくと、AIもそこを実在の値と勘違いせずに済みます。
エラーメッセージは、省略せず全文を渡す
よくあるのは、スタックトレースの最終行だけを貼る頼み方です。
弱い例:
TypeError が出ました。直してください。
これだと、AIは「どの TypeError か」も「どこで起きたか」も分かりません。エラーの種類だけでは、原因の候補が多すぎるからです。
強くするには、メッセージを途中で切らず、出力された全文をそのまま貼ります。スタックトレースは、いちばん下の行よりも、その上に続く「どのファイルの何行目から呼ばれたか」の連なりのほうに原因が出ていることが多いので、上から全部渡すほうが当たります。
次のエラーが出ました。原因と直し方を教えてください。
【エラー全文】
（ここに、エラーメッセージを最初の行から最後まで貼る）
「何をしたかったか」を一行足す
AIはコードの字面は読めますが、あなたが何を作ろうとしていたかは知りません。同じエラーでも、意図が分かると直し方が変わります。
たとえば「ユーザー一覧を取得して表示したい」という意図が伝わると、AIは「そもそも取得に失敗している」のか「取得はできていて、表示のところでこけている」のか、当たりを付けて読みます。意図がないと、エラーの起きた一行だけを近視眼的に直して、目的とずれた修正を返してくることがあります。
やりたいこと: （例: フォーム送信後に、入力内容を一覧へ追加して表示したい）
出ているエラー: （全文を貼る）
コードは「最小限の実物」を渡す
関連するコードを渡すと、AIは推測ではなく実物を見て直せます。ただし、ファイルを丸ごと貼る必要はありません。エラーに関係する部分と、その前後だけで足ります。
長すぎるコードは、かえってAIの注意を散らします。エラーの行を中心に、その呼び出し元と、関係する変数の定義くらいまでに絞ると、的の絞られた答えが返ってきます。どこを渡せばいいか分からないときは、エラーに出ているファイル名と行番号の周辺、と考えると選びやすいです。
実行環境を書く。これだけで誤答が減る
言語やそのバージョン、フレームワーク、動かしている場所によって、正しい直し方は変わります。古い書き方を提案されたり、自分の環境では動かない解を渡されたりするのは、たいていここが抜けているからです。
渡し方は、箇条書きでかまいません。たとえば、言語と版（Python 3.12）、フレームワーク（Django 5.1）、動かしている場所（ローカルの開発サーバー、あるいは本番のレンタルサーバー）を、一行ずつ。WordPress プラグインのことを聞くなら、WordPress と PHP のバージョンも添えておくと、返ってくる答えが自分の足元に合ってきます。
「すでに試したこと」を伝えると、堂々巡りが止まる
これは見落とされがちですが、よく効きます。すでに試して駄目だった方法を書いておかないと、AIは真っ先にその方法を提案してきます。あなたはもう試したのに、また同じところへ戻される。この堂々巡りが、いちばん時間を溶かします。
すでに試したこと:
- （例: キャッシュを消して再読み込みした → 変化なし）
- （例: 変数名のタイポを確認した → 問題なし）
一行でいいので、試したことと、その結果をセットで書くのがよく効きます。結果まで書くと、AIはその先から考え始めてくれます。
「してほしいこと」を指定する
最後に、何を返してほしいかを決めて伝えます。ここを省くと、AIは「とりあえず直したコード」だけを返しがちで、なぜそれで直るのかが分からないまま貼り戻すことになります。初心者のうちは、修正と一緒に理由も短くもらうほうが、次に似たエラーが出たとき自分で直せるようになります。
理由も知りたいとき:
直したコードと、なぜそのエラーが起きていたのかを、2〜3行で説明してください。
候補を先に知って、自分で選びたいとき:
考えられる原因が複数あるなら、可能性の高い順に挙げて、それぞれの確かめ方を教えてください。実際に直すのは、そのあとで相談します。
エラーの種類で、足す情報を変える
6つを全部そろえるのが基本ですが、エラーの種類によって、とくに効く情報が変わります。種類ごとに、何を厚めに渡すといいかを並べます。
| エラーの種類 | とくに効く情報 |
|---|---|
| 構文エラー（書き方の誤り） | エラーの行と、その前後数行。これだけでほぼ足りる |
| 実行時エラー（実行中に止まる） | 変数に何が入っているはずか、と、実際に入っていた値 |
| 論理バグ（動くが結果が変） | 期待した結果と、実際の結果。入力と出力の具体例 |
| 環境・依存のエラー | 環境とバージョン、インストールの手順 |
とくに分かりにくいのが、3つ目の論理バグです。エラーが出ないので、AIは「どこがおかしいのか」をそもそも知りません。ここでは、こう渡します。
動いてはいるのですが、結果が想定と違います。
入力: （実際に入れた値）
期待した結果: （こうなってほしかった）
実際の結果: （こうなった）
原因として考えられるところを挙げてください。
環境まわりのエラー（モジュールが見つからない、バージョンが合わない、など）は、エラー文より環境のほうが主役になります。言語とバージョン、使っているパッケージ管理ツール、インストール時に打ったコマンドまで添えると、解像度が一気に上がります。
全部入りの型。これをコピペして埋める
ここまでをひとつにまとめた型です。これをコピーして、空欄を自分の状況で埋めれば、そのまま送れます。
次のエラーを直したいです。
やりたいこと:
（何を作ろうとしていたか）
実行環境:
（言語とバージョン / フレームワーク / 動かしている場所）
エラー全文:
（最初の行から最後まで、省略せずに貼る）
関連するコード:
（エラーの前後だけ。長い場合は、関係する部分に絞る）
すでに試したこと:
（試して駄目だった方法と、その結果）
してほしいこと:
（修正だけか、理由の説明も要るか。原因の候補を先に知りたいか）
弱い頼み方と強い頼み方を、実例で見比べる
型の効き目は、並べて見るといちばん分かります。よくある実行時エラーを例にします。
弱い頼み方は、こうです。
TypeError: 'NoneType' object is not subscriptable が出ました。直して。
この一行だと、AIは「どこかで None になっている変数を、添字でアクセスしている」という一般論しか返せません。あなたのコードのどこが None になっているかは見えないので、ありそうな原因をいくつか並べて終わりがちです。
同じ状況を、型に沿って渡すと、こうなります。
次のエラーを直したいです。
やりたいこと:
APIから取得したユーザー情報の、名前を画面に表示したい
実行環境:
Python 3.12 / requests ライブラリ
エラー全文:
Traceback (most recent call last):
File "app.py", line 14, in show_name
name = data["name"]
TypeError: 'NoneType' object is not subscriptable
関連するコード:
res = requests.get(url)
data = res.json()
name = data["name"] # ここの14行目で落ちる
すでに試したこと:
print(data) を入れたら、None と表示された
してほしいこと:
原因と、直したコードを。理由も2〜3行で。
ここまで渡すと、AIは「data が None なのは、res.json() の前にレスポンスが空、または失敗している可能性が高い」と、原因を一点に絞れます。返ってくるのも、ステータスコードの確認や、None だったときの分岐を足した、具体的な修正になります。違いを生んだのは、AIの賢さではなく、print(data) が None だったという一行でした。
弱くなる頼み方と、その直し方
逆に、答えを弱くしてしまう頼み方もあります。当てはまっていないか、ざっと見てみてください。
| 弱くなる頼み方 | なぜ弱いか | こう変える |
|---|---|---|
| エラーを自分の言葉で要約して貼る | 原文にあった手がかりが消える | 全文をそのまま貼る |
| 「動きません」だけ送る | 何がどう動かないかが伝わらない | 症状とエラー全文を書く |
| 最終行だけ貼る | 原因の場所が分からない | 上から全文を貼る |
| 「全部書き直して」と頼む | 関係ない所まで変わり、新しいバグが増える | 直してほしい範囲を絞る |
| コードを渡さず直してと頼む | AIが実物を見られず、推測で答える | 関連するコードを添える |
とくに「全部書き直して」は、つい頼みたくなりますが、危ないです。広く投げると、AIは動いていた部分まで作り直してしまい、別の不具合を増やすことがあります。直す範囲は、できるだけ狭く指定するほうが安全です。
大量のログやスタックトレースは、どう渡すか
ログが何百行も出ると、全部は貼れません。そういうときは、削り方にちょっとした順番があります。
残すのは、まずいちばん上、つまり最初に壊れた所です。それから、自分が書いたファイルの名前が出ている行。この二つに原因が出ていることが多いです。同じ警告が何度も繰り返されているなら、1つだけ残して、あとは省きます。削った所には「（中略）」と書いて、削ったことをAIに伝えておきます。黙って削ると、AIは「ここで終わっている」と誤解することがあるからです。
どこを残せばいいか自分でも分からないほど大量なら、先に聞いてしまう手もあります。
長いログが出ています。原因を絞るには、このうちどの部分を見せればいいですか。
まず全体の最初の30行だけ貼ります。
返ってきた答えは、貼り戻す前にひとつ確かめる
型を使うと、答えの精度は上がります。それでも、返ってきた修正をそのまま貼り戻す前に、ひとつだけ確かめる習慣をつけると安全です。
確かめるのは、「この修正は、貼ったエラーそのものに対応しているか」です。AIは、頼まれたついでに別の場所まで書き換えたり、こちらが渡していない前提を勝手に置いて直したりすることがあります。修正後のコードだけを受け取ると、それに気づけません。
不安なときは、こう聞き返します。
その修正で、さきほどのエラーのどの部分が解消されますか。新しく置いた前提や、私が渡していない変更があれば、それも教えてください。
これで、修正の理由と、勝手に足された変更があぶり出せます。理由が筋の通ったものなら、貼り戻す。ずれているなら、もう一度、足りなかった状況を渡して頼み直す。この一往復を挟むだけで、AIの修正を鵜呑みにして別のバグを増やしてしまう、という事態をかなり防げます。
直らなかったときの、次の頼み方
一回で直らないことは、ふつうにあります。そのときに「直りませんでした」とだけ返すと、また堂々巡りになります。次の頼み方にも、型があります。
別のエラーに変わったとき:
その修正を入れたら、エラーが変わりました。新しい全文はこれです。
（新しいエラー全文を貼る）
症状が変わらないとき:
直りませんでした。症状は変わらず、（こういう状態）のままです。
さきほどとは別の原因も考えられますか。可能性を、高い順に挙げてください。
原因がまったく絞れないとき:
原因が特定できないので、まず切り分けたいです。
どこに print やログを入れれば、原因を絞り込めますか。確かめる手順を教えてください。
エラーが変わったら前進、というのは覚えておくと気が楽です。同じ場所で止まらず、次のエラーに進んだなら、一段は直っています。
答えの説明が分からないときの、聞き返し方
AIの説明に知らない用語が出てきて、そこで止まることもあります。分からないまま貼り戻すより、聞き返したほうが、結局は早いです。
用語が分からないとき:
その説明の中の「（用語）」が分かりません。プログラミング初心者向けに、たとえ話で説明してください。
直したコードの中身が分からないとき:
直してもらったコードを、1行ずつ、何をしているか日本語のコメントを付けて説明してください。
聞き返しは、恥ずかしいことではありません。むしろ、ここで一度立ち止まって理解しておくと、次に同じエラーが出たとき、自分で直せるようになります。
直ったあとに、もうひとつ聞いておく
エラーが直ったら、それで終わりにせず、もう一問だけ足すと得をします。
なぜこのエラーが起きたのか、今後同じものを避けるには何に気をつければいいか、短く教えてください。
これを聞いておくと、その場の修正が、次に活きる知識に変わります。余裕があれば、確認用の簡単なテストの書き方まで聞いておくと、直ったつもりで直っていなかった、という取りこぼしも減ります。
おわりに
エラーが出たとき、「直して」の一言で済ませたくなる気持ちは分かります。私もそうです。けれど、AIに渡す情報をほんの少し足すだけで、返ってくる答えは驚くほど変わります。次にエラーで詰まったら、まずこの型の空欄を埋めるところから始めてみてください。たぶん、いつもより一回少ないやり取りで、抜け出せるはずです。