2026年5月2日土曜日

第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. 次にやるべきこと

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

これは妥当だと思う。

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

  1. 代表パターンのE2Eをさらに安定させる

  2. 詳細画面から次の体験画面へ進む導線を確認する

  3. 別パターンのシナリオを追加する

  4. 複数回繰り返す流れを確認する

  5. ステージング実機で通し確認する

  6. 画面品質や導線の違和感を潰す

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

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


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活用の開発体制を強くする一手になるはずである。

第33回:ログイン後に迷わない導線が、かなり改善されてきた

1. はじめに

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

最近の開発では、派手な新機能を増やすというより、ログイン後にユーザーが迷わない導線作りを重視している。

これはかなり重要だ。

どれだけ機能があっても、ログインした直後に何をすればよいか分からなければ、ユーザーは離脱する。
どれだけ中身を作り込んでも、最初の画面で迷わせたら意味がない。

今回の進捗では、その「最初に迷わないための改善」がかなり進んだ。


2. PR #13 まで完了した

今回、PR #13 まで完了し、対象の改善は main に反映済みとなった。

これはかなり良い進み方だと思っている。

単にコードを書いただけではなく、GitHub Actions を通し、既存の基本テストやメイン画面まわりのE2Eも確認したうえでマージしている。

AIを使った開発では、勢いで実装が進む一方で、品質確認やドキュメント整合が置き去りになることがある。

その意味で、今回のように、

  • feature ブランチで実装する

  • E2Eを確認する

  • GitHub Actionsを通す

  • PRでmainへ反映する

  • 残課題一覧も更新する

という流れで進められているのは、かなり良い。


3. ログイン後の最初の案内が改善された

今回の大きな改善は、ログイン後の中心画面に、「次にできること」 が分かる案内を出せるようになったことだ。

これは地味に見えるが、かなり効く。

ユーザーは、ログイン直後にこう思う。

「で、次に何をすればいいの?」

ここに対して、画面が何も答えてくれないと、ユーザーは迷う。
逆に、次にできることが最上段に出ていれば、かなり安心感がある。

今回の改善では、状態に応じて案内が変わるようになっている。

たとえば、

  • 今すぐ操作できるものがある場合

  • 今は操作対象がない場合

  • 情報取得に失敗している場合

  • 処理済みの履歴がある場合

こうした状態に応じて、ユーザーに次の行動を案内できるようになった。

これは、初期確認版の体験としてかなり大きい。


4. 文言の統一も進んだ

もう一つ良かったのは、外向けページ、ナビゲーション、ログイン後の中心画面で、主要な文言が揃ってきたことだ。

これも重要である。

画面ごとに言い方が違うと、ユーザーは混乱する。

同じ機能なのに、ある画面ではAと呼ばれ、別の画面ではBと呼ばれる。
これが積み重なると、サービス全体が分かりにくくなる。

今回、主要導線の文言がある程度揃ってきたことで、ユーザーが迷いにくくなった。

たとえば、以下のような導線が整理されてきている。

  • 一覧を見る

  • 対象を見る

  • 履歴を見る

  • 使い方を見る

具体的なサービス内容はまだ伏せるが、ログイン後に進むべき道が少しずつ見えやすくなってきた。


5. 重要なロジックに触らなかったのも良い

今回の改善で良かったのは、重要な残高系・精算系のロジックには触れていないことだ。

今の段階では、導線や表示改善を進めたい。
しかし、重要な処理ロジックを不用意に触ると、別の不具合を生む可能性がある。

今回は、ユーザー案内や画面上の導線改善が中心であり、コアロジックには手を入れていない。

これは良い判断だと思う。

AI開発では、つい「ついでに直す」「ついでに整える」が増えがちである。
しかし、影響範囲が広がるほど、レビューもテストも重くなる。

今回のように、目的を絞って進めるのは大事だ。


6. まだドキュメント上の小さな矛盾が残っている

一方で、まだ小さな課題も残っている。

残課題一覧の一部に、今回のPRで反映済みになった内容について、まだ「別途PRが必要」という趣旨の表記が残っている。

これは小さいようで、放置すると危ない。

AIに作業を依頼する場合、ドキュメントの表記をAIがそのまま信じることがある。

実際には完了しているのに、ドキュメント上に「未対応」「別途PR」と残っていれば、次回以降のCursorが誤解する可能性がある。

だから、次は小さなドキュメント整合のPRを入れたい。

アプリコードは触らず、残課題一覧だけを直す。
今回のPRで完了したことを反映し、まだ残っている課題と切り分ける。

これは地味だが、今後のAI活用ではかなり重要である。


7. 次は重複感の整理

今回の改善で、ログイン後の中心画面には「次にできること」が出るようになった。

ただし、その結果として、既存カードとの内容重複が少し出ている。

これは次に直したい。

同じような案内が画面上に複数あると、ユーザーは迷う。

「これは同じ意味なのか」
「どちらを押せばよいのか」
「なぜ似た情報が2つあるのか」

こういう違和感が出る。

次の実装候補としては、中心画面のカード重複を圧縮し、情報の優先順位を整理する作業がある。

これはUXとしてかなり効くと思っている。

画面をスッキリさせることは、単なる見た目の問題ではない。
ユーザーの迷いを減らすための重要な作業である。


8. もう一つの候補は体験画面の改善

もう一つの候補は、体験画面の演出改善である。

詳細画面から体験画面へ誘導する導線は少しずつ整ってきている。
そのため、次はその先の体験そのものを改善するのも自然である。

ただし、現時点では優先順位を慎重に見たい。

まずはログイン後の中心画面を分かりやすくする。
次に、重複や情報密度を整理する。
そのうえで、体験画面の演出を強化する。

この順番がよいと思っている。


9. 今の進め方は悪くない

今回の進捗を見ると、今の進め方はかなり良い。

以前は、要件が広がりすぎたり、ドキュメントが増えすぎたり、AIが余計な方向に進んだりすることもあった。

最近は、少しずつ進め方が整ってきた。

  • 開発用PCで実装する

  • Cursorで細かく進める

  • PR単位でmainへ反映する

  • GitHub Actionsを通す

  • E2Eを確認する

  • 小さなドキュメント矛盾も潰す

  • 進捗をブログで振り返る

これは、独力+AI活用の開発体制として、かなり現実的な形になってきた。


10. ただし、まだ油断はできない

一方で、まだ油断はできない。

ログイン後の導線は改善されてきた。
しかし、サービス全体の品質が十分になったわけではない。

まだ以下の課題は残っている。

  • 主要画面の情報密度

  • カードや導線の重複

  • 初回ユーザーの理解

  • スマホ表示

  • 体験画面の魅力

  • 回帰テストの定期実行

  • ステージングや実機確認

  • ドキュメント整合

特に、以前一人で確認したときに感じた「品質への不安」は、まだ完全には消えていない。

今回の改善は大きい。
ただし、まだ「人に見せられる」と胸を張れる段階までは、もう少し品質を上げる必要がある。


11. 次の優先順位

現時点の次の優先順位は、以下がよいと思っている。

  1. 残課題一覧の表記矛盾を直す

  2. 中心画面のカード重複を圧縮する

  3. 主要画面の情報整理を進める

  4. 体験画面の演出を改善する

  5. 回帰テストを継続的に通す

  6. 節目で実機確認を行う

まずは、小さなドキュメント整合を直す。
その後、中心画面の重複を整理する。
そして、体験画面や演出の改善へ進む。

順番としては、かなり妥当だと思っている。


12. 今回の結論

PR #13 まで完了し、ログイン後の中心導線はかなり改善された。

最上段に「次にできること」が表示され、状態に応じて案内が変わるようになった。
外向けページ、ナビゲーション、ログイン後の中心画面で主要文言も揃ってきた。
重要なコアロジックには触れず、導線改善に集中できた。
GitHub Actionsも通し、mainへ反映できている。

これはかなり良い前進である。

一方で、残課題一覧の小さな矛盾は早めに直したい。
AIが誤解しないよう、完了済みのものは完了済みとして明確にしておく必要がある。

次は、中心画面の重複整理。
その後、体験画面の改善。

まだ完成ではない。
まだ品質に不安はある。
しかし、ログイン後にユーザーが迷わない導線は、確実に良くなってきた。

独力+AI活用でも、少しずつプロダクトらしい形に近づいている。

注目の投稿

第3回:月商1000万円までのスケジュールを考える

月商1000万円までのスケジュールを考える 1. はじめに 月商1000万円を目指して、新規プロジェクトを進めている。 このブログでは、プロジェクトの具体的な企画内容は公開しない。 ただし、プロジェクトをどう進めているか、どこで悩んでいるか、どのように計画を立てているかは記録して...