リアルタイム通信
チャット、通知、共同編集
推奨：TypeScript
推奨
TypeScript
構成行を開くと詳細（乗り換える条件・根拠・費用・習熟度）
言語TypeScript
TypeScript
言語別の既定§2-1
選ぶ場面§2-10
- 実行環境がエッジ（Cloudflare Workers等）
- DBの読み書きと業務ロジックが中心ボトルネックはDB。言語の性能差はほぼ効かないので、開発速度とチームで選ぶ
- 外部APIの待ち時間が中心非同期I/Oの書きやすさと、フロントとの型共有
- サーバーレスのイベント処理起動が速く、AWS SDKが充実。起動速度を詰めるならGo
- GraphQLサーバーGraphQLのツール群がTypeScript中心
代替：CRUD中心のWebアプリ・管理画面作成物ごとの言語の決め方
既定は Rails（画面の多い業務システムを最も速く作れる）。外部API連携が中心、またはReactで画面を作り込みたいとき に乗り換える。
代替：CLIツール作成物ごとの言語の決め方
既定は Go。社内向けでnpmの資産を使いたい に乗り換える。
代替：ブラウザ内の重い処理（画像・動画処理、暗号、大量データの解析）作成物ごとの言語の決め方
既定は Rust → WebAssembly。処理がそこまで重くないとき に乗り換える。
採用の根拠§22-2
GitHubのOctoverse 2025（https://octoverse.github.com/）で、2025年8月に月間コントリビューター数でPythonとJavaScriptを抜き最も使われる言語になった。Next.jsやAstroなど主要フレームワークが既定でTypeScriptのプロジェクトを生成する。型によって多くの不具合をリリース前に検出でき、AIによるコード生成の誤りも型チェックで拾いやすい。フロントとバックエンドを1言語で書ける
「JavaScriptより難しいのでは」→ 型は段階的に導入でき、エディタ補完が効くぶん学習もしやすい
ケース別の構成§19
習熟度
フロントNext.js（App Router）
Next.js
既定：アプリ（SSR・フルスタック）フロントエンド
乗り換える条件
- TanStack StartVercel依存を避けたい、クライアント主体で型安全なルーティングを重視するとき
- React Router（フレームワークモード）Remix系の資産があるとき
代替：画面Elixir（BEAM）
既定は Phoenix LiveView（サーバー主導でリアルタイムUI）。フロントをReactで作りたいとき に乗り換える。
成長したら → 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
習熟度
バックエンドHono（軽量・どこでも動く・型安全なRPC）
Hono
既定：HTTPフレームワークTypeScript（Node.js）
乗り換える条件
ケース別の構成§19
習熟度
DBPostgreSQL
PostgreSQL
採用の根拠§22-2
OSSでライセンス費用がかからない。AWS、GCP、Azureを含む主要クラウドがすべてマネージド版を提供している。拡張機能（pgvector、pg_bigm）でベクトル検索や日本語全文検索までこなせるため、専用DBを増やさずに済む
「MySQLの方が一般的では」→ 機能・標準SQLへの準拠・拡張性で優位。移行ツールも揃っている
ケース別の構成§19
習熟度
データアクセスDrizzle（SQLに近い・軽い・エッジ対応）
Drizzle
既定：ORM／クエリTypeScript（Node.js）
乗り換える条件
ケース別の構成§19
- 業務システム・社内ツール（TypeScript構成）DB：PostgreSQL＋Drizzle
習熟度
ジョブpg-boss（Postgresベース、§4-3）
pg-boss
既定：ジョブキューTypeScript（Node.js）
乗り換える条件
- BullMQ（Redis/Valkey）秒間数百件を超える、またはValkeyが既にあるとき（§23-1）
- Inngest／Trigger.devサーバーレス環境でワークフロー（リトライ・待機・ステップ実行）が必要なとき
テストVitest
インフラRender
Render
代替：デプロイRuby / Rails
既定は Kamal。サーバー管理をしたくないとき に乗り換える。
ケース別の構成§19
- 業務システム・社内ツール（Rails構成）デプロイ：Kamal（オンプレVM・VPS）またはRender
- 業務システム・社内ツール（TypeScript構成）デプロイ：Render（AWSならECS on Fargate、オンプレならコンテナでVM）
- データ基盤・バッチ実行：RenderのCron Job（AWSならECSのスケジュールタスク）
監視Sentry
Sentry
既定：エラー監視監視・可観測性・運用
既定：エラー時のユーザー問い合わせプロダクト分析・機能フラグ
採用の根拠§22-2
障害の検知と原因特定の時間を短縮できる。計装をOpenTelemetryにしておけば、監視サービスを後から変更できる
「費用がかかる」→ 無料枠・サンプリングで調整できる。障害の長期化による損失の方が大きい
費用の注意§25
- 主な課金の軸
- エラー数、トレースのスパン数、セッションリプレイ数、ログ量
- 膨らみやすい要因
- 同じエラーの大量発生、トレースの全量送信
- 対策
- トレースのサンプリング率を設定する。既知のノイズを除外する
ケース別の構成§19
- EC（独自要件が多い）監視：Sentry＋Grafana Cloud
- 自社SaaS（B2B）監視：Sentry＋OpenTelemetry＋Grafana Cloud
- AI／LLMプロダクト監視：Sentry＋OpenTelemetry
- データ基盤・バッチ監視：Sentry（Cron Monitoringで実行漏れを検知）
- モバイルアプリ単体監視：Sentry
習熟度
CIGitHub Actions
リアルタイムCloudflare Durable Objects
Cloudflare Durable Objects
ケース別の構成§19
- リアルタイム系（チャット・通知・共同編集）TS・マネージド：Cloudflare Durable Objects
共同編集Yjs（マネージドならLiveblocks）
Yjs
ケース別の構成§19
- リアルタイム系（チャット・通知・共同編集）共同編集：Yjs（マネージドならLiveblocks）
Liveblocks
片方向の配信Server-Sent Events
Server-Sent Events
ケース別の構成§19
- リアルタイム系（チャット・通知・共同編集）片方向で足りる：Server-Sent Events
構成図 リアルタイム系（チャット・通知・共同編集）
flowchart TB
C1["クライアント"] -- "WebSocket" --> PX["Phoenix Channels<br/>＋Presence"]
C2["クライアント"] -- "WebSocket" --> PX
PX --> PS["Phoenix PubSub<br/>ノード間配信"]
PX --> DB[("PostgreSQL")]作り始める
共通の準備
# 言語・ツールのバージョン固定（使う言語だけ）
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アプリを有効化するリアルタイム・Elixir（§19-9）
mix archive.install hex phx_new
mix phx.new app
cd app && mix ecto.create