50日間の高速開発がフェーズ1で完全停止。AIを過信した1人開発のリアルな絶望。

※この記事は、Claude Codeで1人開発しているSNS運用SaaS「ThreadPost」の開発日記です。

設計書を完璧に書き上げた。

Claude Codeに「3フェーズ一気に組んでくれ」と指示を出した。

最初のマイグレーションを実行した。

画面が真っ赤なエラーで埋め尽くされた。

AIは「修正しました」と連呼する。

でも、何度やっても動かない。

僕が書いた仕様書が、最強のバグを生み出していた。

設計書の「ペルソナ上限0」がシステムを止めた

Phase 1のマイグレーションを実行した瞬間、全停止した。

エラー内容をターミナルからコピーして貼る。AIから「修正しました」と即座に返ってくる。もう一度スクリプトを走らせる。まだ動いていない。

原因は僕だった。

設計書のどこかで「Freeプランのペルソナ上限0」と書いていた。

AIはそれを忠実に守った。

その結果、Freeプランのユーザーは何もできない状態になっていた。

ペルソナ上限0。つまり、誰も発信キャラクターを作れない。

オンボーディングの最初のステップで全員が詰む。

SaaSのフリーミアムモデルにおいて、無料プランの設計は命綱だ。ユーザーに価値を体験してもらい、有料プランへ誘導する。その最初の体験が「ペルソナ作成」のはずだった。上限が0なら、ユーザーは登録直後に離脱する。

AIは、この破滅的なビジネスロジックを忠実にデータベースの制約として刻み込んでいた。だから、オンボーディングの途中で新規ユーザーのデータが保存できなかった。

「Correct free plan persona limit from 0 to 1」

この1行を直すために、数時間を溶かした。

企業開発なら、仕様レビューの段階で誰かが気づく。1人開発では、全部自分で被るしかない。

しんたろー:
43コミットのうち、序盤の15件くらいが設計の不整合を埋める作業だった。コードを書くより、ドキュメントの数字を睨んでいる時間の方が長かった。AIを責められないのが一番きつい。完璧なアシスタントは、主人のミスも完璧に実行する。

今週の全体像

オンボーディングからプラン管理まで、一気に基盤を作るつもりだった。

結果として、43回のコミットを積むことになった。

新機能追加が2件。バグ修正が1件。

残りの40件は、ひたすら不整合と戦った記録だ。

AIのコーディング速度は異常に速い。

でも、設計の穴は人間が埋めないといけない。

完璧な設計書が招いた崩壊

「Phase 1のマイグレーション、Phase 2のプラン管理UI、Phase 3のオンボーディング実装」

これを設計書に全部書いて、Claude Codeに渡した。

データベース設計からフロントエンドの画面遷移まで、一気に駆け抜けるはずだった。

最初の動作確認スクリプトでコケた。

「修正しました」じゃないんだよ。

一般的なSaaS開発で、データベースのマイグレーションは鬼門中の鬼門だ。

一度失敗すると、データベースの状態が汚染される。テーブルは作られたがカラムが足りない、といった中途半端な状態になる。整合性の復旧には多大なコストがかかる。

特にプラン制限のようなビジネスロジックは厄介だ。コードだけでなく、データベースのCheck制約などと同期させる必要がある。AIが単体テストをパスしても、ビジネス要件との乖離は防げない。

しんたろー:
ここで数時間溶かした。AIは指示通りに動くだけ。僕の指示が狂っていたら、狂ったまま爆速で実装が進む。恐怖しかない。

「fix: Default plan to free」

このコミットを打つまで、何が起きているか全く分からなかった。

そこから先は割と早かった。プラン別のアカウント数制限を実装した。Freeプランのスケジュール予約上限を設定した。1問1画面のスライド式オンボーディングも組んだ。

「feat: Slide-style onboarding」

デザインは一気にモダンになった。グラデーション背景にスライドアニメーションを入れた。プログレスバーも動くようにした。

1問1画面のスライド式UIは、コンバージョン率を上げるための現代の定石だ。長いフォームを一度に見せると、ユーザーは離脱する。ステップごとに分割し、プログレスバーで進捗を示す。これで心理的なハードルを下げる。

Reactで実装するには、状態管理とアニメーションライブラリの組み合わせが必要になる。ステップの切り替え時に画面上部に戻す処理など、細かいUXの調整もAIに指示した。

GoogleのOAuth認証フローが途中で壊れていたのも直した。サインアップ完了時に成功メッセージが出るようにした。オンボーディングの完了画面には、SNS連携の訴求を入れた。発信キャラ作成画面には「一度しっかり設定すれば、あとは全自動」と書いた。

「fix: OAuth error handling」

この辺りの修正は、AIが本領を発揮した。

認証周りのエラーハンドリングは、エッジケースが多くて人間が見落としやすい。AIは、キャンセル時やコード欠損時の処理を網羅的に実装してくれた。ただし、それも僕が「キャンセル時の処理も全部書いて」と明示したからだ。

消えた紹介コード

紹介コードの機能を実装しようとした。

URLパラメータから「ref」を取得するだけだと思っていた。

「fix: 紹介コード（ref）がsignupページに正しく渡されるよう修正」

このコミットメッセージが全てを物語っている。

LPからサインアップ画面に遷移する。その間に、紹介コードが消え去っていた。

フロントエンドの認証フローにおいて、OAuthリダイレクトはブラウザのセッションを跨ぐ。Googleでログインするボタンを押すと、一度外部のドメインに飛ばされる。戻ってきたときには、URLのパラメータは綺麗さっぱり消えている。

URLパラメータのみに依存するのは非常に脆弱だ。業界標準では、初回アクセス時にCookieやLocalStorageへ書き込む。認証完了後にそれを読み出すのが定石とされている。

僕はそれを完全に忘れていた。

だから僕は、Cookieへの保存処理を実装した。

結果、HeroCTAからsignupページまで、全コンポーネントの改修が必要になった。Cookieから値を読み取り、リンクのパラメータとして再構築する。たった一つの文字列を受け渡すために、巨大なバケツリレーの仕組みを作ることになった。

Reactの状態管理とルーティングの複雑さに、しんどくなった。

しんたろー:
単なるパラメータ受け渡しが、Cookie永続化を伴う巨大タスクに化けた。「refを渡すだけ」が半日仕事になるのが1人開発のリアルだ。こういうのが一番心折れる。

「update signup placeholder name」

ついでにプレースホルダの名前も変えた。

「田中太郎」から「節約主婦ゆみ、筋トレ社長、Web系フリーランスたく」へ。実際のSNSアカウント名に近い形式にした。

AIにペルソナを提案させる際、この入力値がプロンプトの一部になる。具体的なジャンルと名前の組み合わせを促すことで、AIの出力の質が変わった。店舗の代表者名には、店舗名も含めるようにした。「パン工房まるやの店長 山田」といった具合だ。

紹介コードのバグも、気づいたら静かに直っていた。Cookieから読み取って、リンクにパラメータとして含める。たったこれだけの処理に、どれだけのコンポーネントを跨いだか。状態管理は本当に面倒だ。

落とし穴：「修正しました」の無限ループ

「設計書通りに動くはず」と信じてPhase 1のマイグレーションを実行した。

データベースの制約エラーで全停止し、AIが「修正しました」と繰り返す無限ループに突入した。

ターミナルの画面には、同じエラーメッセージが何度も何度も表示される。ロールバックのスクリプトすら、整合性が取れなくなってきた。

結局、AIが壊したのではなく、僕が書いた「ペルソナ上限0」という仕様が原因だった。AIの完璧な忠実さによって「ユーザーを詰ませる最強のバグ」として具現化していた。

設計書の数字が間違っていれば、AIはその間違いを完璧なコードとして出力する。レビュアーがいない1人開発では、この構造的な罠から逃げる方法がない。次からは設計書の数値を全部声に出して読む。たぶん。

今日の数字

| 指標 | 今回のデータ | 比較対象 |

|------|------------|----------|

| コミット数 | 43件 | 人間のみなら推定120時間相当 |

| 新機能 | 2件 | スライド式オンボーディング、プラン別制限 |

| バグ修正 | 1件 | Freeプランペルソナ上限0→1 |

| 不整合修正 | 40件 | 全コミットの93% |

43コミットを人間が手動で行った場合、推定120時間はかかる。

AI活用で約18時間に圧縮できた計算だ。ただし、設計書の修正コストと実装コストの比率は1対9だった。

人間が泥臭く数字の辻褄を合わせ、AIが一瞬でコードを書く。コードを書く時間は減ったが、頭を抱える時間は増えた。企業チームなら仕様策定含め1ヶ月かかる規模を、18時間で回した。ただしUIはまだボロボロな箇所がある。

FAQ

Q: 「ペルソナ上限0」のバグはなぜレビューで気づけなかったのか？

1人開発にレビュアーはいない。設計書を書いた本人が実装者でもあるため、「0は意図的な設定かもしれない」という思い込みが働く。企業開発なら仕様レビューで誰かが「0だとユーザーが何もできないですよね？」と突っ込む。その一言がない環境では、AIが完璧に0を実装してしまう。次からは数値制限を書いたら必ず「この値でユーザーは何ができるか」を声に出して確認する。たぶん。

Q: OAuthリダイレクト後にURLパラメータが消える問題は、どう防ぐのか？

初回アクセス時にCookieかLocalStorageへ書き込む。OAuthの認証フローはブラウザが外部ドメインへ飛ぶため、URLパラメータはリダイレクト完了時点で消える。Cookieに保存しておけば、認証完了後に読み出せる。有効期限を短く設定しておくのが定石で、今回は1時間に設定した。

Q: 43コミットのうち40件が不整合修正というのは多すぎないか？

多い。ただ、これはAIの問題ではなく設計フェーズの問題だ。Phase 1〜3を一気に設計書に書いてAIに渡したため、フェーズ間の依存関係の矛盾が後から次々と噴出した。フェーズを分けて、Phase 1が動いてからPhase 2の設計書を書く順番にすれば、不整合の連鎖は防げた。次回からはそうする。たぶん。

まとめ

設計書の1文字のミスが、システム全体を止める。

AI開発は速いが、その分だけ人間の責任が重くなる。

👉 ThreadPostでSNS運用を自動化する