フロントエンド：SSRは「復権」ではなく「標準化」へ

主要フレームワークは軒並みSSRを標準化し、Edge実行と組み合わせることでTTFBを削り、体感速度を改善する流れが強いです。
また、ReactではストリーミングSSRと選択的ハイドレーションが普及し「準備できた部分から返す」「重要UIからhydrateする」が実務の標準になります。

SSR/Edge/RSCの“適用パターン”を固定する（勝ち筋だけ残す）

Next.js（App Router）で「JSを送らない」設計の型（実務版）

目的：データ取得をサーバ側に寄せ、クライアントJSを最小化。必要な部分だけClient Componentに閉じ込めます。

// app/products/page.tsx (Server Component)
import { Suspense } from "react";
import ProductClientFilters from "./ProductClientFilters";

type Product = { id: string; name: string; price: number; updatedAt: string };

async function getProducts(): Promise<Product[]> {
  // 公開情報なら revalidate を設計（例：60秒）
  const res = await fetch("https://example.internal/api/products", {
    // cache: "no-store", // 個人情報や在庫/価格などズレが致命なら no-store
    next: { revalidate: 60 },
  });
  if (!res.ok) throw new Error("fetch failed");
  return res.json();
}

function Skeleton() {
  return <div style={{opacity:.75}}>Loading...</div>;
}

export default async function Page() {
  const products = await getProducts();

  return (
    <div>
      <h2>Products</h2>

      {/* UIの一部だけClientにして、初期JSを抑える */}
      <ProductClientFilters />

      {/* 重要でない部分はストリーミングで後から返す */}
      <Suspense fallback={<Skeleton />}>
        <ul>
          {products.map((p) => (
            <li key={p.id}>{p.name} - {p.price}</li>
          ))}
        </ul>
      </Suspense>
    </div>
  );
}

Edgeレンダリング：速いが、制約が強い（だから設計が必要）

Cloudflare Workers / Vercel Edge / Lambda@Edgeなどにより「ユーザー近傍で動的生成」が現実解になりました。
ただし、Edgeは “速い代わりに制約が強い” ので、適用領域の固定が必須です。

ビルドツールチェーン：待ち時間を潰す＝チームの速度が上がる

巨大フロントの開発では「人の思考」がビルド待ちに切断されるのが最大損失です。
2025-2026は、Rust/高速コンパイラ（SWC等）を前提にしたツールが現実解になり、DevExが大きく上がります。

CIのGate設計：2026の事故を減らす“強制装置”

目標は「人が気をつける」から「仕組みが止める」へ。供給網セキュリティ（SBOM/署名/Secrets/依存）をデフォルト化します。

name: ci-gate
on:
  pull_request:
  push:
    branches: [ "main" ]

jobs:
  gate:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      security-events: write
      id-token: write
    steps:
      - uses: actions/checkout@v4

      # 1) Secrets検出（例: gitleaks）
      - name: gitleaks
        uses: gitleaks/gitleaks-action@v2

      # 2) 依存の脆弱性（例: osv-scanner）
      - name: install
        run: npm ci
      - name: osv-scan
        uses: google/osv-scanner-action@v1
        with:
          scan-args: "-r ."

      # 3) SBOM生成（例: syft/anchore）
      - name: sbom
        uses: anchore/sbom-action@v0
        with:
          format: "spdx-json"
          output-file: "sbom.spdx.json"

      # 4) build（成果物生成）
      - name: build
        run: npm run build

      # 5) 署名（例: cosign / OIDC）
      - name: cosign (example)
        run: |
          echo "Sign artifacts here"
          # cosign sign --yes <artifact>

BFF/API：マイクロサービス疲れの後に来る「適正な統合」

Webは“画面都合”でデータが必要になります。複数サービスをそのままフロントから叩くと、速度・権限・監査・リトライで破綻します。
そのため2025-2026は、BFF（Backend For Frontend）で適正に統合する流れが強いです。

APIの使い分け基準（迷わないための固定ルール）

コード：tRPC（最小構成）＋境界の作り方

// server/trpc.ts
import { initTRPC } from "@trpc/server";
import { z } from "zod";

const t = initTRPC.context<{ userId?: string; roles: string[] }>().create();

// “境界”をrouterで切る（例：users / orders / admin）
const usersRouter = t.router({
  getUser: t.procedure
    .input(z.object({ id: z.string().uuid() }))
    .query(async ({ input, ctx }) => {
      // 監査ログ（誰が誰を参照したか）をここで確定
      // audit.log({ actor: ctx.userId, action: "users.getUser", target: input.id });
      return { id: input.id, name: "Alice" };
    }),
});

const adminRouter = t.router({
  // 例：adminのみ
  stats: t.procedure.query(async ({ ctx }) => {
    if (!ctx.roles.includes("admin")) throw new Error("forbidden");
    return { ok: true };
  }),
});

export const appRouter = t.router({
  users: usersRouter,
  admin: adminRouter,
});

export type AppRouter = typeof appRouter;

データ基盤：分散SQL/サーバレスDBが“実装の選択肢”になった

サーバレス/マネージドDBは「運用負荷を下げる」だけでなく、開発速度（スキーマ変更の止めづらさ）にも効きます。
ただし、Edgeと組むと整合性・レイテンシ・規制対応（データ所在）が課題になります。

Edge×データ：整合性を崩さない“型”

Edgeに寄せたくなるほど「データ一貫性」が難しくなります。2025-2026の現実解は、用途別に分けることです。

// 冪等性キーの例（決済/申込系は必須）
POST /api/orders
Idempotency-Key: 0c8b... (UUID)

# サーバ側：
# - (userId, Idempotency-Key) で重複検知
# - 同じキーなら同じ結果を返す
# - 競合はトランザクションで吸収

Webセキュリティ：2025-2026の“盲点”はサードパーティJS

Webサイトは多数の外部（間接含む）サードパーティJSを抱えがちで、改ざんによる情報窃取（Magecartのような手口）が問題になります。
そこで CSP による実行元制限、SRI による改ざん検知が基本になります。

CSP：最小→段階強化（壊さずに強くする）

# Nginx: まずはReport-Onlyで始める（壊さない）
add_header Content-Security-Policy-Report-Only "
  default-src 'self';
  script-src 'self' https://trusted.cdn.example 'nonce-$request_id';
  object-src 'none';
  base-uri 'self';
  frame-ancestors 'none';
  upgrade-insecure-requests;
  report-uri /csp-report
" always;

# 収集したレポートを元に許可先を調整 → 本番CSPへ
# add_header Content-Security-Policy "...";

<!-- SRI: 変更されない静的スクリプトに有効 -->
<script
  src="https://trusted.cdn.example/widget.min.js"
  integrity="sha384-BASE64_HASH_HERE"
  crossorigin="anonymous"></script>

セッション固定（Session Fixation）：認証後にIDを必ずローテーション

認証成功後にセッションIDを再発行（regenerate/rotate）し、固定化攻撃を成立させないのが基本です。

// Express + express-session の例（認証成功後に regenerate）
app.post("/login", async (req, res) => {
  const ok = await auth(req.body.id, req.body.password);
  if (!ok) return res.status(401).send("ng");

  req.session.regenerate((err) => {
    if (err) return res.status(500).send("session error");
    req.session.userId = req.body.id;
    res.send("ok");
  });
});

SSRF：クラウド時代に危険度が増した“設計バグ”

外部URLをサーバ側で取得する機能（OGP取得、画像プロキシ、Webhook検証など）はSSRFの温床です。
2025-2026は「外部リクエストは設計段階で制御」を標準にします。

// Node例：SSRF対策の“型”（擬似コード）
function assertSafeUrl(u) {
  const url = new URL(u);

  // 1) スキーム制限
  if (!["https:", "http:"].includes(url.protocol)) throw new Error("bad protocol");

  // 2) 解決したIPを検証（DNS Rebind対策）
  const ip = resolveDnsToIp(url.hostname);
  if (isPrivateIp(ip) || isLinkLocal(ip) || isMetadataIp(ip)) throw new Error("blocked");

  // 3) リダイレクトは最大回数 + 毎回検証
  // 4) タイムアウト/サイズ制限（DoS対策）
}

認可（Authorization）：RBACだけでは足りない

重要操作（機密データ・管理操作）は、RBAC（役割）だけでなく、条件（属性）で縛るABACが有効です。
例：部署、拠点、時間帯、端末信頼度、操作種別などを条件にする。

// ルールエンジン導入前でも“簡易ABAC”は実装できる（擬似）
function canReadCustomer(user, customer) {
  if (user.role === "admin") return true;
  if (user.dept !== customer.ownerDept) return false;
  if (!user.deviceTrusted) return false;
  return true;
}

サービス展望：2025-2026に「売れる」提供価値の作り方（実装可能形）

技術の進化は“差別化ポイント”を変えます。
2025-2026は「速い」「壊れない」「監査できる」「供給網を守れる」を、数字で売るサービスが伸びます。

提案のテンプレ（そのまま営業資料になる）

実装チェックリスト（2025-2026版・増量）

“読むだけ”で終わらせないために、採用時の最低ラインを定義します。

90日で「武器化」する実行ロードマップ（Webアプリ版）