フレームワークが変わるとミドルウェアの役割が全然違った話

2026.10.07 フロントエンドカンファレンス東京 × Vue Fes Japan × JSConf JP コラボイベント 登壇資料
Next.js で「ミドルウェアはリクエスト前段の軽い処理。リダイレクトや A/B テスト程度」と理解していた私は、React Router v7 のプロジェクトで「認証をどの層で実施するか」という設計判断の中で、ミドルウェアという選択肢を思いつくことができませんでした。その経験から得た「同じ言葉でも、フレームワークが違えば別物」という学びについて話した内容です。

Transcript

1. フレームワークが変わると ミドルウェアの役割が全然違った話 下條 拓未 2026.10.07 フロントエンドカンファレンス東京 × Vue Fes Japan × JSConf JP コラボイベント
2. 下條 拓未 Gaji-Labo Inc. ／ フロントエンドエンジニア 専門 フロントエンド／Next.js、React Router v7 最近 ・デザインハーネスに興味があります @takumi_bv 2
3. プロダクトの課題を一緒に解決します。 最適な技術と、適切な手段で。 お仕事のご依頼・ご相談 サービス案内ページ https://www.gaji.jp/services 採用に関するお問い合わせ 採用情報ページ https://www.gaji.jp/recruit
4. 皆さんは Web フレームワークの中で、 ミドルウェアをどんな場面で使っていますか？ 認証 ロギング リダイレクト レートリミット … 4
5. 今日話すミドルウェアの範囲 Web フレームワークの中で、 リクエストの処理に割り込む層 Middleware Request Response Handler MDN 用語集では「システムの各部分がデータを通信および管理できるようにする、あらゆるソフトウェアまたはサービスの（定義があやふやな）用語」 — developer.mozilla.org/ja/docs/Glossary/Middleware 5
6. プロジェクトを移ったら、 ミドルウェアの役割がまったく違った Next.js プロジェクト → React Router v7 プロジェクト 6
7. React Router で詰まったこと 1回の画面表示で、同じデータ取得が複数回呼ばれる loader A requireAuth() GET /api/me Request それぞれでデータ取得が必要 loader B requireAuth() 描画 loader は並列に走るため、 GET /api/me React Router の loader 関数 ルートごとに、描画の前にデータを取る関数。Nuxt の useAsyncData、Next.js の Server Component 内の取得処理（Pages Router なら getServerSideProps）に近い 7
8. 解決策 ミドルウェアで取って、loader に渡す middlware context.set Request GET /api/me loader A 取得したデータを context で /api/me context.get(userContext) loader に共有することができる loader B context.get(userContext) 8
9. この選択肢を外していた 9 / 14 9
10. React Router v8 のミドルウェア React Router v8 で、middleware がデフォルトに v7.3（2025年3月） future フラグで有効化 unstable_middleware → v7.9（2025年9月） 安定化 → v8（2026年6月） フラグ無しでデフォルト v8_middleware 10
11. Next.js のミドルウェア（Proxy） Proxy は、ルーターの手前にある単一のフック ※ v16 で middleware から Proxy に改名（middleware.ts は非推奨として残っている） アプリ本体 Request proxy.ts Router Page / Layout / Route Handler アプリ全体で 認証・認可・データ取得はこちらで行う 単一のフック 11
12. Next.js のミドルウェア（Proxy） Proxy では、軽く見るだけに留める 1 Cookie の有無だけ見る 楽観的なチェック。本当の認証 2 データ取得は避ける 入口で重い処理をしない ・認可はページやデータ層で 3 「最終手段」 公式も、最終手段として使うべ き機能と位置づけている この考え方を、そのまま React Router に持ち込んでいた https://nextjs.org/docs/app/api-reference/file-conventions/proxy#why-the-change 12
13. ２つのフレームワークは逆方向に進んでいる Next.js React Router 「最終手段」 2021.10 2025.10 Middleware 登場 Proxy に改名 「横断的な処理の 2025.3 2026.6 unstable 機能で フラグなし Middleware 登場 デフォルトに 標準の置き場所」 13
14. まとめ ミドルウェアという名前は共通でも、 作法も進む方向も違う 14
15. 補足 フレームワークごとのミドルウェアの違い Next.js React Router v8 位置づけ 「最終手段」 「横断的な処理の標準の置き場所」 実行される位置 ルーティングより前、アプリの入口に1つ ルートごとにハンドラ(loader)を包む いわゆる玉ねぎ型 下流への値の受け渡し ヘッダ・Cookie のみ context で型付きで渡せる データアクセス 避けるのが作法（DB を引かない） 前提にしている（取って下流に配る） 主な用途 リダイレクト・リライト、ヘッダ操作、 認証とユーザー情報の注入、ロギング、レ 楽観的な認証チェック スポンスヘッダの付与 15