Geminiを用いたAI駆動開発(2)

※この本文はGeminiに書かせています。記載内容はおおむね事実と思われますが、誤りが含まれている可能性が大きいです。

前回までのあらすじ

前回は、最小構成のバックエンド基盤（SQLite / Drizzle ORM）の構築と、シンプルなユーザー登録APIの実装まで完了しました。しかし、システムとしてはまだ「中身（ロジック）」があるだけで、ユーザーが触れるUI/UXは真っ白な画面のままでした。

本文：AIと最新スタックの「ズレ」を乗りこなす

第2回となる今回は、フロントエンドの実装に着手しました。しかし、ここでAI駆動開発ならではの「認識の齟齬」を解消していくプロセスが重要なテーマとなりました。

1. 技術スタックの再認識：Nuxt 3 か Nuxt 4 か

当初、私は情報の多い「Nuxt 3」での開発を想定して対話を進めていました。しかし、実際にプロジェクトの package.json を確認したところ、最新の Nuxt 4 および Nuxt UI v3 が導入されていることが判明しました。

AI（Gemini）は当初 Nuxt 3 の知識ベースで回答を生成していましたが、私が現在の構成を提示したことで、AI側も即座に認識を修正。「では、最先端の Nuxt 4 構成で行きましょう！」と、開発の舵を大きく切る決断を二人三脚で行いました。これにより、app/ ディレクトリにフロントエンドを集約するモダンな構造への移行が決まりました。

2. 「CSSが当たらない」問題と対話による解決

最新スタックへ移行した直後、デザインが全く適用されず、モーダルも動かないという壁にぶつかりました。AIが提示した初期のコードが、まだ旧バージョンの記法に基づいていたためです。

ここで重要だったのは、発生している「事実」をAIにフィードバックし続けることでした。

「レイアウトは表示されるが、白背景に黒文字のままでCSSが効いていない」
「TypeScriptの型定義エラーが出ている」

これらの具体的な状況を伝えた結果、AIは「Nuxt UI v3 では @import によるCSS読み込みの明示や、UApp コンポーネントでのラップが必須である」という正解にたどり着くことができました。

3. ユーザー体験（UX）の基礎固め

システムの根幹となる「ユーザー登録」と「ログイン」を、以下の構成で実装しました。

Cookieによる状態管理: useCookie を活用し、リロードしてもユーザー情報を保持。
ルーティングの分離: ランディングページ（/）と、ログイン後のメイン画面（/home）を物理的に分離。
ページガード: ログイン状態に応じて / と /home を適切に行き来させる自動遷移ロジックの実装。

AIは、フロントエンドの画面遷移から、それに対応するバックエンドの動的APIまで、一貫性のあるコードを提示してくれました。

AI駆動開発を成功させるための学び

今回の作業を通じて得られた、AI（Gemini）とうまく開発を進めるコツは以下の3点です。

環境情報は「事実」で語る: package.json などの構成情報を直接共有することで、AIの推測によるミスを最小限に抑えられる。
不具合は「見た目」を説明する: 「動きません」ではなく「モーダルは出るが背景が暗くならない」のように具体的に伝えることで、AIが原因を特定しやすくなる。
柔軟な軌道修正: AIとの対話の中で、当初の予定よりも適切な技術（今回はNuxt 4）が見つかったなら、その流れに乗ってスタックを更新する柔軟性が開発を加速させる。