メインを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に作業させているため、回数で品質をカバーできているように思います。
（セキュリティやバリデーションのレベルを強めすぎて、自分で書いたテストが通らずにループするケースがあるほどなので、仕様や要件の水準コントロールが、次の課題かな・・とは感じています。）