🚀
【フロントエンド】レンダリング方式と実装方針をまとめたい
はじめに
モダンフロントエンド開発では、MPA、SPA、CSR、SSR、SSG、ISR、PPR など多様なレンダリング方式が選択できます。しかし、それぞれの方式に最適な AWS サービス構成は大きく異なります。
本記事では、各レンダリング方式の特徴を説明し、AWS 観点での技術選定指針と最適なサービス組み合わせを解説します。
レンダリング方式の理解と分類
レンダリング方式の概要
モダン Web アプリケーションでは、以下のレンダリング方式が利用可能です：
アプリケーション構造による分類
- MPA（Multi-Page Application）: 従来型の複数ページアプリケーション
- SPA（Single-Page Application）: 単一ページで動的に内容を切り替えるアプリケーション
レンダリング実行場所による分類
- CSR（Client-Side Rendering）: ブラウザでレンダリング
- SSR（Server-Side Rendering）: サーバーでレンダリング
- SSG（Static Site Generation）: ビルド時に事前レンダリング
高度なレンダリング方式
- ISR（Incremental Static Regeneration）: 静的生成の段階的更新
- SSR with Streaming: ストリーミングによる段階的 SSR
- PPR（Partial Prerendering）: 静的・動的部分の混合レンダリング
配信方式とレンダリング方式の整理
重要な概念の区別
レンダリング方式を理解する上で、配信方式とレンダリング実行場所を明確に区別することが重要です。
配信方式の分類
静的配信（S3 + CloudFront）
- 事前に作成されたファイルをそのまま配信
- HTML、CSS、JavaScript ファイルが固定
- キャッシュ効率が高く、高速・低コスト
動的配信（App Runner / ECS + ALB）
- リクエストごとにサーバーで処理・生成
- データベース参照、API 呼び出し等が可能
- リアルタイム性が高いが、サーバー負荷あり
レンダリング実行場所の分類
クライアントサイドレンダリング（CSR）
- ブラウザ上で JavaScript が DOM を生成
- 配信は静的ファイルでも、実行時に動的に構築
サーバーサイドレンダリング（SSR）
- サーバー上で HTML を生成してから配信
- 必然的に動的配信となる
混乱しやすいパターンの整理
SPA (CSR) + 静的配信
ビルド時: React → bundle.js + index.html（ほぼ空）
配信: S3 + CloudFront（静的ファイル）
実行: ブラウザで bundle.js が全画面を動的生成
重要ポイント
- 配信方式：静的（SSG と同じ S3 + CloudFront）
- レンダリング：CSR（ブラウザで実行）
- SEO：弱い（初期 HTML が空のため）
SSG + 静的配信
ビルド時: Next.js → 完成した HTML + 小さな JS
配信: S3 + CloudFront（静的ファイル）
実行: HTML はそのまま表示、JS でインタラクティブ化
重要ポイント
- 配信方式：静的（CSR と同じ S3 + CloudFront）
- レンダリング：事前生成（ビルド時に完了）
- SEO：強い（完成した HTML が配信される）
SSR + 動的配信
リクエスト時: サーバーで HTML 生成 → 配信
配信: App Runner / ECS（動的生成）
実行: 完成した HTML + ハイドレーション
重要ポイント
- 配信方式：動的（リクエストごとに生成）
- レンダリング：サーバーサイド（配信前に完了）
- SEO：強い（完成した HTML が配信される）
AWS サービス選択の決定要因
| 配信方式 | 成果物の特徴 | AWS 構成 | コスト | 用途 |
|---|---|---|---|---|
| 静的配信 | 事前作成ファイル | S3 + CloudFront | 低 | CSR、SSG、手書き HTML |
| 動的配信 | リクエスト時生成 | App Runner / ECS | 高 | SSR、ISR、従来型 Web アプリ |
主要 AWS サービスの特徴と役割
静的コンテンツ配信サービス
Amazon S3（Simple Storage Service）
- 役割: 静的ファイルの保存・配信
- 特徴: 高可用性（99.999999999%）、容量無制限、低コスト
- 適用: HTML、CSS、JavaScript、画像ファイルの保存
Amazon CloudFront（CDN）
- 役割: 世界中のエッジロケーションでコンテンツキャッシュ
- 特徴: 低レイテンシ配信、HTTPS 証明書自動管理、WAF 統合
- 適用: 静的・動的コンテンツの高速配信
アプリケーション実行サービス
AWS App Runner
- 役割: サーバーレスコンテナ実行環境
- 特徴: 自動スケーリング（0〜25 インスタンス）、運用負荷最小
- 適用: SSR アプリケーション、小〜中規模システム
- 制約: VPC 配置不可、パブリック通信のみ
Amazon ECS + ALB
- 役割: コンテナオーケストレーション + ロードバランサー
- 特徴: VPC 内配置、詳細制御、高スケーラビリティ
- 適用: 大規模 SSR、企業向けシステム、マイクロサービス
- 制約: 運用複雑、最小コスト高め
統合開発・デプロイサービス
AWS Amplify
- 役割: フルスタック開発プラットフォーム
- 特徴: Git 連携 CI/CD、ブランチ別環境、フォーム処理
- 適用: SSG サイト、JAMstack アプリケーション
- 内部構成: CloudFront + S3 + Lambda
API Gateway + Lambda
- 役割: API エンドポイント + サーバーレス処理
- 特徴: 自動スケーリング、従量課金、認証・認可統合
- 適用: CSR のバックエンド API、マイクロサービス
セキュリティ・パフォーマンス強化
AWS WAF（Web Application Firewall）
- 役割: Web アプリケーション保護
- 特徴: DDoS 対策、地理的制限、レート制限
- 適用: CloudFront、ALB への攻撃対策
Lambda@Edge / CloudFront Functions
- 役割: エッジでの処理実行
- 特徴: 低レイテンシ、A/B テスト、認証処理
- 適用: パーソナライゼーション、リダイレクト
レンダリング方式と AWS サービスの対応表
| レンダリング方式 | 成果物 | 推奨 AWS サービス | 理由 |
|---|---|---|---|
| MPA | 静的/動的ページ | S3 + CloudFront または ECS + ALB | シンプルな構成、従来型開発 |
| SPA (CSR) | 静的ファイル | S3 + CloudFront | 静的配信に最適 |
| SPA (SSR) | サーバーアプリ | App Runner または ECS + ALB | サーバーレス vs スケーラビリティ |
| SSG | 静的ファイル | Amplify または S3 + CloudFront | CI/CD 統合 vs カスタマイズ性 |
| ISR | 静的+動的 | Amplify + Lambda または Next.js on App Runner | 段階的更新に対応 |
| SSR + Streaming | サーバーアプリ | App Runner または ECS + ALB | ストリーミング対応 |
| PPR | 混合型 | 複数サービス組み合わせ | 静的・動的部分別構成 |
各レンダリング方式の詳細と AWS 構成
MPA（Multi-Page Application）
方式の特徴
- 従来型の Web アプリケーション構造
- ページ遷移時に完全なページリロードが発生
- SEO に優れ、実装がシンプル
- JavaScript に依存しない基本機能
AWS 構成パターン
静的 MPA: S3 + CloudFront
User Browser → CloudFront → S3 (HTML/CSS/JS/画像)
動的 MPA: ECS + ALB
User Browser → CloudFront (任意) → ALB → ECS (サーバーサイドアプリ)
AWS 選択理由
- 静的コンテンツ中心: S3 + CloudFront が最コスト効率
- 動的処理が必要: ECS + ALB で従来型サーバーサイド処理
- 企業サイトやブログ: 安定性と SEO 重視
SPA（Single-Page Application）
CSR 版 SPA 構成
方式の特徴
- JavaScript が動的に DOM を生成
- 初期 HTML は空で、クライアントで全てレンダリング
- 高いインタラクティブ性
- 初期ロード時間と SEO 課題
AWS 構成: S3 + CloudFront
User Browser
↓
CloudFront (CDN)
↓
S3 (静的ファイル保存)
↓
API Gateway + Lambda (API呼び出し時)
なぜこの構成なのか
- 静的ファイルの配信に最適化
- グローバル CDN でパフォーマンス向上
- 低コスト・高可用性
- SPA のルーティング対応（404→index.html）
SSR 版 SPA 構成
方式の特徴
- サーバーで HTML を生成しつつ SPA の利点を維持
- 初期ロードの高速化と SEO 対応
- ハイドレーションによるインタラクティブ化
AWS 構成: App Runner または ECS + ALB
User Request → CloudFront (任意) → App Runner/ECS (Node.js等)
SSG（Static Site Generation）
方式の特徴
- ビルド時に静的 HTML を生成
- CDN で高速配信可能
- コンテンツ更新時は再ビルドが必要
AWS 構成選択肢
Amplify 構成（推奨：小〜中規模）
Git Repository → Amplify (CI/CD + Hosting) → CloudFront + S3
S3 + CloudFront 構成（推奨：大規模・カスタム要件）
CI/CD Pipeline → S3 (静的ファイル配置) → CloudFront (配信)
使い分けの指針
| 要件 | 推奨 | 理由 |
|---|---|---|
| 迅速な立ち上げ | Amplify | CI/CD が標準装備 |
| 複雑なキャッシュ戦略 | S3 + CloudFront | 細かい制御が可能 |
| 複数環境管理 | Amplify | ブランチ別デプロイ |
| コスト重視 | S3 + CloudFront | 従量課金で最適化しやすい |
ISR（Incremental Static Regeneration）
方式の特徴
- 静的生成の利点を保ちつつ、段階的にコンテンツ更新
- アクセス時に必要に応じて再生成
- 大規模サイトでのビルド時間問題を解決
AWS 構成パターン
Next.js + Amplify
Git Repository → Amplify → Lambda@Edge (再生成) → CloudFront → S3
Next.js + App Runner
User Request → CloudFront → App Runner (Next.js) → DynamoDB (キャッシュ管理)
AWS 選択理由
- Amplify: Next.js との統合が優秀、管理負荷最小
- App Runner: より細かい制御とカスタムキャッシュ戦略
SSR with Streaming
方式の特徴
- HTML を段階的にストリーミング送信
- 重要なコンテンツを先に表示
- ページの体感パフォーマンス向上
AWS 構成: App Runner または ECS + ALB
User Request → CloudFront → App Runner/ECS (Streaming対応サーバー)
AWS 選択理由
- ストリーミング機能をサポートするコンテナ環境が必要
- App Runner: 管理負荷最小、小〜中規模向け
- ECS + ALB: 高度な制御、大規模向け
PPR（Partial Prerendering）
方式の特徴
- 1 ページ内で静的・動的部分を混合
- 静的部分は事前生成、動的部分はランタイム生成
- Next.js 等で実験的に提供
AWS 構成: 複数サービス組み合わせ
User Request
↓
CloudFront
├── 静的部分 → S3
└── 動的部分 → Lambda/App Runner
AWS 技術選定の決定指針
プロジェクト規模別推奨構成
| 規模 | CSR | SSG | SSR | 理由 |
|---|---|---|---|---|
| 小規模 | S3 + CloudFront | Amplify | App Runner | 管理負荷最小 |
| 中規模 | S3 + CloudFront | Amplify / S3+CF | App Runner / ECS | 要件に応じて選択 |
| 大規模 | S3 + CF + WAF | S3 + CF + CI/CD | ECS + ALB + AutoScaling | スケーラビリティ重視 |
要件別選択マトリックス
開発・運用負荷重視
| 運用負荷 | サービス | 適用場面 |
|---|---|---|
| 最小 | Amplify (SSG) / App Runner (SSR) | スタートアップ、プロトタイプ |
| 中程度 | S3 + CloudFront + CI/CD | 標準的な開発チーム |
| カスタム | ECS + ALB + 詳細設定 | エンタープライズ、特殊要件 |
パフォーマンス重視
| 最適化ポイント | 推奨方式 | AWS 構成 |
|---|---|---|
| 初期ロード速度 | SSG | S3 + CloudFront |
| SEO 最適化 | SSR / SSG | App Runner / Amplify |
| インタラクティブ性 | CSR / SPA | S3 + CloudFront |
| 大規模コンテンツ | ISR | Next.js + Amplify |
コスト重視
コスト効率順位
- S3 + CloudFront (CSR/SSG): 最もコスト効率が良い
- Amplify (SSG): 中程度のコスト、高機能
- App Runner (SSR): 従量制サーバー、中程度のコスト
- ECS + ALB (SSR): 高機能だが高コスト
セキュリティ・パフォーマンス強化
WAF（Web Application Firewall）統合
Internet → WAF (攻撃ブロック) → CloudFront → Origin
保護対象
- SQL インジェクション、XSS
- DDoS 攻撃、ボット攻撃
- 地理的制限、レート制限
エッジコンピューティング活用
Lambda@Edge / CloudFront Functions
- A/B テスト、パーソナライゼーション
- リダイレクト、ヘッダー操作
- 認証・認可処理
実装上の注意点とベストプラクティス
SPA ルーティング対応
CloudFront Error Pages設定
404 → /index.html (200レスポンス)
403 → /index.html (200レスポンス)
CORS 対応
CloudFrontでオリジン統合
/api/* → API Gateway
/app/* → S3
キャッシュ戦略
静的リソース: 1年キャッシュ + immutable
HTML: 短時間キャッシュ + ETag
API: キャッシュなし or 短時間
まとめ
レンダリング方式別の最適解
- MPA: 従来型アプリに最適、SEO 重視
- CSR: インタラクティブアプリ、S3+CloudFront が鉄板
- SSR: SEO とパフォーマンス両立、App Runner 推奨
- SSG: 静的サイト最高効率、Amplify 活用
- ISR: 大規模コンテンツサイト、Next.js 連携
- PPR: 新しい手法、柔軟な構成が必要
AWS 選択時の重要ポイント
- 運用負荷 vs カスタマイズ性のトレードオフ
- コスト vs パフォーマンスのバランス
- チームのスキルセットとの適合性
- セキュリティ要件への対応
Discussion