#378 Cursorを使ってプロダクトの設計からMVPの実装完了までの全貌を公開する
2025/8/3 ·
-
この番組はエンジニアの成長は楽しい学びからをモットーに我々が日々学んだことをワイワイアウトプットするラジオでございますございますございますはいということで今日はですね今話題のAIエージェントコーディングツール今話題じゃないですね一昔前に話題だった
-
ずっとよAIコーディングツールカーソルを使い倒してみたのコーナーでございますカーソルなんかちょっと前の情報で恐縮なんですけどクラウドコードがめっちゃ盛り上がった時に一瞬盛り下がったけど取り返してきたみたいなイメージですねそうなの?
-
そうなんだ僕の観測範囲だと未だに取り返せてないんですけど勢いはまだ1位にはいかないけど機能的にはだいぶ取り返したイメージですけどねそうなんだちょっと僕カーソル使ってるのも理由がありましてやっぱ体験好きなんですよね僕クロードコードとかジェミニCLIとかってさコード確定したらその段階でコード書き換えられてるじゃないですか
-
そうですねはいでGit使えば確かにリセットできるんですけどそうするとなんか変なコミットしなきゃいけなくなるなってなっててそこがちょっとこうなんて言うんでしょうモヤモヤを抱えてたんですよ一方カーソルって書き換えた内容を受け入れるかどうかみたいなのって
-
なんかGitとはまた別の単位で動いてるじゃないですかそうなんですねそうGitとは関係なくカーソルの中で持ってるメモリであの受け入れるか拒否するかみたいなやつ決まるんでなるほど結構僕はあのカーソルを使った方がなんかこう体験はいいなと思ってるんですようんうんなんかローカルでうん綺麗なコミット作りやすい
-
っていうイメージですかねそうねコミットが綺麗かって言われるとちょっとこれから見せるものを見てドン引きしちゃうんじゃないかなと思うんですけどいやいやいや今日はちょっとスペシャルバージョンということでちょっと仕事の話になるんですけどちょうど7月からですね3週間ちょいかけて今プロジェクトというかプロダクト1個作ってまして1人で1人です
-
AIを使い倒して作ろうのコーナーだったんですけど完全にそれ使っていく中でまず学びがたくさんありましたとソースコードある程度見せても大丈夫でしょうということであんまりないんですけど実際のソースコードをお見せしながらいろいろこういう風に使ってたよっていうのを説明する回となっておりますありがたいこれ今オンラインコミュニティの方で
-
ハードル開いてオンライン公開収録的に画面共有しながらやってるんですけどポッドキャスト側では音声だけお届けするみたいなそうなります状態になりますねアーカイブも別に残らないですね残しちゃダメですさすがにっていうのでここから本編なんですけど実際にアプリケーションを作っていくってなった時にどっから始めたいとかあります?普段ってどう使ってます?
-
カーソルの話ですかそれともアプリ開発の話ですかアプリ開発の話ですねじゃあなんか新規でアプリ作るよってなったらなんかどっから始めますかじゅんぺいくん新規で作ったことないもしじゃあここから急に作んなきゃいけないってなったらまず何しますかまずは見た目を作るなるほど見た目を作るどんなリードでやめとこうやめとこうやめとこう
-
やめとくらしいですフロント作るのはやめときますフロントはやめとくかどっから作るんだろうな僕だったらちょっとすみませんのりさんの質問の後ろから始まってるかもしれないんですけど何をどうするプロダクトにするかをまず決めて何を解決するなのかみたいなで
-
何を解決するためにどんなユーザーストーリーになるかを整理しますなるほどねだから要は設計やるってことですよね細かい部分のいいですね僕もまず設計からやるんですよ今回作ったアプリケーションっていうのがある程度こうしていきたいというか機能の概要はざっくり決まってたんですね一方で細かい設計とかは結構こっちが自由だったというか
-
開発者僕しかいないんで僕が決めていいっていうそういうスタンスだったんですよなので決まってる機能だけまずジェミニを使って設計書を作ってもらいましたその時にどういう指示を出したかっていうと開発の進め方というか順番順序どういう風にこういう機能を作っていきたいんだけどどういう風な順序で作っていったらいいですかっていうのをまず依頼したんですよ
-
相談か順序っていうのは開発の順番の話ですかそれともなんかもっと広いえっとね開発の順番 あと機能の追加順って感じじゃないうーん実装順なんですねあそうそうでなんでそうしたかっていうとあの一気になんだろう0100で作らせるの無理じゃないですかまず無理まず無理
-
AIって多分コンテキストの量の制限があってあんまり大きい量一気にやらせるとうまく動かないなっていう感覚があるんでまずは分割できる単位で分割したいとだけどこっちで分割の単位を考えるのはちょっとめんどくさかったのでそこの部分プラスアーキテクチャの相談をまずさせてもらいましたでLLMに対してまずアプリこういうものですよっていう説明を送ったんですよ
-
このアプリケーションはこういうユーザーが使えますよっていうのも説明しますとそれぞれのユーザーごとにこういう機能がありますっていうのを質問ですごめんなさい機能は全部送るんですか最初に全部送りますなるほど全部送った上でそれを分割してもらうっていう依頼にあげましたねあとはこっちで考えてるアーキテクチャーも相談してます
-
こっちで考えてるアーキテクチャも相談してますはいあのなんて言うんでしょうじゃあアーキテクチャ作るよってなった時になんか技術がこう制約かかったら嫌じゃないですか急にJavaで作ってくださいって言われても僕困っちゃうんではい僕は主にLarabelとかReactあたりが触ったことあるんで今回スピード大事だったんでそこはちょっと外したくないなっていうのでやったんですねバックエンドはLarabelでどっちもかLarabelで作りますみたいなそうそうそうでフロント側ReactにしてあとInertia.jsって聞いたことあります?
-
知らないこれあのララベルとリアクトって本来別々なんで多分ララベルでAPI作ってリアクトでフロント作ってSSRやるかCSRでやるかみたいなことになると思うんですけどこのイナーシャジエースっていうのを使うとあたかもリアクトがララベルの中の一個のパーツのように動くというかレイルズとかでもやられるようなやつレイルズとかでも
-
レイルズの中でUI書くのレイルズわかんねーそんなイメージだと思いましたっていうのを使ってブリッジさせて一個のレポモノレポでも作っていきたいですよっていうのだけ決めて他は全部ぶん投げみるみたいな感じで依頼投げますとそしたらもう向こうからじゃあこういう順で実装したらいいですねみたいな感じでフェーズ分けのあの
-
依頼がかっ依頼じゃねーなあの答え帰ってくるんですよ はいでまずはなんかこう mvp 作ってみたいな回答帰ってきたんでそれを一旦読みましたと その機能に対してそのフェーズ分けと後アーキテクチャーの高編と帰ってきたんですねうんなんでそれをもうあのざっと読んでそんなに問題なかったんで ジェミニでやってたんでグーグルのドキュメントに次出力してもらいましたとはい
-
今回出力してもらった開発の計画書みたいなやつが基本的にずっとベースになって機能追加の時も更新していくためのドキュメントにするみたいな使い方しましたねジェミニー詳しくないんですけどジェミニーは吉田にGoogleドキュメントの中身を見ながら設計とかをしつつ更新があったらGoogleドキュメントを更新しつつみたいなことをやってくれるんですねできますいろいろ方法があって
-
例えば今これチャットしてジェミニューとチャットしてたと思うんですけどそのジェミニューのチャット画面で都度ドキュメントを出力するってこともできますし逆にファイル追加でドキュメントを見せるってことも可能ですねドライブから追加ってのができるんでそのまま元のドライブを追加してみたいなことができますねなるほどここまで大丈夫そうですかはい大丈夫そうですで
-
必要に応じて、ジェミニは結構そのドキュメントをどんどん更新していくみたいなことできるんですよ。 なので、細かい点とかはどんどん後からチャットで追加していって、どんどんそのドキュメントをブラッシュアップしていくみたいな感じで作りました。さっきフェーズ分けしてもらったんで、次はそのフェーズごとのカーソルにぶん投げるようなドキュメントを作ってもらいました。
-
でコピペしてしやすいように普通にマークダウンのプレインテキストでやってくれって言ってフェーズ1こういう機能を実装していきますよみたいなマークダウンを出力してもらいますとでここまで来てやっと準備の段階終了ですねまだここまでカーソル登場してないっていうね結構しっかりLLM使ってドキュメント作るのを結構意識してますねここまでで出来上がったのはカーソルに投げる用の
-
フロンプとあとは要件というか機能の整理ができたってことですかねここまで作りたい機能とそれをどういうフェーズ分けで実装していけばいいかっていう全体のWBSに近いかなあとはそのフェーズ1用の指示書ができたって感じここからやっとねカーソルを使っていきます一旦ですねまずちょっと画面の説明しますよ
-
どんな感じでやってるかっていうとへーおもろいやいいやこれはもうそのまま説明しちゃおう最初このフェーズ1から4のマークダウンだけ作ってたんですよ他にもいっぱい今マークダウンファイル写ってると思うんですけどこれはその後の機能追加用に作った指示書なんで最初はなかったっすでフェーズ1実装するよってなった時にまずデータベースの定義書
-
マーメイド記法のER図とあとはテーブル定義書かなのドキュメントプラス今回の機能こういう風に作っていきますよっていうさっきジェミニーが出したやつデータベースもジェミニーに出してもらったんですけどこいつを使いますとこれをマークダウン置く用のディレクトリに配置しちゃってそこでカーソルに指示出しますとまずはこのデータベースとあとはこの概要書を元に機能を
-
バンバン実装してってくださいみたいな依頼投げておしまいこの段階だとまだリポジトリは作っていや作ってるかな空のままリポジトリ作ってますねでそのリポジトリの中にドキュメント追加してったみたいな状態ですでプラス開発環境はまた別で作りましたちょっとどっかのローカル開発の環境というかそこはねあの
-
シンプルにカーソルに投げまくって作ったね 依頼をちょっとあんま細かい設計とかせずに作りましたフェーズ1 1 2 3 4を書いてフェーズ1から始まるフェーズ1のプレフィックスが付いているやつ実装してちょって言ったってことですかそうです カーソルってコンテキスト渡せるんでファイル
-
それでもう明確に指示出しましたねアドコンテキストでそうそうそうそうアットマークつけて例えばフェーズ1の概要を参照して機能を押してくださいみたいなっていう感じで依頼出しましたねデータベースの定義はこっちにありますよみたいななるほどフェーズ1db.mdに入ってますよっていう感じで依頼出してますねなるほど
-
でここでポイントが1個ありますまずちょっとカーソルの説明した方がいいかもなカーソルってどんなもんかっていうとVS Codeの中にAIチャットが組み込まれてますよっていうツールなんですけどVS Codeからフォークしてるんでカーソルって別のアプリケーションにはなってますがベースはVS Codeですとでそこにチャット欄がついててAIがエージェントとして勝手にコード書いてくれますよっていうそういう機能がついてますと
-
で今このエージェント2パターンあってチャット欄で動くパターンとあとバックグラウンドエージェントっていうなんか2つあるんですよバックグラウンドエージェントって方はPC閉じてても勝手に作ってくれてるみたいな寝てても開発が進むみたいなそういう機能ですね一方このチャットのやつはカーソル開いてないと動かないで
-
1個ポイントとしては僕はまだバックグラウンドエージェントよりはチャット欄のやつの方が性能いいなと思ってますモデル違うんですか?いやモデル同じなんならバックグラウンドエージェントはちょっとレベル高いモデルじゃないと動かないですねなんでそうなるかっていうとバックグラウンドエージェントってコンテナ多分裏で起動してそこでこういろいろ作ってるんですよなんですけど
-
そのコンテナをちょっと僕調整の仕方分かんなくてコマンド実行できないんですよねもしかしたらそこのコンテナ調整できるのかもしれないんですけど結果的にララベルとかって例えばファイル生成するコマンドとかテスト実行とかいろいろコマンド入ってるんですけどそのコマンドが実行できないんで当てずっぽうで書いたみたいなコードが出てくる時あるんですよ例えばマイグレーションファイルで顕著に出るんですけどマイグレーションファイルって
-
ララベルのやつって日付がファイルの先頭についててその日付が古い順に実行されるんですよなんですけどコマンド実行できないからまず適当にそれっぽい名前のファイルを作るんですけどそれが過去のマイグレーションファイルより前の日付になっちゃうみたいな恐ろしいですねそういうこととかが起きて
-
そこら辺が当てずっぽになったりとかあとテストコード書いてくれみたいな感じで作ってもテストコード実行できないからエラー超残ったまま提出されたりしますねなるほどそれっぽいのをなんとなく書いてできたよって言ってくるんですねそうそうそう一方このチャット欄だとコマンド実行できるんで実行後の結果を元にちゃんと修正までやってくれてる状態になるというかっていう意味で僕はチャット欄の方がなんか精度高いなって感じましたね
-
なるほどねざっくりそんなカーソルの機能があって僕はチャット欄で指示して実装してもらいました実装当初はバックグラウンドエージェントも使いながらだったんですけど最近はもう全部フォアグラウンドでやってますねあとここでもう一個ポイントあってカーソルで裏で動くモデル選べるんですよはい
-
ここでいろいろクロードのForSonnettとかGemini 2.5 ProとかGPT 4.1とかいろいろ選べるんですけどこことかのモデル選びとかは結構ちゃんとやりましたね使い分けなんですけど例えばこのフェーズの実装手順書って結構でかいんですよ実装量というか機能の量がこういうでかいのを実装させるときはもう意図的にクロードForSonnettみたいな結構ハイレベルなモデルかつちょっと
-
オーパスだとコスト高すぎるんで一旦僕はソネットでやってきましたね一方実装がざっくり完了した後の修正指示みたいなやつとかはあんまコストかけなくても意外とちゃんと指示すればやってくれるんでそれはもう全部オートでやってましたねオートってどうやって選ばれるんですかね
-
裏がオートになってるときに裏がどう選ばれるかってこと?そうそうそうそうそれ分かったらカーソル作れちゃうなでもそうですよねさっきマウスオーバーしたときに出てた文章もう一回見せてくださいバランスとクオリティとスピードをリコメンドしてくださいクオリティとスピードを見ていい感じにモデルをチョイスするよって言ってますね
-
へーとしか言えないなこれだと月額料金内で使えると追加課金じゃないやつでやってくれるってことですかそうソネットはね一定量以上使うと有料になるんですよねそういうことなんですね今回のアプリケーション作るにあたって結構吹き飛びましたねへー結構ではないか上限決めてるんでそんな飛んでないんですけど
-
まあまあでもでもちなみに金額感言えたりするんですかオーバーしてる時だと今このフェーズ1オーバービューとか実装するのに3ドルかかるぐらいのイメージだったと思うまあ10両課金クロードぐらいか多分そうねだからえーとなんだろう本当にこうMVPのアプリケーション作るってなったら多分3ドルから5ドルぐらいかかるんじゃないかなっていう感じですねまあ安いもんですねまあまあまあワンコインだからワンコインではないか
-
アメリカの金銭事情知らないか1ドル札だった気がするな5ペーパーでいけるかもって感じかな最初にフェーズ分けしたやつはこれの繰り返しで作っていきましたね指示書はこんな感じで基本的にはLLMにざっくり概要を作らせて細かいとこだけ修正指示こっちで出してその指示書を元にカーソル動かすっていう流れで繰り返してやってきましたと
-
一方そことはまた別でカーソルにいい動きをしてもらうためのドキュメントも必要なんですよそっちはですねドットカーソルスラルールズっていう決まったフォルダがあってそこに置かなきゃいけないんですよ
-
そことかは僕めっちゃメンテナンスしまくりましたねなんかそのLLM使ってコーディングするにあたってめっちゃ変わったなって思ったポイントが実装してテストしてみたいなこのループだったのが実装して気に食わなかったところをドキュメントで修正するような指示をメンテナンスしていくみたいなフェーズが入ってみたいなのがねちょっと変わったなって思ってましたねなるほどその結果今ルール図がね
-
そうですよねめっちゃありますよね20近くある20ぐらいあると思うぐらいありますよね10以上あるな17個か17個ありますねそんなあったんですねこれは基本的に気になった点をずっと書きまくったって感じなんですけど例えばバックエンドの実装
-
が一番メンテナンスちゃんとやっててフロントクソ適当にやってるんですよ僕フロントのことよく分かんないのでバックエンドのところで見ていくとまずアーキテクチャこういう原則に従いますよみたいなルール書いてたりとかあとは各ディレクトリこういう役割を作ってますよみたいなそのディレクトリマップ書いて実装ガイドラインでレイヤーごとのルールみたいなやつ書いてるんですねざっくり例えばコントローラーこういう風に書いてねとか
-
モデルこういう風に書いてねとか認証認可こういう風にやってねみたいなあと既存の機能ぶっ壊さないとかこれめっちゃ大事でしたね確かに大事そう結構ねカジュアルにぶっ壊されるんで既存機能そういう基本ルールプラス今回ちょっと工夫したのはドキュメントをリンクさせていくみたいなところをすごい意識してて例えばコントローラーとかだったら詳細な実装ルールはcontrollerimplementation.mdcを参照してくださいみたいな
-
細かいルール知りたかったらそれを追加のドキュメントで読めるようにしてるって感じですねそこで実際のコードのサンプルとかコントローラー内でのディレクトリ分けのルールとかあとはコントローラーに書くべき処理とか逆に書いちゃいけない処理とかこれないと結構ファットコントローラー生まれやすいんですよね余裕でのモデル使ってくるコントローラー内で
-
なんでそういうのをやっちゃいけないこととか書いてあと基本的にコンストラクターインジェクション使ってくださいねとかなんか気になることを書きまくった結果こうなってると質問いいですかこのドキュメントってのりさんが自分で書いたところどのぐらいあるんですかほぼないじゃあチャットでこういうこと書いてねって言って書いてもらうそう
-
あとはファイルを分けてるのはなぜですかこれはですねルール書いてもちゃんと読み込まれてないなって思うことがめっちゃあったんですよいろいろ仮説を立てていった結果やっぱこれ文章長くなりすぎたら今度は関係ないコンテキストに汚染されてあんまちゃんと動かないんじゃないかってなって必要に応じてリンクをたどった時に適切な量のドキュメントを読み込めるようにしたいっていう要望があったんですね
-
僕の中でどっからって思って今こういう風に細かく分けちゃって実装するときにバックエンドの実装ルールはこちらを確認して関係あるファイルを触るときにそれぞれリンクたどってドキュメントを集めるようにしてくださいみたいな指示を出したことによって
-
コントローラーしか使わない処理とかあるじゃないですか修正の時とかだったらその時はコントローラーだけのドキュメントを読み込むし他も関係あるなら他の関係用のドキュメントも読み込むしっていうので分量を最適化できるようにしたかったっていうのがありますね
-
なるほど指示出す時にコントローラでこういう機能を実装しますで、controllerimplementation.mdcを読み込んでくださいみたいな感じで指示を出しているベースはこのLarabelBackendってやつを読み込ませるようにしててで、ここからさらにリンクたどれるようになってるんでレイヤーごとに必要なドキュメントがあったらそれを読み込むようにしてくださいっていうプロンプト投げてましたね都度?都度なるほど
-
それもこの中に書けばいいんじゃないって今思ったけどそうそうそうそうそれもでもなんかいけそうですね確かにそっちの方が手間減りそう読んでくれそうだからどっちみちって感じでしたねなんでルールズディレクトリのファイルとかはあのなんかこれルールもどのレベルで適用させるかみたいなやつあるんですよ
-
いつも適用するやつとエージェントがいい感じにやってくれるやつと特定のファイルこれがいいじゃん今この機能初めて知ったわマニュアルで指定するみたいなでも今思うとアプライトスペシフィックファイルズで
-
特定のディレクトリの時に特定の関係あるドキュメント読ませるとかできそうだなこれやったらそうですね確かにディレクトリで分かれてるでしょうしねそのレイヤーがでも自動読み込ませでできてんだったらそれでいい気しますけどね今後増えた時にめんどくさそうアプライをそのエージェントに任せちゃってでも
-
プロンプトでも支持するみたいなやり方してるかなうんうんうんなんか忘れてた時に意図せず適用されてうざいことありそうですねそうそうそうねそれはありそうだどういう時に使うんだろう全部適用させるのってで全部適用系は僕コマンドとかはね全部適用にしてますねあーなるほどなんかねコマンド用のMDCも作っててルール作っててこれ何かっていうとあの
-
基本的にはコマンドはコンテナの中で実行してくれよっていうドキュメントなんですよ本当だローカルでやるなって書いてるそうこれ何回もねローカルのNPMを起動しやがってねやりそうってかだってローカルにファイルありますもんねそうしつこく依頼しまくってこれを書いてこれをAlways Applyにしてやっともうほぼミスんなくなったですねへーおもろー基本的には全コマンドも裏列してうん
-
絶対にホストマシンで直接コマンドを実行すんなって書いてここに怒りが見えますよねノリさんの怒りの分というかノリさんがくそーってなった分のコマンドが書いてるんですねこれを使って基本的なコマンドは全部コンテナ内でやるようになったというのもありますね優しい言葉で語りかけてくださいとか書いてないですか書いてないな口調とかね口調こだわりないからね見ないからあとこのワークフローも
-
オールウェイズにしてたわ開発の手順例えば新機能実装するときの開発フローみたいな感じでまずマイグレーション作ってモデル作ってコントローラー作ってルート定義してフロントエンドでコンポーネント実装してテスト実装してドキュメント更新してくださいねみたいなどこまでやるかっていうワークフローを決めてるみたいなマジで文章火力というか言語火力求められるなでもほぼLLMやってくれるからねそれ
-
でもなんかこれがこれの言語化が必要だって思うのは人間じゃないですかまあ確かにねなんでこれを使って書いてるとこれあのペストでテストを実装ってあるんですけどペストってPHPのテスティングツールなんですねPHPユニットの方が有名なんですよはい聞く聞くそっちの方が聞くなんですけど最近だとペストが結構使いやすいよねみたいな感じでこう
-
割とシェア増えてきてるみたいな個人的にもペストの方が好きだったんでこれで書いてほしいんですけどなんかLLMって過去にあったたくさん情報量あるやつに引っ張られるじゃないですかそうですねしょっちゅうPHPユニットの書き方をしてくることが多くて結構ペストに書かせるようにいろんな工夫をしてますねテスティング.MDCというテスト用のルールとかでも絶対ペストを使ってくれみたいな
-
これでやってくれるんですかそれで今はだいたいミスんないですねへーすごいだねドキュメントだけでこれ何千行あるんだろうね結構あると思いますねルールのかなこれで一旦実装全部終わってこれでだいたい最初のMVP作るまでのフェーズ終わったんですよで次にクライアントに見せながら追加開発していく必要があるんで
-
追加の時のポイントはそんなに多くないんですけど
#378 Cursorを使ってプロダクトの設計からMVPの実装完了までの全貌を公開する