ATLAS_v1.0.md
# ATLAS v1.0
## Architecture & Technology Layer Alignment System
> プロジェクト特性と技術選定を構造的に整合させるフレームワーク
---
## 概要
ATLASは、Webアプリケーション開発における技術選定を体系化するフレームワークである。
**解決する問題**：
- 技術選定が属人的で再現性がない
- プロジェクト特性と技術特性のミスマッチによる後発的な問題
- 「どの技術を使うか」ではなく「どう判断すべきか」が不明確
**提供する価値**：
- プロジェクトアーキタイプに基づく判断構造
- アンチパターンの体系的な検知
- スケール段階に応じた移行パス
---
## Part 1: Project Archetypes（プロジェクト原型）
プロジェクトを7つの原型に分類する。実際のプロジェクトは複数の原型の特性を持つことがある。
### 1.1 アーキタイプ一覧
| ID | アーキタイプ | 代表例 | 本質的要件 |
| --- | ------------------- | ---------------------------------------- | ---------------------------------------- |
| A1 | **Static Presence** | コーポレートサイト、IR、採用サイト | 信頼性、SEO、更新容易性、長期運用 |
| A2 | **Campaign** | プロモーションサイト、LP、イベントサイト | 速度、スケール耐性、期間限定、撤収容易性 |
| A3 | **Consumer App** | toC Webサービス、SNS、メディア | UX、認証、スケール、コスト効率 |
| A4 | **Business SaaS** | toB 業務システム、管理画面 | マルチテナント、権限管理、監査、SLA |
| A5 | **Marketplace** | EC、マッチングサービス、予約システム | 決済、双方向性、信頼性、トランザクション |
| A6 | **Real-time** | チャット、コラボツール、ゲーム | 低遅延、常時接続、状態同期 |
| A7 | **AI/Compute** | 生成AI、データ分析、変換処理 | 長時間処理、GPU、非同期、コスト管理 |
### 1.2 アーキタイプ判定フロー
```
Q1: ユーザーとのインタラクション頻度は？
└─ 低（閲覧中心）→ A1 or A2
└─ 高（操作中心）→ Q2へ
Q2: リアルタイム性が必要か？
└─ Yes → A6
└─ No → Q3へ
Q3: 金銭取引があるか？
└─ Yes → A5
└─ No → Q4へ
Q4: 主なユーザーは？
└─ 一般消費者 → A3
└─ 企業・組織 → A4
Q5: 重い計算処理があるか？
└─ Yes → A7（他との複合）
```
### 1.3 アーキタイプ別の重要判断軸
| アーキタイプ | 最重要軸 | 次点 | 軽視可能 |
| ------------------ | -------------------- | ---------- | ------------ |
| A1 Static Presence | 可用性、SEO | CMS体験 | スケール |
| A2 Campaign | 配信速度、コスト予測 | 撤収容易性 | 長期運用 |
| A3 Consumer App | 認証、UX | スケール | 監査 |
| A4 Business SaaS | 権限、監査 | SSO | 配信速度 |
| A5 Marketplace | 決済、信頼性 | 検索 | リアルタイム |
| A6 Real-time | 遅延、接続維持 | 状態同期 | SEO |
| A7 AI/Compute | 処理時間、コスト | キュー | UX |
---
## Part 2: Technology Categories（技術カテゴリ）
個別の技術名ではなく、技術カテゴリの特性を理解する。
### 2.1 Compute（実行環境）
| カテゴリ | 特性 | 適合 | 不適合 |
| ----------------------- | ------------------------------ | --------------------------------- | --------------------- |
| **Serverless Edge** | 超低遅延、軽量処理、グローバル | 静的配信、リダイレクト、A/Bテスト | DB接続、重い処理 |
| **Serverless Regional** | 自動スケール、従量課金 | API、SSR、軽量処理 | 長時間処理、WebSocket |
| **Container PaaS** | 永続プロセス、予測可能コスト | WebSocket、Worker、汎用 | 極端なスケール |
| **Self-hosted** | 完全制御、低コスト | 高帯域、特殊要件 | 運用リソースなし |
| **Kubernetes** | 大規模、マルチサービス | エンタープライズ | 小規模チーム |
### 2.2 Database（データ永続化）
| カテゴリ | 特性 | 適合 | 不適合 |
| ----------------------- | ---------------------------- | ------------------------ | ------------------ |
| **Serverless Postgres** | スケールtoゼロ、ブランチング | 汎用、開発効率重視 | 超高スループット |
| **Managed Postgres** | 安定、エンタープライズ対応 | 本番運用、SLA重視 | コスト最小化 |
| **Edge SQLite** | 超低遅延読み取り | 読み取り中心、グローバル | 書き込み中心 |
| **Document DB** | スキーマレス、柔軟 | プロトタイプ、非構造化 | 複雑なリレーション |
| **Vector DB** | 類似検索、AI統合 | RAG、推薦 | 汎用クエリ |
### 2.3 Background Processing（非同期処理）
| カテゴリ | 特性 | 適合 | 不適合 |
| --------------------- | ------------------------------------ | ----------------------------- | ---------------- |
| **Durable Workflow** | 状態管理、リトライ、サーバーレス対応 | 複雑なフロー、Vercel環境 | 超低遅延 |
| **External Compute** | タイムアウトなし、重い処理 | AI生成、動画処理 | 単純なタスク |
| **Self-hosted Queue** | 低遅延、無料 | Container環境、高スループット | サーバーレス環境 |
| **Simple Webhook** | 軽量、設定容易 | CRON、通知 | 複雑なフロー |
### 2.4 Authentication（認証）
| カテゴリ | 特性 | 適合 | 不適合 |
| ---------------------- | ---------------------------- | ------------------------ | ---------------- |
| **DX-First Auth** | 高速実装、UIコンポーネント | MVP、開発速度重視 | コスト最小化 |
| **DB-Integrated Auth** | RLS連携、低コスト | Supabase環境、コスト重視 | 高度なSSO |
| **Enterprise Auth** | SAML、監査、コンプライアンス | 大企業向けB2B | 小規模 |
| **Self-hosted Auth** | 完全制御、無料 | 特殊要件、内製力あり | 運用リソースなし |
### 2.5 Payment（決済）
| カテゴリ | 特性 | 適合 | 不適合 |
| ---------------------- | -------------------------- | ---------------------------- | ---------------- |
| **Payment Processor** | 低手数料、柔軟 | 国内中心、税務体制あり | グローバル小規模 |
| **Merchant of Record** | 税務代行、コンプライアンス | グローバルSaaS、小規模チーム | 国内のみ |
---
## Part 3: Alignment Matrix（適合マトリクス）
アーキタイプと技術カテゴリの適合関係を示す。
### 3.1 Compute選定マトリクス
| アーキタイプ | 推奨Compute | 理由 |
| ------------------ | ------------------------------------- | ---------------------------- |
| A1 Static Presence | Serverless Edge + SSG | CDN配信で十分、コスト最小 |
| A2 Campaign | Serverless Edge | スパイク対応、期間後撤収容易 |
| A3 Consumer App | Serverless Regional or Container PaaS | スケールと機能のバランス |
| A4 Business SaaS | Container PaaS or Self-hosted | 予測可能コスト、永続処理 |
| A5 Marketplace | Container PaaS | トランザクション信頼性 |
| A6 Real-time | Container PaaS | WebSocket必須 |
| A7 AI/Compute | Container PaaS + External Compute | 長時間処理対応 |
### 3.2 Database選定マトリクス
| アーキタイプ | 推奨DB | 理由 |
| ------------------ | ------------------------------- | ---------------------- |
| A1 Static Presence | なし or Headless CMS | 静的生成で十分 |
| A2 Campaign | Serverless Postgres or なし | 軽量、スケールtoゼロ |
| A3 Consumer App | Serverless Postgres | 開発効率、スケール |
| A4 Business SaaS | Managed Postgres | SLA、監査対応 |
| A5 Marketplace | Managed Postgres | トランザクション信頼性 |
| A6 Real-time | Managed Postgres + Redis | 状態同期にRedis |
| A7 AI/Compute | Serverless Postgres + Vector DB | AI統合 |
### 3.3 Worker選定マトリクス
| アーキタイプ | 推奨Worker | 理由 |
| ------------------ | ------------------------------------- | ---------------- |
| A1 Static Presence | なし or Simple Webhook | 定期ビルドのみ |
| A2 Campaign | Simple Webhook | 軽量 |
| A3 Consumer App | Durable Workflow | 複雑なフロー対応 |
| A4 Business SaaS | Durable Workflow or Self-hosted Queue | 信頼性重視 |
| A5 Marketplace | Self-hosted Queue | 高スループット |
| A6 Real-time | Self-hosted Queue | 低遅延 |
| A7 AI/Compute | External Compute | タイムアウト回避 |
---
## Part 4: Anti-Patterns（アンチパターン）
致命的な技術組み合わせとその回避策。
### 4.1 Compute関連
| ID | アンチパターン | 問題 | 代替案 |
| ----- | ---------------------------------- | ------------------------------ | ---------------------------------- |
| AP-C1 | Serverless + 常駐Worker (BullMQ等) | プロセス維持不可、リソース枯渇 | Durable Workflow or Container PaaS |
| AP-C2 | Serverless + 長時間処理 (>60s) | タイムアウト強制終了 | External Compute |
| AP-C3 | Edge SSR + リージョナルDB | Data Gravity問題、遅延増大 | Regional SSRに変更 |
| AP-C4 | 高帯域アセット + Serverless配信 | Denial of Wallet | 外部CDN/Object Storage |
### 4.2 Database関連
| ID | アンチパターン | 問題 | 代替案 |
| ----- | ----------------------- | ---------------- | -------------------------- |
| AP-D1 | Serverless + 標準DB接続 | コネクション枯渇 | コネクションプーラー必須 |
| AP-D2 | ORM + サーバーレス並列 | 接続数爆発 | HTTPドライバ or Accelerate |
| AP-D3 | 単一DBに全機能 | 単一障害点 | 用途別分離検討 |
### 4.3 Security関連
| ID | アンチパターン | 問題 | 代替案 |
| ----- | ------------------------ | -------------------------- | ------------------- |
| AP-S1 | 公開API + レート制限なし | DDoS、Bot被害 | WAF + Rate Limiting |
| AP-S2 | 直接ファイルアップロード | タイムアウト、セキュリティ | Presigned URL |
| AP-S3 | クライアントに秘密情報 | 漏洩リスク | サーバーサイド処理 |
### 4.4 Cost関連
| ID | アンチパターン | 問題 | 代替案 |
| ----- | ---------------------- | -------------- | ---------------------- |
| AP-$1 | 従量課金 + 上限なし | 請求額爆発 | Spend Limit設定 |
| AP-$2 | 開発環境の常時起動 | 無駄なコスト | Scale-to-Zero DB |
| AP-$3 | 過剰なリアルタイム機能 | 接続コスト増大 | ポーリングで十分か検討 |
---
## Part 5: Scale Templates（スケール別テンプレート）
### 5.1 Tier定義
| Tier | 対象 | 月額予算 | チーム規模 | DevOps能力 |
| ---- | ------------------ | --------- | ---------- | ---------- |
| T1 | MVP・個人開発 | ~$50 | 1-2人 | なし~基本 |
| T2 | スタートアップ初期 | $50-500 | 2-5人 | 基本 |
| T3 | 成長期 | $500-5000 | 5-20人 | 中級 |
| T4 | エンタープライズ | $5000+ | 20人+ | 上級 |
### 5.2 Tier別推奨スタック
#### Tier 1: MVP・個人開発
**最適化対象**：開発速度、学習コスト最小化
| レイヤー | 推奨 | 理由 |
| ---------- | ------------------ | -------------------- |
| Compute | Vercel (Hobby→Pro) | 設定不要、最高DX |
| Database | Neon or Supabase | 無料枠、ブランチング |
| Auth | Clerk | 実装工数最小 |
| Worker | Inngest | サーバーレス統合 |
| Payment | LemonSqueezy | 税務代行 |
| Monitoring | Vercel Analytics | 統合済み |
**Exit Strategy**：Tier 2移行時はContainer PaaSへ
#### Tier 2: スタートアップ初期
**最適化対象**：コスト効率、予測可能性
| レイヤー | 推奨 | 理由 |
| ---------- | ----------------------------- | --------------------- |
| Compute | Railway or Coolify (VPS) | 定額制、WebSocket対応 |
| Database | Self-hosted Postgres or Turso | 従量課金回避 |
| Auth | Supabase Auth | MAU単価安い |
| Worker | BullMQ + Redis | 無料、低遅延 |
| Payment | Stripe | 手数料最適化 |
| Monitoring | Grafana + Prometheus | セルフホスト |
**Exit Strategy**：Tier 3移行時はAWS (SST)へ
#### Tier 3: 成長期
**最適化対象**：スケーラビリティ、信頼性
| レイヤー | 推奨 | 理由 |
| ---------- | ------------------------------- | ---------------------- |
| Compute | AWS (SST/OpenNext) | Vercel互換、コスト削減 |
| Database | Neon Scale or Aurora Serverless | マネージドスケール |
| Auth | Clerk or Auth0 | SSO、コンプライアンス |
| Worker | Trigger.dev | 大規模ジョブ |
| Payment | Stripe | 成熟したエコシステム |
| Monitoring | Datadog or New Relic | APM |
**Exit Strategy**：Tier 4移行時はKubernetesへ
#### Tier 4: エンタープライズ
**最適化対象**：ガバナンス、セキュリティ、制御
| レイヤー | 推奨 | 理由 |
| ---------- | ------------------------- | ------------------------ |
| Compute | Kubernetes (EKS/GKE) | 完全制御 |
| Database | Crunchy Data or Cloud SQL | エンタープライズサポート |
| Auth | Auth0 or Keycloak | AD連携、監査 |
| Worker | Temporal or 自前基盤 | ミッションクリティカル |
| Payment | Stripe | 複雑な請求対応 |
| Monitoring | Datadog + PagerDuty | 24/7運用 |
### 5.3 Tier移行トリガー
| 移行 | トリガー条件 |
| ----- | -------------------------------------------- |
| T1→T2 | 月額コストが$100超過 or WebSocket必要 |
| T2→T3 | 帯域1TB超過 or チーム5人超過 or SLA要件 |
| T3→T4 | コンプライアンス要件 or マルチリージョン要件 |
---
## Part 6: Decision Protocol（意思決定手順）
### 6.1 初期選定プロトコル
```
Step 1: アーキタイプ特定
└─ Part 1の判定フローを実行
└─ 複合の場合は主要アーキタイプを決定
Step 2: Tier判定
└─ 予算、チーム規模、DevOps能力から決定
Step 3: ベーススタック選択
└─ Part 5のTier別テンプレートを参照
Step 4: アーキタイプ調整
└─ Part 3のマトリクスで微調整
Step 5: アンチパターンチェック
└─ Part 4の全項目を確認
└─ 該当があれば代替案を適用
Step 6: Exit Strategy確認
└─ 次のTierへの移行パスを確認
└─ ロックインリスクを評価
```
### 6.2 再評価トリガー
以下の状況で技術選定を再評価する：
| トリガー | 評価対象 |
| -------------------------------- | ------------------ |
| 月額コストが想定の150%超過 | Compute、DB |
| レスポンス遅延が目標の200%超過 | Compute、DB、CDN |
| 障害が月2回以上発生 | 全体アーキテクチャ |
| チーム規模が2倍以上に | Tier再判定 |
| 新規要件（リアルタイム、AI等） | アーキタイプ再判定 |
| ベンダーの価格改定・サービス終了 | 該当レイヤー |
### 6.3 意思決定の記録
技術選定時に以下を記録する：
```markdown
## 技術選定記録
### 基本情報
- プロジェクト名:
- 日付:
- 決定者:
### 判定結果
- アーキタイプ: [A1-A7]
- Tier: [T1-T4]
### 選定スタック
| レイヤー | 選択 | 理由 |
| -------- | ---- | ---- |
| Compute | | |
| Database | | |
| Auth | | |
| Worker | | |
| Payment | | |
### アンチパターンチェック
- [ ] AP-C1〜C4 確認済み
- [ ] AP-D1〜D3 確認済み
- [ ] AP-S1〜S3 確認済み
- [ ] AP-$1〜$3 確認済み
### Exit Strategy
- 次Tier移行時の計画:
- ロックインリスク:
### 再評価予定
- 日付:
- トリガー条件:
```
---
## Part 7: Security & Compliance（セキュリティ・コンプライアンス）
### 7.1 セキュリティ基本原則
| 原則 | 内容 | 実装例 |
| ---------- | ------------------------------ | ----------------------- |
| 最小権限 | 必要最小限のアクセス権のみ付与 | IAM、RLS、スコープ制限 |
| 多層防御 | 単一の防御に依存しない | WAF + Rate Limit + 認証 |
| 暗号化 | 転送中・保存中のデータを暗号化 | TLS、AES-256 |
| 監査 | 全てのアクセスをログ | 監査ログ、アクセスログ |
| 迅速な対応 | 脆弱性の早期検知と対応 | 依存関係監視、アラート |
### 7.2 Tier別セキュリティ要件
| 要件 | T1 | T2 | T3 | T4 |
| ---------------------- | --- | --- | --- | --- |
| HTTPS強制 | ✓ | ✓ | ✓ | ✓ |
| 認証・認可 | ✓ | ✓ | ✓ | ✓ |
| Rate Limiting | - | ✓ | ✓ | ✓ |
| WAF | - | △ | ✓ | ✓ |
| 監査ログ | - | - | ✓ | ✓ |
| SOC2/ISO27001 | - | - | △ | ✓ |
| ペネトレーションテスト | - | - | △ | ✓ |
| 24/7監視 | - | - | - | ✓ |
### 7.3 コンプライアンス対応
| 規制 | 対象 | 主要要件 |
| -------------- | -------------------- | ---------------------- |
| GDPR | EU居住者データ | 同意管理、削除権、DPO |
| CCPA | カリフォルニア居住者 | オプトアウト、開示請求 |
| PCI DSS | カード情報 | 決済代行利用で回避可能 |
| HIPAA | 医療情報（米国） | BAA締結、暗号化 |
| 個人情報保護法 | 日本国内 | 利用目的明示、安全管理 |
---
## Appendix A: Technology Examples（技術例 - 2025年版）
> 注意：この付録は2025年時点の例示であり、定期的な更新が必要
### A.1 Compute
| カテゴリ | 技術例 |
| ------------------- | ----------------------------------------------- |
| Serverless Edge | Cloudflare Workers, Vercel Edge Functions |
| Serverless Regional | Vercel Functions, AWS Lambda, Netlify Functions |
| Container PaaS | Railway, Fly.io, Render, Google Cloud Run |
| Self-hosted PaaS | Coolify, Dokploy, CapRover |
| IaC for Serverless | SST, OpenNext, Serverless Framework |
### A.2 Database
| カテゴリ | 技術例 |
| ------------------- | --------------------------------------- |
| Serverless Postgres | Neon, Supabase, Vercel Postgres |
| Managed Postgres | AWS RDS, Google Cloud SQL, DigitalOcean |
| Edge SQLite | Turso, Cloudflare D1 |
| Document DB | MongoDB Atlas, Firestore |
| Vector DB | pgvector, Pinecone, Weaviate |
### A.3 Background Processing
| カテゴリ | 技術例 |
| ------------------- | ---------------------------- |
| Durable Workflow | Inngest, Trigger.dev v3 |
| Self-hosted Queue | BullMQ + Redis, Celery |
| Simple Webhook | Upstash QStash, Vercel Cron |
| Enterprise Workflow | Temporal, AWS Step Functions |
### A.4 Authentication
| カテゴリ | 技術例 |
| ------------- | ---------------------------- |
| DX-First | Clerk, Stytch |
| DB-Integrated | Supabase Auth, Firebase Auth |
| Enterprise | Auth0, Okta |
| Self-hosted | Keycloak, Authentik |
| Library | NextAuth.js, Lucia |
### A.5 Payment
| カテゴリ | 技術例 |
| ------------------ | -------------------- |
| Payment Processor | Stripe, Square |
| Merchant of Record | Paddle, LemonSqueezy |
---
## Appendix B: Quick Reference Cards
### B.1 アーキタイプ早見表
```
A1 Static Presence → SSG + CDN + Headless CMS
A2 Campaign → SSG + CDN + 最小構成
A3 Consumer App → Serverless + Managed DB + Auth SaaS
A4 Business SaaS → Container + Managed DB + Enterprise Auth
A5 Marketplace → Container + Managed DB + Payment
A6 Real-time → Container + Redis + WebSocket
A7 AI/Compute → Container + Vector DB + External Compute
```
### B.2 アンチパターン早見表
```
❌ Serverless + BullMQ → ✓ Inngest/Trigger.dev
❌ Serverless + 標準DB接続 → ✓ コネクションプーラー
❌ Edge SSR + Regional DB → ✓ Regional SSR
❌ 高帯域 + Vercel配信 → ✓ R2/S3 + CloudFront
❌ 公開API + レート制限なし → ✓ WAF + Rate Limiting
❌ 従量課金 + 上限なし → ✓ Spend Limit設定
```
### B.3 Tier移行チェックリスト
```
T1→T2 移行時:
□ Container化対応（Dockerfile）
□ 環境変数管理の整備
□ ログ集約の設計
T2→T3 移行時:
□ IaC導入（Terraform/SST）
□ CI/CD強化
□ 監視・アラート設計
T3→T4 移行時:
□ Kubernetes習熟
□ マルチリージョン設計
□ DR計画策定
```
---
## Changelog
| Version | Date | Changes |
| ------- | ------- | ------------ |
| 1.0 | 2025-01 | 初版リリース |
---
## License
This framework is provided under CC BY 4.0.
Attribution: mirror / ATLAS Framework
---
## 参考文献
- Gemini Deep Research: 技術選定・アーキテクチャ設計の判断マトリクス構築のための包括的調査報告書 (2025)
- AWS Well-Architected Framework
- ThoughtWorks Technology Radar
- The Twelve-Factor App