第23回：Cursor Ultraに月額200ドルを払った

1. はじめに

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

ここまで、ChatGPT、Cursor、Genspark、新PC、PlaywrightによるE2E、GitHub連携などを使いながら開発を進めてきた。

そして今回、ついに Cursor Ultra を契約した。

金額は、月額200ドル。

正直、軽い金額ではない。

個人開発で、まだ売上が立っていない段階で、月額200ドルの開発ツールに課金する。
日本円にすると為替次第では毎月数万円になる。

それでも、今の開発状況を考えると、ここで開発速度を落とす方がリスクだと判断した。

---

2. Cursor Ultraの支払い内容

今回契約したのは、Cursor Ultra。

支払い画面では、以下のように表示されていた。

項目	内容
プラン	Cursor Ultra
月額	$200.00 / 月
請求	1か月ごと
小計	$200.00
税金	$0.00
今日期日の合計額	$200.00

年次払いにすれば月額換算で $160/月 になり、年間 $480 節約できる表示もあった。
ただし、今回は月額契約にした。

理由は、まだ効果測定の段階だからである。

いきなり年額で固定するのではなく、まずは1か月使って、どれだけ開発速度が上がるかを見る。

---

3. なぜ払ったのか

一番大きい理由は、現在のCursor利用量が限界に近かったからである。

これまで使っていたPro+では、すでに使用量がかなり高くなっていた。

開発では、Cursorを単なる補助ツールではなく、かなり本格的な実装担当として使っている。

具体的には、以下のような作業を任せている。

• 実装

• 既存コード調査

• 不具合修正

• UI改善

• E2Eテスト追加

• 回帰テスト更新

• ドキュメント更新

• README更新

• lint / format / build確認

• commit / push前の整理

• 作業報告

ここまで任せていると、使用量が増えるのは当然である。

そして今は、一人用確認版に近づいている重要なタイミングである。
ここでCursorの制限に引っかかって作業が止まるのは避けたい。

だから、月額200ドルを払ってでも、開発速度を維持する判断をした。

---

4. これは贅沢ではなく、開発加速投資

月額200ドルという数字だけ見ると高い。

ただ、自分の中ではこれは贅沢ではなく、開発加速投資である。

もし人に実装を依頼すれば、数万円どころでは済まない。
1画面、1機能、1修正だけでも外注すればかなりの費用がかかる。

それに対して、Cursor Ultraによって、

• 実装待ちが減る

• 制限を気にせず作業できる

• E2Eまで含めて依頼しやすくなる

• 1セッションあたりの作業量が増える

• 一人用確認版への到達が早まる

のであれば、月額200ドルは投資として成立する可能性がある。

もちろん、払っただけで成功するわけではない。

Cursorに何を依頼するか。
どこまで任せるか。
どう確認するか。
どの作業を優先するか。

そこを間違えれば、200ドルを払っても無駄になる。

---

5. 今の課題は、機能追加より品質改善

ちょうど最近、一人用確認版を確認して、品質面にかなり不安を感じた。

デザイン品質が低い。
機能品質も弱い。
画面のつながりもまだ不十分。
E2Eが通っていても、ユーザー体験としてはまだ見せられる状態ではない。

この状況で必要なのは、単純な機能追加ではない。

必要なのは、品質改善である。

Cursor Ultraを契約したからといって、むやみに機能を増やしてはいけない。

むしろ、今後は以下に使うべきだと思っている。

• 主要画面のUI改善

• 初回導線の整理

• 空データ・エラー表示の統一

• スマホ表示の改善

• 一人用通し確認の障害除去

• E2Eの品質向上

• 残課題のP0整理

• 既存実装の見直し

• 見せ場となる画面の改善

Ultraの価値は、作業量を増やすことだけではない。

人に見せられる品質へ近づけることに使わなければ意味がない。

---

6. 費用整理上の影響

これで、現時点の開発費用はさらに増えた。

確定している支払いとしては、以下になる。

項目	金額	状態
BOSGAME P3 PLUS	87,900円	購入済み
ChatGPT Plus	3,000円/月	契約中
Genspark Plus	$27.49/月	契約中
Cursor Pro+	$60/月	利用済み
Cursor Ultra	$200/月	契約済み

Cursorについては、これまで $20 → $60 → $200 という流れで上げてきた。
実際の過去請求については明細確認が必要だが、少なくとも今回から Cursor Ultra $200/月 は実支払いとして発生する。

これはかなり大きい。

月商1000万円を目指すとはいえ、まだ売上がない段階での固定費増加である。

だからこそ、効果測定が必要になる。

---

7. 1か月で何を見るか

今回のCursor Ultra契約は、まず1か月の開発加速期間として見る。

この1か月で確認したいのは、以下である。

確認項目	見たいこと
一人用確認版	到達時期が早まったか
品質改善	デザイン・機能品質が上がったか
実装量	1セッションあたりの作業量が増えたか
E2E	回帰テストや主要導線の確認が増えたか
待ち時間	制限による停止が減ったか
精神面	制限を気にせず開発できたか
費用対効果	月額200ドルに見合う成果があったか

特に重要なのは、一人用確認版の品質である。

単に「たくさん実装した」では足りない。

実際に触って、
「これなら次の段階に進める」
と思える状態に近づいたかどうかを見る。

---

8. 年額ではなく月額にした理由

支払い画面では、年次払いにすれば $480 節約できる表示があった。

月額換算では $160/月。

かなり魅力的ではある。

ただ、今回は月額にした。

理由は、まだこの投資がどれだけ効くか分からないからである。

Cursor Ultraが本当に開発速度を上げるのか。
一人用確認版の品質改善に直結するのか。
自分の運用スタイルに合うのか。
月額200ドルを払う価値があるのか。

これは1か月使ってみないと分からない。

効果が明確なら、継続する。
必要であれば年額も検討する。
効果が薄ければ、戻す。

まずは実験である。

---

9. 今回の結論

Cursor Ultraに、月額200ドルを払った。

これは、個人開発としてはかなり大きな判断である。

ただ、今は一人用確認版が近づいている重要な時期であり、同時に品質の低さにも不安が出てきている。

ここで開発速度を落とすより、1か月だけでも開発加速に投資する方がよいと判断した。

ただし、払っただけでは意味がない。

Cursor Ultraは、魔法ではない。
使い方を間違えれば、ただ固定費が増えるだけである。

この1か月でやるべきことは明確である。

• 機能を増やしすぎない

• 品質改善に集中する

• 一人用確認版の通し体験を整える

• 主要画面を人に見せられる水準へ近づける

• E2Eと人手確認を組み合わせる

• 残課題をP0中心に整理する

• 5月中の一人用確認版到達を現実にする

月額200ドルを払った以上、成果を出す。

これは支出ではある。
しかし、月商1000万円へ向けた開発投資でもある。

ここから1か月、Cursor Ultraを使って、どこまで品質を引き上げられるか。

かなり重要な勝負期間に入った。

第22回：一人用確認版を見て、正直かなり不安になった

1. はじめに

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

ここまで、AI活用、開発用PCの導入、Cursorによる実装、PlaywrightによるE2Eテスト、ドキュメント整備、クラウドファンディング構想などについて書いてきた。

そして最近、一人用確認版にかなり近づいてきたと感じていた。

進捗率としても、だいたい50%前後まで来ているという見立てをしていた。
E2Eテストも増えてきた。
新PCによって開発効率も上がってきた。
実装、テスト、commit、pushの流れも回るようになってきた。

しかし、実際に一人用確認版として触ってみると、正直かなり厳しかった。

デザイン品質が低い。
機能品質も低い。
画面のつながりも弱い。
使っていて楽しい以前に、触っていて不安になる部分が多い。

これは、かなり心配になってきた。

---

2. 「動く」と「使える」はまったく違う

今回、改めて痛感したのは、動くことと、使えることは違うということだ。

E2Eテストが通る。
buildが通る。
lintが通る。
画面が表示される。
ボタンを押せる。
データが保存される。

これらはもちろん重要である。

しかし、それだけではサービスとして成立しない。

実際に触ってみると、

• 何をすればいいか分かりにくい

• 画面が見づらい

• 情報の優先順位が分からない

• デザインに統一感がない

• 操作していて気持ちよくない

• 画面ごとの品質差が大きい

• 一人用の体験としてつながっていない

• そもそも楽しいと感じる前に不安になる

という問題が見えてきた。

これはかなり大きい。

コード上は動いていても、ユーザー体験としてはまだ弱い。
むしろ弱いどころか、このままでは人に見せるのが怖いレベルかもしれない。

---

3. デザイン品質への不安

特に気になったのは、デザイン品質である。

今回のプロジェクトでは、世界観や体験をかなり重視している。
ただ機能を並べるだけではなく、ユーザーがその世界に入り込み、継続して触りたくなるようなサービスにしたい。

しかし、現時点の一人用確認版を見ると、そこまで到達していない。

画面として最低限表示されているだけで、体験としての魅力が弱い。
UIとしても、情報設計としても、見せ方としても、かなり改善が必要だと感じた。

特に問題なのは、デザインの荒さが、そのままサービスの信頼感を下げてしまうことである。

ユーザーは中身のロジックまでは見ない。
最初に見るのは画面である。

画面が雑だと、
「本当にこのサービスは大丈夫なのか」
「ちゃんと作られているのか」
「続けても意味があるのか」
と感じてしまう。

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

---

4. 機能品質への不安

デザインだけでなく、機能品質にも不安がある。

個別には実装されている機能がある。
テストが通っている部分もある。
ドキュメント上では仕様も整理されている。

しかし、実際に一人用として触ると、機能が自然につながっていない。

たとえば、一般論として、確認版では以下が重要になる。

• 最初に何をすればよいか分かる

• 次の操作が自然に提示される

• 画面遷移に迷わない

• データがない時も意味が分かる

• エラー時も不安にならない

• 主要な体験が一連の流れになっている

• 管理者操作なしでも最低限進行できる

• 結果や履歴が納得感を持って表示される

ここが弱いと、一人用確認版としても成立しにくい。

今の状態は、部品は増えてきたが、体験としてまだつながりきっていない印象がある。

これは、単なるバグ修正だけでは解決しない。
画面導線、UX、機能の優先順位、初回体験を見直す必要がある。

---

5. E2Eテストがあっても安心できない理由

PlaywrightによるE2Eテストはすでに使っている。
これは大きな前進である。

ただし、今回の確認で分かったのは、E2Eテストが通っても、サービス品質が高いとは限らないということだ。

E2Eテストは、以下の確認には強い。

• 画面が落ちない

• ボタンが押せる

• 遷移できる

• 要素が表示される

• データの基本的な保存・表示ができる

• 空データやエラー状態が最低限表示される

しかし、以下はE2Eでは判断しにくい。

• 画面が魅力的か

• 初回ユーザーが迷わないか

• 触っていて楽しいか

• 世界観が伝わるか

• 説明が自然か

• 情報量が適切か

• 継続したくなるか

• 人に見せたい品質か

つまり、E2Eは必要だが、それだけでは足りない。

今回の問題は、テスト不足だけではなく、UX品質・デザイン品質・体験品質の不足である。

---

6. 進捗率の見方を修正する必要がある

これまで、一人用確認版への到達度を48〜55%程度と見ていた。

しかし、実際に触った印象を踏まえると、この数字は少し楽観的だったかもしれない。

実装量としては50%前後でも、体験品質としてはもっと低い可能性がある。

ここは、見方を分ける必要がある。

観点	現在地の見方
実装部品の量	ある程度進んでいる
E2E・回帰確認	積み上がってきている
ドキュメント整備	かなり進んでいる
一人用体験のつながり	まだ弱い
デザイン品質	かなり改善が必要
人に見せられる品質	まだ不安
限定公開の準備	まだ早い

つまり、単純に「何%できた」と言うのが難しくなってきた。

実装進捗と体験品質は別物である。

ここを分けて見ないと、判断を誤る。

---

7. クラウドファンディングどころではない可能性

最近、クラウドファンディングの活用も考え始めていた。

一人用確認版、レトロ風の演出、初期ファン集め、テスター募集。
うまく使えば、かなり意味があると考えていた。

しかし、現時点の品質を見ると、クラウドファンディングを急ぐのは危険かもしれない。

クラウドファンディングでは、支援者に見せる画面や動画が必要になる。
「これは面白そう」と思ってもらえる見せ場が必要になる。
少なくとも、信頼できる開発状況に見える必要がある。

今のデザイン品質・機能品質のまま出すと、逆に不安を与える可能性がある。

つまり、クラウドファンディングはまだ可能性として残すが、タイミングは慎重に見直すべきである。

まずは、一人用確認版の品質を引き上げる。
その後に、見せられる画面と動画を作る。
クラウドファンディングはその後でよい。

---

8. 今の課題は「機能追加」ではなく「品質改善」

ここで重要なのは、次に何をするかである。

今の状態で、さらに新機能を足しても、問題は解決しない可能性が高い。

むしろ、画面や導線がさらに複雑になり、品質が悪化するかもしれない。

今必要なのは、機能追加よりも品質改善である。

特に優先すべきは以下だと思う。

1. 初回導線の整理

2. 主要画面のデザイン改善

3. 一人用での通し導線の整理

4. 空データ・エラー表示の統一

5. 操作後のフィードバック改善

6. スマホ表示の確認

7. 画面ごとの情報優先度の整理

8. 見せ場となる画面の品質向上

9. E2Eでは拾えない人手確認項目の追加

10. 一人用確認版の合格基準の見直し

これは、かなり重要な方針転換である。

「作る」から「整える」へ。
「機能を増やす」から「体験を成立させる」へ。

ここに切り替えないと、人に見せられる状態にはならない。

---

9. AI開発の弱点も見えてきた

今回の品質問題は、AI開発の弱点でもあると思っている。

Cursorはかなり実装してくれる。
ChatGPTは仕様や指示文を作ってくれる。
E2Eテストも追加できる。
ドキュメントも整備できる。

しかし、AIに任せると、部品単位では進む一方で、全体体験が弱くなることがある。

画面はある。
機能もある。
テストもある。
でも、実際に触ると微妙。

これは、AIに任せる範囲と、人間が見るべき範囲を改めて考える必要があるということだ。

AIには実装を任せられる。
しかし、体験品質の最終判断は人間がしなければならない。

特に、今回のようなサービスでは、ユーザーがどう感じるかが重要である。

そこは、AI任せにしてはいけない。

---

10. 不安になったことは悪いことではない

一人用確認版を見て不安になった。

これは正直、しんどい。

ここまでかなり時間もお金も使っている。
PCも買った。
Cursorにも課金している。
ChatGPTも使っている。
Gensparkも使っている。
ドキュメントもかなり作っている。
E2Eも増やしている。

それでも、実際に触った品質が低いと、かなり不安になる。

しかし、不安になったこと自体は悪いことではない。

むしろ、この段階で気づけてよかった。

もしこの品質のまま限定公開やクラウドファンディングに進んでいたら、もっと危なかった。

今ならまだ直せる。
今ならまだ方向転換できる。
今ならまだ、一人用確認版の品質基準を見直せる。

これは痛いが、必要な気づきだと思う。

---

11. 今後の対応方針

現時点での対応方針は以下である。

11.1 一人用確認版の合格基準を見直す

単に画面が動くことを合格にしない。

以下も見る。

• 初回ユーザーとして迷わないか

• 画面が最低限見やすいか

• 主要導線が自然につながっているか

• エラーや空データ時に不安にならないか

• スマホで最低限使えるか

• 触っていて続きを見たいと思えるか

11.2 デザイン改善をP0に近づける

これまでデザイン改善は後回しにしがちだった。

しかし、現時点の品質を見ると、主要画面のデザイン改善はP0に近い。

少なくとも、一人用確認版で触る主要画面については、最低限の見栄えと情報設計が必要である。

11.3 通しプレイ観点で確認する

画面単位ではなく、ユーザー体験単位で確認する。

• 開始する

• 説明を見る

• 主要操作を行う

• 結果を見る

• 次に何をするか分かる

• 履歴や状態を確認する

この流れで見る。

11.4 機能追加を一時的に絞る

新機能を増やす前に、既存部分の品質を上げる。

特に、人に見せる可能性がある画面、クラウドファンディング用の見せ場になる画面は優先的に整える。

11.5 AIへの指示を品質改善型に変える

Cursorへの指示も、単なる実装追加ではなく、品質改善に寄せる。

• UI/UX改善

• 画面導線整理

• 空データ表示統一

• スマホ表示改善

• 操作フィードバック追加

• 一人用通し確認の障害除去

こうした指示に切り替える必要がある。

---

12. 現時点の結論

一人用確認版を確認して、正直かなり不安になった。

デザイン品質が低い。
機能品質も低い。
画面のつながりも弱い。
サービスとしての魅力がまだ伝わらない。

これは厳しい現実である。

ただし、ここで気づけたのは大きい。

今の段階で必要なのは、さらに機能を増やすことではない。
一人用確認版として、人間が触って「最低限成立している」と思える品質まで引き上げることである。

E2Eが通っているから安心、ではない。
buildが通っているから完成、でもない。
ドキュメントがあるから品質が高い、でもない。

実際に触って、分かりやすく、破綻せず、少しでも面白さが伝わること。
そこまで持っていく必要がある。

月商1000万円を目指すなら、ここは避けて通れない。

今回の確認は、かなり苦い。
しかし、必要な現実確認だった。

ここからは、機能追加ではなく、品質改善に本気で向き合う。

一人用確認版は近づいていると思っていた。
しかし、本当に必要なのは、単に「一人で動かせる状態」ではなく、
一人で触って、これなら次に進めると思える状態である。

そこまで引き上げる。
ここが、次の大きな課題である。

第21回：クラウドファンディングを活用できないか考え始めた

1. はじめに

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

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

開発は少しずつ進んでいる。
一方で、費用も確実に増えている。

開発用PCを購入した。
ChatGPT Plusを使っている。
Cursorも上位プランへ上げた。
Gensparkも利用している。
今後は、サーバー費用、素材制作費、UI改善費、テスト環境費、外部向けページ制作費なども必要になる可能性がある。

そこで、少し考え始めたことがある。

クラウドファンディングを活用できないか。

これは単なる資金調達の話ではない。

初期ユーザー、応援者、テスター、発信協力者を集める手段として、クラウドファンディングを使えないかという話である。

---

2. クラウドファンディングは選択肢になるのか

結論から言うと、クラウドファンディングは検討する価値があると思っている。

ただし、やるなら慎重に設計する必要がある。

特に重要なのは、寄付型や投資型ではなく、購入型に寄せることである。

支援してくれた人に対して、金銭的なリターンを返すのではなく、先行利用権、支援者向け特典、クレジット掲載、限定レポート、開発状況の共有などを提供する形が現実的だと考えている。

逆に、以下のような打ち出し方はしない。

• 売上を分配する

• 利益を分配する

• 配当を出す

• 元本を返す

• 投資家として参加してもらう

• 将来の収益を約束する

このプロジェクトは、あくまでWebサービス開発である。
クラウドファンディングを使う場合も、支援者には金銭的リターンではなく、サービス利用や開発参加感に近いリターンを提供する形にしたい。

---

3. 目的はお金だけではない

クラウドファンディングというと、まず資金調達をイメージする。

もちろん、資金面の意味は大きい。

たとえば、以下のような費用に充てられる可能性がある。

• UI改善

• ビジュアル素材制作

• 外部向けページ制作

• 紹介動画制作

• テスト環境整備

• サーバー・DB・ドメイン関連費用

• 説明資料の整備

• 初期利用者向けサポート体制

ただ、それ以上に重要なのは、初期ファンを集めることだと思っている。

支援してくれる人は、単なる利用者ではない。
開発段階から応援してくれる人である。

まだ完成していない段階で関心を持ってくれる人。
先行して触ってくれる人。
分かりにくい点を教えてくれる人。
改善案をくれる人。
周囲に紹介してくれる人。

そういう人たちと早い段階で出会えることは、資金以上に価値があるかもしれない。

クラウドファンディングは、資金調達であり、需要検証であり、初期コミュニティ作りでもある。

---

4. いきなり大きく狙いすぎない

もしクラウドファンディングを行うなら、最初から大きく狙いすぎない方がよいと思っている。

いきなり数百万円規模を目指すと、準備も重くなる。
リターン設計も大変になる。
達成できなかった場合の見え方も悪い。
支援後の対応負荷も大きくなる。

そのため、最初は小さく試すのが現実的だと思う。

たとえば、第1弾は 30万〜100万円程度 の小規模な挑戦にする。

目的は、巨大な資金調達ではない。

• コンセプトが伝わるか

• 支援してくれる人がいるか

• どのリターンに反応があるか

• 外部向け説明が分かりやすいか

• 先行利用者が集まるか

• SNSで反応があるか

これを確認する。

第1弾で反応があれば、第2弾として、より大きな開発費・改善費・運用費を集めることも考えられる。

まずは、小さく出して反応を見る。
これが現実的だと思っている。

---

5. 第1弾の目標金額イメージ

第1弾をやるなら、目標金額は 50万円前後 が現実的ではないかと考えている。

まだ仮ではあるが、使い道のイメージは以下である。

用途	金額目安
ビジュアル素材・UI素材制作	15万円
サーバー・DB・ドメイン・検証費	5万円
自動テスト・開発環境強化	5万円
初期確認版のUI改善	10万円
外部向けページ・説明画像・紹介動画制作	10万円
手数料・予備費	5万円

もちろん、クラウドファンディングでは手数料がかかる。
集まった金額がそのまま使えるわけではない。
また、税金やリターン提供にかかる費用も考える必要がある。

そのため、50万円を集めたとしても、実際に自由に使える金額はそれより少なくなる。

ここは、実施前に必ず最新の手数料や規約を確認する。

---

6. リターン案

リターンは、慎重に設計する必要がある。

現時点で考えられる案は以下である。

支援額	リターン案
1,000円	開発応援、支援者限定レポート
3,000円	先行利用権、支援者向け特典
5,000円	初期確認版の先行利用枠、クレジット掲載
10,000円	支援者向け特典、プロフィール装飾、開発レポート
30,000円	サービス内名称・記念掲載枠の候補採用権
50,000円	コンテンツ名称候補の優先採用、支援者紹介枠
100,000円	創設支援者枠、記念ページ掲載、特別クレジット

ここで重要なのは、金銭的なリターンにしないことである。

支援に対して、売上分配、利益分配、配当、元本返還などは行わない。
また、換金性を想起させるリターンも避ける。

リターンはあくまで、先行利用、記念掲載、支援者向け特典、開発レポート、クレジット掲載などに寄せる。

---

7. 外部向けの訴求軸

クラウドファンディングで重要なのは、単に「Webサービスを作っています」と言うことではない。

なぜ作るのか。
何が新しいのか。
なぜ支援してほしいのか。
支援者は何に参加できるのか。

ここを伝える必要がある。

現時点で考えている訴求軸は、以下である。

昔、自分が本当に楽しいと思った体験を、現代のWebサービスとして再構築したい。
単なる便利ツールではなく、ユーザーが継続して関わり、自分なりの記録や体験を積み重ねられるサービスを作りたい。
AIを活用しながら、独力でどこまで大きなサービスを作れるのかに挑戦している。
その最初の支援者、先行利用者、開発過程を一緒に見守ってくれる人を集めたい。

これは、ただの資金募集ではない。

一緒に初期サービスを育ててくれる人を集めるという打ち出し方がよいと思っている。

---

8. 必ず明記すべき注意事項

クラウドファンディングを行うなら、誤解を避けるための注意事項はかなり重要である。

公開ページには、少なくとも以下のような説明を入れる必要がある。

本プロジェクトは、実在の人物・団体・サービス・取引を対象にしたものではありません。
サービス内で扱う内容は、すべて独自に設計されたコンテンツです。

支援に対して、売上分配、利益分配、配当、元本返還などの金銭的リターンは行いません。

また、サービス内の表示・特典・ポイント等は、現金、暗号資産、電子マネー等へ換金できません。

リターンは、先行利用権、支援者向け特典、クレジット掲載、開発レポート等の購入型リターンとして設計します。

本サービスは現在開発中であり、仕様、提供時期、画面構成、機能内容は変更される可能性があります。

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

支援者に期待を持ってもらうことは大事だが、過度な期待を持たせてはいけない。

できること。
まだできないこと。
変更される可能性があること。
金銭的リターンではないこと。

ここは明確に書く必要がある。

---

9. いつ実施するべきか

クラウドファンディングは、今すぐ公開するより、もう少し見せられる状態になってからの方がよい。

現時点では、まだ品質に不安がある。

一人用の確認では、デザイン品質や機能品質に課題が見えている。
この状態のまま外に出すと、支援どころか不安を与えてしまう可能性がある。

そのため、クラウドファンディングを実施するなら、最低限以下が必要だと思っている。

• 初期確認版の主要導線が通る

• 外部向けに見せられる画面がある

• 何が面白いのか説明できる

• 30〜90秒程度の紹介動画がある

• 支援金の使い道が明確である

• リターン内容が現実的である

• 提供時期とリスクを説明できる

• できること／まだできないことを明記できる

つまり、文章だけで出すのではなく、一定の画面・動画・説明資料が必要である。

---

10. 想定スケジュール

現時点で考えるなら、以下のような流れが現実的だと思っている。

時期	内容
2026年5月前半	初期確認版の主要導線と見せ場を整える
2026年5月中旬	クラウドファンディング本文・リターン・FAQ案を作る
2026年5月下旬	外部向けページ・説明画像・紹介動画を準備する
2026年6月	小規模クラウドファンディングを検討する
2026年6月以降	支援者向け先行利用・限定レポートを開始する
2026年7〜8月	初期公開へ接続する

ただし、これはかなり攻めたスケジュールである。

品質改善が想定より重ければ、後ろ倒しにする。
無理に早く公開して、信頼を落とす方が危険である。

---

11. リスク

クラウドファンディングにはメリットだけでなく、リスクもある。

リスク	内容
支援が集まらない	需要が弱いように見えてしまう
準備が重い	本文、画像、動画、FAQ、リターン設計が必要
リターン履行負荷	支援者対応が増える
開発遅延	約束した時期に提供できない可能性
誤解	サービス内容やリターンの意味を誤解される可能性
期待値管理	支援者に過度な期待を持たせるリスク
品質不足	見せた画面の品質が低いと逆効果になる

特に大きいのは、品質不足である。

今の段階では、まだ人に見せるには不安な部分がある。

だから、クラウドファンディングを検討する前に、まずは初期確認版の品質を上げる必要がある。

---

12. 自分にとっての意味

自分にとってクラウドファンディングは、単なるお金集めではない。

それは、プロジェクトを外に出す最初の大きな一歩になる。

これまでは、自分の中で考え、ChatGPTと壁打ちし、Cursorで実装し、GitHubに積み上げてきた。

しかし、クラウドファンディングを行うなら、外部の人に説明しなければならない。

• なぜ作るのか

• 何が面白いのか

• どこまでできているのか

• 何にお金を使うのか

• いつ届けるのか

• どんな人に支援してほしいのか

• 何がまだ未完成なのか

これを言語化する必要がある。

これは大変だが、プロジェクトにとって大きな意味がある。

---

13. 現時点の結論

クラウドファンディングは、かなり検討してよい。

ただし、目的はお金だけではない。

むしろ、初期ファン、先行利用者、開発過程を見守ってくれる人を集めることが大きい。

やるなら、購入型に寄せる。
金銭的リターンは出さない。
先行利用、支援者向け特典、クレジット掲載、開発レポートなどをリターンにする。

最初は50万円前後の小規模クラウドファンディングでよい。

まずは、支援してくれる人がいるかを確認する。
反応があれば、次の展開を考える。

ただし、今すぐ出すのはまだ早い。

まずは、初期確認版の品質を上げる。
外部に見せられる画面と説明資料を作る。
できること、まだできないこと、リスクを正直に書ける状態にする。

クラウドファンディングは、資金調達であり、宣伝であり、需要検証であり、初期コミュニティ作りでもある。

このプロジェクトを本当に月商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. 現時点の方針

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

1. まず、現在のブランチをmainに取り込む

2. 次に、残っているP0確認項目を消化する

3. 主要導線の通し確認に近づける

4. 空データ・エラー表示の残りを潰す

5. Surface側のチェックリストや指示文と連携する

6. スマホで最低限確認する

7. 一人用確認版の完成条件を明文化する

8. 通し確認で出た課題を整理する

9. 限定公開版に必要な項目を切り分ける

10. 初期サービスインへ向けた次の計画に進む

この流れで進めたい。

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

---

13. 今回の結論

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

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

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

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

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

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

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

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

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

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

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

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

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

1. はじめに

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

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

今回は、ついに届いた新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は、単なる買い物ではなく、開発体制への投資だった。

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