AIで作った試作が動かなくなる、よくある3つの原因

バイブコーディングで試作を進めていると、「さっきまで動いていたのに、急に動かなくなった」という場面に必ず出会います。これは失敗ではなく、バイブコーディングの過程でよく起きることです。ただし、原因のパターンをあらかじめ知っておくと、慌てずに対処できるようになります。

この記事では、AIで作った試作が動かなくなる、よくある3つの原因と、それぞれの対処法を解説します。あわせて、実際によく報告される失敗パターンの具体例、原因を切り分けるためのチェックリスト、よくある疑問へのQ&Aも収録しました。

なお、こうしたトラブルは決して珍しい話ではなく、本番投入時に約4割が壊れるとされる実態も報告されているほど、バイブコーディングにはつきものの現象です。

この記事で分かること

試作が動かなくなる原因は、大きく3つのパターンに分けられます。それぞれ対処の仕方が異なるため、どのパターンに当たっているかを見極めることが、解決への近道になります。

結論を先に示すと、よくある3つの原因は次の通りです。

• 新しい指示が、既存の動いていた部分に意図せず影響してしまう
• AIが、実際には存在しない情報をもとに実装してしまう
• 細かい修正の積み重ねで、全体の整合性が崩れてしまう

この3つは、それぞれ発生のタイミングや気づき方が違います。原因1は「機能を追加した直後」に気づくことが多く、原因2は「実行した瞬間」にエラーとして表れやすく、原因3は「しばらく経ってから、じわじわと」表面化する傾向があります。まずはこの傾向を頭に入れておくと、実際に遭遇したときの当たりをつけやすくなります。

原因1：新しい指示が、既存の動いていた部分に影響してしまう

最も多いパターンが、新しい機能を追加する指示を出した際に、それまで動いていた別の部分まで意図せず変更されてしまうケースです。AIは指示された範囲を正確に把握しきれず、関連する部分まで書き換えてしまうことがあります。

このパターンに気づいた場合は、まず「〇〇を追加する前は動いていた△△の機能が、今は動かなくなっています」というように、いつから・何が起きたのかを具体的にAIへ伝えることが第一歩です。多くのツールには、過去の状態に戻す機能（変更前の状態を復元する機能）が用意されているため、うまく直せない場合は、一度その機能を使って動いていた状態に戻し、そこから改めて慎重に指示を出し直すという対処も有効です。

このパターンを防ぐには、普段から「一度に直す範囲を小さく保つ」ことを意識するとよいでしょう。改善の進め方については、AIとの対話を繰り返して試作を改善していく、基本的な進め方でも詳しく解説しています。

原因1のよくある具体例

実際に起きやすい具体例を挙げると、次のようなケースがあります。

• 「予約フォームに電話番号の入力欄を追加してほしい」と依頼したところ、フォーム全体のレイアウトが再構成され、それまで正しく動いていた日付選択の機能が動かなくなった
• 「一覧画面に並び替えボタンを追加してほしい」と依頼したところ、一覧の表示件数を制御していた部分まで書き換わり、常に全件表示されるようになった
• 「ボタンの色を変えてほしい」という見た目だけの依頼のはずが、ボタンに紐づいていた処理そのものが別の処理に置き換わってしまった

これらの例からわかるように、依頼の範囲が「見た目の変更」や「一部の追加」であっても、AIは関連しそうな箇所を広めに解釈して手を入れてしまうことがあります。特に、フォームや一覧表示のように複数の要素が組み合わさっている画面ほど、この影響が起きやすい傾向があります。

原因1を防ぐための工夫

• 依頼するときに「〇〇の部分だけを変更してください。△△の機能には触れないでください」と、変更してよい範囲とダメな範囲を明示する
• 大きな変更を依頼する前に、現在動いている状態を保存しておく（保存の頻度を上げるほど、被害を小さくできます）
• 1回の依頼で複数の機能をまとめて頼まない。1つの依頼が終わって動作確認をしてから、次の依頼に進む

原因2：AIが、実際には存在しない情報をもとに実装してしまう

2つ目のパターンは、ハルシネーションと呼ばれる現象に関係します。AIが、実際には存在しない機能や仕様を、あたかも存在するかのように扱ってコードを生成してしまうことがあります。

例えば、実際には対応していない外部サービスの機能を「使える」前提でコードを書いてしまったり、存在しない設定項目を参照するコードを生成してしまったりすることがあります。この場合、コード自体は一見正しく見えても、実行すると「そのような機能・設定は存在しない」というエラーになります。

このパターンに遭遇した場合、AIに「これは本当に存在する機能ですか。確認してください」と問い直すことが有効です。AI自身が誤りに気づき、修正してくれることもあります。また、公式ドキュメントなど信頼できる情報源を確認しながら進めることも、このパターンを防ぐ助けになります。

原因2のよくある具体例

• 「メール送信機能を追加してほしい」と依頼したところ、実際には契約していない、あるいは存在しないメール配信サービスの機能を前提としたコードが生成された
• 決済機能を組み込む際、実際のサービスには存在しない設定項目（架空のオプション名）を参照するコードが書かれ、設定画面でエラーになった
• 「この外部サービスのAPIを使って地図を表示してほしい」と依頼したところ、そのサービスが実際には提供していない機能（存在しない座標変換オプションなど）を使う前提のコードが生成された

このパターンの厄介な点は、コードの見た目だけでは気づきにくいことです。文法的には正しく、変数名や関数名も自然に見えるため、実際に動かしてエラーが出るまで気づかないケースが多くあります。

原因2に気づくためのサイン

次のようなサインが出たら、原因2を疑ってみてください。

• エラーメッセージに「存在しません」「見つかりません」「未定義です」といった言葉が含まれている
• 使っている外部サービスの管理画面を見ても、AIが説明していた設定項目自体が見当たらない
• AIに「この機能は本当に存在しますか」と聞くと、それまでの説明を撤回したり、別の方法を提案し直したりする

原因3：細かい修正の積み重ねで、全体の整合性が崩れてしまう

3つ目のパターンは、技術的負債（技術的負債）とも関係する現象です。1つずつは小さな修正であっても、それが積み重なることで、全体の設計に矛盾や無理が生じ、あるタイミングで急に動かなくなることがあります。

このパターンは、「なぜ動かなくなったのか」の原因が1つに特定しにくいという特徴があります。個別の修正はそれぞれ正しかったとしても、組み合わさることで予期しない不整合が生まれるためです。

対処法としては、AIに「これまでの変更の履歴を振り返って、矛盾している部分がないか確認してください」と依頼することが一つの手段です。また、あまりにも複雑になってしまった場合は、思い切って一部の機能を作り直す（ゼロから組み立て直す）ほうが、細かい原因を追い続けるより早く解決することもあります。

原因3のよくある具体例

• 「会員ランクによって表示する内容を変える」という機能を、数週間かけて少しずつ条件を追加していった結果、途中のどこかで矛盾する条件が生まれ、特定のランクの会員だけ画面が真っ白になった
• 割引計算のロジックに、キャンペーンごとの例外処理を都度追加していった結果、複数のキャンペーンが同時に適用される場面で、意図しない金額が表示されるようになった
• 通知機能に「この場合は送らない」という例外を何度も追加していった結果、本来送るべき通知まで送られなくなった

こうした例に共通するのは、「最後に追加した1つの変更」が単独では正しくても、それ以前に積み重ねてきた変更との組み合わせで不整合が生まれている点です。そのため、直前の変更だけを見直しても解決せず、時間を遡って複数の変更を横断的に見直す必要が出てきます。

原因3への向き合い方

• 機能が複雑になってきたと感じたら、「今の仕組みを一度整理してほしい」とAIに依頼し、コードを整理し直す機会を作る
• 条件分岐が増え続けている部分は、早い段階で「この機能はどういう条件で何をするか」を一覧表のような形でAIに書き出してもらい、矛盾がないか目で確認する
• どうしても原因が特定できない場合は、無理に直そうとせず、その機能だけを作り直す判断も検討する

「動かなくなった」ときに、まず確認したいこと

原因を特定する前に、次の3点を確認しておくと、その後の対処がスムーズになります。

エラー画面・エラーメッセージをそのまま記録する

「動きません」という状態だけを覚えておくのではなく、実際に表示されたエラーメッセージや、画面がどのように変化したかを、スクリーンショットやメモとして残しておいてください。AIに状況を伝える際、この記録が原因特定の重要な材料になります。

エラーメッセージは、たとえ意味が分からなくても、一字一句そのまま伝えることが大切です。「よく分からないエラーが出ました」と伝えるだけでは、AIも原因を絞り込めません。逆に、エラーメッセージの文言をそのまま貼り付けるだけで、AIはそこから多くの情報を読み取り、原因の候補を大きく絞り込めることがあります。

直前に何をしたかを、時系列で振り返る

「最後に正常に動いていたのはいつか」「その後、どんな指示を出したか」を、順を追って振り返ります。この振り返りによって、3つの原因のうちどれに近いかの見当をつけやすくなります。

振り返る際は、可能であれば「〇分前に△△を依頼した」「その次に□□を依頼した」というように、依頼した順番と内容をメモしておくと、後から見返しやすくなります。特に、複数の依頼を立て続けに出した後で動かなくなった場合は、どの依頼が引き金になったのかを1つずつ遡って確認する必要があります。

焦って複数の対処を同時に試さない

動かなくなったことに気づくと、慌てて複数の修正を同時に試してしまうことがあります。しかし、複数の対処を同時に行うと、どの対処が効果があったのか、あるいは新たな問題を生んでいないかが分かりにくくなります。1つずつ、順番に試すことを心がけてください。

例えば、「AIに直してもらう」「自分で設定を変える」「別のツールで試す」を同時に行うと、たとえ問題が解決しても、何が効いたのかが分からず、次に同じ問題が起きたときに再現できません。1つの対処を試して結果を確認し、それでも解決しなければ次の対処に移る、という順序を守ることが、結果的に一番早い解決につながります。

「動かない」状態を、AIにどう伝えるか

3つの原因のいずれであっても、AIへの伝え方には共通するポイントがあります。

まず、「動きません」だけで終わらせず、「いつから」「何をした後に」「どのような症状が出ているか」の3点を、順番に伝えることが基本です。この3点が揃っていれば、AIは原因の候補を絞り込みやすくなります。

また、複数回試しても解決しない場合は、「これは〇回目の試行です。これまでに試した対処法は△△と□□です」と伝えることで、AIが同じ対処を繰り返し提案することを避けられます。すでに試した方法を伝えることは、対話の効率を上げる重要な情報です。

伝え方の良い例・悪い例

伝え方によって、AIからの回答の的確さが大きく変わります。

悪い例:「なんか動かなくなりました。直してください」

この伝え方では、AIは症状も原因の手がかりも受け取れず、当てずっぽうの対処しか提案できません。

良い例:「予約フォームに電話番号の入力欄を追加した後から、日付選択のカレンダーが表示されなくなりました。エラーメッセージは『calendarWidget is not defined』と出ています。まだ何も対処していません」

この伝え方であれば、「いつから」（電話番号の入力欄を追加した後）、「何をした後に」（フォームへの追加依頼の後）、「どのような症状」（カレンダーが表示されない、特定のエラーメッセージが出ている）が全て含まれており、AIは原因1（既存機能への意図しない影響）を優先的に疑って調査を始められます。

3つの原因を見分けるための簡単な手順

実際にどの原因に当たっているかを見分けるには、次の手順で確認するとよいでしょう。

1. 「最近何を変更したか」を振り返る：直前の変更が原因（原因1）である可能性が高いパターンです
2. エラーメッセージに「存在しない」「見つからない」といった内容が含まれているか確認する：原因2の可能性が高いパターンです
3. 特定の変更が原因ではなく、複数の小さな変更が積み重なった結果に見えるか確認する：原因3の可能性が高いパターンです

この手順で大まかな見当をつけてから、それぞれの対処法を試すと、闇雲に試行錯誤するよりも効率的に解決に近づけます。

チェックリストで原因を切り分ける

以下のチェックリストに、当てはまるものにチェックを入れてみてください。当てはまる項目が多いパターンが、最も疑わしい原因です。

原因1（既存機能への影響）を疑うサイン

• [ ] 動かなくなったのは、何かを追加・変更した「直後」だった
• [ ] 動かなくなった機能は、今回変更を依頼した機能とは別の場所にある
• [ ] 変更前の状態に戻すと、問題なく動く

原因2（存在しない情報に基づく実装）を疑うサイン

• [ ] エラーメッセージに「未定義」「存在しない」「見つからない」といった言葉が出ている
• [ ] 使っている外部サービスの管理画面に、AIが説明していた機能や設定項目が見当たらない
• [ ] コード自体は一見自然に見えるが、実行すると必ず同じ箇所でエラーになる

原因3（積み重ねによる整合性の崩れ）を疑うサイン

• [ ] 特定の1回の変更が原因だと言い切れず、しばらく前から少しずつ様子がおかしかった
• [ ] 同じような条件分岐の追加・修正を何度も繰り返してきた機能で問題が起きている
• [ ] AIに原因を聞いても、「複数の要因が絡んでいる可能性があります」といった説明になる

それでも解決しない場合

上記の対処法を試しても解決しない場合、無理に自分だけで解決しようとせず、いったん立ち止まることも大切です。「もう自分では無理」と感じるタイミングの見極め方については、「もう自分では無理」と判断するタイミングの見極め方で詳しく扱っています。専門家に相談する、あるいは範囲を小さくしてやり直す、といった選択肢も、決して後退ではありません。

特に、同じエラーに対して3回以上対処を試みても解決しない場合や、直そうとするたびに別の場所で新しい不具合が発生する場合は、それ以上自力で試行を続けても状況が改善しにくいサインです。こうした状況になったら、一度立ち止まって、これまでの経緯を整理してから次の一手を考えることをおすすめします。

専門知識を反映した試作で起きやすいトラブル

専門分野の業務ロジックを反映した試作を作っている場合、上記の3つの原因に加えて、もう一つ注意したいパターンがあります。それは、専門的な条件分岐が複雑になるほど、AIがその条件の一部を見落としたまま実装してしまうケースです。

例えば、「AかつBの場合はC、AでなくBの場合はD、それ以外の場合はE」というような3段階以上の条件分岐は、AIが正確に反映しきれず、一部の条件だけが正しく動いていないことがあります。このパターンは見た目には動いているように見えるため、発見が遅れがちです。

対処法としては、条件分岐が複数ある機能を実装した際は、それぞれの条件パターンを実際に試して、意図した結果になっているかを1つずつ確認する習慣をつけることです。専門知識を反映した部分は、他の一般的な機能よりも入念な確認が必要だと考えておくとよいでしょう。

業種別に見られる具体例

専門分野の業務ロジックというと抽象的に聞こえるかもしれませんが、実際には次のようなケースで見られます。

• 予約業務で、「平日は3時間前まで、土日祝日は前日までに予約変更可能」というような曜日・時間帯をまたぐ条件が、一部のパターンだけ正しく反映されていなかった
• 在庫管理で、「セット商品は、構成する個別商品のいずれかが欠品したら在庫なし扱いにする」という条件が反映されず、個別商品が欠品していてもセット商品が購入可能な状態のままだった
• 顧客対応で、「特定の条件を満たす顧客だけ優先対応フラグを立てる」という条件に、複数の条件が絡む場合の組み合わせが一部漏れていた

こうした業務ロジックの見落としは、通常の操作では気づかれにくく、特定の条件が重なったときだけ問題が表面化するため、公開後にクレームや問い合わせで初めて発覚することも少なくありません。試作の段階で、条件分岐のパターンを網羅的に洗い出し、1つずつ試しておくことが重要です。

「動かなくなった」経験は、次の試作に活かせる

試作が動かなくなった経験は、ネガティブな出来事のように感じられますが、実際には次の試作に活かせる学びでもあります。どのパターンの原因で動かなくなったか、どう対処して解決できたかを振り返ることで、次に似た問題が起きた際に、より早く対処できるようになります。

トラブルを完全にゼロにすることは、バイブコーディングにおいては現実的ではありません。むしろ、トラブルが起きたときに落ち着いて対処できる経験を積んでいくことが、非エンジニアがバイブコーディングを続けていく上での重要なスキルになります。

トラブルを未然に防ぐための心構え

トラブルが起きてから対処するだけでなく、日頃から次のような心構えを持っておくと、動かなくなる頻度自体を減らせます。

• 変更前の状態を、都度保存する習慣をつける：問題が起きたときにすぐ戻せる安心感があると、試行錯誤にも積極的に取り組めます
• 一度に多くの変更を依頼しない：小さな変更の積み重ねのほうが、問題が起きた際の原因特定が楽になります
• 「動いている」を過信せず、都度確認する：新しい変更を加えるたびに、既存の機能が壊れていないかを簡単に確認する習慣をつけると、問題の早期発見につながります

AIツール別に見られる傾向の違い

バイブコーディングで使うAIツールには複数の種類がありますが、どのツールを使っていても、上記の3つの原因は共通して起こり得ます。ただし、ツールの設計思想によって、どのパターンが起きやすいかには多少の傾向差があります。

チャット形式で1つずつ指示を出しながら進めるタイプのツールでは、原因1（既存機能への影響）が比較的目につきやすい傾向があります。1回の対話ごとに変更範囲が明確なため、「この指示の後から動かなくなった」という切り分けがしやすい一方、対話が長く続くほど、AI側が過去の文脈を保持しきれず、以前の指示と矛盾する変更を加えてしまうことがあります。

自動でファイルを次々に生成・修正していくタイプのツールでは、原因3（積み重ねによる整合性の崩れ）が起きやすい傾向があります。一度に広い範囲を自動で書き換えるため、人が1つずつ確認する余地が少なく、小さな矛盾が発見されにくいまま積み重なっていきやすいためです。

いずれのタイプのツールを使う場合でも、「一度に変更する範囲を意識する」「動いている状態をこまめに保存する」という基本の心構えは共通して有効です。ツールの特性に合わせて、どちらの原因が起きやすいかを意識しておくと、トラブルへの初動が早くなります。

動かなくなったときの実際のやり取りの流れ

ここまでの内容を踏まえて、実際に「動かなくなった」ときにAIとどのようにやり取りを進めていくか、一連の流れを整理してみます。

まず最初に行うのは、状況の記録です。エラーメッセージ、画面の様子、直前に依頼した内容をまとめます。この段階では、まだ原因を推測する必要はありません。事実だけを整理することに集中してください。

次に、記録した内容をそのままAIに伝えます。「〇〇を依頼した後から、△△の症状が出ています。エラーメッセージは『□□』です」という形で、時系列と症状をセットで伝えることがポイントです。

AIからの返答を受けて、提案された対処を1つだけ試します。複数の対処が提案された場合でも、まずは最も可能性が高いとされた1つに絞って試すことが大切です。

対処を試した結果、解決した場合はそこで完了です。解決しなかった場合は、「この対処を試しましたが、まだ同じ症状が出ています」とAIに伝え、次の対処法を検討してもらいます。この際、「試した対処法」を伝え続けることで、AIは同じ提案を繰り返さずに、次の可能性を検討できます。

この一連の流れを、慌てずに1つずつ進めることが、結果的に最短距離での解決につながります。

動かなくなる頻度は、進めるペースによっても変わる

意外と見落とされがちですが、「どのくらいのペースで機能を追加していくか」も、動かなくなる頻度に大きく関わっています。

短期間に多くの機能をまとめて追加しようとすると、1つ1つの変更を確認する時間が取れず、原因1・原因3のどちらのパターンも起きやすくなります。逆に、1つの機能を追加したら必ず動作確認をしてから次に進む、というペースを守ると、問題が起きてもすぐに気づけるため、原因の特定にかかる時間が大幅に短縮されます。

特に、公開期限やリリース予定日が近づいてくると、焦って複数の変更を一度に依頼してしまいがちです。しかし、こうした場面こそ、逆に慎重なペースを保つことが重要です。焦って一度に多くの変更を依頼した結果、思わぬ場所で動かなくなり、結果的にリリースがさらに遅れるという事態は、非エンジニアの試作づくりで頻繁に見られるパターンです。

「急いでいるときほど、変更の範囲を小さく保つ」という原則を、心構えの1つとして持っておくとよいでしょう。

動かなくなったことを記録に残しておく効果

トラブルが解決した後、そのまま忘れてしまうのではなく、簡単な記録を残しておくことにも意味があります。

記録する内容は、次の3点程度で十分です。「いつ、どんな依頼をした後に、どんな症状が出たか」「どの原因のパターンだったか」「どう対処して解決したか」。この3点を、メモ帳やドキュメントに数行書き留めておくだけで、次に似たような症状が出たときに、過去の記録を見返して対処のヒントを得られます。

また、複数の試作を並行して進めている場合や、時間をおいて再び同じ試作に取り組む場合には、こうした記録が特に役立ちます。数週間前にどう対処したかを覚えていないことは珍しくないため、記録があることで、同じ調査を最初からやり直す手間を省けます。

記録を取ることを難しく考える必要はありません。「〇月〇日、フォームに項目を追加した後カレンダーが表示されなくなった。原因1のパターン。前の状態に戻して、範囲を絞って再依頼したら解決」といった簡単なメモで十分です。この積み重ねが、次第に自分自身の「トラブル対処のノウハウ」として蓄積されていきます。

この記事の次に読みたい記事

試作が動かなくなったときの対処法を知っておいたら、次はその先の判断についても知っておくと安心です。あわせて次の記事も参考にしてください。

• AIとの対話を繰り返して試作を改善していく、基本的な進め方
• AIがバグを直せなくなったとき、次にどうすればいいか
• 「もう自分では無理」と判断するタイミングの見極め方