一般向けサービス

既定：アプリ（SSR・フルスタック）フロントエンド

乗り換える条件

• TanStack StartVercel依存を避けたい、クライアント主体で型安全なルーティングを重視するとき
• React Router（フレームワークモード）Remix系の資産があるとき

代替：画面Elixir（BEAM）

既定は Phoenix LiveView（サーバー主導でリアルタイムUI）。フロントをReactで作りたいとき に乗り換える。

代替：静的サイト・コンテンツ中心フロントエンド

既定は Astro。同じリポジトリでアプリ部分も持つとき に乗り換える。

代替：同一リポジトリ内のフロント⇔バック（TS同士）API設計

既定は Hono RPC。Next.jsの中で完結し、別プロセスのAPIを持たないとき に乗り換える。

成長したら → ECS／Cloud Run（コンテナ）§24

きっかけ

費用の増加、AWSに集約したい

最初からの備え

Next.jsのstandalone出力でコンテナ化できる状態を保つ。Vercel固有の機能への依存を最小にする

ケース別の構成§19

• EC（独自要件が多い）フロント：Next.js＋shadcn/ui
• 自社SaaS（B2B）フロント：Next.js＋shadcn/ui＋TanStack Query
• toCサービス（Web＋モバイル）Web：Next.js
• AI／LLMプロダクトフロント：Next.js（ストリーミング表示）
• 個人開発・MVPTS全部入り：Next.js＋Supabase＋Vercel

既定：モバイルアプリ作成物ごとの言語の決め方

乗り換える条件

• Kotlin／Swift（ネイティブ）端末機能を深く使うとき
• Flutterデザインの一貫性を最優先するとき

既定：クロスプラットフォームモバイルアプリ

乗り換える条件

• Flutterデザインの完全な一貫性を重視し、Dartを受け入れられるとき
• Hotwire NativeRailsで作っていて画面の多くがWebで済むとき

代替：モバイルRuby / Rails

既定は Hotwire Native。ネイティブ体験を重視するとき に乗り換える。

ケース別の構成§19

• toCサービス（Web＋モバイル）モバイル：React Native＋Expo（Expo Router、NativeWind）
• モバイルアプリ単体アプリ：React Native＋Expo（Expo Router、NativeWind）

既定：モバイルアプリ作成物ごとの言語の決め方

乗り換える条件

• Kotlin／Swift（ネイティブ）端末機能を深く使うとき
• Flutterデザインの一貫性を最優先するとき

既定：クロスプラットフォームモバイルアプリ

乗り換える条件

• Flutterデザインの完全な一貫性を重視し、Dartを受け入れられるとき
• Hotwire NativeRailsで作っていて画面の多くがWebで済むとき

ケース別の構成§19

• toCサービス（Web＋モバイル）モバイル：React Native＋Expo（Expo Router、NativeWind）
• モバイルアプリ単体アプリ：React Native＋Expo（Expo Router、NativeWind）

既定：ナビゲーションモバイルアプリ

ケース別の構成§19

• toCサービス（Web＋モバイル）モバイル：React Native＋Expo（Expo Router、NativeWind）
• モバイルアプリ単体アプリ：React Native＋Expo（Expo Router、NativeWind）

既定：スタイルモバイルアプリ

ケース別の構成§19

• toCサービス（Web＋モバイル）モバイル：React Native＋Expo（Expo Router、NativeWind）
• モバイルアプリ単体アプリ：React Native＋Expo（Expo Router、NativeWind）

既定：HTTPフレームワークTypeScript（Node.js）

乗り換える条件

• NestJS10人以上のチームでDI・モジュール構造を強制したいとき
• FastifyNode専用で既存プラグイン資産を使いたいとき

ケース別の構成§19

• 業務システム・社内ツール（TypeScript構成）API：Hono（RPCでフロントと型共有）
• 自社SaaS（B2B）バックエンド：Go（net/http＋sqlc＋pgx）。少人数ならHono
• toCサービス（Web＋モバイル）バックエンド：Hono（またはGo）
• 個人開発・MVPエッジ：Hono＋Cloudflare Workers＋D1／R2

言語別の既定§2-2

選ぶ場面§2-10

• Kubernetes・クラウドのコントロールプレーンを扱う
• 中程度の常時接続＋高スループットgoroutineで並行処理が簡潔に書け、運用も単純
• サービス間のRPCProtocol Buffers周りのツールが充実し、単一バイナリで配りやすい

既定：CLIツール作成物ごとの言語の決め方

乗り換える条件

• Rust起動時間・バイナリサイズ・処理速度を詰めたい
• TypeScript（Bun）社内向けでnpmの資産を使いたい

既定：インフラ系ツール（Kubernetes Operator、Terraformプロバイダ等）作成物ごとの言語の決め方

代替：一般的なWeb API・SaaSのバックエンド作成物ごとの言語の決め方

既定は TypeScript（フロントと1言語に揃う）。3人以上で公開APIを長期運用するとき（§2-10 手順3） に乗り換える。

代替：開発者向けツール（Linter、フォーマッタ、ビルドツール、パーサ）作成物ごとの言語の決め方

既定は Rust。処理が軽く、開発速度を優先したいとき に乗り換える。

代替：データベース・検索エンジン等の基盤ソフト作成物ごとの言語の決め方

既定は Rust。GCの影響が許容できる分散系の制御部分 に乗り換える。

代替：スクリプト・社内の小さな自動化作成物ごとの言語の決め方

既定は TypeScript（Node.jsで直接実行、またはBun）。単一バイナリで配りたいとき に乗り換える。

採用の根拠§22-2

単一バイナリで配布でき、実行時の依存がない。メモリ使用量が小さく、同時接続に強い。Go 1互換性の約束により、長期間コードが壊れにくい。Docker、Kubernetes、TerraformなどインフラOSSの多くがGoで書かれている

「人材が少ないのでは」→ 言語仕様が小さく、他言語経験者なら短期間で読み書きできる

ケース別の構成§19

• 自社SaaS（B2B）バックエンド：Go（net/http＋sqlc＋pgx）。少人数ならHono
• toCサービス（Web＋モバイル）バックエンド：Hono（またはGo）
• リアルタイム系（チャット・通知・共同編集）同時接続が多い（Elixirを採用しない場合）：Go（WebSocket）＋Valkey Pub/Sub
• インフラツール・CLI言語：Go（Cobra、slog）
• 個人開発・MVPGo単体：Go＋PostgreSQL＋htmx

代替：本番ホスティング（PaaS）DB本体とホスティング

既定は Neon（ブランチ機能でPRごとにDBを複製できる）。認証・ストレージ・リアルタイムも一緒に欲しいとき に乗り換える。

費用の注意§25

主な課金の軸

コンピュート（インスタンスサイズ）、月間アクティブユーザー数、データ転送量、ストレージ

膨らみやすい要因

toCでのユーザー増加、Storageからの大量配信

対策

画像や動画の配信はCDN（Cloudflare Images等）に逃がす。規模が見えたら §24 の移行パスを検討する

成長したら → RDS＋Clerk等＋S3§24

きっかけ

費用の増加、細かいチューニングや閉域接続が必要

最初からの備え

標準的なPostgres機能だけを使う。ユーザーIDは自前のテーブルでも保持する

ケース別の構成§19

• toCサービス（Web＋モバイル）DB・認証・ストレージ：Supabase（小〜中規模）／ RDS＋Clerk＋S3（中規模以上）
• 個人開発・MVPTS全部入り：Next.js＋Supabase＋Vercel
• モバイルアプリ単体DB・認証・ストレージ：Supabase

既定：AWSを使うどこで動かすか

乗り換える条件

• Lambdaリクエストがまばらでコールドスタートを許容できるとき
• ECS Express Mode構成を最小にしたい小規模案件

App Runnerは新規受付を終了したため選ばない

ケース別の構成§19

• EC（独自要件が多い）DB：RDS for PostgreSQL
• 自社SaaS（B2B）インフラ：ECS on Fargate＋RDS＋Terraform
• toCサービス（Web＋モバイル）DB・認証・ストレージ：Supabase（小〜中規模）／ RDS＋Clerk＋S3（中規模以上）

既定：マネージド（toC・スタートアップ）認証・認可

乗り換える条件

• Supabase AuthSupabase採用時
• Firebase Authenticationモバイル中心

費用の注意§25

主な課金の軸

月間アクティブユーザー数

膨らみやすい要因

toCでユーザーが急増

対策

規模が見えたら §24 の移行パスを検討する

成長したら → 他のIdP・自前認証§24

きっかけ

費用の増加、要件がClerkの範囲を超えた

最初からの備え

OIDCの標準仕様で連携する。ユーザー情報の正本は自前のDBに持つ

ケース別の構成§19

• 自社SaaS（B2B）認証：Clerk（SSO／SCIMが必要になったらWorkOS）
• toCサービス（Web＋モバイル）DB・認証・ストレージ：Supabase（小〜中規模）／ RDS＋Clerk＋S3（中規模以上）

既定：オブジェクトストレージ（AWS）ファイル・画像・動画

既定：stateの保存IaC

乗り換える条件

• HCP Terraformチームでのplan/applyのレビュー運用が必要なとき

費用の注意§25

主な課金の軸

保存量、リクエスト数、データ転送

膨らみやすい要因

外部への大量配信

対策

CloudFront経由で配信する。配信が多いならR2を検討する

ケース別の構成§19

• toCサービス（Web＋モバイル）DB・認証・ストレージ：Supabase（小〜中規模）／ RDS＋Clerk＋S3（中規模以上）

既定：プッシュ通知メール・通知

ケース別の構成§19

• toCサービス（Web＋モバイル）プッシュ通知：FCM（Expo Notifications）
• モバイルアプリ単体プッシュ通知：FCM（Expo Notifications経由）

既定：プッシュ通知メール・通知

ケース別の構成§19

• toCサービス（Web＋モバイル）プッシュ通知：FCM（Expo Notifications）
• モバイルアプリ単体プッシュ通知：FCM（Expo Notifications経由）

既定：画像変換・配信ファイル・画像・動画

乗り換える条件

• imgproxyセルフホストしたいとき

ケース別の構成§19

• EC（独自要件が多い）画像：Cloudflare Images
• toCサービス（Web＋モバイル）画像・動画：Cloudflare Images／Cloudflare Stream

既定：動画配信ファイル・画像・動画

乗り換える条件

• Mux分析機能やAPIの使い勝手を重視するとき

ケース別の構成§19

• toCサービス（Web＋モバイル）画像・動画：Cloudflare Images／Cloudflare Stream

既定：プロダクト分析・セッションリプレイ・機能フラグプロダクト分析・機能フラグ

乗り換える条件

• Amplitude／Mixpanel分析だけを高度にやりたいとき

既定：Webサイトのアクセス解析プロダクト分析・機能フラグ

乗り換える条件

• Cloudflare Web Analytics静的サイトでCookieなしの最小限の計測だけ欲しいとき
• Plausibleセルフホストもできる軽量な解析が欲しいとき
• GA4取引先やマーケティング担当がGA4のレポートを求めるとき

既定：機能フラグ（単独）プロダクト分析・機能フラグ

乗り換える条件

• Unleashセルフホスト
• OpenFeatureベンダーを差し替えられるようにしたいとき

既定：A/Bテストプロダクト分析・機能フラグ

ケース別の構成§19

• 自社SaaS（B2B）分析・機能フラグ：PostHog
• toCサービス（Web＋モバイル）分析：PostHog
• モバイルアプリ単体分析：PostHog

既定：ビルド・配信モバイルアプリ

ケース別の構成§19

• toCサービス（Web＋モバイル）配信：EAS Build／Submit／Update
• モバイルアプリ単体配信：EAS Build／Submit／Update

既定：ビルド・配信モバイルアプリ

ケース別の構成§19

• toCサービス（Web＋モバイル）配信：EAS Build／Submit／Update
• モバイルアプリ単体配信：EAS Build／Submit／Update

既定：OTA更新モバイルアプリ

ケース別の構成§19

• toCサービス（Web＋モバイル）配信：EAS Build／Submit／Update
• モバイルアプリ単体配信：EAS Build／Submit／Update