Next.jsエンジニアのフリーランスがつまずきやすい点と対策

フリーランスのNext.jsエンジニアがつまずきやすいのは、画面の開発のつもりでサーバー側や配信まで範囲が広がること、キャッシュの方針が決まらないまま作り始めること、Server Actionsの権限確認が抜けること、移行が終わった時点で契約も終わることです。どれも、Next.jsがサーバーとブラウザの両方にまたがるフレームワークであることから起きやすくなります。

この記事では、契約・現場・技術・お金の4つの面から、Next.jsならではのつまずきと対策を整理します。Reactの案件全般で起きやすいことはReactエンジニアのつまずきやすい点の記事で扱っているので、ここではNext.jsに特有の場面に絞ります。

契約でのつまずき

「フロントエンド開発」の一言で範囲が広がる

Next.jsでは、画面のコードと同じ場所に、データベースへの問い合わせ、認証、外部APIの呼び出しを書けます。そのため、契約書には「フロントエンド開発」とあっても、参画してみるとAPIの設計、認証のつなぎ込み、配信先の設定まで求められることがあります。

対策は、契約前にどこまでを担うかを具体的に確かめることです。画面だけか、Route HandlersやServer Actionsで書くサーバー側の処理も含むか、配信の設定や本番環境の操作は誰が行うかを聞き、業務範囲の書き方に反映してもらいます。フリーランス法では、発注事業者は業務委託をしたら直ちに、取引条件を書面または電磁的方法で明示することとされています（公正取引委員会の特設サイト、2026年10月時点）。明示される項目はフリーランス法の取引条件の明示で解説しています。

版上げを「完了」まで請け負う形になる

版上げやApp Routerへの移行の案件では、準委任の契約なのに「すべての画面が新しい版で動くこと」を成果として求められることがあります。移行は、古いライブラリの対応状況や、テストの有無で手間が大きく変わります。

準委任であれば、約束するのは作業の遂行で、完成ではありません。期間内に終わらない見込みが出た時点で、残りの画面と理由を示して相談するのが基本です。範囲が増えたときの対応は作業範囲の変更への対応をご覧ください。

生成AIや自動の版上げの道具の扱いが決まっていない

Next.js 16.4では、コーディングエージェント向けに版上げを手伝うnext upgrade --agentが用意されました。便利な一方で、取引先のコードを外部の生成AIに渡してよいかは、現場の規則で決まります。参画前に、使ってよい道具と渡してよい情報を確かめてください。考え方は生成AIの利用と契約の記事で整理しています。

現場でのつまずき

キャッシュの方針が決まらないまま作り始める

App Routerのキャッシュは、版によって考え方が変わってきました。16.4の公式ブログは、Cache Componentsを以前の暗黙のキャッシュに代わるものとし、次のNext.js 17で標準にする予定と示しています（2026年10月時点）。現場によって、古い考え方のまま、新しい考え方へ移行中、新しい考え方で作り始めた、と状況が分かれます。

方針が共有されないまま各自が作ると、ある画面は古いデータを表示し、別の画面は毎回サーバーで描く、といったばらつきが出ます。参画したら、どの考え方で作っているか、誰がキャッシュの方針を決めるかを早めに確かめ、分からない点はチケットやドキュメントに残して合意を取ります。

現場の規約より自分の書き方を優先する

'use client'をどこに置くか、データの取得をどの層に寄せるかは、現場ごとに決まりがあります。前の現場の書き方を持ち込むと、レビューで差し戻しが続き、信頼を落とします。最初は現場の書き方に合わせ、変えたい点は理由を添えて提案として出してください。

配信環境の権限がなく、確かめられない

Next.jsの動きは、配信先や本番の設定で変わることがあります。手元では正しく表示されても、本番ではキャッシュの効き方が違う、という場面です。配信環境やログを見る権限がないまま不具合の調査を任されると、原因を突き止められません。調査に必要な権限と、権限がない場合に誰に頼むかを、初月のうちに決めておきます。

技術でのつまずき

Server Actionsの権限確認が抜ける

Next.jsの公式ブログは、"use server"を付けた関数は外から呼び出せる入口になるため、関数の最初で利用者の権限を確かめ、引数も検証するよう説明しています。画面からしか呼ばない前提で権限確認を省くと、他人のデータを書き換えられる穴になりかねません。

対策は、Server Actionsを公開されたAPIと同じものとして扱うことです。公式は、新しいプロジェクトではデータへのアクセスを一つの層にまとめ、そこで権限を確かめる形を勧めています。現場にその層があればそこを通し、なければ点検の観点としてレビューで共有します。

ブラウザに渡すデータが多すぎる

Server ComponentからClient Componentへ、データベースの行をそのまま渡すと、画面に出さない項目までブラウザに届きます。公式ブログも、Client Componentが受け取るデータは必要な最小限にするよう説明しています。部品の受け取る値の型を広く取りすぎていないか、レビューで見る習慣をつけてください。

版ごとの違いで立ち上がりが遅れる

同じNext.jsでも、Pages RouterとApp Router、14.x以前と16.xとでは、書き方が大きく違います。面談で聞いた版と実際の版が違い、立ち上がりに時間がかかることもあります。参画が決まったら、使っている版とルーターを確かめ、公式の移行ガイドに目を通しておくと初月が楽になります。

お金でのつまずき

緊急のセキュリティ更新で稼働が増える

Next.jsは2026年7月から、月に1回ほどセキュリティ更新の予定を事前に告知する運用を始めました。一方で、緊急の脆弱性には予告なしの修正も出すとしています。保守を担う案件では、こうした臨時の更新の適用で稼働が増えることがあります。精算幅を超えたときの扱いや、時間外の対応を誰が担うかを、契約前に確かめておきます。精算の仕組みは精算幅の記事で解説しています。

移行が終わると契約も終わる

版上げやApp Routerへの移行の案件は、移し終えた時点で区切られやすい仕事です。終わりが見えたら、契約の終了時期の1〜2か月前を目安に、次の案件を探し始めると空白を短くできます。移行のあとの保守や機能開発に関われるかを、早めに相談しておくのも一つの方法です。

学び直しの時間を見込んでいない

Next.jsは版ごとの変化が大きく、新しいキャッシュの考え方や配信の仕組みを学ぶ時間がかかります。報酬の対象になる稼働とは別に、学ぶ時間を毎月の予定に入れておかないと、気づけば知識が古くなっていた、ということになりかねません。時間の取り方は勉強時間の確保の記事を参考にしてください。

よくある質問

参画してから、聞いていた版やルーターと違うと分かりました。どうすればよいですか？

まず、違いによって何が変わるか（立ち上がりの期間、担える範囲、見込んでいた作業量）を整理し、紹介を受けたエージェントと発注側の窓口に早めに伝えてください。契約書に書かれた業務範囲と照らし合わせ、変わる点があれば書面で取り決め直すのが基本です。個別の判断が要る場合は専門家にご相談ください。

自分の書いた処理でキャッシュの不具合が起き、他の人の情報が表示されたらどうなりますか？

責任の範囲は契約の形と内容によって変わります。準委任か請負か、損害賠償の上限があるかを、参画前に契約書で確かめておくことが大切です。起きてしまったら、隠さずにすぐ報告し、影響の範囲を調べることを優先してください。個人の情報が関わる場合の扱いは、取引先の規則に従います。法的な判断が要るときは専門家にご相談ください。

現場の書き方が古く、新しい書き方に直したくなります。どうすればよいですか？

すぐに書き換えるより、まず現場の書き方に合わせて動くことをおすすめします。そのうえで、直したい点と理由、影響の範囲、移す順番をまとめて提案として出すと、受け入れられやすくなります。参画初月の進め方はNext.jsエンジニアの参画初月にやることで整理しています。