EC

GitHubのOctoverse 2025（https://octoverse.github.com/）で、2025年8月に月間コントリビューター数でPythonとJavaScriptを抜き最も使われる言語になった。Next.jsやAstroなど主要フレームワークが既定でTypeScriptのプロジェクトを生成する。型によって多くの不具合をリリース前に検出でき、AIによるコード生成の誤りも型チェックで拾いやすい。フロントとバックエンドを1言語で書ける

「JavaScriptより難しいのでは」→ 型は段階的に導入でき、エディタ補完が効くぶん学習もしやすい

成長したら → 一部をGo／Rustに切り出し§24

きっかけ: CPU負荷・レイテンシがボトルネックになった
最初からの備え: APIをOpenAPIで定義しておき、実装言語を差し替えられるようにする

ケース別の構成§19

EC（独自要件が多い）コマースエンジン：Medusa（TypeScript）
AI／LLMプロダクトAIバックエンド：LLM API呼び出し中心ならHono（TS）、埋め込み・ML処理があるならFastAPI（uv、Ruff、Pydantic）

習熟度

フロントNext.js＋shadcn/ui

Next.js

公式サイト ↗

既定：アプリ（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

習熟度

shadcn/ui

公式サイト ↗

既定：UIコンポーネントフロントエンド

乗り換える条件

Mantineコンポーネントを一式そのまま使いたい管理画面
MUIMaterial Design指定のとき

ケース別の構成§19

EC（独自要件が多い）フロント：Next.js＋shadcn/ui
業務システム・社内ツール（TypeScript構成）UI：shadcn/ui＋TanStack Table（編集が重いならAG Grid）
自社SaaS（B2B）フロント：Next.js＋shadcn/ui＋TanStack Query

DBRDS for PostgreSQL

RDS

公式サイト ↗

既定：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（中規模以上）

決済Stripe＋KOMOJU（国内決済手段）

Stripe

公式サイト ↗

既定：カード決済・サブスク（汎用）決済

採用の根拠§22-2

カード情報を自社システムで扱わずに済み、PCI DSSの対応範囲を最小にできる。国内の決済手段（コンビニ払い等）はKOMOJUで補える

「手数料が高い」→ 自前でカード情報を扱う場合のセキュリティ対策・監査コストと比べて判断する

費用の注意§25

主な課金の軸: 決済額に対する手数料率
対策: 決済手段ごとの料率を事前に確認する

ケース別の構成§19

EC（独自要件が多い）決済：Stripe＋KOMOJU（国内決済手段）
自社SaaS（B2B）課金：Stripe Billing

習熟度

KOMOJU

公式サイト ↗

既定：国内の決済手段（コンビニ、銀行振込、PayPay等）が必要決済

乗り換える条件

GMOペイメントゲートウェイ大手・既存契約があるとき
PAY.JPカード中心で国内サポート重視

採用の根拠§22-2

カード情報を自社システムで扱わずに済み、PCI DSSの対応範囲を最小にできる。国内の決済手段（コンビニ払い等）はKOMOJUで補える

「手数料が高い」→ 自前でカード情報を扱う場合のセキュリティ対策・監査コストと比べて判断する

費用の注意§25

主な課金の軸: 決済額に対する手数料率
対策: 決済手段ごとの料率を事前に確認する

ケース別の構成§19

EC（独自要件が多い）決済：Stripe＋KOMOJU（国内決済手段）

習熟度

検索Meilisearch

Meilisearch

公式サイト ↗

既定：サイト内検索・EC商品検索検索

乗り換える条件

Typesense型付きのスキーマ定義と高速なファセット検索を優先するとき

ケース別の構成§19

EC（独自要件が多い）検索：Meilisearch

習熟度

画像Cloudflare Images

Cloudflare Images

公式サイト ↗

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

乗り換える条件

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

ケース別の構成§19

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

メールAmazon SES＋React Email

Amazon SES

公式サイト ↗

既定：トランザクションメール（AWS）メール・通知

ケース別の構成§19

EC（独自要件が多い）メール：Amazon SES＋React Email

React Email

公式サイト ↗

既定：メールテンプレートメール・通知

乗り換える条件

MJMLReact以外の環境

ケース別の構成§19

EC（独自要件が多い）メール：Amazon SES＋React Email

インフラECS on Fargate、Cloudflare（CDN・WAF・Waiting Room）

ECS on Fargate

公式サイト ↗

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

乗り換える条件

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

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

費用の注意§25

主な課金の軸: vCPU・メモリの稼働時間
膨らみやすい要因: 過大なタスクサイズ、最小タスク数の設定しすぎ
対策: 実測に合わせて調整する。検証環境はSpotを使う

ケース別の構成§19

EC（独自要件が多い）インフラ：ECS on Fargate、Cloudflare（CDN・WAF・Waiting Room）
業務システム・社内ツール（TypeScript構成）デプロイ：Render（AWSならECS on Fargate、オンプレならコンテナでVM）
自社SaaS（B2B）インフラ：ECS on Fargate＋RDS＋Terraform
データ基盤・バッチ実行：RenderのCron Job（AWSならECSのスケジュールタスク）

習熟度

Cloudflare

公式サイト ↗

既定：CDNネットワーク・エッジ

乗り換える条件

CloudFrontAWS内で完結、S3オリジン中心のとき

既定：証明書ネットワーク・エッジ

Let's Encrypt（Kamalは自動対応）

既定：レート制限セキュリティ

乗り換える条件

アプリ側Valkey/Redisでトークンバケット

採用の根拠§22-2

DNS、CDN、WAF、DDoS対策、アクセス集中時の入場制御（Waiting Room）を1か所で管理できる

「障害時に全部止まるのでは」→ オリジンへの直接経路と切り戻し手順をランブックに用意する

ケース別の構成§19

EC（独自要件が多い）インフラ：ECS on Fargate、Cloudflare（CDN・WAF・Waiting Room）

習熟度

Cloudflare Waiting Room

公式サイト ↗

既定：アクセス集中対策ネットワーク・エッジ

ケース別の構成§19

EC（独自要件が多い）インフラ：ECS on Fargate、Cloudflare（CDN・WAF・Waiting Room）
高トラフィック（セール・チケット販売）入場制御：Cloudflare Waiting Room

監視Sentry＋Grafana Cloud

Sentry

公式サイト ↗

既定：エラー監視監視・可観測性・運用

既定：RUM（実ユーザーの表示速度）監視・可観測性・運用

乗り換える条件

Vercel Speed InsightsVercel採用時

既定：エラー時のユーザー問い合わせプロダクト分析・機能フラグ

採用の根拠§22-2

障害の検知と原因特定の時間を短縮できる。計装をOpenTelemetryにしておけば、監視サービスを後から変更できる

「費用がかかる」→ 無料枠・サンプリングで調整できる。障害の長期化による損失の方が大きい

費用の注意§25

主な課金の軸: エラー数、トレースのスパン数、セッションリプレイ数、ログ量
膨らみやすい要因: 同じエラーの大量発生、トレースの全量送信
対策: トレースのサンプリング率を設定する。既知のノイズを除外する

ケース別の構成§19

EC（独自要件が多い）監視：Sentry＋Grafana Cloud
自社SaaS（B2B）監視：Sentry＋OpenTelemetry＋Grafana Cloud
AI／LLMプロダクト監視：Sentry＋OpenTelemetry
データ基盤・バッチ監視：Sentry（Cron Monitoringで実行漏れを検知）
モバイルアプリ単体監視：Sentry

習熟度

Grafana Cloud

公式サイト ↗

既定：可観測性基盤（コスト重視）監視・可観測性・運用

乗り換える条件

セルフホストのGrafanaスタックオンプレ要件

ケース別の構成§19

EC（独自要件が多い）監視：Sentry＋Grafana Cloud
自社SaaS（B2B）監視：Sentry＋OpenTelemetry＋Grafana Cloud

§19-3の構成

構成図 EC（標準）

flowchart TB
  U["購入者"] --> S["Shopify<br/>Liquid テーマ"]
  S --> P["Shopify Payments"]
  S --> A["Shopify アプリ／Functions"]

構成図 EC（独自要件が多い）

flowchart TB
  U["購入者"] --> CF["Cloudflare<br/>CDN・WAF・Waiting Room"] --> N["Next.js"]
  N --> M["Medusa API<br/>ECS Fargate"]
  N --> IMG["Cloudflare Images"]
  M --> DB[("PostgreSQL<br/>RDS")]
  M --> MS["Meilisearch"]
  M --> PAY["Stripe／KOMOJU"]
  M --> SES["Amazon SES"]

作り始める

共通の準備

# 言語・ツールのバージョン固定（使う言語だけ）
mise use node@lts pnpm@latest
mise use go@latest
mise use ruby@latest
mise use python@latest uv@latest

# Gitフックと依存更新
pnpm add -D lefthook && pnpm exec lefthook install
# renovate.json を置き、GitHubでRenovateアプリを有効化する

EC・独自要件（§19-3）

npx create-medusa-app@latest
pnpm create next-app@latest storefront

次に読む

§7 決済 §19-12 高トラフィック（セール・チケット販売）§23 判断の目安となる数値 §24 成長したときの移行パス §25 費用の考え方