😖１．AIに何度指示しても直らない！！
GithubCopilot、Cursor、Claude CodeなどのコーディングAIアシスタントをつかっていると必ず遭遇する状況だと思います。
私は、Cline、Cursorを経て、今は、Claude Codeだけで開発をしています。
それは、何度指示しても直らない状況を経験して、モデル料金の節約と精度の高いコードを求めた結果でした。
でも、最近（2025.08）は、AIアシスタントやツールのせいではない気がしています。
ここ最近は、修正ループを減らして、比較的早めにループを脱出させられるようになりました。
何をしているのかメモ代わりに書いてみます。
😵💫２．問題を起こすバイブコーディング
まず、防止や脱出に言及するにあたり、問題を引き起こす状況を整理します。
これを裏返せば防止と脱出の方法になります。
AIでアプリ開発をする際の醍醐味でもある「バイブコーディング（Vibe Codoing）」。
これが問題を生むポイントになります。
バイブコーディングは一般的に以下のようなものを指します。
バイブコーディングの大きな特徴は、正確な仕様書ではなく「こういった雰囲気にしたい」「このような操作感にしたい」といった曖昧な表現にもAIが対応できる点にあります。
ちなみに、バイブコーディングという言葉の発端になったAI（OpenAI）の共同創業者であるアンドレイ・カルパシー氏のポストは以下です。内容はAIに翻訳してもらえばいいと思います。
バイブコーディングは、AIをつかったソフトウェア開発の醍醐味ではあります。
そして、バイブコーディングをしてはいけないわけではないです。
スタートはバイブコーディングでもOKだと思います。
問題は、それの使い方だと思います。
2025年8月時点では、アプリの表面的なこと、すなわち、ユーザー視点の要求を投げて、自動的に綺麗、かつ、問題のないコードを生成することはありません。
つまり、内部設計（プログラム仕様、アーキテクチャ）の言及なく、きれいなコーディングはほぼ不可能です。
勿論、スコープを絞り、設計の指示を与えれば実装してくれます。
アプリは複数の画面や機能があります。それを作らせるのに、少なく、曖昧な指示で、完璧なコーディングを期待するのは、現時点の比較的安価なAIサービスやツールでは無理です。
この状況でバイブコーディングを進めるとコードが汚くなり、修正ループに入っていくことになります。
🔍️３．現時点(2025.8）のAIコーディングツールの限界と特性
AIでソフトウェア開発している人は、実体験を通して、AIに丸投げしたらきれいなコードができるなど思っていないと思います。
✏️a. コンテキストウィンドウ（入出力サイズ）の限界
生成AIには、入出力する文字の制限（コンテキストウィンドウ）があります。
また、コンテキストウィンドウが増えれば増えるほど、個々の作業の質が下がったり、忘れたりします。これは多くの人が記事で投稿しています。
これは、指示だけでなく、読み込む情報や生成したコードにも当てはまるので、一つの指示で必要な情報は絞り、生成するコードも小さく保つ必要があります。
なので、基本的には小さくタスクを作り、少ない情報で処理することがよいと言われています。以下の記事でいうと、「インクリメンタルモデルクエリ」に該当します。
インクリメンタルモデルクエリでは、AIとのやり取りを段階的（ステップ・バイ・ステップ）に行います。ユーザーのゴールに向かって一直線に答えを出すのではなく、まず小さな一歩を踏み出し、その結果を見て次の一歩を決める、という人間の対話に近いプロセスを辿ります
💪b. 細かくタスクを絞り情報を与えれば精度の高いコードができる
私は、仕事でソフトウェア開発以外にも、AIコーディングをします。たとえば、以下です。
インフラ系作業
・ファイルサーバの権限やパスを取得（C#）
・AWSなどのインフラ構築用のterafformの定義ファイル作成
・ネットワーク調査のコマンド作成
・SaaSを操作・管理するためのAPIをつかったプログラム開発（Python）
データ解析系作業
・データの集約集計、クレンジング（SQL、C#、Python）
・ExcelVBAやGASの操作
こうした処理内容が少なく明確なコードは、かなり精度の高いものになります。
内部設計についても指示すればその通りにしてくれます。
ちなみに、以下の論文では、複雑なプログラミング問題をより小さく、独立した推論ステップに分解することで、より構造化され、解釈しやすい問題解決ができることを示しています。（モジュールプロンプティング）
Ruwei Pan, Hongyu Zhang. "Modularization is Better: Effective Code Generation with Modular Prompting." arXiv preprint, 2025‑03‑16. arXiv:2503.12483.arxiv.org
⚔️４．現時点のAIの制約と特性を踏まえた修正ループの防止、脱出策
これまで観た通り、漠然と沢山の情報を与えてもコードが汚くなり、問題を起こします。
一方で、小さく処理を絞っていけばかなり精度の高いコードになります。
これを踏まえて以下のようにすることで修正ループに対応できると思います。
【修正ループ防止案】
・１回の指示で必要な情報を与える。
└（rule、CLAUDE.mdなどの広域メモリに詰め込まない）
・１つの指示の処理範囲を狭くする。
・必ずコードのリファクタリングをする。
└ ある程度モジュールが揃ったら、細かくコードレビューをして共通化やコードのムダを省き、１つのファイルの行数を減らす。
生成AI登場前の手動開発時と同じ作業だと思います。
現時点のAIでは、全自動で要求仕様（ユーザー視点の仕様）だけで、内部設計まできれいなコードは作れません。
なので、人間が内部設計（アーキテクチャやコードの質）まで担保する必要があります。
前述したとおり、コードの行数が増えると問題を起こす確率も高くなるので、定期的にリファクタリングをして見通しの良い、内容を把握しやすいコードを保つことは大切です。
たとえば、ClaudeCodeは、入力トークンの限界があるので、長すぎるコードは分割して読むため、かなりコード理解力が落ちるように見えます。
とりあえず、コードを綺麗に保つことで、あとはそれを真似させたりすれば、比較的きれいなコードができて、AIのコーディングの精度も高くなります。
それでも、ときに問題を起こすことがあります。
そのときは以下のような方法で対処すれば修正ループから脱出できると思います。
【修正ループ脱出案】
・コードをみて内部設計的なアドバイスをいれる
└ バイブコーディングしてる場合戸惑いを覚えると思います。ただ、前述した通り、現時点のAIは内部をうまく設計できないので、やはり人間がコードをみてアドバイスする必要があります。後述の対策はこの観点に基づきます。
・現状の仕組みを調査して、整理する
└ まず、問題担っていることをAIに調査させます。手をいれようとしている仕組みはどうなっているのか。
・デバッグログをいれて確認
└ ハマりやすいのはWebのフロントエンドのイベントやスタイルです。イベントの場合は、ログをいれて流れを整理させます。Playwright MCPつかってもいいと思いますが、人間の目で確認した方がよいときも多いです。
・（Webフロント限定）コンポーネントにidやclassをいれてDevToolで人間が確認
└ スタイルの問題であれば、コンポーネントにidやclassをつけて構造を確認して、アドバイスをいれます。
・コードが巨大なら分割リファクタリング
└ 適宜リファクタリングをしてこなかった場合は、ループになったのがよいきっかけなのでここで分割リファクタリングをします。
・Contex7(MCPサーバ）やGeminiCLIでネットの情報を参照させる
└ ハマってしまっているので、別の視点を与えるために公式ドキュメントやネットの情報を参照させます。これはあんまり期待薄ですが、偶にうまくいきます。
以上が、修正ループの防止と脱出作の案です。
まずは、防止を心がけたほうがよいと思います。ただ、すでに汚いまま進んで修正ループに入ったら、この機会にリファクタリングをして綺麗にしましょう。
WebフロントでReactをつかっている場合、機能が多いコンポーネントは肥大化しています。
Presentation/ContainerパターンやCompositパターンで分割するように指示して、コードを分割しましょう。
📐５．AIコーディングでもプログラムのコードをみる内部設計観点は重要
現時点では、AIは特に指示がない限り、内部設計観点で問題がないようにコーディングは指示なくしてはできません。外部設計（ユーザー視点）の要望だけ与えている場合、内部設計の観点はバラバラになり、問題を引き起こします。
なので、かならず内部設計の観点をもってコードレビューをシて適宜リファクタリングする必要があります。
そのうち、外部設計の情報だけで、綺麗に内部設計もできるAIができるかもしれませんが、2025.08時点ではないようです。少なくとも民間人が出せる金額のサービスでは見当たりません。
もし未経験でいきなりAIでのコーディングをはじめた人は、この機会に内部設計をするために、ソフトウェアアーキテクチャを学ぶとよいと思います。
🔑６．書き捨てツール以外のアプリ開発はコンテキストエンジニアリングが重要
最近、生成AIの利用にあたっては、プロンプトエンジニアリングから一歩進んでコンテキストエンジニアリングが重要と言われます。
簡単にいえば、一回の指示に関する情報を理解しやすいように過不足なく伝えることだと思います。
AIコーディングツールの使い方をみていると、cursorrulesやCLAUD.mdなどのAIが参照するプロンプト（メモリ）に多くの情報を書いているのを見かけます。
一方で、指示をするチャットでは簡単な情報だけにすることがあります。
これでは、一つの作業にあたって重要な情報が伝わりません。
本当に、その作業に必要な情報だけをAIに伝える必要があります。
こうした、作業に密接な情報を過不足なく伝えることをコンテキストエンジニアリングといえます。
最近評価の高い、AIコーディングエディタの「KIRO」は、作業ごとのコンテキストをうまくつくれるところが評価されていると思います。
前述の通り現時点では、生成AIはコンテキストウィンドウの制約によりアプリ全体の仕様を把握して個々のモジュールをコーディングはできません。
モジュール間の情報を誰かが補る必要があります。現時点ではまだ人間がその役を担わざるを得ないと思います。
また、コンテキストエンジニアリングのサポートツールとしては、MCPサーバのSerenaが挙げられます。
Serenaを活用しながら、人間がアプリのアーキテクチャやモジュール間の整合性をとるというのが今のところは重要だおと思います。
残念ながら、2025.08時点では、外部設計を伝えても、アプリの全体のアーキテクチャを考え、それをどんなときも踏襲するAIコーディングツールはないようです。
それゆえ、人間がアーキテクトの役割を担い、モジュールをリファクタリングしながら品質を担保する必要がまだあります。
🏭️7. AIを期待通りに処理させるフローをつくるClaude Code
ここまでの話で、2025.08時点ではAIがバイブコーディングだけで綺麗にコーディングしてくれないこと示しました。
ソフトウェア開発の流れ、ソフトウェアのアーキテクチャはまだ人間が主導権を握る必要があると思います。
AIはあくまでも個別の工程で驚異的な速度と性能を示す補助ツールに過ぎません。
ただ、流れをつくればかなり開発の後押しをしてくれるのも確かです。
そうしたAIの生産性を高めるには、適宜人間がサポートをいれることが現時点では必要です。
そうしたAIの処理フローをつくりやすいツールとして、Claude Codeがあると思います。
Claude Codeは、Sonet4やOpus4などプレミアムモデルを定額で多めに利用できるだけがメリットではないと思います。
カスタムスラッシュコマンド、Hooks、サブエージェント、MCPサーバ管理などAIのコンテキストエンジニアリングや精度を高めるための機能を比較的簡単に整備できるのがメリットだと思います。
モデルにコードを生成させてる点では、CursorやClineも変わらないと思います。Cursor でOpusやSonnetを使えばよいだけです。
これらとClaude Codeが異なる点は、人間が考えた処理の流れにAIを乗せやすい所だと思います。
完全に仕事をお任せできるAIアシスタントというより、AIモデルを使った「フローフレームワーク」という方が適切だと思います。
カスタムスラッシュコマンドで大枠の流れをつくり、サブエージェントでメインコンテキストを汚さずに処理をさせ、適切なモデル利用をする。そして、確実にさせたい処理はMCPサーバで行う。
こうした処理フローを作りやすいのがClaude Codeです。
全自動ではできないからこそ、こうしたフレームワークが必要な気がします。
⛳️8. 最後に
AIの修正ループをどうやって防止し、脱出するかについて私の提案をしてみました。
あくまでも案なので、絶対これで問題が回避できるかはわかりませんが、私は比較的何もしないときよりは問題を減らせました。
私は2025年4月からGithub Coilot、Gemini Code Assist、Cline、Cursor、Claude CodeなどのAIコーディングツールをつかって、実案件での開発を行いました。
その経験から、バイブコーディングだけでアプリが作れないのを実感しました。
まだまだ、内部設計ができるプログラマーの存在が必要だと思います。
この制約がありながらも部分的には驚異的な速度でコーディングやテスト、ドキュメント作成をしてくれるAI。
使わない手はないですが、その制約と特性をしり、うまく活用することが必要だと思います。
少しでも読んだ人のAI駆動開発の参考になれば幸いです。