技術選定 | Notion

目的：本プロダクトの技術スタックを確定し、実装フェーズの判断根拠とする。

選定基準：PoC最速化・個人開発の維持コスト最小・将来のスケールアウト可能性の3軸。

✅ 確定スタック

┌─────────────────────────────────────────────┐
│  Next.js 15（App Router）                   │
│  ├─ フロントエンド（React / Tailwind CSS）  │
│  └─ Route Handler（API / SSE中継）          │
├─────────────────────────────────────────────┤
│  Supabase                                   │
│  ├─ PostgreSQL（DB）                        │
│  └─ Supabase Auth（認証）                   │
├─────────────────────────────────────────────┤
│  Vercel（デプロイ・ホスティング）           │
├─────────────────────────────────────────────┤
│  Groq API（Llama 3.3 70B Versatile）        │
└─────────────────────────────────────────────┘

レイヤー	確定技術	バージョン目安	選定理由
フロントエンド	Next.js（App Router）	v15系	BEと統合できPoC構成が最もシンプル。Vercelデプロイがゼロ設定
バックエンド	Next.js Route Handler	—	FEと同一リポジトリで完結。SSEをネイティブサポート
UI	Tailwind CSS	v4系	ユーティリティファースト・設定最小
DB	Supabase（PostgreSQL）	—	認証まで内包。無料枠・管理UIが使いやすい
認証	Supabase Auth	—	DBと一体化。ゲスト／ログイン分岐も容易
ORM	Prisma	v6系	型安全。Supabase + Next.jsとの相性◎
デプロイ	Vercel	—	GitHubプッシュで自動デプロイ。SSE対応
LLM	Groq API	Llama 3.3 70B	無料枠で運用。OpenAI互換SDK経由で呼び出し

選定理由まとめ

「リポジトリ1本・外部サービス2つ（Supabase + Vercel）で全て完結」 することが最大の採用理由。

Next.js Route Handler がBEを兼任するため、FE/BE間のリポジトリ分離・デプロイ設定が不要
Supabase がDB・認証・管理UIを一括提供するため、認証基盤の別途構築が不要
Vercel がNext.jsのホスティングをゼロ設定で提供。SSEも追加設定なしで動作
Llama 3.3 70B でPoC段階のAPIコストを抑制。モデル切替はAPIクライアントの抽象化で容易に対応可能

リスクと対策

#	リスク	影響度	対策
R1	Vercel無料枠の帯域上限超過	中	初期はPoC・個人利用範囲に抑制。超過時はProプランへ移行
R2	Supabaseプロジェクトの自動停止（非アクティブ時）	中	定期アクセスで維持。本番化時はProプランへ
R3	Next.js Route HandlerでのSSE挙動	低	公式サポート済み。Phase 1 PoCで早期に動作検証する
R4	Groq APIへの単一依存	中	OpenAI互換SDKで抽象化済み。LLMプロバイダーの差し替えが容易な設計
R5	PrismaのEdge Runtime非対応	低	Node.js RuntimeのRoute Handlerで使用するため問題なし

未確定事項（Phase 2以降で確定）

#	事項	確定タイミング
1	状態管理ライブラリ（Zustand / Jotai / Context API）	Phase 2 MVP整備時
2	テストフレームワーク（Vitest / Playwright）	Phase 3 品質強化時
3	ペルソナイラストの配信方法（Vercel Blob / Supabase Storage 等）	Phase 2 MVP整備時
4	モニタリング（Sentry / Vercel Analytics 等）	Phase 4 公開準備時