「動かない」を解決！ChatGPT/Claudeが吐いたコードのバグ修正をプロに頼むべきタイミング

ChatGPTやClaude、Cursorのおかげで、コードを書くハードルは劇的に下がりました。しかし、同時に増えているのが「AIが書いたコードがどうしても動かない」という悩みです。

エラーをAIに投げると新しい修正案が出ますが、それを試すとまた別のエラーが出る……この「無限デバッグ地獄」にハマった経験はありませんか？

なぜAIとのデバッグはループするのか

AIのデバッグが堂々巡りになる理由は構造的なものです。3つの限界があります。

1. コンテキスト窓の限界 AIは会話の中で一定量のコードしか「見る」ことができません。プロジェクトが大きくなるにつれ、全体を把握しきれなくなります。ファイルAを修正するとファイルBが壊れる——という複数ファイルにまたがる問題は、AIが特に苦手とする領域です。

2. 症状への対処で根本原因を直さない AIはエラーメッセージという「症状」に反応します。しかし本当の問題はアーキテクチャ設計やデータフローにある場合、症状をいくら叩いても解決しません。「エラーは消えたが別の場所が壊れた」を繰り返すのはこのためです。

3. 全体設計が見えていない AIはあなたが渡したコードしか見ていません。「なぜこの設計になっているのか」「どんな技術的制約があるのか」という背景を知らずに修正するため、システム全体の整合性を保てないことがあります。

「ループしている」サインを見極める

次の症状が出たら、デバッグループに入っている可能性が高いです。

• 同じエラーメッセージが、「修正した」はずなのに再び現れる
• バンドエイド的な修正が積み重なり、コードの見通しが悪くなっている
• 「直した」ことで新しいエラーが発生し、修正すべき箇所が増えている
• コードの変更理由が自分でも説明できなくなっている
• 最初の問題から別のファイルでのエラーに話が飛んでいる

3時間ルール： 1つのエラーに対してAIとのやり取りで3時間以上かかっている場合、それはAIが解決できる問題ではない可能性が高い。これ以上粘っても、コードは継ぎ接ぎだらけになり、仮に動いたとしても将来的にメンテナンス不可能な「スパゲッティコード」になります。

プロに頼むべき3つのカテゴリ

カテゴリ1：環境構築・デプロイ周りのエラー

典型的な症状：

• 「ローカルでは動くのにVercelに上げるとエラーになる」
• 「npm install したのにモジュールが見つからない」
• 「Dockerコンテナが起動しない」
• 「Node.jsのバージョンが違うとエラーになる」

環境構築・デプロイ系のエラーは、AIが特に苦手とする領域です。ライブラリのバージョン依存、OS固有の問題、Linuxとmacの挙動差異、クラウド環境特有の設定——これらはAIが学習データから正確に把握できていない最新情報を含むことが多い。また、エラーの原因が「自分のコード」ではなく「環境設定」にある場合、コードを修正するアプローチそのものが間違っています。

カテゴリ2：マルチファイルの不整合

典型的な症状：

• 「AのAPIを修正したら、それを呼んでいるBが動かなくなった」
• 「型定義を変えたら、10箇所でエラーが出た」
• 「データベースのスキーマ変更に伴い、全体を整合させたい」
• 「コンポーネントのpropsを変えたら他でも全部変える必要がある」

全体設計を理解した上でリファクタリングするのは、人間のエンジニアが最も得意とする仕事です。AIは一度に渡せるコードの量に限界があり、プロジェクト全体を見渡した上で「最小変更で最大効果を出す」判断を下すのは難しい。

カテゴリ3：認証・決済などのセキュリティクリティカルな部分

典型的な症状：

• 「ログイン周りが何かおかしい気がするが原因がわからない」
• 「決済フローが完成したと思うが、本当に安全か自信がない」
• 「パスワードリセットを実装したが、セキュリティ的に問題ないか確認したい」

「なんとなく動く」で済ませた認証・決済コードには、目に見えない脆弱性が潜んでいることがあります。7payの事例でも明らかなように、これは後になって取り返しのつかない事故につながります。セキュリティクリティカルな部分は、AIが「動くコード」を生成したとしても、専門家によるレビューを受けることを強くすすめます。

プロに依頼する前に準備するもの

依頼の質がそのまま解決スピードとコストに直結します。以下を揃えておいてください。

1. エラーログの全文 「エラーが出る」ではなく、コンソールやターミナルに表示されるエラーメッセージをそのままコピーしてください。「TypeError: Cannot read properties of undefined (reading 'map')」のような具体的なメッセージが重要です。

2. 再現手順 「どの画面で」「何をクリックすると」「どのエラーが出るか」を手順として書いてください。再現できないバグの修正は難しく、コストが上がります。

3. 試したことのリスト AIに聞いて試したこと、検索して試したことを列挙してください。これがないと同じことを繰り返すことになり、無駄なコストが発生します。

4. 関連するコードのリンクまたはファイル GitHubリポジトリのリンク、または問題に関係するファイルの内容を共有してください。コード全体が見えないと、的確な診断ができません。

コストの現実：3日間の自己解決 vs 3時間のプロ依頼

「全部を開発会社に丸投げ」するのではなく、「詰まっている特定の問題だけを依頼する」という形であれば、コストは大幅に下がります。

「AIで作ったここまでのコードを動くようにしてほしい」という依頼は、数万円〜数十万円で解決することが多いです。一方、あなたが同じ問題に3日間かけて取り組んでも解決できなかったとしたら——その3日間で失った機会コスト（リリースが3日遅れたこと、その間に失った可能性）を考えると、プロに依頼した方が経済的に合理的であることが多い。

特に「リリース直前で詰まっている」状況では、解決までの時間価値が非常に高くなります。「あとデプロイだけなのに」という状況で1週間詰まるより、プロに1日で突破してもらった方がいい。

AI時代の賢い開発スタイルは「AIで作れる部分はAIに任せ、AIが苦手な部分はプロに任せる」です。すべてを自力でやろうとする必要はありません。