Next.jsエンジニアのフリーランス案件で求められるスキルと経験

Next.jsのフリーランス案件で問われるのは、サーバーで動く部分とブラウザで動く部分の境目をどこに引くか、データをどこで取ってどう更新するか、ページごとの描画方式とキャッシュをどう決めるか、サーバー側の処理を安全に書けるか、どこにどう配信するかの5つです。Reactで画面を書く力は前提で、その上の「サーバーをまたぐ判断」ができるかが見られます。

この記事では、5つの分野ごとに案件で問われる中身を整理し、経験の段階ごとの目安を示します。Reactのコンポーネント設計や状態管理はReactの案件で求められるスキルの記事、型の設計はTypeScriptの案件で求められるスキルの記事で扱っているので、ここではNext.jsに固有の部分に絞ります。

Next.jsの案件で問われるスキルの全体像

構成：境目をどこに引くか

App Routerでは、コンポーネントは何も指定しなければサーバーで動き、"use client"を付けたものがブラウザでも動きます。案件で見られるのは、ブラウザ側に回す範囲をできるだけ小さく保てるかです。ボタンやフォームなど操作が要る部分だけをClient Componentにし、データの取得や重い処理はサーバー側に残すと、ブラウザに送るJavaScriptが減ります。

もう一つは、レイアウトの組み方です。共通のヘッダーや画面の枠をレイアウトにまとめ、ページごとの読み込み中の表示やエラー表示をどこに置くかを決めます。既存の案件に入ったときは、この構成を短い時間で読み取れるかも問われます。

データ：取得と更新の置き場所

取得はサーバー側に寄せる

App Routerでは、Server Componentの中で直接データを取ってこられます。便利な一方、取得処理が画面のあちこちに散らばると、権限の確認が漏れやすくなります。Next.jsの公式ブログは、新しいプロジェクトではデータへのアクセスを一か所の層にまとめ、そこで利用者の権限を確かめてから返す形を勧めています。取得の処理をどこに集めたかを説明できると、構成を任せられる人と見られやすくなります。

更新後の表示を新しくする

フォームの送信などの更新はServer Actionsで書くことが多くなっています。Next.js 16では、更新した直後にその内容を読み直すupdateTag()や、キャッシュしていないデータだけを新しくするrefresh()が加わり、revalidateTag()は第2引数にキャッシュの寿命の指定が要るように変わりました（Next.js公式ブログ、2025年10月21日）。どの方法で表示を新しくしたか、なぜそれを選んだかは、面談でよく掘り下げられる点です。

描画とキャッシュ：ページごとに決める

Next.jsでは、ビルド時に作っておくページ、リクエストのたびに作るページ、静的な部分と動的な部分を一つのページで組み合わせる形を使い分けます。

Next.js 16で入ったCache Componentsは、"use cache"で指定した部分だけをキャッシュする仕組みで、以前の暗黙のキャッシュとは考え方が逆です。Next.js 16.4の公式ブログでは、Cache Componentsがすべてのアプリに勧められ、新しく作るアプリでは最初から有効になると案内されています（2026年10月時点）。16.4では、ページが静的であることをビルド時に保証するensureStaticも加わりました。

案件では、新しい考え方で作られたアプリと、以前の書き方のアプリの両方に出会います。どちらの考え方でも、何がどこでキャッシュされているかを説明できることが求められます。

安全性：サーバー側の入口を守る

Next.jsの公式ブログでは、"use server"を付けた関数は、ブラウザから呼び出せる入口になると説明されています。そのため、関数の最初で利用者が実行してよいかを確かめ、引数の中身を検証する必要があります。TypeScriptの型は実行時には効かないため、検証の仕組みを別に持つことになります。

また、Server ComponentからClient Componentに渡したデータはブラウザに届きます。利用者の情報をまるごと渡さず、画面に必要な項目だけに絞ることも、レビューで見られる点です。サーバー側の処理の安全性やNode.jsの依存パッケージの扱いは、Node.jsの案件で求められるスキルの記事が参考になります。

配信と運用：どこで動かすか

公式ドキュメントでは、配信方法としてNode.jsのサーバー、Dockerのコンテナ、静的な書き出し、各プラットフォーム向けのアダプターが挙げられています。Node.jsのサーバーとコンテナはすべての機能に対応しますが、静的な書き出しでは、Cookieの読み取り、リダイレクトやリライト、Server Actions、既定の画像最適化など、サーバーが要る機能は使えません。

配信先によって使える機能が変わるため、構成を決める段階で配信先の制約を考えに入れられるかが、設計を任される人の条件になります。コンテナで複数台動かす場合のキャッシュの共有など、インフラ寄りの知識が求められる案件もあります。

経験の段階ごとに求められること

浅い段階では、まず境目の判断を自分の言葉で説明できるようにするのが近道です。機能を任されている段階では、キャッシュの不具合を調べた経験が次の段階への材料になります。方針を決める段階では、技術の判断を発注元に説明する場面が増えます。

テストの整え方はテスト自動化の記事で扱っています。

スキルシートと面談での示し方

Next.jsは版によって考え方が大きく変わるため、「Next.js、TypeScript」と並べるだけでは経験の中身が伝わりません。版、ルーター、配信先、そして上の5つの分野のどこで判断したかを書き分けると、読み手が任せられる範囲を判断しやすくなります。具体的な書き方はNext.jsのスキルシートの記事で解説しています。

よくある質問

Pages Routerの知識はもう不要ですか？

不要ではありません。Pages Routerは公式に引き続きサポートされており、Pages Routerで動く既存のサービスの保守や、App Routerへの移行の案件があります。移行では両方の書き方を理解している必要があるため、Pages Routerの知識が強みになる場面もあります。

Cache Componentsを使ったことがないと不利ですか？

新しい考え方なので、使った経験がある人はまだ多くありません。案件では、以前の書き方で作られたアプリも多く残っています。まずはどちらの考え方でも「何がどこでキャッシュされるか」を説明できるようにし、個人のアプリなどで新しい書き方に触れておくと、面談で話せる範囲が広がります。

インフラの知識はどこまで必要ですか？

画面の実装が中心の案件では、配信先の細かい設定まで求められないことが多いです。ただ、構成を決める役割では、配信先によって使える機能が変わることを理解している必要があります。コンテナで動かす案件では、複数台での動かし方やキャッシュの共有まで求められることがあります。