1. はじめに
独力＋AI活用で月商1億円を目指している。
最近は、開発用PCでCursorをかなり使い込んでいる。
実装、UI改善、自動テスト、ビルド確認、ドキュメント更新、進捗報告。
これらをCursorに連続で依頼しながら、開発を前に進めている。
その中で、最近かなり試しているのが、Cursorのキューを大量に積む運用である。
画面を見ると、キューが20個以上積まれていることもある。
ときには50個近く積むこともある。
これはかなり強力である。
自分が寝ている間も、離席している間も、Cursorが作業を続けてくれる。
新しい開発用PCが安定して動いていれば、朝起きたときに作業が進んでいることもある。
ただし、ここで考える必要がある。
キューを大量に積むことは、本当に効率的なのか。
2. 結論：方向性は良い。ただし使い方を間違えると危ない
結論から言うと、Cursorのキューを積む運用はかなり有効である。
特に、開発用PCが安定していて、
スリープしない
Cursorが落ちにくい
buildやtestが途中で止まりにくい
夜間も動き続ける
朝起きたら作業が進んでいる
という状態なら、かなり価値がある。
これは、PC性能というより、安定稼働端末としての価値である。
人間が寝ている時間を、開発時間に変えられる。
これは大きい。
ただし、50個前後を毎回積むのが最適かというと、そこは少し注意が必要である。
止まらないという意味では強い。
しかし、品質管理という意味ではリスクもある。
3. 50個キューのメリット
大量キューの最大のメリットは、作業が止まりにくいことだ。
こちらが寝落ちしても、Cursorは次の指示に進む。
外出していても、ある程度作業が進む。
待ち時間を減らせる。
開発用PCを夜間バッチ処理のように使える。
特に、やるべきことが大量にある今の段階では、これはかなり意味がある。
たとえば、以下のような作業が大量にある。
P0/P1の実装
UI改善
主要導線の改善
空データ表示の整備
既存E2Eの安定化
確認用端末からの指摘修正
残課題一覧の更新
進捗報告の整理
小さなコンポーネント改善
これらを人間が毎回細かく指示していたら、かなり時間がかかる。
だから、正本ルールを読ませて、ある程度自走させる運用は理にかなっている。
4. 50個キューのリスク
一方で、50個キューにはリスクもある。
特に怖いのは、途中で方針がズレたまま大量に進んでしまうことだ。
たとえば、以下のようなことが起きる可能性がある。
1. 途中でbuildが壊れる
2. その状態で後続キューが続く
3. Cursorが修正に入る
4. しかし根本原因から少しズレる
5. さらに後続キューで別の修正が重なる
6. 朝起きたら差分が大きくなっている
これは危険である。
また、次のようなリスクもある。
1個目でテストが失敗しているのに、後続が無駄作業になる
ドキュメント更新ばかりに寄る
同じ指示の繰り返しで実装粒度が雑になる
Git差分が大きくなり、確認が難しくなる
朝起きたときに何が変わったか把握しづらい
本来止まるべきところで止まらない
つまり、50個キューは「止まらない」という意味では強いが、人間の確認が入らない時間が長くなるという弱点もある。
5. 正本が強ければ、大量キューはかなり有効
ここで重要なのが、正本ルールの存在である。
正本が弱い状態で50個キューを積むと危ない。
しかし、正本がしっかりしていて、以下が明確になっていれば、50個キューはかなり実用的になる。
| 条件 | 内容 |
|---|---|
| 正本ファイルがある | AIが毎回参照する作業ルールがある |
| 自走指示がある | 優先順位と作業方針が決まっている |
| main直作業禁止 | Git事故を防げる |
| featureブランチ作業 | 作業単位を分離できる |
| 検証報告ルールがある | build / lint / testの結果を確認できる |
| 進捗報告がある | どこまで進んだか分かる |
| ドキュメント過剰更新を抑制 | 実装から逃げにくくなる |
| 停止条件がある | 壊れたまま突き進みにくい |
| PCが安定稼働する | 夜間自走が成立する |
この前提があるなら、大量キューは「危険な暴走」ではなく、夜間・離席中の自走開発バッチとして機能する。
6. 「前回の続きです」だけの運用
最近は、キューに「前回の続きです」とだけ積むこともある。
これは、正本ルールがしっかりしている場合には成立する。
毎回長文を貼る必要はない。
詳細ルールは正本ドキュメントに寄せる。
Cursorには正本を読ませる。
そのうえで「前回の続きです」と指示する。
この流れはかなり効率的である。
ただし、完全に「前回の続きです」だけだと、少し弱い場合もある。
AIが、
なんとなく前回の作業を続ける
本当にP0/P1を優先しているか曖昧になる
検証報告が薄くなる
テスト失敗時の停止条件が弱くなる
ドキュメント更新に逃げる
可能性がある。
だから、本当に大量キューを積むなら、正本側に強い停止条件と優先順位を入れておく必要がある。
7. 50個キューでも比較的安全な作業
50個キューでも比較的安全なのは、既存方針に沿って進められる作業である。
たとえば、以下のようなものだ。
既存UIの改善
空データ表示の整備
表示文言の修正
主要詳細画面の表示改善
ログイン後導線の改善
既存E2Eの安定化
確認用端末からのP0/P1指摘対応
残課題一覧の更新
進捗報告の整備
小さなコンポーネント改善
こういう作業は、正本ルールに沿って進めやすい。
方針が大きく変わるわけではなく、既存の品質を上げる方向なので、大量キューとの相性が良い。
8. 50個キューを控えた方がいい作業
逆に、50個キューを控えた方がいい作業もある。
以下のような作業は、途中で人間の確認を入れた方がよい。
DBスキーマ変更
migration
認証まわり
middleware
課金まわり
中核ロジックの根本変更
進行管理ロジックの大改修
大規模リファクタ
複数ブランチ統合
main反映前の最終判断
このあたりは影響範囲が広い。
Cursorが自走で進めすぎると、後で戻すのが大変になる。
こういう局面では、50個ではなく、10〜20個くらいで区切って、人間が一度確認した方が安全である。
9. キュー数の目安
状況ごとのキュー数の目安は、今のところ以下がよさそうだ。
| 状況 | 推奨キュー数 |
|---|---|
| 画面を見ながら作業する | 3〜5個 |
| 1〜2時間離席 | 5〜10個 |
| 仕事・外出中 | 10〜20個 |
| 就寝中 | 20個前後、多くても30個 |
| 正本が強く、単純なP0/P1消化 | 30〜50個もあり |
| DB・認証・課金・大規模変更 | 10〜20個で区切る |
つまり、50個が絶対にダメというわけではない。
正本が強く、作業内容が安定していて、開発用PCが安定稼働しているなら、50個キューはありである。
ただし、常に50個が最適というわけではない。
基本は10〜20個。
就寝時や安定作業では30個前後。
かなり安定したP0/P1消化なら50個もあり。
このくらいの感覚がよさそうだ。
10. 大量キューに必ず入れたい停止条件
大量キューを使うなら、正本ルールに停止条件を入れるべきである。
たとえば、以下のような内容である。
長時間自走中に build / lint / E2E が失敗した場合は、後続の大規模実装へ進まず、原因調査・最小修正・再検証・報告を優先してください。
根本原因が不明なまま別機能の実装を積み増さないでください。
これはかなり重要である。
これがないと、Cursorが失敗した状態のまま、次の作業へ進んでしまう可能性がある。
また、以下の条件も入れておきたい。
以下の場合は、無理に次の大改修へ進まず、原因調査・小さな修正・報告に切り替えてください。
- build が失敗した場合
- lint が失敗した場合
- E2E が連続失敗した場合
- DB / migration / seed 変更が必要になった場合
- 仕様判断が必要な分岐に当たった場合
- 同一ファイルの大規模変更が続いて差分が肥大化した場合
- ドキュメント更新だけが続いて実装が進んでいない場合
大量キュー運用では、停止条件が命綱になる。
11. 一番効率が良い運用
現状、一番効率が良さそうなのは以下である。
通常時:
5〜10個キュー
離席時:
10〜20個キュー
就寝時:
20個前後キュー
安定したP0/P1消化:
30〜50個キューもあり
朝起きたら:
git status / commit / build / E2E / 差分を確認
その後、次のキューを積む
重要なのは、朝起きた後の確認である。
寝ている間に進んだ作業を、そのまま信用しない。
必ず差分を見る。
buildやtestを見る。
進捗報告を読む。
変更内容と残課題を確認する。
ここをやらないと、大量キュー運用は危険になる。
12. 50個キューは悪ではない
前は、50個キューは少し多すぎるかもしれないと思っていた。
今も、雑に50個積むのは危ないと思っている。
ただし、正本がしっかりしていて、PCが安定し、作業範囲が明確なら、50個キューはかなり有効だと思うようになった。
特に、今のようにやることが大量にあり、P0/P1を消化し続ける段階では、50個キューは合理的である。
人間が寝ている間も、Cursorが進めてくれる。
これは大きい。
ただし、万能ではない。
使い分けが必要である。
通常のUI改善・P0/P1消化:
50個キューでもあり
DB / 認証 / 課金 / 大規模変更:
10〜20個で区切る
main統合前:
人間が確認する
これが今の判断である。
13. 今回の結論
Cursorに大量キューを積む運用は、かなり有効である。
特に、新しい開発用PCが安定して動いているなら、寝落ちしても作業が進む。
人間が寝ている時間を、開発時間に変えられる。
これは、独力＋AI活用の大きな武器になる。
ただし、50個キューは万能ではない。
正本が弱い状態で大量に積むと危ない。
途中でbuildやtestが壊れても、そのまま進む可能性がある。
ドキュメント更新に逃げる可能性もある。
朝起きたときに差分が大きくなりすぎる可能性もある。
だから、大量キューを使うなら、必要なのはキュー数の調整だけではない。
必要なのは、正本ルール、停止条件、報告形式、人間による節目確認である。
正本が強いなら、50個キューはあり。
ただし、DB・認証・課金・大規模変更は10〜20個で区切る。
main統合前は必ず人間が確認する。
AIを寝ている間も働かせる。
ただし、暴走させない。
このバランスが、Cursor時代の個人開発ではかなり重要になってきた。
0 件のコメント:
コメントを投稿