AI・LLMプロダクト
LLM API、RAG、エージェント
推奨：TypeScript
推奨
TypeScript
- フロントと同じ言語に揃えられ、API呼び出し中心の処理に向くTypeScript（§2-10 手順2）
構成行を開くと詳細（乗り換える条件・根拠・費用・習熟度）
フロントNext.js（ストリーミング表示）
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
習熟度
AIバックエンドLLM API呼び出し中心ならHono（TS）、埋め込み・ML処理があるならFastAPI（uv、Ruff、Pydantic）
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
習熟度
uv
Ruff
既定：Lint＋フォーマットPython（AI/ML、データ処理が必要な場合に限定）
Pydantic
既定：バリデーションPython（AI/ML、データ処理が必要な場合に限定）
DB・ベクトルPostgreSQL＋pgvector
PostgreSQL
採用の根拠§22-2
OSSでライセンス費用がかからない。AWS、GCP、Azureを含む主要クラウドがすべてマネージド版を提供している。拡張機能（pgvector、pg_bigm）でベクトル検索や日本語全文検索までこなせるため、専用DBを増やさずに済む
「MySQLの方が一般的では」→ 機能・標準SQLへの準拠・拡張性で優位。移行ツールも揃っている
ケース別の構成§19
習熟度
pgvector
ケース別の構成§19
- AI／LLMプロダクトDB・ベクトル：PostgreSQL＋pgvector
長時間処理Temporal、またはInngest
Temporal
選ぶ場面§2-10
- 長時間ワークフローリトライ・待機・状態保持をエンジンに任せる
代替：ジョブPython（AI/ML、データ処理が必要な場合に限定）
既定は Celery。長時間ワークフロー に乗り換える。
習熟度
Inngest
代替：ジョブキューTypeScript（Node.js）
既定は pg-boss（Postgresベース、§4-3）。サーバーレス環境でワークフロー（リトライ・待機・ステップ実行）が必要なとき に乗り換える。
代替：ワークフローキャッシュ・キュー・ストリーム
既定は Temporal（長時間・複雑なもの）。サーバーレス環境 に乗り換える。
監視Sentry＋OpenTelemetry
Sentry
既定：エラー監視監視・可観測性・運用
既定：エラー時のユーザー問い合わせプロダクト分析・機能フラグ
採用の根拠§22-2
障害の検知と原因特定の時間を短縮できる。計装をOpenTelemetryにしておけば、監視サービスを後から変更できる
「費用がかかる」→ 無料枠・サンプリングで調整できる。障害の長期化による損失の方が大きい
費用の注意§25
- 主な課金の軸
- エラー数、トレースのスパン数、セッションリプレイ数、ログ量
- 膨らみやすい要因
- 同じエラーの大量発生、トレースの全量送信
- 対策
- トレースのサンプリング率を設定する。既知のノイズを除外する
ケース別の構成§19
- EC（独自要件が多い）監視：Sentry＋Grafana Cloud
- 自社SaaS（B2B）監視：Sentry＋OpenTelemetry＋Grafana Cloud
- AI／LLMプロダクト監視：Sentry＋OpenTelemetry
- データ基盤・バッチ監視：Sentry（Cron Monitoringで実行漏れを検知）
- モバイルアプリ単体監視：Sentry
習熟度
OpenTelemetry
既定：計装Elixir（BEAM）
既定：計装（トレース・メトリクス）監視・可観測性・運用
採用の根拠§22-2
障害の検知と原因特定の時間を短縮できる。計装をOpenTelemetryにしておけば、監視サービスを後から変更できる
「費用がかかる」→ 無料枠・サンプリングで調整できる。障害の長期化による損失の方が大きい
ケース別の構成§19
- 自社SaaS（B2B）監視：Sentry＋OpenTelemetry＋Grafana Cloud
- AI／LLMプロダクト監視：Sentry＋OpenTelemetry
習熟度
§19-8の構成
構成図 AI／LLMプロダクト
flowchart TB
U["ユーザー"] --> FE["Next.js<br/>ストリーミング表示"]
FE --> API["Hono または FastAPI"]
API --> LLM["LLM API"]
API --> DB[("PostgreSQL＋pgvector")]
API --> WF["Temporal／Inngest<br/>長時間処理"]
API --> LF["Langfuse<br/>評価・トレース"]利用規約・データ取り扱い（学習への利用有無、保存リージョン）を利用者に説明できる状態にしておく。
作り始める
共通の準備
# 言語・ツールのバージョン固定（使う言語だけ）
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アプリを有効化するAI／LLMプロダクト（§19-8）
# Python（ML系の処理がある場合）
uv init ai-api && cd ai-api
uv add "fastapi[standard]" sqlalchemy alembic pgvector httpx
uv add --dev ruff pytest pyright