[AI個人開発] Cursorで自動化レバレッジを最大化するためにしたこと10と、Cursor Composer メインでも、Claude 3.5 SonnetならAI開発自動化が進む話の続きです。
日々進歩しているので、このやり方が通用する時期は短いと思います。
ただし、基本的な考え方は今後ツールが変わっても有効だと考えています。
なお、Cursor月額 $20 に収めなくても構わない方は、API叩きまくるRooへ寄せても良いと思います。
メインをCursorに置く
Yoloモードは、Roo Codeに比べると処理出来る範囲が限られています。
Computer use がコマンドライン前提になっているためです。
一方、それはそれで安心感があって、触る範囲に予測が付くメリットにも繋がります。
AI開発への期待は完全自動化ですが、実際は内部的にコードを書くわけなので、うまくコードベースに反映することを中心に考えます。
そうすると、Cursorが月額$20で（Slowを許容しながら）Claude-3.5-sonnetを使える点で優位になります。最近DeepSeekが良いらしいため、API叩く上では追加検証してくことになりますが、月額固定である良さはCursorにあります。
Roo Codeに行ってもらうこと
最近Geminiの無料開放枠が大きくなったこと、従量で比べても安いことから、Rooから使う際にはGeminiを選択します。
ここでClaude精度を求めてはいけません。
では、どういった点でRooの良さを引き出すか？
- 全てを網羅的に自動で完成させる
- 持っているコンテキスト量が増えても処理ができる
この2点を活かすために、仕様書作成やQA観点のチェック作業をRooへ寄せます。
Roo → Cursor → Roo という流れです。
Rooに任せる範囲
Roo が用いるモデルとバージョン
Roo のAPIにGemeniを設定します。バージョンは好きなもので良いと思いますが、制約の小さい(tokenサイズの大きい、コール上限数が大きい)モデルが良いと思います。
直近では gemini-2.0-flash-thinking-exp-01-21 が開放されています。
設定
Rooにはシステムプロンプトを複数渡せます。これらは共通して、役割に必要な情報を持たせるように考えられています。
私は、アプリケーションの意図から仕様を検討する役割と、アプリケーションの意図を踏まえて品質をチェックする役割の２つを設定しています。
指示
Rooには、出来る限り細かな指示を渡しません。
Cursorに細かく渡しているため、それ以外の作業を自動化するためにも、できる限り人間が行う作業を減らしたいです。
必要な制約（障る範囲、触ってはならない範囲）はシステムプロンプトへ入れておきます。
使って欲しい観点は、役割として定義しておきます。
そのうえで、指示は抽象度の高いものを入れます。ただし、スコープが絞られないと無限に広がってしまうため、
最近2週間以内に追加されたコードを洗い出してください。それらを1つずつスコープを定めて検証し、ミッションをクリアしてください。
あなたの役割は、テスト対象の漏れや、コード修正が必要な課題を洗い出して、直したり整理することです。
システムプロンプトの指示に従って作業しなさい。
のようにします。システムプロンプトが無視される場合は、重要なプロンプトを繋いだ状態にしてから、指示すると良いでしょう。
仕様を決めていくときは、
今回は、仕様決めがゴールです。実装は不要です。
アプリケーションの課題は、**情報は一覧表示があるものの、edinetの一覧表示はないことです。
また、別々に閲覧するのは不便であるため、**とedinetが混在した一覧作成を行うことが望まれています。そこでまず、**を表示している箇所を洗い出してください。
そのうえで、以下の要求から必要な仕様を考えて整理し、最善と考える仕様を決定してください。
- ヘッダのリンク「**」情報を表示している方法と同じような、一覧表示を新設したいです。
- 一覧は「開示」というリンクにします。内容は**とedinetを混在した一覧にします。
- ** のリンク先は、既存の ** と同様にします。edinetのリンク先は、stock showに存在するリンクと同じにします。
あなたの役割は、既存システムやドキュメントを読み解いて、仕様を考え、仕様を決めて記載することです。
考えた仕様は、****** へまとめなさい。検討プロセス自体はタスク管理し、ステータスを更新しながら進めなさい、
これで自走します。
成果
詳しくは書きませんが、成果の測り方や保存の仕方には工夫が必要です。
ドキュメント作成をゴールにする場合は、ドキュメントの出力場所や形式、ボリュームを決めていく必要があります。
また、Cursorへ引き継ぐために、目的や背景を記載させることも重要になります。
フロント側であれば設計効率や速度とUI/UXを、バックエンドであれば堅牢性・セキュリティ・冪等性を重視するなど、いくつか異なる観点を交えてRooに作業させつつ、Cursorへ渡すときには絞り込まれた状態にしておく必要があります。
いずれにしても、自走するRooにはカバー範囲の広い上流を、狭い範囲でパフォーマンスを発揮するCursor Composerにはコーディングを担当させるのが、今のところ有効そうに思います。
最後に
こうしたAI開発環境を作ることで、自らコーディングせずに済みます。
最近は、精度が上がっているため、ブランチのMergeもCursor Composer(Yolo)へ任せています。ボタンを押すプルリクは、最後のmainブランチへのマージだけです。
時々、ミスは起こります。
例えばブランチを綺麗にするためにpruneなどをさせて綺麗にします。そのときに、merge済みのブランチを削除させようと指示を同時に出すと、まだマージしていないブランチを削除したりします。 -D で強制削除することもあります。
従って、ブランチを切りながら、作業をコミットさせていくことによって、手戻りを許容する必要があります。Gitで管理できない差分のある作業は、まだ任せられません。
ただ、良いコードの積み上げを自律的に行い、人間はコーディングせずに開発できる時代になっていることを、自分自身の肌身で感じています。
もう、AIが書いたコードを念のために読むこともなくなってきています。
セキュリティの懸念、パフォーマンスの懸念なども、繰り返しRooやCursorに作業させているため、回数で品質をカバーできているように思います。
（セキュリティやバリデーションのレベルを強めすぎて、自分で書いたテストが通らずにループするケースがあるほどなので、仕様や要件の水準コントロールが、次の課題かな・・とは感じています。）