Next.jsのRFPで成否を分けるのは、非機能要件を数字で書けるかどうかです。SSRの要否や運用コストの上限を数字にすると、見積もりの根拠が揃います。
フルスクラッチ受託と国内開発を手がけるriplaの視点から、技術選定から検収基準までを順に見ていきます。全体像はNext.js開発の完全ガイドにもまとめています。
AI駆動開発の基本や工程ごとの活用方法、費用・期間への影響については、無料ホワイトペーパー「【2026年最新版】AI駆動開発の完全ガイドブック」で詳しく解説しています。
Next.jsのRFPで成否を分ける非機能要件の定量化
【この記事のアンサー】 Next.jsのRFP・要件定義書で成否を分けるのは、機能要件よりもむしろ非機能要件を定量的に書けるかどうかです。
特に、SSRの要否と運用コストの上限、表示速度の目標（Lighthouseスコア）は、数値で示せるかどうかが鍵になります。対応端末・ブラウザやアクセシビリティのレベルも、数字で示すと、ベンダーは見積もりを正確に出せ、発注側は提案を横に並べて比べられ、検収時の認識のずれも防げます。
「使いやすく速いサイトを」といった曖昧な依頼は、工数とコストを大きく膨らませる原因になります。そこで、技術選定の前提として、本当にNext.jsが必要かを問い直すところから始めます。
要件に対するNext.jsの適合性
要件定義の第一歩は、機能を細かく書き出すことより先に、自社の事業要件にNext.jsが本当に適しているかを問い直すことです。
npmの新規プロジェクトの約35%がNext.jsを採用しており、事実上の標準になっています。とはいえ、すべての案件に最適とは限りません。技術選定の根拠をRFPに書いておくと、ベンダーから的確な提案を引き出せます。
事業フェーズとROIから見た選定基準
技術選定は、エンジニアの好みやトレンドよりも、事業フェーズとROIから逆算して決めるべきです。SEO流入が事業の生命線となるメディアやEC、表示速度がコンバージョンに直結するサービスでは、SSRやSSGを備えたNext.jsの価値がはっきりします。一方で、社内向けの管理画面のように検索流入が要らない場合は、SSRの恩恵が薄く、よりシンプルなReactのSPAで足りることもあります。
RFPには、「なぜこの技術が必要か」という事業上の理由を書いておくとよいでしょう。ベンダーには、代替案の提示も求めます。
短期のMVPか、長期で育てるプロダクトかによっても、最適な選択は変わります。また、事業の寿命と成長スピードも選定基準に入れます。
- 短期のMVP：開発の初速を優先する選び方
- 長期で育てるプロダクト：保守性と陳腐化への追従コストを優先する選び方
採用容易性とベンダーロックイン回避の要件
採用要件として見落とされがちなのは、開発後に保守できる人材を確保できるかという視点です。Next.jsはReactベースのため人材市場が厚く、フリーランス案件データベースでも平均月額約82万円と高単価で流通しています。そのため、人材は比較的見つけやすい部類です。
Next.jsの技術者は高単価でもあるため、保守の前提を決めておかないと、運用フェーズで破綻しかねません。
ベンダーロックインの回避も、重要な採用要件です。特定ベンダー独自の構成や、Vercelのような特定のホスティングに強く依存する設計は、将来のリプレイスを難しくします。シェアの高いNext.jsを指定することも、将来の選択肢を広げ、ロックインを避ける手立てになります。
- 想定する保守体制：自社内製か継続委託か、その人材確保の前提
- 標準的な構成：他社でも保守・移行できることを条件にすれば、囲い込み型の提案を避けられる
SSR要否の判断とRFPへの明記
Next.jsのRFPで最も技術的で重要な論点は、SSR（サーバーサイドレンダリング）を使うかどうかの判断です。ここが曖昧だと、運用コストと工数の見積もりがぶれてしまいます。そこで、発注側がSSRの要否を整理してRFPに書いておくと、ベンダーの提案の精度が大きく上がります。
SSRが必要なページと不要なページの切り分け
SSRの要否は、ページごとに切り分けて考えます。RFPには、どのページ群にSEOが必要か、どのページがリアルタイム性を要するかを示します。そうすれば、ベンダーはページごとに適切なレンダリング方式を割り当てられます。
注意すべきは、SSRを使えばどのページも速くなるという誤解です。SSRはアクセスのたびにサーバーが処理を行うため、全ページをSSRにすると、むしろ運用コストを押し上げます。
そのため、RFPに「全ページSSR」と指定する代わりに、「SEOと表示速度の要件を満たす最適なレンダリング設計を提案すること」と求めるのが賢明です。ベンダーに設計力を競わせる書き方になります。
- SSRが要るページ：検索流入を狙い、内容がリアルタイムに変わるページや、ログイン後にユーザー固有の情報を表示するページ
- SSGで足りるページ：内容が頻繁に変わらない記事やコーポレートページ。社内向けの管理画面は、SSR自体が不要なこともある
判断に迷うときの確認ポイント
SSRの要否は、ページごとに次の問いで確かめられます。まず、そのページに検索エンジンからの流入を期待するかどうかです。次に、表示する内容がユーザーごと、時刻ごとにリアルタイムに変わるかどうかです。
さらに、初期表示の速さがビジネス成果に直結するかどうかも問われます。これらすべてに当てはまるならSSRの価値が高く、いずれも当てはまらないならSSGやクライアント処理で十分です。
- RFPへの添付：判断の理由を書き添えると、発注側とベンダーの認識がそろい、「なぜここはSSRなのか」という議論を避けられる
- 自社ページへの当てはめ：技術用語が分からなくても、確認の問いを自社のページに当てはめるだけで、ベンダーとの会話の質が変わる
Vercel従量課金の運用コストの予測
Next.jsの要件定義で最も見落とされやすいのは、初期開発費ではなく、運用フェーズのランニングコストです。特にVercelに代表されるホスティングサービスは従量課金のため、アクセスが増えると費用が跳ね上がります。そこで、運用コストを非機能要件として事前に予測しておくと、後の予算超過を防げます。
従量課金が跳ね上がる構造の理解
Vercelは、Gitと連携した自動デプロイなど開発体験が極めて優れ、立ち上げも容易です。一方で、課金は利用量に応じて積み上がる構造です。
SSRを多用するとサーバー処理が増え、アクセスの増加とともにコストが想定の数倍に膨らむケースも珍しくありません。立ち上げ時は無料枠や安価な料金で済んでいても、サービスの成長とともに請求が急増し、慌てて構成を見直す失敗が後を絶ちません。
RFPには、次の前提条件を示し、それに基づく運用コストの試算を提案に含めるよう求めるべきです。あわせて、「運用コストが月額いくらを超えない構成にすること」という上限を非機能要件として示すと、ベンダーはコストを意識した設計を提案せざるを得なくなります。
- トラフィック量：想定する月間アクセス数、ピーク時のトラフィック、画像配信量
- サーバー処理：関数の実行回数と実行時間
配信基盤の選択肢と要件への組み込み
Next.jsの配信先はVercelに限りません。Cloudflareやそのほかのクラウド、セルフホスティングといった選択肢があり、コスト構造やロックインの度合いはそれぞれ異なります。
RFPでは、想定アクセス規模における最適なホスティング構成と、その月額コスト試算を複数案で提示するよう求めます。そうすれば、コストとロックインの両面から比較検討できます。
運用コストは、初期開発費とあわせてTCO（総所有コスト）で捉えるべきです。初期費用を抑えても運用で高くつけば、本末転倒です。要件定義の段階で運用フェーズまで含めたコスト設計をベンダーと共有しておくと、長期的に見て最もコストを抑えられます。
- エッジ環境のCloudflare：アクセスが多く、安定したコストを重視するなら有利なこともある
- 自社管理のインフラ：同じ条件で有利になる場合がある
非機能要件と検収基準の定量化
フロントエンド開発のトラブルの多くは、「フワッとした使いやすさ」を要件にしたまま検収段階を迎え、認識がずれて揉めることから生じます。
これを防ぐには、品質を数字で測れる非機能要件として定め、検収基準まで落とし込むことが欠かせません。
Lighthouseスコアと対応端末の検収基準
表示速度の品質は、Googleが提供するLighthouse（サイトの性能を採点する無料ツール）のスコアで数字にできます。RFPには、「主要ページのLighthouseパフォーマンススコアを90点以上とすること」といった目標値を書きます。
対応する端末やブラウザの範囲も明示しておくと、テストの抜け漏れや、「想定していた端末で崩れる」というトラブルを防げます。
Next.jsは画像最適化やコード分割といった機能で高いスコアを出しやすい技術ですが、実装次第ではスコアが伸びないこともあります。だからこそ、目標スコアは契約の段階で合意しておく必要があり、それが技術の強みを確実に成果へ結びつける担保になります。「速いサイト」という曖昧な言葉を、測れる数字に置き換えることが要件定義の要になります。
- スコアの測定：検収時に主要ページのスコアを測り、目標値と比べる
- 対応端末・ブラウザ：スマートフォン、タブレット、PCと、対応ブラウザの範囲
アクセシビリティと保守要件の明文化
アクセシビリティ（高齢者や障害のある方も使える設計）も、非機能要件としてRFPに明記すべき項目です。その際は、WCAG（Webアクセシビリティの国際基準）のどのレベルまで対応するかを書きます。
公共性の高いサービスや大企業のサイトでは対応が求められることが多く、後から対応するより最初から要件に含めたほうが、圧倒的に低コストです。レベルを曖昧にしたままだと、検収の段階で対応範囲をめぐって追加費用が発生しがちです。
納品後の保守要件も定めておくと、運用フェーズでの引き継ぎが円滑になります。
これらをRFPに織り込むには、機能・性能・保守の各要件を整理し、どれを技術選定の必須条件とするかを見極める作業が欠かせません。どの機能を要件に含めるかは、関連記事のNext.js標準機能の解説も判断材料になります。
- 障害対応とバージョンアップ：障害対応の体制、Next.jsのバージョンアップへの追従方針
- ドキュメント：納品範囲を要件として明文化
まとめ
Next.jsのRFPや要件定義書で成否を分けるのは、機能要件以上に、非機能要件を数字で示せるかどうかです。
技術選定では、事業フェーズとROIから「本当にNext.jsが必要か」を問い直します。そのうえで、採用容易性とベンダーロックイン回避も、要件として書いておきます。
SSRの要否はページ単位で切り分けて明記します。Vercelの従量課金による運用コストは、アクセス想定から予測して上限を示すことが大切です。
フロント特有の非機能要件として、Lighthouseスコア、対応端末・ブラウザ、WCAGレベルを検収基準まで落とし込むと、見積もりの精度が上がり、検収段階のトラブルも防げます。
「使いやすく速いサイトを」といった曖昧な依頼こそ、工数とコストを最も大きく膨らませる原因になります。
riplaは、発注側の事業要件を整理し、技術選定から非機能要件の定量化までを一緒に組み立てるNext.js開発をご支援します。
▼開発を相談する前に読みたい無料ホワイトペーパー
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。