SPAのシステム開発の進め方/やり方/流れや方法/手法/工程/手順

SPAのシステム開発は、業務要件の整理と方式・発注先の選定を経て、設計・開発・テスト・定着の順に進みます。この流れで進めると、作業時間や入力ミスの改善につながります。

▼全体ガイドの記事
・SPAのシステム開発の完全ガイド

・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。

SPAのシステムの全体像

SPAはSingle Page Applicationの略で、最初に読み込んだHTMLを土台に、JavaScriptがAPIからデータを取得する方式です。

必要な部分だけ画面を更新するWebアプリケーション方式で、ページ全体を毎回読み直すMPAとは異なります。

一覧から詳細、登録、承認へ進む業務では、操作の流れを保ちやすいのが特徴です。ただし、画面の裏側にはバックエンドやデータベースが必要です。

業務システムでSPAが向いている業務

SPAは、同じ画面のなかで検索や絞り込み、編集、承認を繰り返す業務と相性がよい方式です。

• 販売管理：受注一覧で顧客を探し、在庫と納期を確認しながら明細を編集します。
• 営業管理：一覧から案件を選び、活動履歴を更新する場面です。
• ワークフロー：申請内容を確認し、差し戻しや承認を行います。

画面を移っても入力途中のフィルタ条件やタブの状態を保ちやすく、そのぶん画面遷移のたびに操作をやり直す負担が減ります。

採用の目的を「見た目が滑らかになること」だけに絞ると、判断を誤ります。というのも、品質には二重送信防止、入力エラー表示、通信失敗時の再試行も含まれるからです。

権限のないレコードの非表示、監査ログ、アクセシビリティも必要です。さらに、ブラウザの更新に追随できることも欠かせません。成果指標は、作業時間や入力ミスで測ります。

企画段階では、確認待ちや他システムへの転記をどれだけ減らせるかも検討します。この効果は、ページ遷移の速さとは別に見ておきます。

SPAを構成する範囲と、SPAにしない範囲

典型的なSPAは、画面やデータに加えて、認証や外部連携、運用基盤まで含めて構成します。

• SPAにする画面：ログイン後の業務操作を中心に据えます。
• 公開ページ：検索流入が必要なら、配信方式を分けて考えます。
• 構成要素：API・BFF、業務ロジック、DB、認証基盤、外部連携、CDN・WAF・監視を含めます。

画面だけをSPAにしても、API側の認可は欠かせません。利用者・組織・レコード単位の認可を検証しないと、情報漏えいにつながります。あわせて、データの正、APIの責任範囲、障害時の復旧範囲も決めておきます。

社内のログイン後画面は、CSR中心のSPAにしやすい方式です。

一方で、Google Search Centralは、JavaScriptで生成されるコンテンツが検索結果に反映されない場合があると説明しています。また、同機関は動的レンダリングを恒久的な解決策とは位置づけていません。

検索流入を得たい公開部分はSSRやSSGで配信し、ログイン後の操作画面だけをSPAにするなど、範囲を分けます。

React・Vue・フレームワークの選定ポイント

選定では、技術の名称よりも、担当会社が継続して保守できるかを確かめます。

• 標準化：ルーティング、データ取得、コード分割、認証、テスト、アクセシビリティを確認します。
• 保守体制：採用バージョン、更新担当、脆弱性対応、メジャー更新の計画。
• 実績と引き継ぎ：本番運用の年数、E2Eテスト、担当交代後の成果物。

React、Vue、Angularのどれを選ぶ場合でも、この3点で標準化の方法を比べます。

React公式は2025年2月、Create React Appを新規アプリ向けに非推奨としました。また、フレームワークまたはViteなどのビルドツールを案内しています。

採用バージョンや更新計画は、見積もりと運用契約に含めておきます。

発注先には、本番画面の利用年数や、コード分割とキャッシュ更新の設計を尋ねます。加えて、E2Eテストをどの業務シナリオで自動化するか、担当が替わっても引き継げる成果物を確かめます。

一つの事例で、画面やAPIを説明してもらいます。権限や監視、運用手順も含めると、実装力と保守力を比べやすくなります。

SPAのシステム開発の進め方（6フェーズ）

画面から作り始めると、後からAPIや権限の制約が見つかり、作り直しが起きやすくなります。

要件整理から定着までを6フェーズに分け、フェーズごとに次へ進む条件を決めておくと、関係者の認識をそろえられます。また、業務の整理と稼働後の定着も、開発工程に含めます。

フェーズ1：要件整理による業務と成功条件の定義

最初に、誰がどの業務をどの頻度で行い、何分かけているかを一覧にします。

• 利用者と業務：役割ごとの操作、参照データ、廃止・標準化・改善する作業を整理します。
• 成果物：業務フロー、利用者と権限、画面とデータ項目、連携先、優先順位、非機能要件、受入基準の一式。
• プロトタイプ：主要3〜5画面で検索、登録、承認、差し戻しを試します。
• 前提条件：個人情報、連携頻度、停止許容時間、RPO・RTO、対応ブラウザ、アクセシビリティ水準。

利用者は、役割ごとに分けておきます。管理者、現場担当者、承認者、外部利用者などが対象です。そのうえで、現場の利用者には簡易プロトタイプを実際に操作してもらいます。

「便利そう」という感想だけで終わらせず、1件あたりの処理時間や入力項目数、エラー時の復帰方法を確かめます。

利用者数と同時接続数、最も重い検索条件、データ量の増加見込みは、事前に調べておきます。あわせて、バックアップの保持期間も確認します。

前提が未定のまま「Reactで作る」と決めると、実装後に変更が生じ、変更管理が難しくなります。

フェーズ2：SaaS・パッケージ・スクラッチと発注先の選定

要件を整理したら、標準化できる業務と独自に開発する業務に分け、SPAで作る範囲を絞ります。

• SaaS・パッケージ：標準化しやすい業務はFit to Standardを基本にします。
• スクラッチ：独自業務や競争力の源泉、大量データ処理などが候補になります。
• 発注先：業務ヒアリング、API・認証・権限、移行、切り戻し、テスト、SLA、脆弱性対応の担当を比べます。
• 契約と成果物：コード、IaC、設計資料、ライセンス、再委託、アカウント名義、保守移管条件を確認します。

勤怠、会計、CRM、ワークフローでは、API連携や不足画面だけを追加すると、5年の保守負担を抑えられます。

相見積もりでは、同じRFPを2〜3社に渡し、工程、前提、除外事項、体制、成果物を同じ粒度で比べます。

著作権の帰属に加えて、成果物の引き渡し条件も契約前に確かめます。

開発会社を変える場合にどこまで協力するかも明記しておくと、将来の内製化や保守移管に備えられます。

フェーズ3：画面・API・認証の設計と開発

画面仕様とAPI仕様は、業務シナリオに沿って結び付けて作ります。

• 画面・API：入力、表示、エラー、再試行、二重送信防止、HTTP応答、ページング、ソート、同時更新の定義。
• 認証・認可：OIDC、テナント分離、代理操作、パスワードリセット、退職者無効化、監査ログを設計します。
• 開発の進め方：代表業務を縦切りで先行実装し、利用者の意見を受けて範囲を広げます。
• 仕様変更：理由、影響、工数、納期、受入基準を記録し、優先順位を更新します。

画面ごとに、入力項目や表示条件、ローディング中、空データの扱いを決めます。APIでは、エラーの形式も定義します。

OpenAPIなどで契約を共有しておくと、フロントエンドとバックエンドの認識のずれを減らせます。

認証では、ログイン後に何ができるかも併せて設計します。社内SSOなら、OIDCを使います。外部ユーザーを含む場合は、テナント分離も確かめます。

OWASPは、OAuth 2.0の公開クライアントでAuthorization CodeとPKCEを使う方針です。その方針では、Implicit Grantは使いません。

設計書では、アクセストークンをブラウザに置く方法や、HttpOnly・Secure・SameSite Cookie、BFFの採用を確認します。

CORSとCSRFの制御も設計書に記載し、担当者の経験だけに頼らないようにします。

まず、ログイン、一覧検索、詳細、登録、承認、履歴確認を一つの縦切りで実装し、利用者の意見を得ます。

その後で帳票やCSV、通知、複雑な検索条件に広げると、業務上の違和感を早く見つけられます。

フェーズ4：業務・性能・セキュリティのテスト

画面が表示されるかを確かめるだけでは、テストとして不十分です。そこで、各テストを要件に対応付けます。

• テスト範囲：単体、API・画面結合、E2E、権限、端末、負荷、脆弱性、利用者受入を計画します。
• 業務ルール：閲覧権限、承認後の編集、連携失敗時の再送、CSVが業務側で開けるかを確かめます。
• SPA固有動作：戻る・進む、URL直打ち、リロード、複数タブ、セッション切れを試します。
• 性能：95パーセンタイル、同時利用、重い検索、バッチ連携の重なりを確認します。

業務ルールは、具体的なシナリオにしてテストします。

通信が遅い環境やオフラインからの復帰では、古いキャッシュが残らないかも確かめます。

APIの応答が遅くても画面が固まらないか、再クリックで二重登録が起きないかも確認します。

負荷テストは、平均値だけで判断しないようにします。

フェーズ5：小さな稼働と切り戻せる状態の確保

本番では、部署や業務を限定したパイロットから始め、全社への一斉展開は避けます。

• 移行計画：並行稼働期間、基準日、件数照合、未処理データの扱いを決めます。
• 障害対応：連絡網、切り戻し条件、意思決定者を事前に定めます。
• 稼働判定：残課題、受入合格率、応答時間、復旧確認、監視、権限、問い合わせ窓口を見ます。

問題が起きてから切り戻しを考えると、現場が不具合を我慢しかねません。

その場合、停止時間や信用の損失が大きくなります。そのため、稼働判定は不具合件数だけに頼らないようにします。

運用担当者の訓練も行い、開発者や業務責任者、インフラ担当、ヘルプデスクが同じ手順書を使います。

稼働判定では、残課題を重大度ごとに分けて見ます。主要操作の応答時間や、バックアップからの復旧も試しておきます。

フェーズ6：利用状況を見ながらの定着

システムは、稼働させただけでは成果になりません。そのため、利用状況と業務の変化を計測します。

• 利用状況：ログイン率、主要機能の利用率、問い合わせ件数を見ます。
• 業務の変化：処理時間、入力エラー、差し戻し、手作業への逆戻りを追います。
• 定着支援：初月の研修と問い合わせ対応を厚くし、寄せられた質問をマニュアルに反映します。
• 継続改善：月次または四半期ごとに要望を管理し、保守範囲も見直します。

利用状況と業務の変化の指標から、現場の作業が止まりやすい箇所を把握します。

操作説明は、受注登録から承認依頼までの業務シナリオに沿って作ります。

たとえば、在庫不足を確認して担当者へ通知する流れを説明する例もあります。

保守の範囲には、ブラウザやOSの更新、脆弱性への対応、クラウド費用、バックアップ、障害訓練のほか、権限を洗い出す作業も含まれます。

新機能を足す前に、使われない画面や重複入力を減らすと、満足度と運用コストを改善できる場合もあります。

SPAのシステム開発の費用相場とコストの内訳

SPA単独の全国統計や公的な価格表は確認できません。そのため、ここに示す金額は、NotebookLMの業務システム相場と、2026年公開のWebシステム開発相場を組み合わせた推定です。

費用は、画面数に加えて同時利用者数やAPI数で変わります。さらに、既存システムとの連携やデータ移行、認証・監査、テスト範囲、保守体制も影響します。

株式会社SIAの2026年版の相場解説では、規模と機能を整理し、内訳を示したうえで複数社に概算を依頼する考え方が示されています。

規模別の費用と期間の目安

費用と期間は、規模や含める機能によって異なります。下に示す金額と期間は目安として比較するもので、いずれも確定価格ではなく、要件が確定する前のレンジです。

• 小規模：社内向け5〜10画面程度なら、300万〜700万円、3〜6カ月程度が目安です。
• MVP・PoC：単機能に絞ると100万〜300万円、1〜3カ月程度の提案もあります。
• 中規模：複数部署向けで700万〜1,500万円、5〜9カ月程度の範囲です。
• 大規模：顧客向け・基幹系は1,500万〜5,000万円以上、9〜18カ月程度の可能性があります。
• 全社刷新：ERP・会計・販売・在庫は5,000万〜1億円以上、1〜2年以上の場合もあります。

小規模の社内SPAは、ログイン、権限、CRUD、検索、簡易APIを含む想定です。

MVPやPoCは、本番用のセキュリティ診断、データ移行、運用設計を含まない場合があります。

中規模には、ワークフロー、帳票、ダッシュボード、SSO、外部APIや既存DBとの連携を含みます。

大規模SPAでは、マルチテナント、大量データ、リアルタイム連携、監査ログ、可用性やDRまで含む場合があります。

要件定義・設計・実装・テストの費用配分

初期費用は、要件定義、設計・環境構築、実装、テストに分けて比べます。

• 要件定義：10〜12%が目安です。
• 設計・環境構築：22〜24%が目安です。
• 実装・テスト：実装48〜50%、テスト15〜17%を配分の起点にします。
• 人月単価の参考：PMは90万〜150万円、SEは65万〜110万円です。
• 人月単価の参考：PGは50万〜90万円、テスターは45万〜80万円程度です。

配分を見ると、実装だけが大きく、要件整理やテストが極端に少ない見積もりを見つけやすくなります。

比率は案件によって変わるため、各項目の人日と成果物を確認します。

単価は、経験や契約形態、地域、業務知識によって変わる参考値です。

画面部品の再利用、デザインシステム、テスト自動化の有無も工数に影響します。また、連携先の仕様調査を誰が担うかによっても、必要な工数が変わります。

クラウド・保守・移行を含めた5年TCO

5年TCOで考えるときは、初期費用に加えて、利用料や保守に含まれる作業を確認します。

• 基盤費用：クラウド、DB、CDN、WAF、監視、ログ保管、メール・通知を含めます。
• 運用費用：脆弱性診断、ブラウザ検証、バックアップ、移行、研修も見込みます。
• SaaS・パッケージ：初期設定等は20万〜300万円程度で、利用料は月額課金が目安です。
• 保守：初期費用の年15〜25%程度を目安に、契約範囲を確認します。
• 契約明細：「保守一式」ならSLA、対応時間、対象外作業、休日対応、追加改修単価を分けてもらいます。

ユーザー数やAPI利用量、ストレージ、追加アドオンまで含めて5年TCOで比べると、初期費用だけでは見えない差がつかめます。

保守契約では、脆弱性対応、フレームワーク更新、OS・ブラウザ対応、障害の一次切り分けを確認します。

データ復旧や問い合わせ、軽微な改修が月額に含まれるかどうかで、実質費用も変わります。

SPAのシステム開発の見積もりのポイント

見積もりを比べるときは、合計金額よりも前提条件と除外事項をそろえることが大切です。たとえば「画面数」の定義が入力画面だけか、一覧や詳細、エラー、権限違いまで含むかで、工数が変わります。

外部連携も、APIの有無や仕様調査の必要性、リアルタイムか日次バッチかによって、難易度が異なります。

依頼時には、業務フローや画面のラフ、利用者数、データ量を渡します。そのほか、連携先、希望時期、保守範囲も伝えます。

RFPに書く業務シナリオ

RFPには、「顧客管理画面を作る」という一文だけでなく、営業担当の業務シナリオを書きます。

• 業務の流れ：検索、権限に応じた参照、商談登録、上長承認、監査ログで追跡します。
• 期待動作：正常系と、入力ミス、権限不足、連携停止、同時更新、タイムアウト時を記載します。
• 優先順位：Must・Should・Couldと受入基準を置き、段階導入する機能を決めます。

こうすると、画面だけでなくAPI、権限、ログ、テストまで含めた見積もりになります。

MVPのMustは、ログイン、主要な検索・登録・承認、必須の権限、データ照合、監視などです。

たとえば、利用頻度の低い帳票や高度な分析は、段階2に回す方法があります。

契約前に優先順位を決めておくと、追加の要望が出たときに、延期する対象も判断しやすくなります。

複数社の工程・成果物・体制の比較表

比較表を使い、工程・成果物・体制を各社で同じ項目にそろえます。

• 工程・成果物：要件定義、試作、設計書、API仕様の作成者、レビュー、各種テストを比べます。
• 移行・支援：データ移行、リリース支援、研修、保守の有無を確認します。
• 体制：担当者、再委託、オフショア時のブリッジ、稼働後の継続期間を見ます。
• 契約条件：除外・変更請求、テストデータ、納品形式、障害時の初動と復旧目標を尋ねます。

担当者は、氏名と役割まで具体的に確認します。再委託の有無も確認の対象です。

技術スタックの提案が異なっても、品質を担保する活動の有無は比べられます。

回答が曖昧な会社は、初期価格が低いからといって選ばない方が安全です。

既存DBの品質調査にかける日数も確かめます。納品時のソースコードやクラウド設定は、どの形式で受け取るかも確認します。

予算超過と運用トラブルのリスク対策

NotebookLMのリサーチでは、要件定義を圧縮すると工数が1.3〜1.5倍に膨らむ可能性が指摘されています。

• 変更管理：受付窓口、影響分析、承認、追加見積もり、納期、受入基準の履歴を決めます。
• 情報管理：個人情報の保管先、委託先、海外クラウド所在地、権限、ログ期間、漏えい時の連絡を定めます。
• セキュリティ：秘密情報をブラウザに置かず、API認可と依存パッケージ監視をテストします。
• 契約：要件が未確定の上流は準委任、成果物と受入基準が明確な開発は請負とする方法があります。

この数字は全案件に当てはめず、要件の曖昧さへの警告として使います。

個人情報を扱う場合は、個人情報保護委員会のガイドラインを確認します。ガイドラインには、安全管理措置や委託先監督が含まれます。保存場所や委託先は、契約と運用手順に記載します。

依存パッケージは継続して監視し、ガイドラインの原則は受入テストで検証します。

要件整理とプロトタイプで前提を確定してから、本開発の範囲と価格を決めます。そうすると、発注側と開発会社の双方がリスクを説明しやすい形になります。

SPAのシステム開発でよくある質問

SPAのシステム開発で多い疑問に順に答えます。前提となるプロジェクトの条件によって判断が変わる点も、あわせて押さえます。

業務システムはすべてSPAにした方がよいですか？

すべてをSPAにする必要はありません。検索や登録、承認を続けて行うログイン後の画面は、SPAに向いています。

検索流入が重要な公開ページはSSRやSSG、標準化しやすい業務はSaaSやパッケージとの併用が合理的です。

画面や業務ごとに、操作性、SEO、開発費、保守負担を比べて範囲を決めます。

SPAのシステム開発には何カ月、いくらかかりますか？

小規模の社内SPAなら300万〜700万円、3〜6カ月程度、中規模なら700万〜1,500万円、5〜9カ月程度が目安です。

MVPだけに絞るなら、100万〜300万円程度の提案もあります。ただし、本番用の移行やセキュリティ、保守を含むかで金額は変わります。

画面数、API連携、権限、データ移行、テストの範囲をそろえて、見積もりを比べてください。

ReactとVueはどちらを選べばよいですか？

自社の要件と保守体制に合う方を選びます。その際は、開発会社の実績や採用候補者の確保、ルーティング、データ取得を比べます。

テストやアクセシビリティ、更新方針、既存資産との接続も比較の項目です。また、Reactでは、Create React Appが2025年に新規アプリ向けに非推奨となりました。

フレームワークやビルドツール、コード分割、認証、更新担当まで、提案に含めてもらいます。

SPAの認証やセキュリティで最低限確認することは何ですか？

認証・認可は、ログイン方式からAPIの権限、個人情報の扱いまでを一連で確認します。

• 認証とセッション：OAuth 2.0・OIDC、Authorization CodeとPKCE、トークン管理、セッション失効を確認します。
• 攻撃対策：CORS・CSRF・XSS対策、レート制限、監査ログ。
• API認可：利用者、テナント、レコード単位で権限を検証します。
• 個人情報：保存、委託、ログ保管、漏えい時の連絡手順。

認可になるのは、API側で権限を検証したときです。画面でボタンを隠すだけでは認可になりません。そのため、各項目を設計、テスト、運用の各工程で確かめます。

まとめ：業務成果から逆算するSPAのシステム開発

大切なのは、SPAを採用すること自体ではなく、作業時間や入力ミス、転記、確認待ち、運用負担を改善することです。

まず、業務フロー、利用者と権限、データの正、連携先、非機能要件を整理します。そのうえで、SPAにする範囲と、SaaS・パッケージ・SSRなどを組み合わせる範囲を決めます。

6フェーズで確認する成功条件

要件整理では成功指標と受入基準を決め、選定では業務の理解やAPI、権限、移行、保守を比べます。

設計・開発では、エラーや認証も定義します。続くテストでは、業務シナリオや性能、セキュリティを検証します。

稼働時は移行の照合と切り戻し条件を用意し、定着後は利用状況と問い合わせから改善を進めます。この順番を守ると、後から要件が見つかるリスクを抑えられます。

最初の一歩：主要業務のプロトタイプ化

最初から全社の画面を洗い出し、完璧な仕様書を作る必要はありません。

• 業務を選ぶ：利用頻度が高く、改善効果を測りやすいものを一つ選びます。
• 前提を確かめる：主要3〜5画面のプロトタイプでのAPI・権限の確認。
• 発注先を比べる：同じRFPを複数社へ渡し、費用、期間、作業、成果物、体制、保守、5年TCOを比較します。

SPAを適切な範囲で採用し、稼働後まで責任を持てる体制を選ぶことが、長く使えるシステムにつながります。

▼全体ガイドの記事
・SPAのシステム開発の完全ガイド

▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック

会社紹介

株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

株式会社riplaの会社HPはこちら

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール

張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。