🛠️ 現場でのシステム開発 SvelteKit編

個人開発から法人チーム開発へ — Amazon Aurora構成・GitHub Flow・8ステップロードマップ

最終更新: 2026-05-01

01 ゴール — 個人開発から法人チーム開発へ

このページの読者の前提

個人で SvelteKit × Amazon Aurora を使って開発中
将来的に法人向けシステムを作る予定（社内ツール・SaaS・受託）
チーム開発（2〜50人規模）の工程・ツール選定・落とし穴を知りたい
「教科書の理想」より「現場の妥協点と実態」が欲しい

今日のゴールは明確です。個人の小さな SvelteKit プロジェクトを、10〜50人のチームでも壊れない開発体制に拡張するための道筋を、全工程・具体コスト・実際の失敗パターン込みで提示します。規模が変わるとツールだけでなく「思考の作法」も変わります。それを段階的に可視化するのがこのページの目的です。

👤

個人（1人）

〜POC/個人SaaS

SvelteKit + Vercel
Drizzle ORM
GitHub Actions 簡易
Aurora Serverless v2（min 0）
月コスト: $10〜$50

👥

小規模（2〜5人）

スタートアップ初期

Turborepo + pnpm workspaces
GitHub Flow + PR レビュー
Doppler（シークレット）
Aurora + RDS Proxy 検討
月コスト: $100〜$300

🏢

中規模（10〜20人）

スタートアップ成長期

branch protection rules 必須化
GitHub Environments（prod 承認）
Playwright e2e CI 組み込み
Aurora Blue/Green デプロイ
月コスト: $500〜$2,000

🏗️

大規模（30〜50人）

法人・エンタープライズ

Trunk-based Development
feature flag（LaunchDarkly等）
AWS Secrets Manager
SRE チーム / on-call 体制
月コスト: $3,000〜$20,000+

⚠️ 現場の落とし穴: 規模感のズレ

「将来は大規模になるから最初から完璧な構成で」という発想が最も危険です。現場の実態は「必要になったタイミングで段階的に導入」がほぼ100%。RDS Proxy は月 $86〜かかります。1人の個人開発段階で入れても赤字になるだけです。

02 個人 vs チーム — 9軸工程対比

同じ SvelteKit プロジェクトでも、規模が変わると9つの工程が根本的に変わります。「個人なら省略してよいもの」と「小規模でも早期に導入すべきもの」の区別が重要です。

工程	個人（1人）	小規模（2〜5人）	中〜大規模（10〜50人）
要件定義	自分の頭の中。Notionメモ程度	GitHub Issues + ラベル管理。口頭確認が多い	PRD文書化（Linear/Jira）、スプリント計画、DoD定義
ブランチ戦略	main 直 push。ブランチなし	GitHub Flow（feature→PR→main）	GitHub Flow + branch protection / Trunk-based（20人以上）
レビュー	なし（自己確認のみ）	PR レビュー 1名必須。非同期で	コードオーナー制、レビュー SLA（24h以内）、セキュリティレビュー
CI/CD	Vercel の自動デプロイのみ	GitHub Actions（lint + build + vitest）	Playwright e2e、prod 手動承認、キャッシュ最適化
テスト	手動確認のみ。テストなし	vitest でユニット。カバレッジ 50%〜	unit + integration + e2e（Playwright）。カバレッジ 80%+
デプロイ	git push したら自動。環境は本番のみ	PR Preview → staging → production の3環境	Blue/Green、カナリア、環境別シークレット、承認フロー
監視	Vercel Dashboard の確認程度	Sentry エラー追跡。Uptime Robot	Datadog/New Relic、SLO/SLA 定義、アラート閾値設定
オンコール	自分が気づいたら直す	メール通知→Slack。ローテなし	PagerDuty、週次ローテ、インシデント振り返り（blameless）
ドキュメント	README.md 1枚あれば十分	Notion wiki + ADR（アーキテクチャ決定記録）	OpenAPI、Storybook、ランブック、アーキテクチャ図（Mermaid）

📌 2〜5人フェーズで早期投資すべき3点

①GitHub Flow + PR レビュー（コスト: ゼロ、効果: 最大）、②vitest の導入（後付けは辛い）、③Sentry エラー追跡（Free プランで十分）。逆にオンコール体制・Jira・Datadog は10人未満では重すぎます。

03 SvelteKit特有のチーム開発

React + Next.js と比べて SvelteKit はエコシステムが小さい分、チームでの約束事を早期に決めないと設計がバラける。7つのポイントを現場の判断基準付きで解説します。

1
モノレポ構成

Turborepo + pnpm workspaces

プロはここでまず「どこまで共有するか」を決める。推奨構成は apps/web（SvelteKit本体）、apps/api（独立REST API、10人〜で分離）、packages/types（zodスキーマ + 型）、packages/db（Drizzle定義）、packages/ui（共通コンポーネント）。pnpm の workspace:* プロトコルでパッケージ間参照。

💡 現場のおすすめ: 個人〜2人でもこの構成を早めに作っておく。後から分割は地獄。Turborepo の Remote Cache は Vercel 無料枠で使える。
2
shared packages で型共有

zod × 型の単一ソース化

プロは「型定義が2箇所にある」状態を最も嫌う。packages/types に zod スキーマを集約し、z.infer<typeof schema> で TypeScript 型を自動生成する。フロント・バック・DBの3層で同じ型が使えるため、「APIレスポンスの型とフロントの型がズレる」バグが構造的に防げる。

💡 現場のおすすめ: zod の parse と safeParse の使い分けをチーム決め打ちしておく。APIエントリポイントでは必ず parse、内部ロジックでは safeParse が現場標準。
3
API設計の境界線

+server.ts vs 別REST API分離

プロは規模に応じてここを判断する。個人〜5人: src/routes/api/[endpoint]/+server.ts で十分。デプロイも一体、型も共有しやすい。10人以上で「モバイルアプリも作る」「別チームが APIを使う」「トラフィックがフロントと独立」のどれかに当たったら apps/api として Hono か Fastify で分離を検討する。

💡 現場のおすすめ: 早期分離は開発速度を著しく落とす。「5人で月500万ARR超えたら分離を検討」くらいのラインが現実的。

デプロイ先とのアダプター整合

adapter選定 — Aurora直接接続ならadapter-node必須

プロはまずデプロイ先を固定してからアダプターを選ぶ。逆順は詰む。

adapter	デプロイ先	Aurora直接接続	用途
adapter-node	AWS EC2/ECS/Lambda	✅ 可（同VPC）	本番Aurora接続の主役
adapter-vercel	Vercel	△ Data API or Proxy経由	初速重視・個人〜小規模
adapter-cloudflare	Cloudflare Pages	❌ VPC外（Hyperdrive経由）	エッジ配信・静的寄り
adapter-static	CDN/S3	❌ サーバーなし	LP・ドキュメント

💡 現場のおすすめ: Aurora を使うなら最初から adapter-node + AWS を選択。後から Vercel → AWS 移行はストレスが高い。

5
認証の標準化

hooks.server.ts で認証を一元管理

プロはここで認証ライブラリをチーム決め打ちにして event.locals に型定義を入れる。Lucia Auth（フルコントロール派・DBセッション）か Better Auth（OAuth/Magic Link も楽な新興）かを最初に選択。どちらも src/app.d.ts の Locals インタフェースに user: User | null を定義し全ページで使える状態にする。

💡 現場のおすすめ: 2026年現在は Better Auth が勢いあり。Lucia は v3 でスコープを絞った。SaaS で Google/GitHub ログインを早期に入れるなら Better Auth が楽。
6
フォームの型安全化

superforms で actions を統一

プロはフォームバリデーションを各ページで書かず、sveltekit-superforms + zod の組み合わせを全チームで使うことに決める。+page.server.ts の actions で superValidate を呼ぶパターンが統一されると、コードレビューで「バリデーションが漏れている」バグがほぼ撲滅できる。クライアントサイドエラー表示も自動で型安全になる。

💡 現場のおすすめ: superforms は学習コスト2〜3時間。5人以上のチームなら必須投資。個人でも入れておいて損はない。
7
環境変数の使い分け

$env 4種の使い分け基準

SvelteKit の $env は4種類あり、誤用するとシークレットがブラウザに漏洩する。プロはここで明確なルールを決める: $env/static/private（ビルド時確定・サーバーのみ、基本これ）、$env/dynamic/private（起動時環境変数・Secrets Manager取得時）、$env/static/public（ビルド時確定・公開OK）、$env/dynamic/public（ランタイム・公開OK）。

⚠️ 落とし穴: $env/dynamic/private を使い忘れて Secrets Manager の値をビルド時に焼き込もうとして詰まる事案が頻発。Aurora の接続文字列はランタイムで注入するため dynamic/private 必須。

04 Amazon Aurora運用 — 個人〜法人の現場実態

Aurora は「高性能だが高コスト」のイメージがありますが、Serverless v2 の ACU=0 対応（2024年11月）以降、個人開発でも現実的な選択肢になっています。コストの罠と運用のコツを現場目線で解説します。

選定基準

Aurora vs RDS PostgreSQL — どちらを選ぶか

Aurora は独自の分散ストレージを持ち、RDS PostgreSQL 比で最大3倍のスループットとフェイルオーバー30秒以内を実現する。ただしコストは 20〜30% 高い。判断基準: 個人〜小規模初期はRDS PostgreSQL が安い（db.t3.micro で月 $15〜）。Read Replica でのスケールが必要、Serverless v2 の ACU=0 停止で開発コスト削減したい、フェイルオーバー要件が厳しい場合は Aurora に移行する。

比較軸	RDS PostgreSQL	Aurora PostgreSQL
最小月額（東京）	$13〜（t3.micro）	$0〜（Serverless v2 min 0）
フェイルオーバー	60〜120秒	30秒以内
スループット	標準	最大3倍
Serverless対応	なし	v2（ACU=0可）

2
Aurora Serverless v2 ACU=0運用

2024年11月解禁 — dev環境は無料に近くできる

ACU（Aurora Capacity Unit）を 0 まで下げられるようになり、使わない夜間は停止できる。現場標準の設定値: dev環境は min 0 / max 1 ACU（月 $0〜$10程度）、stg は min 0.5 / max 4 ACU、prd は min 2 / max 16 ACU。1 ACU = 約 $0.12〜$0.20/h（東京）。

⚠️ 落とし穴: 接続が残っていると ACU=0 に停止しない。DB接続を明示的にクローズするコードが必要。Lambda/サーバーレス環境では特に注意。アイドルタイムアウトを設定するか、接続プールのmaxIdleを短くする。

💡 Cold start: ACU=0 からの起動は 15〜30秒かかる。dev/stg では許容できるが prd は min 2 以上を推奨。

マイグレーション

ツール選定 — Drizzle ORM を新規で推奨

プロはここでチームの「SQL書ける度」と「型安全の優先度」でツールを決める。

ツール	バンドルサイズ	型安全	おすすめ対象
Drizzle ORM	7KB	◎	新規プロジェクト全般（推奨）
Prisma	大（エンジン別）	○	チーム規模大・既存資産あり
Kysely	小	◎	SQL書きたい・型安全重視
Knex	中	△	既存レガシー維持のみ

接続管理

3パターン — SvelteKit × Aurora の接続設計

プロはデプロイ先と規模で接続パターンを決める。

パターン	月額目安	適用条件	注意点
直接接続	$0追加なし	adapter-node + 同VPC	接続数上限に注意（max 5000）
RDS Proxy	$86〜（min 8 ACU）	Lambda多数・接続数爆発時	個人には高い
Aurora Data API	$0.35/百万req	VPC外・Serverless向け	レイテンシが高め（10〜50ms追加）

5
スキーマ変更のゼロダウンタイム

Blue/Green デプロイメント — 1クリックで安全なDDL

Aurora の Blue/Green デプロイは AWS コンソールから1クリックで Green 環境を複製 → DDL 適用 → スイッチオーバー（50秒以内）という手順で無停止スキーマ変更が可能。本番での ALTER TABLE を手動実行する必要がなくなる。

⚠️ 落とし穴: カラム名・テーブル名の変更（RENAME）はレプリケーション切断を引き起こす。新カラムを追加→データコピー→旧カラム削除の3ステップを踏むこと。これを知らずに RENAME して本番ダウンした事例が現場では珍しくない。
6
コスト削減

個人・小規模向けの Aurora コスト最適化

Serverless v2 min ACU=0 で夜間停止させると dev 環境は月 $5〜$15 程度に抑えられる。I/O-Optimized モード（ストレージ I/O 料金なし）は月 I/O コストが Aurora 料金の 25% 超えたら有利になるが、低トラフィック初期は逆に高くなるので注意。

環境 ACU設定月額目安（東京）備考
dev min 0 / max 1 $5〜$15 使用時のみ課金
stg min 0.5 / max 4 $30〜$80 Cold start 5〜10秒
prd min 2 / max 16 $150〜$500 Cold start なし

環境	ACU設定	月額目安（東京）	備考
dev	min 0 / max 1	$5〜$15	使用時のみ課金
stg	min 0.5 / max 4	$30〜$80	Cold start 5〜10秒
prd	min 2 / max 16	$150〜$500	Cold start なし

05 ブランチ戦略の現場実態

ブランチ戦略は「教科書で最善のもの」を選ぶより「チームが実際に守れるもの」を選ぶことが重要です。現場の実態と規模別の選択基準を解説します。

1
現場の9割

GitHub Flow — シンプルさが最強

プロはまずこれを選ぶ。feature/issue-123-add-login のような命名でブランチを切り、PR を出して Squash merge する。main は常にデプロイ可能な状態を保つ。Vercel / Cloudflare Pages の Preview Deploy との相性が抜群で、PR URL を確認してからマージというフローが自然にできる。

💡 SvelteKit との相性: svelte-check を CI に組み込むと PR Preview で型エラーを早期検出できる。merge 前に型安全を保証できるのは SvelteKit の強みを最大化する。
2
採用しない理由

Git Flow — SvelteKit 新規案件では選ばない

develop ブランチと main ブランチを分けるスタイル。SIer・金融・組み込み系に残存している。問題は develop と main の差分が長期化するにつれコンフリクト地獄になること。SvelteKit のような CI/CD 前提のフレームワークで Git Flow を採用する現場は2026年現在ほぼ存在しない。

⚠️ 既存の Git Flow プロジェクトを引き継いだ場合: 急に変えず、まず release ブランチを廃止して develop → main 直マージ化するステップを踏む。急な変更はチームが混乱する。
3
Google/Meta式

Trunk-based Development — 20人以上で検討

ブランチ寿命を1〜2日に制限し、feature flag で未完成の機能を本番コードに含めたまま OFF にしておく戦略。Google・Meta・Netflix が採用。CI/CD が完全に整備されていることが前提。10人以下で導入するとfeature flag の管理コストと、CI が壊れた時のブロッキングが大問題になる。

💡 feature flag ツール: LaunchDarkly（$10/人〜）、Statsig（無料枠あり）、自前実装（DB + 環境変数）。SvelteKit では hooks.server.ts で flag を注入するのが定番。
4
環境別ブランチが必要な場合

GitLab Flow — 環境分離が複雑な場合のみ

main / staging / production の環境別ブランチを持ち、上流から下流にマージしていくモデル。「staging でしか確認できない設定がある」「production にのみ適用するパッチがある」ような複雑な環境分離要件がある場合に検討する。通常の SvelteKit SaaS では GitHub Flow + GitHub Environments で代替できる。

💡 現場のおすすめ: GitLab Flow を採用する前に「GitHub Environments + required reviewers」で解決できないか確認する。多くのケースで環境別ブランチは不要。

規模別おすすめ

人数別の選択マトリクス

人数	推奨戦略	追加すべきルール
1人	GitHub Flow（緩め）	main 直 push も許容
2〜5人	GitHub Flow	branch protection rules 必須化
5〜20人	GitHub Flow + code owners	CODEOWNERS ファイル + レビュー SLA
20人以上	Trunk-based + feature flag	CI/CD 完全整備が前提

✅ branch protection rules 必須チェックリスト（2〜5人〜）

✔ Require status checks to pass before merging（CI グリーンを必須に）
✔ Require approvals: 1名以上（自分のPRを自分でマージしない）
✔ Restrict direct pushes to main（main への直 push を禁止）
✔ Dismiss stale pull request approvals when new commits are pushed
○ Require signed commits（任意: セキュリティ要件がある場合）

06 CI/CDの実装パターン

SvelteKit プロジェクトの CI/CD は GitHub Actions が事実上の標準です。シークレット管理・環境分離・承認フローの現場実態と、よくある失敗パターンを解説します。

1
標準ワークフロー

GitHub Actions — pnpm キャッシュで 2〜3 分

現場標準の実行順: pnpm install → lint → svelte-check → vitest → build → Playwright e2e。pnpm のキャッシュが効くと install が 20秒→3秒に短縮される。svelte-check は TypeScript の型チェックも含むため必須。
```
name: CI
on:
  pull_request:
    branches: [main]

jobs:
  ci:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: pnpm/action-setup@v3
      - uses: actions/setup-node@v4
        with:
          node-version: 20
          cache: pnpm
      - run: pnpm install --frozen-lockfile
      - run: pnpm run lint
      - run: pnpm run check
      - run: pnpm run test:unit
      - run: pnpm run build
      - run: pnpm run test:e2e
```
💡 --frozen-lockfile は必須。これがないと CI でバージョンが変わる「CI でだけ動く」問題が発生する。

シークレット管理

4ツール比較 — 規模に合わせて選ぶ

プロはシークレット管理ツールを「チーム人数」と「AWS への依存度」で決める。

ツール	料金	おすすめ規模	特徴
GitHub Secrets	無料	個人〜5人	CI/CD に直接注入可。ローカル開発は .env
AWS Secrets Manager	$0.40/secret/月	AWS全振りチーム	ローテーション自動化。Aurora認証情報管理に最適
Doppler	5人まで無料	2〜15人	dev/stg/prd の環境分離が直感的。CLI も良い
1Password CLI	$4/人/月	ローカル開発重視	.env を平文で持たない。セキュリティ意識高いチーム向け

3
環境分離

PR Preview → staging 自動 → production 手動承認

プロはデプロイを3段階に分ける: ①PR ごとに Preview Deploy（Vercel/CF Pages が自動）→ ②main merge 後に staging 自動デプロイ → ③手動承認後 production。staging までは自動化してデプロイ頻度を上げ、production だけは人間の目を通す。

💡 現場のおすすめ: 「staging でバグを発見した率」を KPI にすると、チームが staging を真剣にテストするようになる。production でしかバグを発見できていないチームは staging の存在意義を感じていない。
4
デプロイ承認

GitHub Environments + required reviewers

GitHub Environments の required reviewers を設定すると、production デプロイジョブを指定したメンバーが承認しないと実行されない。無料プランでも使える（パブリックリポジトリ）。プライベートリポジトリは Team/Enterprise プランが必要。チーム化したら最低1名の approval を必須にする。

⚠️ 落とし穴: required reviewers に自分自身を入れると「誰でも本番に入れる」になる。最低2人で互いに承認する構成が必要。1人チームの場合は CI グリーン必須 + Slack 通知で補完する。
5
キャッシュ戦略

CI時間 10分→3分に短縮する3つのキャッシュ

プロは CI の遅さがチームの生産性を直接下げることを知っている。3つのキャッシュが有効: ①pnpm キャッシュ（actions/setup-node の cache: pnpm）、②Turborepo Remote Cache（Vercel 無料、ビルドが変更されたパッケージのみ再実行）、③Playwright ブラウザキャッシュ（毎回 100MB ダウンロードを防ぐ）。

💡 現場の数値: キャッシュなし 10〜15分 → pnpm キャッシュ追加で 6〜8分 → Turbo Remote Cache で 3〜4分が典型値。Playwright は別ジョブに分離してから並列実行するとさらに短縮できる。
6
失敗パターン集

現場でよく起きる CI/CD の失敗 6 選
- ✗
  シークレット漏洩: .env をコミットして GitHub に push。Secrets Manager に移行するまでローテーションが必要になる。
- ✗
  本番 DB マイグレーションを手動実行: drizzle-kit push を prod Aurora に直接実行してロールバック不能になる。Blue/Green デプロイを使うこと。
- ✗
  PR ごとに DB が汚れる: テスト用 Aurora が全 PR で共用されており、並列テストが干渉する。PR ごとに DB スキーマをリセットする仕組みが必要。
- ✗
  テスト用 Aurora がコスト爆発: min ACU=0 にせず常時起動。月 $100 以上が dev 環境だけで消える。ACU=0 設定と接続の明示的クローズを徹底する。
- ✗
  CI が壊れたまま放置: 「後で直す」が積み重なり誰も CI を信頼しなくなる。CI グリーンを branch protection の必須条件にして強制する。
- ✗
  prod に直 push: 「緊急だから」という理由で branch protection を bypass して直 push。後で必ず PR を作るというルールを徹底する。
💡 失敗の共通点: 「今回だけ」「緊急だから」という判断で例外を作ること。仕組みで防ぐ（branch protection、ACU=0 強制）ことが本質的な解決策。

11. 個人→チーム移行 8ステップロードマップ

「いつ何を導入するか」の時系列判断が最も難しい。売上・人数・トラフィックのマイルストーンと紐づけた現場の判断基準を示します。

1
Phase 1 — POC（0〜1人）

まず動くものを作る。品質より速度

SvelteKit + Vercel + Drizzle + Aurora Serverless v2（min 0）。テストなし、CI 最小（build だけ）、main 直 push も可。目的は「本当に需要があるか」の検証。月コスト $10〜$30。
2
Phase 2 — 最初のユーザー獲得（月 ARR 0〜50万円）

vitest 導入 + Sentry エラー追跡

実際のユーザーが来始めたらエラーを見えるようにする。vitest で重要なビジネスロジックのユニットテストを書き始める（カバレッジ 30% 目標）。GitHub Actions に lint + check + test を追加。
3
Phase 3 — 2〜3人体制（月 ARR 50〜300万円）

GitHub Flow 導入 + branch protection rules

初めて他人がコードを触る段階。GitHub Flow と PR レビュー 1名必須を設定する。Turborepo + pnpm workspaces でモノレポ化も検討開始。Doppler でシークレット管理を一元化。
4
Phase 4 — 5人体制（月 ARR 300万〜1000万円）

staging 環境 + prod 承認フロー

PR Preview → staging 自動 → prod 手動承認の3段階を確立。GitHub Environments + required reviewers を設定。Aurora を adapter-node + 同VPC 直接接続に移行（Vercel から AWS へ）。月コスト $300〜$500。
5
Phase 5 — 10人体制（月 ARR 1000万〜3000万円）

Playwright e2e + CODEOWNERS + AWS Secrets Manager

エンジニアが増えると「誰がこのコードのオーナーか」が重要になる。CODEOWNERS ファイルを設定。Playwright で e2e テストを CI に組み込む。Aurora Blue/Green デプロイを本番スキーマ変更の標準手順にする。
6
Phase 6 — 20人体制（月 ARR 3000万〜1億円）

Trunk-based 移行 + feature flag + オンコール体制

デプロイ頻度が週5回以上になったら Trunk-based Development を検討。LaunchDarkly や Statsig で feature flag を導入。週次ローテのオンコール体制（PagerDuty）と blameless ポストモーテムを開始。
7
Phase 7 — 30〜50人体制（月 ARR 1億円〜）

SRE チーム + SLO/SLA + マイクロサービス分離検討

SRE（サイトリライアビリティエンジニアリング）チームを立ち上げ、SLO（サービスレベル目標）と SLA（外部約束）を定義する。apps/api を独立サービスとして切り出すかの判断もこのフェーズ。
8
Phase 8 — エンタープライズ

SOC2 / ISO27001 / ISMS 取得フェーズ

大手企業との契約に SOC2 Type II や ISMS（ISO27001）が求められる段階。変更管理・アクセスログ・インシデント対応フロー・BCP（事業継続計画）の文書化が必要。このフェーズで初めて「ドキュメントを書く文化」が価値を持つ。

03-B モノレポ構造サンプルとファイル設計ルール

5人体制になる前に決めておくと後が楽なディレクトリ構造と、チームで共有すべきファイル設計のルールを示します。

推奨モノレポ構造（Turborepo + pnpm workspaces）

my-app/
├── apps/
│   ├── web/                    # SvelteKit 本体
│   │   ├── src/
│   │   │   ├── routes/
│   │   │   │   ├── api/        # +server.ts（〜5人フェーズ）
│   │   │   │   └── (app)/      # 認証必須ページ group
│   │   │   ├── lib/
│   │   │   │   ├── server/     # サーバーのみコード
│   │   │   │   └── components/ # Svelteコンポーネント
│   │   │   └── hooks.server.ts # 認証チェック一元管理
│   │   └── svelte.config.js
│   └── api/                    # 独立REST API（10人〜で分離）
│       └── src/index.ts        # Hono or Fastify
├── packages/
│   ├── types/                  # zodスキーマ + z.infer型
│   │   └── src/
│   │       ├── user.ts
│   │       ├── auth.ts
│   │       └── index.ts
│   ├── db/                     # Drizzle スキーマ + migrate
│   │   └── src/
│   │       ├── schema/
│   │       ├── migrations/
│   │       └── index.ts
│   └── ui/                     # 共通UIコンポーネント
│       └── src/
│           └── components/
├── turbo.json
└── pnpm-workspace.yaml

SvelteKit ファイルの役割分担ルール（チームで合意すべき事項）

ファイル	役割	書いてよいもの	書いてはいけないもの
+page.svelte	UI表示	HTML/CSS、UIロジック、ストア購読	DB操作、シークレット参照、ビジネスロジック
+page.server.ts	データ取得・フォーム処理	load関数、actions、DB クエリ	fetch（クライアント側）、window オブジェクト
+server.ts	API エンドポイント	GET/POST/PUT/DELETE ハンドラ	UIコンポーネント、Svelte ストア
hooks.server.ts	全リクエスト共通処理	認証確認、event.locals設定、CORS	ページ固有ロジック、重いDB処理
src/lib/server/	サーバー側ユーティリティ	DB接続、メール送信、外部API呼び出し	クライアント側コード（自動エラー）

superforms × zod の実装パターン（チーム標準化の例）

// packages/types/src/user.ts
import { z } from 'zod';

export const createUserSchema = z.object({
  name: z.string().min(1).max(100),
  email: z.string().email(),
  role: z.enum(['admin', 'member', 'viewer'])
});

export type CreateUserInput = z.infer<typeof createUserSchema>;

// apps/web/src/routes/users/+page.server.ts
import { superValidate, fail } from 'sveltekit-superforms';
import { zod } from 'sveltekit-superforms/adapters';
import { createUserSchema } from '@my-app/types';

export const actions = {
  create: async ({ request }) => {
    const form = await superValidate(request, zod(createUserSchema));
    if (!form.valid) return fail(400, { form });
    // DB 書き込み...
    return { form };
  }
};

📌 チームで最初に合意すべき5点

認証ライブラリ（Lucia か Better Auth か）— 後から変えるのは辛い
ORM（Drizzle か Prisma か）— マイグレーション哲学の違いが大きい
状態管理（Svelte stores か Tanstack Query か）— SSR との兼ね合い
エラーハンドリング方針（throw か Result型か）— 全員が同じ書き方をする
コンポーネントライブラリ（shadcn-svelte か bits-ui か自作か）— デザイン統一

04-B Aurora 監視・アラート設定の現場標準

「監視なしで本番に出す」のが個人開発の典型です。チームになったら最初に設定すべき Aurora のアラートと、SvelteKit 側からの DB パフォーマンス計測を解説します。

CloudWatch アラート — 最低限設定すべき7項目

メトリクス	アラート閾値（目安）	意味	対処法
CPUUtilization	> 80% × 5分	スケールアップが必要	max ACU 増加 or クエリ最適化
DatabaseConnections	> max の 80%	接続数枯渇直前	RDS Proxy 導入 or 接続プール調整
FreeableMemory	< 256 MB	メモリ不足	インスタンスクラス変更 or クエリ改善
ReadLatency	> 20ms	クエリが遅い	EXPLAIN ANALYZE でスロークエリ特定
WriteLatency	> 100ms	書き込みが遅い	インデックス見直し・バッチ書き込み化
ServerlessDatabaseCapacity	max ACU に到達	上限張り付きスロットリング	max ACU 引き上げ
StorageUsed	> 80% of allocated	ストレージ残量僅少	Aurora は自動拡張。上限設定を確認

🔍 パフォーマンス計測のポイント

Performance Insights（Aurora 標準）: どの SQL がCPUを食っているか可視化。無料7日間保存
pg_stat_statements: 実行回数・合計時間・平均時間でスロークエリを特定
EXPLAIN ANALYZE: 特定クエリの実行計画を確認。Seq Scan を Index Scan に変えるとドラマ的改善
Drizzle のクエリログ: 開発時は logger: true で全SQLを出力

💸 コスト監視の要点

AWS Cost Anomaly Detection: 異常なコスト増加を自動検知。無料で使える
Budget アラート: 月 $X を超えたら SNS 通知。$50/$100/$200 の3段階設定が現場定番
I/O コスト: Aurora I/O は $0.20/百万リクエスト。read が多いアプリは I/O-Optimized モードを検討
ACU ×時間グラフ: 「いつ高い」を見て ACU スケジューリング（夜間 min 下げ）を検討

05-B コンフリクト解決と PR レビューの現場作法

チーム開発で最も時間を奪われるのが「コンフリクト」と「レビュー待ち」です。コンフリクトを減らす設計と、レビューを速く終わらせる作法を解説します。

コンフリクトを減らす設計原則

1
ファイルを細かく分割する

1ファイル200行以下を目安に。大きいファイルほどコンフリクトが発生しやすい。SvelteKit の route ごとにファイルが分かれる設計が逆にコンフリクト減少に寄与する。
2
責任範囲を人別に分ける

「Aさんは認証系」「Bさんは決済系」のように CODEOWNERS で責任範囲を明確にする。同じファイルに複数人が同時に触る状況を構造的に防ぐ。
3
ブランチを小さく短命に

1ブランチ = 1機能 = 1〜3日以内にマージ。長命ブランチが最大のコンフリクト原因。「大きな機能は feature flag で小さく分割」が現場の解決策。

PR レビューを速く終わらせる作法

1
PR は 400 行以下を目標に

800行超の PR は「あとで見る」になる。大きな機能は「スキーマ定義 PR」「API PR」「UI PR」に分割してレビュー負荷を下げる。
2
PR テンプレートを用意する

「変更の目的」「テスト方法」「スクリーンショット」「関連 issue」を PR 作成時に必ず書く。レビュアーの「何を見ればいいか」を0秒で伝える。
3
レビュー SLA を設定する

「営業日 1日以内に初回レビュー」を SLA にする。2日以上待たせると PR 作者が他の作業に移って文脈を忘れる。Slack の GitHub 通知を「即時」に設定することが必須。

🔧 コンフリクト解消チートシート

コンフリクトが起きたら

git checkout feature/my-branch
git fetch origin
git rebase origin/main
# コンフリクト解消
git add .
git rebase --continue
git push --force-with-lease

rebase か merge か

rebase: コミット履歴がきれい。個人ブランチに使う
merge: マージコミットが残る。共有ブランチには merge
squash merge: PR マージ時は squash で1コミットに。GitHub Flow の標準
force-with-lease: force push の安全版。他人の push を上書きしない

07. テスト戦略 — vitest × Playwright の現場設計

テストは「書き方を知っている」より「何をどこまでテストするか」の判断が難しい。SvelteKit 特有のテスト設計と、チーム規模に応じたカバレッジ目標を示します。

テスト種別	ツール	何をテストするか	目標カバレッジ	CI時間
Unit test	vitest	ビジネスロジック、zod バリデーション、ユーティリティ関数	ロジック部分 80%	10〜30秒
Integration test	vitest + supertest	+server.ts エンドポイント、DB を含む actions	主要 API 100%	1〜3分
Component test	vitest + @testing-library/svelte	UIコンポーネントのレンダリング・インタラクション	共有コンポーネントのみ	30〜60秒
E2E test	Playwright	重要フロー全体（ログイン・決済・主要CRUD）	クリティカルパス 100%	3〜10分

Playwright e2e の設計指針（現場パターン）

✅ テストすべきフロー

• サインアップ → メール確認 → ログイン
• メインの CRUD 操作（作成・更新・削除）
• 決済フロー（Stripe テストモード）
• 権限制御（管理者でしか見えないページ）
• エラー状態（バリデーションエラー表示）

❌ e2e でテストしなくていいもの

• デザインの細部（スナップショットテスト）
• ユニットで十分な純粋関数
• サードパーティ API の動作（モックする）
• 全ページの全ボタン（維持コストが爆発）
• ローディングスピナーの表示時間

🗄️ テスト DB 戦略 — Aurora を CI で安全に使う

問題: 全 PR が同じ Aurora を使うとデータが干渉する。

解決策 3 パターン:

PostgreSQL ローカル（vitest 推奨）: vitest の setup.ts で postgres コンテナを起動（testcontainers）し、テスト後に破棄。CI も Docker 使用。Aurora よりはるかに安い。
PR ごとにスキーマ分離: Aurora の schema を PR 番号で分ける（schema_pr_123）。migrate → test → drop の3ステップ。コスト増は最小限。
staging Aurora を共用: トランザクションをテスト後にロールバックする。SERIALIZABLE 分離レベルで並列テストのデータ干渉を防ぐ。シンプルだが並列実行が難しい。

現場の9割はパターン1（testcontainers）を選択。Aurora の CI 利用は月コスト $50〜$200 余分にかかるため。

08. レビュー文化とPR運用

コードレビューは「バグを見つける場所」ではなく、チームの知識を均一化し、設計品質を担保するための場です。ルールのないレビューは属人化・遅延・コンフリクトの温床になります。このセクションでは現場で機能するPR運用の具体的なルールを提示します。

1
PR サイズ

1PR = 1機能、100〜400行が目安、上限800行

現場の経験則は「レビュアーが1時間以内に読めるか」。800行を超えるとレビュアーは全体を把握できず、形式的な承認になる。大きな機能は「スキーマ追加PR」「APIエンドポイントPR」「UI PR」に分割するのが定石。
2
テンプレート

PRテンプレート（実用最小版）

変更内容・動作確認チェックリスト・スクリーンショット・ロールバック手順の4項目を定型化するだけで、レビュー前の「これ何の変更？」という往復コミュニケーションが激減する。.github/PULL_REQUEST_TEMPLATE.md に配置すると自動適用される。
3
CODEOWNERS

CODEOWNERSの効果

.github/CODEOWNERS にファイルパスとオーナーを記述すると、該当ファイルの変更時に必須レビュアーが自動アサインされる。「誰でもマージできる」状態を防ぎ、レビュー集中のボトルネックをチームに分散できる。例：src/lib/db/** @db-team。
4
心理的安全性

Conventional Commentsの心理的安全性

コメントにラベルを付けることでレビュアーの意図が明確になり、受け手が不安にならない。[nitpick] は直さなくてOK、[suggestion] は提案、[issue] は問題あり、[blocking] はマージ阻止、[praise] は称賛。ラベルなしの指摘は「これは直さないといけない？」と受け手が迷う。
5
マージ戦略

マージ戦略 — Squash and merge推奨

Squash and merge（推奨）: PR内のコミットを1つにまとめてマージ。履歴がPR単位で整理されrevertが容易。Rebase merge: 全コミットを直線上に展開するが、WIP的コミットが残り複雑。Merge commit: マージコミットが増えて履歴が汚染される。小〜中規模チームはほぼSquash一択。
6
SLA

レビューSLA — 24時間以内に一次レビュー

「レビュー待ちで3日間ブロックされた」はチームの生産性を著しく低下させる。「PRオープン後24時間以内に一次レビュー（Approveでなくコメントでも可）」をチームルールとして明文化し、Slackの/review コマンドやGitHub通知で周知する仕組みを作る。

PRテンプレートのMarkdownサンプル（.github/PULL_REQUEST_TEMPLATE.md）

## 変更内容
- 何を変えたか、なぜ変えたかを1〜3行で

## 動作確認チェックリスト
- [ ] ローカルで正常動作を確認した
- [ ] 既存テストが全てパスしている
- [ ] 新機能のテストを追加した（ある場合）
- [ ] ブラウザ確認（Chrome/Safari）済み

## スクリーンショット（UIの変更がある場合）
Before: （画像を貼る）
After:  （画像を貼る）

## ロールバック手順
- このPRをrevertすれば元に戻る / or 追加の手順があれば記載
- DBマイグレーションが含まれる場合: down migration コマンドを記載

09. オブザーバビリティとインシデント対応

「何かがおかしい」と気づくのに1時間かかるか、1分でわかるかは監視設計で決まります。個人開発では月0円の最小構成から始め、チームが拡大するにつれて段階的にツールを積み上げるのが正しいアプローチです。

1
個人開発（月0円〜）

個人開発の最小構成

Sentry無料枠（5,000 events/月）+ UptimeRobot無料枠（5分おき死活監視）+ CloudWatchデフォルトメトリクス（Aurora/Lambda自動収集）で月0円〜の監視体制が組める。「落ちたら知りたい」と「エラーを把握したい」の2点を無料で押さえることが最優先。
2
小規模チーム（月$30〜100）

小規模チーム（2〜5人）構成

Sentry Team Plan（$26/月〜、無制限events）+ CloudWatch Logs/Metrics（ログ検索・アラーム）+ Slack Webhook（エラー通知）で月$30〜100。エラーの件数・ユーザー影響・スタックトレースがSlackに流れ、誰がオンコールでなくてもトリアージできる体制になる。
3
中〜大規模

中〜大規模構成 — フルオブザーバビリティ

Datadog APM（トレース・ダッシュボード）+ OpenTelemetry（標準計装）+ PagerDuty（オンコールスケジュール・エスカレーション）+ SLO設定（可用性99.9%、p99レイテンシ500ms以下）。ここまで来ると月数百ドルになるが、チームが10人を超えると「なぜ遅いか」を人力で追うコストの方が高くなる。
4
アンチパターン

Sentryの「狼少年化」問題

エラーを全部Slackに流すと通知が多すぎて誰も見なくなる（アラート疲れ）。「ユーザーに影響があるエラーのみ」でフィルタリングするSentryアラートルール設計が必須。具体的には「同じエラーが1時間に10回以上」「新規エラー（初回発生）」「特定のエンドポイントのみ」などの条件でアラートを絞る。
5
Aurora固有

Aurora固有の監視ポイント

特に見るべきメトリクス: ACU使用率（Serverless v2の上限に張り付くとスロットリング）、DatabaseConnections（max_connections枯渇でアプリ全停止）、AuroraReplicaLag（読み取りレプリカが遅延してstaleデータを返す）、FreeStorageSpace（自動拡張があるが上限は設定次第）。これら4つに CloudWatch アラームを設定しておくだけで障害の9割は事前検知できる。
6
インシデント対応

インシデント対応3ステップ

①検知（PagerDuty/Slackアラート → オンコール担当が起動）→ ②初動（Runbook通りに機械的に対応、「考える」より「手を動かす」）→ ③ポストモーテム（blameless — 誰かを責めない、5 Whys分析で根本原因を特定し再発防止策を記録）。ポストモーテムなしで終わると同じ障害が繰り返す。

規模別ツール選定マトリクス

規模	エラー監視	APM	ログ	月額コスト
個人（1人）	Sentry 無料枠	CloudWatch デフォルト	CloudWatch Logs	$0〜10
小規模（2〜5人）	Sentry Team Plan	CloudWatch Metrics	CloudWatch Logs	$30〜100
中規模（5〜20人）	Sentry Business	Datadog APM	Datadog Logs	$200〜500
大規模（20人〜）	Sentry + PagerDuty	Datadog Full Stack	Datadog + OpenTelemetry	$500〜

10. ドキュメント文化

チームの「なぜ」はコードに書けません。技術的判断の理由・インシデントの教訓・セットアップ手順は、意図的に残さないと永遠に失われます。ドキュメント文化は「書く時間のコスト」より「ない場合の調査コスト・属人化リスク」の方が圧倒的に大きいことが現場での共通認識です。

1
何をどこに書くか

ドキュメントの置き場マップ

RFC（GitHub Discussions/Notion、技術判断前に議論）、ADR（docs/adr/にMarkdown、決定後即）、Runbook（Notion/GitHub Wiki、インシデント後）、README/CONTRIBUTING（リポジトリルート、開始時）、API仕様（OpenAPIまたはtRPC自動生成）。「どこに何があるか」の1枚のマップをREADMEに置くと検索コストが激減する。
2
ツール選定

なぜNotionが選ばれるか

非エンジニアも使える直感的UI、リアルタイム同時編集、DBビューでの整理ができるため、PdM・デザイナー・CS込みのチームで採用されやすい。Confluenceは大企業の既存投資が残っているだけで新規採用は減少傾向。GitHub Wikiはエンジニア専用で非エンジニアがアクセスしない。Notionの弱点は「検索性の低さ」と「ネスト構造の複雑化」。
3
ADRの効果

ADRの1年運用の効果

「なぜDrizzle ORMを選んだか」「なぜAuroraにしたか」が1年後も追跡可能になり、「また同じ議論が始まる」を防げる。新メンバーのオンボーディング時間が平均30〜50%短縮されるという報告が多い。コストは「書く時間（1件30分）」と「検索性の維持」。少ない労力で最大のリターンが得られるドキュメント種別。
4
ADRテンプレート

ADR最小テンプレート — 4ブロック構成

ステータス（Accepted/Deprecated/Superseded by ADR-xxx）、コンテキスト（なぜこの判断が必要だったか、当時の制約）、決定（何を選んだか、選ばなかった代替案と理由）、結果（期待する効果、既知のトレードオフ）。この4ブロックだけで将来の自分やチームへの手紙として機能する。
5
Runbook

Runbook（オンコール手順書）

「アラートAが来たら → 手順1: RDSコンソールでACU使用率を確認 → 手順2: スケーリング設定を変更 → 解決しなければエスカレーション先: Slackの#on-call」という具体手順を事前に書いておく。深夜のインシデント対応で「考える」を排除し「手を動かす」に集中できるようにするのがRunbookの目的。
6
README

README必須項目

プロジェクト概要（3行以内）、開発環境セットアップ（コピペで動くコマンド列）、デプロイ手順（本番反映のステップ）、連絡先（困ったら誰に聞くか）。この4項目があるだけで、新メンバーが1人で開発環境を立ち上げられる確率が劇的に上がる。ないと「聞かないとわからない」属人化が発生する。

ADRサンプル（Drizzle ORM採用判断）— docs/adr/0003-drizzle-orm.md

# ADR-0003: Drizzle ORM の採用

## ステータス
Accepted（2026-01-15）

## コンテキスト
SvelteKit + Amazon Aurora（PostgreSQL互換）構成でORMを選定する必要があった。
候補: Prisma / Drizzle ORM / Kysely / 生SQL（pg）

制約:
- TypeScript型安全を保ちたい
- Serverless環境でコールドスタートを最小化したい
- マイグレーション管理をコードで行いたい

## 決定
Drizzle ORM を採用する。

採用理由:
- バンドルサイズが軽量でコールドスタートへの影響が小さい
- SQL寄りの直感的なAPIで生SQLからの移行コストが低い
- PostgreSQL方言のTypeScript型定義が完全
- drizzle-kit によるマイグレーション管理が十分

不採用理由（Prisma）:
- バンドルサイズが大きくServerless環境でコールドスタートが遅くなる
- Prismaエンジンのバイナリ依存がある

## 結果
期待効果:
- 型安全なクエリでランタイムエラーを削減
- マイグレーション履歴をGit管理できる

既知トレードオフ:
- PrismaほどのエコシステムはなくAIコード補完の精度がやや低い
- relationsの複雑なクエリはPrismaの方が書きやすいケースがある

12. まとめ — 個人から法人チームへのロードマップ

「個人で動くコード」と「チームで保守できるコード」は別物です。必要なのは完璧な設計からのスタートではなく、今すぐできる最小アクションを積み重ねて、チームの成長とともに仕組みを育てることです。

🧠

覚えておく原則

「個人で動くコード」と「チームで保守できるコード」は別物。後者はテスト・CI・ドキュメント・レビュー文化という人間の仕組みが支えている。コードの品質は書く人だけでは決まらない。

🚀

明日から始める3つ

1feature branch + PR運用（mainに直接pushしない）
2GitHub Actions CI（lint + test + build）
3Sentry無料枠導入（エラーを可視化する）

🎯

3ヶ月後の目標

✅ Playwright E2Eテスト最低3シナリオ（ログイン・主要フロー・エラー系）
✅ Drizzle migrationでスキーマをGit管理
✅ PRテンプレート + CODEOWNERSを設置

💬

チーム化の合図

「自分以外の人がコードを変えても壊れない自信があるか？」を月1回自問する。

NOなら何が欠けているかを1つ特定して今月中に埋める。それがチーム開発の育て方。

🛠️ 現場でのシステム開発 SvelteKit編

01 ゴール — 個人開発から法人チーム開発へ

02 個人 vs チーム — 9軸工程対比

03 SvelteKit特有のチーム開発

Turborepo + pnpm workspaces

zod × 型の単一ソース化

+server.ts vs 別REST API分離

adapter選定 — Aurora直接接続ならadapter-node必須

hooks.server.ts で認証を一元管理

superforms で actions を統一

$env 4種の使い分け基準

04 Amazon Aurora運用 — 個人〜法人の現場実態

Aurora vs RDS PostgreSQL — どちらを選ぶか

2024年11月解禁 — dev環境は無料に近くできる

ツール選定 — Drizzle ORM を新規で推奨

3パターン — SvelteKit × Aurora の接続設計

Blue/Green デプロイメント — 1クリックで安全なDDL

個人・小規模向けの Aurora コスト最適化

05 ブランチ戦略の現場実態

GitHub Flow — シンプルさが最強

Git Flow — SvelteKit 新規案件では選ばない

Trunk-based Development — 20人以上で検討

GitLab Flow — 環境分離が複雑な場合のみ

人数別の選択マトリクス

06 CI/CDの実装パターン

GitHub Actions — pnpm キャッシュで 2〜3 分

4ツール比較 — 規模に合わせて選ぶ

PR Preview → staging 自動 → production 手動承認

GitHub Environments + required reviewers

CI時間 10分→3分 に短縮する3つのキャッシュ

現場でよく起きる CI/CD の失敗 6 選

11. 個人→チーム移行 8ステップロードマップ

まず動くものを作る。品質より速度

vitest 導入 + Sentry エラー追跡

GitHub Flow 導入 + branch protection rules

staging 環境 + prod 承認フロー

Playwright e2e + CODEOWNERS + AWS Secrets Manager

Trunk-based 移行 + feature flag + オンコール体制

SRE チーム + SLO/SLA + マイクロサービス分離検討

SOC2 / ISO27001 / ISMS 取得フェーズ

03-B モノレポ構造サンプルとファイル設計ルール

04-B Aurora 監視・アラート設定の現場標準

05-B コンフリクト解決と PR レビューの現場作法

07. テスト戦略 — vitest × Playwright の現場設計

08. レビュー文化とPR運用

1PR = 1機能、100〜400行が目安、上限800行

PRテンプレート（実用最小版）

CODEOWNERSの効果

Conventional Commentsの心理的安全性

マージ戦略 — Squash and merge推奨

レビューSLA — 24時間以内に一次レビュー

09. オブザーバビリティとインシデント対応

個人開発の最小構成

小規模チーム（2〜5人）構成

中〜大規模構成 — フルオブザーバビリティ

Sentryの「狼少年化」問題

Aurora固有の監視ポイント

インシデント対応3ステップ

10. ドキュメント文化

ドキュメントの置き場マップ

なぜNotionが選ばれるか

ADRの1年運用の効果

ADR最小テンプレート — 4ブロック構成

Runbook（オンコール手順書）

README必須項目

12. まとめ — 個人から法人チームへのロードマップ

覚えておく原則

明日から始める3つ

3ヶ月後の目標

チーム化の合図

`+server.ts` vs 別REST API分離

`hooks.server.ts` で認証を一元管理

`$env` 4種の使い分け基準

CI時間 10分→3分に短縮する3つのキャッシュ