前回：CursorでWebアプリ個人開発メモ Day2：.cursorrulesからProject Rulesへの移行 - dackdive's blog
そろそろアプリ本体の開発に着手する。
※ ちなみに、Day 1 で Remix で環境構築してたけど、あまりにも Remix を知らなすぎるので Next.js に変えた。変える部分はほとんど自分でやった。。。
基本的なレイアウトの作成
基本的には docs/todo.md に記載したタスクの通りに進める。
ん、 todo.md 確認してないな？
ルールに追加しておく。
その上で、今日取り組むべきは「基本的なレイアウトの作成」らしい。
ここは Cursor に身を委ねて素直に従うことにした。
なんかよくわからんけど header.tsx, footer.tsx などが作られていく。
npm run dev で見てる限りまあええやろという感じで特に修正せず。
次のステップとして提案されたのはこれ。
「1. ホームページのコンテンツデザイン」をやってもらって全然構わないんだが、これでもタスクとしては粒度がでかいのでもう少しやることをブレイクダウンしてもらう。
ということで、次は Supabase プロジェクトの作成に。
Supabase プロジェクトの作成
Supabase は初めてなので使い方全く知らないが、本当に全部教えてくれるので鵜呑みにして進める。
よくわからんが Supabase に beers テーブルが1個できる。
モックデータでビール一覧コンポーネントの作成
次のステップも勧めてくれた通りに。
トップページを完成させたいから、バックエンド側の実装の前にUI作っちゃうのはまあわかる。
lucide-react なんているか？と疑いつつ見守る。
ガシガシ実装して一通り完成する。
画面開いたら普通にエラー出てるんでエラーメッセージをまるっと貼り付け。
自分で解決してもらう。
結果としてこのような画面ができあがる。
右上の「Google でログイン」はこの作業の後に実装したものなのでこの日時点では含まれていない。
とりあえず期待した通りに画像がタイル上に並ぶトップ画面はできてそう。
マウスオーバーでビール名が出るのとか、スマホでしか使うつもりないからいらない機能だなこれ。
前回同様作業ログを残して終わり。
今日の学び
ブログ書くのが遅くなってあんまり覚えてないんだけど、大きなつまりどころもなく実装が進んでいった。
このスピードで実装されていくと、もはや中のコードがきれいに書けてるかとかを一々チェックしようという気持ちはなくなる。
これは Cursor での開発に慣れるのが目的なので、そういう意味ではもっと Cursor に大きめのタスクを渡し、数分は放置するぐらいのことをやってみたい。
そうすると、Cursor が指示されたタスクを完了できたのか、また迷走して自分では抜け出せない状態に陥っていないのか、を Cursor 自身がチェックできる仕組みを担保したい。
先日読んだ
AIをシステム開発に活かすコツ、全部書く｜kmagai
では、E2Eテストを勧めていた。
なるほど、次回E2Eテストの環境構築をお願いしてもいいかもしれない。
作業ログ
https://github.com/zaki-yama/beer-log/blob/main/docs/work-logs/2025-02-23.md
にはこんなことを書いていた。
### 良かった点 - Supabaseのセットアップは手順が明確で、スムーズに実装できた。特にデータベース設計からRLSポリシーの設定まで、一連の流れを効率的に進めることができた - トップページのUIは期待通りの実装ができた。画像のタイル状レイアウトとレスポンシブ対応により、Instagramライクな見た目を実現できた（ただしホバーエフェクトは必要性を再検討する余地あり） ### 改善点・課題 - フレームワークの移行（Remix → Next.js）は自動化できず、手作業での移行となった。ツールの限界を理解し、適切なアプローチを選択する必要がある - AIとの協業において、タスクの粒度とチェックポイントの設定が課題。現状では細かい作業単位での確認が必要で、長時間の自律的な作業には至っていない - 気に入らない粒度で勝手にコミットしてほしくないから .cursorrules にルールとして明記したけど、毎回聞かれるのも鬱陶しい。あとちょいちょい約束が守られない - 今後は、タスクの依頼方法や作業の区切りの付け方について、より効率的な方法を模索していく必要がある ### AIアシスタントからの所感 - タスクの分割と段階的な実装アプローチが効果的だった。特にデータベース設計から始めて、UIの実装へと進む流れは、後戻りを最小限に抑えることができた - コミット前の確認プロセスの導入により、変更の意図と内容を明確に共有できるようになった。これは協業の質を高める重要な改善だった - 一方で、作業の区切りをより大きな単位で提案できる可能性がある。例えば「UIコンポーネントの実装」をまとめて1つのタスクとして提案し、途中経過の報告という形を取ることで、より効率的な進め方ができるかもしれない
