私たちPlusDivideは2名体制でAIサービス「AmpSell」を含む複数プロダクトを開発しています。少人数で0→1のスピードと品質を両立するには、技術スタックの選定が経営判断と同じくらい重要です。2026年時点で私たちが実際に採用している構成と、その選定理由を全公開します。
スタック選定の優先順位
スタックを選ぶ時、私たちは次の5軸を順番に重視しています。
- ① 開発速度：コード量が少なく、概念がシンプルで、AIが書きやすい
- ② 運用負荷：マネージドサービスを最大限活用し、インフラ管理を最小化
- ③ 型安全性：バグ低減と安全なリファクタリングのために型を一気通貫で通す
- ④ AIアシスタント親和性：Claude Code等のAI開発支援ツールで書きやすい
- ⑤ コミュニティと採用しやすさ：将来エンジニアを増やす時の現実的な選択
重要なのは 「最新だから」「Twitterで話題だから」を選定理由にしない こと。2人で回せるかが軸です。
推奨スタック全体像（2026年5月時点）
私たちが実際に採用している構成は次の通りです。
- フロントエンド：Vite + React 19 + TypeScript + TanStack Router
- UI：Tailwind CSS v4 + shadcn/ui
- バックエンド：Convex（リアルタイムDB + TypeScript関数 + 認可）
- 認証：Clerk
- AI：Claude API（Anthropic）+ OpenAI API + Google Gemini（用途別）
- 決済：Stripe（SaaS課金）
- デプロイ：Vercel
- Lint/Format：Biome
- LP/SEO重視のサイト：Astro（別プロジェクト）
- 監視・ログ：Sentry + Vercel Analytics
フロントエンド: Vite + React 19 + TanStack Router
Next.jsを使わない理由をよく聞かれます。Next.jsはServer Components、キャッシュ、ミドルウェア、App Router/Pages Routerの選択肢など機能が豊富ですが、少人数では意思決定コストが高い。「これはServer Componentで書くべきか？」「キャッシュ戦略はどうするか？」を毎回考えるコストが、プロダクト前進速度を削ります。
SPA中心のSaaS開発なら、Vite + React + TanStack Router の方が概念がシンプルで、コードベースが見通しやすくなります。型安全なルーティングと、明快なファイル分割で、AIアシスタントとの相性も良好です。
SEOが必要なランディングページや採用ページは Astro で別プロジェクトとして作成しています。SPA向きの用途とSEO向きの用途を分けるのが、少人数では効率的です。
UI: Tailwind v4 + shadcn/ui
UIフレームワークの選択はデザイン品質と開発速度のトレードオフですが、shadcn/uiは 「コードをコピペして自分の管理下に置く」 という設計思想が少人数開発と相性が良いです。
Material UI・Ant Designなどのライブラリ型UIフレームワークは、便利な反面、カスタマイズの自由度とビルドサイズで制約が出ます。shadcn/uiは必要なコンポーネントだけ取り込み、自分のコードベースで自由に改変できます。Tailwind v4のCSS変数中心の設計とも相性が良好。
バックエンド: Convex
Convex採用は2026年時点で私たちの最大の意思決定の1つです。理由は4つ。
- リアルタイムDB + TypeScript関数 + 認可ロジックを1プラットフォームに統合：Firebase + Cloud Functions + Firestore Rulesのような分散構成を避けられる
- 型安全性がフロントエンドまで一気通貫：スキーマ・クエリ・ミューテーションの型がフロントで自動補完
- マイグレーション・関数の差分デプロイが自動：CI/CD設定の手間がほぼゼロ
- 少人数のインフラ運用コスト最小化：スケール対応・バックアップ・モニタリング全部マネージド
Supabase・Firebaseと比べた結果、TypeScriptネイティブ性と型安全のアドバンテージでConvexを選びました。ただしConvexはまだ採用人材が少ない・ベンダーロックインが強いという短所もあり、長期的にはここをモニタリングしています。
認証: Clerk
認証は自前実装せず、Clerkに任せています。Google OAuth・パスワード認証・MFA・組織管理・Webhookまで、本来1〜2ヶ月かかる実装が数日でセットアップできます。Convexとの連携も標準対応。
コスト感は無料枠（月間アクティブユーザー5000まで）が広く、有償プラン（$25/月〜）も小規模SaaSなら十分許容範囲。少人数では「認証を自前で持つ価値」は薄く、Clerkのようなマネージドサービスに任せて開発リソースを本業に集中するのが合理的です。
AI: 1モデル依存しない設計
AIプロバイダーは1つに絞らず、用途別に使い分けています。
- Claude（Anthropic）：長文処理・複雑タスク・コード生成。Claude Codeにも使用
- OpenAI（GPT-4o系）：安価で多用途、リアルタイム音声・画像入力
- Google Gemini：画像・動画・マルチモーダル系タスク、長コンテキスト処理
重要なのはコードレベルで プロンプト層を抽象化して切り替えコストを下げる こと。直接APIを叩くのではなく、社内ラッパーを通すことで、モデル変更時の影響範囲を最小化しています。AI Gateway（Vercel AI Gateway等）の利用も検討対象です。
デプロイ: Vercel + Convex
フロントエンドはVercelに自動デプロイ、バックエンドはConvexに自動デプロイ。GitHub連携を組めば、コミットpushだけでPreview/Production環境が自動更新されます。
Vercel固有機能（Edge Functions・Analytics・Speed Insights）は補助的に使い、コア機能はConvexに集約。これでインフラ管理にかかる工数がほぼゼロになります。
Lint/Format: Biome
ESLint + Prettierの伝統的構成より、Biomeの方が 設定がシンプル・実行が速い・1ツールで完結 という3点で少人数向きです。設定ファイルが1つで済み、新メンバーオンボーディングも早くなります。
採用していない/慎重に検討した技術
参考までに、採用しなかった/採用に慎重な技術と理由：
- Next.js：少人数では意思決定コストが高い（前述）
- tRPC：Convexで型安全が解決するため不要
- Redux / Zustand：ConvexのリアルタイムDBがあれば状態管理がシンプルになる
- Kubernetes / 自前インフラ：マネージドで全部回すのが少人数の鉄則
- マイクロサービス：2人で複数サービスを運用するのはオーバーキル
まとめ: 2人で回せる構成を選ぶ
2名スタートアップが採るべき技術スタックの本質は、「最新の技術を使うこと」ではなく 「2人で運用コストを膨らませずに回せること」 です。マネージドサービスを最大限活用し、概念をシンプルに保ち、型安全で守る。この方針を貫いた結果、PlusDivideは2名でも複数プロダクトを並行運用できています。
この技術スタックで0→1を回す具体的な順序は 0→1事業の型 に、PoCを本番に届ける設計は PoCを本番に届ける3つの条件 に、自社事例は 営業AIで0→1を回す方法（AmpSell事例） にまとめています。
FAQ
よくある質問
2名のスタートアップでAIアプリを開発するなら何を選びますか？
フロントエンドはVite + React 19 + TypeScript + TanStack Router、UIはTailwind CSS v4 + shadcn/ui、バックエンドはConvex（リアルタイムDB+関数+認可）、認証はClerk、AIはClaude API / OpenAI API、デプロイはVercel、Linterはbiomeが2026年時点での推奨スタックです。インフラ管理を最小化し、開発に集中できる構成を選びます。
なぜNext.jsを使わないのですか？
Server Components・キャッシュ・ミドルウェアなど機能が豊富な反面、少人数開発では設計上の選択肢が多すぎて意思決定コストが高いと判断しているためです。SaaS型のSPA中心の開発はVite+React+TanStack Routerの方が概念がシンプルで速度が出ます。SEOが必要なLPはAstroで別プロジェクトとして作成しています。
Convexを採用する理由は？
①リアルタイムDB+TypeScript関数+認可ロジックを1つのプラットフォームに統合できる、②型安全がフロントエンドまで一気通貫、③スキーマ・マイグレーション・関数の差分デプロイが自動、④少人数ではインフラ運用コストを最小化することが最重要だから、の4点です。FirebaseやSupabaseと比べても、型安全性とTypeScriptネイティブ性で優位と判断しています。
AIアプリで使うLLM APIはどれを選びますか？
用途別に使い分けています。長文・複雑タスク・コード生成はClaude（Anthropic）、安価で多用途はGPT-4o系（OpenAI）、画像・マルチモーダル系はGoogle Gemini、というのが2026年時点の使い分けです。重要なのは「1つのモデルに依存しない」設計で、プロンプト層を抽象化して切り替えコストを下げています。
スタックを選ぶ時の優先順位は何ですか？
少人数では①開発速度（コード量・概念の少なさ）、②運用負荷（マネージドサービスへの依存度）、③型安全性（バグ低減・リファクタの安全性）、④AIアシスタント親和性（Claude Code等で書きやすいか）、⑤コミュニティと採用しやすさ、の順で重視します。「最新だから」より「2人で回せるか」が選定基準の主軸です。