※この本文はGeminiに書かせています。記載内容はおおむね事実と思われますが、誤りが含まれている可能性が大きいです。
前回までのあらすじ
GitHubリポジトリをGeminiに連携させ、プロジェクトのディレクトリ構造や型定義を前提としたコード生成が可能になった。これにより、ブログ詳細画面（ダッシュボード）の基礎と、Zod/Drizzleを用いた型安全なデータ取得エンドポイントの実装を完了した。
MT形式ファイルのインポート実装
過去記事の資産を活用するため、Movable Type（MT）形式のテキストファイルをアップロードし、パースしてデータベースに一括登録する機能を実装した。
1. パーサーの実装: server/utils に、MT形式特有のセパレータ（-------- や -----）を解析し、記事タイトルや本文、作成日時を抽出するロジックを構築。
2. 一括登録API: readMultipartFormData を用いてファイルを受け取り、Drizzleのトランザクション処理を用いて posts テーブルへ一括保存するエンドポイントを作成。
3. UIの実装: UButton と隠し input 要素を組み合わせ、ファイル選択ダイアログを呼び出す操作系を構築した。
直面した課題：APIの使い分けとUIの整合性
開発の過程で、Nuxt特有のデータ取得手法における混乱が生じた。
* useFetch と $fetch の混同: ページ初期表示用の useFetch と、イベント駆動で動作する $fetch は役割が異なる。インポート完了後に画面を更新するためには、useFetch が提供する refresh 関数を適切に呼び出す必要があった。コピペで動作することもあるが、内部的な挙動（リアクティビティの有無など）を理解していないと、意図した画面更新が行われないケースに直面した。
* UI実装の揺れ: 長時間のチャットによるコンテキストの引き継ぎの影響か、Nuxt UI v4の仕様（スロット名の変更など）に適合しない古い形式のコードが提案される場面があった。
AIによるパーサー実装の恩恵
特筆すべき点として、MT形式のパーサー実装が極めて容易であったことが挙げられる。開発者はMT形式の具体的な内部仕様を詳細に把握していなかったが、Geminiに「MT形式をパースしてほしい」と指示を出すだけで、セパレータや各項目の抽出ロジックが即座に生成された。
細かい不具合が内在している可能性はあるが、少なくとも現状のテストデータにおいては問題なく動作している。仕様を深く調べ学習するコストをスキップして、実用的なロジックを手にできる点は、AI駆動開発の大きな強みであると感じた。
まとめ
GitHub連携により開発スピードは加速したが、AIが提案する「似て非なるAPI」の使い分けや、UIライブラリのバージョン差異については、開発者がドキュメントを確認し、内容を正しく理解した上で採否を判断する必要がある。一方で、フォーマット解析のようなドメイン知識が必要な実装においては、AIの提案が開発コストを大幅に削減してくれることを再認識した。
