「AIにコードを書かせれば、プログラミングを知らなくてもアプリが作れる」——そんな期待を持ってAIコーディングを始めた方は多いはずです。しかし実際には、ある程度まで進んだところで突然動かなくなる・進まなくなるという壁にぶつかるケースが後を絶ちません。
この記事では、AIコーディングが途中で詰まる本当の原因と、その対策を解説します。そして最後に、残念ながら現状プログラミングスキルとコードを読む力は不要にならないという現実についてもお伝えします。
原因1：コンテキストの肥大化とトークン枯渇
AIとのやり取りを重ねるほど、会話の履歴・読み込んだコード・推論の結果が積み重なり、処理できる情報量（コンテキストウィンドウ）を超えていきます。1回のプロンプト処理で消費されるトークンは：
- システムプロンプト
- 会話履歴の全文
- 読み込んだファイル群
- AIの推論・出力
これらすべてが積み上がるため、会話が長くなるほどコストと処理量が増大し続け、最終的には上限に達して正確な応答ができなくなります。「序盤は快調だったのに、後半から急におかしくなった」という経験はこれが原因です。
原因2：変更が積み重なるほど「前提の崩壊」が起きる
AIは前の会話の内容を記憶しているように見えますが、実際は毎回すべてを再解釈しています。修正を重ねるうちに：
- 古い指示と新しい指示が矛盾する
- 間違った前提がそのまま引き継がれる
- 「なんとなく動いているコード」の上にさらに積み上げてしまう
これがコンテキスト汚染と呼ばれる状態です。AIは誤りを黙って推測で補完しようとするため、問題が表面化したときには原因の特定が非常に困難になっています。
原因3：変更範囲の無秩序な拡大
「全体的にリファクタリングして」「ベストプラクティスに合わせて修正して」といった指示は、AIにとって範囲が無限大の作業指示です。関係のないファイルまで変更され、どこで何が壊れたかわからない状態に陥ります。
特に中規模以上のコードベースでは、1つの変更が別のモジュールへの影響を持つことが多く、AIが意図せず依存関係を破壊してしまうことが頻繁に発生します。
原因4：検証ループの欠如
AIは「できました」と答えても、実際には動作確認をしていないことがほとんどです。テストコマンドや完了条件を指定しないまま修正を依頼し続けると、壊れたコードの上に壊れたコードが積み上がっていきます。
対策：途中で詰まらないためのプロンプト設計
対策1：「探索・計画・実装」を分けて指示する
範囲が不明なまま「修正して」と丸投げするのが最大の失敗パターンです。次の3ステップに分割することで、暴走を防げます。
ステップ1（探索）：「このバグを修正するために変更が必要なファイルと箇所を調査し、変更計画のみを出力せよ。コードは書くな。」
ステップ2（計画確認）：計画を人間が確認・承認する
ステップ3（実装）：「上記の計画のうち、〇〇の部分のみ実装せよ。」
対策2：コンテキストを定期的にリセットする
一定のタスクが完了したら、会話を続けるのではなく一度区切りましょう。その際、AIに現状を要約させます：
「ここまでの変更内容を以下の形式で要約せよ：変更済みファイル・未完了タスク・現在の状態の前提」
この要約だけを新しい会話に持ち込むことで、コンテキスト汚染をリセットできます。
対策3：禁止事項をネガティブ定義する
変更してよい範囲が不明確なときは、逆に「触れてはいけない領域」を明示します：
「以下は変更禁止：DBスキーマ定義ファイル、外部APIのインターフェース層、設定ファイル。それ以外で必要な箇所を修正せよ。」
対策4：「判断に迷ったら止まれ」と指示する
これを書かないとAIは黙って推測実装します。必ず以下を含めましょう：
「判断に迷う箇所があれば実装を止めて質問せよ。推測で進めるな。」
対策5：ファイルを丸ごと渡さず、必要な部分だけ渡す
トークンの節約と精度向上のために、ファイルの全文ではなく関連部分だけを渡す工夫が重要です：
- 関数のシグネチャ・型定義のみ抽出して渡す
grepで該当行前後だけを抜き出すgit diffで変更差分のみを渡す
対策6：繰り返し使う実装はモジュール化してAIに参照させる
AIコーディングで見落とされがちなのが、「同じような実装を何度も書かせてしまう」問題です。認証処理・APIリクエスト・エラーハンドリング・ログ出力など、プロジェクト内で繰り返し登場するパターンを毎回AIに一から書かせると、実装がバラバラになり、後から統一的に修正できなくなります。
対策として有効なのが、共通処理をモジュール化して「お手本」としてAIに提示する方法です：
「新しいAPIエンドポイントを追加する。エラーハンドリングは
src/utils/errorHandler.jsのパターンに必ず従え。認証処理はsrc/middleware/auth.jsを使え。新たに同等の実装を書くな。」
モジュール化の具体的な進め方：
- プロジェクト初期に「共通処理ライブラリ」のディレクトリを作り、AIにその存在を常に認識させる
- AIが新しいコードを書くたびに「同じ処理が既存モジュールにないか確認してから実装せよ」と指示する
- 同じパターンが2回以上出てきたらモジュール化のサインと判断し、AIに切り出しを指示する
この習慣があるだけで、コードベース全体の一貫性が保たれ、後からの修正コストが大幅に下がります。AIにとっても「既存のお手本に倣う」という明確な制約があるほど、出力の品質と安定性が上がります。
対策7：定期的にコードの検証・リファクタリングを実施する
AIと一緒に開発を進めていると、個々の実装は動くのにコードベース全体としてじわじわと劣化していく問題が起きます。重複した処理の散在・一貫性のない命名・不要になった変数や関数の放置・モジュール間の依存関係の複雑化——これらは1回の変更では気づきにくいですが、積み重なると後からAIも人間も理解できないコードになっていきます。
これを防ぐために有効なのが、一定のサイクルで立ち止まって振り返る「リファクタリングスプリント」を設けることです。
AIにやらせる場合の指示例：
「新機能の追加は一切行わず、以下の観点でコードを検査・改善せよ：①重複している処理の統合、②使われていないコードの削除、③命名の一貫性、④モジュール間の依存関係の整理。変更前に必ず計画を出力し、承認後に実装せよ。」
ただし、このフェーズこそ人間がコードを読む最大の機会でもあります。AIによる自動リファクタリングは便利ですが、「なぜそのような構造になっているか」という背景をAIは知らないことが多く、意図のある設計を誤って「整理」してしまうリスクがあります。
リファクタリング時に人間が確認すべきポイント：
- AIが削除しようとしているコードに意図があるか
- 統合された処理が本当に「同じもの」か（似ているが微妙に異なる場合がある）
- リファクタリング後に既存のテストがすべて通るか
- コードが読みやすくなったか、それとも逆に抽象化しすぎていないか
目安として、ひとつの機能単位が完成したタイミング、あるいは一定のコミット数ごとにリファクタリングの時間を設けると、コードの健全性を保ちやすくなります。まとめてやろうとするほど手がつけられなくなるため、小さく定期的にやることが重要です。
対策8：Gitで「いつでも戻れる」状態を保つ
AIコーディングで開発が破綻するケースの一因として、見落とされがちなのが「戻れない」問題です。通常の開発では「少し試してダメなら戻す」という判断が自然にできますが、AIに任せながら進めていると変更が積み重なり、「どこから壊れたのかわからない、でも戻し方もわからない」という状態に陥りがちです。
これを防ぐ最も確実な方法が、Gitによるバージョン管理をAIコーディングの大前提にすることです：
- AIに実装を依頼する前に必ずコミットし、「動いている状態」を記録しておく
- 1タスク＝1コミットを原則にし、変更の単位を小さく保つ
- AIへの指示の中に「作業前に現在のブランチを確認し、新しいブランチを切ってから実装せよ」を含める
- うまくいかなければ迷わず
git resetやgit checkoutで戻る判断をする
「Gitを使っているから大丈夫」ではなく、コミットの粒度が粗いとGitがあっても戻れない点に注意が必要です。AIが一気に10ファイルを変更した後にまとめてコミットするのではなく、1ファイルまたは1機能単位でこまめにコミットする習慣が、AIコーディング特有のリスクを大幅に下げます。
※GITがない場合は、AIによる１～２修正ごとに、AIに何を支持したかをリストして紐づいたバックアップを取るのもお勧めです。
それでも、プログラミングスキルは不要にならない
ここまでの対策を見てわかる通り、AIを使ったコーディングが詰まる原因の多くは「何をAIに任せるかの判断」を人間がしくじることです。これは裏を返せば、その判断ができる人間がいなければ、対策を実行することすらできないということです。
コードが読めなければ「完了」を判断できない
AIが「修正しました」と言ったとき、それが本当に正しいかどうかを確認するには、コードを読む力が必要です。動作確認だけでは見落とす問題（セキュリティの穴、パフォーマンスの劣化、将来の保守コストの増大）は多く、コードを読めない人は「動いているからOK」という判断しかできません。
エラーの原因を特定できなければ指示が出せない
AIが出したエラーメッセージや問題のある箇所を理解するには、最低限のプログラミング知識が必要です。「なんかエラーが出た、直して」という指示では、AIも的確な修正ができず、試行錯誤のループに入ります。
適切な「タスクの粒度」は知識がないと設定できない
「探索・計画・実装を分ける」という対策も、そもそも何がひとつの作業単位になるかを理解していなければ分割できません。コードの依存関係・モジュール構造・テストの単位を知っていることが前提です。
AIが間違えたとき、引き返す判断ができない
AIは自信満々に誤ったコードを書くことがあります。それが誤りだと気づくためには、正しいコードがどういうものかを知っている必要があります。知識がないまま「AIが言ったから正しいはず」と進み続けると、後から取り返しのつかない技術的負債が積み上がります。
現実的なAIコーディングの位置づけ
AIコーディングは残念ながら現状では「プログラミングスキルを不要にするもの」ではなく、「プログラミングスキルを持つ人の生産性を上げるもの」です。
自動車が「歩く力を不要にした」わけではなく、目的地を設定する判断力や交通ルールの理解が引き続き必要なように、AIというツールを正しく使いこなすには土台となる知識が欠かせません。
AIをうまく活用するために最低限必要なスキルをまとめると：
- コードの構造・依存関係を読み解く力
- エラーメッセージの意味を理解する力
- 変更の影響範囲を推定する力
- 「これは正しい実装か」を判断する力
AIに任せるべき作業と、人間が判断すべき作業を見極めながら活用することが、現時点でのベストプラクティスです。
まとめ
AIコーディングが途中から詰まる主な原因は、コンテキストの肥大化・前提の崩壊・変更範囲の無秩序な拡大・検証ループの欠如の4つです。これらは「探索・計画・実装の分離」「コンテキストの定期リセット」「禁止事項の明示」「判断に迷ったら止まれという指示」といった対策で大きく改善できます。
加えて、繰り返し登場する処理のモジュール化・定期的なリファクタリング・そしてGitでいつでも戻れる状態を保つことが、長期的にプロジェクトを健全に保つための三本柱です。
しかし根本的には、AIを正しく使いこなすためにも、コードを読み・理解し・判断する人間のスキルは依然として不可欠です。AIは優秀なアシスタントですが、プロジェクトの責任者は人間であるという認識を持って取り組むことが、AIコーディングで成果を出す最大のコツですね。
