SSR基盤の技術選定ガイド
Nginx × Node.js / Bun / Deno
フロントエンド SSR を前提に、Web サーバーと実行環境の役割、Nginx を置く理由、ランタイム選定、および官公庁・大規模案件のセキュリティ・長期運用・説明責任までを一枚の技術選定資料に整理。
まず結論
必須ではなく、前段の選択肢
TLS終端、経路制御、静的配信、アクセス制御を担う。CDN・WAF・ロードバランサー・Ingress/Gatewayが同じ役割を提供するなら省略を検討できる。
公共・大規模なら Node.js LTS を基準線
Node.js + npmをベースラインにして、Bun・Denoは互換性、運用実績、セキュリティ、実測性能で比較する。
まず「3コンテナ」を整理
① Nginx ② SSR(Node/Bun/Deno)③ API。DB、監視、CDN/WAFなどは必要に応じて追加。Nginx と SSR を同居させる必然性はない。
npm はパッケージマネージャーであり、Node.js と同じ種類のランタイムではない。Bun はランタイム兼パッケージ管理等のツール群、Deno はランタイム兼統合ツール群。
Nginx と SSR の役割
静的サイト(SSG / CSR のビルド成果物)
Nginx だけで配信可能。動的な API は別途存在してよい。
動的 SSR(Next.js / Nuxt 等)
Nginx が必要になる場面
| 条件 | Nginx の価値 | 別の選択肢/注意点 |
|---|---|---|
| SSL/TLS 終端、証明書管理 | 複数アプリの入口を一元化できる | マネージド LB / CDN で代替可能 |
| 複数サイト・API をドメイン/パスで振り分け | / → SSR、/api/ → API などを統合 | クラウド Gateway / Kubernetes Ingress でも実現 |
| リクエスト制限・アクセス制御 | リクエストサイズ、タイムアウト、IP制限等の入口制御 | WAF 専用製品に任せる領域と区別する。Nginx 単体は WAF と同義ではない |
| 静的ファイル・キャッシュ・圧縮 | 大容量アセットを効率的に配信 | CDN のほうが有利な場合も多い。SSR の HTML を無条件にキャッシュしない |
| バックエンドの直接公開防止 | SSR・API を内部ネットワークに閉じやすい | LB、ネットワークポリシー、Firewall でも実現する |
| 高可用性/可観測性 | アクセスログ・リクエスト追跡・ヘルスチェック連携の入口 | 複数 Nginx またはマネージド入口が必要。Nginx 1台だけなら単一障害点 |
置くことを優先
- オンプレ/VPSで TLS や複数サービスを自前運用
- 入口で要求制御・リバースプロキシを明示的に設計
- 組織の標準構成に Nginx が含まれる
省略も合理的
- マネージド LB / CDN / WAF が役割を満たす
- 1つの SSR アプリで追加のルーティング要件がない
- 運用コンポーネント数を減らす効果が大きい
簡易チェック:前段に Nginx を置く?
以下は初期検討用の目安です。調達・セキュリティ要件の代わりにはなりません。
Node.js + npm / Bun / Deno 比較
「SSR フレームワークが想定する実行環境」と「組織が確実に保守できる環境」を最重視。単純なベンチマーク結果だけでは結論を出さない。
| 判断項目 | Node.js + npm | Bun | Deno |
|---|---|---|---|
| 位置づけ | 標準的な JavaScript ランタイム + npm | ランタイム・パッケージ管理・テスト・ビルド等の統合環境 | ランタイム・権限制御・開発ツールの統合環境 |
| SSR の適用 | Next.js / Nuxt 等で広範な採用・運用例 | Next.js 等を実行可能。使用機能と実環境を検証 | npm/Node 互換機能あり。フレームワーク・依存性を要検証 |
| 互換性 | npm エコシステムの基準 | 高い Node 互換性を志向。差異・未実装が残る | Node/npm 互換を提供。構成・権限設定で差異 |
| セキュリティの特徴 | 成熟した周辺ツールと長期の運用知見 | 一体型ツール構成。OS/コンテナ側の分離が基本 | ファイル・通信・環境変数等をデフォルトで権限制御 |
| パフォーマンス | 堅実な比較基準 | 起動やツール処理速度に強み。SSRの実測はアプリ依存 | 実装・負荷特性次第。要ベンチマーク |
| ライフサイクル管理 | 公開された LTS / EOL スケジュールが明確 | アップデートと互換性検証方針を個別策定 | アップデートと互換性検証方針を個別策定 |
| 大規模運用の初期評価 | 第一候補 | PoC候補 | 要件適合時にPoC |
選択を決める判断軸
フレームワークとの適合性(最優先)
Next.js、Nuxt、React Router 等の本番実行方式、プラグイン、画像最適化、ストリーミング SSR、Edge 機能、ネイティブモジュールを再現できるか。
保守期間・バージョン固定・脆弱性対応
サポート終了までの余裕、CVE 公表時の対応、パッチ取得、ロールバック、運用委託先の習熟度。
非機能要求に対する実測性能
平均値だけでなく p95/p99 応答、同時接続、初期表示、ストリーミング、メモリ、CPU、コールドスタート、障害回復を比較。
依存関係・サプライチェーン管理
ロックファイル、再現可能ビルド、SBOM、脆弱性スキャン、パッケージの出所と更新頻度、ネイティブ依存の有無。
組織・チームの運用成熟度
監視、障害解析、標準イメージ、CI/CD、教育、引き継ぎ、外部ベンダーの支援可否。人材確保が技術上の速度差を上回ることもある。
導入・移行費用を含む総保有コスト
PoC、互換性検証、CI 適合、運用手順書、監査証跡、アップグレード費用を含めて比較。npm を Bun に置き換えるだけの採用も独立して評価可能。
選び方の現実的なパターン
Node.js LTS + npm
既存知見が豊富で、調達・監査・引継ぎに説明しやすい。
Bun を比較候補
まず Bun をパッケージマネージャーとして評価し、実行ランタイムの切替は別ゲートで判断。
Deno を比較候補
最小権限と依存パッケージの動作、ネイティブ機能に抜け道がないかを検証。
官公庁・大規模案件で追加する観点
公共案件では「動く」だけでなく「要求を証明できる」「長く直せる」「組織として維持できる」ことが重要。下表は典型的な評価項目であり、実際の必須要件は対象機関・システム分類・調達仕様・適用規程によって異なる。
| 評価領域 | 求められる具体的な証跡・設計 | SSR/Nginx/ランタイムへの影響 |
|---|---|---|
| 適用規程・調達 | 仕様書・設計書と「政府機関等の統一基準群」「デジタル社会推進標準ガイドライン」の該当項目の対応表 | 「Bun が禁止」「Nginx が必須」といった一律の決めつけは避ける |
| クラウド選定 | ISMAP 等の適用確認、対象サービス・提供範囲・契約・データ所在の確認 | ISMAP はクラウドサービスの評価制度。Node/Bun/Deno 自体の適合証明ではない |
| 脆弱性管理 | 資産台帳、SBOM、CVE 監視、パッチ期限、修正結果、例外承認記録 | OS、Nginx、ランタイム、npm 依存、コンテナイメージを一体管理 |
| 認証・認可 | セッション保護、権限制御、CSRF/XSS 対策、秘密情報管理、個人情報を含むログの最小化 | SSR はサーバーで機微データに触れる。HTML キャッシュとログに特に注意 |
| 可用性・復旧 | SLO、RTO/RPO、冗長化、障害訓練、バックアップ、切戻し手順 | Nginx・SSR・API 各層の単一障害点を排除し、起動・停止時の挙動を検証 |
| 監査・運用 | アクセスログ、相関ID、権限変更、デプロイ履歴、保管期間、改ざん対策 | Nginx と SSR/API でトレースIDを伝播。監視・アラート・当番体制を整備 |
| サプライチェーン | バージョン固定、署名・来歴、CI/CD の権限分離、依存物スキャン、成果物の再現性 | ランタイム採否よりも継続した更新・再ビルド体制が重要 |
| 保守・ベンダーロック | 引継ぎ資料、技術者層、保守体制、代替可能性、契約期間内の EOL 回避 | 選定理由と交換可能な境界(SSRアプリ単位)を文書化 |
| 性能・負荷 | ピーク想定、負荷試験記録、p95/p99、静的配信・動的ページ・API の分離計測 | ランタイム比較は同じアプリ・同じ設定・同じ負荷で実施 |
Node.js LTS
サポート期限と経験あるベンダーの確保が説明しやすい。ただし脆弱性ゼロを意味しない。
Bun
本番採用は互換性試験、保守体制、監視、更新経路、障害時の代替手段を承認条件に。
Deno
権限制御の効果を評価。ネイティブ依存と実行許可設定、運用技能まで確認。
リファレンス構成(3コンテナ)
/ → SSR / /api/ → API最低限の構成例
動作関係を示すための学習用サンプルです。TLS がロードバランサーで終端され、Nginx に内部 HTTP で到達する想定。実運用では LB 信頼境界・Forwarded ヘッダー・ヘルスチェック・シークレット・ネットワークポリシーを個別設計してください。
services:
nginx:
image: nginx:stable-alpine # 本番では検証済みの固定タグ/ダイジェストを使用
ports: ["8080:80"] # 例示用。公開経路は環境に応じて設計
volumes:
- ./nginx.conf:/etc/nginx/conf.d/default.conf:ro
depends_on: [frontend, api]
networks: [web]
frontend:
build: ./frontend # Node/Bun/Deno + SSR アプリ
expose: ["3000"] # ホストへは公開しない
networks: [web]
api:
build: ./backend
expose: ["8080"]
networks: [web]
networks:
web:
driver: bridge
server {
listen 80;
server_name _;
# API コンテナが /api/ を受け取る想定
location /api/ {
proxy_pass http://api:8080;
proxy_http_version 1.1;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_read_timeout 30s;
}
location / {
proxy_pass http://frontend:3000;
proxy_http_version 1.1;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
# Streaming SSR を妨げないための一例
proxy_buffering off;
proxy_read_timeout 60s;
}
}
注意:この Nginx が HTTP で受ける場合、$scheme は http。上流 LB で HTTPS 終端しているなら、信用する LB からの Forwarded 情報を適切に受け継ぐ設計が必要。ユーザーが任意に送るヘッダーを無条件で信頼しない。
PoC と受入基準のひな型
以下の条件が揃えば、Node.js / Bun / Deno の比較結果に監査可能な根拠を持たせやすくなります。
- 同条件のデプロイ同じSSRフレームワーク、同じ依存パッケージ、同じ入力データ、同一クラスのCPU・RAM・ネットワーク。
- 互換性確認認証、動的ルート、画像最適化、フォーム、Streaming SSR、例外処理、ファイル・暗号API、ネイティブ依存。
- 性能と資源使用量同時接続・ピーク負荷・ウォームアップ・長時間運転で p50/p95/p99、エラー率、CPU、メモリ、起動時間を記録。
- セキュリティ検証SAST/DAST/SCA、SBOM、イメージスキャン、権限チェック、秘密情報漏えい、キャッシュ・認証境界確認。
- 運用・復旧検証異常終了時の再起動、ローリング更新、ロールバック、ログ相関、アラート、構成変更の監査証跡。
- 選定理由の記録評価尺度、証跡URL、残リスク、保守責任、更新方針、再評価時期を設計審査記録として残す。
参考資料・一次情報
- Next.js 公式|Self-Hostingリバースプロキシ推奨、配備時の考慮点
- Node.js Release Working Group|リリースと LTS / EOL2026年10月時点のサポート系列と予定日
- Bun 公式|Node.js CompatibilityNode.js 互換性と差分の詳細
- Bun 公式|Next.js と Bun開発・本番SSRサーバーの実行例
- Deno 公式|Security and Permissionsデフォルト権限・許可設定と限界
- Deno 公式|Node and npm Compatibilitynpm / Node互換性
- 国家サイバー統括室|政府機関等の統一基準群令和7年度版、令和8年6月のガイドライン一部改定を含む掲載ページ
- デジタル庁|デジタル社会推進標準ガイドライン政府情報システムの整備・管理、セキュリティ・バイ・デザイン等
- デジタル庁|ISMAPクラウドサービスリスト更新(2026年9月)対象クラウドサービスのリストと評価制度
- 国家サイバー統括室|主要公表資料政府調達におけるセキュリティ要件策定資料など