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

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をチームとして扱い、プロジェクトとして管理する。

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

登録: 投稿 (Atom)