個人開発では「自分一人でインフラも運用も全部やる」という前提で選定する。
| 軸 | 内容 |
|---|---|
| 開発速度 | 認証・DB・ストレージが最初から揃っているか |
| 運用コスト(お金) | 無料枠で賄えるか、スケール時に破産しないか |
| 運用コスト(手間) | サーバー管理が必要か、デプロイが簡単か |
| スケーラビリティ | ユーザーが増えたとき対応できるか |
❌ オーバーエンジニアリング
「将来スケールするかも」→ ECS + RDS を最初から構築
→ 運用が重すぎて開発が止まる
❌ 後から詰む
「とりあえず動けばいい」→ Supabaseだけで無理やり実装
→ 複雑化したとき移行コストが爆発する
💡 ポイント: 「今の要件で最もシンプルな構成」を選び、「1段階上の構成」に移行できる設計にしておく
バックエンドサーバーを自分で立てずに済む最速構成。SupabaseがBaaSとしてDB・認証・ストレージをまるごと肩代わりしてくれる。
[ユーザー]
↓
[Vercel] ← Next.jsをホスティング
↓
[Supabase]
├── PostgreSQL(DB)
├── Auth(認証)
├── Storage(ファイル)
└── Realtime(リアルタイム通信)
// 認証
const { data } = await supabase.auth.signInWithPassword({
email: 'user@example.com',
password: 'password',
});
// DBアクセス(APIルート不要)
const { data: posts } = await supabase
.from('posts')
.select('*')
.eq('user_id', user.id);
| サービス | 無料枠 |
|---|---|
| Vercel | 個人利用は実質無料 |
| Supabase | DB 500MB・Auth 50,000ユーザーまで無料 |
| 合計 | ほぼ0円 |
・プロジェクト数:2つまで
・非アクティブ7日でDBが一時停止
・ストレージ:1GB
・DBサイズ:500MB
対策:
① 1つのプロジェクトにスキーマで複数アプリを共存
② MVPはSupabase → 育ったらPro($25/月)へ
③ MVP検証後にRDS + Renderへ移行
シンプルなCRUD → ✅ Supabase Clientで十分
複雑なJOIN・集計 → ⚠️ 辛くなってくる → Drizzle導入を検討
バックグラウンド処理 → ❌ 無料枠では定期実行不可 → 次の構成へ
独自の複雑な認証ロジック → ❌ 向いていない → 次の構成へ
💡 ポイント: 「まずこれで作り始めて、詰まったら次の構成に移行する」が個人開発の正しい戦略
Lightest構成にHonoを追加した構成。コストはLightestと同じままで柔軟性が上がる。
✅ ビジネスロジックをAPIに集約できる
✅ ミドルウェアで認証・バリデーションを共通化
✅ Drizzleと組み合わせて複雑なクエリを書ける
✅ Edge Runtimeで動くので高速
✅ 将来バックエンドだけ切り出しやすい
// Next.js Route Handlersのみ → 全ルートに個別に書く必要がある
export async function GET(req) {
const user = await checkAuth(req) // 毎回書く
if (!user) return Response.json({ error: 'Unauthorized' }, { status: 401 })
}
// Honoのミドルウェア → 一箇所に書くだけで全ルートに適用
app.use('/api/*', authMiddleware) // これだけ
app.get('/api/posts', (c) => { /* 認証済み前提で書ける */ })
app.get('/api/comments', (c) => { /* 認証済み前提で書ける */ })
💡 ポイント: ファイル分割だけでもロジックは分けられるが、Honoの本質的な価値は「ミドルウェア・ルーティング・移植性」。規模が小さいうちはファイル分割で十分なケースもある
Pythonが必要になる要件が出てきたときに選ぶ構成。
✅ 機械学習・データ分析(Python資産が使える)
✅ 複雑な管理画面(Django Adminが強力)
✅ 重いバックグラウンド処理(Celery + Redis)
✅ すでにDjangoの経験がある
| サービス | 無料枠 | 注意点 |
|---|---|---|
| Render | あり | 15分でスリープ |
| Railway | 月$5分のクレジット | 無料枠が少ない |
| AWS ECS | ほぼなし | 設定が複雑 |
Phase 1: 共存
├── /api/posts → Hono(既存のまま)
└── /api/ml → Django(新しく追加)
Phase 2: 徐々に移行
複雑になってきたルートからDjangoに移す
Phase 3: 完全移行(必要なら)
全APIをDjangoに統一
💡 ポイント: HonoとDjangoはURLで呼び分けられるので共存は難しくない。「全部作り直し」ではなく「必要な部分だけ追加」が現実的
SupabaseのAWS版というイメージ。企業レベルのスケーラビリティが必要なとき。
Supabase Auth:個人開発で十分
✅ メール/パスワード・OAuth・マジックリンク
Cognitoが必要になる現実的なケース:
✅ 企業のAD・SAMLと連携が必要
✅ MFAが必須要件(医療・金融系)
✅ 既存のCognitoユーザープールがある
月額目安:$15〜$30/月〜(RDSの固定費が発生)
💡 ポイント: 個人が趣味で作るアプリでCognitoが必要になることはほぼない。Google/GitHubログインならSupabase Authで十分
AWSインフラをフルコントロールする構成。本格的なプロダクトか仕事の学習目的で選ぶ。
API Gateway:
→ 外部からのリクエストを受け付ける門番
→ レート制限・認証チェック・ルーティング
ECS(Fargate):
→ Dockerコンテナでバックエンドを動かす
→ サーバー管理不要(サーバーレスコンテナ)
RDS:
→ AWSが管理するPostgreSQL
→ バックアップ・フェイルオーバーが自動
Render:アプリを動かす場所だけを提供
ECS + API Gateway:
API Gateway → セキュリティ・レート制限・ルーティング
↓
ECS → アプリを動かす
→ AWSエコシステム(Cognito・CloudWatch・WAF)と密連携
月額目安:$35〜$80/月〜
💡 ポイント: AWS ECS経験があるなら移行コストは低い。個人開発で選ぶ理由は「本格運用化」または「仕事のAWS経験を個人でも活かしたい」場合
スタート:個人で何か作りたい
↓
Q1. Pythonが必要か?(ML・データ分析・Django Admin)
├── Yes → Q4へ
└── No → Q2へ
↓
Q2. ビジネスロジックが複雑か?
├── No → 【Lightest】Next.js + Supabase + Vercel
└── Yes → 【Light】Next.js + Hono + Supabase + Vercel
↓
Q3. 有料ユーザーがいる・SLAが必要か?
├── No → Lightのまま
└── Yes → Q5へ
↓
Q4. AWSに統一したいか?
├── No → 【Middle】Next.js + Django + Supabase + Render
└── Yes → Q5へ
↓
Q5. フルAWSコントロールが必要か?
├── No → 【Heavy①】Amplify + Cognito + RDS
└── Yes → 【Heavy②】ECS + API Gateway + Cognito + RDS
| 構成 | バックエンド | DB | 認証 | ホスティング | 月額目安 |
|---|---|---|---|---|---|
| Lightest | なし | Supabase | Supabase Auth | Vercel | 0円 |
| Light | Hono | Supabase | Supabase Auth | Vercel | 0円 |
| Middle | Django | Supabase/RDS | Django Auth | Vercel + Render | $7〜 |
| Heavy① | Amplify | RDS | Cognito | Vercel + AWS | $15〜 |
| Heavy② | Django/Hono | RDS | Cognito | Vercel + ECS | $35〜 |
Lightest → Light ✅ Honoを追加するだけ
Light → Middle ✅ バックエンドを差し替えるだけ
Middle → Heavy② ⚠️ インフラ設計が必要、ただし段階移行可能
| ミス | 改善策 |
|---|---|
| 最初からECS + RDSを構築する | MVPはLightest/Lightから始める |
| Supabaseの2プロジェクト制限を忘れる | MVP用・本番用で1つずつ、または早めにPro移行 |
| HonoからDjangoに全部作り直す | 共存→段階移行が現実的 |
| 個人開発にCognitoを採用する | SSO・SAML連携が必要でない限りSupabase Authで十分 |
| Renderの無料枠を本番で使う | 15分スリープがあるため本番は有料プランへ |
- 個人開発の鉄則:「今の要件で最もシンプルな構成から始めて、1段階上に移行できる設計にしておく」
- Supabaseの無料枠(2プロジェクト・非アクティブ7日停止)は個人開発で現実的な制約になる
- HonoとDjangoは共存できるのでいきなり全部移行しなくていい
- AWS Heavy構成はECS経験があるMickeyには移行コストが低い選択肢
- ミドルウェアはDjangoのデコレータ・Middlewareと同じ発想