【ITニュース解説】Why Next.js Middleware is the Wrong Place for Auth

Next.jsは、アプリケーションを高速化し、世界中のどこからアクセスしても遅延なく動作させる「Edge Everything」という考え方で多くの開発者を魅了している。しかし、この新しいアーキテクチャを採用する際、特に認証処理、つまりユーザーが正しい人物であるかを確認し、アクセス権があるかを判断するプロセスをNext.jsのMiddleware内で直接データベースと連携して行うことは、見かけによらず大きな問題を引き起こす。これは、アプリケーションの入り口でセキュリティチェックを行うという直感的な発想が、結果的にシステム全体の性能を著しく低下させる「隠れたコスト」となるためだ。この手法は、アプリケーションが成長し、より多くのユーザーを抱えるようになるにつれて、性能を著しく悪化させる「アンチパターン」、つまり避けるべき設計であることが指摘されている。

問題の根源は、Next.jsのEdge Runtimeの根本的な性質にある。これは従来のNode.js環境とは異なり、Google Chromeなどにも使われているV8エンジンをベースに、プログラムを高速かつ軽量に実行するための特別な隔離環境（V8 isolates）として設計されている。この特性のため、Edge Runtimeは、高速なグローバル分散を可能にする一方で、利用できる機能に大きな制約がある。具体的には、ファイルシステムへのアクセス（fs）、ネットワーク通信の基礎となるTCPソケット（net, tls）など、Node.jsで一般的な多くのネイティブモジュールがサポートされていない。しかし、多くの伝統的なデータベースドライバー、例えばPostgreSQLで使われるpgライブラリや、PrismaのようなORM（オブジェクト関係マッピング）が内部で利用する低レベルのネットワーク通信機能は、まさにこれらのNode.jsネイティブモジュールに依存している。そのため、Next.jsのMiddleware内でこれらのデータベースドライバーを直接使おうとすると、実行時にエラーが発生してしまう。この問題を回避するために、開発者がAPI GatewayやREST APIを通じて間接的にデータベースにアクセスする「HTTPベースの回り道」を試みることがあるが、これは通信回数を増やし、余計な処理時間を発生させるため、Edge Runtimeの高速性という利点を打ち消してしまう。

たとえEdge Runtimeの制約を何とか回避してデータベースドライバーを動かせたとしても、Next.jsのMiddlewareにはより深刻な問題がある。それは、Middlewareが実行される頻度だ。Next.jsにおいて、Middlewareは、指定されたルートに一致するすべてのリクエストに対して実行される。これには、ユーザーがページを移動するときの標準的なリクエストだけでなく、React Server Components（RSC）がデータを取得する際のリクエスト、バックグラウンドでのコンテンツの再検証（revalidation）リクエスト、さらには設定ミスがあればCSSやJavaScriptファイルなどの静的アセットへのリクエストまで含まれる。つまり、ユーザーがウェブサイト上のリンクを一度クリックしただけでも、背後では複数のリクエストが連鎖的に発生し、それぞれのリクエストに対してMiddlewareが実行される可能性がある。もしMiddleware内でデータベースへの問い合わせを行っている場合、これはまるでユーザー自身が意図せずアプリケーションのデータベースに対して大量のリクエストを送りつける「自己分散型サービス拒否攻撃（Self-inflicted DDoS）」のような状態を生み出してしまう。結果として、データベースへの接続が枯渇したり、応答が遅延したり、最悪の場合、データベースプロバイダーからアクセス制限を受けたりする可能性がある。

セキュリティと性能の両方を高いレベルで維持するためには、認証・認可のプロセスを「2層アーキテクチャ」に分割して考えるべきである。

まず第一層は「Edge Gatekeeper（エッジの門番）」と位置付けられる。Next.jsのMiddlewareは、あくまで軽量でEdge Runtimeと互換性のあるタスクに限定して使用する。ここでの目的は、データベースに問い合わせることなく、セッショントークンが存在し、その有効性を迅速に検証することだ。例えば、JSON Web Token（JWT）という形式のトークンが使われている場合、その署名が正しいかどうかの検証は、joseというライブラリを使うことでEdge環境で数ミリ秒のうちに完了できる。joseはWeb Crypto APIという標準技術を活用しているため、Edge Runtimeでも問題なく動作する。この層では、トークンの署名が正しいことを確認するだけで、そのトークンが持つユーザーIDが有効なものか、あるいはユーザーに特定のリソースへのアクセス権があるかといった詳細な情報は確認しない。これにより、Middlewareは非常に高速に動作し、データベースへの不要な負荷をかけずに、不正なアクセスを初期段階でブロックする「門番」としての役割を果たす。また、CSSや画像などの静的ファイルに対してMiddlewareが実行されないように、matcher設定を適切に行うことも重要だ。

第二層は「Node.js Heavy Lifter（Node.jsの重労働者）」である。より詳細な認可、例えばデータベースに保存されているユーザーの役割をチェックしたり、セッションが明示的に取り消されていないかを確認したり、ユーザーのプロフィールデータを取得したりといった「重い」処理は、Next.jsのServer Components、Route Handlers、またはServer Actionsといった場所で行うべきだ。これらの機能は、完全なNode.jsランタイム環境で実行されるため、Edge Runtimeのような制約がない。そのため、pg-poolのようなデータベース接続を効率的に管理するライブラリや、機能豊富なORM（オブジェクト関係マッピング）を問題なく利用できる。この層でデータベースアクセスを行うことで、データベースへのトラフィックを予測可能にし、アプリケーションのロジックを整理し、安定した性能を保つことができる。

結論として、Next.jsのMiddlewareでデータベースへの問い合わせを行うことは、一見便利に見えても、アプリケーションの性能を大きく損ない、スケーラビリティを阻害する。Edge Runtimeの特性を理解し、Middlewareを軽量な認証処理、つまりトークンの有効性チェックに限定することが重要だ。そして、ユーザーの役割や権限の確認、データベースからのデータ取得といった「重い」状態確認は、Server ComponentsやRoute Handlersといった完全なNode.js環境で実行されるサーバーサイドのコンポーネントに任せるべきである。これにより、Edge環境の高速性を最大限に活かしつつ、データベースへの負荷を適切に管理し、アプリケーション全体のパフォーマンス、スケーラビリティ、そしてセキュリティを両立できる。Middlewareでデータベースにアクセスしようとするときは、一度立ち止まって「この処理は本当にEdgeで必要か？サーバーサイドに任せられないか？」と自問自答することが、より良いアプリケーション設計への第一歩となるだろう。

文字数: 1999文字