SPAのシステム発注は、業務を整理し、方式と委託範囲を選び、要件・契約・検収基準を合意する順に進めると、費用や納期の膨張を抑えやすくなります。
発注形態を選び、RFPと要件を整え、契約と進め方を決めてから、費用と委託先を比べる流れです。
▼全体ガイドの記事
・SPAのシステム開発の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
SPAのシステムを発注・外注するときの全体像
SPAは、最初に読み込んだHTMLを土台に、JavaScriptがAPIからデータを取得して画面の一部を更新するWebアプリケーション方式です。画面全体を再読み込みせず、検索、登録、承認、一覧更新を続けられるため、社内の管理画面や業務ポータルに向いています。
ただし、フロントエンドだけで業務システムが完成するわけではありません。発注時には、ブラウザ、API、業務ロジック、データベースを含む構成を確認します。
認証基盤、外部サービス連携、監視も発注範囲に含めます。画面だけでなく、システム全体の役割分担を決めておくことが重要です。
SPAの操作性だけでなくAPIと業務ルールを含む発注範囲
受注一覧の絞り込み、詳細表示、承認、販売管理システムへの連携では、画面の見た目よりデータの整合性が大切になります。そのため、二重送信防止、APIの権限制御、通信失敗時の再試行を、業務に応じて設計します。さらに、操作履歴、CSV入出力、通知なども設計の対象になります。
RFPには、「Reactで作る」といった技術名だけでなく、誰が何をどの条件で操作するかを記載します。データの流れも併せて示します。
SPAにする範囲とSSR・SaaSに任せる範囲の分け方
表示方式は、画面の目的と検索流入の有無で選びます。画面の種類ごとに、候補が次のように分かれます。
- 社内管理画面：検索流入が不要で入力や一覧操作が多い場合は、CSR中心のSPAが候補です。
- 公開ページ：商品紹介、求人、ヘルプ、記事などは、SSRやSSGの併用が初期表示やクロールに有利です。
なお、React公式は2025年、Create React Appを新規アプリ向けに非推奨とし、フレームワークまたはViteなどのビルドツールを案内しています（出典: React公式「Sunsetting Create React App」、2025年）。技術名を先に指定するより、画面ごとの目的を起点に構成を選びます。
SPAの発注形態の選び方
発注形態には、SaaS・パッケージ、不足部分の開発、クラウド上のSPA構築があります。独自業務を一から作るフルスクラッチも選択肢です。
判断では、業務を標準機能に合わせやすいか、差別化の必要性があるかを見ます。さらに、既存データとの連携や将来の保守を含め、5年程度の総コストで比べます。
SaaS・パッケージを先に検討する業務
業務を標準機能に合わせやすい領域では、SaaSやパッケージを先に比較します。
- 対象業務：勤怠、経費、会計、CRM、ワークフローなどが候補です。
- 外注範囲：初期設定、権限設計、移行、API連携、画面拡張に絞って外注します。
- 費用面：この範囲なら全面スクラッチより初期開発と保守の負担を抑えやすくなります。
比較時は5年TCOで見ます。まず、ユーザー数、ストレージ、API呼び出しを含めます。さらに、追加アドオンとデータエクスポート制限も確認します。標準機能に合わせて現場業務を無理に変えないことが大切です。
クラウド＋SPAで段階的に広げる業務
複数部署の業務ポータルや既存システムと連携する管理画面では、クラウド上に構成する方法が現実的です。構成要素は、SPAとAPI、データベースを中心に、認証と監視を加えたものです。
全機能を一度に作らず、検索・登録・承認など主要3〜5画面をMVPとしてリリースします。そのうえで、利用状況を見て帳票や高度な分析を追加します。
発注時に、クラウドアカウントの所有者、費用上限アラートの設定、障害時の一次対応者を決めておきます。
フルスクラッチを選ぶべき業務
独自の承認ルール、競争力の源泉になる業務フロー、大量データを扱う特殊な連携は、標準機能で成果が出ない場合にフルスクラッチが候補になります。既存業務をそのまま画面に移すと、古い手順や二重入力まで固定されてしまいます。
そのうえで、現状業務を「残す・廃止する・標準化する・自動化する」に分類します。スクラッチで作る理由を一機能ごとに説明できてから、外注します。
RFPと要件整理の準備事項
RFPは、開発会社に「何を、なぜ、どの条件で作るか」を伝える資料です。同じ前提で提案と見積もりを得るために使います。
完成した仕様書でなくても構いません。背景、対象業務、利用者を明記します。
さらに、現状の課題や希望時期、予算帯も書きます。既存システム、連携先、必須条件も書き込みます。
業務上の正解は自社が決め、技術的な実現方法は候補会社に提案してもらいます。業務の中身まで委託先に任せきりにしないことが大切です。
RFPに書く業務・利用者・データの3点
見積もりの前提をそろえるために、次の3点を具体化します。
- 業務：現状と理想の手順をフローにし、時間がかかる箇所や減らしたい入力ミスを記載します。
- 利用者：管理者、担当者、承認者の役割と人数を整理し、外部ユーザーや同時利用のピークも書きます。
- データ：顧客・商品などの項目と件数を書き、保存期間や正となるシステム、移行の要否も記載します。
画面数に加えて、APIの数や外部連携、権限単位も、見積もりを大きく左右します。
主要画面のプロトタイプと受入基準の準備
利用頻度が高い主要3〜5画面は、開発の前に確認します。対象は一覧検索、詳細編集、承認などです。確認にはワイヤーフレームや操作プロトタイプを使います。
現場担当者に業務の順で触ってもらったうえで、検索結果の表示秒数、必須項目が空欄の場合の登録可否、承認後の通知先まで合意します。
合意した内容を受入基準にしておけば、完成直前に好みの違いから大幅な作り直しになる事態を防げます。
非機能要件とセキュリティ要件の扱い
RFPには、性能や運用、端末対応などの非機能要件も含めます。
- 性能・運用：応答時間や同時接続数、稼働時間を定め、バックアップや復旧目標、監視も決めます。
- 利用環境：ブラウザやスマートフォンへの対応、アクセシビリティを含めます。
- 認可：ログイン画面だけでなく、API側で利用者・組織・レコード単位の認可を検証します。
- 個人情報：委託先と再委託先、データの所在地を示し、漏えい時の連絡と報告を契約に記載します。
SPAの公開クライアントでは、OAuth 2.0のAuthorization Code GrantとPKCEを使います。一方、Implicit Grantは避けることが推奨されています（出典: OWASP「OAuth2 Cheat Sheet」、2026年閲覧）。
契約形態と開発の進め方
SPA外注では、要件が固まる前の調査や要件定義と、仕様が確定した後の実装やテストとで、契約の考え方が異なります。
IPAはシステム開発の健全化に向け、開発フェーズと契約類型として準委任契約と請負契約の論点を整理しています（出典: IPA「システム開発の健全化に向けて」、2025年）。契約名よりも中身で判断します。成果物や責任分界は本文と個別契約で確かめ、変更手順と検収条件も併せて見ます。
要件定義の準委任と確定した開発の請負
準委任は、専門家が業務を行うことに対して報酬を支払う考え方です。調査や整理、設計、開発支援などが対象になります。要件が変わりやすい上流工程やアジャイル開発と相性があります。
請負は合意した成果物の完成を目的とするため、仕様と検収基準が明確な機能の開発に向きます。
実務では、フェーズごとに組み合わせることがあります。たとえば、要件定義は準委任、機能単位の実装は請負、リリース後の改善は準委任とする形です。
変更管理と検収条件の契約前の合意
SPA開発では、プロトタイプを触った現場から追加要望が出ることが普通です。変更をすべて無償で対応すると、開発会社は品質か納期を削ることになり、発注者は予算超過に直面します。
契約書や個別契約には、変更要求の受付方法、影響分析、追加見積もりを定めます。さらに、優先順位と承認者、リリースへの反映時期も決めます。
検収は、画面の表示だけでなく、業務シナリオと権限別の操作、エラー時の動きまで基準にします。性能やデータ移行後の照合も含めます。
ソースコード・運用資料・障害対応の引き渡し
納品物には、ソースコードに加えて資料とデータも含めます。引き渡す内容は一覧にして確認します。
- 設計資料：API仕様書、画面仕様、データモデル、環境構築手順、IaC
- テスト資料：テストコードとテスト結果
- 運用資料：デザインデータ、依存パッケージ、管理者マニュアル、移行手順、障害時の連絡網
ソースコードやデザインデータの利用権と、第三者ライブラリのライセンスを確認します。さらに、クラウドアカウントの所有者と再委託の範囲も確かめます。
保守の応答時間と復旧目標も決めておきます。Google CloudやAWSのアカウントを開発会社名義にすると、委託先を変える際に移行しにくくなるため、可能な場合は自社のアカウントで管理します。
SPAのシステムを外注する費用相場
SPA単独の全国統計や公的な一律価格表はありません。そのため、業務・Webシステムの公開相場を組み合わせた2026年時点の目安を参考にします。
金額は、同時利用者数やAPI数、既存システム連携によって変わります。画面数に加えて、認証・監査やデータ移行、テスト範囲も金額を左右します。
SIA株式会社の2026年公開情報は、小規模100万〜300万円、中規模500万〜1,000万円、大規模1,000万円以上としています（出典: SIA株式会社「システム開発の費用・相場 2026年版」）。ただし、SPAの見積もりを比べるときは、どの工程が含まれているかを確認します。
規模別の費用と期間の目安
SPAの費用と開発期間は、規模や含める機能によって異なります。
- 小規模の社内SPA：ログイン、権限、CRUD、検索、簡易API、5〜10画面程度で300万〜700万円、3〜6カ月程度が目安です。
- PoC・MVP：画面を絞る場合、100万〜300万円、1〜3カ月程度の提案もあります。
- 中規模：複数部署、ワークフロー、帳票、ダッシュボード、SSO、外部API連携を含み、700万〜1,500万円、5〜9カ月程度が目安です。
- 大規模：基幹・顧客向けは1,500万〜5,000万円以上、9〜18カ月程度が見込まれます。
全社刷新やERP連携は、5,000万円超や1年以上になることもあります。
PoCやMVPの提案は、本番のセキュリティ診断や移行を含まない場合があります。監視や保守も、提案に含まれないことがあります。
見積もりの内訳とランニングコスト
見積もりは、初期の開発工程と稼働後の費用に分けて確認します。
- 設計・環境：要件定義、UI・UX設計、アーキテクチャ設計、環境構築
- 開発・移行：フロント、API・バックエンド、テスト、移行、リリース支援
- 工程別の配分目安：要件定義10〜12%、設計・環境構築22〜24%、実装48〜50%、テスト15〜17%
- 運用費：クラウド、データベース、CDN、WAF、監視、メール・通知
- 保守関連：脆弱性診断、ブラウザ検証、保守運用
また、データ移行や外部連携、セキュリティ診断を別計上する会社もあります。そのため、工程別の割合が近いかだけで、見積もりの良し悪しを判断しません。各工程に何が含まれるかを見て、見積もりを読みます。
保守費は初期開発費の年15〜25%程度が一つの目安です。障害対応だけか、脆弱性対応まで含むかで、金額は変わります。OS・ブラウザの更新や法改正、軽微な改善まで含むかでも差が出ます。
見積書では、初期費用と月額固定費、従量課金を分けて確認します。さらに、年次更新費と追加開発費も分けて示してもらいます。そのうえで、1年だけでなく3〜5年のTCOで比べます。
委託先の選定と見積比較の確認ポイント
開発会社は、ReactやVueを使えるかに加えて、業務ヒアリングの進め方を見て選びます。さらに、APIと権限設計、データ移行とテストの進め方を確認します。リリース後に誰が担当するかも、事前に確かめます。
株式会社エヌデーデーは、React SPAとSalesforce・CTI・既存基幹の連携事例を紹介しています。ディレクトリジャパン株式会社は、Reactによる基幹システムUI刷新で上流支援からAPI開発までを公開しています。こうした事例は、自社と同じ業務・連携・体制かを確かめる材料になります。
業務・規模・担当範囲で見る実績の確認
「SPAの開発実績あり」の一言で終えず、具体的に質問します。利用者数や画面数、連携先を聞き、データ量や同時接続、公開後の保守期間も確認します。なお、社内管理画面と一般ユーザー向けの大量アクセスサービスでは、必要なテストや監視の経験が異なります。
担当予定のPMやテックリードが、提案時だけでなく本番まで参加するかを確認します。さらに、再委託先を含む体制と責任者を明確にしておきます。
見積書の工程と除外項目の比較
相見積もりでは、同じRFPを3社程度に渡し、同じ質問に答えてもらうと比べやすくなります。
- 比較する工程：要件定義、プロトタイプ、UI設計、フロント、API、認証・権限
- 続けて比べる工程：連携、移行、テスト、インフラ、教育、保守
- 記録する条件：各工程の金額、期間、担当、成果物、前提条件、除外項目
- 安い見積もり：テスト、移行、障害対応、デザイン、ブラウザ検証、管理者教育が別料金になっていないか見ます。
- 高い見積もり：過剰な機能や不要な高可用性構成が含まれていないかを精査します。
安さだけで選ばないための責任分界の確認
失敗しやすいのは、画面を先に作り、APIや権限を後から足すケースです。移行や運用も同じ流れで後回しになります。画面だけの見積もりは安く見えても、業務システムに必要な設計が抜けている可能性があります。
- 提案内容：失敗しそうな点、未確定の前提、追加費用が発生する条件を説明してもらいます。
- 発注者側の体制：業務参加者と意思決定者、データ担当を置き、受入テスト担当も決めます。毎週、課題や変更、リスクを確認します。
- 公開ページの方式：ログイン後と同じCSRだけの提案では、SEOと初期表示について質問します。
- 方式の分け方：公開ページだけをSSR・SSGに分ける提案が、目的に沿うかを判断します。
JavaScript実行後のHTMLもインデックス対象です（出典: Google Search Central「Understand the JavaScript SEO Basics」、2026年閲覧）。
SSRや事前レンダリングは、利用者とクローラー双方の表示を速くします。ただし、すべてのボットがJavaScriptを実行できるわけではありません。
SPAのシステム発注・外注でよくある質問
SPAの発注では、外注先へ相談する前に確認しておきたい疑問が出ます。技術選定や費用のほか、社内体制や既存システム連携についても聞かれます。
社内業務システムは必ずSPAにした方がよいですか？
SPAにするかは、業務の形で判断します。検索や登録を続ける管理画面や、入力状態や絞り込みを保持したい業務には適しています。
ページ数が少ない参照画面や、SEOが重要な公開ページでは、MPA、SSR、SSGが適する場合があります。
業務改善の効果と保守負担を比べ、画面ごとに方式を選びます。
SPAのシステム開発費用を抑えるにはどうすればよいですか？
業務上の必須機能を絞り、主要3〜5画面のMVPから始める方法が有効です。また、標準化できる部分はSaaSやパッケージに任せます。
さらに、独自性の高い機能だけをSPAで作ると、初期費用と保守範囲を抑えやすくなります。
テストや移行、セキュリティは削らず、段階導入によって後続の工程に分けます。監視は後続の工程で扱います。
社内にエンジニアがいなくてもSPAを発注できますか？
発注はできますが、社内に業務責任者と意思決定者は必要です。業務要件や技術設計を開発会社に支援してもらう場合でも、その役割は社内に残ります。
改善したいことと利用者は、発注者が決めます。正とするデータや完成の判定方法も、発注者が決めます。
外注先に、リスクや追加費用、納期への影響を専門用語なしで説明できる担当者がいるかを確認します。
開発会社を途中で変更できるようにするには何を確認しますか？
契約には、ソースコードやAPI仕様、インフラ構成の引き渡し条件を記載します。さらに、IaCやテストコードに加え、デザインデータとアカウントの所有権も記載します。
特に、リポジトリやクラウドを開発会社だけが管理すると、契約終了時に移行できない場合があります。
定例の場で成果物を共有し、担当者しか知らない手順をなくします。さらに、保守の応答時間と引き継ぎ期間も決めます。
SPAのシステム発注・外注のまとめ
SPAを外注するときは、技術名や画面数だけでなく、業務の流れまで含めて発注範囲を決めます。APIや認証・権限、データ移行は、その範囲の中心になります。テスト、監視、保守も含めて決めます。
SaaS・パッケージで標準化する部分、クラウド＋SPAで段階的に作る部分、スクラッチで差別化する部分を分けると、予算と効果のバランスを取りやすくなります。
発注前に確認する5つの項目
発注前の確認事項は、業務と技術、契約の観点から整理できます。
- 方式と範囲：SPAにする画面とSSR・SaaSに任せる範囲
- 業務と利用者：利用者・権限・業務フロー
- データ連携：API・既存システム・データ移行
- 品質条件：受入基準・非機能要件・セキュリティ
- 契約と運用：成果物・保守責任
RFPにまとめて3社程度へ同じ条件で依頼し、工程別の金額と除外項目を比べます。総額の比較では見えない提案の差が、浮かび上がってきます。
業務課題とMVPの整理から始める相談
発注の相談は、対象業務を選び、必要な情報を整理してから進めます。
- 最初から全機能の完成形を決めず、現場が最も時間を使う一つの業務を選びます。
- 主要な利用者と入力・検索・承認の流れを整理し、現在のデータや改善したい指標も書き出します。
- プロトタイプや概算を相談し、業務理解からAPI・権限設計、テスト、引き継ぎ、運用保守まで見通せる委託先を選びます。
▼全体ガイドの記事
・SPAのシステム開発の完全ガイド
▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。