Claude Codeに頼むだけで、プログラムのエラー修正はどこまでできる?

3つのエラーで 修正力を徹底検証

Claude Codeでコードを書いていると、必ずエラーに遭遇します。エラーメッセージをコピペして「これ直して」と頼むだけで直ることもあれば、何回やり取りしても解決しないこともあります。その違いは何なのか——今回は、シンタックスエラー、型エラー・モジュール不足、権限エラー・環境依存の3パターンを順番に試して、それぞれ「頼むだけでどこまで直るのか」を確かめました。読み終わる頃には、自分が出会ったエラーが「頼むだけで直りそうか」「人の確認が必要か」を判断できるようになります。

目次

この記事で確かめること

「Claude Codeにエラー修正を頼むだけで、どこまで直るのか?」——これを3種類のエラーで検証します。

シンタックスエラー(書き方のミス)、型エラーやモジュール不足(組み合わせの問題)、権限エラーや環境依存のエラー(Windows環境特有の壁)。この3つを順番に試していきます。

環境はWindows 11前提です。MacやLinuxの手順は含めません。

前提:検証環境と準備

検証に使う環境はシンプルです。

  • Windows 11
  • Claude Codeがインストール済みで使える状態
  • 検証用の小さなPythonスクリプト(架空のプロジェクト)

Claude Codeのインストールがまだの場合は、このブログの「はじめ方」記事を先に読んでください。

検証用プロジェクトは、ユーザーの名前と年齢を受け取ってメッセージを出力するだけのシンプルなPythonスクリプトを用意しました。これにわざとエラーを仕込んで、Claude Codeに直させる流れです。

my_project/
  ├── main.py
  └── utils.py

プロジェクト名も内容も架空のものです。ご自身の環境で試す場合は、適当なフォルダを作って同じように試せます。

実験1:シンタックスエラーを直してもらう

シンタックスエラーは、コードの書き方が間違っているエラーです。カッコの閉じ忘れや、コロン(:)の付け忘れなどが該当します。

どう頼んだか

main.pyにカッコの閉じ忘れがある状態で、ターミナルに表示されたエラーメッセージをそのままコピペして頼みました。

依頼文:「以下のエラーが出ました。main.pyを直してください。
SyntaxError: unexpected EOF while parsing (main.py, line 5)」

結果

1回のやり取りで直りました。Claude Codeはエラーメッセージから該当行を特定し、カッコを追加してくれました。修正内容を見ると、確かに5行目の閉じカッコが欠けていたのが補われています。

頼むだけでできたこと
– エラー原因の特定
– 該当箇所の修正
– 修正後のコードの提示

人が確認すべきこと
– 直した箇所以外に変更がないか
– スクリプトが正しく動くか

カッコの閉じ忘れくらいなら、エラーメッセージに行番号も出るので、Claude Codeにとっては得意な領域です。修正後にスクリプトを実行して、想定通りの結果が出るかだけ人が確認すれば問題ありません。

実験2:型エラーとモジュール不足を直してもらう

少し難易度を上げます。今度は「型エラー」(文字列に数値を足そうとする等)と「モジュール不足」(インストールされていないライブラリを使おうとする)の2つを仕込みました。

どう頼んだか

依頼文:「以下のエラーが出ました。utils.pyとmain.pyを確認して直してください。
TypeError: can only concatenate str (not “int”) to str (utils.py, line 3)
ModuleNotFoundError: No module named ‘requests’ (main.py, line 1)」

1回目の結果

Claude Codeは型エラーを修正し、requestsモジュールのインストールコマンド(pip install requests)を提案してくれました。ここまでは順調です。

ただ、型エラーの修正方法が私の意図と違いました。数値を文字列に変換する方向で直したのですが、本来は文字列を数値に変換して計算する意図でした。

どう修正指示を出したか

修正指示:「型エラーの修正方針を変えてください。文字列を数値に変換してから計算するようにしてください」

2回目の結果

指示通りに修正されました。int()で変換するコードに書き換わっています。

やり取りの回数:2回

頼むだけでできたこと
– モジュール不足の解決策の提示(pip install)
– 型エラーの原因特定

人が確認・補足したこと
– 修正方針が正しいかの判断(意図と違う方向で直ったため)
– 修正指示の追加

ここで分かったのは、エラーメッセージだけだと「どう直すか」の方向が自分の意図とズレることがある、ということです。エラーの原因は正しく特定できても、修正方針は人の判断が必要になる場面があります。

実験3:権限エラーと環境依存のエラーに挑戦

一番難易度が高いパターンです。ファイルのアクセス権限エラーと、Windows環境特有のパスの問題(バックスラッシュの扱いなど)を仕込みました。

どう頼んだか

依頼文:「ファイルの読み書きでエラーが出ます。
PermissionError: [Errno 13] Permission denied: ‘C:\Users\user\data\output.txt’」

1回目の結果

Claude Codeは原因を「権限不足」と特定し、管理者権限での実行を提案してきました。これは部分的に正解です。ただ、実際の原因は「output.txtが別のアプリで開かれていてロックされていた」という別の理由でした。

人が補足した情報

修正指示:「このファイルはExcelで開いたままになっている可能性があります。ファイルを閉じた状態で再実行する案内に変えてください」

2回目の結果

指示に従って、ファイルが開かれていないか確認してから実行する手順に書き換えてくれました。

やり取りの回数:2回

頼むだけでできたこと
– エラーメッセージからの原因候補の提示
– 解決策の提案

人が補足したこと
– 実際の環境で起きていることの説明
– 正しい原因の特定
– 適切な解決手順の指定

権限エラーは、エラーメッセージだけでは本当の原因が分からないことがあります。「権限がない」と出ていても、実際はファイルがロックされているだけ、というケースはWindowsではよくあります。こういう状況は、画面の前で何が起きているかを人がClaude Codeに伝える必要があります。

ここから先は人が確認・判断しないと進まない領域です。エラーメッセージに書かれていない「今の画面で何が起きているか」は、使っている人にしか分かりません。

結果まとめ:どこまで頼むだけで直る?

3つの実験結果を一覧にまとめます。

エラーの種類 頼むだけで直る率 やり取りの回数 人が確認すること
シンタックスエラー 高い 1回 動作確認のみ
型エラー・モジュール不足 中程度 1〜2回 修正方針の確認
権限エラー・環境依存 低い 2回以上 原因の特定と状況の説明

全パターンで共通して人がやるべきこと:
– 修正後にスクリプトを動かして結果を確認する
– 直した箇所以外に予期しない変更がないか見る
– エラーメッセージに書かれていない状況(画面の状態、開いているアプリなど)をClaude Codeに伝える

依頼文にはエラーメッセージだけでなく「何をしようとしていたか」も添えると、修正方針がズレにくくなります。「ファイルを保存しようとしたらこのエラーが出た」のように、やろうとしたことの文脈があると精度が上がります。

検証の振り返りと次のステップ

3つの実験のやり取りは合計5回(シンタックスエラー1回、型エラー2回、権限エラー2回)でした。

エラーメッセージからの原因特定は全パターンでできました。一方で、修正方針が意図とズレたこと(型エラー)と、エラーメッセージに現れない本当の原因を人が特定したこと(権限エラー)がありました。

使ったのはエラーメッセージのコピペと、結果を見ての追加指示だけです。プログラミングの深い知識がなくても、「直ったかどうか」をスクリプトの実行結果で確認できます。

次に試すなら

基本機能だけでも、エラーメッセージをコピペして頼めばかなりの確率で修正の方向が分かります。まずはシンタックスエラーや型エラーあたりから試してみるのがおすすめです。

もっと精度を上げたい場合は、ターミナルのログをClaude Codeが自動で読めるようにするMCPサーバー(拡張機能)の導入という手段もあります。ただし初期設定が必要になるので、まずは基本機能で試してからで十分です(MCPサーバーの詳細は別記事で紹介します)。

このブログには「Claude Codeで429エラーが出た時の直し方」という記事もあります。あちらは特定のエラーに対する具体的な解決手順を扱っていて、この記事とは切り口が違います。特定のエラーに困っている場合はそちらも参照してください。

まとめ

エラー修正をClaude Codeに頼む場合、「エラーメッセージから原因が読めるかどうか」が成功率の分かれ目になります。シンタックスエラーのようにメッセージと原因がほぼ1対1のものは頼むだけで直ります。権限エラーのようにメッセージだけでは本当の原因が分からないものは、人が状況を補足する必要があります。どのエラーでも最後の動作確認は人がやる。この境界線を知っておくと、エラーに出会っても焦らず対応できます。

目次