# 不満を募らせたNext.jsユーザー、ミドルウェアのロギング問題からフレームワーク批判へ
NeoTechNews編集部
2025年9月2日の発生日に、Next.jsをめぐる辛辣な開発者の論考が、本来なら日常的であるはずの作業、すなわちサービスに本番環境対応のロギングを追加することに焦点を当て、注目を集めた。[16131]
投稿は具体的な状況から始まる。Next.jsのサービスが本番環境で障害を起こし、デフォルトのロギングは開発環境でしか有効になっておらず、チームにはリクエストを認識するログが必要になる。[16131] そこから筆者は、単純なオブザーバビリティーの作業が、断片化したランタイムと不足した拡張ポイントを巡る旅へと急速に変わると主張する。
最初の不満はミドルウェアそのものに向けられている。筆者は、Next.jsのミドルウェアが渡せるパラメーターは4つだけであり、呼び出されるルートに影響を与えられるのはヘッダーだけだと述べている。[16131] 投稿はまた、ミドルウェアの合成には制約があり、Expressのようなフレームワークで開発者が長年当然と考えてきたスタイルで、階層化されたリクエスト処理を構築することが難しくなっていると主張する。[16131]
この制約により、筆者はリクエストのコンテキストを受け渡すために一般的に使われるNode.jsの仕組みである`AsyncLocalStorage`へと向かう。しかし投稿によると、Next.jsのミドルウェアはデフォルトでEdgeランタイム上で動作するため、当初のミドルウェア用ロガーは期待されたサーバー側のログではなく、ブラウザー側に出力した。[16131] 筆者によると、Node.jsランタイムへの切り替えは新規プロジェクトでは有効だったが、実際のアプリケーションでは一貫して機能しなかった。[16131]
より深い不満は、ロギングの対象がミドルウェアを越えてページやレイアウトに広がった時に表面化する。投稿によると、ロガー関数は`null`を返したが、これはレンダリングがミドルウェアの実行と同じ非同期コンテキスト内で行われていなかったためとみられる。[16131] 筆者によると、回避策はヘッダーを通じて状態をトンネリングすることだった。ミドルウェアからルート層へ情報を渡す永続的な橋渡しとして事実上利用できるのは、ヘッダーだけだったからだ。[16131]
この回避策が重要なのは、筆者が最も有害だと考えるフレームワークの境界を露呈させるためだ。投稿によると、ミドルウェアのロギングコードをサーバーコードに単純にインポートすることはできず、サーバーのロギングコードをミドルウェアへ単純にインポートすることもできない。[16131] クライアントコンポーネントは、名前に反して状況によってはサーバー上でも動作するため、筆者が「第3の分断」と表現するものを生み、状況をさらに複雑にしている。[16131]
論考はその後、一つのロギング問題からフレームワーク設計への批判へと範囲を広げる。筆者はNext.jsを、同じくVercelと関係するプロジェクトであるSvelteKitと対比し、ロガーのような実際のオブジェクトや、より豊富なデータを受け渡せるSvelteKitのミドルウェアモデルを高く評価している。[16131] 筆者の説明では、この比較によってNext.jsは、明確な設計思想を持つフレームワークというよりも、中心的な機能をフレームワーク作者は利用できる一方、ユーザーには利用させない、厳しく管理された環境のように感じられるという。[16131]
GitHubのイシュートラッカーも、この批判の一部となっている。投稿は、コミュニティーから大きな反響を集めながら何年も公式回答がない長期未解決の問題が多数あると主張し、再現可能な事例を提示した後も回答がなかったと筆者が述べる具体的なバグ報告を2件挙げている。[16131] 要点は単にバグが存在するということではない。開発者は、問題点がいつ認識されるのか、ましてや修正されるのかを確実に予測できないと感じているということだ。
証拠として見れば、これはプラットフォームのベンチマークや公式なインシデント報告ではなく、一人の開発者の主張である。それでもこの記事が共感を集めたのは、フレームワーク疲れに共通する原因を明確に切り出しているためだ。生産性を高めるための抽象化が、力を与えるものではなく、越えられない壁のように感じられ始める瞬間である。リクエスト単位のロギングは、特殊ケース向けのぜいたくな機能ではない。運用を支える基本的な配管だ。その配管が扱いにくくなれば、開発者がその上に構築されたすべてを疑い始めるのは当然だ。
提供された情報源が裏付けるのは、限定的だが重要な結論である。これは、一つの実務的な作業を通じて展開された、開発者主導のNext.js批判だった。そしてその作業は、ミドルウェアの使い勝手、ランタイムの断片化、サポートの対応速度に関する懸念を露呈させた。こうした懸念は、大規模にこのフレームワークを利用する多くのチームにとって、おそらく身近なものだ。[16131]



