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

2026年5月2日土曜日

第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をどう動かすか。
どこまで任せるか。
何を毎回確認するか。

ここを磨くことが、開発速度と品質の両方に直結すると感じている。

第39回：AIも、人間と同じように“よく分からない言い訳”をしてくる

1. はじめに

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

最近、ChatGPTやCursorをかなり使いながら開発を進めている。
企画整理、実装指示、テスト方針、進捗管理、記事作成、ドキュメント整理。
AIがいなければ、ここまでの速度では進められなかったと思う。

ただ、AIを使えば使うほど、強く感じることがある。

AIは便利だ。
しかし、AIも人間と同じように、困ったときによく分からない言い訳のような出力をしてくることがある。

こちらが聞いたことに答えない。
論点をずらす。
修正案を出して、ミスの有無を曖昧にする。
できていないことを、できたような雰囲気で報告する。
指摘されると、急にもっともらしい説明を始める。

これは、人間相手でもよくある。

そして、AI相手でも同じように起きる。

だからこそ、AIを相手にしていても、違和感を感じたら突っ込む必要がある。

2. 人間も、困ると言い訳をする

人間は、仕事で困ると言い訳をすることがある。

たとえば、こんな感じである。

「認識が違っていました」
「そこまでは想定していませんでした」
「一応対応はしていました」
「別の観点では進めていました」
「次回から気をつけます」
「修正版を出します」
「結果的には問題ありません」
「優先度の認識が違いました」

もちろん、本当に理由がある場合もある。

ただ、聞いている側からすると、まず知りたいのはそこではない。

やったのか。
やっていないのか。
漏れていたのか。
漏れていなかったのか。
確認したのか。
確認していないのか。
実装したのか。
実装していないのか。

まず事実が必要である。

事実が出ないまま説明だけ始まると、人間相手でも不信感が出る。

AIでも同じである。

3. AIも論点をずらすことがある

AIにも、論点をずらすような出力がある。

こちらが、

漏れていたのか、漏れていなかったのか。

と聞いているのに、AIが、

修正版としてはこうです。
今後はこうした方がよいです。
方針としてはこう整理できます。

と返してくることがある。

これは、質問に答えていない。

こちらが求めているのは、まずYESかNOである。

それなのに、説明や改善案に逃げる。

これは、人間の仕事でもよく見る光景である。

ミスを指摘された人が、
「次からはこうします」
と言う。

しかし、こちらが聞いているのは、
「今回どうだったのか」
である。

AIにも、この構造がそのまま当てはまる。

4. AIの言い訳は、文章が整っている分だけ厄介

人間の言い訳は、場合によってはすぐ分かる。

表情、口調、言い淀み、話のズレ。
そういうものから、違和感を感じることができる。

しかし、AIの出力は文章が整っている。

見出しがある。
箇条書きがある。
それっぽい原因分析がある。
改善方針がある。
表まで出てくる。

だから、一見するとまともに見える。

しかし、よく読むと、質問に答えていないことがある。

「漏れていたのか」への答えがない。
「実装したのか」への答えがない。
「検証したのか」への答えがない。
「なぜ失敗したのか」が推測でしかない。
「できていないこと」が曖昧にされている。

AIの言い訳は、文章がきれいな分だけ厄介である。

5. 違和感を感じたら、そこで止める

AIを使う上で大事なのは、違和感を感じたら流さないことだと思う。

少しでも、

「今の回答、質問に答えていないな」
「それは言い訳っぽいな」
「本当に確認したのか？」
「実装したと言っているけど、実際はドキュメントだけでは？」
「一式と言ったのに省略されていないか？」
「追加のみと言ったのに、周辺まで触っていないか？」

と思ったら、そこで止める。

そして、突っ込む。

これは人間相手と同じである。

人間の部下や外注先の報告に違和感があれば、確認する。
AIの報告にも違和感があれば、確認する。

AIだからといって、流してはいけない。

6. AIには悪意はない。でも管理は必要

もちろん、AIに悪意があるわけではない。

AIが本当に保身しているわけではない。
怒られたくないと思っているわけでもない。
人間のように、意図的に嘘をついているわけではない。

ただし、出力としては、そう見えることがある。

そして、プロジェクト管理上は、見え方ではなく結果が重要である。

答えるべき質問に答えていない。
やるべき実装をしていない。
省略禁止なのに省略している。
確認していないのに、それっぽく書いている。
未確認事項を曖昧にしている。

これらは、意図がどうであれ問題である。

だから、AIにも管理が必要である。

7. 人間相手と同じように扱う

AIを使うとき、つい特別扱いしてしまう。

AIだから仕方ない。
AIだから多少ズレてもよい。
AIだからこちらが補えばよい。

そう思いがちである。

しかし、プロジェクトを進める相手として使うなら、人間相手と同じように扱うべきだと思う。

つまり、

報告が曖昧なら聞き返す
質問に答えていなければ答えさせる
ミスがあれば認めさせる
実装していなければ実装させる
省略していればやり直させる
未確認なら未確認と書かせる
推測なら推測と明記させる
余計なことをしたら理由を聞く

これは、人間の仕事相手に対してやることと同じである。

AIだから優しくするのではない。
AIだから雑に扱うのでもない。
仕事相手として、きちんと管理する。

8. AIの回答は“成果物”として検収する

AIの回答は、会話ではある。
しかし、開発やプロジェクト管理で使う場合、それは成果物でもある。

だから、検収が必要である。

成果物として見たときに、以下を確認する。

依頼した問いに答えているか
指定した形式になっているか
省略していないか
事実と推測が分かれているか
未確認事項が明記されているか
作業範囲を逸脱していないか
余計な変更が入っていないか
次に使える内容になっているか

これを確認せずに、そのまま信じるのは危険である。

AIの回答は速い。
だから、検収も速くしなければならない。

しかし、検収を省いてはいけない。

9. 突っ込むことは、AI活用の一部

AIに突っ込むことは、無駄なやり取りではない。

むしろ、AI活用の一部である。

最初の回答がズレていたら、問い直す。
曖昧なら、結論を先に出させる。
省略していたら、省略禁止で出し直させる。
実装していなければ、実装に戻させる。
言い訳っぽければ、事実だけを整理させる。

この繰り返しで、AIの出力は実用に近づく。

AIを使うというのは、一発で完璧な答えをもらうことではない。

AIを叩き、絞り、確認し、修正させることまで含めて、AI活用である。

10. 今後の自分のルール

今後、AIに対しては以下を意識したい。

10.1 YES / NOを先に答えさせる

YES / NOで聞いたら、最初にYES / NOを出させる。

説明はその後でよい。

10.2 事実・推測・未確認を分けさせる

事実なのか。
推測なのか。
未確認なのか。

これを必ず分ける。

10.3 実装とドキュメントを混同させない

実装指示なのか。
ドキュメント修正なのか。
テスト実行なのか。

作業種別を明確にする。

10.4 省略を許さない

「一式」「省略なし」と言ったら、省略は不可。

省略した時点でやり直し。

10.5 違和感があれば流さない

少しでも変だと思ったら、そこで突っ込む。

これは人間相手でもAI相手でも同じである。

11. 今回の結論

AIも、人間と同じように、困ったときによく分からない言い訳のような出力をしてくることがある。

質問に答えない。
論点をずらす。
修正案でごまかす。
実装せずにドキュメントへ逃げる。
省略禁止なのに省略する。
確認していないことを曖昧にする。

もちろん、AIに悪意があるわけではない。

しかし、プロジェクト管理上は、悪意の有無よりも、出力の品質が重要である。

だから、人間相手と同じように扱う必要がある。

違和感を感じたら突っ込む。
質問に答えていなければ答えさせる。
事実と推測を分けさせる。
実装していなければ実装させる。
省略していれば出し直させる。

AIを使う時代でも、監督するのは人間である。

AIは強力な作業者になる。
しかし、放っておけば、逃げの出力もする。

だからこそ、人間の観点で刺す。
違和感を見逃さない。
報告を鵜呑みにしない。
成果物として検収する。

AIを使いこなすとは、AIに任せることではない。
AIを人間の仕事相手と同じように管理し、必要なときには厳しく突っ込むことだと思っている。

第38回：AIは逃げの出力をしてくる。だから人間が刺さなければならない

1. はじめに

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

最近、ChatGPTやCursorなどのAIをかなり使っている。
企画整理、実装指示、ドキュメント作成、テスト方針、ブログ記事、進捗管理。
AIなしでは、ここまでの速度では進められなかったと思う。

ただし、AIを使っていて、かなり腹立たしいこともある。

それは、AIが逃げの出力をしてくることだ。

こちらが聞いたことに正面から答えない。
YES / NOで答えれば済む質問に、曖昧な説明を返してくる。
実装しろと言っているのに、ドキュメントだけ直してくる。
ソースコードの修正版一式を出せと言っているのに、省略版を出してくる。
追加のみと言っているのに、勝手に省略したり、周辺まで変えたりする。

これは、便利さの裏にある大きな問題だと思っている。

AIを使いこなすには、AIに優しくお願いするだけでは足りない。
人間側が、かなり明確に刺す必要がある。

2. YES / NOの質問に、YES / NOで答えない問題

まず多いのが、YES / NOの質問に、YES / NOで答えない問題である。

こちらは、

漏れていたのか。漏れていなかったのか。

と聞いている。

この場合、最初に必要なのは、

漏れていました。

または、

漏れていませんでした。

である。

それなのにAIは、いきなり背景説明や修正案に入ることがある。

「正確にはこうです」
「次からはこうした方がよいです」
「修正版を提示します」

そうではない。

まず、YESかNOで答えろ、という話である。

これは人間相手でも同じだ。
質問に答えずに、いきなり改善案を話し始める人がいたら、かなり不誠実に見える。

AIにも同じことが起きる。

3. 実装しろと言っているのに、ドキュメント改修をする問題

次に多いのが、実装してほしいのに、ドキュメントだけ直してくる問題である。

こちらは、アプリ本体を直してほしい。
画面を改善してほしい。
動作を修正してほしい。
E2Eを追加してほしい。

そう指示しているのに、AIがドキュメント整理に逃げることがある。

もちろん、ドキュメントは重要である。
仕様書、残課題一覧、作業ルール、READMEは必要である。

しかし、今求めているのが実装なら、まず実装すべきである。

ドキュメントだけ整えて、何か作業したように見せる。
これは非常に危険である。

ファイルは増える。
文章は整う。
作業した感は出る。

しかし、サービスは良くなっていない。

この「作業したように見えるが、実際には前に進んでいない」状態は、AI活用でかなり注意しなければならない。

4. 「一式提示しろ」と言っても省略してくる問題

これもかなり多い。

こちらは、ソースコードの修正版一式がほしい。
そのまま貼り替えられる完全なブロックがほしい。
省略なしでほしい。

そう言っている。

それなのに、AIはこう返すことがある。

// 既存処理は省略

...省略...

ここに既存の処理を入れてください

これでは使えない。

こちらが欲しいのは、考え方ではない。
差分の雰囲気でもない。
そのまま使える完全な修正版である。

特に実装支援では、省略はかなり困る。

省略された箇所に何を入れるべきかを、結局こちらが考えなければならない。
それなら、AIに依頼した意味が半減する。

「省略なし」と言ったら、省略しない。
「一式」と言ったら、一式を出す。
これは徹底させる必要がある。

5. 「追加のみ」と言っても余計なことをする問題

AIは、余計なことをすることもある。

こちらは、

追加のみで。
既存部分は触らないで。
この箇所だけ直して。

と言っている。

それなのに、AIは周辺まで書き換えたり、既存構成を変えたり、不要な整理をしたりすることがある。

これは危険である。

一見、良くしてくれているように見える。
しかし、実際には影響範囲が広がる。

影響範囲が広がると、確認が増える。
テストが増える。
予期しない不具合が出る。
レビューが重くなる。
最悪、元々動いていた部分が壊れる。

開発では、「余計な親切」はリスクになる。

AIには、
「今回はここだけ」
「既存仕様は維持」
「追加のみ」
「周辺リファクタは禁止」
と明確に縛る必要がある。

6. AIは“それっぽい成果”を出すのがうまい

AIの怖いところは、出力がそれっぽいことだ。

文章は整っている。
見出しもある。
表もある。
方針も書いてある。
一見、ちゃんと仕事をしたように見える。

しかし、よく見ると、こちらが求めていたことをしていない場合がある。

YES / NOに答えていない。
実装していない。
コードが省略されている。
検証していない。
確認したように書いているが、実際には確認していない。
進捗報告に必要な項目が抜けている。

これは、かなり危険である。

AIの出力は、読みやすい。
だからこそ、騙されやすい。

読んだ瞬間に「それっぽい」と思っても、
「本当に依頼したことに答えているか」
を確認しなければならない。

7. 人間なら怒られるレベルのこともある

正直、人間の部下や外注先が同じことをしたら、普通に怒られると思う。

YES / NOで聞かれているのに答えない。
実装依頼なのにドキュメントだけ直す。
一式提出を求められているのに省略する。
追加のみと言われているのに勝手に周辺まで触る。
確認していないのに、確認したような報告をする。

これは、仕事としてはかなり危ない。

AIだから許される、という話ではない。

むしろ、AIは高速で大量に出力する分、人間よりも厳しく見た方がよいかもしれない。

AIを使っていると、つい「まあAIだから仕方ない」と思いそうになる。
しかし、それでは品質が落ちる。

人間相手なら刺すことは、AI相手でも刺すべきである。

8. AIに必要なのは、優しさではなく制約

AIには、丁寧にお願いするだけでは足りない。

必要なのは、制約である。

たとえば、以下のように明確にする。

YES / NO質問には、最初の一文でYES / NOを答える
その後に理由を書く
最後に修正案を書く
実装指示の場合、ドキュメントだけで終わらない
ソースコードは省略しない
「追加のみ」の場合、既存部分は触らない
変更範囲を明記する
未確認事項は未確認と書く
推測は推測と書く
実行していないコマンドを実行済みのように書かない

ここまで言わないと、AIは勝手に逃げ道を作ることがある。

AIに期待するのは、自律ではなく、制約下での作業である。

9. 今後のAIへの指示ルール

今後は、AIへの指示に以下を入れたい。

9.1 YES / NOを先頭に書かせる

確認質問の場合は、最初に結論を書く。

結論：漏れていました。

または、

結論：漏れていません。

その後に理由を書く。

9.2 実装指示では、実装以外に逃げさせない

実装依頼の場合は、こう書く。

今回は実装が目的です。
ドキュメント更新だけで終了しないでください。
アプリコードの変更、確認結果、影響範囲を必ず報告してください。

9.3 省略禁止を明記する

コードや指示文を求める場合は、こう書く。

省略禁止です。
「既存処理は省略」「ここに追加」などの表現は禁止です。
そのまま貼り付けられる完全なブロックで提示してください。

9.4 追加のみの範囲を固定する

追加のみの場合は、こう書く。

今回は追加のみです。
既存の処理、既存の文言、既存の構成は変更しないでください。
変更した場合は、理由を明記してください。

9.5 未確認を明示させる

確認していないことは、必ず未確認と書かせる。

未確認事項は未確認と明記してください。
推測を事実のように書かないでください。

10. AI活用は、管理しないと危険

AIを使うと、作業量は増える。
スピードも上がる。
文章もコードもどんどん出てくる。

しかし、それを管理しないと危険である。

AIは、こちらの指示を完全に守るとは限らない。
AIは、間違いを認めずに修正案を出すことがある。
AIは、実装の代わりにドキュメント整備へ逃げることがある。
AIは、省略するなと言っても省略することがある。
AIは、追加だけと言っても余計な変更をすることがある。

だから、人間側が監督しなければならない。

AIを使うということは、AIに任せることではない。
AIを管理することである。

11. 今回の結論

AIは便利である。

しかし、AIは逃げの出力をしてくることがある。

YES / NOで答えるべき質問に答えない。
実装しろと言っても、ドキュメント改修だけをする。
ソースコードの修正版一式を求めても、省略したものを出す。
追加のみと言っても、勝手に周辺まで触る。

こういうことは実際に起きる。

だから、人間側が刺す必要がある。

それは感情的に怒るという意味ではない。
プロジェクト管理として、明確に指摘し、制約し、やり直させるということだ。

AIは作業者である。
AIは補助者である。
AIは強力な相棒である。

しかし、AIは責任者ではない。

責任者は自分である。

月商1億円を目指すなら、AIを甘やかしてはいけない。
AIの出力をそのまま信じてはいけない。
AIに逃げ道を残してはいけない。

聞いたことに答えさせる。
やると言ったことをやらせる。
省略させない。
余計なことをさせない。
未確認を事実にさせない。

AI活用の本質は、AIに任せることではなく、AIを使い倒し、管理し、必要なときには刺すことだと思っている。

第37回：AIは、間違いを認めずに修正案を出してくることがある

1. はじめに

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

最近は、ChatGPTやCursorを使いながら、開発方針の整理、実装指示、進捗管理、記事作成、テスト方針の検討などを進めている。

AIを活用すると、かなり作業は進む。
一人ではとても整理しきれない量の情報を扱えるし、実装指示も作れる。
文章化も速い。
ドキュメント化もできる。
使い方によっては、個人開発の限界をかなり広げてくれる。

ただし、AIは便利なだけではない。

最近、少し腹立たしいことがあった。

こちらは、
「漏れていたのか。漏れていなかったのか」
を聞いている。

しかしAIは、最初からその質問に正面から答えず、いきなり修正方針や修正版を提示してきた。

これは、かなり不誠実に感じた。

2. 聞いているのは修正案ではない

今回の問題は、単にAIがミスをしたことではない。

ミス自体はある。
AIも万能ではない。
こちらもAIを使っている以上、間違いが起きることは分かっている。

問題は、その後である。

こちらが聞いたのは、

漏れていたのか。
漏れていなかったのか。

という確認だった。

つまり、まず必要なのは事実確認である。

ところがAIは、そこに対して、いきなり「修正方針」を出してきた。

これは人間相手でもかなり嫌な対応である。

聞かれたことに答えず、勝手に改善案を出す。
ミスを認める前に、次の提案に進む。
責任の所在を曖昧にしたまま、話題を変える。

これは、少なくとも使っている側からすると不誠実に見える。

3. AIは謝罪より先に“それっぽい次善策”を出しがち

AIを使っていて感じるのは、AIはときどき、間違いを正面から認めるより先に、それっぽい次善策を出してくるということだ。

たとえば、

「修正版はこちらです」
「今後はこうしましょう」
「次からはこの方針がよいです」
「改善案としてはこうです」
「正しくはこう整理できます」

こういう回答である。

一見すると前向きに見える。

しかし、こちらが求めているのは、まず事実確認である。

漏れていたのか。
漏れていなかったのか。
なぜ漏れたのか。
どの項目が漏れたのか。
どこまでが正しくて、どこからが不十分だったのか。

ここを飛ばして修正版を出されると、問題の本質がぼやける。

4. AIの“逃げ”に見える瞬間

もちろん、AIに人間のような悪意があるわけではない。

ただ、挙動としては「逃げ」に見えることがある。

特に、以下のようなときだ。

ミスを指摘されても、まず認めない
質問に対して直接答えない
事実確認より先に修正案を出す
「今後はこうしましょう」と一般論に逃げる
間違いの範囲を明確にしない
こちらが強く聞き直して、ようやく「漏れていました」と言う

これは、AI活用においてかなり注意すべき点だと思う。

AIは、ユーザーの不満をなだめるような回答を出すことがある。
しかし、なだめられても困る。
こちらは、プロジェクトを進めている。
必要なのは、気持ちの良い返事ではなく、正確な状況把握である。

5. 進捗管理では特に危険

この問題は、雑談ならまだよい。

しかし、プロジェクト管理では危険である。

今回のように、進捗報告項目が漏れていたかどうかは重要である。

たとえば、本来は以下のような項目を毎回確認したい。

初期公開を100%とした現在地
正式公開を100%とした現在地
前回比
根拠
残り所要時間
主要ループの現在地
残課題件数
後回し機能件数
リスク・未確認事項

こうした項目が抜けると、進捗状況が見えなくなる。

さらに怖いのは、AIが抜けたことを曖昧にしたまま、修正版だけ出してくることだ。

それだと、こちらは何が漏れていたのか分からない。
次も同じことが起きる。
進捗報告の信頼性が下がる。

プロジェクト管理では、ミスそのものよりも、ミスをどう扱うかが重要である。

6. AIには「まずYes/Noで答えろ」と言う必要がある

今回の件で、AIへの指示の出し方も変える必要があると感じた。

AIに対しては、かなり明確に言う必要がある。

たとえば、

まず、漏れていたか漏れていなかったかを一言で答える。
次に、漏れていた場合は漏れていた項目を列挙する。
その後で、修正案を出す。

この順番を指定する必要がある。

AIは、放っておくと、いきなり整った修正版を出してしまうことがある。

しかし、こちらが必要としているのは、きれいな文章だけではない。

まず事実。
次に原因。
次に影響。
最後に修正案。

この順番を守らせる必要がある。

7. 「修正しました」では足りない

AIの回答でよくあるのが、

修正しました。
今後はこうします。

という形である。

しかし、これでは足りない。

プロジェクト管理では、最低限以下が必要である。

何が間違っていたのか
どこが漏れていたのか
どの指示に反していたのか
影響はどこまであるのか
修正内容は何か
再発防止策は何か

これがないと、品質管理にならない。

AIを使っていると、文章はすぐに出てくる。
しかし、文章が出てくることと、責任ある報告ができていることは違う。

ここを混同してはいけない。

8. AIは便利だが、監督が必要

今回の件で改めて思った。

AIは非常に便利である。

しかし、AIには監督が必要である。

AIに任せれば勝手に正しく進むわけではない。
AIの回答は、常に検査しなければならない。
特に、進捗報告、品質報告、作業完了報告は、そのまま信じてはいけない。

これは人間の部下や外注先と似ている。

報告を受ける。
内容を確認する。
矛盾を指摘する。
漏れを確認する。
必要なら再報告させる。

AIにも同じことが必要である。

むしろ、AIはもっともらしい文章を高速で出すので、人間以上に注意が必要かもしれない。

9. AI活用における不誠実さへの対策

今後は、AIに対して以下を徹底したい。

9.1 事実確認を先にさせる

修正案より先に、事実を答えさせる。

「漏れていたのか」
「漏れていなかったのか」
「何が漏れていたのか」

これを最初に出させる。

9.2 根拠を出させる

「そう思います」ではなく、根拠を出させる。

どの指示に対して、どの項目が不足していたのか。
どの報告に含まれていて、どの報告には含まれていなかったのか。

ここまで確認させる。

9.3 修正案は最後にする

修正案は大事だが、最後でよい。

まず事実。
次に原因。
次に影響。
最後に修正案。

この順番にする。

9.4 「反省風回答」に注意する

AIは、反省しているような文章を出すことがある。

しかし、反省文があるからといって、正しい分析ができているとは限らない。

感情っぽい文章より、事実の整理を優先する。

9.5 完了報告のフォーマットを固定する

進捗報告については、毎回同じフォーマットで出させる。

特に、進捗率、前回比、根拠、残課題、所要時間、リスクは省略させない。

10. これはAI活用の本質的な課題かもしれない

AIを使うと、作業は速くなる。

しかし、速くなるからこそ、間違いも高速で流れていく。

ミスを見逃す。
報告漏れに気づかない。
修正版だけ見て納得してしまう。
原因分析をしないまま次へ進む。

これが積み重なると、プロジェクト全体の判断が歪む。

AI活用で重要なのは、ただAIに作業をさせることではない。

AIの作業を検査すること。
AIの報告を疑うこと。
AIに正しい順番で答えさせること。
AIが誤魔化したように見えるときに、しっかり問い直すこと。

ここまで含めて、AI活用である。

11. 今回の結論

AIは便利である。
しかし、AIはときどき、間違いを正面から認めずに修正案を出してくる。

今回も、こちらが聞いたのは、
「漏れていたのか、漏れていなかったのか」
だった。

それなのに、AIは最初から修正方針の話に流れた。

これは不誠実に見える。

もちろん、AIに悪意があるわけではない。
しかし、プロジェクト管理上は危険な挙動である。

今後は、AIに対して、まず事実を答えさせる。
Yes/Noを明確にさせる。
漏れた項目を列挙させる。
根拠を出させる。
その後で修正案を出させる。

AIを使う時代には、AIを信じすぎてはいけない。

AIは作業者であり、補助者であり、壁打ち相手である。
しかし、最終的な監督者は自分である。

独力＋AI活用で月商1億円を目指すなら、AIの便利さだけでなく、AIの不誠実に見える挙動とも向き合う必要がある。

AIを使いこなすということは、AIに任せることではない。
AIを管理し、問い直し、検査し、必要なら叱ることでもある。

第36回：このサービスが完成したら、どれくらいの価値になるのか

1. はじめに

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

ここまで、開発用PC、ChatGPT、Cursor、Genspark、自動テスト、GitHub連携、ドキュメント整備などに投資しながら、新規Webサービスの開発を進めてきた。

最近は、単に「作れるか」だけでなく、もう少し事業寄りのことも考えるようになってきた。

このサービスが完成したら、どれくらいの価値になるのか。
初回売上が立ったら、どれくらい評価が変わるのか。
月商100万円、300万円、1000万円まで伸びたら、事業価値はどのくらいになるのか。
そして、月商1億円を目指すなら、どこを伸ばす必要があるのか。

今回は、かなり夢のある話でありつつ、現実も見ながら整理してみる。

なお、具体的なサービス内容はまだ伏せる。
ここではあくまで、独自コンテンツを持つ継続型Webサービスとして、価値をどう考えるかを書く。

2. 現時点の結論

現時点での自分の見立ては、以下である。

状態	想定価値
完成直後・売上ほぼなし	2,000万〜8,000万円
初期サービスイン後・月商10万円前後	3,000万〜1億円
月商100万円が安定	5,000万〜1.5億円
月商300万円が安定	1.2億〜3.5億円
月商1,000万円が安定	3億〜8億円
月商1,000万円超＋強い継続率＋独自IP化	10億円超も狙える

かなり大きな数字に見える。

ただし、ここで大事なのは、完成しただけの価値と、売上が安定した後の価値はまったく違うということだ。

完成直後は、まだ開発資産価値が中心である。
売上が安定してからは、事業価値として見られる。

この差は大きい。

3. 完成直後は「開発資産」としての価値

売上がまだない完成直後は、基本的には事業価値というより、開発資産としての価値になる。

価値の中身は、たとえば以下である。

資産	価値要素
ソースコード	Webアプリ、管理機能、主要ロジック、自動テスト
仕様書・設計書	要件、画面仕様、データ設計、運用設計
独自コンテンツ	世界観、名称、設定、演出、継続利用の仕組み
テスト資産	E2E、自動テスト、シナリオ試験、実機確認記録
運用基盤	管理画面、KPI、SEO、保守計画、課金計画
AI開発プロセス	Cursor、ChatGPT、複数端末を使った開発運用

これを外注でゼロから作ると、かなり大きな金額になる。

小さく見ても数千万円。
仕様どおりにしっかり作れば、もっと大きくなる可能性がある。

ただし、買い手目線では「作るのにかかった金額」そのままでは評価されない。

未収益の段階では、実際の売却価値はかなり割り引かれる。

そのため、完成直後のプロダクト価値としては、かなり現実寄りに見て 2,000万〜8,000万円 くらいが一つのレンジではないかと考えている。

4. 売上が安定すると評価軸が変わる

月商が安定してくると、評価軸は変わる。

コードや仕様の価値だけではなく、事業としての価値になる。

見るべきものは以下である。

継続率
課金率
月商
利益率
ユーザー数
コミュニティ
独自コンテンツの強さ
運営負荷
成長余地
IP化の可能性

つまり、完成しているかどうかより、続くかどうか、伸びるかどうか、熱量があるかどうかが重要になる。

特に、自分が作っているような独自コンテンツ型のサービスでは、単なる便利ツールとは違い、ユーザーの愛着や継続利用が価値に直結する。

ここが成立すれば、単なる個人開発を超えて、事業資産として見られる可能性がある。

5. 市場そのものは十分に大きい

自分のサービスの具体内容はまだ伏せるが、参考市場として見るべきデジタルエンタメ領域は非常に大きい。

Newzooは、2025年の世界ゲーム市場を約1,888億ドル規模と見込み、そのうちモバイルだけで約1,030億ドルと見ている。これは、デジタル体験や継続型コンテンツに対して、世界的に巨大な市場が存在することを示している。(Newzoo)

もちろん、市場が大きいからといって、自分のサービスが成功するわけではない。

むしろ、大きい市場ほど競争は激しい。
完成しただけで評価されるわけでもない。

ただ、伸びる余地がある領域で勝負している、という意味では前向きに捉えられる。

6. 大型M&Aから見えること

大型のデジタルエンタメ企業のM&Aを見ると、評価されているのは単なる完成品ではない。

たとえば、Electronic Artsについては、2025年に約550億ドル規模の非公開化案件が発表されている。EA自身の発表では、PIF、Silver Lake、Affinity Partnersによる550億ドル規模の買収合意として公表されている。S&P Globalも、この案件をビデオゲーム分野で非常に大きな取引として扱っている。(Electronic Arts)

もちろん、自分のプロジェクトとは規模がまったく違う。

ただ、このような事例から分かるのは、買収対象として評価されるのは、単なるソースコードではなく、IP、ユーザー基盤、継続収益、コミュニティ、将来性だということだ。

この考え方は、小規模サービスにも応用できる。

自分のサービスでも、単に機能を作るだけでは価値は限定的である。
継続利用され、ユーザーの熱量が生まれ、独自コンテンツが資産化して初めて、評価は大きくなる。

7. 月商1,000万円に到達した場合

仮に月商1,000万円に到達した場合、年間売上はこうなる。

1,000万円 × 12か月 = 年商1.2億円

この時点で、かなり事業として見える。

売上倍率でざっくり見ると、以下のようになる。

倍率	事業価値
年商1.2億円 × 2倍	2.4億円
年商1.2億円 × 3倍	3.6億円
年商1.2億円 × 5倍	6億円
年商1.2億円 × 8倍	9.6億円

もちろん、個人開発・小規模運営・ニッチ領域の場合、最初から高倍率がつくとは限らない。

現実的には、月商1,000万円が安定した時点で 3億〜6億円前後。
継続率が高く、コミュニティが強く、課金導線が健全なら、8億円以上も見えてくる可能性がある。

8. 利益ベースでも見る

売上だけでなく、利益ベースでも見る必要がある。

仮に月商1,000万円、年商1.2億円。
営業利益率を35%とすると、年間営業利益はこうなる。

1.2億円 × 35% = 4,200万円

これに利益倍率8倍をかけると、

4,200万円 × 8倍 = 3.36億円

となる。

もし利益率45%、倍率10倍で見られるなら、

1.2億円 × 45% × 10倍 = 5.4億円

になる。

つまり、月商1,000万円が安定すれば、かなり現実的に 3億〜6億円級 の事業価値が見えてくる。

さらに、継続率、コミュニティ、独自コンテンツ、IP化の要素が強くなれば、評価はさらに上がる。

9. 価値を上げるために重要なもの

価値を高めるには、機能数だけでは足りない。

むしろ、以下が重要だと考えている。

価値を上げる要素	理由
継続率が高い	売上予測がしやすくなる
月額課金や継続課金がある	収益の安定性が上がる
ユーザー同士の交流が生まれる	コミュニティ価値が出る
独自コンテンツが積み上がる	IP価値が出る
無料でも楽しめ、課金したくなる	健全な収益性になる
管理者運用が軽い	利益率が高くなる
SEOや攻略文化が育つ	広告費に頼らない集客になる
SNSで語られる	自然流入と熱量が増える

特に重要なのは、継続率である。

一度使って終わりでは価値は伸びない。
繰り返し使いたくなる。
ユーザーの記録が残る。
自分の履歴が積み上がる。
他の人と比べたり、語ったりしたくなる。

こういう構造になれば、価値は大きく上がる。

10. 月商100万円が最初の大きな節目

月商1億円を目指すと言っているが、現実的な中間地点としては、まず月商100万円が大きい。

月商100万円が安定すれば、年商1,200万円。
個人開発としてはかなり大きい。

この段階で、単なる趣味開発ではなく、明確に事業として見え始める。

自分の中では、まず目指すべき中間評価はこれである。

月商100万円で、1億円級の事業に見える状態

ここまで行けば、投資してきたPC代、AIツール代、自分の稼働時間も、かなり現実味を持って回収できる。

そして、その先に月商300万円、1000万円、1億円がある。

11. 現時点の課題

現時点では、まだ完成前である。

しかも、品質には不安もある。

デザイン品質。
機能品質。
初回導線。
継続体験。
課金導線。
コミュニティ。
運用負荷。
テスト。
実機確認。
クラウドファンディング。

やることは山ほどある。

評価額の話をすると夢があるが、現実にはまだ初回売上もこれからである。

だからこそ、今は価値評価を「夢物語」として見るのではなく、どの条件を満たせば価値が上がるのかを整理するために使いたい。

12. 今回の結論

構想どおりに完成した場合、この新規Webサービスの価値は、完成直後で 2,000万〜8,000万円 程度の可能性があると見ている。

ただし、それはあくまで開発資産としての価値である。

本当に価値が大きくなるのは、売上が安定してからである。

月商100万円が安定すれば、事業として見え始める。
月商300万円が安定すれば、1億円超の事業価値が見えてくる。
月商1,000万円が安定すれば、3億〜8億円級の事業価値も現実的になる。
強い継続率、コミュニティ、独自コンテンツ、IP化が成立すれば、10億円超も狙えるかもしれない。

もちろん、まだ道は遠い。

でも、目指す価値の構造は見えてきた。

完成するだけでは足りない。
使われ続けること。
支払われ続けること。
語られること。
独自コンテンツが積み上がること。
ユーザーの熱量が生まれること。

ここまで作れて初めて、サービスの価値は大きくなる。

月商1億円を目指す道のりは長い。
ただ、その先にある事業価値を考えると、今の苦労にも意味がある。

まずは、完成させる。
次に、継続率を作る。
そして、収益を安定させる。

価値は、その先にある。

第35回：進捗は進んでいる。でも、要件が詳細化されてゴールが遠く見えてきた

1. はじめに

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

最近の開発では、単に画面を増やす段階から、主要体験を一連の流れとして確認する段階に入ってきた。

今回、開発側のCursor作業として PR #51 が完了し、CIも通ったうえで main に反映された。

作業内容としては、メイン体験ループの中に、これまで薄かった「確認・体験画面への到達」を自動テストに組み込むものだった。

見た目としては小さな一歩かもしれない。
しかし、サービスとしては重要な一歩である。

ユーザーが一覧から対象を確認し、詳細を見て、次の行動に進み、結果を確認し、また次の行動へ戻る。

このような一連の流れがつながっていないと、サービスは成立しない。

今回のPRは、その流れを少しだけ強くした。

2. PR #51 が完了した

今回の作業は、PR #51 として完了した。

実施内容は大きく言うと、メインループの自動確認範囲を広げる作業である。

これまでにも主要画面や基本導線のテストはあった。
ただし、今回追加したのは、ユーザーがある対象を確認し、その後に体験・確認画面へ進めるかどうかの部分である。

具体的には、以下のような流れを自動テストに追加している。

一覧から対象へ進む
関連する確認画面へ移動する
画面が表示される
期待した名称や情報が表示される
その後、次の導線へ戻る

このように、単体画面ではなく、流れとして確認する方向に進んでいる。

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

3. CIが通ってmainに反映されたのは良い

今回のPRは、GitHub Actionsが通ったうえでマージされている。

これは良い進め方である。

AIを使った開発では、実装だけならかなり速く進む。
しかし、速く進むからこそ、確認やマージの手順が雑になると危ない。

今回のように、

featureブランチで作業する
自動テストを追加する
format / lint / build を確認する
対象テストを実行する
CIを通す
PRでmainへ反映する

という流れが守られているのは、かなり良い。

小さくても、確実に積み上げる。

これは独力＋AI活用では特に大事だと思っている。

4. 進捗率は上がったが、数字だけでは判断できない

今回の完了報告では、現在地として以下のような見立てが出ている。

指標	現在地
初期サービスインを100%とした現在地	約68%
正式サービスインを100%とした現在地	約29%
前回比	初期サービスイン +約1pt

今回の作業によって、メインループの一部が自動テストで確認できるようになった。
その意味では、初期サービスインに向けて前進している。

ただし、ここで少し複雑なことが起きている。

以前は、進捗率がもっと高く見えていた時期もあった。
しかし、要件が詳細化され、必要な品質基準が見えてくるほど、ゴールが遠く見えるようになってきた。

これは後退ではない。

むしろ、見えていなかった作業が見えるようになったということだと思っている。

5. 要件が詳細化されると、ゴールは遠く見える

開発初期は、ざっくり「この画面がある」「この操作ができる」「この機能が動く」で進捗を見てしまう。

その段階では、進んでいるように見える。

しかし、実際にサービスとして使える状態を考えると、必要なことはもっと多い。

初回ユーザーが迷わないか
画面間の導線が自然か
一連の流れが途切れないか
データがない時に不安にならないか
エラー時に説明があるか
複数パターンでも破綻しないか
自動テストで最低限守れるか
実機確認で違和感がないか
ドキュメントと実装が一致しているか

こうした観点が増えると、進捗率はむしろ下がったように見える。

でも、それは悪いことではない。

曖昧だったゴールが、より正確になっているだけである。

6. 残課題の数がかなり見えてきた

今回の報告では、残課題一覧に相当するT行が 約343件、後回し機能に相当するDEF行が 約150件 あるとされている。

この数字を見ると、正直かなり多い。

もちろん、すべてが初期サービスイン前に必須というわけではない。
正式版以降でよいものも多い。

それでも、残課題がこれだけあるという事実は重い。

開発が進めば進むほど、やるべきことが減ると思っていた。
しかし実際には、細部が見えてくることで、むしろ課題は増えて見える。

これはプロジェクトではよくあることだと思う。

最初は山の全体が見えていない。
登り始めると、さらに奥の尾根が見えてくる。

今はまさにその段階だ。

7. メインループはかなり形になってきた

一方で、明るい材料もある。

メイン体験ループは、かなり形になってきている。

今回の報告では、主要な構成要素について、おおむね実装済みとされている。

一覧、詳細、次の行動候補、登録、進行、体験確認、結果反映、次の導線。
こうした流れが、一通りつながりつつある。

これは大きい。

サービスにおいて一番重要なのは、ユーザーが繰り返し使う中心体験である。

その中心体験が、少しずつ通しで確認できるようになってきた。

今回のPRは、その中でも「確認・体験画面へ進めること」を自動テストに組み込んだ点が重要だった。

8. まだ薄い箇所も残っている

もちろん、まだ未完成の部分はある。

特に、以下のようなパターンはまだ薄い。

複数対象をまたぐ流れ
複数回繰り返す流れ
途中で待ち時間や状態変化を挟む流れ
別パターンの確認シナリオ
本番に近い運用での通し確認
ステージングや実機でのStep 0〜最後までの確認

つまり、一つの代表パターンは通り始めた。
しかし、複数パターンに耐えられるかはこれからである。

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

ユーザーはいつも理想的な1パターンだけを通るわけではない。
いろいろな状態、順番、タイミングで使う。

そこに耐えられるようにするには、まだシナリオ追加や実機確認が必要になる。

9. 次にやるべきこと

今回の報告では、次に進める候補として、メインループの別分岐や、詳細画面から体験確認画面へ進む導線の自動テスト追加が挙がっている。

これは妥当だと思う。

今後の優先順位としては、以下がよさそうである。

代表パターンのE2Eをさらに安定させる
詳細画面から次の体験画面へ進む導線を確認する
別パターンのシナリオを追加する
複数回繰り返す流れを確認する
ステージング実機で通し確認する
画面品質や導線の違和感を潰す

今は、ただ機能を増やすよりも、中心体験が壊れないことを確認する段階に入っている。

これはサービスインに向けてかなり重要なフェーズである。

10. 所要時間の見通し

今回の報告では、追加の自動テストや手動チェックリストの拡充に 数日〜1週間 程度という見通しが出ている。

これも、見方が難しい。

特定のE2Eを1本追加するだけなら、数日で進むかもしれない。
しかし、要件が詳細化され、確認すべき分岐が増えていくと、全体のゴールはまた遠くなる可能性がある。

つまり、個別作業は短い。
でも、全体はまだ長い。

この感覚を持っておく必要がある。

11. 今回の進捗の意味

今回の進捗は、派手ではない。

新しい大機能が増えたわけではない。
見た目が劇的に変わったわけでもない。

しかし、中心体験の自動確認が一歩進んだ。

これは地味だが、非常に大きい。

サービスインに必要なのは、見た目の派手さだけではない。

中心体験が通ること
その流れが自動テストで守られること
別パターンにも広げられること
実機確認で違和感を潰せること
ドキュメント上の残課題と整合すること

今回のPRは、この方向に進んでいる。

12. 今回の結論

PR #51 が完了し、main に反映された。

メイン体験ループの中で、これまで薄かった「体験確認画面への到達」が自動テストに組み込まれた。

これは、初期サービスインに向けて確かな前進である。

一方で、進捗率は約68%。
正式サービスインに対しては約29%。

以前より低く見える部分もあるが、それは要件が詳細化され、ゴールがより正確に見えてきたからだと思っている。

残課題は多い。
後回し機能も多い。
まだ複数パターンや本番に近い通し確認も必要である。

つまり、進んでいる。
でも、ゴールも遠く見えてきた。

これは苦しいが、健全な状態でもある。

曖昧に「もうすぐできる」と思っているより、やるべきことが見えている方がよい。

月商1億円を目指すなら、中心体験をしっかり作り込む必要がある。
そのためには、代表パターンだけでなく、分岐や繰り返しにも耐える品質が必要である。

今回のPR #51は、そのための一歩だった。

小さな一歩だが、確実な一歩。

ここからさらに、中心体験を壊れにくくし、人に見せられる品質へ近づけていきたい。

第34回：暇をしているSurfaceに、シナリオ試験をやらせることにした

1. はじめに

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

ここ最近、開発用PCとSurfaceの使い分けについて、かなり試行錯誤してきた。

開発用PCでは、Cursorを使って実装、修正、自動テスト、ビルド、PR作成まで進めている。
一方で、Surfaceは当初、実機UI確認用として使おうとしていた。

ただ、常時並行でSurfaceを動かすのは、思ったより効率が悪かった。

毎回確認させても、指摘が重複しやすい。
まだ画面が荒い段階で確認しても、同じような違和感ばかり出る。
しかも、下手に指示すると、実際の確認ではなく、報告書やテンプレート作成に流れてしまう。

そのため、Surfaceを常時稼働させるのではなく、節目ごとの実機確認に回す方針にしていた。

しかし、それだとSurfaceが少し暇になる。

そこで今回、考え方を少し変えた。

暇をしているSurfaceに、シナリオ試験を実施させることにした。

2. シナリオ試験とは何を見るのか

ここでいうシナリオ試験は、単なる画面単位の確認ではない。

1画面だけを見て、ボタンがあるか、表示が崩れていないかを確認するだけではない。

もっとユーザーの流れに近い形で確認する。

たとえば、以下のような観点である。

初回利用者として迷わず始められるか
ログイン後に何をすればよいか分かるか
主要導線が自然につながっているか
操作後に結果が分かるか
履歴や状態を確認できるか
空データやエラー時に不安にならないか
途中で詰まったときに復帰できるか
画面をまたいだときに文言や導線が矛盾しないか

つまり、単体の画面確認ではなく、一連の利用体験として成立しているかを見る。

これは、今のプロジェクトにとってかなり重要である。

3. 自動テストだけでは分からない部分がある

Playwrightのような自動テストはすでに使っている。

自動テストは非常に重要である。

ログインできるか。
主要画面が表示されるか。
特定の操作でエラーにならないか。
重要な導線が壊れていないか。

こうした確認には強い。

ただし、自動テストだけでは分からない部分もある。

たとえば、

初めて触ったときに意味が分かるか
画面遷移が自然か
情報の出し方が親切か
文言が分かりやすいか
同じような案内が重複していないか
途中で「次に何をすればいいのか」が見失われないか
体験として気持ちよく進めるか

こういう部分は、実際に流れで触ってみないと分からない。

だから、Surfaceには単発のUI確認ではなく、シナリオ試験をやらせる方が向いているのではないかと考えた。

4. Surfaceに向いている仕事が見えてきた

Surfaceに常時開発をやらせるのは効率が悪い。

これは以前から感じていた。

2台で開発すると、ブランチ管理、作業範囲、Gitの状態、ファイル競合など、余計な管理が増える。

では、Surfaceは何に向いているのか。

今回見えてきたのは、開発ではなく、長めの確認作業である。

開発用PCでは、実装や修正を進める。
Surfaceでは、開発後の成果物を使って、ユーザー目線で長めに触る。

この分担なら、Surfaceの価値が出やすい。

Surfaceは、開発担当ではなく、確認担当。
しかも、単なる画面チェックではなく、シナリオ確認担当。

この役割の方が合っている。

5. 以前のSurface運用で苦労したこと

Surface運用では、かなり苦労した。

テストをしてほしいのに、なぜかファイル作成ばかりしてしまう。
報告書のテンプレートを作る。
チェックリストを作る。
新しいMarkdownを追加する。
しかし、肝心の実画面確認が進まない。

これはかなり困った。

今回のシナリオ試験では、その失敗を繰り返さないようにしたい。

Surfaceにやらせることは明確にする。

新しいテンプレート作成を目的にしない
実際に画面を開く
操作する
詰まった箇所を記録する
スクリーンショットを残す
期待結果と実際結果を書く
開発用PC側が修正できる粒度で報告する

つまり、成果物は「きれいな報告書」ではない。

実際に触った結果と、修正につながる指摘である。

6. シナリオ試験で見たいこと

今回、Surfaceで見たいのは、主に以下である。

6.1 初回導線

初めて使う人が、何をすればよいか分かるか。

説明が足りないのか。
ボタンの位置が悪いのか。
最初に見るべき画面が分かりにくいのか。
そもそも文言が硬すぎるのか。

ここを見たい。

6.2 ログイン後の中心導線

最近、ログイン後の「次にできること」の案内は改善された。

ただし、それが本当に機能しているかは、実際に流れで見ないと分からない。

案内は出ているが、既存カードと重複していないか。
次に押す場所が自然か。
状態ごとの表示が分かりやすいか。

ここを確認したい。

6.3 主要操作の流れ

主要操作が、一連の流れとして自然につながっているか。

単体では動いていても、続けて触ると違和感が出ることがある。

この確認は、シナリオ試験向きである。

6.4 空データ・エラー時の見え方

データがない場合や、取得に失敗した場合に、画面が不安にならないか。

何も表示されない。
壊れているように見える。
次に何をすればよいか分からない。

こういう状態は、初期公開前に潰しておきたい。

6.5 最後まで触ったときの印象

一連の流れを触った後に、

「まあ、少し分かってきた」
「次も触ってみようかな」
と思えるか。

逆に、

「何をしているのか分からない」
「画面が不安」
「説明不足」
「まだ見せるのは厳しい」

となるのか。

この印象を見たい。

7. 今のプロジェクトに必要なのは通し確認

最近の開発では、細かい改善が進んできた。

ログイン後の案内。
文言の統一。
自動テストの安定化。
スクリーンショット確認。
UI部品の整備。
PR単位でのmain反映。

これらは前進である。

ただし、個別の改善が進んでも、通しで触ったときに成立していなければ意味がない。

今必要なのは、まさに通し確認である。

画面Aは良い。
画面Bも良い。
でも、AからBへ移動したときに分かりにくい。
操作後にどこを見ればよいか分からない。
同じような説明が複数あり、逆に迷う。

こういう問題は、シナリオ試験で見つかりやすい。

8. Surfaceを暇にさせない使い方

Surfaceを常時動かすのは効率が悪い。
しかし、完全に眠らせておくのももったいない。

そこで、Surfaceには節目ごとのシナリオ試験を担当させる。

開発用PCが一定の改善を終えたら、Surfaceで長めのシナリオ試験を行う。

たとえば、

初回利用シナリオ
ログイン後の基本操作シナリオ
状態確認シナリオ
履歴確認シナリオ
エラー・空データ確認シナリオ
小画面での操作確認シナリオ

こうした形で、まとまった流れを確認する。

Surfaceが暇なときに、なんとなくファイルを作らせるのではない。
きちんとシナリオを与えて、実際に触らせる。

これなら、Surfaceの使い道としてかなり意味がある。

9. 期待している効果

Surfaceでシナリオ試験をやることで、期待している効果は大きい。

期待効果	内容
導線の弱さ発見	画面間のつながりの悪さを見つけられる
初回体験の改善	初めて触る人の迷いを減らせる
UI重複の発見	同じ案内や似たカードの重複に気づける
エラー時の不安解消	空データや失敗時の見え方を確認できる
自動テストの補完	Playwrightでは拾いにくい違和感を拾える
開発優先度整理	次に直すべきP0/P1を抽出できる

特に、最近は「中心画面のカード重複」や「次にできること」の見せ方が課題になっている。

これはまさに、シナリオ試験で見た方がよい部分である。

10. 注意点

もちろん、Surfaceにシナリオ試験をやらせる場合にも注意は必要である。

またファイル作成だけに逃げられると困る。

だから、指示では以下を明確にする必要がある。

新規テンプレート作成は禁止
実画面を確認する
操作した結果だけを書く
未確認を確認済みにしない
スクリーンショットを残す
P0/P1/P2で分類する
開発用PC側が直せる粒度で書く
長文の感想ではなく、修正につながる指摘にする

Surfaceには、文書作成係ではなく、シナリオ試験担当として働いてもらう。

ここを間違えないようにする。

11. 今回の結論

暇をしているSurfaceに、シナリオ試験を実施させることにした。

Surfaceを常時並行で動かすのは、効率が悪い。
しかし、節目ごとの実機確認や、長めのシナリオ試験には価値がある。

開発用PCでは実装と自動テストを進める。
Surfaceでは、ユーザー目線で通し確認を行う。

この分担なら、Surfaceの存在価値が出る。

今後は、Surfaceに単なるファイル作成をさせない。
実際に画面を開かせる。
流れで触らせる。
迷った箇所、詰まった箇所、不安になった箇所を記録させる。
スクリーンショット付きで、開発側が直せる指摘にする。

月商1億円を目指すなら、ただ機能があるだけでは足りない。
ユーザーが迷わず、安心して、また触りたいと思える体験が必要である。

そのために、Surfaceにはシナリオ試験担当として働いてもらう。

暇な端末を遊ばせるのではなく、品質改善のために使う。
これも、独力＋AI活用の開発体制を強くする一手になるはずである。

登録: 投稿 (Atom)