ジェンスパーク(Genspark)はフロントエンドが苦手？Next.js開発で直面した3つの壁と解決策
目次
はじめに：AI開発の鬼門は「見た目」と「メモリ」
バックエンドのロジック構築において、ジェンスパーク(Genspark)は神がかった能力を発揮します。しかし、フロントエンド開発に足を踏み入れた瞬間、状況は一変します。
「ビルドが終わらない」「テストがタイムアウトする」「デザイン崩れを認識できない」。これらは私がコミュニティアプリ開発中に直面した、サンドボックス環境の物理的な限界でした。本記事では、Next.js開発でぶつかった3つの壁と、それをどう乗り越えたかを共有します。
壁1：Next.jsが重すぎてビルドできない
最新のNext.js 15を採用したことは、機能面では正解でしたが、開発環境としては茨の道でした。
サンドボックスのメモリ不足
ジェンスパークのコード実行環境（サンドボックス）は、軽量なスクリプト実行には向いていますが、Node.jsの重厚なビルドプロセスには耐えられません。Next.jsの `npm run build` を実行すると、高確率でメモリ不足（OOM）やタイムアウトで落ちます。
対策：クラウドに逃がす
サンドボックス内でのビルドは諦めましょう。GitHub連携を設定し、Cloudflare Pagesなどの外部ホスティングサービスの「ビルド支援ツール」に任せるのが正解です。ローカル（サンドボックス）ではコードを書くだけにし、重い処理は外部へ委譲します。
壁2：AIは「見た目」を評価できない
AIエージェントの弱点、それは「視覚的なデバッグ能力の低さ」です。
「ボタンの位置がズレている」「スマホで見ると文字がはみ出している」。これらをAIに修正させようとすると、AIはこう言ってきます。
「現在の画面のスクリーンショットを提供してください」
こちらが確認して、スクショを撮って、アップロードして...という手順を踏むなら、自分でCSSを直した方が早い場合すらあります。AIはHTML構造上の論理的なミスは見つけられますが、「デザインとして美しいか」の判断は人間に委ねられます。
壁3：テストツール全滅事件（Rod, Puppeteer...）
「人間が目視確認するのは大変だから、E2Eテストツールで自動化しよう」。そう考えて様々なツールを試しましたが、結果は惨敗でした。
サンドボックスで動かなかったツールたち
- Playwright: メモリ不足で起動不可。
- Selenium: 重すぎてタイムアウト。
- Puppeteer/Splash: 環境依存エラーで安定せず。
- Chromedp: メモリ不足。
- Rod: 唯一惜しかったが、表示が不安定でスクリプトを極限まで小分けにする必要あり。
AIエージェントは「自前のブラウザ機能」でデバッグしようとしますが、実際のChromeアクセスとは挙動が異なるようで、結果がぐちゃぐちゃになることもしばしばありました。
解決策：外部脳（GitHub Actions）を借りる
サンドボックス内でのテストが無理なら、外でやればいい。最終的にたどり着いた答えは「GitHub Actions」でした。
Playwright on GitHub Actions
ジェンスパークからGitHubへコードをプッシュし、GitHub Actions上でPlaywrightを実行させる。これならリソース制限を気にせず、フルスペックのブラウザテストが可能です。
初期フェーズの妥協点
ただし、最初から自動テストを構築しようとすると、テストコード自体のデバッグに時間を取られます。開発初期は「人間が目視でデバッグする」のが、皮肉にも最も効率的です。ある程度動くようになってから、GitHub Actionsによる自動化を導入することをお勧めします。
まとめ：サンドボックスの中で戦うな
ジェンスパークのサンドボックスは優秀ですが、万能ではありません。特にフロントエンド開発においては、「軽量なフレームワーク（Honoなど）を選ぶ」か、Next.jsを使うなら「ビルドとテストは外部で行う」という割り切りが不可欠です。
「AIに全てをやらせる」のではなく、「AIが得意なこと（コード生成）」と「外部ツールが得意なこと（ビルド・テスト）」を使い分ける。これがフロントエンド開発を成功させる秘訣です。
次回予告
次回は「デバッグとデータベースの教訓」について。2万行のコードが生んだ「修正の無限ループ」と、開発後半で判明したDB設計ミスの悲劇。そこから学んだ「絶対にやってはいけないデバッグ方法」を紹介します。