Claude Code だけで個人 SaaS を 90 日で作って稼ぐ — 設計・実装・収益化の完全記録（2026年版）

個人で SaaS を作り、Claude Code に支払うコストより多くを稼ぐ。このシンプルな目標に向けて、私は 2026 年 2 月から 90 日間の記録をつけ続けました。この記事はその全工程の公開ノートです。

成功談を並べたいわけではありません。つまずいた箇所、判断ミス、トークンを無駄にした失敗も、すべて含めています。なぜなら、それらこそが次に同じことをしようとしている方に一番役立つと思うからです。

1. 出発点 — なぜ Claude Code だったのか

「Cursor を使えばいいのでは？」とよく聞かれます。私もそう思っていた時期がありました。

転機になったのは、あるバグ修正でした。コードベースをまたいで影響範囲を自分で把握し、テストを書き直し、PR を出す——この一連の作業を Claude Code は自律的にやり遂げてくれたのです。Cursor はエディタ内補完が得意ですが、Claude Code は「考えながら作業する」ことができます。SaaS 開発のような複雑な依存関係が絡む場面では、この差は大きいです。

もうひとつの理由は、API コストの透明性です。Claude Code は Anthropic API 従量課金なので、何にいくら使っているかが明確です。フラット料金のツールは「使い放題」に見えてコスト感覚が鈍りますが、私はトークン消費を意識しながら開発したかった。個人開発者にとって、コスト感覚は利益率に直結します。

2. プロダクト選定（Day 1〜7）

最初の 1 週間は、プロダクトアイデアの選定に使いました。判断基準は 3 つです。

① 自分が毎日使うもの
外部市場調査より確実な需要確認手段は「自分が困っているか」です。私が選んだのは、複数の App Store プロダクトの売上・レビュー・ランキングを一括で管理するダッシュボードでした。

② Claude Code が得意な技術スタック
Next.js + TypeScript + Stripe + Cloudflare Workers。この組み合わせを選んだのは、Claude Code がこのスタックに非常に精通しており、エラーの自己修正率が高いからです。Ruby on Rails や Django を選んでいたら、学習コストとデバッグコストが跳ね上がっていたと思います。

③ 3 ヶ月で収益化できる複雑さ
「スモールスタートで課金する」設計にしました。完成してから課金するのではなく、最初の有料機能を Day 30 にリリースする計画で逆算しました。

3. MVP 設計 — Claude Code との設計対話（Day 8〜14）

コードを書く前に 1 週間、Claude Code と設計を練りました。具体的には、/architect プロンプト（Claude Code の計画モード）を多用しました。

# 設計フェーズで使ったコマンド例
claude --model claude-opus-4-6 "
以下の要件で Next.js + Cloudflare Workers の設計をレビューしてください。
 
要件:
- App Store Connect API でデータ取得
- 複数アプリの売上・レビューを統合表示
- Stripe Pro 月額課金（¥580/月）
- 10,000 ユーザーまでスケール可能
 
懸念点として伝えておきたいのは、App Store Connect API には rate limit があること。
Cloudflare Workers の CPU 制限（10ms/request）も考慮に入れてください。
"

この設計対話で気づいた落とし穴が 2 つありました。

落とし穴①: Cloudflare Workers の CPU 制限
App Store Connect からのデータ集計は Worker 上でやると CPU 制限に引っかかる。Claude Code の提案は「集計は Cron Trigger + KV にオフロードする」でした。この設計変更を Day 8 に決断したことで、後のパフォーマンス問題を未然に防げました。

落とし穴②: Stripe Webhook の冪等性
「課金完了 → KV にフラグを立てる」という単純な設計では、Webhook の再送信で重複処理が発生します。Claude Code が指摘するまで、私はこれを見落としていました。冪等キーの設計を最初から組み込んだことで、後でハマる典型的なバグを防げました。

4. 実装フェーズ — モデル使い分けとトークン管理（Day 15〜60）

ここが最もコストに直結するフェーズです。私が確立したルールを公開します。

モデル使い分けの原則

タスク	モデル	理由
設計・アーキテクチャ判断	claude-opus-4-6	複雑な判断が必要
実装・コード生成	claude-sonnet-4-6	コスパ最良
単純なリファクタリング	claude-haiku-4-5	高速・低コスト
バグ修正（原因特定済み）	claude-haiku-4-5	方針が決まっていれば十分

具体的には、朝の設計セッションだけ Opus を使い、それ以外は Sonnet と Haiku を使い分けました。この切り替えだけで、月間トークンコストが 40% 削減できました。

セッション設計の重要性

Claude Code で一番失敗しやすいのが、1 つのセッションを長くしすぎることです。コンテキストが膨らむと：

既に決定した設計を「忘れて」別の実装を提案し始める
修正のループが増え、無駄なトークンを消費する
前の変更を踏まえた提案ができなくなる

私が実践したのは「CLAUDE.md での状態管理」です。各セッションの開始時に、直前のセッションで決定したことを CLAUDE.md に記録し、次のセッションで最初に読み込ませます。

<!-- CLAUDE.md の state セクション例 -->
## 現在の実装状態（2026-03-15 更新）
 
### 完了済み
- App Store Connect API wrapper（src/lib/asc.ts）
- Cloudflare KV キャッシュ戦略（5分TTL）
- Stripe Webhook 冪等キー実装
 
### 次のセッションのタスク
- ダッシュボード UI コンポーネントの実装
- recharts でグラフ表示
- [ ] 注意: recharts は Cloudflare Workers では動かない（SSR 禁止）

このメモが、セッション間の「文脈の橋渡し」になります。特に「注意点」を記録する習慣が、後のデバッグ時間を大幅に削減しました。

5. 最初の有料ユーザー獲得（Day 30）

計画通り、Day 30 に最初の有料機能をリリースしました。設計上の判断を 1 つ共有します。

「Free → Paid」の摩擦を下げる設計

Claude Code に実装を依頼した際、最初の提案は「登録後に支払い情報を入力させる」フローでした。私はこれを却下し、こう変えました。

無料で使う → 7日間フルアクセス → 8日目から有料機能が制限される → Stripe Checkout に誘導

理由は個人的な体験からです。登録直後に課金を求められるサービスは、私自身が離脱しているからです。まず価値を体験してもらう。これがコンバージョン率に大きく影響しました。実際、フリートライアルを設けた後、有料転換率は 12% から 27% に改善しました。

Claude Code での実装時、Stripe Trial Period の設定は 1 行の変更でした。しかし「7 日後に自動課金が始まる」ことをユーザーに明示するメールのタイミング設計——これは Claude Code と何度も対話しながら詰めた部分です。

6. 本番リリースと Cloudflare 運用（Day 60〜90）

Cloudflare Workers + Pages にデプロイしての本番運用で、Claude Code が特に役立ったのはデバッグフェーズです。

エッジ環境特有のエラー対応

本番で発生したエラーのうち、私が自力では原因を特定できなかったものが 3 件ありました。すべて Cloudflare Workers 固有の制約によるものです。

エラー①: Cannot perform I/O on behalf of a different request

claude "以下のスタックトレースを分析してください。
Cloudflare Workers 環境で発生しています。
[スタックトレースをペースト]
 
このエラーは KV 操作が非同期で分離されたコンテキストで呼ばれた時に起きます。
修正方法を示してください。"

Claude Code の回答は即座でした。原因は waitUntil() を使わずに KV を非同期書き込みしていたこと。修正は 5 行。自力でドキュメントを読んでいたら、1 日かかっていたと思います。

エラー②: articles.json の 62 MiB 制限超過

これも Cloudflare Workers 特有のものです。記事データを JSON で管理していたところ、記事数が増えると Worker バンドルが制限を超えてデプロイできなくなりました。

Claude Code の提案は「Content Split Architecture」——メタデータと HTML コンテンツを分離して、コンテンツは public/ に個別ファイルとして出力する設計です。この大規模なアーキテクチャ変更を、コードを生成しながら説明してくれたのは本当に助かりました。

90 日間のコストと収益

公開できる範囲で数字を共有します。

項目	金額
Claude Code トークンコスト（90日）	約 ¥45,000
Cloudflare Workers（無料プラン）	¥0
Stripe 手数料（売上の 3.6%）	変動
90日時点の MRR（月次経常収益）	公開非公開

トークンコストが ¥45,000 というのは、最初の 1 ヶ月が ¥20,000 超で焦りましたが、モデル使い分けと CLAUDE.md による状態管理を確立してからは、月 ¥10,000 前後に安定しました。

7. 振り返り — Claude Code との 90 日で学んだこと

やってよかったこと

設計に時間をかけたこと。Day 1〜14 の設計フェーズで Claude Code と丁寧に対話したおかげで、後の手戻りが最小になりました。実装フェーズで「根本から設計を変える」ことは一度もありませんでした。

失敗を記録し続けたこと。CLAUDE.md の「注意点」セクションに失敗パターンを書き続けたことで、同じミスを繰り返しませんでした。Claude Code は前のセッションを覚えていませんが、ドキュメントは覚えています。

やらなければよかったこと

完璧主義。UI のデザインに時間をかけすぎました。最初の有料ユーザーは UI のきれいさではなく「自分の問題を解決できるか」で判断します。Day 20 に気づいてからは、「動く最小構成」を優先する意思決定に変えました。

1 つのセッションを長く続けること。これは本当に痛い目を見ました。8 時間のセッションの末に、Claude Code が最初の設計と矛盾するコードを生成し始め、すべてロールバックしたことがあります。今は 2 時間を目安にセッションを切っています。

90 日という期間は、「SaaS を作れるかどうか確認する」には十分でした。収益化まで到達できたのは、Claude Code のおかげだけではなく、個人開発者として積み上げてきた判断力もあります。Claude Code は実装速度を 3〜5 倍にしてくれますが、「何を作るか」「いつ切り上げるか」の判断は、まだ人間の仕事です。

次のステップとして試してほしいのは、まず 30 日間のミニ SaaS チャレンジです。30 日で「誰かに課金してもらう」を目標にすると、設計も実装も適切な優先順位がつきます。Claude Code はその最良のパートナーになれると、私は確信しています。