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

2026年5月2日土曜日

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

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

第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は、そのための一歩だった。

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

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

登録: 投稿 (Atom)