AIにエラー調査を丸投げするとどこまで原因を特定できるのか検証してみた
はじめに
開発中にエラーが出たとき、ChatGPTなどの生成AIにエラーメッセージをそのまま貼り付けて、
「このエラーの原因を教えて」
と聞いたことがある人も多いと思います。
自分もエラーで詰まったときに生成AIへ質問することがありますが、エラーメッセージだけを渡すと、
- 原因の候補が大量に出てくる
- 今回の問題とは関係なさそうな修正方法まで提案される
- 結局、何度か追加情報を渡すことになる
といったことがよくあります。
では、最初からある程度情報を渡しておけば、どのくらい正確に原因を特定してくれるのでしょうか。
今回は、生成AIに渡す情報を少しずつ増やしながら、エラー原因の特定精度がどう変わるのかを試してみました。
今回検証するエラー
今回は、JavaScriptでよく見かける以下のエラーを使います。
TypeError: Cannot read properties of null (reading 'value')
検証用のコードはこちらです。
<form id="userForm">
<input id="userName" type="text" />
<button type="submit">送信</button>
</form>
<script>
const form = document.getElementById("userForm");
form.addEventListener("submit", (event) => {
event.preventDefault();
const email = document.getElementById("email").value;
console.log(email);
});
</script>
HTML側にあるinputのIDはuserNameです。
一方でJavaScript側では、
document.getElementById("email")
として、存在しないemailというIDの要素を取得しようとしています。
getElementById("email")の結果はnullになるため、そのまま.valueを参照すると、
null.value
のような状態になり、
TypeError: Cannot read properties of null (reading 'value')
が発生します。
今回はこの原因を、生成AIがどの段階で正確に特定できるか確認します。
検証方法
生成AIに渡す情報を、以下の4パターンに分けました。
パターン1
エラーメッセージのみ
TypeError: Cannot read properties of null (reading 'value')
このエラーの原因を教えてください。
パターン2
エラーメッセージ + 該当コード
パターン3
エラーメッセージ + コード + 実行環境
パターン4
エラーメッセージ + コード + 実行環境 + 本来やりたいこと
それぞれ、
- 原因を特定できたか
- 関係のない推測がどの程度あったか
- 修正方法まで提示できたか
- 追加のやり取りが必要だったか
という点を見ていきます。
パターン1:エラーメッセージだけ渡す
まずは、エラーメッセージだけを渡してみます。
TypeError: Cannot read properties of null (reading 'value')
このエラーの原因を教えてください。
生成AIからは、おおむね以下のような回答が返ってきました。
このエラーは、nullになっているオブジェクトから
valueプロパティを取得しようとした場合に発生します。
例えば以下のようなコードです。
document.getElementById("email").value
対象の要素が存在しない場合、
getElementById()はnullを返します。
IDが正しいか、DOMが読み込まれた後に処理を実行しているか確認してください。
結果
エラーがどういう意味なのかは、問題なく説明できています。
ただしコードを渡していないので、
- IDの指定が間違っている
- DOMの読み込み前にJavaScriptが実行されている
- 条件によって対象の要素が生成されていない
- JavaScript実行時にはすでに要素が削除されている
など、いくつかの候補が挙げられました。
今回の原因である、
HTML側にemailというIDの要素が存在しない
というところまでは、この情報だけでは特定できません。
評価
| 項目 | 評価 |
|---|---|
| エラーの意味 | ◎ |
| 原因特定 | △ |
| 修正方法 | △ |
| 不要な推測 | 多い |
| 追加情報 | 必要 |
当然といえば当然ですが、エラーメッセージだけでは、原因の候補を出すところまではできても、どれが本当の原因なのかまでは判断できないようです。
パターン2:エラー + コードを渡す
次はコードも一緒に渡します。
以下のエラーが発生しています。
TypeError: Cannot read properties of null (reading 'value')
コードはこちらです。
<form id="userForm">
<input id="userName" type="text" />
<button type="submit">送信</button>
</form>
<script>
const form = document.getElementById("userForm");
form.addEventListener("submit", (event) => {
event.preventDefault();
const email = document.getElementById("email").value;
console.log(email);
});
</script>
原因を教えてください。
今度はかなり具体的な回答になりました。
原因は以下の部分です。
document.getElementById("email").value
HTMLにはid="email"の要素が存在しません。
getElementById("email")はnullを返すため、
その後の.value参照でエラーになっています。
さらに、
<input id="email" type="text" />
に変更する方法や、
document.getElementById("userName").value
とJavaScript側を修正する方法も提示されました。
結果
コードまで渡すと、今回の原因はほぼ一発で特定できました。
評価
| 項目 | 評価 |
|---|---|
| エラーの意味 | ◎ |
| 原因特定 | ◎ |
| 修正方法 | ◎ |
| 不要な推測 | 少ない |
| 追加情報 | ほぼ不要 |
今回のように原因がコード上にはっきり出ているエラーであれば、エラーメッセージと関連コードを一緒に渡すだけでも、かなり精度が上がることが分かります。
パターン3:実行環境も追加する
次は、実行環境も伝えてみます。
ブラウザ上でJavaScriptを実行しています。
Chromeで以下のエラーが発生しています。
TypeError: Cannot read properties of null (reading 'value')
コードはこちらです。
...
今回については、パターン2と回答内容に大きな違いはありませんでした。
原因がHTMLとJavaScriptを見るだけで判断できるため、Chromeで動かしているという情報は、ほとんど必要なかったためです。
ただ、実際の開発では環境情報が重要になるケースもあります。
例えば、
Node.js 20
TypeScript
React
Next.js 15
Windows 11
Docker
といった情報です。
同じようなエラーでも、
- ブラウザなのかNode.jsなのか
- Reactなのか素のJavaScriptなのか
- 使用しているライブラリのバージョンはいくつか
によって、見るべきポイントが変わることがあります。
今回のような単純なエラーでは差が出ませんでしたが、環境依存のトラブルを調べてもらう場合は、実行環境も最初から伝えた方がよさそうです。
パターン4:「本来やりたいこと」まで伝える
最後に、エラーの情報だけではなく「何をしたいのか」まで伝えてみます。
フォーム送信時に入力されたユーザー名を取得したいです。
Chromeで実行しています。
以下のエラーが発生しています。
TypeError: Cannot read properties of null (reading 'value')
コードはこちらです。
<form id="userForm">
<input id="userName" type="text" />
<button type="submit">送信</button>
</form>
<script>
const form = document.getElementById("userForm");
form.addEventListener("submit", (event) => {
event.preventDefault();
const email = document.getElementById("email").value;
console.log(email);
});
</script>
この場合は、
const userName = document.getElementById("userName").value;
のように、単にエラーを消すだけではなく、「ユーザー名を取得したい」という目的に合わせた修正が提案されました。
結果
評価
| 項目 | 評価 |
|---|---|
| エラーの意味 | ◎ |
| 原因特定 | ◎ |
| 修正方法 | ◎ |
| 目的に合った修正 | ◎ |
| 不要な推測 | かなり少ない |
| 追加情報 | 不要 |
「エラーを直してください」だけではなく、
何をしようとしているのか
まで書いておくことで、回答の方向性もかなり合わせやすくなります。
検証結果
今回の結果をまとめると、以下のようになりました。
| AIに渡した情報 | 原因特定 | 修正案 | 不要な推測 |
|---|---|---|---|
| エラーのみ | △ | △ | 多い |
| エラー + コード | ◎ | ◎ | 少ない |
| + 実行環境 | ◎ | ◎ | 少ない |
| + やりたいこと | ◎ | ◎ | 非常に少ない |
エラーメッセージだけでも、「このエラーが何を意味しているのか」までは説明してもらえました。
ただ、実際にどこが悪いのかを特定するには、やはりコードが必要です。
さらに「本来何をしたいのか」まで伝えることで、単にエラーを消すだけではなく、目的に合った修正案を出してもらいやすくなりました。
AIにエラー調査をお願いするときに渡した方がいい情報
今回試してみて、エラー調査をお願いするときは、次の4つを渡しておくとよさそうだと感じました。
1. エラーメッセージ
まずはエラー内容を省略せずに渡します。
TypeError: Cannot read properties of null (reading 'value')
スタックトレースが出ている場合は、それも一緒に貼った方がよいです。
2. エラー周辺のコード
エラーが出ている1行だけではなく、その前後もある程度含めます。
例えば、
const email = document.getElementById("email").value;
だけを渡すより、
form.addEventListener("submit", (event) => {
event.preventDefault();
const email = document.getElementById("email").value;
console.log(email);
});
くらいまで見せた方が、どういうタイミングで実行されている処理なのかが分かります。
とはいえ、プロジェクト全体のコードをそのまま貼る必要はなく、まずはエラーに関係ありそうな範囲だけで十分だと思います。
3. 実行環境
環境依存の可能性がありそうな場合は、使用している環境も伝えます。
OS: Windows 11
Node.js: 20.x
Framework: Express
Language: TypeScript
Browser: Chrome
特にフレームワークやライブラリを使っている場合は、バージョンまで書いておくと原因を絞り込みやすくなります。
4. 本来やりたいこと
今回試してみて、一番差が出たと感じたのがこの情報です。
例えば、
このエラーを直してください
だけではなく、
フォームから入力されたユーザー名を取得して、
APIへ送信したいです。
現在、以下のエラーが発生しています。
と書きます。
「どこを直せばエラーが消えるのか」だけではなく、「何を実現したいのか」まで分かるため、見当違いな修正を提案されにくくなります。
個人的におすすめの質問テンプレート
実際にエラー調査をお願いするなら、以下くらいの情報をまとめておくと使いやすいと思います。
以下のエラーについて原因を調査してください。
## やりたいこと
ユーザー登録フォームから入力値を取得し、
APIへPOSTしたいです。
## エラー
TypeError: Cannot read properties of null (reading 'value')
## 実行環境
- Windows 11
- Chrome
- JavaScript
## 該当コード
(コード)
## 確認してほしいこと
1. エラーが発生している原因
2. 修正方法
3. なぜその修正で直るのか
4. 他に同じ問題が起きそうな箇所
「原因を教えて」だけでも回答は返ってきますが、何を確認してほしいのかまで書いておくと、欲しい情報をまとめて返してもらいやすくなります。
生成AIの回答をそのまま信用していいのか
今回のような単純なエラーでは、生成AIはかなり正確に原因を特定できました。
ただし、実際の開発で出てくるエラーは、もう少し複雑です。
例えば、
500 Internal Server Error
だけでは、
- API側の実装
- DB接続
- 環境変数
- 外部API
- 権限
- リクエストパラメータ
- ライブラリ
- ネットワーク
など、いくらでも原因が考えられます。
この状態でAIに聞けば、それっぽい原因候補は出してくれます。
ただし、それが実際の原因とは限りません。
情報が少ない状態では、どうしても「与えられた情報から可能性の高そうなものを推測する」回答になります。
そのため、
AIがそう言っているから正しい
ではなく、
AIが挙げた原因が本当に当てはまるか、自分の環境で確認する
ことは必要です。
個人的には、生成AIは「エラーを勝手に直してくれるもの」というより、調査のスタート地点を素早く作るための道具として使うのが便利だと感じています。
例えば、
「まずどこを見るべきか」
「このログから何が分かるか」
「次に何を確認すれば原因を切り分けられるか」
といった部分はかなり頼れます。
まとめ
今回は、生成AIに渡す情報を少しずつ増やしながら、エラー調査の回答がどう変わるのか試してみました。
結果として、エラーメッセージだけでも一般的な原因は説明してもらえましたが、実際の原因を特定するにはコードが必要でした。
さらに、
エラー
+ コード
+ 実行環境
+ 本来やりたいこと
まで伝えると、原因の特定だけでなく、目的に合った修正方法まで提案してもらいやすくなりました。
生成AIにエラー調査をお願いするときは、エラーを貼って、
これ何?
と聞くだけではなく、
何をしようとしていて
どの環境で
どのコードを動かした結果
何が起きたのか
をセットで伝えるのがよさそうです。
もちろん、AIの回答が必ず正しいわけではありません。
ただ、自分だけで一から原因候補を洗い出すよりも、調査の方向性を決めるまでの時間はかなり短縮できます。
全部をAIに丸投げするというより、「一緒に原因を切り分ける相手」として使う。
今のところ、このくらいの距離感がエラー調査では一番使いやすいのではないかと思います。