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

2026年5月1日金曜日

第20回：結局、ここまでに実際いくら払ったのか

1. はじめに

月商1000万円を目指して、新規プロジェクトを進めている。

ここまで、PC購入、ChatGPT、Cursor、Gensparkなど、いくつかの開発投資をしてきた。

これまでは、主に「月額固定費」や「今後の投資判断」として費用を見ていた。
しかし、今回はもう少し現実的に整理したい。

それは、結局ここまでに、実際いくら払ったのかである。

サービスを作るにはお金がかかる。
無料でできる部分もあるが、本気で進めようとすると、開発環境、AIツール、デザインツール、検証環境などに少しずつ費用が発生する。

今回は、現時点で分かっている実支払い額を整理する。

2. 一番大きい支払いは開発用PC

まず、現時点で一番大きい支払いは、開発用PCである。

今回購入したのは、BOSGAME P3 PLUS。

スペックとしては、Ryzen 7 7840HS、32GBメモリ、1TB SSDのミニPCである。
開発用としてはかなり心強い。

購入価格は、税込87,900円。

これは月額費用ではなく、一時費用である。

ただし、金額としてはかなり大きい。
AIツールの月額費用とは違い、一度にまとまった金額が出ていく。

それでも購入した理由は、開発効率を上げるためである。

実際、新PC導入後は、実装、E2Eテスト、build確認、commit / pushまでの流れがかなり回しやすくなった。

つまり、この87,900円は、単なるガジェット購入ではなく、開発体制への投資である。

3. 現時点で判明している支払い

現時点で整理できている支払いは、以下である。

区分	項目	金額	状態
一時費用	BOSGAME P3 PLUS	87,900円	購入済み
AIツール	Genspark Plus	$27.49 / 月	契約中
AIツール	Cursor 初期プラン	$20想定	要明細確認
AIツール	Cursor Pro+	$60 / 月	現在利用中
AIツール	ChatGPT	月額課金中	要明細確認
検討中	Cursor Ultra	$200 / 月	未契約

この中で、金額として確定的に扱えるのは、まずPCの 87,900円。
Gensparkについても、画面上で $27.49 / 月 が確認できている。

Cursorについては、最初に$20プランを使い、その後$60のPro+へ上げている。
ただし、実際に$20と$60がそれぞれ請求されているのか、アップグレード時に日割りやクレジット調整が入っているのかは、請求履歴を確認する必要がある。

4. Cursorの実支払いは要確認

Cursorについては、ここが少しややこしい。

現在のプランは Pro+ $60/月。
さらに、使用量が上限に近づいているため、Ultra $200/月 へのアップグレードも検討している。

ただし、実支払い額としては、以下を分けて考える必要がある。

項目	扱い
$20プラン	過去に支払った可能性あり
$60 Pro+	現在の支払い対象
$200 Ultra	まだ未契約なので、実支払いには入れない
$140差額	Pro+からUltraにした場合の今後の月額増加分

ここで注意したいのは、$140は実支払い済みの金額ではないという点である。

$140は、現在の$60プランから$200プランに上げた場合に、今後毎月増える固定費の差額である。

一方で、ここまで実際に払った金額としては、$20と$60がそれぞれ発生している可能性がある。

ここは、Cursorの請求履歴またはカード明細で確認する必要がある。

5. Gensparkは月額$27.49

Gensparkについては、現在 Plus Monthly Subscription を契約している。

金額は、1か月ごとに$27.49。

Stripe経由で日本円請求されている。

Gensparkは、主に以下の用途で使っている。

デザイン案
LP案
チラシ的な素材
画面イメージ
外向け表現の検討

CursorやChatGPTが開発や仕様整理に近い役割だとすると、Gensparkはデザインや見せ方の補助という位置づけである。

6. ChatGPTの費用

ChatGPTも月額課金して使っている。

用途としては、かなり広い。

アイデアの壁打ち
要件整理
課題の棚卸し
Cursorへの指示文作成
ブログ記事作成
プロジェクト計画
リスク整理
GitHub状況の把握
開発方針の整理

自分にとってChatGPTは、単なるチャットツールではない。

PMO、議事録係、壁打ち相手、仕様整理担当、記事作成担当に近い。

ただし、今回の記事では「実支払い額」を整理したいので、ChatGPTについてもカード明細や請求履歴を確認し、実際に何円払っているかを記録したい。

7. 現時点の概算

現時点で、最低限見えている費用を整理すると、以下になる。

項目	金額
BOSGAME P3 PLUS	87,900円
Genspark	$27.49
Cursor $20プラン	$20想定
Cursor Pro+	$60想定
ChatGPT	３０００円

外貨分だけを単純に足すと、

$20 + $60 + $27.49 = $107.49

となる。

つまり、AIツール系だけでも、ChatGPT分を除いて $107.49前後 を支払っている可能性がある。

ここにChatGPTの月額費用が加わる。
さらに、PC代として 87,900円 が加わる。

ただし、Cursorについてはアップグレード時の日割りや調整がある可能性があるため、実支払い額は明細確認が必要である。

8. 現時点で確実に言えること

現時点で確実に言えるのは、開発費用はすでに小さくないということだ。

PCだけで 87,900円。
そこに、Cursor、ChatGPT、Gensparkなどの月額費用が乗っている。

まだ売上は立っていない。

その状態で、これだけの費用を使っている。

これは少し怖さもある。

ただし、現時点では無駄遣いというより、開発を前に進めるための投資だと考えている。

特に新PCについては、実際に開発効率の向上を感じている。
Cursorも、実装、E2E、ドキュメント更新にかなり使っている。
ChatGPTは、プロジェクト管理や壁打ちに欠かせない。
Gensparkは、デザインや外向け表現の検討に役立っている。

つまり、支払いは増えているが、それぞれ役割はある。

9. ただし、費用管理は必要

とはいえ、役に立っているからといって、無制限に課金してよいわけではない。

今後は、費用管理をもっときちんと行う必要がある。

特に、Cursor Ultraの$200/月を契約する場合は、かなり大きな判断になる。

現時点で、Cursor Pro+の使用量はかなり上限に近づいている。
そのため、Ultraへのアップグレードは現実的な選択肢になっている。

しかし、すでにPC代87,900円を支払い、他のAIツール費用もある。

ここでさらに月額$200を追加するなら、明確に効果測定が必要である。

たとえば、

一人用確認版がどれだけ早まったか
実装量が増えたか
E2E追加が進んだか
待ち時間や制限による停止が減ったか
サービスインまでの見通しが良くなったか

こうした観点で見たい。

10. 今後確認すべき明細

今回、実支払い額を確定するために、以下を確認したい。

確認対象	確認したい内容
Amazon購入履歴	BOSGAME P3 PLUS 87,900円の確定
Cursor請求履歴	$20と$60がどう請求されたか
Genspark / Stripe	$27.49の円換算額
ChatGPT請求履歴	月額の実請求額　３０００円
クレジットカード明細	外貨決済の円換算額と手数料
その他	ドメイン、サーバー等の支払い有無

この確認をすれば、実際にここまでいくら払ったのかがかなり正確に見える。

11. 今回の結論

ここまでの実支払いを整理すると、まず大きいのは開発用PCである。

BOSGAME P3 PLUS：87,900円。

これは、現時点で最も大きな一時費用である。

加えて、AIツール系として、

Cursor $20プラン
Cursor Pro+ $60
Genspark $27.49
ChatGPT月額費用 3000円

が発生している。

単純計算では、ChatGPTを除いてもAIツール系で $107.49前後 を支払っている可能性がある。
ただし、Cursorの実請求は日割りや調整がある可能性があるため、明細確認が必要である。

そして、Cursor Ultra $200はまだ未契約なので、今回の実支払い額には入れない。
ただし、今後の開発加速投資として、かなり現実的な検討対象になっている。

開発は進んでいる。
一人用確認版も近づいている。

しかし、その裏側では、確実にお金も出ていっている。

月商1000万円を目指すなら、投資は必要である。
ただし、支出を見ないふりしてはいけない。

ここからは、開発進捗だけでなく、実支払い額も定期的に整理していきたい。

売上が立つ前の投資をどう管理するか。
それも、このプロジェクトの重要な課題である。

第19回：Cursorのアップグレードが必要になる時期が近い

1. はじめに

月商1000万円を目指して、新規プロジェクトを進めている。

このブログでは、プロジェクトの具体的な企画内容はまだ公開しない。
ただし、開発の進め方、AI活用、費用、進捗、課題、判断の過程については記録している。

今回は、AI開発ツールである Cursorの利用量 について書く。

以前から、Cursorの上位プランに上げるかどうかは迷っていた。
現在は Pro+ の月額$60プラン を使っている。

ただ、最近の利用状況を見ると、いよいよ Ultra 月額$200プラン へのアップグレードを現実的に考える時期が近づいてきた。

2. 現在のCursor利用状況

現在のCursor利用状況は、かなり上限に近づいている。

現時点の表示では、以下のようになっている。

項目	状況
現在のプラン	Pro+
月額	$60 / 月
Total使用量	92%
Auto + Composer	90%
API	100%
次回リセット	5月25日
リセットまで	24日
On-Demand Usage	Disabled
アップグレード候補	Ultra $200 / 月

特に大きいのは、API使用量が100%に到達していることである。

Totalもすでに92%。
まだリセットまで24日ある。

つまり、今の開発ペースだと、Pro+の範囲では明らかに足りなくなってきている。

3. なぜここまで使っているのか

Cursorの使用量がここまで増えた理由は明確である。

最近は、Cursorを単なるコード補助ではなく、かなり本格的な開発担当として使っている。

実際に任せている作業は、以下のようなものだ。

実装
既存コード調査
不具合修正
画面改善
E2Eテスト追加
回帰テスト整備
ドキュメント更新
README更新
build / lint / format確認
commit / push前後の整理
作業報告の作成

特に、新PCであるBOSGAME P3 PLUSが届いてからは、実装、E2E、build、commit / pushまでを1セッションでかなり回しやすくなった。

その結果、Cursorの利用量も一気に増えている。

これは悪いことではない。

むしろ、Cursorをかなり有効活用できている証拠でもある。

ただし、問題は、使えているからこそ上限に当たり始めているという点である。

4. 今の開発ペースだと、Pro+では厳しい可能性が高い

現時点で、リセットまでまだ24日ある。

それなのに、Total 92%、API 100%。

これは、かなり厳しい。

今後も一人用確認版に向けて、以下の作業が残っている。

手動確認項目の消化
残画面の空データ・エラー表示確認
E2E追加
回帰テスト維持
主要導線の通し確認
スマホ確認
ドキュメント整備
mainへの取り込み
次の実装ブランチ作成
一人用確認版の完成条件整理

これらを進めるには、Cursorをかなり使う。

つまり、今のままだと、途中でCursorの利用制限が開発速度のボトルネックになる可能性がある。

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

一人用確認版が近づいてきたタイミングで、AI開発ツールの使用量制限にぶつかるのは避けたい。

5. Ultra $200/月は高いが、現実的な選択肢になってきた

Cursorには、さらに上位の Ultra $200/月 がある。

月額$200は、個人開発の固定費としてはかなり重い。

現在のPro+が$60なので、Ultraにすると追加で 月額+$140 になる。

これは決して軽い金額ではない。

ただし、今の開発状況を考えると、単なる贅沢とは言い切れない。

現在のプロジェクトでは、Cursorは実装担当に近い役割を担っている。

もしCursorの制限によって作業が止まると、一人用確認版の到達時期にも影響する。

逆に、Ultraにすることで開発を止めずに進められるなら、$200/月は開発速度を買う投資とも言える。

6. 判断基準は「高いか安いか」ではない

ここで考えるべきなのは、単純に「$200は高いか安いか」ではない。

大事なのは、その費用で何が前倒しできるかである。

判断基準は、以下になる。

判断軸	確認したいこと
開発速度	一人用確認版への到達が早まるか
待ち時間	Cursor制限による停止が減るか
作業量	1セッションあたりの実装量が増えるか
品質	E2Eやbuild確認まで回しやすくなるか
精神面	制限を気にせず作業できるか
費用対効果	差額$140以上の価値があるか

もしUltraにすることで、一人用確認版が1〜2週間早まるなら、十分に検討価値はある。

逆に、プランを上げても指示が曖昧で、作業が進まないなら意味がない。

つまり、アップグレードはCursorだけの問題ではない。
Cursorに何をさせるか、どれだけ具体的に指示できるかもセットで考える必要がある。

7. 1か月限定の開発加速期間として考える

現時点での考え方としては、Ultraに上げる場合、まずは 1か月限定の開発加速期間 として扱うのがよいと思っている。

いきなり長期前提で契約するのではなく、1か月だけ試す。

その1か月で、以下を検証する。

一人用確認版にどれだけ近づいたか
実装セッション数が増えたか
E2E追加が進んだか
手動確認項目の消化が進んだか
回帰テストが維持できたか
Cursorの制限による停止が減ったか
サービスイン見通しが前倒しになったか

効果が大きければ継続する。
効果が薄ければPro+に戻す。

このやり方なら、固定費増加のリスクを抑えながら、開発加速の効果を確認できる。

8. On-Demand Usageという選択肢もある

現時点では、On-Demand UsageはDisabledになっている。

つまり、追加利用分を都度課金で使う設定にはしていない。

選択肢としては、Ultraに上げる以外にも、On-Demandを使う方法があるかもしれない。

ただし、On-Demandは使い方を間違えると費用が読みにくくなる可能性がある。

月額$200のUltraにする方が、費用上限が見えやすい面もある。
一方で、一時的な不足だけならOn-Demandの方が安く済む可能性もある。

ここは、今後の利用量を見ながら判断したい。

ただ、現在のようにリセットまで24日残してAPI 100%という状況だと、一時的な不足というより、今の開発ペースに対してPro+が足りていない可能性が高い。

9. アップグレードしない場合の対策

もちろん、すぐUltraに上げない選択肢もある。

その場合は、Cursorの使い方を絞る必要がある。

たとえば、以下のような対策が考えられる。

Cursorに投げる作業をP0に絞る
大きすぎる指示を減らす
ドキュメント更新だけの作業ではCursorを使いすぎない
ChatGPTで指示文をより精密に作ってから渡す
E2E追加対象を厳選する
手動でできる軽い作業は自分でやる
実装セッション数を抑える
リセット日まで重要作業だけに集中する

ただし、今は一人用確認版に近づいている大事な時期である。

ここでCursor利用を抑えすぎると、進捗が鈍る可能性もある。

だから、節約と加速のバランスが難しい。

10. 一人用確認版への影響

現時点で、一人用確認版への到達度は 48〜55%程度 と見ている。

一人用確認版は、2026年5月中を目標にしている。

ここから先は、単に仕様を考えるだけではなく、実装、E2E、手動確認、通し確認が必要になる。

つまり、Cursorの使用量はさらに増える可能性が高い。

このタイミングで制限にぶつかると、開発速度が落ちる。

逆に、Ultraに上げてCursorを止めずに使えるなら、5月中の一人用確認版到達に向けてかなり有利になるかもしれない。

もちろん、Ultraにしたからといって自動的に完成するわけではない。

必要なのは、以下である。

作業指示の精度
P0への集中
1セッションごとの完了条件
E2Eとbuild確認
commit / pushまでの完了
残課題の更新
次作業への連続性

これらがあって初めて、Ultraの効果が出る。

11. 現時点の結論

Cursorのアップグレードが必要になる時期は、かなり近い。

現時点で、Pro+ $60/月の使用量は以下である。

Total 92%
Auto + Composer 90%
API 100%
リセットまで24日

この状況を見る限り、今の開発ペースではPro+の上限に収まりきらない可能性が高い。

Ultra $200/月は高い。
しかし、一人用確認版が近づいている今、開発を止めないための投資としては現実的な選択肢になってきた。

判断としては、すぐに長期継続を決めるのではなく、1か月限定の開発加速期間として試すのがよさそうである。

月商1000万円を目指すなら、必要なところには投資しなければならない。
ただし、投資は効果測定とセットで行う必要がある。

今回のCursorアップグレード判断は、単なるサブスク変更ではない。

これは、個人開発をどこまでAIに任せ、どこまで開発速度を買うかという判断である。

一人用確認版が近い。
だからこそ、ここで止まりたくない。

そのために、Cursor Ultraへのアップグレードは、いよいよ現実的な選択肢になってきた。

第18回：一人用で実施できる状態が、かなり近づいてきた

1. はじめに

月商1000万円を目指して、新規プロジェクトを進めている。

このブログでは、プロジェクトの具体的な企画内容はまだ公開しない。
ただし、開発状況、進捗、課題、費用、AI活用、プロジェクト管理については記録している。

今回は、現時点での大きな節目について書きたい。

それは、一人用で実施できる状態がかなり近づいてきたということだ。

まだ完成ではない。
まだ正式公開できる状態でもない。
限定公開版でもない。

ただ、自分自身が一人のユーザーとして触り、主要な流れを確認できる状態が、かなり現実的になってきた。

2. 一人用確認版とは何か

まず、ここで言う「一人用確認版」は、本番サービスではない。

一般ユーザーに広く使ってもらうものでもない。
収益化を開始する段階でもない。

一人用確認版とは、まず自分自身がサービスの最初から最後までの基本体験を確認するためのバージョンである。

一人用確認版で確認したいのは、主に以下である。

新規ユーザーとして開始できるか
初回説明や基本導線が分かるか
メイン画面に進めるか
基本操作を一通り試せるか
データが作成・更新・表示されるか
結果や履歴を確認できるか
空データやエラー時に破綻しないか
管理者が細かく操作しなくても、最低限の流れが成立するか
スマホでも最低限確認できるか
致命的なエラーで止まらないか

つまり、「完璧な製品」ではなく、サービスの中心体験が通る状態である。

ここまで到達できれば、次に限定公開やプレオープンへ進むための土台ができる。

3. 現在地はかなり進んできた

現時点の進捗感としては、一人用確認版に対して 48〜55%程度 まで来ていると見ている。

以前は、まだ構想・仕様・ドキュメントの比重が大きく、実際に通しで確認できる状態までは距離があった。

しかし、最近は少しずつ状況が変わってきた。

特に大きいのは、以下である。

新PC導入により、実装・E2E・build確認が回しやすくなった
PlaywrightによるE2Eテストが積み上がってきた
回帰テストの範囲が広がってきた
空データや取得失敗時のUI確認が進んできた
主要導線の破綻を潰す作業が進んできた
ドキュメントと実装の連携が少しずつ整ってきた
Cursorへの連続指示により、実装が止まりにくくなってきた

まだ半分を少し超えた程度の感覚ではある。

ただし、単なる企画段階ではない。
動くものが増え、確認できるものが増え、テストで守れる範囲も増えてきている。

ここは大きな前進である。

4. 最近の進捗で大きかったこと

直近では、画面の空データ状態や取得失敗状態の整備が進んだ。

これは一見すると地味な作業である。

しかし、一人用確認版にとってはかなり重要である。

実際にサービスを触るとき、常に理想的なデータがあるとは限らない。
データがない状態もある。
読み込みに失敗することもある。
想定外の状態になることもある。

そのときに、画面が壊れて見える。
何も表示されない。
何が起きているのか分からない。
関連する操作だけができそうに見える。

こういう状態だと、通し確認中に不安になる。

今回のように、空データや取得失敗時の表示を整え、E2Eテストで確認できるようにしたことは、地味だが重要な前進である。

5. E2Eテストが効いてきている

一人用確認版に近づいていると感じる理由の一つに、E2Eテストがある。

すでにPlaywrightを使って、画面操作ベースの確認を行っている。

直近では、特定の確認項目で 16件のE2Eテスト が通り、さらに一人用回帰テストとして 28件 が通っている。

これはかなり大きい。

もちろん、E2Eテストが通ったからといって、すべての品質が保証されるわけではない。

ユーザー体験の良し悪し、分かりやすさ、楽しさ、導線の自然さは、最終的には人間が見る必要がある。

ただし、主要な導線が壊れていないこと、重要な画面が落ちないこと、空データやエラー状態で破綻しないことを自動で確認できるのは大きい。

一人用確認版では、まず自分で触ることが重要だが、その前提として最低限壊れていない状態を作る必要がある。

その意味で、E2Eテストが効いてきている。

6. 新PC導入も効いている

新PC、BOSGAME P3 PLUSの導入も大きい。

これにより、実装、ローカル確認、E2E、build、commit / pushまでの流れがかなり回しやすくなった。

既存PCではChatGPTとの壁打ち、記事作成、仕様整理、次の指示文作成を行い、新PCではCursorによる実装と検証を進める。

この役割分担がうまく機能し始めている。

1台で全部やっていたときは、どうしても画面も頭も混ざりやすかった。
今は、思考と実装を分けやすくなっている。

これは単なる性能向上ではない。

開発体制そのものが少し整ってきたという感覚に近い。

7. まだ完成ではない

ただし、ここで勘違いしてはいけない。

一人用確認版は近づいているが、まだ完成ではない。

残っている作業はまだある。

主な残課題は以下である。

手動確認項目の消化
本番相当の権限・RLS確認
主要画面の空データ・エラー表示確認
残画面のdevシミュレートやtestid棚卸し
Surface側のチェックリスト連携
一人用確認版の完成条件整理
主要導線の通し確認
スマホでの最低限確認
素材や表示の最低限整合
管理者操作を使わなくても最低限進行できる確認

特に重要なのは、通し確認である。

個別機能が動いていても、最初から最後まで触ったときに自然につながるとは限らない。

画面単位では動く。
テストも通る。
でも、ユーザーとして触ると次に何をすればいいか分からない。

こういうことはよくある。

だから、今後は個別機能の確認だけでなく、一人用の体験として通すことが重要になる。

8. 一人用確認版で大事なのは「全部入り」ではない

一人用確認版では、すべての機能を入れる必要はない。

ここを間違えると、いつまでも完成しない。

今後も追加したい機能は多い。
仕様も多い。
残課題も多い。
やりたい演出や改善もたくさんある。

ただ、一人用確認版の目的は、完成品を作ることではない。

目的は、サービスの中心体験が成立しているかを確認することである。

だから、以下のような割り切りも必要になる。

一部の演出は後回しでよい
細かいデザイン調整は後でよい
高度な管理機能は最低限でよい
収益化導線はまだ仮でよい
本番運用向けの細部は後で詰める
まずは通しで触れることを優先する

一人用確認版は、完成版ではなく、次のフェーズへ進むための確認版である。

9. いつごろ一人用確認版に到達できそうか

現時点では、一人用確認版については、引き続き 2026年5月中 を目標にしたい。

もちろん、まだ確定ではない。

残課題はある。
確認も必要である。
想定外の不具合も出る可能性がある。

ただ、新PC導入後の実装効率、E2Eの積み上がり、最近の進捗を見ると、5月中に一人用確認版の通し確認へ持っていく現実味はかなり上がってきた。

今の感覚では、あと複数セッションで、一人用確認版としての通し確認に入れる可能性がある。

ただし、ここで重要なのは、焦って雑に区切らないことである。

一人用確認版と呼ぶ以上、最低限の中心導線は通したい。
致命的なエラーで止まる状態では区切りたくない。
空データやエラー状態も、最低限説明される状態にしたい。

だから、5月中を目指しつつ、完成条件は冷静に見る。

10. 一人用確認版に到達した後の意味

一人用確認版に到達すると、プロジェクトの意味がかなり変わる。

これまでは、主に作る段階だった。

仕様を考える
ドキュメントを書く
実装する
画面を作る
テストを追加する
課題を整理する

しかし、一人用確認版に到達すると、次は触って評価する段階に入る。

実際に自分で使ってみて、

面白いか
分かりやすいか
続けたくなるか
どこで迷うか
どこが弱いか
どこを強化すべきか
限定公開に出せるか

を見られるようになる。

これは大きい。

作っているだけでは分からないことが、触ることで見えてくる。

11. ここからが本当の検証でもある

一人用確認版が近いということは、開発が終わるという意味ではない。

むしろ、ここからが本当の検証でもある。

一人用で通してみると、必ず課題が出るはずである。

思ったより分かりにくい
導線が長い
説明が足りない
画面が重い
スマホで見づらい
操作が面倒
期待したほど楽しくない
逆に、想定以上に良い部分がある

こうしたことは、実際に触らなければ分からない。

だから、一人用確認版はゴールであると同時に、次の改善のスタートでもある。

12. 現時点の方針

今後の方針は、かなり明確である。

まず、現在のブランチをmainに取り込む
次に、残っているP0確認項目を消化する
主要導線の通し確認に近づける
空データ・エラー表示の残りを潰す
Surface側のチェックリストや指示文と連携する
スマホで最低限確認する
一人用確認版の完成条件を明文化する
通し確認で出た課題を整理する
限定公開版に必要な項目を切り分ける
初期サービスインへ向けた次の計画に進む

この流れで進めたい。

ここからは、単に機能を増やすだけではなく、確認版として成立させるための整理が重要になる。

13. 今回の結論

一人用で実施できる状態は、かなり近づいてきた。

まだ完成ではない。
まだ正式公開でもない。
まだ収益化でもない。

しかし、現時点で一人用確認版への到達度は 48〜55%程度 まで来ている。

新PCの導入により、実装・E2E・build・commit / pushの流れがかなり回しやすくなった。
PlaywrightによるE2Eテストも積み上がっている。
空データやエラー時の表示整備も進んでいる。
主要導線を壊さず進める土台ができつつある。

一人用確認版は、引き続き 2026年5月中 を目標にする。

ここまで来ると、少し見えてきた。

最初は膨大な要件、膨大な仕様、膨大な残課題に圧倒されていた。
今もそれは変わらない。

ただ、少なくとも「動くもの」として確認できる状態が近づいている。

月商1000万円までは、まだまだ遠い。
でも、最初の大きな節目である一人用確認版は、もう遠い夢ではなくなってきた。

まずは、ここを必ず通す。

一人で触って、確認して、直して、次のフェーズに進む。

いよいよ、作るだけの段階から、実際に体験を検証する段階へ近づいてきた。

第17回：新PCは開発効率をどれだけ上げたのか

1. はじめに

月商1000万円を目指して、新規プロジェクトを進めている。

今回は、ついに届いた新PC、BOSGAME P3 PLUS を使った開発について書く。

これまでは、新PCに対してかなり期待していた。

既存PCと新PCを併用することで、ChatGPTでの整理、Cursorでの実装、GitHubでの管理、E2Eテスト、ビルド確認をより効率的に回せるのではないかと考えていた。

では実際に、新PCが来てどうだったのか。

結論から言うと、かなり効果はあった。

ただし、PCが増えただけで魔法のように開発速度が倍になるわけではない。
重要なのは、2台体制に合わせて作業範囲を分け、役割を明確にし、止まらない運用に近づけることだと改めて感じた。

2. 今回はBOSGAME側で実装セッションを回した

今回の作業は、BOSGAME P3 PLUS側で実施した。

作業内容としては、実装、E2Eテスト追加、ドキュメント更新、チェック、commit、pushまで含めた一連の開発セッションである。

ざっくり言うと、今回の1セッションで以下まで完了した。

一部画面の空データ状態・取得失敗状態の表示改善
関連する購入ブロック側の表示整合
dev用のシミュレート機能追加
Playwright系E2Eテスト追加
回帰テストへの組み込み
ドキュメント更新
lint / format / build 確認
E2E 16件確認
回帰テスト28件確認
commit / push

これは、かなりまとまった作業である。

以前の1台体制だと、実装、確認、ドキュメント、ChatGPTでの整理、次の指示検討がかなり混ざりやすかった。
今回、新PC側に実装と検証を寄せられたことで、作業の流れがかなり整理された。

3. 今回の成果

今回の開発セッションでは、主に「データがない場合」「データ取得に失敗した場合」の画面表示を整えた。

こういう作業は、一見すると地味である。

しかし、サービスとしてはかなり重要である。

ユーザーが画面を開いたとき、データがないだけなのに壊れているように見える。
データ取得に失敗したのに、何も説明がない。
関連する別ブロックでは購入できそうに見えてしまう。

こうした状態は、実際にサービスを触る段階では大きな不安につながる。

今回の作業では、そうした不整合を潰し、E2Eテストでも確認できるようにした。

チェック結果としては、以下まで通っている。

チェック	結果
lint	OK
format check	OK
build	OK
E2E empty guards	16 passed
one-player regression	28 passed
commit / push	完了

ここまでを1セッションで回せたのは大きい。

新PCによる効率化は、単に処理が速いというより、実装から確認、commit / pushまでを一つの流れとして回しやすくなったことにある。

4. 二台開発の効果

今回特に感じたのは、2台体制の効果である。

新PC側では、実装、ローカル確認、テスト、ビルドを進める。
既存PC側では、ChatGPTでの整理、記事作成、次の指示文検討、進捗把握を行う。

この分担ができると、頭の切り替えが楽になる。

これまで1台で全部やっていたときは、画面が混ざりやすかった。

Cursor
ブラウザ確認
ターミナル
ChatGPT
ドキュメント
GitHub
テスト結果
次の指示文

これらを1台で切り替えると、作業そのものよりも、画面管理と頭の切り替えで疲れる。

2台になると、役割を分けられる。

端末	主な役割
新PC	実装、E2E、build、commit / push
既存PC	ChatGPT壁打ち、指示整理、進捗確認、記事作成

この分担はかなり良い。

ただし、2台になると競合リスクも出る。
そのため、今回も作業宣言を行い、どの端末がどの作業を担当するかを明確にして進めた。

5. 作業宣言の重要性

今回の作業では、端末、ブランチ、重複作業の有無、参照ドキュメント、作業前後のgit statusまで確認している。

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

2台体制では、同じファイルを別々のPCで触ってしまうと危険である。
Gitの競合も起きるし、どちらが正しい変更か分からなくなる。

そのため、作業前に以下を明確にする必要がある。

どの端末で作業するか
どのブランチで作業するか
他端末側で重複作業していないか
参照する指示書はどれか
今回触るファイルは何か
作業後にcommit / pushするか
終了時にgit statusがcleanか

今回のセッションでは、この流れがかなりうまく機能した。

特に、終了時に clean で終われているのは大きい。

作業が中途半端に残っていると、次回の開始時にまず状況確認から入る必要がある。
それだけで時間を失う。

新PCを使うだけでなく、作業をきれいに閉じることが効率化には重要だと感じた。

6. 開発効率はどれくらい上がったのか

では、新PCによって開発効率はどれくらい上がったのか。

正確な数字を出すのはまだ難しい。

まだ新PC到着後の初期段階であり、長期的な平均を取れるほどのデータはない。

ただ、今回の1セッションを見る限り、少なくとも以下の効果はあった。

実装と確認を止めずに進めやすい
E2Eテストやbuildを実行しやすい
ChatGPT側の整理と実装作業を分離できる
commit / pushまでの流れがスムーズ
作業後の報告が明確になった
進捗率の見立てを更新できた

今回の成果により、一人用確認版への到達度は、ざっくり 48〜55% まで来たと見ている。

前回はおおよそ 45〜50% くらいの感覚だったので、今回の作業で +1〜3% 程度前進した印象である。

たった1〜3%と思うかもしれない。

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

なぜなら、今回進んだのは単なる見た目の追加ではなく、空データ・エラー・購入導線・E2E回帰確認という、サービスを壊さず進めるための土台部分だからである。

7. 一人用確認版はいつごろできそうか

では、このペースで一人用確認版はいつごろできそうなのか。

現時点では、まだ断言はできない。

ただし、新PC導入によって、5月中に一人用確認版の通し確認へ近づける可能性は高まったと思っている。

現在の見立ては以下である。

到達目標	現在地
一人用確認版	約48〜55%
初期サービスイン版	まだ先
月商1000万円	まだ入口

一人用確認版までには、まだ複数セッションが必要である。

残っている主な作業としては、以下がある。

手動確認項目の消化
本番相当の権限・RLS確認
残画面の空データ・エラー表示確認
Surface側のチェックリスト連携
主要導線の通し確認
最低限の素材・表示整合
一人用確認版としての完了条件整理

ただ、今回のように、1セッションで実装、E2E、build、commit / pushまで回せるなら、かなり現実味は出てきた。

一人用確認版については、引き続き 2026年5月中を目標に置きたい。

ただし、これは「全機能完成」ではない。
あくまで、自分が一人で主要導線を通し確認できる状態である。

8. 新PCで分かった課題

一方で、新PCによって課題がすべて解決したわけではない。

むしろ、2台体制になったことで新しい課題も見えた。

8.1 Surface側アウトプットの運用

今回、Surface側のアウトプット置き場を確認したが、対象フォルダがまだ未作成だった。

そのため、今回は既存ドキュメントと既存タスクをもとに進めた。

今後は、Surface側で次回BOSGAME向け指示を作成し、リポジトリ内に置く運用ができると、さらに効率が上がる。

つまり、

Surface側で仕様・指示を整理する
BOSGAME側で実装・E2Eを進める
GitHubで状態を共有する

という役割分担がより明確になる。

8.2 並行開発の衝突リスク

2台体制は便利だが、同じファイルを触ると危険である。

今回のように作業宣言を行い、重複なしで進める必要がある。

今後は、より明確に以下を管理したい。

どのPCが何を担当しているか
触ってよい範囲
触らない範囲
ブランチの役割
mainへの取り込みタイミング
rebaseやpullのタイミング

2台開発は、効率化にもなるが、運用を誤ると混乱も増える。

8.3 まだ待ち時間はある

新PCによって効率は上がったが、待ち時間がなくなったわけではない。

build、E2E、commit、push、AIの実装待ち、差分確認などは引き続き発生する。

ただ、2台体制により、その待ち時間に別端末で整理や記事作成を進めやすくなった。

待ち時間そのものを消すというより、待ち時間を無駄にしにくくなったという感覚に近い。

9. 次にやるべきこと

今回の作業後、次にやるべきことも見えている。

優先度が高いのは、まず今回のブランチをmainに取り込むことである。

そのうえで、次は以下に進みたい。

手動確認項目の消化
残画面の空データ・エラー表示確認
Surface側アウトプットの整備
一人用確認版の完成条件整理
主要導線の通し確認

特に、一人用確認版に向けては、これ以上「ただ機能を増やす」だけではなく、通しで触れる状態に近づけることが重要である。

10. 今回の結論

新PC、BOSGAME P3 PLUS の導入は、かなり効果があった。

今回のセッションでは、実装、E2E追加、ドキュメント更新、lint、format、build、E2E 16件、回帰28件、commit / pushまで一通り完了できた。

これは、2台開発体制の効果がかなり出た結果だと思う。

開発効率は確実に上がっている。

ただし、それはPCの性能だけではない。

作業宣言をする
端末ごとの役割を分ける
ブランチを明確にする
E2Eまで回す
commit / pushまで完了させる
終了時にcleanにする
進捗率を更新する

こうした運用とセットで初めて、新PCの効果が出る。

現時点で、一人用確認版への到達度は 48〜55% 程度。
今回の作業で +1〜3% 進んだ感覚である。

一人用確認版は、まだ完成ではない。
しかし、5月中に通し確認できる状態を目指す現実味は上がってきた。

新PCは、単なる買い物ではなく、開発体制への投資だった。

そして少なくとも今回のセッションを見る限り、その投資はかなり意味があったと思っている。

2026年4月30日木曜日

第16回：既存サービスとの差別化は、本当に十分なのか

1. はじめに

月商1000万円を目指して、新規プロジェクトを進めている。

このブログでは、プロジェクトの具体的な企画内容はまだ公開しない。
ただし、開発の進め方、課題、リスク、投資判断、AI活用、プロジェクト管理については記録している。

今回は、既存サービスとの差別化について書く。

新しいサービスを作る以上、必ず考えなければならないのが、既存サービスとの差である。

すでに似たようなサービスがある中で、なぜ自分のサービスを使ってもらえるのか。
なぜ時間を使ってもらえるのか。
なぜお金を払ってもらえるのか。
なぜ継続してもらえるのか。

ここを曖昧にしたまま開発を進めるのは危険である。

今回のプロジェクトでも、既存サービスとの差別化については考えている。
そして、その対策もいくつか入れようとしている。

ただし、正直に言うと、その差別化がどこまで効果的なのかは、まだ分からない部分もある。

ここは大きな懸念であり、リスクでもある。

2. 既存サービスがあること自体は悪いことではない

まず、既存サービスがあること自体は、必ずしも悪いことではない。

むしろ、既存サービスがあるということは、そこに需要がある可能性がある。

誰もやっていない領域は魅力的に見えるが、実際には需要がないだけかもしれない。
逆に、すでに誰かがやっている領域は、ユーザーが存在し、課金や利用習慣が成立している可能性がある。

だから、既存サービスがあること自体は問題ではない。

問題は、その中で自分のサービスが選ばれる理由を作れるかどうかである。

既存サービスと同じようなものを、後から出すだけでは厳しい。
ユーザーはすでに慣れているものを使い続ける。
よほど大きな理由がなければ、乗り換えてくれない。

だからこそ、差別化が必要になる。

3. 今回考えている差別化

今回のプロジェクトでも、既存サービスとの差別化はかなり意識している。

具体的な内容はまだ伏せるが、方向性としては、単に同じ機能を後追いで作るのではなく、体験そのものを変えることを考えている。

機能数で勝負するだけではない。
画面の見た目だけで勝負するわけでもない。
価格だけで勝負するわけでもない。

ユーザーが使ったときに、

こちらの方が分かりやすい
こちらの方が続けたくなる
こちらの方が楽しい
こちらの方が自分に合っている
こちらの方が参加している感覚がある
こちらの方が記録や成果が残る
こちらの方が愛着を持てる

と感じてもらえるかどうか。

ここを重視したい。

今回の対策は、既存サービスに対する単なる機能追加ではなく、体験設計、継続性、参加感、記録性、運営の見せ方などを含めた差別化にしたいと考えている。

4. ただし、差別化が本当に効くかは分からない

一方で、ここには大きな不確実性がある。

自分では「これは差別化になる」と思っていても、ユーザーがそう感じるとは限らない。

作り手が面白いと思っているポイントと、ユーザーが価値を感じるポイントはズレることがある。

自分では重要だと思っている機能が、ユーザーには伝わらないかもしれない。
自分では強みだと思っている世界観が、ユーザーには分かりにくいかもしれない。
自分では既存サービスにない魅力だと思っていても、ユーザーには違いが見えないかもしれない。

これはかなり怖い。

差別化は、作り手が宣言するだけでは成立しない。
ユーザーが実際に違いを感じて初めて成立する。

だから、現時点では、差別化の方向性はある。
対策も考えている。
しかし、それが本当に効くかは、まだ検証が必要である。

5. 差別化が伝わらないリスク

差別化で怖いのは、機能として存在していても、ユーザーに伝わらないことである。

たとえば、裏側ではかなり工夫している。
データ設計も凝っている。
継続利用の仕組みもある。
ユーザーごとの体験差も考えている。
将来的な拡張性も持たせている。

しかし、初めて触ったユーザーがそれを理解できなければ、意味が薄い。

ユーザーは最初から設計思想を読んでくれるわけではない。
長い説明を全部読んでくれるわけでもない。
裏側の複雑な仕組みを理解してくれるわけでもない。

最初の数分、最初の数画面で、何かを感じてもらう必要がある。

ここが難しい。

差別化は、仕様書の中にあるだけでは足りない。
画面、文言、導線、初回体験、結果表示、通知、演出、継続導線に落ちていなければならない。

6. 既存サービスに勝つ必要はあるのか

もう一つ考えたいのは、既存サービスに正面から勝つ必要があるのか、という点である。

既存サービスを完全に置き換える必要はないかもしれない。

既存サービスとは違う楽しみ方、違うユーザー層、違う利用シーンを狙うこともできる。

たとえば、既存サービスがすでに強い領域があるなら、そこに真正面からぶつかるのではなく、少し違う角度から入る。

既存サービスが重いなら、こちらは分かりやすさを重視する
既存サービスが競技性重視なら、こちらは継続体験を重視する
既存サービスが効率重視なら、こちらは物語性や愛着を重視する
既存サービスが上級者向けなら、こちらは初心者導線を重視する
既存サービスが単発利用なら、こちらは長期的な記録を重視する

このように、正面衝突ではなく、別の軸を作ることも重要だと思っている。

差別化とは、必ずしも「既存サービスより全部優れている」という意味ではない。

違う理由で選ばれることも差別化である。

7. 別の強みを考えられないか

現時点で考えている差別化対策はある。

ただ、それだけで十分かは分からない。

だから、さらに別の強みを考えたい。

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

7.1 継続したくなる仕組み

一度使って終わりではなく、また見たくなる、また触りたくなる仕組みを作れるか。

日々の変化、履歴、通知、ランキング、成長、記録、イベントなど、継続利用につながる要素をもっと考えたい。

7.2 ユーザーが語りたくなる要素

サービスは、使われるだけでなく、語られる必要がある。

SNSで共有したくなる。
友人に話したくなる。
ブログや動画で取り上げたくなる。
自分の成果や記録を見せたくなる。

そういう要素を作れないか。

7.3 初回体験の強さ

どれだけ奥が深くても、最初に伝わらなければ離脱される。

初回ユーザーが、すぐに「これは何か違う」と感じる導線が必要である。

最初の画面、最初の説明、最初の操作、最初の結果表示。
ここをもっと強くできないか。

7.4 運営そのものの魅力

サービスの機能だけでなく、運営の見せ方も強みになる可能性がある。

開発過程を公開する。
改善の過程を見せる。
ユーザーの声を反映する。
プレオープンから一緒に作る雰囲気を出す。

これは大手サービスにはない強みになるかもしれない。

7.5 個人開発ならではの熱量

個人開発は、規模では大手に勝てない。

しかし、熱量では勝てる可能性がある。

作り手の思い、改善の速さ、細部へのこだわり、ユーザーとの距離感。
こうしたものを強みにできないか。

8. 差別化は機能だけではない

今回、改めて考えたいのは、差別化を機能だけで考えすぎないことだ。

機能は重要である。
ただ、機能だけなら、いずれ真似される可能性がある。

差別化には、もっと複数の層がある。

差別化の層	内容
機能	何ができるか
体験	どう感じるか
導線	迷わず使えるか
継続性	また使いたくなるか
世界観	愛着を持てるか
運営	参加している感覚があるか
記録性	自分の成果や履歴が残るか
コミュニティ	他の人と関わりたくなるか
価格	支払いやすいか
信頼	安心して使えるか

既存サービスとの差別化を考えるなら、この複数の層で考える必要がある。

単に「この機能があります」だけでは弱いかもしれない。

9. 差別化はリリース前に完全証明できない

ここも重要である。

差別化が本当に効くかどうかは、リリース前には完全には分からない。

いくら考えても、最終的にはユーザーに触ってもらわなければ分からない。

だから、今後は限定公開やプレオープンを使って、差別化が伝わっているかを確認したい。

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

既存サービスとの違いを感じるか
何が面白いと感じたか
どこが分かりにくいか
また使いたいと思うか
他人に勧めたいと思うか
お金を払う価値を感じるか
最初の数分で魅力が伝わるか

このフィードバックを見て、差別化の方向性を修正する必要がある。

最初から正解を出すのではなく、反応を見ながら磨く。

これが現実的だと思っている。

10. 現時点の懸念

現時点での懸念は以下である。

懸念	内容
差別化が伝わらない	作り手の意図がユーザーに届かない可能性
既存サービスとの差が弱い	ユーザーが乗り換える理由にならない可能性
機能過多になる	差別化のために機能を増やしすぎるリスク
初回体験が弱い	奥深さがあっても最初に離脱される可能性
価格との整合性	課金する価値が伝わらない可能性
継続性不足	一度触って終わる可能性
検証不足	自分の思い込みで進めてしまう可能性
大手との差	体力・認知・開発速度で負ける可能性

これらはかなり重要なリスクである。

特に、自分だけが「これは面白い」と思っている状態は危険である。

ユーザーに伝わるか。
使い続けてもらえるか。
お金を払ってもらえるか。

そこまで見なければならない。

11. 今後考えたいこと

今後は、差別化についてさらに考えたい。

特に、以下を詰めたい。

既存サービスと比較したときの明確な違い
初回ユーザーに最初に伝えるべき強み
継続利用につながる仕組み
ユーザーが語りたくなる要素
課金したくなる理由
大手にはできない個人開発ならではの強み
プレオープンで確認すべき質問
差別化が伝わっているか測る方法
既存サービスに正面衝突しないポジショニング
今ある対策以外の別軸の強み

ここは、もう少し考えたい。

むしろ、今考えるべき重要テーマの一つだと思っている。

12. 今回の結論

既存サービスとの差別化については、今回のプロジェクトでも対策を考えている。

ただし、それがどこまで効果的かは、まだ分からない。

ここは大きな懸念であり、リスクである。

自分では強みだと思っていても、ユーザーに伝わらない可能性がある。
既存サービスとの差が十分に感じられない可能性もある。
奥深い仕組みを作っても、初回体験で伝わらなければ離脱されるかもしれない。

だから、差別化はもっと考える必要がある。

機能だけではなく、体験、継続性、初回導線、記録性、運営の見せ方、ユーザーが語りたくなる要素、個人開発ならではの熱量。

こうした別の強みをさらに探したい。

月商1000万円を目指すなら、作るだけでは足りない。
既存サービスがある中で、なぜこれを使うのか。
なぜ続けるのか。
なぜお金を払うのか。

この問いに答えられなければならない。

現時点では、答えの方向性はある。
しかし、まだ十分とは言い切れない。

だから、もう少し考える。
作りながら考える。
ユーザーに触ってもらいながら磨く。

差別化は、リリース前に一度決めて終わりではない。
サービスを育てながら、何度も見直していくものだと思っている。

第15回：AIの待ち時間に、何をするか問題

1. はじめに

月商1000万円を目指して、新規プロジェクトを進めている。

このブログでは、プロジェクトの具体的な企画内容はまだ公開しない。
ただし、開発の進め方、AI活用、費用、スケジュール、体調管理、日常生活とのバランスについては記録している。

前回は、AIに仕事をさせていると待ち時間が多くなり、その間に椅子で寝落ちしてしまうことが増えてきた、という話を書いた。

今回は、その続きとして、AIの待ち時間をどう過ごすかについて考えたい。

AIを使うと、作業はかなり進む。
ただし、AIが作業している間、人間側には待ち時間が発生する。

この待ち時間をどう使うかが、意外と重要になってきた。

2. AIに任せている間、完全に暇になるわけではない

Cursorに作業を依頼する。
ChatGPTに整理を頼む。
ビルドやテストを走らせる。
GitHubへの反映状況を確認する。

こうした作業には、どうしても待ち時間がある。

ただし、この待ち時間は完全な自由時間ではない。

数分後には結果を確認する必要がある。
エラーが出たら判断する必要がある。
Cursorが止まったら次の指示を出す必要がある。
テストが失敗したら原因を見る必要がある。

つまり、完全に離席できるほど長くはないが、ずっと画面を見続けるには少し長い。

この中途半端な時間が難しい。

3. 最近の待ち時間の過ごし方

最近は、AIの待ち時間にいろいろなものを見たり聞いたりしている。

たとえば、以下のようなものだ。

Netflix
Amazon Prime Video
radiko
三四郎のラジオ
オードリーのラジオ
ドキュメンタリー系の番組
最近だとNetflixで細木数子関連の作品も見た

こうしたコンテンツを流しながら、Cursorの作業やテスト結果を待つことがある。

特にラジオは相性がよい。

画面を見なくてもよい。
耳だけで聞ける。
作業中でも邪魔になりにくい。
少し気分転換にもなる。

三四郎やオードリーのラジオは、開発の待ち時間にちょうどよい。
真剣に見続けなくてもよく、笑えるし、少し肩の力が抜ける。

一方で、NetflixやAmazon Primeは、画面を見てしまうので、場合によっては集中を持っていかれる。

待ち時間のつもりが、気づいたら普通に見入っていることもある。

これはこれで問題である。

4. 待ち時間を全部「作業」にしようとすると疲れる

最初は、AIの待ち時間も全部有効活用しようとしていた。

Cursorが作業している間に、ChatGPTで次の指示文を作る。
ビルド待ちの間に、残課題を整理する。
テスト待ちの間に、ブログ記事を書く。
回答待ちの間に、ドキュメントを読む。

これは確かに効率は良い。

しかし、ずっとこれをやっていると疲れる。

AIが働いている間も、人間が別の作業をし続ける。
結果として、休む時間がなくなる。

AIは疲れない。
しかし、自分は疲れる。

だから、待ち時間をすべて作業で埋めるのは危険だと思うようになってきた。

待ち時間は、作業時間にもできる。
でも、休憩時間にもしてよい。

この切り替えが大事だと思っている。

5. ラジオはかなり相性が良い

待ち時間の活用として、今のところラジオはかなり相性が良い。

理由は単純で、画面を奪われないからである。

開発では、画面を見て確認する必要がある。

Cursorの差分を見る。
ブラウザで画面を見る。
テスト結果を見る。
エラー内容を見る。
Gitの状態を見る。

そのため、動画を見てしまうと、目が持っていかれる。

一方、ラジオなら耳だけで楽しめる。

作業に戻るのも簡単である。
エラーが出たらすぐ画面を見られる。
Cursorが止まったらすぐ対応できる。

三四郎やオードリーのようなラジオは、深刻になりすぎた頭をほぐす意味でもよい。

開発はどうしても真面目になりがちである。
仕様、課題、バグ、スケジュール、費用、体調、売上。
考えることが多い。

その中で、少し笑える時間があるのは大事だと思う。

6. 動画は気分転換になるが、注意も必要

NetflixやAmazon Primeも、待ち時間の気分転換にはなる。

特に、少し長めの処理や、すぐには戻らなくてよい作業のときは、動画を見るのも悪くない。

最近はNetflixで細木数子関連の作品も見た。

自分の開発とは直接関係ないが、こういうものを見ると、人生、家族、仕事、成功、失敗、人間関係などについて、何となく考えることもある。

ただし、動画には注意も必要である。

見始めると、普通に続きが気になる。
待ち時間のつもりが、開発の方が止まる。
気分転換のつもりが、集中が切れる。

だから、動画は使いどころを選びたい。

短い待ち時間には向かない。
長めの待ち時間、あるいは今日はもう確認だけでよいという時間帯ならよい。

7. PS5でゲームするのが一番の趣味だった

もともと、自分の一番の趣味はPS5でゲームをすることだった。

ゲームは本当に好きである。

仕事が終わった後にゲームをする。
休日にゲームをする。
新作を楽しみにする。
オンラインで遊ぶ。
そういう時間は、自分にとってかなり大事だった。

しかし最近は、ゲームをほとんど休止している。

理由は単純で、開発が楽しいからである。

今は、ゲームをするよりも、このプロジェクトを進める方に気持ちが向いている。

これは自分でも少し不思議である。

普通なら、仕事が終わった後はゲームで息抜きしたい。
でも今は、ChatGPTと壁打ちしたり、Cursorに指示を出したり、仕様を考えたり、ブログを書いたりする方が楽しい。

ある意味、開発そのものがゲーム化しているのかもしれない。

8. 開発が「趣味」になっている

このプロジェクトは、月商1000万円を目指している。

だから、単なる趣味ではない。
本気で収益化したい。
生活を良くしたい。
妻を喜ばせたい。
マンションのローンも払いたい。
いつかサラリーマンを辞める選択肢も持ちたい。

ただ、その一方で、今の開発はかなり趣味に近い楽しさもある。

アイデアを考える。
仕様に落とす。
AIに指示する。
画面ができる。
課題が整理される。
GitHubに積み上がる。
少しずつ形になっていく。

これは、ゲームの育成要素やシミュレーションに近い感覚もある。

自分がプレイヤーであり、プロジェクトが育成対象であり、AIが仲間であり、GitHubがセーブデータのようなものになっている。

そう考えると、開発が楽しいのも自然かもしれない。

9. ゲームをやりながら開発してもよいのか

待ち時間が多いなら、PS5でゲームをやりながら進めてもよいのではないか。

そう思うこともある。

Cursorに作業を投げる。
その間にPS5を少し進める。
結果が出たら戻って確認する。
また指示を出す。
またゲームに戻る。

理論上はできる。

ただ、今は何となくそれをしていない。

理由は、こちらに専念したい気持ちが強いからだと思う。

ゲームを始めると、どうしても意識がゲーム側に持っていかれる。
特にPS5のゲームは没入感が高い。

少しだけのつもりが、普通に1時間、2時間と遊んでしまう可能性がある。

それ自体は悪いことではない。
趣味としては最高である。

ただ、今はこのプロジェクトを前に進めたい気持ちが勝っている。

だから、ゲームは少し休止している。

10. 待ち時間の活用にも分類が必要

今後は、AIの待ち時間をもう少し分類して使いたい。

たとえば、以下のように分ける。

待ち時間	過ごし方
1〜3分	画面のまま待つ、軽くメモする
5〜10分	ラジオを聞く、次の指示を考える
10〜30分	ブログ下書き、仕様整理、軽い動画
30分以上	休憩、食事、風呂、犬猫の世話、場合によってはゲーム
夜遅い時間	無理に待たず、寝る
疲れている時	作業を切る、布団に行く

大事なのは、待ち時間を全部同じ扱いにしないことだと思う。

短い待ち時間に動画を見ると、戻りにくい。
長い待ち時間に画面をじっと見ていると、疲れる。
夜遅い待ち時間に無理して確認すると、椅子で寝落ちする。

待ち時間にも適切な過ごし方がある。

11. 休憩もプロジェクトの一部

最近、少しずつ思うようになった。

休憩もプロジェクトの一部である。

開発を進めるためには、頭が必要である。
判断力が必要である。
継続力が必要である。

疲れた状態で判断すると、ミスが増える。
眠い状態で差分を見ると、見落とす。
体調が悪いと、続かない。

だから、待ち時間にラジオを聞くことも、動画で少し気分転換することも、場合によっては必要である。

ただし、休憩がそのまま長時間の逃避になってしまうと、プロジェクトは進まない。

このバランスが難しい。

休む。
でも戻る。

これが大事である。

12. 現時点の課題

今回整理した課題は以下である。

課題	内容
AI待ち時間	Cursorやテストの待ち時間が多い
待ち時間の使い方	作業、休憩、娯楽の切り分けが必要
動画視聴	気分転換になるが、集中を持っていかれる
ラジオ活用	作業との相性が良い
PS5休止中	一番の趣味だったが、今は開発に専念気味
開発の趣味化	楽しいが、休息とのバランスが必要
寝落ち問題	待ち時間に椅子で寝てしまうリスク
体調管理	アラフィフとして無理は禁物

13. 今後の方針

今後は、待ち時間を以下のように使い分けたい。

短い待ち時間は、すぐ戻れる状態で待つ
少し長い待ち時間は、ラジオを聞く
集中が切れている時は、軽い動画で休憩する
夜遅い時間は、無理に待たず寝る
PS5は完全禁止ではなく、時間を決めて再開してもよい
ただし、今は開発優先で進める
待ち時間に次の指示文を作る時と、休む時を分ける
体調が悪い時は、開発より回復を優先する
椅子で寝そうなら、作業を切って布団に行く
開発を長く続けるために、娯楽も適度に使う

14. 今回の結論

AIを活用して開発していると、待ち時間が発生する。

その待ち時間をどう使うかは、思った以上に重要である。

最近は、Netflix、Amazon Prime、radiko、三四郎やオードリーのラジオなどを使って、待ち時間を過ごしている。
ラジオは作業との相性が良い。
動画は気分転換になるが、集中を持っていかれることもある。

もともとはPS5でゲームをするのが一番の趣味だった。
しかし今は、開発が楽しくて、ゲームはかなり休止中である。

ゲームをやりながらAIの作業を待つこともできるかもしれない。
ただ、今は何となく、このプロジェクトに専念したい。

それだけ、この開発が面白い。

月商1000万円を目指す道のりは長い。
だからこそ、作業時間だけでなく、待ち時間、休憩時間、娯楽時間も含めて、うまく付き合っていく必要がある。

AIは働いてくれる。
でも、自分の集中力と体力は有限である。

待ち時間を活用する。
休む時は休む。
戻る時は戻る。

このバランスを作りながら、少しずつ前に進めていきたい。

第14回：AIに仕事をさせているのに、待ち時間で寝落ちしてしまう問題

1. はじめに

月商1000万円を目指して、新規プロジェクトを進めている。

このブログでは、プロジェクトの具体的な企画内容はまだ公開しない。
ただし、開発の進め方、AI活用、費用、スケジュール、課題、体制、そして現実的な悩みについては記録していく。

今回は、少し泥臭い話を書く。

AIに仕事をさせていると、意外と待ち時間が多い。

ChatGPTで方針を整理し、Cursorに実装指示を出し、Gensparkでデザインや資料を検討する。
一見すると、AIによってどんどん作業が進んでいるように見える。

実際、進んではいる。

ただ、その裏側には、AIの処理を待つ時間、Cursorの作業完了を待つ時間、ビルドやテストを待つ時間、結果を確認する時間がある。

最近は、その待ち時間の間に、椅子に座ったまま寝てしまうことが増えてきた。

これは少しまずいかもしれない。

2. AIに任せても、人間の待機時間はなくならない

AIを使えば、人間がすべて手作業するよりは明らかに速い。

自分一人では何時間もかかるような作業を、Cursorがかなりの速度で進めてくれる。
ChatGPTも、仕様整理や指示文作成、課題の棚卸しをかなり助けてくれる。

ただし、AIを使っているからといって、人間の待ち時間がゼロになるわけではない。

実際には、以下のような待ち時間が発生する。

Cursorが実装している間の待ち時間
コード生成が終わるまでの待ち時間
lint / build / test の完了待ち
E2Eテストの実行待ち
差分確認の待ち時間
commit / push の結果確認
AIの回答生成待ち
次の指示を考えるまでの待ち時間

AIに仕事をさせているのに、こちらはただ待っている時間がある。

この時間をうまく使えればよい。
次の指示文を考えたり、別の課題を整理したり、ブログ記事を書いたりできる。

ただ、疲れていると、そこで意識が飛ぶ。

3. 連続的にCursor指示を入れて、止まらないようにはしている

最近は、Cursorに対して、なるべく連続的に作業指示を入れるようにしている。

一つの作業が終わったら、次に何をやるか。
詰まった場合は、どの作業に切り替えるか。
ドキュメント更新だけで終わらず、実装に進めるか。
作業後には、進捗率や残課題を報告してもらうか。

こうした指示をあらかじめ入れて、Cursorができるだけ止まらないようにしている。

特に意識しているのは、以下である。

作業範囲を明確にする
完了条件を明確にする
詰まったら別タスクに移る
実装可能なものを優先する
ドキュメント更新だけで終わらせない
最後に次の作業候補を出してもらう
進捗率と残り見通しを報告してもらう

これはかなり効果がある。

AIに対しても、プロジェクトマネジメントが必要である。
人間のメンバーではなくても、役割、作業範囲、完了条件、報告内容を決めないと、作業は止まりやすい。

4. それでも、たまに止まる

ただし、どれだけ指示を工夫しても、AIの作業はたまに止まる。

理由はいろいろある。

エラーで止まる
判断が必要になる
仕様が曖昧になる
テストが失敗する
ファイルの影響範囲が大きくなる
コマンド実行待ちになる
こちらの確認待ちになる
次の指示が不足している

この「たまに止まる」が地味に効いてくる。

人間側としては、AIが止まっていないかを見ておく必要がある。
止まったら、確認して、判断して、次の指示を出す必要がある。

つまり、AIに仕事をさせている間も、完全に放置できるわけではない。

この状態は、少しだけ運用監視に近い。

Cursorが実装担当だとすると、自分はプロジェクトマネージャーであり、レビュー担当であり、判断者であり、運用監視者でもある。

AIを使っているから楽になる部分は大きい。
しかし、AIを動かし続けるための管理負荷もある。

5. 待ち時間に寝てしまう問題

最近、一番気になっているのは、待ち時間に寝てしまうことだ。

Cursorに作業を依頼する。
少し待つ。
結果を見ようと思う。
気づいたら椅子に座ったまま寝ている。

これが増えてきた。

正直、あまり良くない。

単純に疲れているのだと思う。

普段はサラリーマンとして働いている。
そのうえで、夜や休日にこのプロジェクトを進めている。
さらに、通勤中、犬の散歩中、室内サイクルマシンでのトレーニング中にもChatGPTと壁打ちしている。

つまり、頭のどこかがずっとプロジェクトに向いている。

楽しい。
前に進んでいる。
月商1000万円を目指したい。

それは本当である。

ただし、体は正直である。

6. アラフィフとして、体調面は軽視できない

自分はアラフィフである。

若い頃のように、多少寝なくても何とかなる、という年齢ではない。

睡眠不足は翌日に残る。
疲労も抜けにくい。
集中力も落ちる。
肩や腰にもくる。
無理をすれば、仕事にも家庭にも影響する。

個人開発で一番怖いのは、途中で燃え尽きることだと思う。

短期的に無理をして、数日だけ頑張ることはできる。
しかし、このプロジェクトは月商1000万円を目指している。

それは、数日で終わる挑戦ではない。

一人用確認版、限定公開、初期サービスイン、初売上、月商10万円、100万円、300万円、1000万円。
長い道のりである。

長い道のりだからこそ、体調を壊す進め方は危険である。

7. 「AIがあるから無理できる」は危険

AIを使うと、できることが増える。

一人でも、かなり大きなプロジェクトを進められる。
ChatGPTが整理してくれる。
Cursorが実装してくれる。
Gensparkがデザイン案を出してくれる。
GitHubで状況も追える。

だから、つい思ってしまう。

「これなら、もっと進められる」
「もう少しだけやろう」
「待っている間に次の指示を作ろう」
「寝る前にもう一つだけ投げよう」

この積み重ねが危ない。

AIがあるからこそ、人間側が止まれなくなる可能性がある。

昔なら、一人でできる作業量には自然な限界があった。
しかし今は、AIに任せれば深夜でも作業が進む。

これは強力だが、危険でもある。

AIは疲れない。
しかし、自分は疲れる。

ここを忘れてはいけない。

8. 今後は「待ち時間の使い方」も管理する

今後は、AIの待ち時間をどう使うかも管理したい。

ただ待つのではなく、待ち時間を以下のように分類する。

待ち時間の種類	使い方
短い待ち時間	差分確認、次の指示メモ、軽い整理
長い待ち時間	ブログ下書き、仕様整理、休憩
ビルド・テスト待ち	結果確認に備える、無理なら休む
夜遅い待ち時間	無理に待たず、翌朝確認する
疲れている時	作業を止めて寝る

特に重要なのは、夜遅い時間である。

深夜にCursorの結果を待ち続けるのは危ない。
眠い状態で差分確認しても、品質確認の精度は落ちる。

むしろ、夜は指示だけ出して、結果確認は翌朝に回す方がよい場合もある。

9. 連続稼働より、継続稼働が大事

月商1000万円を目指すなら、短期集中も必要である。

ただし、それ以上に大事なのは、継続することだ。

一晩で無理をして、その後数日動けなくなるより、毎日少しずつでも進めた方がよい。

今後は、以下を意識したい。

深夜の無理な確認を減らす
椅子で寝落ちしそうなら作業を切る
Cursorに投げたら翌朝確認でもよい
通勤中や散歩中は壁打ち中心にする
実装確認は集中できる時間にやる
週単位で稼働量を見る
休む日も計画に入れる

これは、甘えではない。

プロジェクトを長く続けるための戦略である。

10. 体調管理もプロジェクトマネジメントの一部

PMP的に考えても、これは資源管理やリスク管理の話である。

自分自身は、このプロジェクトにおける最大のリソースである。

ChatGPTもある。
Cursorもある。
Gensparkもある。
追加PCもある。
GitHubもある。

しかし、最終判断をするのは自分である。
方向性を決めるのも自分である。
何を作るか、何を捨てるか、いつ公開するかを決めるのも自分である。

その自分が倒れたら、プロジェクトは止まる。

だから、体調管理は単なる私生活の話ではない。
プロジェクトマネジメント上の重要課題である。

特にアラフィフで、本業があり、妻がいて、犬と猫もいる。
無理を前提にした計画は破綻しやすい。

11. 今後の対策

現時点で考えている対策は以下である。

11.1 夜の作業終了ラインを決める

まず、夜の作業終了ラインを決めたい。

たとえば、一定時刻を過ぎたら新しい実装指示は出さない。
出すとしても、確認は翌日に回す。

深夜に判断が必要な作業をしない。

これはかなり重要だと思う。

11.2 Cursorへの指示は「翌朝確認前提」にする

夜にCursorへ指示を出す場合は、最初から翌朝確認前提にする。

つまり、

作業完了後に結果を整理する
実施内容を箇条書きで報告する
変更ファイルを示す
テスト結果を示す
残課題を示す
次に確認すべき点を示す

ところまで依頼しておく。

そうすれば、翌朝に状況を把握しやすい。

11.3 待ち時間は休憩にしてよいと決める

AIが作業している待ち時間に、必ず別作業をしようとすると疲れる。

待ち時間は休憩にしてもよい。

むしろ、AIが働いている間に人間が休む、という考え方も必要である。

AIに仕事を任せているのだから、その間に自分が少し休むのは合理的である。

11.4 椅子で寝る前に布団へ行く

これは単純だが大事である。

椅子で寝るくらいなら、作業を切って布団へ行く。

椅子で寝ても疲れは取れない。
体も痛くなる。
翌日のパフォーマンスも落ちる。

眠いなら寝る。

これは、今後かなり意識したい。

11.5 週単位で稼働と体調を振り返る

毎日厳密に管理する必要はないが、週単位では振り返りたい。

何時間くらい作業したか
何日寝落ちしたか
体調はどうだったか
進捗はあったか
無理した割に進まなかった作業はないか
AI待ち時間をうまく使えたか
休むべき日を休めたか

これを見れば、無理な進め方に気づきやすい。

12. 現時点の課題

今回整理した課題は以下である。

課題	内容
AI待ち時間	Cursorやテストの待ち時間が意外と多い
作業停止	連続指示していても、たまにAI作業が止まる
監視負荷	AIが止まっていないか人間が見る必要がある
寝落ち	椅子に座ったまま寝てしまうことが増えている
体調不安	アラフィフとして睡眠不足や疲労が心配
夜間判断	眠い状態で確認・判断すると品質が落ちる
継続性	短期的な無理より、長く続ける体制が必要

13. 今回の結論

AIを活用すると、開発はかなり進む。

ChatGPTで整理し、Cursorで実装し、Gensparkでデザインを考え、GitHubで履歴を管理する。
この流れは非常に強力である。

ただし、AIに仕事をさせていると、待ち時間も発生する。
そして、その待ち時間に椅子で寝落ちすることが増えてきた。

これは、少し危険信号だと思っている。

自分はアラフィフである。
本業もある。
妻もいる。
犬と猫もいる。
マンションのローンもある。

月商1000万円を目指すからこそ、無理をしすぎてはいけない。

AIは疲れない。
でも、自分は疲れる。

この当たり前のことを忘れないようにしたい。

今後は、AIを止めない工夫だけでなく、
自分を壊さない工夫も必要である。

待ち時間をどう使うか。
どこで作業を切るか。
いつ確認を翌日に回すか。
どこからは寝るか。

これも、プロジェクトマネジメントの一部である。

月商1000万円までの道のりは長い。
だからこそ、短距離走ではなく、長距離走として進めたい。

無理はする。
でも、壊れるほどはしない。

AIを働かせながら、自分もちゃんと休む。
そのバランスを作ることが、今後の大きな課題である。

登録: 投稿 (Atom)