仕様変更

Next.js は長らくルート直下（または src/）の middleware.ts をエッジミドルウェアの入口としてきたが、Next.js 16 ではこれが proxy.ts にリネームされた。エクスポートする関数名も middleware から proxy に変わり、export function proxy(request) { ... } と export const config = { matcher: [...] } の組み合わせになる。

監査・レビューでの落とし穴

認証ガードやルート保護の有無を調べるとき、middleware.ts が見つからないだけで「エッジでの認証ガードがない」と早合点しない。Next.js 16 以降では proxy.ts を探す。バージョンは package.json の next で確認できる。

逆に、Next.js 16 にアップグレードした際、旧名 middleware.ts のままだとエントリポイントとして認識されず、認証リダイレクトが黙って効かなくなるリスクがある。移行時はリネームと関数名変更を忘れない。

併せて確認する認証設計の原則

middleware / proxy 層のルート保護は UX 上のリダイレクトと位置づけ、そこを信頼境界にしないこと。本当の認可（リソースの所有者判定など）は API 側で行う。こうしておけば、エッジガードの有無やファイル名変更に関わらず、未認証アクセスは API で拒否される。

検証方法

config.matcher に保護対象パスが含まれるか、未認証で保護パスにアクセスしてリダイレクトされるかを実機で確認する。同時に、そのリダイレクトをバイパスして API を直接叩いたときも 401/403 になること（認可が API 側にあること）を確認する。