WEB PLATFORM / ARCHITECTURE DECISION

SSR基盤の技術選定ガイド
Nginx × Node.js / Bun / Deno

フロントエンド SSR を前提に、Web サーバーと実行環境の役割、Nginx を置く理由、ランタイム選定、および官公庁・大規模案件のセキュリティ・長期運用・説明責任までを一枚の技術選定資料に整理。

SSR / Next.js・Nuxt等Docker / Kubernetesセキュリティ・運用設計公共調達を想定
01

まず結論

NGINX

必須ではなく、前段の選択肢

TLS終端、経路制御、静的配信、アクセス制御を担う。CDN・WAF・ロードバランサー・Ingress/Gatewayが同じ役割を提供するなら省略を検討できる。

RUNTIME

公共・大規模なら Node.js LTS を基準線

Node.js + npmをベースラインにして、Bun・Denoは互換性、運用実績、セキュリティ、実測性能で比較する。

DEPLOYMENT

まず「3コンテナ」を整理

① Nginx ② SSR(Node/Bun/Deno)③ API。DB、監視、CDN/WAFなどは必要に応じて追加。Nginx と SSR を同居させる必然性はない。

判断の順序:「SSR が本当に必要か」→「フレームワークの本番実行方式」→「前段に必要なネットワーク機能」→「ランタイム選定」→「公共調達・運用要件を満たすか」。
npm はパッケージマネージャーであり、Node.js と同じ種類のランタイムではない。Bun はランタイム兼パッケージ管理等のツール群、Deno はランタイム兼統合ツール群。
02

Nginx と SSR の役割

静的サイト(SSG / CSR のビルド成果物)

ブラウザHTTPS リクエスト
受信
NginxHTML / CSS / JS / 画像を配信

Nginx だけで配信可能。動的な API は別途存在してよい。

動的 SSR(Next.js / Nuxt 等)

ブラウザページを要求
HTTPS
Nginx(任意の前段)TLS・ルーティング・制御
HTTP 内部通信
SSR アプリNode.js / Bun / Deno が実行
API 呼び出し等
バックエンド API認可・業務ロジック・DB アクセス
重要:Node.js・Bun・Deno 自体でも HTTP サーバーを提供できるため、Nginx がないと SSR できないわけではない。Nginx は「HTTP の入口の品質と制御」を補助するものであり、React / Vue の SSR の実行エンジンではない。また、SSR はフロントエンドでありながらサーバー側コードを実行するため、秘密情報・認証・監視の対象となる。
03

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 を置く?

以下は初期検討用の目安です。調達・セキュリティ要件の代わりにはなりません。

現時点では要件未選択。入口に必要な機能から判定してください。
04

Node.js + npm / Bun / Deno 比較

「SSR フレームワークが想定する実行環境」と「組織が確実に保守できる環境」を最重視。単純なベンチマーク結果だけでは結論を出さない。

判断項目Node.js + npmBunDeno
位置づけ標準的な JavaScript ランタイム + npmランタイム・パッケージ管理・テスト・ビルド等の統合環境ランタイム・権限制御・開発ツールの統合環境
SSR の適用Next.js / Nuxt 等で広範な採用・運用例Next.js 等を実行可能。使用機能と実環境を検証npm/Node 互換機能あり。フレームワーク・依存性を要検証
互換性npm エコシステムの基準高い Node 互換性を志向。差異・未実装が残るNode/npm 互換を提供。構成・権限設定で差異
セキュリティの特徴成熟した周辺ツールと長期の運用知見一体型ツール構成。OS/コンテナ側の分離が基本ファイル・通信・環境変数等をデフォルトで権限制御
パフォーマンス堅実な比較基準起動やツール処理速度に強み。SSRの実測はアプリ依存実装・負荷特性次第。要ベンチマーク
ライフサイクル管理公開された LTS / EOL スケジュールが明確アップデートと互換性検証方針を個別策定アップデートと互換性検証方針を個別策定
大規模運用の初期評価第一候補PoC候補要件適合時にPoC
2026年10月23日時点の Node.js:24.x は LTS 系列、26.x は Current 系列で、26.x の LTS 移行予定日は 2026年10月28日。新規の長期本番運用では採用日と EOL、フレームワーク要件を確認し、LTS 系列から選ぶことを基本とする。公式リリーススケジュール参照。
05

選択を決める判断軸

01

フレームワークとの適合性(最優先)

Next.js、Nuxt、React Router 等の本番実行方式、プラグイン、画像最適化、ストリーミング SSR、Edge 機能、ネイティブモジュールを再現できるか。

02

保守期間・バージョン固定・脆弱性対応

サポート終了までの余裕、CVE 公表時の対応、パッチ取得、ロールバック、運用委託先の習熟度。

03

非機能要求に対する実測性能

平均値だけでなく p95/p99 応答、同時接続、初期表示、ストリーミング、メモリ、CPU、コールドスタート、障害回復を比較。

04

依存関係・サプライチェーン管理

ロックファイル、再現可能ビルド、SBOM、脆弱性スキャン、パッケージの出所と更新頻度、ネイティブ依存の有無。

05

組織・チームの運用成熟度

監視、障害解析、標準イメージ、CI/CD、教育、引き継ぎ、外部ベンダーの支援可否。人材確保が技術上の速度差を上回ることもある。

06

導入・移行費用を含む総保有コスト

PoC、互換性検証、CI 適合、運用手順書、監査証跡、アップグレード費用を含めて比較。npm を Bun に置き換えるだけの採用も独立して評価可能。

選び方の現実的なパターン

安定重視

Node.js LTS + npm

既存知見が豊富で、調達・監査・引継ぎに説明しやすい。

性能・開発効率

Bun を比較候補

まず Bun をパッケージマネージャーとして評価し、実行ランタイムの切替は別ゲートで判断。

権限制御

Deno を比較候補

最小権限と依存パッケージの動作、ネイティブ機能に抜け道がないかを検証。

06

官公庁・大規模案件で追加する観点

公共案件では「動く」だけでなく「要求を証明できる」「長く直せる」「組織として維持できる」ことが重要。下表は典型的な評価項目であり、実際の必須要件は対象機関・システム分類・調達仕様・適用規程によって異なる。

評価領域求められる具体的な証跡・設計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

権限制御の効果を評価。ネイティブ依存と実行許可設定、運用技能まで確認。

07

リファレンス構成(3コンテナ)

利用者のブラウザHTML / JS / CSS
HTTPS
CDN / WAF / Load Balancer(必要に応じて)TLS 終端・防御・負荷分散
HTTP(S) / 内部ネットワーク
① Nginx コンテナ(任意)/ → SSR / /api/ → API
↓ ページ描画             ↓ API 経路
② SSR コンテナNext.js / Nuxt + Node・Bun・Deno
③ API コンテナGo / Java / Python など
SSR → API へ内部 HTTP 呼び出しも可能(認証・接続先を別途設計)
データ層 / 外部システムDB・キャッシュ・ID基盤・監視など
公開するのは原則入口のみ内部コンテナは直接インターネットに公開しないDBは通常別サービス・別構成
注意:①+②をひとつのコンテナにする構成も可能。ただし、プロセスの独立監視・パッチ適用・スケール・ログ設計が複雑になりやすいため、通常は分離を推奨。Kubernetes では Nginx コンテナを自前で置かず、Ingress Controller やクラウド Gateway を入口にする構成も一般的。
08

最低限の構成例

動作関係を示すための学習用サンプルです。TLS がロードバランサーで終端され、Nginx に内部 HTTP で到達する想定。実運用では LB 信頼境界・Forwarded ヘッダー・ヘルスチェック・シークレット・ネットワークポリシーを個別設計してください。

compose.yaml(概念構成)
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
nginx.conf(簡易ルーティング例)
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 情報を適切に受け継ぐ設計が必要。ユーザーが任意に送るヘッダーを無条件で信頼しない。

本番配備前にはコンテナイメージの固定、非 root 実行、読み取り専用ファイルシステム、リソース制限、ヘルスチェック、リトライ・タイムアウト、証明書、ログ集約、CSP / Cookie 設計等を追加。上例だけで公共システムのセキュリティ要件を満たすわけではありません。
09

PoC と受入基準のひな型

以下の条件が揃えば、Node.js / Bun / Deno の比較結果に監査可能な根拠を持たせやすくなります。

  1. 同条件のデプロイ
    同じSSRフレームワーク、同じ依存パッケージ、同じ入力データ、同一クラスのCPU・RAM・ネットワーク。
  2. 互換性確認
    認証、動的ルート、画像最適化、フォーム、Streaming SSR、例外処理、ファイル・暗号API、ネイティブ依存。
  3. 性能と資源使用量
    同時接続・ピーク負荷・ウォームアップ・長時間運転で p50/p95/p99、エラー率、CPU、メモリ、起動時間を記録。
  4. セキュリティ検証
    SAST/DAST/SCA、SBOM、イメージスキャン、権限チェック、秘密情報漏えい、キャッシュ・認証境界確認。
  5. 運用・復旧検証
    異常終了時の再起動、ローリング更新、ロールバック、ログ相関、アラート、構成変更の監査証跡。
  6. 選定理由の記録
    評価尺度、証跡URL、残リスク、保守責任、更新方針、再評価時期を設計審査記録として残す。
p95 / p99 レイテンシエラー率RSS / CPU脆弱性是正時間復旧時間サポート終了日
最終的な推奨:官公庁等の長期保守案件で、フレームワーク上の特別な要件がなければ「Node.js のサポート対象 LTS + SSR + マネージド入口(なければ Nginx) + 独立した API」を比較の基準構成とする。Bun / Deno を排除するのではなく、上記 PoC と保守・監査条件を通過した場合に採用する。
REF

参考資料・一次情報

  1. Next.js 公式|Self-Hostingリバースプロキシ推奨、配備時の考慮点
  2. Node.js Release Working Group|リリースと LTS / EOL2026年10月時点のサポート系列と予定日
  3. Bun 公式|Node.js CompatibilityNode.js 互換性と差分の詳細
  4. Bun 公式|Next.js と Bun開発・本番SSRサーバーの実行例
  5. Deno 公式|Security and Permissionsデフォルト権限・許可設定と限界
  6. Deno 公式|Node and npm Compatibilitynpm / Node互換性
  7. 国家サイバー統括室|政府機関等の統一基準群令和7年度版、令和8年6月のガイドライン一部改定を含む掲載ページ
  8. デジタル庁|デジタル社会推進標準ガイドライン政府情報システムの整備・管理、セキュリティ・バイ・デザイン等
  9. デジタル庁|ISMAPクラウドサービスリスト更新(2026年9月)対象クラウドサービスのリストと評価制度
  10. 国家サイバー統括室|主要公表資料政府調達におけるセキュリティ要件策定資料など