📅 2026年1月30日 📁 開発実績 👀 0 views 🏷️ #ジェンスパーク #AI開発 #デバッグ #データベース

AI開発の落とし穴：2万行のコードが生んだ「修正の無限ループ」とデータベースの悲劇

目次

はじめに：開発後半、AIは「壊し屋」になる

「よし、基本機能はできた。あとはバグを取るだけだ」

そう思った瞬間から、本当の地獄が始まりました。22,500行まで膨れ上がったコードに対し、ジェンスパーク(Genspark)を使って安易なバグ修正を行うと、1つ直せば2つ壊れる「修正の無限ループ」に突入します。

この記事では、開発後半で私が直面したデバッグの失敗と、そこから編み出した「AIを制御下に置くためのデバッグ・フロー」を共有します。

教訓1：バグ修正の無限ループ（モグラ叩き）

開発初期のデバッグは簡単です。エラーログをAIに投げれば、即座に修正してくれます。しかし、コードが複雑化した後半で同じことをやると大惨事になります。

失敗パターン：「これ直して」の連続

AIは「目の前のエラー」を消すことには長けていますが、「修正による副作用（他の機能への影響）」を完璧に予測できるわけではありません。
Aを直すとBが動かなくなり、Bを直すとCがバグり、Cを直すとAがまた壊れる...。いつの間にか修正コード同士がバッティングし、コードはスパゲッティ化します。

解決策：「デバッグリスト」を作らせて指揮する

この泥沼から脱出するために、私はAIへの指示方法を根本から変えました。「直させる」のではなく、まず「整理させる」のです。

黄金のデバッグ・フロー

  1. リスト作成: 現在発生している不具合をAIに列挙させ、「デバッグリスト」を作成させる。
  2. ドキュメント化: リストに従って、それぞれの原因と修正方針をまとめた「修正計画ドキュメント」を書かせる。
  3. 品質チェック: そのドキュメントを別の視点（品質管理プロンプト）でチェックさせ、修正内容にバッティングや抜け漏れがないか確認させる。
  4. 実装: 全体の整合性が取れて初めて、コード修正を実行させる。

✅ 効果：手戻りの激減

「不具合が多そうだな」と思ったら、手を止めてまずリストを作らせる。これだけで、AIは全体像を再認識し、矛盾のない修正プランを提示してくれます。急がば回れ、はAI開発でも真理でした。

教訓2：データベースの悲劇（リファクタリング地獄）

もう一つの大きな失敗は、データベース設計です。

開発後半になって「あ、この機能を実現するにはDB構造を変えないといけない」という事態が発生しました。AIにリファクタリング（構造変更）を依頼しましたが、これが悪夢の始まりでした。

DBの型定義、APIのレスポンス型、フロントエンドの受け取り処理...。たった一つのカラム変更が、アプリ全体に波及し、大量の型エラー（Type Error）を吐き出しました。

⚠️ 重要：初めから「拡張性」を持たせる

AI任せにすると「今の要件を満たす最小限のDB」を作りがちです。「将来的に通知機能が入るかも」「DM機能が増えるかも」といった拡張性は、人間が最初から指示して盛り込んでおく必要があります。

教訓3：「構想漏れ」はAIには見えない

開発も大詰めになって、「あれ？この機能がないとアプリとして成立しなくない？」という機能漏れに気づくことがありました。

AIは仕様書に忠実です。仕様書に書いてなければ、それがどんなに一般的なSNSに必要な機能であっても、作りません。

「よく読まないとだめだね」

これは自戒の念を込めた言葉です。AIが書いた要件定義書を、人間が「顧客目線」で本気で読み込み、抜け漏れを指摘する。このプロセスをサボると、開発後半で手痛いしっぺ返しを食らいます。

まとめ：AIに使われるな、AIを使え

AI開発において、バグ修正は「モグラ叩き」になりがちです。しかし、指揮者である人間が「一旦ストップ。リストを作って」と号令をかけることで、AIは優秀なエンジニアに戻ります。

今回の一連の開発（記事57〜59）を通じて、AI開発の真髄は「コードを書かせること」ではなく、「AIの思考プロセスをドキュメント化させ、管理すること」にあると確信しました。

これからジェンスパークでアプリ開発に挑む皆さんが、私と同じ轍を踏まないことを祈っています。

あわせて読みたい

🎉 シリーズ完結

全3回にわたる「SNSアプリ開発奮闘記」をお読みいただきありがとうございました。このブログでは引き続き、ジェンスパークを活用したAI開発の最新ノウハウを発信していきます。