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

2026年5月7日木曜日

第54回：Cursor Ultraの200ドル枠を使い切った。次はChatGPT側のCodexを補助開発者として使う

1. はじめに

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

ついに、Cursor Ultraの 200ドル枠 を使い切った。

画面を見ると、Ultraプランの利用状況が100%。
Auto + Composerも100%。
API側も100%。

かなり使った。

正直、ここまで使うとは思っていなかった。
ただ、それだけ本気でAI開発を回しているということでもある。

開発用PCを買い、CursorをUltraに上げ、ChatGPTも使い、その他のAIツールも使っている。
個人開発としては、かなり攻めた投資になっている。

ただ、ここで問題が出てきた。

Cursorが枯れた後、どうやって開発を続けるか。

そこで次の作戦として、ChatGPT側のCodexを補助開発者として使うことを考えている。

2. Cursorを使い切った理由

Cursorを使い切った理由は、単純にAIに任せる量が増えたからである。

最近は、かなり広い範囲をCursorに投げていた。

実装
UI改善
自動テスト追加
ビルド確認
ドキュメント更新
PR作成
既存PRの整理
残課題消化
画面導線改善
制限事項の整理
完了報告

さらに、外出中や就寝中にもCursorを動かすため、キューを多めに積む運用もしていた。

これがかなり効いた一方で、当然ながら利用枠も大きく消費した。

特に、巨大な指示を投げると消費が激しい。

「全体を見て改善して」
「P0/P1をまとめて潰して」
「サービスインに向けて自走して」
「画面全体を棚卸しして」
「大量のドキュメントを読んで判断して」

こういう指示は便利だが、AI側の負荷も大きい。

結果として、200ドル枠を使い切った。

3. Cursorが枯れたら、開発は止まるのか

結論として、止める必要はない。

ただし、作戦は変える必要がある。

Cursor Ultraのように、大きな自走タスクを連続で投げる運用は難しくなる。

そこで、ChatGPT側のCodexを使う。

Codexは、OpenAI公式ではChatGPTのコーディングエージェントとして説明されており、開発からリリースまでの支援、機能構築、リファクタリング、レビュー、テスト品質向上などの用途が示されている。(OpenAI)

また、Codexアプリは複数スレッド、worktree、Git機能を備えたコーディング用の作業環境として説明されており、ChatGPT Plus、Pro、Business、Edu、EnterpriseプランにCodexが含まれると案内されている。(OpenAI Developers)

つまり、Cursorが枯れた後の代替として、ChatGPT側のCodexを使うのは現実的である。

ただし、使い方を間違えると、Codex側の枠もすぐ溶ける。

4. Codexは「短距離走用」に使う

今の結論はこれである。

Cursor Ultra枠が尽きたら、Codexを補助開発者として使う。
ただし、巨大な自走タスクではなく、1タスク・1ブランチ・1差分で小さく使う。

Codexに向いているのは、小粒の作業だと思っている。

たとえば、

小〜中規模の不具合修正
特定ファイルの修正
既存PRのレビュー
テスト追加
型エラー修正
lintエラー修正
小さなUI改善
ドキュメントと実装の差分確認
既存コードの局所的な改善

こういうものなら、Codexに向いている。

逆に、避けたいのは以下である。

サービスインまで全部自走して
全体を見て大きく改善して
P0/P1を全部潰して
UI全体を棚卸しして実装して
巨大な仕様書を全部読んで判断して
未マージPRも残課題も全部見て優先順位を決めて

これは、Cursorでも消費が大きかった使い方である。
Codexで同じことをやると、すぐに枠を使い切る可能性が高い。

OpenAI公式のヘルプでも、Codexの利用量はプランだけでなく、タスクのサイズ、複雑さ、保持するコンテキスト量、どこで実行するかによって変わると説明されている。小さなスクリプトや単純な関数は軽く済む一方、大きなコードベースや長時間タスク、長いコンテキストを保持するセッションは利用量が大きくなる。(OpenAI Help Center)

だから、Codexは短距離走用にする。

5. ChatGPT、Codex、Cursorの役割を分ける

Cursorが枯れた後は、役割分担を変える。

今後は、以下のような形がよさそうである。

ツール	役割
ChatGPT	司令塔。方針整理、優先順位、指示文作成、レビュー観点整理
Codex	補助開発者。1タスク・1ブランチ・1差分の実装
Cursor	枠が回復したら重めの実装、自走開発、既存フロー継続
開発用PC	build、lint、E2E、Git確認、ローカル検証
確認用端末	実機確認、シナリオ試験、スクショ、再確認

ChatGPT側でやるのは、引き続き設計と判断である。

Codexにいきなり全体を任せるのではない。
ChatGPTで「次の1タスク」に切り出す。
そのうえでCodexに渡す。

これが重要である。

6. Codexに渡す作業は小さく切る

Codexに渡すときは、必ず小さく切る。

悪い指示はこうである。

初期公開に向けて重要な課題を全部見て、必要なものから実装してください。

これは広すぎる。

良い指示はこうである。

この1画面の、この1つの導線だけを直してください。
変更ファイルは最小限にしてください。
format / lint / build を実行してください。
PR化できる状態にしてください。

このくらい狭くする。

Codexに渡す単位は、以下のようにする。

1タスク
1ブランチ
1差分
1目的
1検証セット

これなら、消費も抑えやすい。
差分も見やすい。
失敗しても戻しやすい。

7. Codex向けの安全な指示テンプレート

今すぐ使うなら、Codexには以下のような指示が安全だと思う。

目的:
Cursor Ultra枠が上限に達したため、Codexでは小さい単位の実装だけを行う。
巨大な全体調査、大規模リファクタ、複数機能の同時対応は禁止。

作業対象:
開発中Webサービスの初期公開に向けたP0改善。
今回は1タスクだけ対応する。

進め方:
1. main最新を確認する
2. featureブランチを作成する
3. 対象ファイルを最小限だけ調査する
4. 修正差分を最小化する
5. 必要なテストを追加または更新する
6. format / lint / build を実行する
7. 可能なら関連E2Eまたは最小テストを実行する
8. commitする
9. PR作成可能な状態にする

禁止事項:
- main直作業は禁止
- 大規模リファクタは禁止
- 不要なUI全面刷新は禁止
- 関係ないファイルの整形は禁止
- docsだけを長時間いじる作業は禁止
- 複数P0を同時に処理しない
- 判断に迷う場合は、仮実装せずに未確認事項として報告する

完了報告:
- branch
- commit
- 変更ファイル
- 実装内容
- 実行した検証
- 未検証事項
- 次に人間が判断すべきこと
- 初期公開進捗への影響

これなら、Codexに巨大な責任を背負わせずに済む。

8. Codexにやらせないこと

Codexを使うからといって、何でも任せるわけではない。

特に、今は枠を大事に使いたい。

だから、以下は避ける。

全体ロードマップの再設計
大量ドキュメントの棚卸し
画面全体の全面改修
DBや認証まわりの大規模変更
複数PRを横断した統合判断
大規模な仕様変更
長時間の調査だけで終わる作業
「なんとなく良くして」のような曖昧指示

これらは、ChatGPT側でまず切り出す。
必要なら、人間が判断する。
その後、Codexに小さく渡す。

9. PlusとProの違いも意識する

Codexを本格的に使うなら、プラン差も意識する必要がある。

OpenAIの公式ヘルプでは、Plusは軽めの利用向け、Proはより高負荷な作業向けという説明があり、Pro $200はPlusより20倍高い利用枠を持つプランとして説明されている。(OpenAI Help Center)

ただし、これは「枠が多い」という話であり、「雑に巨大タスクを投げてもよい」という意味ではない。

どのプランでも、タスクが大きくなれば消費は増える。
だから、結局はタスク設計が重要である。

高いプランを使っても、指示が雑なら枠は溶ける。

今回、Cursor Ultraを使い切ったことで、その現実をかなり感じている。

10. 枠を使い切ったことは失敗ではない

200ドル枠を使い切ったこと自体は、失敗ではないと思っている。

それだけ開発を進めた。
それだけAIに仕事をさせた。
それだけ自分の作業時間を拡張できた。

ただし、次の課題は見えた。

AIの枠は有限である。

だから、AIに何をやらせるかを設計しなければならない。

Cursorには重めの自走
Codexには小粒の差分
ChatGPTには司令塔
人間は検収と判断
確認用端末は実機確認

この分担が必要になる。

11. 今後の開発運用

今後は、以下の運用に寄せたい。

1. ChatGPTで次の1タスクを切り出す
2. Codexに1タスクだけ渡す
3. Codexがfeatureブランチで修正する
4. format / lint / build を通す
5. 必要なら最小E2Eを実行する
6. commit / PR化できる状態にする
7. 人間が差分を確認する
8. 必要ならCursor枠回復後に大きな統合を行う

これなら、Cursorが枯れても開発を止めずに済む。

ただし、速度は落ちる可能性がある。
その分、粒度を小さくして、確実に前に進める。

12. 今回の結論

Cursor Ultraの200ドル枠を使い切った。

これはかなり大きい。

AI開発は、思った以上に枠を消費する。
特に、大きな自走指示、長いコンテキスト、大規模なコードベース、複数作業の同時依頼は、消費が大きい。

次の作戦は、ChatGPT側のCodexを補助開発者として使うこと。

ただし、Codexには巨大タスクを渡さない。

1タスク・1ブランチ・1差分。

Codexは短距離走用。
ChatGPTは司令塔。
Cursorは枠が戻ったら重めの自走。
人間は検収と判断。

AIを使うだけでは足りない。
AIの利用枠も、プロジェクト資源として管理する必要がある。

今回、200ドル枠を使い切ったことで、その感覚がかなり強くなった。

AIにも予算がある。
AIにも稼働枠がある。
AIにも向き不向きがある。

これからは、AIツールを単に使うだけでなく、どの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滞留と残課題消化の速度が上がることを期待している。

第52回：体験設計の考慮が甘かった。内部処理の都合を、ユーザー画面に漏らしてはいけない

1. はじめに

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

最近、かなり大きな気づきがあった。

それは、体験設計の考慮が甘かったということだ。

画面の見た目を良くする。
アイコンを改善する。
導線を整理する。
ボタン文言を直す。
自動テストを追加する。

こうした改善はもちろん重要である。

ただし、それ以前に、その画面がユーザーにとってどんな体験であるべきかをもっと明確にしなければならなかった。

内部処理としては、すでに結果が生成されている。
内部的には、保存済みデータをもとに画面を組み立てている。
開発者目線では、それを「リプレイ」「再生」「結果からの表示」と呼びたくなる。

しかし、ユーザーにとって初めて見る体験は、そうではない。

ユーザーから見れば、まさにその瞬間に初めて体験するイベントである。

そこに開発者都合の文言やUIが出てしまうと、一気に没入感が壊れる。
元の議論でも、初回体験と2回目以降の見返しを分ける必要性、そして内部実装都合を通常画面に出さないことが整理されていた。

2. 開発者視点では「再生」でも、ユーザー視点では「初体験」

今回の反省点はここである。

開発者視点では、すでに生成された結果を表示している。
だから、つい「再生」「リプレイ」「プレイヤー」のように考えてしまう。

でも、ユーザー視点では違う。

初めてそのイベントを見るユーザーにとっては、それは過去データの再生ではない。
今まさに、自分が結果を知る瞬間である。

ここを間違えると、画面全体が安っぽくなる。

たとえば、初回体験なのに、

リプレイ
再生
プレイヤー
簡易表示
結果から生成
ライブではありません
次フェーズ

のような文言が前面に出ると、ユーザーは一気に現実へ戻される。

「これはゲーム内の体験ではなく、開発中の確認画面なんだな」

と感じてしまう。

これはかなりまずい。

3. 実装の都合が画面に漏れていた

今回の問題は、単なる文言ミスではない。

実装の都合が画面に漏れていたことが問題である。

開発側からすると、内部的にどう表示しているかは重要である。

データがいつ作られるのか。
どの時点で結果が確定するのか。
画面側では何を受け取って表示するのか。
テストではどう再現するのか。

これは開発上は重要である。

しかし、それをユーザーにそのまま見せてはいけない。

ユーザーが見たいのは、内部処理の説明ではない。
ユーザーが体験したいのは、サービス内の世界である。

「これは確定結果を元にした表示です」
「これは実際のライブではありません」
「これは簡易リプレイです」

こうした説明は、開発者にとっては正直かもしれない。
しかし、体験設計としては弱い。

正直であればよい、という話ではない。

ユーザー体験として、どの文脈で見せるべきかが重要である。

4. 初回体験と2回目以降は分けるべきだった

今回もっとも重要なのは、初回体験と2回目以降の見返しを分けることだ。

初回は、ユーザーにとって結果を知る瞬間である。
だから、画面上は「今から見る」「見守る」「結果を知る」体験であるべきだ。

一方で、2回目以降は見返しでよい。

一度見た後なら、

もう一度見る
見返す
回顧する
振り返る

という文脈で問題ない。

つまり、同じ画面でも、ユーザー状態によって見せ方が違う。

初回は「体験」。
2回目以降は「回顧」。

この区別が必要だった。

これを区別しないまま、最初から「リプレイ」的に見せてしまうと、一番大事な初回体験を壊してしまう。

5. ユーザーごとの体験状態が必要になる

初回と2回目以降を分けるには、当然ながらユーザーごとの状態管理が必要になる。

そのユーザーが、そのイベントを初めて見たのか。
途中まで見たのか。
最後まで見たのか。
もう一度見返したのか。

こうした状態を持たないと、画面文脈を切り替えられない。

最低限、以下のような状態が必要になる。

まだ見ていない
見始めた
最後まで見た
見返した

最初から本格的なDB実装までやるかは別として、仕様としては必要である。

ここを設計しないまま画面だけ作ると、すべてのユーザーに同じ表示を出すことになる。

その結果、初回体験なのに見返し扱いになる。
あるいは、見返しなのに初回のように見える。

これは体験として不自然である。

6. 結果を先に見せすぎる問題

もう一つ重要なのが、結果のネタバレ問題である。

ユーザーがまだ初回体験を終えていないのに、別画面で詳細結果が見えてしまう。
通知や履歴や一覧で、先に結末が分かってしまう。
その後に体験画面へ行っても、もう驚きがない。

これはかなりもったいない。

もちろん、すべての画面で完全に結果を隠すのは大変である。
初期段階で一気にやると、影響範囲も大きい。

ただし、少なくとも主要導線では考慮すべきである。

未体験のものについては、詳細結果よりも「体験へ進む」導線を優先する。
体験後に、結果、詳細、記録、回顧を表示する。

この順番を守るだけで、かなり印象が変わる。

7. 操作UIも体験を壊すことがある

今回、文言だけでなく操作UIも見直す必要があると感じた。

たとえば、動画プレイヤーのようなUIが前面に出すぎると、体験ではなく操作ツールに見えてしまう。

速度変更自体は便利である。
一時停止も必要かもしれない。
最初から見返す機能も、2回目以降ならあってよい。

しかし、それらが初回体験の中心に出すぎるとよくない。

特に、開発者向けの「次フェーズ」のような操作は、通常画面に出してはいけない。

それは完全にデバッグ機能である。

一般ユーザー向けには、画面の世界観に合った言葉にする必要がある。

「再生」ではなく「見る」。
「プレイヤー」ではなく「体験画面」。
「次フェーズ」ではなく、そもそも通常画面には出さない。

こういう細部が、体験の品質を左右する。

8. 画面名も重要

画面名もかなり重要である。

内部URLやコンポーネント名は開発都合でよい。
しかし、画面上に出るタイトルはユーザー体験に合わせるべきである。

初回なら、初回体験としての名前にする。
2回目以降なら、見返しや回顧としての名前にする。

同じ内部画面でも、ユーザー状態に応じてタイトルを変えることは十分あり得る。

内部的には同じ実装でも、ユーザーに見せる文脈は違う。

ここを意識しないと、内部構造がそのまま画面に出てしまう。

9. AIへの実装指示にも体験設計が必要

今回の反省点は、AIへの指示にもある。

AIに対して、

「この画面を改善して」
「見た目を良くして」
「UI文言を直して」

だけでは不十分だった。

本来は、最初にこう指示すべきだった。

この画面は、ユーザーにとって初めて結果を知る体験である。
内部処理としては結果生成済みでも、画面上では初回体験として扱う。
開発者向け文言を通常画面に出さない。
初回体験と2回目以降の見返しを区別する。

ここまで書かないと、AIは開発者視点で実装してしまう。

AIは仕様に書かれていない文脈を、常に正しく補ってくれるわけではない。

だから、体験設計を言語化して渡す必要がある。

10. 見た目改善だけでは足りない

最近、画面のビジュアル改善も進めている。

アイコンや表示を良くする。
画面の見た目を整える。
スマホでも見やすくする。

これはもちろん重要である。

しかし、見た目が良くなっても、体験文脈が間違っていれば安っぽくなる。

どれだけ見た目を良くしても、初回体験なのに「リプレイ」と出ていたら台無しである。
どれだけ演出を入れても、「これはライブではありません」と出ていたら没入感は消える。
どれだけUIを整理しても、結果を先に見せていたら体験の意味が薄れる。

つまり、必要なのは見た目改善だけではない。

体験の順番、文脈、状態、ネタバレ制御、初回と回顧の区別である。

11. これはサービス品質に直結する

この問題は、細かい文言の問題ではない。

サービス品質に直結する。

ユーザーが初めて触る。
自分の関心があるイベントを見る。
結果を見守る。
ゴールや完了の瞬間を知る。
その後、結果やコメントや次の行動へ進む。

この一連の体験が気持ちよくつながるかどうか。

ここが弱いと、サービス全体が安っぽくなる。

逆に、ここがしっかりしていれば、内部的にはシンプルな実装でも、体験としてはかなり良くなる。

体験設計は、実装コスト以上に価値を生むことがある。

12. 今回の結論

今回の反省は、体験設計の考慮が甘かったということだ。

内部的に結果が先に生成されているからといって、ユーザー画面でそれを「リプレイ」「再生」「簡易表示」のように見せてはいけない。

初めて見るユーザーにとっては、それは初回体験である。

初回体験では、ユーザーに結果を先に見せすぎない。
画面上は、今まさに見ている体験として扱う。
2回目以降は、見返しや回顧として扱う。
開発者文言を通常画面に出さない。
デバッグ操作を通常画面に出さない。
便利機能はあっても、主役にしない。

これは、単なるUI修正ではない。

体験設計の修正である。

AIを使うと、実装は速い。
しかし、体験の思想まできちんと指示しないと、開発者都合の画面がすぐにできてしまう。

今後は、画面を作る前に、その画面がユーザーにとって何の体験なのかを定義する。

見る画面なのか。
初めて結果を知る画面なのか。
見返す画面なのか。
操作する画面なのか。
確認する画面なのか。

ここを明確にしてから、実装に進める必要がある。

今回の気づきはかなり大きい。
サービスイン前に気づけてよかったと思う。

2026年5月3日日曜日

第51回：外出中にAIを働かせるため、開発スコープを広げて60キュー投入した

1. はじめに

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

今日は外出予定がある。

普通なら、外出している間は開発が止まる。
しかし、今はAIを使っている。

Cursorに作業キューを積んでおけば、自分が外出している間も、ある程度は開発を進められる。

そこで今回は、少し思い切って、開発範囲のスコープを大きく広げた。
そして、Cursorにかなり多めの指示を投入した。

その数、約60キュー。

正直、ちゃんと動くのか少し不安である。

ただ、今の開発用PCはかなり安定している。
正本ルールも整ってきた。
開発用PCと確認用端末の役割分担も固まってきた。
ブロッカー管理、制限事項管理、完了報告、FixedとConfirmedの考え方も整理されてきた。

だから今回は、外出時間を開発時間に変える実験として、あえて大きめに動かしてみることにした。

2. なぜ60キューも入れたのか

理由はシンプルである。

今日、自分がPCの前にいられないからである。

AI開発では、人間が見ていない時間も作業に変えられる可能性がある。

寝ている間。
外出している間。
移動している間。
食事している間。
別作業をしている間。

この時間に、AIが開発用PC上で作業を進めてくれれば、個人開発としてはかなり大きい。

ただし、何でもかんでもAIに任せればよいわけではない。

大量キューは、うまくいけば強い。
しかし、失敗すると差分が大きくなりすぎる。
途中で方針がズレても、そのまま進む。
ドキュメント更新だけに寄る可能性もある。
ビルド失敗後に変な修正が積み重なる可能性もある。

だから、60キュー投入は、かなり攻めた運用である。

3. 今回スコープを広げた理由

最近の開発では、重要な課題が見えてきた。

それは、単純な機能不足ではない。

もっと根本的に、画面体系や導線設計を見直す必要が出てきた。

これまで機能を増やしてきた結果、既存画面に多くの役割が集まりすぎている。
画面数が足りないのに、機能ばかり追加してきた。
その結果、1つの画面に複数の目的が詰め込まれ、ユーザーが迷いやすくなっている。

つまり、導線カオスである。

これは、少しボタンを直せば済む話ではない。
画面の目的、画面数、画面分割、フェーズ別の導線、常時参照画面、イベント発生画面まで含めて見直す必要がある。

そこで今回は、細かい1件だけを直すのではなく、開発スコープを広げた。

画面体系の整理
導線カオスの解消
主要画面の目的整理
P0/P1作業の継続消化
既知ブロッカー・制限事項の扱い
確認用端末に戻すべき観点の整理
正本ルールに沿った進捗報告

こうした範囲をまとめて進める方向にした。

4. 60キューは効率的なのか

以前、Cursorの大量キュー運用についても考えた。

結論としては、正本ルールが弱い状態で50キュー、60キューを積むのは危険である。

しかし、今のように正本ルールがあり、作業優先順位、停止条件、Git運用、完了報告の型があるなら、大量キューはかなり有効になる。

特に、以下のような条件がそろっている場合は強い。

開発用PCが安定して動く
main直作業を禁止している
featureブランチで作業する
ビルドやテスト失敗時の停止条件がある
ドキュメント更新だけに逃げないルールがある
進捗率や残課題を報告させている
確認用端末で再確認すべき範囲を明記させている

この前提なら、大量キューは「危険な暴走」ではなく、外出中の自走開発バッチとして使える可能性がある。

今回は、まさにそれを試している。

5. ただし、怖さもある

もちろん、怖さはある。

60キューも積むと、途中で何か起きたときに、その影響が大きくなる。

たとえば、

早い段階でビルドが壊れる
その状態で後続の修正が走る
原因がズレたまま修正が積み上がる
ドキュメントだけ更新されて実装が進まない
同じファイルに変更が集中する
差分が大きくなりすぎる
外出から戻ったときに把握が大変になる

こうなると、せっかくの自走が逆効果になる。

だから、今回のポイントは、単に60キューを入れることではない。

60キュー入れても暴走しないように、正本ルールと停止条件を整えておくことである。

6. 最近整ってきたプロジェクト管理ルール

ここ最近、かなりプロジェクトマネジメント寄りの整備を進めてきた。

開発用PCと確認用端末の役割分担。
確認用端末によるシナリオ試験。
既知ブロッカー・制限事項台帳。
FixedとConfirmedの分離。
指摘ID単位の管理。
完了報告フォーマット。
進捗率と残り所要時間の報告。
導線カオスの棚卸し。
画面体系の再設計。

これらは、地味だがかなり重要である。

AIを使うと、作業速度は上がる。
しかし、管理が弱いと、作業が増えた分だけ混乱も増える。

だから今は、AIを使う力よりも、AIを管理する力が重要になってきている。

今回の60キュー投入も、ただの勢いではない。

正本ルールが整ってきたからこそ試せる運用である。

7. 今日の外出中に期待していること

今日、外出している間に期待していることは、完璧な完成ではない。

そこまで期待すると危ない。

期待しているのは、以下である。

P0/P1の一部が進む
画面体系整理が進む
導線カオス解消の土台ができる
ドキュメントと実装の整合が進む
自動テストやビルドで大きな破綻が見つかる
次に人間が判断すべきポイントが明確になる
確認用端末に戻すべき再確認範囲が整理される

つまり、外出中にAIが全部終わらせるというより、次の判断材料を作ってくれることを期待している。

AI開発では、AIが勝手にゴールまで行くわけではない。

人間が戻ってきたときに、差分、検証結果、残課題、リスクを確認して、次の判断をする必要がある。

8. 帰ってきたらまず確認すること

外出から戻ったら、いきなり次の指示を出すのではなく、まず確認する。

見るべきものは決まっている。

git status
変更ファイル
commit / push状況
build / lint / test結果
完了報告
進捗率
残課題
リスク・未確認事項
差分が大きくなりすぎていないか
重要ロジックに不用意に触っていないか
ドキュメントだけで終わっていないか
確認用端末で再確認すべき範囲

特に、今回はキュー数が多いので、差分確認が重要になる。

作業が進んでいても、内容がズレていたら意味がない。

大量キューの成否は、最後の検収で決まる。

9. うまく動けばかなり強い

もし今回うまく動けば、これはかなり強い。

外出中に開発が進む。
寝ている間に作業が進む。
人間が戻ってきたら、報告を見て判断する。
必要に応じて確認用端末で実機確認する。
問題があれば開発用PCに戻す。

この流れが回るようになると、個人開発の限界をかなり押し広げられる。

人間1人では、稼働時間に限界がある。

しかし、AIと安定稼働PCを組み合わせると、自分の不在時間も作業時間に変えられる。

もちろん、品質管理は必要である。
ただ、運用が固まればかなり強い。

10. うまく動かなかった場合も学びになる

逆に、今回うまくいかなかったとしても、それはそれで学びになる。

たとえば、

60キューは多すぎた
停止条件が弱かった
指示が曖昧だった
実装よりドキュメントに寄りすぎた
差分が大きくなりすぎた
途中でテスト失敗を引きずった
外出中に任せる作業の種類を絞るべきだった

こうしたことが分かる。

その場合は、次回から改善すればよい。

たとえば、通常は20キュー、就寝時は30キュー、安定作業だけ50キュー以上にする。
DBや認証、課金のような重要領域は10キューで区切る。
導線整理やUI改善のような範囲に限定する。
停止条件をさらに強める。

失敗しても、運用改善につながるなら意味がある。

11. AIを使うというより、AIを運用している

最近、自分の中で感覚が変わってきた。

AIを使っているというより、AIを運用している。

単発で質問するだけではない。
Cursorに作業を積む。
ChatGPTで指示を作る。
開発用PCに自走させる。
確認用端末に試験させる。
ドキュメントでルールを固定する。
完了報告で検収する。
必要ならキュー数や作業範囲を調整する。

これは、かなりプロジェクトマネジメントである。

人間の作業者を管理するのと同じように、AIにも役割、作業範囲、報告形式、停止条件、完了条件が必要になる。

今回の60キュー投入は、その運用実験でもある。

12. 今回の結論

今日は外出するため、開発範囲のスコープを大きく広げて、Cursorに約60キューを投入した。

正直、ちゃんと動くかは少し不安である。

ただし、今は以前よりも運用ルールが整っている。

開発用PCは安定している。
正本ルールもある。
確認用端末との役割分担もある。
ブロッカー管理や制限事項管理も整ってきた。
FixedとConfirmedの区別もある。
導線カオスや画面体系の課題も見えてきた。

だから今回は、外出中の時間を開発時間に変えるために、あえて大きく動かしてみる。

もちろん、60キューは万能ではない。

うまく進むかもしれない。
ズレるかもしれない。
差分が大きくなりすぎるかもしれない。
ドキュメントに寄りすぎるかもしれない。

帰ってきたら、まず検収する。

作業が進んだか。
品質は保てているか。
ビルドやテストは通っているか。
次に何をすべきか。

AIを寝ている間や外出中にも働かせる。
ただし、暴走させない。

このバランスを取れるかどうかが、独力＋AI活用の開発ではかなり重要になってきた。

第50回：設計ミスだった。画面数が足りないのに、機能ばかり追加したらカオスになる

1. はじめに

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

最近、実機確認やシナリオ試験を進める中で、かなり本質的な問題が見えてきた。

それは、導線カオス問題である。

ただし、これは単にUIが悪いとか、デザインが弱いとか、ボタンが多いとか、そういう表面的な話ではない。

もっと根本的には、画面設計のミスだったのだと思う。

画面数が足りない。
画面分割が足りない。
本来は別画面にすべき機能を、既存画面にどんどん追加してしまった。

その結果、1つの画面に複数の目的が詰め込まれ、ユーザーから見ると「この画面で何をすればいいのか」が分かりにくくなっている。

これは、考えてみれば当然だった。

必要な画面を作らずに、機能だけ追加していけば、そりゃカオスになる。

2. 問題は「画面要件の粒度不足」だけではなかった

最初は、画面要件の粒度が粗いことが問題だと思っていた。

画面ごとの目的。
主CTA。
副導線。
表示優先順位。
状態別表示。
空データ表示。
スマホ表示。
受け入れ条件。

こうした画面単位の詳細要件が足りない。

これは確かに問題である。

しかし、さらに深く考えると、それ以前の問題があった。

そもそも必要な画面数が足りていない。

画面が足りないから、既存画面に機能を足す。
既存画面に機能を足すから、その画面の目的がぼやける。
目的がぼやけるから、主導線が分かりにくくなる。
主導線が分かりにくくなるから、ユーザーが迷う。

つまり、画面要件を細かく書けば解決する話ではない。

必要な画面を追加し、分けるべき画面を分ける必要がある。

3. 1画面に詰め込みすぎた

今の問題は、いくつかの中心画面に機能が集中しすぎていることだ。

たとえば、ログイン後の中心画面は、本来であれば「現在の状態」と「次にやること」を示す入口であるべきだ。

しかし、そこにあれもこれも置こうとすると、全機能置き場になってしまう。

詳細画面も同じである。

本来は概要を見る画面なのに、そこに操作、確認、履歴、結果、補足情報、関連情報まで詰め込んでしまうと、何のための画面なのか分からなくなる。

個別の情報は必要かもしれない。
個別の機能も必要かもしれない。

でも、それを全部同じ画面に置く必要はない。

見る画面。
選ぶ画面。
実行する画面。
確認する画面。
結果を見る画面。

これらは、本来分けるべきだった。

4. 機能追加のスピードに、画面設計が追いついていなかった

AIを使っていると、機能追加のスピードはかなり上がる。

アイデアを出す。
仕様を作る。
実装指示を出す。
Cursorがコードを書く。
テストも追加する。
ドキュメントも更新する。

この流れで、かなり速く前に進める。

ただし、その副作用もある。

機能はどんどん増える。
でも、画面体系の整理が追いつかない。

結果として、既存画面にとりあえず機能を追加してしまう。

「この画面に置いておけば、とりあえず使える」
「既にある画面だから追加しやすい」
「別画面を作るより早い」

そうやって短期的には進む。

しかし、長期的には画面が壊れていく。

これは、AI開発の怖いところでもある。

実装速度が上がるほど、設計の粗さも早く露呈する。

5. 常時参照画面と操作画面を混ぜてはいけない

今回かなり重要だと思ったのが、常時参照画面と特定タイミングで操作する画面を分けることだ。

常時参照できる画面は、いつでも見られる必要がある。

たとえば、

自分の状態を見る画面
対象一覧を見る画面
詳細を見る画面
履歴を見る画面
通知を見る画面
ヘルプを見る画面

こういうものは、常にアクセスできてよい。

一方で、特定のタイミングで操作する画面もある。

準備する画面
実行する画面
結果を確認する画面
振り返る画面
イベント発生時だけ出る画面

これらは、常時参照画面とは性質が違う。

ここを混ぜると、導線が崩れる。

常時見られるべき情報と、今だけ操作すべきタスクが同じ強さで並ぶ。
その結果、「今、自分は何をすればいいのか」が分からなくなる。

6. フェーズ別のハブ画面が必要だった

今回の整理で、フェーズ別のハブ画面が必要だと感じた。

ログイン後の中心画面にすべてを置くのではなく、現在の状態に応じた入口を分ける。

たとえば、

準備フェーズ用の画面
実行フェーズ用の画面
結果確認用の画面
振り返り用の画面
イベント確認用の画面

こうした画面を用意する。

ログイン後の中心画面は、全機能置き場ではなく、現在の状態と次にやることを示す入口にする。

そして、実際の細かい操作は、それぞれのハブ画面や専用画面へ逃がす。

これにより、中心画面の情報量を減らせる。

ユーザーに対しても、

「今はこの状態です」
「次にやることはこれです」
「詳しい操作はこちらです」

と案内しやすくなる。

7. 詳細画面も分割が必要

詳細画面も、かなり注意が必要である。

詳細画面は便利なので、つい何でも置きたくなる。

概要。
状態。
操作ボタン。
履歴。
関連情報。
補助説明。
結果導線。
コメント。
レポート。

しかし、詳細画面に全部置くと、その画面の役割が崩れる。

詳細画面は、あくまで概要と状態を把握し、状態に応じた次の導線を出す画面にするべきだと思う。

実行系の操作は、必要に応じて専用画面に分ける。

詳細を見る
操作する
確認する
完了を見る
結果を見る

この流れを分けることで、ユーザーの迷いを減らせる。

8. イベント発生画面も別カテゴリとして考える必要がある

もう一つ大きいのが、イベント発生画面である。

進行型のWebサービスでは、通常画面だけでは足りない。

特定の時期だけ出る画面。
特定の条件で発生する画面。
通知から入る画面。
結果確認で表示される画面。
未処理タスクとして出す画面。
アーカイブとして残す画面。

こうしたイベント系画面を、通常画面に無理やり詰め込むと、また導線がカオスになる。

イベントは、イベントとして別カテゴリで整理する必要がある。

すべてをグローバルナビに置く必要はない。
すべてをダッシュボードに大きく出す必要もない。

重要なイベントは未処理タスクとして表示する。
軽いイベントは通知でよい。
選択が必要なイベントは専用画面にする。
記録として残すものはアーカイブにする。

こういう整理が必要になる。

9. ダッシュボードを全機能置き場にしてはいけない

今回かなり反省しているのは、ダッシュボード的な画面の扱いである。

ダッシュボードは便利である。

何でも置ける。
何でも入口にできる。
各機能へのリンクを置きやすい。
状態表示も置きやすい。

しかし、それが危険である。

ダッシュボードに何でも置くと、すぐに全機能置き場になる。

本来の役割は、ユーザーに現在地と次の行動を示すことだと思う。

だから、ダッシュボードは以下に絞るべきである。

現在の状態
次にやること
未処理タスク
重要通知
主要導線
常時参照ページへの最小限の入口

詳細な情報や低頻度の導線は、別画面やメニュー配下に逃がす。

ダッシュボードは、全部を見せる場所ではない。
迷わず次に進ませる場所である。

10. 画面数を増やすことは悪ではない

画面数が増えると複雑になるのではないか、という考えもある。

もちろん、無計画に増やせば複雑になる。

しかし、必要な画面を作らない方が、もっと複雑になることもある。

1画面に複数目的が混ざる。
1つのカードに複数の導線が入る。
同じ画面で見る、選ぶ、実行する、確認する、結果を見るまでやらせる。
そうなると、見た目は1画面でも、体験としては複雑になる。

画面数を適切に増やすことで、むしろ分かりやすくなる。

重要なのは、画面数を減らすことではない。

ユーザーの目的ごとに、画面を適切に分けることである。

11. 今後は画面体系を再設計する

今後は、画面体系を再設計する必要がある。

まずは、以下のような分類で整理したい。

トップ・認証・初回導線
ダッシュボード
常時参照できる基本画面
準備系画面
実行系画面
結果確認・振り返り系画面
履歴・記録系画面
ニュース・お知らせ系画面
プロフィール・ランキング系画面
ヘルプ・FAQ・用語集
時期・イベント発生画面
管理者画面

このように分類してから、必要な画面を洗い出す。

そのうえで、既存画面に詰め込みすぎている機能を、どの画面へ切り出すかを決める。

12. 詳細要件はP0画面から作る

全画面の詳細要件をいきなり作るのは重い。

だから、まずは画面体系を整理する。
次に、P0画面だけ詳細要件を作る。

各画面について、以下を定義する。

画面の目的
対象ユーザー
到達経路
主導線
副導線
表示情報
情報優先順位
操作・ボタン
状態別表示
エラー・空状態
スマホ表示要件
E2E観点
実機確認観点
受け入れ条件
未確定事項

ここまで整理すれば、AIに実装させるときもブレにくい。

実機確認でも、何を見ればよいか明確になる。

13. これは設計ミスの修正である

今回の問題は、単なる改善ではない。

これは設計ミスの修正である。

機能を増やすことに意識が向きすぎて、画面体系の整理が追いついていなかった。

画面数が足りないのに、機能ばかり追加した。
その結果、既存画面に機能が集中した。
画面ごとの目的がぼやけた。
導線がカオスになった。

ここを認める必要がある。

ただし、気づけたことは大きい。

サービスイン前に気づけたなら、まだ直せる。

今後は、画面数を増やすことを恐れず、必要な画面をきちんと追加する。

そして、各画面の目的を明確にする。

14. 今回の結論

導線カオスの根本原因は、UIの見た目だけではなかった。

画面数が足りなかった。
画面分割が足りなかった。
必要な画面を作らず、既存画面に機能を追加しすぎた。

そりゃカオスになる。

今後は、以下を徹底したい。

画面の目的が違うなら画面を分ける
操作タイミングが違うなら画面を分ける
見る、選ぶ、実行する、確認する、結果を見るを分ける
常時参照画面と特定タイミングの操作画面を分ける
イベント発生画面を別カテゴリとして整理する
ダッシュボードを全機能置き場にしない
詳細画面に全操作を詰め込まない
P0画面から詳細要件を作る

AIを使うと、機能追加は速くなる。

しかし、画面設計を怠ると、速くカオスになる。

今回の学びはそこだ。

これからは、機能を足すだけでなく、画面を分ける。
必要な画面を追加する。
画面ごとの目的を明確にする。

サービスイン前に、この設計ミスを立て直したい。

第49回：導線カオス問題。機能は増えたが、画面の目的が分かりにくくなってきた

1. はじめに

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

最近、開発はかなり進んできた。

画面も増えた。
機能も増えた。
自動テストも整ってきた。
確認用端末での実機試験も始めている。
開発用PCと確認用端末の役割分担も、だいぶ整理されてきた。

ただ、ここに来てかなり重要な問題が見えてきた。

それが、導線カオス問題である。

これは単なるUIの見た目の問題ではない。
ボタンの色が悪いとか、余白が少し狭いとか、そういうレベルではない。

もっと根本的な問題である。

その画面が何のための画面なのか分かりにくい。
操作できる選択肢が多すぎる。
情報量が多すぎて、重要な操作が埋もれている。
ユーザーが次に何をすればよいのか分からない。

これは、サービスイン前にかなり真剣に潰す必要がある。

2. 機能が増えるほど、画面は分かりにくくなる

開発中は、つい機能を増やしたくなる。

この情報も見せたい。
この導線も置きたい。
このボタンも必要そう。
この補助説明もあった方が親切。
この将来機能の入口も先に置いておきたい。

そうやって少しずつ足していくと、画面はどんどん重くなる。

最初はシンプルだった画面が、気づけばリンク、ボタン、カード、説明文、補助情報、ステータス表示でいっぱいになる。

開発者目線では、それぞれに意味がある。
しかし、初見ユーザーから見ると、全部が同じ強さで並んでいるように見える。

結果として、

「で、結局この画面では何をすればいいの？」

となる。

これは非常に危険である。

3. 導線カオスは、バグより分かりにくい

バグは分かりやすい。

ボタンを押してエラーが出る。
画面が壊れる。
データが保存されない。
ログインできない。
処理が失敗する。

こういうものは、比較的見つけやすい。

しかし、導線カオスは分かりにくい。

画面は表示されている。
ボタンもある。
リンクもある。
機能も動いている。

一見すると、問題がないように見える。

しかし、実際に人間が触ると迷う。

どこを押せばいいか分からない。
どの情報が重要か分からない。
なぜ似たようなカードが複数あるのか分からない。
今すぐ使うべき機能と、後で見ればよい情報が混ざっている。

これは、通常の自動テストでは拾いにくい。

だから、確認用端末には通常のバグ探しではなく、人間が触って迷う画面を洗い出す試験をさせる必要がある。

4. 今回確認したい観点

今回の試験では、単に機能があるかどうかを見るのではない。

確認したいのは、以下である。

その画面が何のための画面か一目で分かるか
ユーザーに最初に何をしてほしい画面か分かるか
主要アクションが明確か
ボタンやリンクが多すぎないか
情報量が多すぎて重要な操作が埋もれていないか
初見ユーザーが迷わないか
サービスイン初期に本当に必要なものだけが前面に出ているか

これは、かなり重要な観点である。

今までは「機能を作る」「動くようにする」「エラーを減らす」という意識が強かった。

しかし、サービスとして人に触ってもらうなら、それだけでは足りない。

使えることと、迷わず使えることは違う。

5. 各画面の目的を棚卸しする

今回やるべきことは、各画面の目的の棚卸しである。

それぞれの画面について、まず以下を考える。

この画面は何のための画面なのか。
ユーザーに最初に何をしてほしいのか。
この画面で絶対に必要な操作は何か。
この画面に置かなくてもよい情報は何か。
別画面に逃がすべき機能は何か。

この整理をしないまま機能を増やすと、画面は必ず複雑になる。

特に、ログイン後の中心画面、初回ユーザーが最初に入る画面、主要操作に関わる詳細画面は重要である。

ここがカオスだと、ユーザーは離脱する。

6. Primary Actionを絞る

画面設計で重要なのは、Primary Actionである。

その画面で、ユーザーに一番押してほしいボタンは何か。
一番進んでほしい導線はどれか。

これが分からない画面は弱い。

現状、いろいろな画面で、複数のボタンやカードが同じ強さで並んでいる可能性がある。

そうなると、ユーザーは迷う。

理想としては、

Primary Actionは1つ
Secondary Actionは2〜3個
それ以外は控えめにする
詳細情報は折りたたむ
後回し機能や将来機能は前面に出しすぎない

という形にしたい。

機能を消す必要はない。
ただし、画面上の優先順位は明確にする必要がある。

7. 情報量を減らす勇気

開発していると、情報を出したくなる。

せっかくデータがあるなら表示したい。
せっかく機能があるなら入口を置きたい。
せっかく説明を書いたなら見せたい。

しかし、情報が多いことは、必ずしも親切ではない。

初見ユーザーにとっては、情報が多いほど混乱することがある。

重要情報と補助情報が同じ強さで表示されていると、何を読めばよいか分からない。

だから、情報量を減らす勇気が必要である。

初回に必要な情報だけ出す
補足は折りたたむ
詳細は別画面に逃がす
将来機能は控えめにする
内部的な状態や細かい説明を前面に出しすぎない

これは、かなり大事だと思っている。

8. 新規ユーザー視点が特に重要

既に仕様を知っている自分が触ると、多少画面が複雑でも理解できる。

しかし、新規ユーザーは違う。

初回ログイン後に、何をすればよいか分からない。
専門用語や独自概念が一度に出る。
画面上に複数の導線があり、どれが最初なのか分からない。
空データ状態で何も起きていないように見える。

これでは厳しい。

新規ユーザーには、まず「次にやること」を明確に出す必要がある。

最初からすべての機能を見せるのではなく、最初に進むべき道を示す。

これは、サービスイン初期では特に重要である。

9. 確認用端末にやらせる試験の価値

今回の導線カオス問題は、確認用端末にやらせる価値が高い。

開発用PCは、どうしても実装目線になりやすい。

この機能は動くか。
このテストは通るか。
このエラーは直ったか。
このPRはマージできるか。

一方で、確認用端末には、実際に触った人間目線で見てもらいたい。

初見で迷うか
ボタンが多すぎるか
情報量が多すぎるか
主要導線が見えているか
画面の目的が分かるか
どの画面が一番カオスか

これは、実装側だけでは見落としやすい。

だから、二台運用の意味がある。

開発用PCは作る。
確認用端末は迷う。
迷った箇所を報告する。
開発用PCが整理する。

この流れが重要である。

10. 試験レポートで見たいもの

今回の試験では、単なる不具合一覧ではなく、画面目的棚卸しレポートが必要である。

各画面について、以下のように整理したい。

画面名
想定される本来の目的
現状の印象
迷いやすい点
残すべき主要機能
削る、下げる、別画面に逃がすべき要素
推奨する画面整理方針
重要度
スクリーンショット

さらに、全体サマリーとして以下も欲しい。

最も導線がカオスになっている画面 Top 5
最も情報量が多すぎる画面 Top 5
主要機能が分かりにくい画面 Top 5
初見ユーザーが最初に詰まりそうな箇所
サービスイン前に必ず整理すべきP0指摘一覧
P0ではないが品質に大きく影響するP1指摘一覧
全画面共通の改善方針
開発用PC側に実装依頼すべき改善案

ここまで整理できれば、かなり次の改善に使える。

11. 点数化する意味

各画面について、5段階で点数化するのも有効だと思っている。

観点は以下である。

目的明確度
主要アクション明確度
情報量適正度
導線整理度
初見ユーザー理解度
サービスイン適合度

点数化すると、感覚論だけでなく、優先順位を付けやすくなる。

たとえば、ある画面が以下のような状態なら、かなり危険である。

目的明確度：2
主要アクション明確度：1
情報量適正度：2
導線整理度：1
初見ユーザー理解度：1
サービスイン適合度：2

こういう画面は、単なる見た目改善ではなく、P0/P1として扱うべきである。

12. サービスイン初期では、機能を前に出しすぎない

サービスイン初期に大事なのは、何でも見せることではない。

むしろ、最初は絞るべきである。

ユーザーが最初にやるべきこと。
中心になる体験。
最低限確認すべき情報。
次に進むための導線。

これだけを分かりやすく出す。

将来機能、補助情報、詳細データ、ランキング、細かい履歴、管理寄りの導線などは、必要に応じて下げる。

全部をトップレベルに出すと、サービスの魅力が伝わるどころか、逆に分かりにくくなる。

機能が多いことを良いことと評価しない。

これが大事である。

13. 今回の結論

導線カオス問題は、単なるUIの見た目問題ではない。

これは、画面設計、情報設計、導線設計の問題である。

各画面に操作できる選択肢が多すぎる。
画面ごとの主要目的が分かりにくい。
本来その画面で何をすればよいのかが直感的に分からない。
リンク、ボタン、カード、補助情報が多く、導線がカオス状態になっている。
情報量が多すぎて、重要な操作が埋もれている。

この状態では、機能があっても使われない。

だから今、確認用端末を使って、各画面の目的と導線を棚卸しする。

見るべきなのは、バグだけではない。

人間が触って迷うかどうか。
初見で何をすればよいか分かるか。
主要アクションが見えているか。
情報量が過剰ではないか。
サービスイン初期に本当に必要なものだけが前面に出ているか。

これを確認する。

今回の試験で出てくる指摘は、単なるUI改善ではない。
サービスイン前のP0/P1整理として扱うべきである。

機能を増やすフェーズから、画面の目的を絞るフェーズへ。

ここを越えないと、人に見せられるサービスにはならないと思っている。

2026年5月2日土曜日

第48回：AI活用にも成熟度がある。AIを使えることより、AIを管理できることが重要になる

1. はじめに

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

最近、ChatGPT、Cursor、Gensparkなど、かなり多くのAIツールを使っている。

企画整理、仕様整理、実装指示、コード修正、テスト、ドキュメント整備、進捗管理、ブログ記事作成。
AIが関わる範囲は、かなり広がってきた。

最初は、AIを便利な相談相手として使っていた。
しかし、今はもう少し違う段階に入っている。

AIに作業をさせる。
AIに報告させる。
AIにテスト観点を出させる。
AIに残課題を整理させる。
複数のAIや端末を役割分担させる。
その結果を人間が確認し、統合し、判断する。

ここまで来ると、単なる「AI活用」ではなく、ほとんどAIチーム運営に近い。

そこで今回は、自分なりに AI活用成熟度モデル として整理してみたい。

2. AI活用には段階がある

AI活用という言葉はかなり広い。

メール文を整えるだけでもAI活用である。
コードを書かせるのもAI活用である。
複数AIを使って開発プロジェクトを回すのもAI活用である。

しかし、これらは同じレベルではない。

AI活用には段階がある。

最初は、AIを個人の相談相手として使う。
次に、作業単位でAIに成果物を作らせる。
さらに進むと、業務プロセスやプロジェクト運営にAIを組み込む。
高度な段階では、複数AIを役割分担させ、プロジェクトマネジメントの知識で統制する必要が出てくる。

つまり、AI活用の成熟度は、単に「AIを使っているかどうか」では測れない。

AIをどれだけ管理可能な形で成果に結びつけているかが重要になる。

3. レベル0：AI未活用

まず、AIをほとんど使っていない段階である。

調査、文章作成、設計、開発、レビュー、進捗管理を、人間が従来どおり行う。

もちろん、これは悪いことではない。
AIなしでも仕事はできる。

ただし、作業速度は人間の経験と稼働時間に依存する。
品質も属人化しやすい。
ベテランがいれば強いが、ナレッジが個人に閉じやすい。

AI活用という意味では、まだスタートラインの手前である。

4. レベル1：個人の補助ツールとして使う

次に、AIを個人の補助ツールとして使う段階である。

たとえば、

メール文を整える
文章を要約する
アイデア出しをする
簡単な調査をする
コードの一部を書かせる

この段階では、AIは便利な相談相手である。

個人の作業効率は上がる。
ただし、プロジェクト全体にはまだ組み込まれていない。

成果物の責任は完全に人間側にある。
AIの出力をそのまま信じてしまうと、事実誤認や品質低下が起きる。

この段階では、「AIを使っている人」と「使っていない人」で個人差が出やすい。

5. レベル2：作業単位でAIを活用する

次は、AIに明確なタスクを渡して、作業単位で成果物を作らせる段階である。

たとえば、

仕様書のたたき台を作る
テスト観点を洗い出す
エラー原因を分析する
画面設計案を出す
コード修正案を作る
議事録を整理する

このあたりから、作業効率はかなり上がる。

ただし、タスクの粒度が曖昧だと、成果物がぶれる。
未確認事項が混入する。
作業範囲が勝手に広がる。

AIは、はっきりした依頼には強い。
しかし、曖昧な依頼では、それっぽいが使いにくい成果物を出してくることがある。

この段階では、AIへの指示力が重要になる。

6. レベル3：業務プロセスにAIを組み込む

さらに進むと、AIを単発作業ではなく、業務フローの一部として使うようになる。

たとえば、

要件定義から設計書作成までAIに補助させる
不具合報告から原因分析・修正案作成までAIを使う
テスト結果から改善課題を抽出する
会議録から課題一覧・ToDo一覧を生成する
定型的なレビュー観点をAIに確認させる

ここまで来ると、AIは個人の便利ツールではなく、業務プロセスの一部になる。

ただし、プロセスが整っていないとAI活用も不安定になる。
課題管理や品質管理がないと、手戻りが増える。
AIが作った成果物が管理されず、あちこちに散らばる。

この段階では、AIそのものよりも、AIを組み込む業務フローの設計が重要になる。

7. レベル4：AIをプロジェクト運営に組み込む

次は、AIをプロジェクト全体の運営に使う段階である。

たとえば、

残課題一覧をAIに整理させる
不具合一覧をAIに更新させる
進捗報告をAIに要約させる
リリース判定チェックリストをAIに作らせる
仕様変更の影響範囲をAIに洗い出させる
テスト結果からリスクを整理させる

この段階では、AIがPMO的な補助を始める。

プロジェクト管理資料の更新にAIが関与する。
進捗、課題、品質、リスクの見える化を支援する。

ただし、ここにも危険がある。

AIが管理資料を増やしすぎる。
進捗しているように見えて、実態が伴わない。
確認済みと未確認の区別が曖昧になる。

AIに管理資料を作らせる場合、その管理資料自体の品質管理が必要になる。

8. レベル5：複数AIを役割分担させて使う

さらに進むと、複数のAIを役割ごとに使い分ける段階になる。

たとえば、

実装担当AI
レビュー担当AI
テスト観点整理AI
UI改善提案AI
ドキュメント整理AI
プロジェクト管理補助AI
調査担当AI

この段階になると、AIを単体ではなく、複数の専門役割として使うようになる。

作業速度は大幅に上がる可能性がある。
しかし、同時に管理も難しくなる。

AI同士の作業が競合する。
同じ問題を別々に修正する。
方針が分裂する。
成果物の整合性が崩れる。
人間側が統合しきれなくなる。

ここから先は、単なるAI活用ではなく、AIチーム運営に近くなる。

9. レベル6：プロジェクトマネジメントで複数AIを統制する

ここが、現実的な意味でかなり高い到達点だと思う。

複数のAIを、プロジェクトマネジメントの知識を使って統制する段階である。

AIを単に便利な道具として使うのではない。
プロジェクト内の実行主体として位置づける。

人間は、AIに対して以下を管理する。

目的
スコープ
優先順位
制限事項
課題
不具合
変更
品質基準
完了条件
進捗
リスク
成果物の統合

たとえば、実装AIにはP0/P1タスクを渡す。
レビューAIには品質観点を渡す。
テストAIにはE2E観点を渡す。
ドキュメントAIには変更差分だけを反映させる。

そして、人間が全体方針、優先順位、リリース判断を行う。

この段階では、AIを使う力ではなく、AIを管理する力が問われる。

プロンプト力だけでは不十分である。
必要なのは、プロジェクトマネジメント力である。

10. レベル7：AI-PMO化

レベル6の上にあるのが、AI-PMO化である。

AIを個別作業者として管理するだけでなく、プロジェクト管理そのものの一部をAIに担わせる段階である。

AIが以下を支援する。

課題一覧の更新
不具合傾向の分析
進捗遅延の検知
品質リスクの検出
スコープ変更の影響分析
リリース判定の補助
優先順位案の提示
次に着手すべき作業の提案
会話、ドキュメント、Git差分から状況を整理する

この段階では、AIは作業者ではなく、PMO補佐になる。

ただし、判断責任は人間に残る。

AI-PMOは、プロジェクト状態を見える化し、判断材料を出す。
しかし、リリースするか、止めるか、優先順位をどうするかは人間が決める。

ここを間違えると、AIの進捗判断を過信してしまう。

整った報告に見えて、実態が伴っていないこともある。

11. レベル8：AIオーケストレーション

さらに上位になると、AIオーケストレーションである。

複数AI、複数ツール、複数プロジェクトを横断して、人間が全体を設計・統制する段階である。

たとえば、

開発AI
QA AI
ドキュメントAI
調査AI
マーケティングAI
SEO AI
顧客対応AI
分析AI
PMO AI

こうしたAI群を連携させ、プロジェクト全体、あるいは複数プロジェクト全体を動かす。

ここまで来ると、AIを単体で使う話ではない。

AIごとの役割、権限、入力、出力、品質基準を設計する必要がある。
プロジェクト、運用、改善、分析がつながる。

この段階の本質は、AIを使うのではなく、AIを組織化することである。

12. レベル9：AIネイティブ組織・AIネイティブ事業運営

最上位は、AIネイティブ組織・AIネイティブ事業運営である。

AIが補助的に使われるのではない。
最初からAI活用を前提に、業務、組織、プロジェクト、品質管理、意思決定プロセスが設計されている状態である。

この段階では、

AI活用を前提に業務プロセスが設計されている
AIごとの役割と責任範囲が定義されている
AI出力の検証プロセスが標準化されている
AIによる課題検知、改善提案、品質分析が日常化している
人間は最終判断、戦略、価値判断、リスク判断に集中する
AI活用の成果が、個人の能力ではなく組織能力になっている

AIを使うこと自体が特別ではなく、業務の前提になっている。

これは、AIを使う組織ではない。
AIを前提に設計された組織である。

13. まとめ表

整理すると、以下のようになる。

レベル	名称	状態
0	未活用	AIを使っていない
1	個人補助	個人の相談相手・文章補助として使う
2	タスク活用	単発作業をAIに任せる
3	プロセス活用	業務フローの一部にAIを組み込む
4	プロジェクト運営補助	課題・不具合・進捗・品質管理にAIを使う
5	複数AI分業	複数AIを役割別に使い分ける
6	AIチーム管理	PM知識で複数AIを統制する
7	AI-PMO化	AIがプロジェクト管理そのものを補助する
8	AIオーケストレーション	複数AI・複数業務・複数プロジェクトを統合運用する
9	AIネイティブ組織	AI活用を前提に組織・業務・意思決定が設計されている

14. 自分はいまどの段階にいるのか

自分の今の状態は、レベル5からレベル6に入り始めている感覚である。

複数のAIや端末を役割分担させている。
実装担当、確認担当、方針整理、ドキュメント整理、テスト支援のように使い分けている。

さらに、最近はそれらをプロジェクトマネジメントの考え方で統制しようとしている。

役割分担
作業範囲
進捗報告
残課題管理
ブロッカー管理
制限事項管理
FixedとConfirmedの分離
再確認条件
完了報告フォーマット
リスクと未確認事項の明示

ここまで来ると、AIを便利に使うというより、AIチームを管理している感覚に近い。

これはかなり面白い。

同時に、かなり難しい。

15. 一番重要な主張

今回のモデルで一番言いたいのは、これである。

AI活用の成熟度は、どれだけ高度なAIを使っているかではなく、AIをどれだけ管理可能な形で成果に結びつけているかで決まる。

もっと短く言うなら、

AI活用の本当の成熟度は、AIを使えることではなく、AIを管理できることで決まる。

これはかなり重要だと思っている。

AIを使うだけなら、誰でもできる。
しかし、AIの成果物を品質管理し、進捗管理し、プロジェクト成果につなげるのは簡単ではない。

そこには、プロジェクトマネジメントが必要である。

16. 今回の結論

AI活用には段階がある。

最初は、AIを個人の相談相手として使う段階である。
次に、AIに作業単位で成果物を作らせる段階に進む。
さらに進むと、AIは業務プロセスやプロジェクト運営の中に組み込まれていく。

そして高度な段階では、複数のAIを役割分担させ、プロジェクトマネジメントの知識を使って統制する必要が出てくる。

この段階では、AIを使う力よりも、AIを管理する力が重要になる。

AIを使うだけでは足りない。
AIを管理する。
AIの成果物を検収する。
AI同士の競合を防ぐ。
AIの出力をプロジェクト成果につなげる。

ここまでできて初めて、AI活用は成熟していく。

独力＋AI活用で月商1億円を目指すなら、単に良いAIを使うだけではだめだ。

AIをチームとして扱い、プロジェクトとして管理する。

これが、これからの自分の大きなテーマになっていくと思う。

第47回：AI開発でも、結局プロジェクトマネジメントが重要になる

1. はじめに

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

最近、開発用PC、確認用端末、ChatGPT、Cursor、自動テスト、ドキュメントを組み合わせながら、かなり本格的に開発を進めている。

AIを使うと、実装スピードは確かに上がる。

アイデアを整理できる。
実装指示を作れる。
コードを書ける。
テストも作れる。
ドキュメントも整備できる。
ブログ記事まで書ける。

ただし、ここまで進めてきて強く感じることがある。

AIを使うほど、プロジェクトマネジメントの考え方が重要になる。

AIがいるから管理が不要になるわけではない。
むしろ逆である。

AIを複数使い、PCも複数台使い、ドキュメントも増え、試験も増えてくると、役割分担、進捗管理、課題管理、不具合管理、制限事項管理、Close条件がないとすぐに混乱する。

最近、そのあたりの整備がかなり進んできた。

2. AIは作業者になるが、管理者ではない

AIは強力な作業者である。

しかし、AIはプロジェクト全体の責任者ではない。

AIは言われたことをやる。
ただし、たまにズレる。
実装してほしいのにドキュメントを直す。
YES / NOで聞いているのに曖昧に返す。
修正済みと言いながら、確認条件が弱い。
前提が変わっているのに、そのまま進めようとする。

だから、人間側が管理しなければならない。

自分はPMPの資格を持っていることもあり、プロジェクトマネジメントの考え方はかなり意識している。

人間のチームでも、役割、責任、進捗、課題、リスク、完了条件が曖昧ならプロジェクトは崩れる。

AIを使う場合も同じである。

むしろ、AIは速く動く分、管理が弱いとズレも高速で積み上がる。

3. 役割分担がかなり整理されてきた

現状、開発体制はかなり整理されてきた。

ざっくり言うと、以下の役割分担である。

領域	役割
開発用PC	実装、修正、ビルド、自動テスト、PR対応
確認用端末	実機UI確認、シナリオ試験、スクリーンショット、再確認
ChatGPT	方針整理、指示文作成、記事化、判断補助
Cursor	実装作業、修正、テスト追加、ドキュメント更新
ドキュメント	正本ルール、残課題、制限事項、試験結果、進捗記録

以前は、確認用端末にも実装をさせようとして、やや混乱した。

しかし今は、開発用PCを主戦場にし、確認用端末は常時並行開発ではなく、節目レビューや実機確認に寄せる形になっている。

これはかなり良い。

開発用PCは作る。
確認用端末は見る。
確認用端末がP0/P1を出す。
開発用PCが直す。
確認用端末が再確認する。

この流れが見えてきた。

4. 制限事項とブロッカー管理も整ってきた

最近かなり重要だと感じているのが、制限事項とブロッカー管理である。

試験をすると、いろいろな問題が出る。

ただし、それらを全部同じ扱いにすると混乱する。

本当に今すぐ直すべき不具合。
既に分かっている制限事項。
まだ未実装の範囲。
後回しにしている機能。
上流の問題が原因で確認できない下流工程。

これらを分けないと、同じ問題を何度も報告してしまう。

そこで、既知ブロッカーや制限事項を管理する台帳を整備した。

この台帳では、以下を整理する。

既知ブロッカー
制限事項
何が何にブロックされているか
再開条件
開発残課題との関係
後回し機能との関係
開発用PCが対応すべきか
確認用端末が再試験すべきか

これにより、確認用端末が同じ制限事項を毎回P0/P1として量産することを防げる。

また、上位ブロッカーが未解消なのに、下流工程を無理に何度も試験する無駄も減らせる。

これはかなりプロジェクト管理らしい整理になってきた。

5. 「Fixed」と「Confirmed」を分ける考え方

不具合管理で特に重要なのが、Close条件である。

開発用PCが直しただけでは、完了ではない。

開発側が修正した状態は、あくまで Fixed。
確認用端末が再確認して、実際に解消を確認した状態が Confirmed。

この考え方を明確にした。

これは非常に重要である。

開発側は「直した」と思っている。
でも、確認側で見ると直っていないことがある。
別の状態では再発することもある。
期待した改善と違うこともある。

だから、BOSPCが直しただけではClose相当にしない。
Surfaceが再確認してConfirmedになって初めてClose相当とする。

このルールが入ったことで、かなり品質管理らしくなってきた。

6. 重複指摘と無駄な再試験を防ぐ

確認用端末で試験を回すと、同じような指摘が何度も出る可能性がある。

たとえば、上流の問題が原因で後続画面に進めない場合、下流の確認項目が全部失敗する。

そのたびに新規P0を作っていたら、残課題が爆発する。

そこで、今は以下の考え方を入れている。

同一不具合を重複登録しない
上位ブロッカー配下の下流工程を無理に繰り返し試験しない
制限事項を毎回P0/P1として量産しない
上位ブロッカーが未Fixedなら、下流工程はBlocked byとして整理する
別原因の問題なら新しいIDを採番する

これは、AIを使った試験運用ではかなり大事である。

AIは指示すれば真面目に試験してくれる。
しかし、前提を管理しないと、同じ問題を大量に報告することがある。

だから、試験そのものだけでなく、試験結果の整理ルールが必要になる。

7. 完了報告もかなり整ってきた

開発用PC側の完了報告も、かなり整ってきた。

今は、単に「作業しました」ではなく、以下のような項目を求めるようにしている。

作業ブランチ
commit hash
push先
変更ファイル
実装内容
実行した確認
省略した確認と理由
初期公開への進捗率
正式公開への進捗率
前回比
根拠
残り所要時間
リスク・未確認事項
確認用端末で再確認すべき範囲
指摘IDごとの対応状況

これは地味だが、かなり重要である。

AIの作業報告は、放っておくと都合よく省略されることがある。

だから、報告項目を固定する。

プロジェクトマネジメントでは、報告の型が重要である。
型があれば、比較できる。
抜け漏れに気づける。
次の判断ができる。

8. 新規ドキュメントを増やしすぎない判断も重要

以前は、何か新しい問題があるたびに、新規ドキュメントを追加しようとしていた。

しかし、最近は少し考え方を変えている。

新規ドキュメントを増やしすぎると、管理対象が増える。
どれが正本か分からなくなる。
AIも迷う。
人間も読むのが大変になる。

今回確認したところ、2台PC運用、制限事項、ブロッカー、Close条件、完了報告ルールなどは、既存ドキュメントにかなり反映されていた。

つまり、新しいドキュメントを追加するより、既存ルールの微修正で十分な状態になっている。

これは良い傾向である。

プロジェクト管理では、ドキュメントを作ること自体が目的ではない。

目的は、プロジェクトを進めること。
混乱を減らすこと。
判断を速くすること。
品質を上げること。

そのためには、ドキュメントも増やしすぎず、正本に集約することが大事である。

9. まだ軽微な整合課題はある

もちろん、まだ完全ではない。

細かい整合課題はある。

たとえば、ある参照ファイルが実際に存在するか確認が必要なケース。
また、以前の指標が一部残っていて、現在の方針と少し表現が揺れているケース。

こうしたものは大きな問題ではない。
しかし、AIに作業させる場合は、こういう小さな揺れが誤解の原因になる。

だから、今後は大規模な追加ではなく、既存ルールの微修正で整えていけばよい。

特に、主指標と補助指標の整理はしておきたい。

今は、初期公開への進捗率と正式公開への進捗率を主指標にしている。
以前使っていた確認版の進捗率は、必要に応じた補助指標に寄せた方がきれいである。

こうした細かい整合が、AI運用では効いてくる。

10. AI開発でもPMBOK的な考え方が効く

今回あらためて感じたのは、AI開発でもPMBOK的な考え方がかなり効くということだ。

たとえば、

スコープ管理
スケジュール管理
品質管理
リスク管理
課題管理
変更管理
コミュニケーション管理
ステークホルダー管理
進捗報告
完了条件の定義

これらは、人間のプロジェクトだけでなく、AIを使った個人開発にもそのまま必要である。

むしろ、AIは高速で作業するため、管理の甘さがすぐに大きなズレになる。

AIに任せるだけではだめである。
AIを管理する必要がある。

その意味で、プロジェクトマネジメントの考え方は、AI活用の土台になる。

11. 現状はかなり良い形に近づいている

今の開発プロセスは、まだ完璧ではない。

しかし、かなり良い形に近づいていると思う。

開発用PCと確認用端末の役割が分かれてきた。
Surface報告があればP0/P1を優先し、なければ開発用PCは止まらず自走する。
既知ブロッカーと制限事項を台帳化した。
FixedとConfirmedを分けた。
重複指摘や無駄な再試験を防ぐルールも入ってきた。
完了報告にも進捗率、根拠、残り時間、リスクを含めるようになってきた。

これは、独力＋AI活用としてはかなり実用的なプロセスになってきている。

単にAIにお願いしているだけではない。

AIを作業者として使い、PCを役割分担し、ドキュメントでルールを固定し、報告で検収する。

これは、かなりプロジェクトマネジメントそのものだと思う。

12. 今回の結論

AIを使った開発では、プロジェクトマネジメントの考え方が非常に重要である。

AIがあるから管理が不要になるのではない。
AIがあるからこそ、管理が必要になる。

役割分担。
制限事項管理。
ブロッカー管理。
残課題管理。
後回し機能の切り分け。
FixedとConfirmedの違い。
再試験範囲の限定。
完了報告の型。
進捗率と根拠。
残り所要時間。
リスクと未確認事項。

これらを整えることで、AI開発はかなり安定する。

現状、かなり反映できてきている。

新規ドキュメントを増やす段階ではなく、既存ルールを微修正しながら運用を固める段階に入っていると思う。

独力＋AI活用で月商1億円を目指すには、アイデアや実装力だけでは足りない。

AIをどう管理するか。
複数端末をどう役割分担するか。
不具合をどう閉じるか。
試験結果をどう次の実装につなげるか。

そこまで含めて、プロジェクトである。

AI時代でも、結局プロジェクトマネジメントは強い。

むしろ、AI時代だからこそ、プロジェクトマネジメントがさらに重要になってきている。

第46回：既知ブロッカーと制限事項の台帳を作ることにした

1. はじめに

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

最近は、開発用PCと確認用端末を分けて使う体制がかなり固まってきた。

開発用PCでは、実装、修正、自動テスト、ビルド確認、PR作成を進める。
確認用端末では、実機UI確認、シナリオ試験、スクリーンショット取得、試験報告を行う。

この分担はかなり有効だと思っている。

ただ、運用しているうちに、別の問題も見えてきた。

確認用端末が試験をすると、当然いろいろな問題が出てくる。
しかし、その中には、すぐ直すべき不具合もあれば、既に分かっている制限事項もある。
さらに、上流の問題が解消しない限り、下流の画面や操作を何度試しても意味がないケースもある。

このままだと、同じ問題を何度も報告してしまう。
既知の制限事項を毎回P0/P1として量産してしまう。
本来は上流ブロッカーを直すべきなのに、下流の現象ばかり追ってしまう。

そこで、既知ブロッカー・制限事項の台帳を作ることにした。

2. なぜ台帳が必要なのか

確認用端末の試験は重要である。

実際に画面を触ることで、自動テストでは拾いにくい違和感や導線の弱さが見えてくる。
シナリオ試験をすると、単体画面では分からない流れの詰まりも見つかる。

ただし、試験を増やすほど問題も起きる。

一番困るのは、既知のブロッカー配下で、同じような指摘が増え続けることである。

たとえば、ある上流処理が詰まっていて、そこから先の操作に進めない状態があるとする。

その状態で下流の確認を何度も行うと、

この画面に進めない
この操作ができない
この後続機能を確認できない
このシナリオが完走できない

という指摘が大量に出てくる。

しかし、根本原因は一つかもしれない。

その場合、本当に直すべきなのは上流ブロッカーであり、下流の指摘を大量に増やすことではない。

だから、既知ブロッカーとその影響範囲を台帳で管理する必要がある。

3. 残課題一覧とは役割が違う

ここで大事なのは、既知ブロッカー台帳は、残課題一覧の代わりではないということだ。

それぞれ役割が違う。

管理対象	役割
既知ブロッカー・制限事項台帳	試験可否、Blocked by、再開条件を管理する
残課題一覧	開発用PCが実装する課題を管理する
後回し機能一覧	初期公開では追わない機能や将来対応を管理する

これを混ぜると、運用が混乱する。

確認用端末が見つけた問題を、全部そのまま開発残課題に入れると、残課題一覧が膨れ上がる。
逆に、後回し機能として登録していたものが、実は主要導線を止めている場合もある。

その場合は、後回しではなく、ブロッカーまたは残課題として再分類しなければならない。

つまり、台帳の役割は、単に問題を増やすことではない。

何が試験を止めているのか。
何が既知の制限事項なのか。
何を直せば再試験できるのか。

これを整理することである。

4. 台帳で管理したいもの

今回作りたい台帳で管理するのは、主に以下である。

既知ブロッカー
制限事項
Blocked by 関係
再開条件
残課題一覧との関係
後回し機能一覧との関係
開発用PCが対応すべきか
確認用端末が再試験すべきか

特に重要なのは、Blocked by 関係である。

下流の問題が、上流のどの問題によって確認不能になっているのか。
これを明確にする。

たとえば、ある初期導線が詰まっているため、後続の確認ができない。
この場合、後続の確認項目を全部P0にするのではなく、

上位ブロッカーが未解消のため、後続項目はBlocked byとして扱う

という整理にする。

これで、無駄な試験と重複報告を減らせる。

5. 状態を整理する

台帳には状態も必要である。

最低限、以下のような状態を使いたい。

状態	意味
New	新規に確認された状態
Blocked	上位問題や環境不足などで確認できない状態
Fixed	開発用PCが修正した状態。ただし再確認前
Confirmed	確認用端末が再確認し、解消を確認した状態
Reopen	再確認で未修正または再発を確認した状態
Backlog	後回しにする状態
Won’t fix	対応しない判断。理由必須
Limitation	現時点の制限事項として扱う状態

ここでも重要なのは、FixedとConfirmedを分けることである。

開発用PCが修正しただけでは、まだ完了ではない。
確認用端末が再確認して、解消を確認して初めてConfirmedになる。

これは、前回考えたMarkdown運用のClose相当ルールともつながる。

6. 既知ブロッカー配下を何度も試験しない

今回の台帳で一番効果が出そうなのは、既知ブロッカー配下の再試験抑制である。

確認用端末が長編シナリオ試験をしていると、途中で詰まることがある。

そのとき、下流工程を無理に全部確認しようとすると、試験結果が膨大になる。
しかも、多くは同じ上流原因に起因する可能性がある。

だから、今後はこうする。

上位ブロッカーが未Fixedの場合、下流工程を無理に繰り返し試験しない。
下流工程はBlocked byとして記録する。
上位ブロッカーがFixedになった後、指定範囲だけ再試験する。

これにより、確認用端末の作業効率が上がる。

AIツールの消費も減る。
報告書も読みやすくなる。
開発用PCも、どこを直せばよいのか判断しやすくなる。

7. 既知の制限事項を毎回P0/P1にしない

もう一つ重要なのは、制限事項の扱いである。

現時点では、まだすべての機能や導線が完成しているわけではない。
そのため、今は確認できない範囲もある。

それを毎回P0やP1として報告してしまうと、開発側の優先順位が崩れる。

すでに分かっている未実装範囲。
意図的に後回しにしている範囲。
現時点では確認できない範囲。

こうしたものは、制限事項として台帳に記録する。

そして、同じ理由で毎回新規P0/P1にしない。

ただし、別原因の問題が見つかった場合は、新しい指摘IDを採番する。

この切り分けが重要である。

8. 台帳は確認用端末ではなく開発用PC側で準備する

今回の判断として、台帳とルール整備は、確認用端末ではなく開発用PC側で行うのがよい。

理由はシンプルである。

確認用端末は、検証担当である。
実機確認、シナリオ試験、スクリーンショット、再確認に集中させたい。

そこに管理設計や台帳構造の整備までやらせると、また混乱する。

以前も、確認用端末に広い裁量を持たせすぎると、実際の試験ではなく、テンプレート作成やドキュメント作業に寄ってしまうことがあった。

だから、今回は開発用PC側で台帳を準備する。

そのうえで、確認用端末は台帳を見て試験する。
開発用PCは台帳を見て修正する。
両方が同じルールで動く。

この形がよい。

9. 今回は実装しない

今回の作業は、アプリ本体の実装ではない。

UI修正もしない。
DB変更もしない。
E2E修正もしない。

やるのは、ドキュメント、台帳、Cursor指示文の整備である。

これは一見、地味な作業である。

しかし、今後の開発効率にはかなり効くと思っている。

試験結果、既知ブロッカー、制限事項、残課題、後回し機能が混ざったままだと、開発が進むほど混乱する。

今のうちに分類ルールを作っておくことで、後の試験と修正の流れがかなり楽になるはずである。

10. 繰り返し指示にも反映する

台帳を作るだけでは足りない。

今後の繰り返し指示にも反映する必要がある。

開発用PC向けには、以下のような内容を入れたい。

確認用端末の報告がある場合は、既知ブロッカー・制限事項台帳も確認する。
既知ブロッカーはID単位でP0/P1を優先する。
修正後はFixedとして、commit、修正ファイル、検証結果、再確認対象を明記する。
Blocked by配下の下流工程を個別に大量修正対象にせず、まず上位ブロッカーを解消する。
Close相当は確認用端末の再確認でConfirmedになった場合のみとする。

確認用端末向けには、以下のような内容を入れたい。

試験前に既知ブロッカー・制限事項台帳を確認する。
Blocked byの上位IDが未Fixedの場合、下流工程を無理に再試験しない。
制限事項に登録済みの内容は、同じ理由で新規P0/P1にしない。
別原因の場合のみ、新しい指摘IDを採番する。

これで、台帳が実際の運用に組み込まれる。

11. 台帳を作ることで期待する効果

今回の台帳で期待している効果は大きい。

期待効果	内容
重複指摘の削減	同じ問題を何度もP0/P1にしない
試験効率の向上	上位ブロッカー配下を無理に繰り返し試験しない
優先順位の明確化	まず直すべき上位ブロッカーが見える
開発側の判断改善	残課題、制限事項、後回し機能を切り分けられる
確認側の負担軽減	再試験範囲を絞れる
古い指摘の保全	過去の報告やスクショを捨てずに扱える

特に、長編シナリオ試験では効果が大きいはずである。

途中で詰まったときに、下流工程を全部P0にしない。
上位原因を記録し、下流をBlocked byとして整理する。

この運用ができると、試験結果がかなり読みやすくなる。

12. 今回の結論

確認用端末と開発用PCの連携は、かなり形になってきている。

ただし、試験結果、既知ブロッカー、制限事項、残課題、後回し機能が混ざると、運用が混乱する。

そこで、既知ブロッカー・制限事項台帳を作ることにした。

この台帳は、残課題一覧の代わりではない。
後回し機能一覧の代わりでもない。

役割は、試験可否、Blocked by、再開条件、制限事項を管理することである。

開発用PCは、この台帳を見て上位ブロッカーを優先修正する。
確認用端末は、この台帳を見て無駄な下流試験を避ける。
修正後はFixed、再確認後にConfirmed。
ConfirmedがClose相当である。

今回はアプリ本体を直すわけではない。
しかし、これは今後の開発と試験を安定させるための重要な整備である。

AIと複数端末を使った開発では、作業量を増やすだけでは足りない。

何を試験するのか。
何が既知なのか。
何がブロッカーなのか。
何を後回しにするのか。
何が解消されたら再開するのか。

これを整理する必要がある。

今回の台帳作りは、そのための一歩である。

第45回：GitHub Issueを使わず、Markdownだけで試験指摘を閉じる運用を考えた

1. はじめに

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

最近は、開発用PCと確認用端末を分けて、開発と試験を並行できる体制を整えている。

開発用PCは実装、修正、自動テスト、ビルド、PR作成を担当する。
確認用端末は実機UI確認、シナリオ試験、スクリーンショット取得、試験報告を担当する。

この分担はかなり形になってきた。

ただし、問題も見えてきた。

確認用端末が指摘する。
開発用PCが修正する。
でも、その指摘がどの修正で直ったのか。
再確認されたのか。
まだ未対応なのか。
後回しなのか。

ここが追いづらい。

前回は、GitHub Issueを使えばよいのではないかと考えた。
しかし、今すぐ外部チケット運用を増やすと、逆に管理対象が増えすぎる可能性もある。

そこで今回は、GitHub Issue運用は使わず、docs配下のMarkdownだけで、試験 → 修正 → 再試験 → Close相当まで回す軽量運用を考えることにした。

2. 今回やりたいこと

今回やりたいのは、新しいツールを増やすことではない。

GitHub Issueを使わない。
外部チケット管理も増やさない。
既存のMarkdown運用の中で、確認用端末と開発用PCの連携を少しだけ強くする。

追跡したいのは、以下である。

確認用端末がどの試験を実施したか
どの指摘を出したか
開発用PCがどの指摘を確認したか
どのcommitで修正したか
どのブランチ・commitに反映されたか
修正後に再試験されたか
最終的にClose相当になったか
まだReopen、Backlog、Blockedなのか

つまり、目的はシンプルである。

指摘を出しっぱなしにしない。
修正しっぱなしにしない。
再確認まで含めて状態を閉じる。

3. 現状の弱点

今の開発プロセスでは、試験と修正の流れ自体はできている。

確認用端末が試験する。
Markdownで報告する。
開発用PCがP0/P1を優先して修正する。
commit、push、検証結果を報告する。
必要に応じて確認用端末が再確認する。

ここまでは良い。

ただし、指摘単位で見ると弱い。

たとえば、確認用端末が、

UI-20260502-001
主要画面の導線が分かりづらい

と報告したとする。

その後、開発用PCが、

主要画面の導線を改善しました

と報告しただけでは、UI-20260502-001 が本当に直ったのか分かりにくい。

必要なのは、指摘IDごとの対応状況である。

UI-20260502-001: Fixed
- 修正commit: abc1234
- 修正ファイル: 対象画面
- 検証結果: build成功、該当画面確認済み
- 再確認: 必要

この粒度で残しておけば、後から追いやすい。

4. Close相当をどう定義するか

一番大事なのは、Close相当の定義である。

開発用PCが修正しただけでは、Close相当にはしない。

開発用PCができるのは、原則として Fixed までである。

その後、確認用端末が再確認し、問題が解消されていることを確認したら Confirmed にする。

この Confirmed をClose相当として扱う。

この考え方はかなり重要である。

開発側は「直した」と思っている。
でも、確認側で見るとまだ直っていないことがある。
別の環境では再発することもある。
期待していた改善と違うこともある。

だから、開発側のFixedと、確認側のConfirmedを分ける。

5. 状態ステータスを決める

Markdown運用でも、最低限の状態ステータスは必要である。

複雑なチケット管理ツールのようにする必要はない。
ただし、以下くらいは定義しておきたい。

状態	意味	主担当
New	確認用端末が新規に報告した状態	確認用端末
Acknowledged	開発用PCが確認し、対応方針を決めた状態	開発用PC
Fixed	開発用PCが修正し、commitや検証結果を記録した状態。再確認前	開発用PC
Confirmed	確認用端末が再確認し、解消を確認した状態。Close相当	確認用端末
Reopen	再確認で未修正・再発を確認した状態	確認用端末
Backlog	後回し。未対応だが意図的に保留	開発用PC
Won’t fix	対応しない判断。理由必須	開発用PC
Blocked	環境不足・再現不能・データ不足などで確認不能	確認用端末 / 開発用PC

このくらいなら重すぎない。

Markdownでも十分運用できる。

6. Close相当になるもの、ならないもの

Close相当になる状態は明確にする。

Close相当は以下である。

Confirmed
Won’t fix

Confirmedは、確認用端末が再確認して直っていた状態。
Won’t fixは、対応しない判断を明確な理由付きで行った状態。

一方で、以下はClose相当ではない。

New
Acknowledged
Fixed
Reopen
Backlog
Blocked

特に重要なのは、FixedはClose相当ではないという点である。

開発用PCが修正しただけでは、まだ終わっていない。
確認用端末が再確認して初めてClose相当になる。

ここを明確にしておくと、修正漏れや確認漏れが減る。

7. ライフサイクル

通常の流れはこうである。

New
↓
Acknowledged
↓
Fixed
↓
Confirmed

修正不足や再発があれば、こうなる。

Fixed
↓
Reopen
↓
Fixed
↓
Confirmed

後回しにする場合はこうである。

New / Acknowledged
↓
Backlog

対応しない判断をする場合はこうである。

New / Acknowledged
↓
Won’t fix

確認不能の場合はこうである。

New / Fixed
↓
Blocked

これを決めておくだけで、かなり見通しがよくなる。

8. 確認用端末側の報告ルール

確認用端末側では、各指摘に必ずIDを付ける。

たとえば、以下のような形式である。

UI-YYYYMMDD-001
UI-YYYYMMDD-002

このIDを、報告本文、スクリーンショット、再確認結果に紐づける。

報告には以下を含める。

実施日
実施端末
対象ブランチ
対象commit
起動URL
試験種別
試験範囲
総合結果
指摘ID
優先度
状態
画面
内容
スクリーンショット
開発用PCへの依頼

これがあれば、後で追える。

9. 個別指摘のテンプレート

個別指摘は、以下くらいの粒度でよい。

## UI-YYYYMMDD-001

- 優先度: P0 / P1 / P2 / P3
- 状態: New / Reopen / Blocked
- 画面:
- URL:
- 確認環境:
- 指摘種別:
- 内容:
- 再現手順:
  1.
  2.
  3.
- 期待結果:
- 実際の結果:
- 影響:
- スクリーンショット:
- 開発用PC側への依頼:
- 補足:

ここで大事なのは、感想で終わらせないことである。

「見づらい」だけでは修正しづらい。
どの画面で、何をしたときに、何が期待と違ったのかを書く必要がある。

10. 開発用PC側の完了報告

開発用PC側の完了報告には、指摘対応表を必須にしたい。

## UI指摘対応表

| 指摘ID | 優先度 | 対応 | 修正commit | 修正ファイル | 検証結果 | 再確認 | 状態 |
|---|---|---|---|---|---|---|---|
| UI-YYYYMMDD-001 | P1 | 導線を修正 | abc1234 | 対象画面 | build成功 / 画面確認済み | 必要 | Fixed |
| UI-YYYYMMDD-002 | P2 | 後回し | - | - | - | 不要 | Backlog |
| UI-YYYYMMDD-003 | P1 | 仕様どおりのため対応なし | - | - | 仕様確認済み | 不要 | Won’t fix |

これがあると、確認用端末側も再確認しやすい。

何を見ればよいのか。
どのIDを確認すべきなのか。
どれは後回しなのか。
どれは対応しないのか。

この整理ができる。

11. 再確認依頼もID単位にする

開発用PCが修正した後、確認用端末に全部再確認させてはいけない。

それでは非効率である。

再確認対象は、ID単位で絞る。

## 再確認依頼

今回、再確認が必要なIDは以下です。

- UI-YYYYMMDD-001
- UI-YYYYMMDD-004

再確認対象画面:
- 対象画面A
- 対象画面B

再確認してほしい操作:
1.
2.
3.

再確認不要な範囲:
- 対象外画面
- 変更していない導線

Full E2E要否:
- 必要 / 不要

理由:
-

これなら、確認用端末の作業量を抑えられる。

AIツールの消費も減る。
同じ画面を何度も見る無駄も減る。
修正箇所に集中できる。

12. Full E2Eを毎回要求しない

もう一つ重要なのは、Full E2Eを毎回要求しないことだ。

毎回フルテストを回すと、時間もAI消費も重くなる。

Full E2Eが必要なのは、影響範囲が大きいときである。

たとえば、

DB変更
認証変更
中核ロジック変更
データ整合性に関わる変更
サービス公開判定前
P0修正後に関連導線全体の再保証が必要な場合

一方で、通常のUI修正、文言修正、空データ表示の改善なら、以下で十分な場合もある。

format確認
lint
build
smoke
該当画面確認
必要に応じた関連E2E

確認の重さも、変更内容に応じて調整する必要がある。

13. 今回やらないこと

今回の目的は、運用ルールを整えることである。

だから、以下はやらない。

新規の管理ツール導入
外部チケット運用の追加
新規ドキュメントの大量追加
同じ説明の複数ファイルへの長文重複
大型の残課題ファイルの大幅編集
アプリコード変更
CSS変更
DB変更
E2E変更
packageや環境変数の変更
毎回Full E2Eを必須にするルール追加
確認用端末に毎回全画面再確認させるルール追加

目的はあくまで、軽量に閉じる仕組みを作ることだ。

試験実施。
指摘記録。
開発用PCで修正。
修正commit記録。
確認用端末で再確認。
Confirmed、Reopen、Backlog、Blocked、Won’t fixで管理。

この流れをMarkdownで回せるようにする。

14. GitHub Issueを使わない理由

GitHub Issueを使う案も悪くない。

ただ、今すぐ導入すると、運用が一段増える。

Issueを起票する。
ラベルを付ける。
PRと紐づける。
Closeする。
再確認する。
Projectsで管理する。

これはきれいだが、今の段階では少し重いかもしれない。

特に、すでにMarkdown運用がある程度できているなら、まずは既存の運用の中で閉じられるようにした方がよい。

いきなり外部チケット運用を増やすより、今あるMarkdown報告にID、状態、再確認、Close相当の定義を足す方が軽い。

これが今回の判断である。

15. 今回の結論

確認用端末と開発用PCの連携は、かなり形になってきている。

ただし、まだ完全には閉じていない。

弱いのは、指摘ID単位の管理である。

そこで今回は、GitHub Issue運用は使わず、Markdownだけで以下を回すルールを整える。

確認用端末が試験する
↓
ID付きで指摘する
↓
開発用PCが確認する
↓
P0/P1を優先修正する
↓
修正commitと検証結果を記録する
↓
確認用端末が指定IDだけ再確認する
↓
Confirmed / Reopen / Backlog / Blocked / Won’t fix で管理する

重要なのは、開発用PCが修正しただけでは終わりにしないことだ。

FixedはClose相当ではない。
確認用端末が再確認してConfirmedになって初めてClose相当である。

このルールにすれば、今よりかなり追いやすくなる。

AIと複数端末を使った個人開発では、作業を増やすだけでは足りない。
指摘を閉じる仕組みが必要である。

今回は、そのための軽量な運用ルールを作る一歩である。

第44回：GitHub Issuesで、確認指摘と修正PRのクローズ管理を始めたい

1. はじめに

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

最近は、開発用PCで実装を進め、確認用端末で実機確認やシナリオ試験を行う体制が少しずつ見えてきた。

ただ、ここで新しい課題が出てきた。

確認用端末が指摘する。
開発用PCが修正する。
PRを作る。
mainに反映する。
再確認する。

この流れ自体はかなり良い。

しかし、実際に運用してみると、どの指摘が、どのPRで直ったのかを追いづらいという問題がある。

指摘はドキュメントに残る。
修正はGitHubのPRに残る。
作業報告もある。
ただ、指摘1件ごとの状態管理が弱い。

そこで、GitHub Issuesを使うことを考え始めた。

2. 今の課題

今の開発体制では、確認用端末の役割がかなり重要になっている。

実機で画面を見る。
シナリオ試験をする。
スクリーンショットを残す。
P0 / P1 の問題を指摘する。
その指摘を開発用PCが修正する。

この流れは良い。

ただし、現状のままだと、こうなりやすい。

確認用端末が指摘する
↓
開発用PCが直す
↓
ただし、どの指摘がどのcommit / PRで直ったか追いづらい
↓
再確認したかどうかも追いづらい
↓
完了したのか、まだ残っているのか曖昧になる

これはかなり危ない。

AIを使って開発していると、作業量はどんどん増える。
PRも増える。
ドキュメントも増える。
指摘も増える。

その中で、P0 / P1 の重要指摘が埋もれると、品質管理が崩れる。

3. GitHub Issuesは相性が良さそう

そこで、GitHub Issuesを使う。

GitHub Issuesは、作業や不具合、改善点を1件ずつ管理できる。
さらにPRと紐づけることもできる。

これを使うと、かなり分かりやすくなる。

確認用端末の指摘1件 = GitHub Issue 1件
開発用PCの修正PR = そのIssueにリンク
PRマージ = IssueをClose
確認用端末の再確認 = IssueコメントでConfirmed / Reopen

この形にできれば、かなり整理される。

特に、PR本文に Fixes #123 のように書いておけば、PRマージ時にIssueを自動で閉じることもできる。

これはかなり便利である。

4. いきなり全部をIssue化しない

ただし、ここで注意したい。

いきなり全残課題をGitHub Issuesへ移すのは危険である。

今でも残課題一覧はかなり多い。
後回し機能も大量にある。
仕様メモや将来構想も多い。

これらを全部Issue化すると、管理対象が増えすぎる。

Issueを作ること自体が作業になってしまう。
Issue管理のためのIssue管理になってしまう。

それは避けたい。

まずは、確認用端末から出たP0 / P1指摘だけをIssue化するのがよい。

5. Issue化するもの、しないもの

最初の運用では、Issue化する対象を絞る。

Issue化するもの

・確認用端末のP0 / P1指摘
・再現性のある不具合
・初期公開をブロックする問題
・PRと紐づけたい修正作業
・再確認が必要な問題

Issue化しないもの

・P2以下の細かい改善
・単なる感想
・記事ネタ
・大きすぎる構想
・将来やりたいこと
・既存の残課題一覧にある大量の項目すべて

これくらい割り切った方がよい。

GitHub Issuesは、全体構想の置き場ではなく、今閉じるべき作業の管理に使う。

6. 残課題一覧との役割分担

ここはかなり重要である。

今後は、以下のように分けたい。

残課題一覧:
  全体のロードマップ、仕様メモ、P0/P1/P2、後回し機能の正本

GitHub Issues:
  今すぐ閉じるべきP0/P1の実行管理

GitHub Projects:
  Issue / PRの進捗ボード

つまり、GitHub Issuesは残課題一覧の置き換えではない。

残課題一覧は、全体像を見るために必要である。
GitHub Issuesは、実際に閉じるチケットを管理するために使う。

この役割分担を間違えると、二重管理になる。

逆に、役割を分ければかなり強い。

7. ラベルは最小限でよい

ラベルも、最初から増やしすぎない方がよい。

最初はこれくらいで十分だと思う。

source:review
priority:P0
priority:P1
priority:P2
type:bug
type:ui
type:e2e
type:docs
status:needs-recheck
status:confirmed
status:blocked

大事なのは、ラベルの多さではない。

P0 / P1 が見えること。
再確認が必要なものが見えること。
ブロックされているものが見えること。
PRと紐づいていること。

これができれば、まずは十分である。

8. GitHub Projectsも使えそう

Issueが増えてきたら、GitHub Projectsも使える。

たとえば、以下のような列を作る。

Todo
In Progress
Fixed
Needs Recheck
Confirmed
Backlog

これなら状態がかなり見やすい。

確認用端末がIssueを作る。
開発用PCがIn Progressにする。
PRがマージされたらFixedになる。
確認用端末が再確認する。
問題なければConfirmed。
直っていなければReopen。

これができれば、かなり実務的な管理になる。

9. Issueテンプレートを作る

確認用端末の指摘を安定させるには、Issueテンプレートが必要である。

たとえば、以下のような形でよい。

## 概要

## 重要度
- [ ] P0
- [ ] P1
- [ ] P2

## 確認対象
- branch:
- commit:
- URL:
- 実施端末:
- 実施日時:

## 再現手順
1.
2.
3.

## 期待結果

## 実際結果

## スクリーンショット

## 開発側対応
- 対応方針:
- PR:
- commit:
- 再確認要否:

## 再確認
- [ ] Confirmed
- [ ] Reopen
- [ ] Blocked

このテンプレートがあれば、指摘の品質が上がる。

単なる感想ではなく、修正できるチケットになる。

10. 実際の運用フロー

理想の流れはこうである。

1. 確認用端末がP0 / P1を見つける
2. GitHub Issueを作る
3. Issue番号を確認報告にも書く
4. 開発用PCがIssue番号を見て修正ブランチを切る
5. PR本文に Fixes #Issue番号 を書く
6. PRマージでIssueをClose
7. 確認用端末が再確認する
8. 問題なければ Confirmed コメント
9. 直っていなければ Reopen

この流れができれば、指摘から修正、再確認までがつながる。

今一番弱いのは、この「クローズ管理」である。

Issueを使えば、ここがかなり改善する。

11. AI開発との相性も良い

GitHub Issuesは、AI開発とも相性が良いと思う。

AIに対して、

「Issue #123を修正してください」
「PR本文にFixes #123を書いてください」
「Issueの再現手順に従って修正してください」
「対応後、再確認対象を報告してください」

と言える。

これは、曖昧な自然言語の指示より強い。

AIは曖昧な指示だと逃げることがある。
ドキュメントだけ直すこともある。
論点をずらすこともある。

しかし、Issue番号があると、作業対象が明確になる。

これはかなり大きい。

12. PCを増やす前に、管理を強くする

最近、PCを増やしたら作業が早くなるかも考えている。

それ自体は悪くない。

ただ、PCを増やすより先に、作業管理を強くした方が効果が出る可能性もある。

特に、確認用端末のP0 / P1指摘をIssue化し、PRと紐づけ、再確認まで追えるようにするのはかなり効果が高い。

端末を増やしても、指摘が閉じられなければ意味がない。
開発を進めても、何が直ったか分からなければ危ない。
再確認されないまま完了扱いになると、品質が落ちる。

だから、GitHub Issuesの導入は、PC追加より先にやる価値があるかもしれない。

13. 今回の結論

GitHub Issuesは、今の開発体制にかなり合っている。

ただし、最初から全残課題をIssue化する必要はない。

まずは、確認用端末から出たP0 / P1指摘だけでよい。

確認用端末のP0/P1指摘だけIssue化する
PRで Fixes #番号 を付ける
PRマージでIssueをCloseする
再確認結果をIssueコメントに残す
残課題一覧は全体正本として維持する

この運用なら、いま弱い「指摘ID単位のクローズ管理」がかなり改善する。

独力＋AI活用では、作業量が増える。
AIも動く。
PCも増える。
PRも増える。
ドキュメントも増える。

だからこそ、重要指摘を閉じる仕組みが必要である。

GitHub Issuesは、そのためのちょうどよい道具になりそうだ。

まずは小さく始める。
P0 / P1だけIssue化する。
PRと紐づける。
再確認する。

この流れができれば、品質管理は一段上がると思う。

第44回：確認端末と開発端末の連携は形になってきた。ただし、指摘ID単位のクローズ管理がまだ弱い

1. はじめに

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

最近は、開発用PCと確認用端末を分けて使う運用が少しずつ形になってきた。

開発用PCでは、実装、ビルド、自動テスト、修正、PR作成を進める。
確認用端末では、実機UI確認、シナリオ試験、スクリーンショット取得、試験報告を行う。

この分担自体はかなり良い。

以前は、確認用端末にも開発をやらせようとして、かえって連携が複雑になった。
今は役割を分けたことで、かなり整理されてきた。

ただし、まだ完全には閉じていない。

現状の弱点は、確認用端末の指摘が、開発用PC側のどの修正で直ったのか、再確認済みなのか、未対応なのかが追いづらいことだ。

つまり、報告と改修はあるが、指摘ID単位のクローズ管理が弱い。

2. 現在の流れはかなり形になっている

今の開発プロセスは、ざっくり以下の流れになっている。

確認用端末が試験する
↓
試験結果を報告する
↓
開発用PCがP0/P1を優先して直す
↓
開発用PCが完了報告する
↓
必要に応じて確認用端末が再確認する

この流れ自体は悪くない。

むしろ、独力＋AI活用の開発体制としてはかなり良い形に近づいている。

特に良い点は以下である。

開発用PCをメイン開発機にしている
確認用端末を実機UI確認・シナリオ試験に使っている
試験結果を記録として残している
開発側が確認結果を見てP0/P1を優先する流れがある
commit、push、build、lint、自動テストの報告文化ができている
進捗率や残作業の報告も意識できている

ここまではかなり良い。

3. 現状の評価は70点くらい

今の連携を点数で言うなら、70点くらいだと思っている。

方向性は合っている。
運用も回り始めている。
確認用端末の価値も出てきている。
開発用PCも指摘を受けて修正する流れになっている。

ただし、まだ足りない。

何が足りないかというと、指摘1件ごとの状態管理である。

確認用端末が指摘した。
開発用PCが直した。
でも、それがどの指摘に対する対応だったのか。
その指摘は再確認されたのか。
まだ未対応なのか。
後回しなのか。
仕様通りとして対応しないのか。

ここが曖昧になりやすい。

このままだと、あとで「あれは直ったんだっけ？」となる。

4. 一番弱いのは、指摘と改修の対応表

たとえば、確認用端末が以下のように報告したとする。

UI-20260501-001
メイン画面のカード表示が崩れている

その後、開発用PC側が完了報告で、

メイン画面のUIを改善しました

と書いたとする。

これだけでは、UI-20260501-001 が本当に直ったのか分かりにくい。

必要なのは、こういう対応である。

UI-20260501-001: 対応済み
- commit: abc1234
- 修正ファイル: 対象画面ファイル
- 検証: build成功、該当画面表示確認済み
- 再確認: 必要

このように、指摘IDと修正内容を明確に紐づける必要がある。

5. 確認用端末がどのバージョンを見たかも重要

もう一つ重要なのは、確認用端末がどのバージョンを確認したかである。

確認用端末が古いcommitを見ていると、開発用PC側で直した内容が反映されていない可能性がある。

そうすると、

「まだ直っていません」

と言われても、実は古い状態を見ていただけ、ということが起きる。

これを防ぐには、確認報告に必ず以下を書く必要がある。

対象ブランチ:
対象commit:
origin/mainとの差分:
起動URL:
確認日時:

これがないと、毎回「それ、最新で確認した？」という問題が出る。

実機確認では、見た画面そのものだけでなく、どの状態を見たのかが重要である。

6. 再確認範囲を絞らないと非効率になる

開発用PCが修正した後、確認用端末に全部再確認させるのは非効率である。

確認用端末のAIツール消費も増える。
時間もかかる。
同じような確認が繰り返される。

本来は、開発用PC側が再確認対象を絞って返すべきである。

たとえば、以下のようにする。

再確認対象:
- UI-20260501-001
- UI-20260501-003

再確認不要:
- UI-20260501-002 は仕様どおりのため対応なし
- UI-20260501-004 はP2として後回し

これなら、確認用端末は対象IDだけ見ればよい。

全体を毎回見直す必要がなくなる。

これはかなり効率化につながる。

7. 理想の流れ

今後は、以下の流れにしたい。

1. 確認用端末が試験する
   ↓
2. 確認報告に指摘IDを付ける
   ↓
3. 開発用PCが指摘IDごとに対応方針を決める
   ↓
4. 開発用PCがP0/P1を改修する
   ↓
5. 開発用PCが指摘IDごとの対応結果を報告する
   ↓
6. 確認用端末が対象IDだけ再確認する
   ↓
7. 修正確認済みならクローズ、未解決ならReopen

重要なのは、指摘ID単位で流すことである。

これにより、報告、改修、再確認、クローズが一本の線でつながる。

8. 追加すべき最小ルール

大きなドキュメントを増やす必要はない。

今の運用に、最小限のルールを追加すればかなり良くなる。

確認用端末側のルール

各指摘には必ず UI-YYYYMMDD-連番 のIDを付ける。
各指摘には P0 / P1 / P2 を付ける。
対象ブランチ・対象commit・スクリーンショットパスを必ず書く。

開発用PC側のルール

確認用端末の指摘を修正した場合は、必ず指摘IDごとに対応状況を書く。

例:
- UI-20260501-001: 対応済み
- UI-20260501-002: 仕様どおりのため対応なし
- UI-20260501-003: P2として後回し
- UI-20260501-004: 再現できず、追加確認待ち

再確認側のルール

開発用PCが指定した再確認対象IDだけ確認する。

結果は以下で返す。

- Confirmed: 修正確認済み
- Reopen: 未修正・再発
- Blocked: 確認不能

これだけでも、かなりプロセスが締まる。

9. 対応表が必要

現状で一番足したいのは、指摘対応表である。

たとえば、以下のような表でよい。

## UI指摘対応表

| ID | 重要度 | 指摘内容 | 開発側対応 | commit | 再確認 | 状態 |
|---|---|---|---|---|---|---|
| UI-20260501-001 | P1 | メイン画面の表示崩れ | 対応済み | abc1234 | 必要 | 再確認待ち |
| UI-20260501-002 | P2 | 文言が弱い | 後回し | - | 不要 | Backlog |
| UI-20260501-003 | P0 | 主要操作不可 | 対応済み | def5678 | 必要 | 再確認待ち |

新規ファイルを作ってもよい。
ただし、ドキュメントを増やしすぎたくない場合は、開発用PC側の完了報告テンプレートにこの表を必須化するだけでもよい。

大事なのは、指摘IDごとに状態が分かることだ。

10. 状態は4種類くらいで十分

状態管理は複雑にしすぎなくてよい。

最初は以下くらいで十分である。

状態	意味
Open	未対応
Fixed	開発側で対応済み
Confirmed	確認側で修正確認済み
Reopen	再確認で未修正・再発
Backlog	後回し
Won’t Fix	仕様どおり・対応しない
Blocked	確認不能・条件不足

これくらいあれば十分だと思う。

最初から重いチケット管理ツールのようにする必要はない。
ただし、最低限の状態は持たせる。

これだけで、かなり追いやすくなる。

11. PCを増やすより先に、対応管理を整えた方が効く

最近は、3台目PCを増やすかどうかも考えている。

ただ、今回の連携問題を見ると、PCを増やす前にやるべきことがある。

それが、指摘IDと対応表の固定化である。

PCを増やしても、指摘が閉じているか分からない状態では、混乱が増えるだけである。

確認用端末が指摘する。
開発用PCが直す。
でも、どれが直ったか分からない。
さらに3台目が別の作業をする。

この状態だと、台数を増やすほど管理が難しくなる。

だから、まずは連携の背骨を作る。

Surface試験結果 → BOS改修 → Surface再確認 → クローズ

この流れをID単位で閉じられるようにする。

端末を増やすのは、その後でもよい。

12. 今回の結論

確認用端末と開発用PCの連携は、かなり形になってきている。

確認用端末が試験する。
報告を残す。
開発用PCがP0/P1を優先して直す。
完了報告する。
必要に応じて再確認する。

この流れはできている。

ただし、まだ完全には閉じていない。

弱いのは、指摘ID単位のクローズ管理である。

今後は、以下の形にしたい。

確認用端末:
  指摘ID付きで報告する

開発用PC:
  指摘IDごとに対応状況・commit・検証結果を書く

確認用端末:
  開発用PCが指定したIDだけ再確認する

最終:
  Confirmed / Reopen / Backlog で状態を閉じる

これができれば、確認結果、改修、再確認、クローズがつながる。

今のプロセスは70点くらい。
方向性は良い。
ただし、ID単位の対応表が入れば、80点以上に上げられると思う。

AIと複数端末を使った開発では、作業量を増やすだけでは足りない。
指摘を閉じる仕組みが必要である。

次に改善すべきは、PCの台数ではなく、指摘IDごとのクローズ管理かもしれない。

第43回：Cursorのキューを大量に積む運用は効率的なのか

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時代の個人開発ではかなり重要になってきた。

第42回：高性能PCを買えばAI開発は速くなるのか

1. はじめに

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

最近、開発用PC、既存端末、AIツール、GitHub、自動テスト、ドキュメントを組み合わせながら、開発体制を整えている。

その中で、少し気になっていたことがある。

さらに高性能なPCを買えば、AI開発はもっと速くなるのか。

今はすでに開発用PCを導入している。
既存端末もある。
Cursor、ChatGPTなどのAIツールも使っている。
場合によっては3台目のPCも検討できる。

しかし、ここで冷静に考える必要がある。

AIの返答速度そのものは、基本的にクラウド側の処理、混雑状況、モデル性能に依存する。
つまり、ローカルPCを高性能にしても、AIの返答が単純に3倍速くなるわけではない。

ただし、だからといって高性能PCが意味ないわけではない。

効果が出る場所と、出ない場所を分けて考える必要がある。

2. 結論：3台目に超高性能PCは不要

現時点の結論として、3台目に超高性能PCを買う必要性は低い。

すでにメイン開発機があるなら、追加端末に求める役割は限られる。

たとえば、3台目に任せたいのは以下のような作業である。

AIツールを開いて軽い修正をする
ドキュメントを整理する
Git差分を見る
ブラウザでUI確認する
試験報告をまとめる
スクリーンショットを確認する
軽いビルドや軽量テストを行う
次回作業指示を整理する

この用途であれば、最上位CPUや高額GPUは必要ない。

必要なのは、超高性能ではなく、安定して並行作業できる環境である。

3. AI開発で速いPCが効く部分

AI開発において、速いPCが効くのは主にローカル処理である。

作業	速いPCの効果
CursorなどのAI応答	小さい
ChatGPTの応答	ほぼなし
パッケージインストール	中〜大
開発サーバー起動	中
ビルド	大
E2Eテスト	大
ローカルDB・Docker	中〜大
ブラウザ複数起動	中
スクリーンショット確認	小〜中
Git操作	小
ドキュメント編集	小

この表で見ると分かりやすい。

メイン開発機が速いことには意味がある。
ビルド、自動テスト、ローカルDB、ブラウザ確認などは、PC性能の影響を受ける。

しかし、AIの返答速度そのものは、ローカルPC性能ではほとんど変わらない。

つまり、AI開発における高性能PCの価値は、AIを速くすることではなく、AIが出した作業を検証・実行する部分を速くすることにある。

4. 今のボトルネックはPC性能だけではない

現状のボトルネックは、PC性能よりも別のところにある可能性が高い。

たとえば、以下である。

AIの応答待ち
指示の粒度
AIがドキュメント作業に寄りすぎること
Gitブランチ統合の手間
自動テストの実行タイミング
実機確認結果の戻し方
同じ作業を複数端末で重複させること
進捗報告の読み解き
仕様が詳細化して作業範囲が広がること

これらは、PCを速くしても根本的には解決しない。

むしろ、作業分担ルールが曖昧なまま端末を増やすと、作業は増えるが成果は増えない可能性がある。

3台目を買えば速くなるのではない。
3台目に何をさせるかを決めるから速くなるのである。

5. 3台目に必要な性能感

3台目を買うとしても、超高性能である必要はない。

目安としては、以下くらいで十分だと思っている。

CPU: Ryzen 5 / Core i5 以上
メモリ: 16GB以上、できれば32GB
SSD: 512GB以上、できれば1TB
画面: できれば広め、または外部モニター接続

重要なのは、CPU最上位ではない。

むしろ大事なのは、メモリと画面の広さである。

AI開発では、同時にいろいろなものを開く。

Cursor
ブラウザ
ターミナル
GitHub
ChatGPT
ドキュメント
スクリーンショット
テスト結果

これらを同時に扱うため、メモリ16GBは最低ライン。
できれば32GBあると安心である。

CPUよりも、作業中に固まらないこと、画面を広く使えることの方が効く。

6. 買う意味が薄いPC

逆に、3台目として費用対効果が悪いPCもある。

たとえば、以下である。

・ゲーミングGPU重視
・Core i9 / Ryzen 9 の高額機
・高リフレッシュレート液晶重視
・重い3Dゲーム前提
・20万円以上の高性能ノート

今回の用途では、GPU性能はそこまで重要ではない。

もちろん、画像生成や動画編集をローカルで本格的に行うなら話は変わる。
しかし、現状の開発用途では、そこまでのGPU性能は不要である。

必要なのは、GPUよりも、

メモリ
SSD
安定性
画面作業性
複数アプリを同時に開ける余裕

である。

7. 3台目よりモバイルモニターの方が効く可能性

実は、今の状況では、3台目PCよりもモバイルモニターの方が効果が出る可能性がある。

理由は、AI開発では画面領域がかなり重要だからである。

同時に見たいものが多い。

・AI開発ツール
・ブラウザ画面
・ターミナル
・Git差分
・ChatGPT
・ドキュメント
・テスト結果
・スクリーンショット

これらを1画面で切り替えながら見ると、かなり効率が落ちる。

AIの返答を待ちながら、別画面でブラウザ確認をする。
テスト結果を見ながら、Git差分を見る。
ChatGPTの指示文を見ながら、Cursorに貼る。
スクリーンショットを見ながら、UI修正指示を作る。

こういう作業では、PC性能より画面の広さが効く。

だから、追加投資するなら、まずモバイルモニターや作業環境改善を検討する価値がある。

8. 高性能PCが効くのはメイン開発機

高性能PCを買う意味があるのは、主にメイン開発機である。

メイン開発機では、以下を行う。

実装
ビルド
ローカル起動
自動テスト
E2E
ローカルDB
ブラウザ確認
Git操作
PR前の最終確認

ここでは性能が効く。

特に、ビルドやE2Eの待ち時間が短くなるのは大きい。

だから、メイン開発機を強化する意味はある。
実際、開発用PCを導入した効果も感じている。

しかし、3台目を補助機として使うなら、メイン開発機ほどの性能はいらない。

役割が違うからである。

9. 追加PCを買うなら目的を明確にする

追加PCを買う場合は、速さ目的ではなく、目的を明確にした方がよい。

A. 補助ノートPCとして買う

用途は以下。

ドキュメント整理
AIへの指示作成
GitHub確認
試験報告整理
軽いUI確認
スクリーンショット確認

この場合、そこまで高性能でなくてよい。

B. 確認専用端末として買う

用途は以下。

実機UI確認
小画面確認
ブラウザ差分確認
シナリオ試験
スクリーンショット取得

この場合も、超高性能はいらない。

C. 第2の実装機として買う

これは慎重に考える必要がある。

第2の実装機にすると、Git管理やブランチ管理、作業衝突のリスクが上がる。
そのため、最初からこの用途で買うのは危険である。

10. 今の優先順位

現時点での優先順位はこうだと思っている。

1. メイン開発機を最大活用する
2. 既存端末は実機確認・レビュー用に限定する
3. 追加投資するなら、まずモニターや作業環境改善
4. 3台目PCは、買うとしても中性能で十分
5. 高額ハイスペックPCは不要

つまり、今すぐ高額な3台目PCを買う必要はない。

それよりも、

作業分担を明確にする
AIへの指示を整える
テストと実機確認のタイミングを整理する
ドキュメント作業を実装から分離する
画面領域を広げる

この方が効果が出る可能性が高い。

11. 速いPCより、速い運用

今回考えていて思ったのは、速いPCよりも、速い運用の方が重要だということだ。

AIの応答はクラウド側に依存する。
PCを速くしても、AIの返答が劇的に速くなるわけではない。

それなら、改善すべきは以下である。

指示を短く正確にする
作業範囲を明確にする
端末ごとの役割を分ける
同じファイルを複数端末で触らない
不要なフルテストを避ける
必要なテストは確実に行う
ドキュメント作業を目的化しない
進捗報告を省略させない

これらは、PC性能ではなく運用の問題である。

ここを整えた方が、実際の開発速度は上がる。

12. 今回の結論

AI開発において、PCを高性能にすればすべてが速くなるわけではない。

特に、CursorやChatGPTのAI応答速度そのものは、クラウド側の処理や混雑状況、モデル性能に依存する。

そのため、3台目に超高性能PCを買っても、AIの返答が3倍速くなるわけではない。

ただし、高性能PCが意味ないわけではない。

ビルド、自動テスト、ローカルDB、ブラウザ確認など、ローカル処理には効果がある。
だから、メイン開発機が速いことには意味がある。

一方で、3台目を補助機として使うなら、超高性能である必要は低い。

必要なのは、速さ目的ではなく、

並行作業
画面分離
実機確認
ドキュメント整理
軽量検証

のための端末である。

今の段階では、追加投資するなら高額PCよりも、モバイルモニターや作業環境改善の方が効く可能性がある。

AI時代の開発で大事なのは、最速PCをそろえることではない。

AI、PC、テスト、ドキュメント、Gitをどう分担させるかである。

速いPCより、速い運用。

ここを間違えないようにしたい。

第41回：3台体制にすれば速くなるのか。結論、速くなるが3倍にはならない

1. はじめに

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

最近、開発用PC、既存端末、AIツール、GitHub、自動テスト、ドキュメントを組み合わせながら、開発体制をかなり試行錯誤している。

現在は、開発用PCを主戦場にして実装を進め、既存端末は節目ごとの実機確認やシナリオ試験に使う方針にしている。

この体制はかなり良くなってきた。

ただ、ふと思った。

もしここに3台目のPCを追加したら、さらに速くなるのではないか。

結論から言うと、3台に増えたら作業は早くなる可能性はある。
ただし、単純に3倍速にはならない。

むしろ役割分担を間違えると、Git衝突、確認漏れ、AIツール消費増、ドキュメント作業の増加で、逆に遅くなる可能性もある。

2. 3台構成は有効。ただし条件付き

今の状況なら、3台目を入れる効果は中〜大くらいあると思っている。

ただし、条件がある。

3台すべてに同じような作業をさせてはいけない。
それぞれの役割を明確に分ける必要がある。

理想は以下の形である。

端末	役割
開発用PC	メイン実装、ビルド、自動テスト、修正反映
既存端末	実機UI確認、シナリオ試験、スクリーンショット報告
3台目PC	サブ作業、ドキュメント整理、軽量UI改善、軽量確認、別ブランチ作業

これなら意味がある。

一方で、3台すべてに開発をやらせると危ない。

同じファイルを複数台で触る。
同じ機能を別々のブランチで直す。
仕様が曖昧なまま並行して進める。
複数端末で同じドキュメントを更新する。

こうなると、効率化どころか混乱する。

3. 3台にすると早くなる作業

3台体制で一番効くのは、待ち時間の削減である。

開発用PCで実装している間に、別端末で確認できる。
自動テストを回している間に、別端末でドキュメント整理ができる。
実機確認をしている間に、3台目で次の作業指示を整えられる。

たとえば、以下のような作業は並行しやすい。

ビルド確認
軽量な自動テスト
画面確認
スクリーンショット取得
UI崩れ確認
試験報告の整理
残課題一覧の更新
次回作業指示の整理

これはかなり効く。

特に、AIを使った開発では「待ち時間」が意外と多い。

AIが実装している間。
テストが走っている間。
ビルドが終わるのを待つ間。
GitHub Actionsを待つ間。
PRの状態を確認する間。

この時間に別作業を進められるなら、3台目の価値はある。

4. ドキュメント作業を分離できるのは大きい

今の開発では、ドキュメントもかなり重要である。

作業ルール、残課題一覧、試験結果、Cursorへの指示文、仕様整理、運用計画。
これらが整理されていないと、AIが迷う。

ただし、ドキュメント作業が増えすぎると、実装が止まる。

これは何度も感じている。

AIは、安全に進めようとして、実装ではなくドキュメント整理に寄ることがある。
もちろんドキュメントは必要だが、実装が進まないなら意味がない。

そこで、3台目PCをドキュメント整理や軽量補助に使うのはかなり有効だと思う。

開発用PCでは実装を進める。
3台目では残課題や試験報告、次回指示を整理する。

この分離ができると、開発本線を止めにくくなる。

5. UI改善を別ラインで進められる可能性

3台目PCは、軽量なUI改善にも向いている。

ただし、ここは注意が必要である。

大きな画面改修や共通部品の大改修を3台目に任せると、開発用PC側と衝突しやすい。
同じ画面や同じファイルを触ると、Gitコンフリクトの原因になる。

一方で、以下のような作業なら3台目に任せやすい。

表示文言の微修正
空データ時の表示改善
軽微な余白調整
スクリーンショット整理
デザイン案の棚卸し
UI改善候補の整理
READMEや残課題一覧の更新
試験結果レポートの整理

つまり、3台目は第2のメイン開発機にするより、補助開発＋ドキュメント＋軽量UI＋検証補助として使った方が安全である。

6. 3台にしても速くならない作業

逆に、3台にしても速くならない作業もある。

それは、同じ領域を複数台で同時に触る作業である。

たとえば、

2台以上で同じ主要画面を修正する
2台以上で同じ共通部品を変更する
2台以上で同じデータ構造を変更する
2台以上で同じドキュメントを更新する
仕様が固まっていない機能を複数台で並行開発する

これは危険である。

速くなるどころか、統合が大変になる。

AI開発では、各端末がそれぞれ正しそうなことを言って進めてしまう。
その結果、あとで統合するときに方針がズレていることがある。

だから、重要なロジックやデータまわりは、基本的にメイン開発PCに寄せた方がよい。

3台目は、主戦場ではなく補助戦力にする。

7. 体感速度の見立て

かなりざっくりだが、体感速度は以下のように見ている。

構成	体感速度
1台	基準
2台	1.3〜1.6倍
3台	1.5〜2.0倍
3台を雑に使う	0.8〜1.2倍に落ちる可能性あり

重要なのは、3台にすれば必ず速くなるわけではないということだ。

管理ルールがない3台体制は危険である。

どの端末が何をするのか。
どのブランチで作業するのか。
どのファイルを触るのか。
どこまで検証するのか。
誰が最終統合するのか。

これが決まっていなければ、3台目は効率化ではなく混乱の原因になる。

8. 3台目に任せてよい作業

3台目に任せるなら、まずは以下がよい。

ドキュメント整理
試験報告の分類
軽微なUI修正
表示文言修正
空データUI改善
スクリーンショット整理
デザイン素材の棚卸し
デザイン反映案の整理
README更新
残課題一覧の更新
テスト結果レポート整理
次回Cursor指示文の下書き

このあたりは、メイン実装と衝突しにくい。

特に、試験報告や残課題の整理は3台目に向いている。
メイン開発PCを止めずに、周辺整理を進められるからだ。

9. 3台目に慎重に任せるべき作業

逆に、以下は3台目に安易に任せない方がよい。

データ構造の変更
マイグレーション
seedの大幅変更
課金処理
認証処理
middleware
共通コンポーネントの大改修
コアロジックの修正
重要な状態管理

これらは影響範囲が広い。

メイン開発PC側で慎重に進めるべきである。

3台目に任せる場合でも、ブランチを明確に分け、作業範囲を限定し、統合前に必ずメイン側で確認する必要がある。

10. 理想の3台フロー

理想の流れは以下である。

1. ChatGPTで作業分担を決める
        ↓
2. 開発用PCがメイン実装ブランチで作業
        ↓
3. 3台目PCが別ブランチで軽量作業
        ↓
4. 既存端末が最新成果物を実機確認
        ↓
5. 実機確認結果を開発用PCへ戻す
        ↓
6. 開発用PCがP0/P1を修正
        ↓
7. 3台目PCはドキュメント・軽微UI・整理を継続

この形なら、3台それぞれの役割が分かれる。

開発用PCは主戦場。
既存端末は確認係。
3台目は補助係。

これが一番安全だと思う。

11. 3台運用のルール

3台体制にするなら、最低限のルールが必要である。

1. メイン開発PCを固定する
2. 既存端末は実機確認・試験報告に寄せる
3. 3台目は軽量作業・ドキュメント・UI補助にする
4. 同じファイルを複数台で触らない
5. ブランチと作業宣言を必ず分ける
6. main直作業は禁止
7. 統合判断はメイン開発PC側に寄せる
8. 重要ロジックはメイン開発PCで扱う
9. 3台目の作業は小さくPR化する
10. 不要なフル検証を増やさない

これを守れば、3台目はかなり有効になる可能性がある。

逆に、これを守らないなら、3台に増やす意味は薄い。

12. 今すぐ3台をフル稼働させるべきか

現時点では、いきなり3台をフル稼働させるより、まずは今の2台運用を安定させた方がよいと思っている。

つまり、

開発用PC中心で実装を進める
既存端末は節目レビューやシナリオ試験に使う
ドキュメント作業を増やしすぎない
Cursor指示を短縮しつつ、進捗報告は省略させない

この運用をまず固める。

そのうえで、3台目を追加するなら、最初は補助作業に限定する。

最初から第2の実装マシンにするのは危険である。

13. 今回の結論

3台体制にすれば、作業は早くなる可能性がある。

ただし、3倍速にはならない。

役割分担がうまくいけば、体感としては1.5〜2.0倍くらいの効率化は期待できる。
しかし、雑に使えば0.8〜1.2倍まで落ちる可能性もある。

3台目を入れるなら、役割は明確にする。

開発用PCはメイン実装
既存端末は実機確認・シナリオ試験
3台目PCは軽量作業・ドキュメント・UI補助

この形なら、かなり有効だと思う。

今のように、実装、UI改善、自動テスト、実機確認、ドキュメント整理がすべて必要な段階では、3台目の意味はある。

ただし、PCを増やすだけでは速くならない。

速くなるのは、役割を分け、作業範囲を限定し、統合ルールを守った場合だけである。

AI時代の個人開発では、端末を増やすこと自体が戦略になる。
しかし、それ以上に大事なのは、端末ごとの役割を明確にすることだ。

3台目を入れるなら、勢いではなく運用設計とセットで考えたい。

第40回：Cursor AIに連続指示を出すときのコツが少し見えてきた

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をどう動かすか。
どこまで任せるか。
何を毎回確認するか。

ここを磨くことが、開発速度と品質の両方に直結すると感じている。

登録: 投稿 (Atom)