独力＋AI活用で月商1億円達成までの奮戦記！: 第53回：作戦変更。AIに「効果が大きいものを選ばせる」のをやめて、キューを機械的に潰す

2026年5月4日月曜日

第53回：作戦変更。AIに「効果が大きいものを選ばせる」のをやめて、キューを機械的に潰す

1. はじめに

独力＋AI活用で月商1億円を目指している。

最近、開発の進め方について少し作戦を変えることにした。

これまでは、Cursorに対して、

初期公開や正式公開に一番効果が大きい作業を選んで進めてください。

という指示をしていた。

一見、これは正しい。

限られた時間で開発するなら、効果が大きいものからやるべきである。
優先順位を考えて、重要なものから進める。
プロジェクトマネジメントとしても自然な考え方である。

しかし、実際に運用してみると問題が出てきた。

Cursorが「どれを選ぶか」で止まりやすい。
PR状態確認、CI確認、次に何をすべきかの棚卸しに寄りすぎる。
報告は増えるが、実装消化の速度が落ちる。

つまり、優先順位判断をAIに任せすぎると、AIが判断作業に寄ってしまい、実装が進まないことがある。

そこで今回、作戦を変える。

「効果が大きいものを選ぶ」ではなく、まずキューを機械的に潰す。

2. 今の問題：選定で止まる

最近のCursorの動きを見ていると、実装そのものよりも、状態確認に時間を使いすぎている場面があった。

たとえば、

どのPRを先に見るべきか
どのPRがまだ未マージか
CIが赤なのか
どれが次に重要そうか
どの作業が正式公開に効きそうか
何を選ぶべきか

こういう整理で止まってしまう。

もちろん、これは不要な作業ではない。

PR状態確認も必要である。
CI状況確認も必要である。
次に何をやるかの判断も必要である。

ただし、そればかりになると困る。

こちらが欲しいのは、最終的には実装消化である。
未マージPRをmainへ反映すること。
残課題を閉じること。
ブロックされているものを明確にすること。
小さくても前に進めること。

状態確認だけで終わるなら、開発速度は上がらない。

3. 「最も効果が大きい作業を選ぶ」は、AIには重いことがある

人間のプロジェクト管理でも、優先順位判断は難しい。

何が一番効果が大きいのか。
何が今やるべきなのか。
何が後回しでよいのか。
何がブロックされているのか。
何を先にマージすべきなのか。

これは、プロジェクト全体の文脈を理解していないと判断しにくい。

AIはかなり優秀だが、ここを任せすぎると、毎回判断に時間を使う。

その結果、

次に何をやるべきか整理しました。

で終わってしまうことがある。

これは困る。

今必要なのは、きれいな整理だけではない。
実際に未完了のものを減らすことである。

4. まず未マージPRキューを潰す

そこで、まず最優先を変える。

新しい作業を選ぶ前に、未マージPRキューを潰す。

すでに作業済みで、mainに入っていないものがあるなら、それを放置して新しい実装を増やしてはいけない。

未マージPRが残っていると、以下の問題が起きる。

実装済みなのに本線に反映されない
同じような修正を別PRで重ねる
PR同士が競合する
どれが最新状態か分かりにくくなる
docsや進捗報告とmainの実態がズレる

だから、まずはPRキューを片付ける。

順番としては、

既に作業済みでmain未反映のPR
初期公開・正式公開に関係するPR
開発運用ルール系PR
QA・試験系PR
その他

この順でよい。

重要なのは、CIやGitHub Actionsの問題でマージできない場合でも、そこで止まらないことだ。

ローカルでできる確認をする。
マージ可能性を判断する。
CI復旧待ちとして記録する。
そして次のPRへ進む。

CIが使えないことを理由に、状態確認だけで1セッションを終わらせない。

5. PRごとの処理を定型化する

未マージPRを見るときも、毎回迷わせない。

PRごとにやることを固定する。

mainとの差分確認
conflict確認
local build
local lint
関連E2E
skipがある場合は理由を明記
マージ可能か判断
マージできるならマージ
CIやActions上限でマージできないなら、CI復旧待ちとして記録
次のPRへ進む

この型でよい。

重要なのは、AIが「どうしましょうか」と止まらないことだ。

確認できるところまで確認する。
マージできるなら進める。
できないなら理由を残して次へ行く。

これで、滞留が減る。

6. PRキューが片付いたら、残課題を上から潰す

未マージPRが片付いたら、次は残課題一覧である。

これまでは、残課題一覧の中から「効果が大きいもの」を選ばせようとしていた。

しかし、当面はその方針をやめる。

上から順に見る。

もちろん、完全に何も考えずに上からやるわけではない。

各項目を見て、次のように処理する。

実装可能なら実装する

小さく切れるなら、featureブランチを切って、最小縦切りで実装する。

関連画面、関連データ、必要最低限の確認を行い、残課題の状態を更新する。

巨大すぎるなら分割する

巨大だから何もしない、は禁止にする。

巨大な場合は、最初の最小サブタスクだけ切り出して実装する。
残りは分割して残す。

Blockedなら理由を書く

前提が未解決なら、Blockedにする。

ただし、ただ「できません」ではなく、なぜできないのか、何が必要なのかを書く。

今やる価値が薄いならDeferredにする

現時点では正式公開に不要なら、Keep DeferredやBacklogとして理由を残す。

そして次へ進む。

重要なのは、迷って止まらないことである。

7. 後回し一覧も、迷ったら上から見る

後回し機能一覧も同じである。

後回しだから絶対に触らない、ではない。

開発が進むと、以前は後回しでよかったものが、実は初期公開や正式公開に必要だったと分かることがある。

だから、詰まったら後回し一覧も上から見る。

今も不要なら、Keep Deferred
必要になっているなら、軽量ドラフト実装
巨大なら、最小縦切りに分解
依存があるなら、Blocked理由を書く

これでよい。

「後回し一覧だから見ない」ではなく、迷ったら上から確認して、判断を記録する。

8. 作業上限を決める

AIが調査で長時間止まるのも問題である。

そこで、作業上限を決める。

目安としては以下である。

作業種別	調査・対応上限
軽微UI・文言	15〜30分
通常導線・空状態・ボタン	30〜60分
build / E2E / データ不整合	60〜90分
それ以上かかるもの	Blocked / Backlog化して次へ

もちろん厳密な時間管理は難しい。

ただ、思想としては重要である。

AIが1つの項目に長く詰まるなら、無理に粘らせない。
理由を書いて次へ進める。

これにより、全体の前進速度を保てる。

9. 「上から順」は完璧ではないが、今は有効

上から順に潰す方式は、理想的な優先順位管理ではない。

本来は、効果、緊急度、依存関係、リスク、工数を見て判断するのがよい。

しかし、今の問題はそこではない。

今の問題は、選定で止まることである。

どれが一番効果的かを考えすぎて、何も進まない。
PR状態確認だけで終わる。
次にやることの報告だけが増える。

この状態を壊すには、ある程度機械的に進めた方がよい。

上から見る。
できるならやる。
できないなら理由を書く。
次へ進む。

これは、今のフェーズではかなり有効だと思う。

10. AIに自由度を与えすぎると、止まりやすい

AIは自由に考えさせると、意外と止まることがある。

「最適なものを選んでください」
「効果が大きいものを進めてください」
「今一番重要なことを判断してください」

こういう指示は、人間には自然でも、AIには少し重いことがある。

AIは、候補を整理し、比較し、リスクを出し、結論を出そうとする。
その結果、実装ではなく整理に寄る。

だから、しばらくは自由度を下げる。

PRは上から処理
残課題は上から確認
Blockedなら理由を書く
巨大なら分割
Deferredなら理由を書く
迷ったら次へ進む

この方が、実装消化の速度は上がるはずである。

11. 完了報告も変える

作戦を変えるなら、完了報告も変える必要がある。

今後は、完了報告で必ず以下を書かせたい。

処理したPR番号、または残課題ID
実装したのか
Blockedなのか
Deferredなのか
その判断理由
実行したbuild / lint / E2E
skipがある場合のspec名、ケース名、理由
PR URL
merge有無
main反映有無
次に処理すべきPRまたは残課題ID
初期公開・正式公開への進捗影響

これにより、単なる「確認しました」では終わらせない。

必ず、処理結果を残す。

12. 通常指示も修正する

通常のCursor指示も変える必要がある。

これまでのように、

正式公開への効果が大きい順に選んでください。

ではなく、

原則として上から順に処理してください。
ただし、Blocked、巨大、前提未解決、現時点で不要なものは、理由を明記してスキップしてください。
「どれを選ぶか」で長時間止まることは禁止します。

という方向に変える。

後回し一覧も同じである。

迷う場合は上から確認する。
必要なら軽量ドラフト実装する。
不要ならKeep Deferredと理由を記録する。

この方が、AIにとって実行しやすい。

13. これは後退ではなく、運用最適化である

一見すると、「効果が大きいものを選ぶ」方が高度に見える。

逆に、「上から潰す」は雑に見えるかもしれない。

しかし、これは後退ではない。

今の課題に合わせた運用最適化である。

理想的な優先順位判断で止まるくらいなら、多少単純でも前に進めた方がよい。

特に、既に大量のPRや残課題がある状態では、まず滞留を減らすことが重要である。

選び続けるより、処理する。

これが今の方針である。

14. 今回の結論

Cursorへの指示方針を変えることにした。

これまでは、正式公開への効果が大きいものを選ばせる方針だった。

しかし、現状では、AIが選定、棚卸し、PR状態確認に寄りすぎて、実装消化の速度が落ちている。

そこで、当面はキュー消化方式にする。

未マージPRを上から潰す
↓
残課題一覧を上から潰す
↓
Blockedなら理由を書いて次へ
↓
巨大なら最小サブタスクに分解して進める
↓
後回し一覧も迷ったら上から確認する

この方式で、「何を選ぶか」で止まる時間を減らす。

もちろん、上から順が常に最適ではない。
しかし、今は選定で止まる方が問題である。

AIには、考えさせすぎるより、処理させる。

そのために、ルールを単純化する。

今回の作戦変更で、PR滞留と残課題消化の速度が上がることを期待している。

独力＋AI活用で月商1億円達成までの奮戦記！