AI生成コードのデバッグの仕方（非エンジニア視点）
私はプログラミング言語をほとんど読めません。HTML や CSS すら、見ても何が書いてあるのか分かりません。JavaScript・Python に至っては「動いているらしい」という認識しかありません。
それでも、AIが書いたコードのバグを直せます。この記事では、非エンジニアでもできるデバッグの手順 を書きます。
「分からないけど直せる」という状態
私のスキル感を率直に書くと：
- HTML：タグが何のためにあるのか分からない
- CSS：色やフォントの指定が書いてあるらしい、くらい
- JavaScript：呪文に見える
- Python：もはや何も分からない
このレベルで、ツール工房のすべてのツール（ホテル検索、子連れスポット、楽天最安値検索、お金診断、スマホ料金比較）が公開できているのは、バグの直し方を覚えたから です。
基本パターン1：エラーをそのまま貼る
何かが動かないとき、ターミナルやブラウザのコンソールに エラーメッセージ が出ています。これを そのままClaude Codeに貼り付け ます。
「エラーが出ました」だけだと、Claude も何が起きているか分かりません。エラーメッセージをそのまま貼ると、Claude が原因を特定して直してくれます。
例：
- 「
TypeError: Cannot read property 'length' of undefinedというエラーが出ました」 - 「
Module not found: Error: Can't resolve 'xxx'と出ます」
これだけで、9割のケースは解決します。
基本パターン2：症状を具体的に伝える
エラーが出ない（けど何かおかしい）ケースもあります。このときは 症状を具体的に 伝えます。
避けたい伝え方：
- 「動かない」
- 「変です」
- 「うまくいきません」
伝わる伝え方：
- 「ボタンを押しても何も起きない。コンソールには何も表示されない」
- 「データは表示されるけど、ソート順がおかしい。最新順にしたいのに、古い順になっている」
- 「PCでは正しく表示されるけど、スマホで見ると右側がはみ出している」
具体的な症状を伝えると、Claude が「こういう原因かもしれない」と推測して直してくれます。
基本パターン3：「他の方法は？」を聞く
一度提案された方法でうまくいかないとき、すぐに諦めずに 別の方法を聞く のが有効です。
私のよく使う言い回し：
- 「これでもダメでした。他の方法はありますか？」
- 「Plan B を出してください」
- 「もっと簡単な方法はありますか？」
Claude は最初の方法に固執せず、別のアプローチを提案してくれます。「3つ目のアプローチで動いた」みたいなことが普通にあります。
基本パターン4：「ファイル名を明示する」
「ホテル検索のソート機能を直して」と言うより、「ClaudeCode/宿泊公開版/index.html の sort 関数を直して」 と伝える方が、的確に直してくれます。
ファイルパス・関数名・行番号を伝えると、Claude が無関係な場所を触ってしまうリスクが減ります。
基本パターン5：エスケープボタンと git の活用
Claude が想定と違う方向に進んでいるとき、ESCキーで止める のが有効。完了するまで待たずに「あ、これは違う方向だ」と気づいた段階で止めて、方針を伝え直します。
また、変更が大きすぎて元に戻したいときは git diff や git status を確認したうえで、git checkout で元に戻すこともできます（これは Claude にやってもらえます）。
実例1：地図が表示されない
子連れスポット検索を作っているとき、Google Maps が表示されない不具合がありました。
症状を伝えた：
「地図が真っ白で何も表示されません。コンソールには
RefererNotAllowedMapErrorと出ています」
これだけで Claude が判断：
「Google Maps の APIキーにリファラ制限がかかっています。Cloud Console で、現在のドメインを許可リストに追加する必要があります」
→ 私が Google Cloud Console で設定変更 → 解決
実例2：ソートが効かない
スマホ料金比較で、月額料金順のソートが正しく機能しない問題。
エラーを貼った：
「ソートボタンを押しても並び替わらない。コンソールに
Cannot read properties of undefined (reading 'price')と出る」
Claude が判断：
「
priceフィールドがないプランがある可能性があります。確認したい」
→ プランデータを見ると、一部のプランに price フィールドが欠落していた → 全プランに price を追加 → 解決
実例3：レイアウト崩れ
スマホで見ると右側がはみ出すバグ。
症状を伝えた：
「PCでは問題ないが、スマホで見ると料金比較表が画面の右にはみ出している。横スクロールも効かない」
Claude が判断：
「テーブルが画面幅より広いまま表示されています。
overflow-x: autoを親要素に追加するか、<div class='table-wrapper'>で囲むのがおすすめです」
→ 解決
「分からないことを分からないと言う」勇気
非エンジニアがAIで開発するときに、一番大事なのは 「分からないことを分からないと言う」 勇気だと思います。
「JavaScriptの promise が分からない」「非同期処理って何？」と素直に聞けば、Claude は分かりやすく説明してくれます。「分かったふり」をして進めると、後でもっとややこしいバグが出ます。
私は「正直、よく分かっていません」と前置きしてから質問することが多いです。それで困ったことはほぼありません。
デバッグでの「Claude vs 自分」の役割分担
私が担当するのは：
- 症状を観察する（何が起きているか）
- 何をしたいかを伝える（期待する挙動）
- Claude の提案を試す（実行して結果を確認）
- 動作確認の判断（ブラウザで実際に触ってみる）
Claudeが担当するのは：
- コードを読む（どこが問題か）
- 修正案を出す（どう直すか）
- 修正の実行（コードを書き換える）
- 代替案の提案（うまくいかないときの別アプローチ）
非エンジニアの強みは「ユーザー目線で症状を観察できること」、AIの強みは「コードを高速に読み書きできること」。役割分担すると、お互いの強みが活きます。
私の感想
AIが書いたコードのデバッグは、最初は怖かったです。「自分で直せないコードを公開していいのか？」という不安がありました。
でも実際にやってみると、ほとんどのバグは Claude に相談すれば直せる ことが分かってきました。プログラミング言語が読めなくても、症状を伝えて、エラーを貼って、結果を確認できれば、開発は回っていきます。
「全部わかってから始める」を待っていたら、何も公開できていませんでした。動かしながら、必要なことを少しずつ理解していく のが、非エンジニア × AI 開発のリズムだと思います。
← 他の制作記を見る ｜ トップ ｜ お問い合わせ