🏆 フロントエンドランキング 2026年4月

このページは「日本の労働安全衛生法で義務化されている 従業員ストレスチェックシステム」を Vercel + Amazon Aurora 構成で構築する際に、どのフロントエンドフレームワークを選ぶべきかを 2026年4月時点の情報で評価・ランキングしたものです。

フレームワーク選定で失敗しやすいのは「流行」で選ぶことです。本ページでは このシステムの特性（フォーム主体・DB接続・法令対応）に照らして実務的に評価します。

Vercelが開発するNext.jsは、Vercel環境との統合が他の追随を許さないレベルです。 App RouterとReact 19のServer Actionsにより、フォーム送信からDB書き込みまでをサーバー側で完結できます。 React Server Components（RSC）でレポート生成をサーバーで処理し、クライアントに最小限のJSを送るアーキテクチャはストレスチェックシステムに最適です。

// app/actions/stress-check.ts
'use server';
import { z } from 'zod';
import { db } from '@/lib/db';

const schema = z.object({
  employeeId: z.string().min(1),
  answers: z.array(z.number().min(1).max(5)),
});

export async function submitStressCheck(formData: FormData) {
  const raw = Object.fromEntries(formData);
  const parsed = schema.safeParse(raw);
  if (!parsed.success) return { error: parsed.error.flatten() };

  await db.insert(stressCheckAnswers).values({
    employeeId: parsed.data.employeeId,
    answers: parsed.data.answers,
    submittedAt: new Date(),
  });

  return { success: true };
}

SvelteKit 2はVercel公式アダプター（@sveltejs/adapter-vercel）を持ち、Edge FunctionsとServerless Functionsの両方に対応します。 Svelte 5のRunesシステムはTypeScriptとの親和性が非常に高く、コンパイル時に仮想DOMを使わないため、 バンドルサイズが最小クラスです。フォーム処理の使いやすさは8フレームワーク中トップクラスで、 Progressive EnhancementによるJSなしフォーム送信も標準サポートしています。

// src/routes/stress-check/+page.server.ts
import type { Actions } from './$types';
import { fail } from '@sveltejs/kit';
import { z } from 'zod';
import { db } from '$lib/db';

export const actions: Actions = {
  submit: async ({ request, locals }) => {
    const formData = await request.formData();
    const parsed = schema.safeParse(Object.fromEntries(formData));
    if (!parsed.success) return fail(400, { errors: parsed.error.flatten() });

    await db.insert(stressCheckTable).values(parsed.data);
    return { success: true };
  }
};

Nuxt 4はNitroサーバーエンジンを採用し、Vercelへのデプロイに対応しています。 Vue 3.5のリアクティビティシステムとPiniaによる状態管理、VueUseの豊富なComposablesにより エンタープライズシステムの構築に十分な成熟度があります。 日本ではVue.jsの採用率が高く、既存チームのスキルを活かせるケースが多いです。 ただし、NitroのVercel統合はNext.jsほど深くなく、いくつかの機能（PPR等）は利用できません。

Astro 5のIslands ArchitectureはJSを最小限に抑えるため、 レポート閲覧ページ（ほぼ静的）に非常に向いています。 Server Islands機能でAuroraからデータを取得してHTMLを生成し、 一部のインタラクティブなUIコンポーネントだけをハイドレーションする設計が可能です。 ただし、80〜120問の動的フォームは苦手領域で、ReactやVueのコンポーネントを 島として埋め込む形になり、複雑度が増します。ストレスチェックシステムでは レポート中心のサブサービスや管理画面の静的部分には向きますが、 メインのアンケートフォームには別フレームワークとの組み合わせが必要になりえます。

2024年にRemixとReact Router v7が統合され、新たな「React Router v7フレームワークモード」となりました。 WebネイティブのFetch API・FormData・URLSearchParamsを活用したフォーム処理はフレームワーク中最もシンプルで、 Progressive EnhancementによるJS不要のフォーム送信も可能です。 ただしVercelとの統合はNext.jsほど深くなく、Edge RuntimeやISRの活用には別途設定が必要です。 Shopifyのバックアップからコミュニティに移管後の開発体制が安定しており、長期安定性は確保されています。

Solid.js 2のfine-grained reactivityはJavaScriptランタイムで最も効率的なUIレンダリングを実現します。 Hydrationコストがゼロに近く、フォームが多いストレスチェックシステムのTTI（Time to Interactive）は最速クラスです。 しかし認証ライブラリ（Auth.js非対応）、ORM連携、UIコンポーネントライブラリの選択肢が限られており、 エンタープライズシステムで求められるエコシステムが未成熟です。 日本での求人もほぼなく、チーム採用が困難なため実務採用はリスクが高いです。

QwikのResumabilityアーキテクチャは「Hydrationしない」という発想で、初回表示速度が理論上最速です。 サーバー側でシリアライズした状態をそのままクライアントで再開するため、大量のJSをダウンロード・実行する必要がありません。 しかし思考モデルが従来のReact/Vueと大きく異なり、学習コストが高く、 日本でのQwik経験者はほぼいません。また認証・ORM周りのエコシステムが非常に薄く、 ストレスチェックのような法令対応システムに採用するリスクは大きいです。

Angular 20はSignals APIの完全対応により、従来のZone.jsベースの問題が解消されました。 大企業・官公庁向けシステムでの採用実績が豊富で、型安全性（全てTypeScript強制）と テスト容易性が非常に高いです。ただしVercelとの統合はAngular SSR（以前のAngular Universal） 経由となり、Next.jsのような第一級対応ではありません。 Vercel + Auroraに固定する本システムでは、SSR設定の複雑さとVercel最適化の不足がデメリットです。 すでに社内でAngularを使っているチームへの追加機能として作るなら有力ですが、 新規選定であればNext.jsかSvelteKitを選ぶべきです。

Vercel Serverless FunctionsからAmazon Auroraに接続する際の最大の問題は コネクションプール枯渇です。Serverless Functionsは各リクエストで新しいインスタンスが 起動するため、毎回新しいDB接続を張ろうとします。ピーク時8,000接続/時のシステムでは Aurora側の接続数上限（デフォルト〜数百）をすぐに超えてしまいます。

// Aurora DSQL + Drizzle の接続設定例
import { drizzle } from 'drizzle-orm/aws-data-api/pg';
import { RDSDataClient } from '@aws-sdk/client-rds-data';

const client = new RDSDataClient({ region: 'us-east-1' });
export const db = drizzle(client, {
  database: process.env.AURORA_DATABASE!,
  secretArn: process.env.AURORA_SECRET_ARN!,
  resourceArn: process.env.AURORA_RESOURCE_ARN!,
});

// lib/db.ts — Serverless対応のコネクション管理
import { drizzle } from 'drizzle-orm/node-postgres';
import { Pool } from 'pg';

// グローバルシングルトンでコネクションを再利用（Vercel Functions間では再利用不可だが
// 同一warm instance内では再利用される）
const globalForDb = globalThis as unknown as { pool: Pool | undefined };

const pool = globalForDb.pool ?? new Pool({
  host: process.env.AURORA_PROXY_HOST,  // RDS Proxy エンドポイント
  port: 5432,
  database: process.env.AURORA_DB_NAME,
  ssl: { rejectUnauthorized: true }, // 必須（機微情報）
  max: 5,  // Serverless Functionあたりのmax接続数を制限
});

if (process.env.NODE_ENV !== 'production') globalForDb.pool = pool;

export const db = drizzle(pool);

ピーク時8,000接続/時・通常500〜1,000接続/時の中規模ストレスチェックシステムにおける月額コストの概算です。 ストレスチェックは法律上年1回実施が多く、ピーク期間は1〜2ヶ月程度です。

1. 1

   プロジェクト初期化

   npx create-next-app@latest stress-check --typescript --tailwind --app --src-dir

2. 2

   依存関係インストール

   npm install drizzle-orm pg @aws-sdk/client-rds-data
   npm install -D drizzle-kit @types/pg
   npm install next-auth@beta zod

3. 3

   環境変数設定（.env.local）

   AURORA_PROXY_HOST=your-rds-proxy.proxy-xxx.us-east-1.rds.amazonaws.com
   AURORA_DB_NAME=stress_check
   AURORA_DB_USER=app_user
   AURORA_DB_PASSWORD=...
   AUTH_SECRET=... # openssl rand -hex 32
   AUTH_TRUST_HOST=true

4. 4

   Drizzle スキーマ定義（src/lib/schema.ts）

5. 5

   Auth.js 設定（src/auth.ts）— セッション認証

6. 6

   Middleware でルート保護（src/middleware.ts）

7. 7

   Server Action でフォーム送信処理

8. 8

   Vercel CLI でデプロイ & 環境変数設定

   npx vercel --prod
   npx vercel env add AURORA_PROXY_HOST production

9. 9

   Vercel Secure Compute でVPC接続を確立（Pro機能）

10. 10

    負荷テスト実施（k6 または Artillery）でピーク8,000接続/時を検証

    # k6 負荷テスト例
    # 8000接続/時 = 約2.2 req/s を60分間
    k6 run --vus 50 --duration 60m stress-check-test.js