初心者でもSaaSアプリが作れた秘密を公開
3つのLLMツールを「得意分野で使い分ける」という発想
「プロンプトさえあれば、誰でもアプリが作れる時代です」
そう言われても、実際にやろうとすると、たいていこうなります。
- 何から聞けばいいかわからない
- 一回で動くコードが出てこない
- LLMが出したコードを怖くて触れない
- バグるたびに最初から作り直したくなる
私はまさにこの状態からスタートした「超ど初心者」でした。
サーバーとは何か、データベースとは何かもほとんど理解していないところから、
- GitHub でコード管理
- Vercel でホスティング
- Supabase をバックエンド（DB & Auth）に採用
- 本番運用可能な「SaaSアプリ」
を、ChatGPT、Claude Code、Codex の3つだけを相棒にしてここまで作り切ることができました。
この記事では、私が試行錯誤の末にたどり着いた
「3つのLLMツールを、どう使い分けて、どう情報を渡し、どう考えさせていたのか」
という 暗黙知のプロンプト設計 を言語化します。
目次
- なぜ「1つのツール」では限界があるのか
- ChatGPT・Claude Code・Codex の役割分担
- コンテクスト・エンジニアリング：情報の渡し方を設計する
- コグニティブ・プロンプティング：LLMの「考え方」そのものを指定する
- 開発プロセスのフレームワーク化：会話を「設計図」にして再利用する
- 実際の開発フロー：Phase 9（暗号化実装）の事例
- まとめ：初心者がSaaSアプリを作れた「本当の理由」
1. なぜ「1つのツール」では限界があるのか
最初の私は、「ChatGPT だけで全部できる」と思っていました。
しかし、実際にやってみると次のような問題に直面しました。
ChatGPT だけでやろうとしたときの問題
- ✅ 設計や方針の整理は得意
- ❌ ファイルを直接編集できない（コピペ地獄）
- ❌ プロジェクト全体のファイル構造を把握できない
- ❌ コードの差分管理が難しい
VSCode の Copilot / Codex だけでやろうとしたときの問題
- ✅ コード補完は優秀
- ❌ 設計や全体方針を考えてくれない
- ❌ 「次に何をすべきか」を教えてくれない
- ❌ プロンプトで細かく指示する機能が弱い
そこで私が行き着いたのが、
「設計はChatGPT、実装はClaude Code、細かい補完はCodex」という役割分担
でした。
2. ChatGPT・Claude Code・Codex の役割分担
私の開発フローでは、次のように使い分けています。
| ツール | 主な役割 | 使うタイミング |
|---|---|---|
| ChatGPT (5.1) | 設計・方針決定・ドキュメント作成 | Phase の最初、設計レビュー、仕様の言語化 |
| Claude Code (Sonnet 4.5) | 実装・ファイル編集・デバッグ | コードの実装、バグ修正、リファクタリング |
| Codex | リアルタイム補完・関数生成 | コーディング中の細かい補完 |
2-1. ChatGPT の使い方：「設計専門のアーキテクト」
ChatGPT には、**実装の前段階の「思考整理」と「設計」**を任せます。
実際に使っているプロンプトテンプレート
【前提】
- 私は TypeScript / サーバーサイド / DB すべて初心者です。
- ただし仕様を考えたり、要件を整理したりするのは得意です。
【技術スタック（固定）】
- リポジトリ管理：GitHub
- ホスティング：Vercel
- データベース & 認証：Supabase（PostgreSQL）
【依頼内容】
Founders Direct という SaaS の開発を、設計〜実装まで一緒に進めてください。
一度に大きな変更ではなく、「Phase」という単位で小さく進めたいです。
まずは以下の観点で「Phase 0〜Phase N」までの開発ロードマップを作ってください。
- 各 Phase のゴール
- 完了条件（Done のチェックリスト）
- 触るファイル・フォルダ
- その Phase で絶対に壊してはいけない前提
このプロンプトを使うことで、
- ✅ 技術選定が揺れない（固定前提を最初に宣言）
- ✅ 「次に何をすべきか」が明確になる
- ✅ LLMが「初心者である私」を理解した上で設計してくれる
という状態になります。
2-2. Claude Code の使い方：「実装専門のペアプロパートナー」
Claude Code は、実際にファイルを編集し、コードを書き、デバッグするツールです。
Claude Code の強み
- ✅ プロジェクト全体のファイル構造を理解できる
- ✅ 複数ファイルにまたがる変更を一度に処理できる
- ✅ diff 形式でコード変更を提示してくれる
- ✅ Git コミット・プッシュまで自動化できる
実際に使っているプロンプト
あなたは SaaS アプリ開発のペアプロパートナーです。
私は超初心者なので、毎回「今どのフェーズか」と「次に何をすればいいか」も一緒に教えてください。
コードは必ず diff 形式か、ファイル単位で提示してください。
【現在の状況】
- Phase 9-3 まで完了
- 次に Phase 9-4「暗号化関数のテスト実装」を進めたい
【依頼内容】
Phase 9-4 の内容を再掲してから、作業を始めてください。
2-3. OpenAI Codex（ターミナル）の使い方：「コンテクスト復元アシスタント」
Codex は、Claude Codeのコンテキスト切れを補完するために使います。
なぜコンテキスト切れが起こるのか
Claude Code は高性能ですが、長時間の作業や複数セッションを跨ぐと、以下の問題が発生します：
- ❌ 以前の設計方針を忘れる
- ❌ プロジェクト全体の構造を見失う
- ❌ どのファイルをどう修正したか追跡できなくなる
Codex の使い方（ターミナルで実行）
# ターミナルで Codex を起動
$ openai codex
# プロンプト例
「これまでの作業内容：
- Phase 9-3 まで完了
- workspace_data の暗号化統合が完了
- 次に Phase 9-4「暗号化関数のテスト実装」を進める
以下のファイルを読み込んで、Claude Code の新しいセッションで使える
フルパスの指示文を生成してください：
- /Users/5dmgmt/プラグイン/foundersdirect/DOCS/PHASE9-ENCRYPTION-AND-API-RUNBOOK.md
- /Users/5dmgmt/プラグイン/foundersdirect/api/_lib/encryption.ts
- /Users/5dmgmt/プラグイン/foundersdirect/DOCS/HOW-TO-DEVELOP.md
」
Codex が以下のような指示文を生成してくれます：
あなたは SaaS アプリ開発のペアプロパートナーです。
私は超初心者なので、毎回「今どのフェーズか」と「次に何をすればいいか」も一緒に教えてください。
コードは必ず diff 形式か、ファイル単位で提示してください。
【現在の状況】
- プロジェクトパス: /Users/5dmgmt/プラグイン/foundersdirect
- Phase 9-3 まで完了（workspace_data / Leads / Clients 暗号化統合完了）
- 次に Phase 9-4「暗号化関数のテスト実装」を進めたい
【依頼内容】
以下のファイルを読み込んで、Phase 9-4 の内容を再掲してから、作業を始めてください。
- /Users/5dmgmt/プラグイン/foundersdirect/DOCS/PHASE9-ENCRYPTION-AND-API-RUNBOOK.md
- /Users/5dmgmt/プラグイン/foundersdirect/api/_lib/encryption.ts
- /Users/5dmgmt/プラグイン/foundersdirect/DOCS/HOW-TO-DEVELOP.md
【重要なルール】
- 技術スタック: TypeScript + Vercel + Supabase（固定）
- 暗号化方式: AES-256-GCM（2層暗号化）
- テストフレームワーク: Playwright
- すべての変更は diff 形式で提示
この指示文をそのまま Claude Code の新しいセッションに貼り付けるだけで、
前回のセッションの文脈を完全に引き継いで作業を再開できます。
Codex の具体的な活用場面
| 場面 | Codex の使い方 |
|---|---|
| 朝一の作業再開 | 昨日の進捗とファイルパスをまとめた指示文を生成 |
| エラー発生時 | エラーログとプロジェクト構造から原因特定の指示文を生成 |
| セッション切り替え | 現在の Phase とファイル一覧から次のセッション用の指示文を生成 |
| レビュー依頼 | 変更したファイルリストから ChatGPT へのレビュー依頼文を生成 |
3. コンテクスト・エンジニアリング：情報の渡し方を設計する
3-1. 「プロのエンジニア」ではなく「共同開発パートナー」にする
最初期の私は、典型的な「マジックワード信者」でした。
あなたは10年の経験を持つフルスタックエンジニアです。
と書けば、何とかしてくれるはずだ、と。
でも実際には、
- プロっぽい用語は並ぶけれど
- 私の状況もレベル感もわかっていないので
- そのままでは実行できないコードや手順が山ほど出てくる
という壁に何度もぶつかりました。
そこで途中から、役割の設定を 「職業」ではなく「関係性」 に変えました。
あなたは SaaS アプリ開発のペアプロパートナーです。
私は超初心者なので、毎回「今どのフェーズか」と「次に何をすればいいか」も一緒に教えてください。
コードは必ず diff 形式か、ファイル単位で提示してください。
ここでやっているのは、単にロールプレイを変えることではありません。
- LLMの「思考の目的」：一緒に進捗を出すこと
- 会話のフォーマット：diff単位・ファイル単位で返すこと
- 私の制約：「超初心者」であることを常に明示
を一括で指定することで、「人間とペアプロしている感覚」に近づける文脈（コンテクスト） を作っていた、ということに後から気付きました。
3-2. 技術スタックを「固定前提」として宣言する
途中で私は、Neon → Supabase に DB を乗り換えるという大きな遠回りをしました。
- 「サーバーがあれば全部できる」と勘違いしていた
- データベースの役割を理解していなかった
- 認証（Auth）だけ後から別サービスに変えようとして沼にハマった
などなど、正直に言うと 丸2日以上を無駄にしました。
いま振り返ると、最初の段階でこう書いておけば良かったと痛感しています。
技術スタックの前提を、以下のように固定します。
- リポジトリ管理：GitHub
- ホスティング：Vercel
- データベース & 認証：Supabase（PostgreSQL）
これ以外の選択肢は基本的に提案しないでください。
必要があれば、この前提の中で最適な構成を提案してください。
LLMは「親切心」で、
- Firebase を提案してきたり
- 独自 JWT 実装を勧めてきたり
- 代替のDBサービスを出してきたり
しますが、初心者のうちは前提が増えるほど地獄です。
技術選定をしたら、必ずプロンプトの最上流に「固定前提」として書いておく。
これだけで、後からの構造変更コストが桁違いに下がります。
4. コグニティブ・プロンプティング：LLMの「考え方」そのものを指定する
次に効いていると感じるのが、いわゆる コグニティブ・プロンプティング です。
私は無意識に、以下のような形で頻繁に使っていました。
4-1. バグ修正を頼むときの三段階フォーマット
バグ修正やリファクタリングを依頼するとき、いきなり「直してください」とは言いません。
代わりに、思考プロセスごと指示します。
次の3ステップで進めてください。
1. 現状把握：
- 該当ファイルの役割と、今のバグの症状を文章で説明してください。
2. 修正方針の設計：
- どの関数・どの責務を変更するか、テキストで設計をまとめてください。
3. 差分コードの提示：
- 既存コードとの差分がわかるように、```diff``` 形式で提示してください。
これを型にしておくと、毎回、
- いきなり謎の大改造をされる
- どこが変わったのかわからない
- コメントなしのコードだけ投げられる
といった事故が大きく減りました。
4-2. 「説明だけ」「コードだけ」を分けて依頼する
もうひとつ多用しているのが、あえてアウトプットを分割させるという技法です。
まずは説明だけしてください。コードはまだ書かないでください。
と一言添えるだけで、
- ✅ 「この設計で本当に進めてよいか？」を事前にレビューできる
- ✅ 自分の理解とLLMの理解を同期してからコーディングに入れる
というメリットが生まれます。
特に、セキュリティ・暗号化・データ構造まわりでは、この二段構えがかなり効きました。
5. 開発プロセスのフレームワーク化：会話を「設計図」にして再利用する
実は一番効いているのは、会話をそのまま開発ドキュメントに落としている点かもしれません。
プロジェクトルートには、こんなファイルを置いています。
DOCS/HOW-TO-DEVELOP.md
DOCS/FDC-GRAND-GUIDE.md
DOCS/PHASE9-ENCRYPTION-AND-API-RUNBOOK.md
DOCS/Performance-Specification.md
DOCS/RLS-POLICY-GUIDE.md
これらはすべて、LLMとの対話ログから抽出した
- 決定事項
- 開発ルール
- フェーズごとのゴールと DOD（Definition of Done）
を整理したものです。
5-1. LLMに「ドキュメント化」させるプロンプト
作業の区切りごとに、だいたい次のように依頼しています。
ここまでのやりとりをもとに、
- 目的
- 設計方針
- 触ったファイル
- 今後守るべきルール
を整理して、HOW-TO-DEVELOP.md に追記すべきセクション案として Markdown で出力してください。
これを繰り返すことで、
- ✅ 新しいAIエージェントにファイルを読み込ませるだけで「プロジェクトの文脈」が伝わる
- ✅ 未来の自分が読み返しても、「なぜこの設計にしたのか」を思い出せる
- ✅ チーム開発に移行する際、そのままオンボーディング資料として使える
という状態になります。
プロンプトエンジニアリング = 会話の設計 だけでなく、
会話ログを資産化する「ナレッジエンジニアリング」 もセットで回しているイメージです。
6. 実際の開発フロー：Phase 9（暗号化実装）の事例
ここからは、実際に私が行った Phase 9「暗号化機能の実装」 を例に、
ChatGPT → Claude Code → Codex の使い分けを具体的に紹介します。
Phase 9 の概要
- ゴール: ユーザーデータを暗号化して Supabase に保存する
-
要件:
- AES-256-GCM で暗号化
- ワークスペースごとに異なる暗号化キーを使用
-既存のデータは暗号化しない（新規データのみ）
Step 1: ChatGPT で設計を固める
まず、ChatGPT に以下のプロンプトを投げます。
【前提】
- Supabase + Vercel で SaaS アプリを開発中
- TypeScript + Next.js を使用
- 暗号化は AES-256-GCM を使いたい
【依頼】
以下の観点で「Phase 9: 暗号化機能の実装」のロードマップを作ってください。
- Phase 9-1: 暗号化キーの生成・保存方法の設計
- Phase 9-2: 暗号化関数の実装
- Phase 9-3: 暗号化関数のテスト実装
- Phase 9-4: 既存APIへの暗号化処理の組み込み
- Phase 9-5: デプロイと動作確認
各 Phase について、
- ゴール
- 完了条件（Done のチェックリスト）
- 触るファイル・フォルダ
- その Phase で絶対に壊してはいけない前提
を明記してください。
まだコードは書かないでください。設計だけお願いします。
ChatGPT が返してくれた設計を、そのまま DOCS/PHASE9-ENCRYPTION-AND-API-RUNBOOK.md に保存します。
Step 2: Claude Code で実装する
次に、Claude Code を開いて、以下のプロンプトを投げます。
あなたは SaaS アプリ開発のペアプロパートナーです。
私は超初心者なので、毎回「今どのフェーズか」と「次に何をすればいいか」も一緒に教えてください。
コードは必ず diff 形式か、ファイル単位で提示してください。
【現在の状況】
- DOCS/PHASE9-ENCRYPTION-AND-API-RUNBOOK.md に設計がある
- Phase 9-1「暗号化キーの生成・保存方法の設計」から始めたい
【依頼】
Phase 9-1 の内容を DOCS/PHASE9-ENCRYPTION-AND-API-RUNBOOK.md から読み込んで、
そのゴールと完了条件を再掲してから、作業を始めてください。
Claude Code は、
DOCS/PHASE9-ENCRYPTION-AND-API-RUNBOOK.mdを読み込む- Phase 9-1 のゴールと完了条件を表示する
- 必要なファイルを作成・編集する
- diff 形式で変更内容を提示する
- 「次に何をすればいいか」を教えてくれる
という流れで、自動的に作業を進めてくれます。
Step 3: ClaudeCodeのContext上限時に Codex でコンテキスト復元
ターミナルで Codex を使って、フルパスの指示文を生成します。
# ターミナルで Codex を起動
$ openai codex
# プロンプト
「先ほどは Phase 9-3 まで完了しました。
次は Phase 9-4「暗号化関数のテスト実装」を進めます。
以下のファイルを読み込んで、Claude Code の新しいセッションで使える
フルパスの指示文を生成してください：
- /Users/5dmgmt/プラグイン/foundersdirect/DOCS/PHASE9-ENCRYPTION-AND-API-RUNBOOK.md
- /Users/5dmgmt/プラグイン/foundersdirect/api/_lib/encryption.ts
」
Codex が生成した指示文を、そのまま Claude Code に貼り付けるだけで、
前Contextの作業を完全に引き継いで、Phase 9-4 に進むことができます。
Step 4: ChatGPT で振り返りとドキュメント化
Phase 9 が完了したら、再び ChatGPT に戻って、以下のプロンプトを投げます。
【状況】
- Phase 9「暗号化機能の実装」が完了した
- 以下のファイルを変更した：
- lib/encryption.ts（新規作成）
- app/api/data/route.ts（暗号化処理を追加）
- DOCS/PHASE9-ENCRYPTION-AND-API-RUNBOOK.md（設計ドキュメント）
【依頼】
ここまでのやりとりをもとに、
- 目的
- 設計方針
- 触ったファイル
- 今後守るべきルール
を整理して、HOW-TO-DEVELOP.md に追記すべきセクション案として Markdown で出力してください。
ChatGPT が生成したドキュメントを、そのまま DOCS/HOW-TO-DEVELOP.md に追記してもらうようにClaude Codeに指示をします。
7. まとめ：初心者がSaaSアプリを作れた「本当の理由」
私が超初心者の状態から、LLMと一緒に SaaS アプリをここまで形にできたのは、
特別な才能やブラックボックス的な「神プロンプト」があったからではありません。
やっていたことを冷静に振り返ると、次の 6つ に集約されます。
1. 自分のレベルと制約を正直に申告する
前提：
- 私は TypeScript / サーバーサイド / DB すべて初心者です。
- ただし仕様を考えたり、要件を整理したりするのは得意です。
2. 技術スタック（GitHub / Vercel / Supabase）を最初に固定する
技術スタックの前提を、以下のように固定します。
- リポジトリ管理：GitHub
- ホスティング：Vercel
- データベース & 認証：Supabase（PostgreSQL）
これ以外の選択肢は基本的に提案しないでください。
3. Phase / Done を明文化したロードマップを、最初にLLMと一緒に作る
まずは、以下の観点で「Phase 0〜Phase N」までの開発ロードマップを作ってください。
- 各 Phase のゴール
- 完了条件（Done のチェックリスト）
- 触るファイル・フォルダ
- その Phase で絶対に壊してはいけない前提
4. コード修正は「説明 → 方針 → diff」の順番で依頼する
次の3ステップで進めてください。
1. 現状把握：該当ファイルの役割と、今のバグの症状を文章で説明してください。
2. 修正方針の設計：どの関数・どの責務を変更するか、テキストで設計をまとめてください。
3. 差分コードの提示：既存コードとの差分がわかるように、```diff``` 形式で提示してください。
5. 重要な会話はすべて Markdown ドキュメントとして資産化する
ここまでのやりとりをもとに、
- 目的
- 設計方針
- 触ったファイル
- 今後守るべきルール
を整理して、HOW-TO-DEVELOP.md に追記すべきセクション案として Markdown で出力してください。
6. ChatGPT・Claude Code・Codex を役割分担して使う
| ツール | 主な役割 | 使うタイミング |
|---|---|---|
| ChatGPT (5.1) | 設計・方針決定・ドキュメント作成 | Phase の最初、設計レビュー、仕様の言語化 |
| Claude Code (Sonnet 4.5) | 実装・ファイル編集・デバッグ | コードの実装、バグ修正、リファクタリング |
| OpenAI Codex (ターミナル) | コンテクスト復元・フルパス指示生成 | Claude Codeのセッション切り替え時、長時間作業後の文脈再構築 |
これらはすべて、派手なテクニックではありません。
しかし、**AIと人間が一緒にものづくりをするための「対話の設計」**として、非常に再現性が高いと感じています。
もしあなたが、
- コードは読めるけど、自分一人では実装に踏み出せない
- LLMを「調べもの」以上に活用できていない
- 「プロンプトエンジニアリング」という言葉にモヤモヤしている
のであれば、まずはこの記事で紹介した
- 「自己申告テンプレ」
- 「フェーズ設計プロンプト」
- 「3つのツールの使い分け」
だけでも、そっくりそのまま使ってみてください。
きっと、
「あ、LLMと一緒に開発するって、こういう感じなんだ」
という手触りが、これまでとはまるで違って感じられるはずです。
そしていつか、「初心者でも SaaS アプリが作れた秘密」を、
あなた自身の経験で上書きして Qiita に投稿してみてください。
その記事は、きっと誰かの「最初の一歩」を支えるコンテクストになるはずです。
付録A：開発環境の選び方 - なぜ40万円のPCより9.5万円のMacが速いのか
実際に直面した「開発環境」の壁
先日、自社のiOSアプリ開発を始めようと決意しました。すでに高性能なWindows機（レッツノートFV5、約40万円）を使っていたため、「これで十分だろう」と考えていました。
ところが、調査を進めると衝撃の事実が判明。iOSアプリ開発には必ずMacが必要という、避けられない現実がありました。
94,800円のMac mini M4という選択
悩んだ末に選んだのは、Mac mini M4（価格：94,800円税込）。私のレッツノートの4分の1以下。正直、「安すぎて大丈夫か？」と不安でした。
スペック比較
Mac mini M4（94,800円）の構成：
- Apple M4チップ
- 10コアCPU（高性能コア4つ + 高効率コア6つ）
- 10コアGPU
- 16GBユニファイドメモリ
- 256GB SSDストレージ
- 16コアNeural Engine（AI処理用）
レッツノートFV5（約40万円）の構成：
- Intel Core i7-1370P（14コア）
- 32GBメモリ
- 2TB SSD
数字だけ見れば、40万円のWindowsの方が優秀に見えます。しかし...
コア数という数字マジックの真実
組織に例えると見えてくる性能差
40万円のWindows機（14コア）の内訳：
- 管理職6名（高性能コア）
- アルバイト8名（省電力コア）
- 実質的な戦力：6名+補助8名
9.5万円のMac mini（10コア）の内訳：
- エース社員4名（超高性能コア）
- 優秀な正社員6名（高効率コア）
- 全員が即戦力
さらに「ユニファイドメモリ」という仕組みにより、Mac miniは全員が同じ部屋で仕事をしているイメージ。一方、Windowsは部門間で書類を回覧する必要があります。
結果：処理速度は価格が4分の1のMac miniの方が約2-3倍速い
なぜ40万円のPCより9.5万円のMacが速いのか
1. 設計思想の根本的な違い
- Intel: 20年前の設計を改良し続けている
- Apple M4: スマホ用省電力技術を高性能化
2. 製造技術の差
- Intel: 10nmプロセス（10億分の10メートル）
- Apple: 3nmプロセス（10億分の3メートル） → 同じ面積に3倍のトランジスタを搭載
3. 無駄の徹底排除
電力効率を極限まで高めた結果、少ない電力で高性能を実現。まさに「少数精鋭」の組織運営と同じ原理です。
実践的な使い分け戦略
既存のWindows資産は活かす
- ✅ Webサービス開発（WordPressプラグイン等）
- ✅ Chrome拡張機能の開発
- ✅ 日常業務全般
- ✅ 大容量データ管理（2TBを活用）
Mac miniで新しい価値創造
- ✅ iOSアプリ開発（必須）
- ✅ AI機能の実装（Neural Engine活用）
- ✅ 高速処理が必要な作業
- ✅ TestFlightでのベータ配信
結論：Windows機（レッツノートFV5、40万円）は手放し、Mac mini M4 に完全移行しました。
実践的な開発環境（Mac mini M4 一本化）
Mac mini M4 で実現できること（すべて）
- ✅ iOSアプリ開発（必須）
- ✅ Webサービス開発（Next.js、Vercel、Supabase）
- ✅ AI機能の実装（Neural Engine活用、Claude Code最適化）
- ✅ 高速処理（TypeScriptコンパイル、ビルド時間が1/3に短縮）
- ✅ TestFlightでのベータ配信
- ✅ 日常業務（ブラウザ、ドキュメント作成、メール）
当初の懸念： 「256GBしかないMacで大丈夫か？」「2TBのWindowsを手放して後悔しないか？」
実際に使ってわかったこと：
- ✅ クラウドストレージ（Google Drive、iCloud）で容量問題は解決
- ✅ 開発で必要なファイルは合計50GB以下
- ✅ M4チップの処理速度が圧倒的に速い
- ✅ Claude Code が Mac 上で最も安定して動作する
- ✅ 省電力で発熱が少ない（長時間作業でも快適）
投資対効果を経営視点で検証
初期投資（ハードウェア）
- Mac mini M4：94,800円（一回限り）
- Apple Developer Program：年間14,900円
- D-U-N-S番号：0円（Apple経由なら無料）
ハードウェア小計：94,800円
月額ランニングコスト（AIツール）
-
Claude Max プラン：$200/月（約30,000円/月）
- Claude Code（コード実装）
- Claude 3.5 Sonnet（高速処理）
- 無制限のプロジェクト数
-
ChatGPT Pro プラン：$20/月（約3,000円/月）
- o1モデル（高度な推論）
- GPT-4.5（設計・ドキュメント生成）
- DALL-E 3（画像生成）
月額小計：約33,000円/月
年間小計：約396,000円/年
投資総額（初年度）
- ハードウェア：94,800円
- AIツール（年間）：396,000円
- Apple Developer：14,900円
- 初年度合計：約505,700円
この投資で実現できること
- ✅ iOSアプリの自社開発（外注なら最低300万円）
- ✅ アプリの即座な改修（外注なら1回30万円〜）
- ✅ 月額課金アプリの運営（利益率90%以上）
- ✅ AIペアプログラミングで開発速度10倍
- ✅ 設計〜実装〜デバッグまで一貫した開発環境
削減できる年間コスト
- アプリ外注費用：300万円〜1000万円
- 保守改修費用：120万円〜600万円
- エンジニア採用コスト：600万円〜1000万円/年
- 投資回収期間：外注1案件で即回収（初年度投資50万円 vs 外注300万円〜）
コスト比較（年間）
| 項目 | 自社開発（AI活用） | 外注依存 |
|---|---|---|
| 初期開発 | 50万円（初年度のみ） | 300万円〜 |
| 月次改修 | 0円（自社対応） | 30万円/回 × 12回 = 360万円 |
| エンジニア採用 | 0円 | 600万円〜/年 |
| 年間合計 | 約50万円 | 約1,260万円〜 |
| 差額 | - | ▲1,210万円 |
結論：初年度で1,200万円以上のコスト削減が可能
付録B：実践プロジェクト「Founders Direct」の技術仕様
ここでは、実際に私が開発した SaaS アプリ「Founders Direct Cockpit」の技術仕様を公開します。
この仕様書自体も、ChatGPT と Claude Code との対話から生成したドキュメントです。
プロジェクト概要
Founders Direct Cockpit (FDC) は、スタートアップ経営者向けの統合管理プラットフォームです。
- 目的: MVV・OKR・リーンキャンバス・顧客管理・TODO管理を一元化
- 技術スタック: TypeScript + Vercel + Supabase
- 開発期間: 約3ヶ月（Phase 1〜Phase 9）
技術スタック（確定版）
| レイヤー | 技術 | 理由 |
|---|---|---|
| フロントエンド | TypeScript (Vanilla) | フレームワークなしで軽量・高速 |
| バックエンド | Vercel Serverless Functions | サーバー管理不要・自動スケール |
| データベース | Supabase (PostgreSQL 17.6) | RLS対応・認証統合・無料枠が大きい |
| 認証 | Google OAuth + サーバーセッション | Cookie ベース、HttpOnly/SameSite=Lax |
| 暗号化 | AES-256-GCM | 2層暗号化（マスター鍵＋Workspace鍵） |
| テスト | Playwright | E2Eテスト自動化 |
| デプロイ | Vercel | GitHub連携・自動デプロイ |
フォルダ構成
foundersdirect/
├── api/ # Vercel Serverless API
│ ├── _lib/ # 共通ライブラリ
│ │ ├── auth.ts # 認証・認可ヘルパー
│ │ ├── db.ts # Supabase接続・クエリ
│ │ ├── encryption.ts # AES-256-GCM暗号化
│ │ └── keyManagement.ts # ワークスペース鍵管理
│ ├── auth/ # 認証API
│ │ ├── google.ts # Google OAuth
│ │ ├── me.ts # 現在のユーザー情報
│ │ └── logout.ts # ログアウト
│ ├── workspaces/ # ワークスペース管理API
│ │ ├── index.ts # WS一覧・作成
│ │ └── [workspaceId]/
│ │ ├── data.ts # データ保存・取得（暗号化）
│ │ └── members.ts # メンバー管理
│ └── reports/ # レポートAPI
│ ├── summary.ts # ロール別サマリ
│ └── export.ts # CSVエクスポート
├── js/ # フロントエンドTypeScript
│ ├── core/ # コアモジュール
│ │ ├── state.ts # 状態管理（AppData）
│ │ ├── auth.ts # 認証・権限チェック
│ │ ├── apiClient.ts # API通信
│ │ └── analytics.ts # KPI計算・ファネル統計
│ └── tabs/ # タブUI実装
│ ├── dashboard.ts # ダッシュボード
│ ├── mvvOkr.ts # MVV・OKR
│ ├── todo.ts # TODO管理
│ ├── leads.ts # 見込み客
│ ├── clients.ts # 顧客管理
│ └── reports.ts # レポート
├── tests/ # テスト
│ ├── e2e/ # E2Eテスト（Playwright）
│ ├── unit/ # ユニットテスト
│ └── integration/ # 統合テスト
├── migrations/ # DBマイグレーション
│ ├── 000-base-schema.sql # 基本スキーマ
│ ├── 001-rls-policies.sql # RLSポリシー
│ └── 002-workspace-keys.sql # 暗号鍵テーブル
└── DOCS/ # ドキュメント
├── FDC-GRAND-GUIDE.md # プロジェクト全体ガイド
├── HOW-TO-DEVELOP.md # 開発者向け技術ガイド
├── FDC-ARCHITECTURE-OVERVIEW.md # アーキテクチャ図
├── Performance-Specification-v1.0.md # 性能基準
├── RLS-POLICY-GUIDE.md # RLSポリシーガイド
├── E2E-TEST-GUIDE.md # E2Eテストガイド
└── Encryption-Allocation-Table.md # 暗号化対象一覧
データベース設計（主要テーブル）
users（ユーザー管理）
CREATE TABLE users (
id SERIAL PRIMARY KEY,
google_sub TEXT UNIQUE NOT NULL, -- Google OAuth識別子
email TEXT NOT NULL,
name TEXT,
picture TEXT,
global_role TEXT NOT NULL DEFAULT 'normal',
created_at TIMESTAMP DEFAULT NOW(),
updated_at TIMESTAMP DEFAULT NOW()
);
workspaces（ワークスペース）
CREATE TABLE workspaces (
id SERIAL PRIMARY KEY,
name TEXT NOT NULL,
owner_id INT REFERENCES users(id),
created_at TIMESTAMP DEFAULT NOW()
);
workspace_data（暗号化データ保存）
CREATE TABLE workspace_data (
workspace_id INT PRIMARY KEY REFERENCES workspaces(id),
data JSONB NOT NULL, -- 暗号化されたJSONデータ
version INT DEFAULT 1,
updated_at TIMESTAMP DEFAULT NOW()
);
パフォーマンス基準（Performance Specification v1.0）
| 区分 | 指標 | 基準 |
|---|---|---|
| UI 操作 | 初回 Dashboard 表示 | P95 < 2.0 秒 |
| UI 操作 | タブ切替 | P95 < 1.2 秒 |
| API | GET 系 | P95 < 350ms |
| API | POST/PUT 系 | P95 < 450ms |
| 暗号化 | Workspace 復号 | P95 < 280ms |
| 暗号化 | 保存時暗号化 | P95 < 180ms |
| データ | workspace_data JSON | 1 Workspace 250KB 以下 |
開発の進め方（Phase管理）
プロジェクトは Phase 1〜Phase 12 に分割して進めています。
完了したPhase
- ✅ Phase 1-6: 基本UI・データ構造設計
- ✅ Phase 7: 認証・RBAC・監査ログ・レポート機能
- ✅ Phase 8: E2Eテスト基盤構築
- ✅ Phase 9: DB移行（Neon → Supabase）・認証レイヤー移行・暗号化統合
進行中のPhase
- 🚧 Phase 10: TODO機能拡張（4象限 + カレンダー + Elastic Habits）
- 📋 Phase 11: Action Map（行動計画）
- 📋 Phase 12: OKR機能拡張
LLMとの対話で生成したドキュメント一覧
これらすべて、ChatGPT と Claude Code との対話から生成しました：
-
FDC-GRAND-GUIDE.md (約400行)
- プロジェクト全体の規範書
- AIエージェントの役割分担
- 開発理念・運用原則
-
HOW-TO-DEVELOP.md (約800行)
- 開発者・AI向け技術ガイド
- API実装パターン
- セキュリティルール
-
FDC-ARCHITECTURE-OVERVIEW.md (約450行)
- システムアーキテクチャ図（Mermaid）
- データフロー図
- ボトルネック分析
-
Performance-Specification-v1.0.md (約150行)
- パフォーマンス基準
- 計測方法
- 見直し条件
-
Encryption-Allocation-Table.md (約200行)
- 暗号化対象一覧
- フィールド別暗号化要否
- タイミング定義
このプロジェクトから得られた教訓
-
技術選定は最初に固定する
- Neon → Supabase の移行で2日間を無駄にした
- 最初から Supabase に固定していれば良かった
-
Phase管理は必須
- Phase単位で「ゴール」と「Done の定義」を明確にする
- LLMに「今どのPhaseか」を常に伝える
-
ドキュメント化は資産
- 会話ログをMarkdownに落とすだけで、新しいAIにも文脈が伝わる
- 未来の自分が読み返しても理解できる
-
ChatGPT と Claude Code の使い分けが重要
- 設計はChatGPT、実装はClaude Code
- この役割分担で開発効率が10倍になった
参考リンク
この記事が役に立ったら、ぜひ LGTM をお願いします！（この意味をググったことは言うこともありません💦）