1. はじめに
独力＋AI活用で月商1億円を目指している。
最近は、Cursor AIにかなりの作業を任せている。
実装、修正、自動テスト、ビルド確認、PR作成、ドキュメント更新、残課題整理。
うまく使えば、一人開発とは思えない速度で前に進めることができる。
ただし、Cursor AIに連続で作業を依頼する場合、指示の出し方がかなり重要だと分かってきた。
最初は、毎回かなり長い指示文を貼っていた。
ルール、作業方針、Git運用、進捗報告、検証条件、禁止事項、完了報告項目。
全部を毎回貼っていた。
しかし、これを続けるのは非効率である。
一方で、短くしすぎると、今度はAIが重要なことを省略する。
進捗報告が抜ける。
Git運用が崩れる。
検証が弱くなる。
ドキュメントだけ直して実装しない。
完了報告が雑になる。
そこで、連続指示の最適な形を考えるようになった。
2. 結論：毎回貼る指示は、少し変えた方がいい
現時点での結論は、毎回貼る指示は少し変えた方がいいということだ。
ただし、毎回長文にする必要はない。
むしろ、毎回長文を貼り続けるのは非効率である。
今の最適解は、以下だと思っている。
詳細ルールは正本ドキュメントに集約する
自走用の指示ファイルにも詳細を反映する
毎回貼る文面は短縮版にする
ただし、進捗報告の省略禁止だけは毎回明記する
つまり、毎回すべてを説明するのではなく、正本参照型の短縮指示に切り替える。
これが一番バランスがよい。
3. 長文指示を毎回貼る問題
毎回長文指示を貼ると、安心感はある。
こちらの意図を細かく書ける。
禁止事項も書ける。
完了報告項目も書ける。
Git運用も指定できる。
しかし、問題もある。
まず、単純に貼るのが面倒である。
そして、長すぎる指示はAI側でも要点がぼやけることがある。
また、長文指示を毎回微妙に変えていると、どれが最新ルールなのか分かりにくくなる。
たとえば、
前回の指示ではAと書いた
今回の指示ではBと書いた
正本ドキュメントではCと書いてある
この状態になると、AIも人間も混乱する。
だから、詳細ルールは毎回貼るのではなく、正本ドキュメントに寄せた方がよい。
4. 短くしすぎる問題
一方で、短くしすぎるのも危険である。
たとえば、
前回の続きでお願いします。
だけだと、AIは勝手に解釈する。
何を優先すべきか分からない。
前回の続きの範囲も曖昧になる。
Git運用も省略されるかもしれない。
検証も弱くなるかもしれない。
完了報告も雑になるかもしれない。
特にAIは、曖昧な指示を与えると、やりやすい作業に流れやすい。
実装してほしいのにドキュメントだけ直す。
検証してほしいのに報告書だけ作る。
進捗率を出してほしいのに省略する。
PRまでやってほしいのにコミットで止まる。
こういうことが起きる。
だから、短縮版にする場合でも、絶対に外せない項目は毎回書く必要がある。
5. 正本ドキュメントを読ませる形にする
一番良いのは、詳細ルールを正本ドキュメントにまとめ、毎回そこを読ませることだ。
たとえば、以下のようなものを正本にする。
Cursor作業ルール
自走継続指示
Git運用ルール
完了報告フォーマット
進捗率の出し方
検証の省略条件
PR作成ルール
禁止事項
優先順位の決め方
こうしておけば、毎回の貼り付け文は短くできる。
AIには、
正本ファイルを読んで、そのルールに従ってください。
と指示すればよい。
これなら、詳細ルールのメンテナンスは正本側で済む。
毎回の指示文は、今回の目的と優先順位だけに絞れる。
6. ただし、進捗報告省略禁止だけは毎回書く
ここはかなり重要である。
AIは、進捗報告を省略しがちである。
作業内容は書く。
変更ファイルも書く。
テスト結果も書く。
しかし、こちらが本当に欲しい以下のような情報が抜けることがある。
初期公開を100%とした現在地
正式公開を100%とした現在地
前回比
根拠
残り所要時間
メインループの現在地
残課題件数
後回し機能件数
リスク・未確認事項
これが抜けると、プロジェクト管理ができない。
AIは実装担当であると同時に、作業報告者でもある。
報告が弱いと、次の判断ができない。
だから、進捗報告だけは、毎回の短縮指示にも明記する。
ここを正本に書くだけでは少し弱い。
毎回貼る指示にも入れる。
7. 毎回貼る文面の基本形
今後、Cursor AIに貼る指示は、以下のような形がよいと思っている。
前回の続きです。
開発側AIは、以下の正本ファイルを読み込み、その内容に従って自走してください。
docs/15_Cursor作業ルール.md
docs/cursor-instructions/開発側AI_自走継続版.md
今回も、初期公開を最短で目指してください。
最優先は、ログイン後の中心体験と主要導線の成立です。
確認側からP0/P1報告があれば優先対応し、なければメインループの未完成箇所から、初期公開進捗率が最も上がる作業を選んで進めてください。
Git操作・検証・PR・完了報告・進捗報告は正本ルールに従ってください。
小さい修正ごとの過剰なフル検証は不要ですが、必要な確認は省略しないでください。
完了報告では、初期公開進捗率、正式公開進捗率、前回比、根拠、残り所要時間、メインループ現在地、残課題件数、後回し機能件数、リスクを省略しないでください。
未実施項目がある場合は、理由を書いてください。
公開ブログ用なので、具体的なサービス内容に直結する文言は抽象化している。
実際にCursorへ貼るときは、内部用語を使ってよい。
8. 連続指示で大事なのは、前回からの継続性
連続指示で大事なのは、前回からの継続性である。
AIは、前回の作業内容をある程度踏まえることはできる。
しかし、常に完璧に覚えているわけではない。
だから、毎回の指示では以下を明確にしたい。
前回の続きであること
正本ファイルを読むこと
今回の最優先テーマ
報告省略禁止
未実施項目の理由を書くこと
Git運用を守ること
これだけで、かなり事故が減る。
逆に、毎回まったく違う指示を出すと、AIの作業がブレる。
連続作業では、毎回少し変えるが、骨格は固定する。
これが大事である。
9. 小さい修正ごとの過剰検証は不要
もう一つ重要なのは、検証の重さである。
毎回すべての修正で、フル検証、フルE2E、PR、マージ、詳細報告をやらせると、効率が悪い。
もちろん、重要な変更では必要である。
しかし、小さなドキュメント修正や限定的なUI文言修正で、毎回フル検証を求めると、時間もAI使用量も無駄になる。
だから、正本ルール側で以下を整理する必要がある。
docsのみなら軽い確認でよい
アプリコード変更ならlint/buildは基本必要
主要導線変更ならE2Eが必要
ロジック変更なら対象テストが必要
PR前には差分確認が必要
未実施の検証は理由を書く
こういうルールがあると、AIも判断しやすくなる。
10. AIは短縮指示を都合よく解釈する
短縮指示にはリスクもある。
AIは、短縮された部分を都合よく解釈することがある。
たとえば、
正本に従ってください。
と書いても、実際には正本を十分に読んでいないような動きをすることがある。
また、
前回の続きです。
だけでは、前回のどの部分を続けるべきか曖昧になる。
だから、短縮版でも必ず入れるべき項目がある。
正本ファイル名
今回の優先テーマ
報告省略禁止
未実施項目の理由
Git運用遵守
確認側報告があれば優先
これらは毎回入れる。
短くするが、重要な骨格は削らない。
11. ルールドキュメント側に寄せるべきもの
逆に、毎回貼らなくてよいものもある。
以下は正本ドキュメント側に寄せるべきである。
詳細なGit操作ルール
ブランチ命名規則
PR作成手順
完了報告フォーマットの詳細
テストコマンド一覧
検証省略条件
禁止事項一覧
ドキュメント更新ルール
進捗率算定ルール
作業スコープの判断基準
これらを毎回貼ると長くなる。
正本に入れておき、毎回は参照だけにする。
12. 連続指示の目的は、AIを止めないこと
Cursor AIに連続指示を出す目的は、AIを止めないことだ。
AIは便利だが、止まりやすい。
判断に迷う。
確認待ちになる。
どこまでやるべきか分からなくなる。
報告だけで終わる。
次作業を提案して止まる。
これでは効率が悪い。
連続指示では、AIが自走できるようにする必要がある。
そのためには、
優先順位を与える
正本を与える
判断基準を与える
報告形式を固定する
未確認事項を書かせる
次に進む基準を明確にする
これが必要になる。
AIを自由にするのではない。
枠を決めたうえで、自走させる。
13. 今回の結論
Cursor AIに連続指示を出すときのコツが、少し見えてきた。
毎回、長文の指示を貼り続けるのは非効率である。
しかし、短くしすぎると、進捗報告やGit運用が崩れる。
だから、今後は以下の方針にする。
詳細ルールは正本ドキュメントへ反映する
自走指示ファイルにも詳細を反映する
毎回貼る文面は短縮版にする
ただし、進捗報告省略禁止だけは毎回明記する
今回の優先テーマも毎回書く
未実施項目は理由を書かせる
正本参照型でAIを自走させる
これは、AIを楽にするためではない。
こちらがAIを管理しやすくするためである。
AIは、放っておくと逃げる。
省略する。
ドキュメントだけ直す。
報告を端折る。
都合よく解釈する。
だから、正本で縛り、短縮指示で方向を与え、完了報告で検収する。
独力＋AI活用で開発するには、AIへの指示設計そのものがプロジェクト管理になる。
Cursor AIをどう動かすか。
どこまで任せるか。
何を毎回確認するか。
ここを磨くことが、開発速度と品質の両方に直結すると感じている。
0 件のコメント:
コメントを投稿