SPA開発とは？MPAとの違い・SEO・費用と、発注者が決める4つの設計【2026年版】

「開発会社の提案書に『SPAで構築します』と書かれていたのですが、これは何がよくなるのでしょうか」——自社サービスの刷新を検討している事業会社の方から、こうした相談をよく受けます。金額が他社より高い理由を社内に説明しなければならない、けれど検索して出てくるのは開発者向けの技術記事ばかりで判断材料にならない。そういうお困りごとです。

SPA(シングルページアプリケーション)は、1枚のHTMLを読み込んだあと、画面の中身だけをJavaScriptで書き換えていくWebアプリケーションの作り方を指します。クリックのたびにページ全体が真っ白になって切り替わる従来型(MPA)と違い、必要なデータだけを取りに行って必要な場所だけを差し替えるため、2回目以降の操作が速く感じられます。ただし、その速さには原資があります。最初の1回だけは、動作に必要なJavaScriptをまとめて読み込むぶん重くなります。

もうひとつ、この分野には厄介な事情があります。「SPAはSEOに弱い」という説明が、いまも大量に流通していることです。これは2015年前後には正しかった話で、2026年9月16日時点のGoogle検索セントラルの記述とは食い違っています。Googleは現在、クロール・レンダリング・インデックス登録の3段階でJavaScriptを実行すると明記しており、かつて対策として紹介された動的レンダリングについては「回避策であり、推奨する解決策ではない」と自ら書いています。古い前提のまま対策を積むと、必要のない費用がかかります。

この記事では、SPAとは何かという定義から、MPAとの違い、SEOの現在地、URL・履歴・状態管理・認証という4つの設計判断、React・Vue・AngularとNext.js・Nuxtの位置づけ、そして自社のサービスがSPAに向くかどうかの判定までを、発注する側の言葉で整理します。コードは一行も出てきません。判断に必要なのは実装の知識ではなく、何が何と引き換えになるかの理解だからです。

私は人材業界の出身で、2018年からホーチミンに拠点を置き、約100社の開発体制づくりを支援してきました。当社はReact・Vue.js・Next.jsでの開発実績があり、SPAで作るべき案件とそうでない案件の両方を見ています。だからこそ最後に、SPAにしないほうがよいケースも率直に書きます。売り込みではなく、判断の材料としてお読みください。

SPA(シングルページアプリケーション)とは——1枚のHTMLを読み込み、以降は中身だけを書き換える作り方

SPAは Single Page Application の略で、日本語ではシングルページアプリケーションと呼びます。名前のとおり「ページが1枚しかない」作り方ですが、利用者から見て画面が1つしかないという意味ではありません。見た目の画面はいくつあってもかまわず、ブラウザが読み込むHTMLの文書が1枚だけという意味です。まずはこの一点を押さえると、以降の話が整理しやすくなります。

MDNの定義——「1つのドキュメントだけを読み込み、JavaScriptで中身を更新するWebアプリ」

Web技術の一次資料であるMDN Web Docsは、SPAを次のように定義しています(2026年9月16日確認)。

1つのWebドキュメントだけを読み込み、別の内容を表示する必要があるときには Fetch などのJavaScript APIを使ってそのドキュメントの本文を更新する、Webアプリの実装方式

短い定義ですが、判断に必要な要素が3つ入っています。第一に「1つのドキュメントだけを読み込む」。第二に「別の内容を表示するとき」、つまり利用者がリンクやボタンを押したときの話であること。第三に「本文を更新する」、すなわちページごと差し替えるのではなく中身を書き換えること。この3つが揃った作り方をSPAと呼びます。

MDNは同じページで、SPAの利点として全体再読み込みを避けることによる性能向上と、より動的な操作感を挙げ、欠点としてSEOの難しさ、状態を維持する手間、画面遷移の実装の複雑さ、性能の計測のしにくさを挙げています。利点と欠点が同じ量だけ書かれている——これが一次資料の温度感です。日本語の紹介記事にありがちな「モダンで高速」という一方的な評価ではありません。

どこがSPAで、どこがSPAでないのか——ページ内の動きだけではSPAとは呼ばない

よくある誤解を先に潰しておきます。ページ内でタブが切り替わる、アコーディオンが開く、入力チェックが即座に走る——こうした動きがあってもSPAとは呼びません。これらは従来型のページでもJavaScriptで昔から実現されてきたものです。

SPAかどうかの分かれ目は、「別の画面へ移動したときに、ブラウザがサーバーへHTMLを取りに行っているかどうか」です。商品一覧から商品詳細へ移るとき、従来型ならブラウザは新しいHTMLを受け取って表示し直します。SPAなら、商品詳細に必要なデータだけを受け取り、いま表示している文書の中身を書き換えます。画面が真っ白になる一瞬があるかどうかが、利用者から見た目印になります。

画面側の話であって、サーバー側の作りとは別の話

もうひとつ整理しておきたいのは、SPAが画面側(フロントエンド)の作り方の話だという点です。サーバー側をどう作るか——1つのまとまりにするか、機能ごとに分けるか——は別の議論です。「SPAだからサーバーも新しい構成にしなければならない」という関係はありません。役割分担そのものについては「フロントエンドとバックエンドの違い」の記事で扱っています。サーバー側の分割については「マイクロサービスとは」の記事をご覧ください。

また、Webアプリという括りの中でSPAがどこに位置するのかを確かめたい場合は、「アプリとは」の記事でネイティブ・Web・ハイブリッド・PWAの4種類を整理しています。SPAはこのうちWebアプリの作り方の一種にあたります。

つまりSPAとは、紙を差し替えるか、同じ紙の上を書き換えるかの違いです。この違いが、次に見る画面遷移の仕組みと速度の話につながります。

MPA(従来型)との違い——画面遷移で何が起きているか、そして速さの表と裏

従来型のWebサイトはMPA(マルチページアプリケーション)と呼ばれます。SPAとの違いを「速いか遅いか」で語る記事が多いのですが、それでは判断できません。判断に必要なのは、クリックした瞬間に何が起きているかという手順の違いと、その結果としてどこの時間が増えてどこの時間が減るのかという差し引きです。順に見ていきます。

MPAの遷移——クリックのたびにサーバーがHTMLを1枚返す

MPAでリンクをクリックすると、ブラウザは次の順で動きます。

1. ブラウザがサーバーへ、そのURLのHTMLを要求する
2. サーバーがデータベースを読み、HTMLを組み立てて返す
3. ブラウザが受け取ったHTMLを解析し、CSSや画像を追加で取得する
4. 画面を最初から描き直す

この方式の強みは、サーバーから返ってきた時点で中身が完成していることです。検索エンジンのクローラも、JavaScriptを実行しなくても本文を読めます。弱点は、画面の大部分(ヘッダー、サイドバー、フッター)が前のページと同じでも、毎回すべてを組み立て直して送っている点です。

SPAの遷移——必要なデータだけを取りに行き、中身を差し替える

SPAでは、最初にHTMLと、画面を組み立てるためのJavaScriptをまとめて読み込みます。2回目以降のクリックでは次の順で動きます。

1. JavaScriptがクリックを受け取り、ブラウザの標準の遷移を止める
2. 必要なデータだけをAPI経由で要求する(多くはJSON形式)
3. 受け取ったデータで、画面の該当部分だけを書き換える
4. あわせてURLと履歴を更新する(この4の仕組みは後述します)

ヘッダーやサイドバーは書き換えないので、通信量も描画の手間も小さくなります。MPAが「紙を差し替える」なら、SPAは「紙の一部分に貼り紙をする」動きです。

対比表——8つの観点でMPAとSPAを並べる

発注判断で効いてくる観点だけを8つ選んで並べます。

表を見ると、SPAが一方的に優れているわけではないことが分かります。初回表示・URL・実装の手間の3項目はMPAのほうが有利です。SPAは「後半の体験のために、前半とつくりの手間を差し出す」構造になっています。

体感速度が上がる理由と、最初の表示が遅くなる理由

体感速度が上がる理由は3つあります。第一に、通信する量が減ること。画面全体のHTMLではなく、変わる部分のデータだけを取りに行きます。第二に、描き直す範囲が狭いこと。ブラウザはページ全体の解析をやり直しません。第三に、白い瞬間が入らないため、待っている感覚そのものが減ることです。

一方で最初の表示が遅くなる理由は、原理的なものです。SPAは画面を組み立てる仕事をブラウザ側に移しています。そのための道具一式(フレームワーク本体と自社で書いた画面のコード)を、最初にまとめてダウンロードして実行する必要があります。Googleのweb.devに掲載されている「Rendering on the web」(Addy Osmani・Jason Miller、2019年2月6日公開・2026年1月5日更新、2026年9月16日確認)は、この点を次のように書いています。

クライアントサイドレンダリングの主な欠点は、アプリケーションが大きくなるにつれて必要なJavaScriptの量が増える傾向があり、それがページのINPに影響しうることだ

同記事は対策として、コード分割を積極的に行うことを推奨しています。つまり「最初に全部を読み込む」のではなく、「その画面に必要な分だけを読み込み、残りは後から取りに行く」という作り方です。これは実装で対処できる問題ですが、対処するという工数が乗ります。見積もりを比べるときは、この項目が含まれているかを確認してください。

ここまでを整理すると、損得の分かれ目は画面遷移の回数です。1人の利用者が1回の訪問で何画面を行き来するか。3〜4画面で離脱するサイトなら初回の重さが効き、20画面、30画面と操作が続く業務画面なら差分描画が効きます。私が相談を受けたときに最初にうかがうのも、この「1セッションあたりの遷移回数」です。

SPAとSEO——「検索に弱い」は2026年時点でどこまで本当か

この記事でいちばん誤情報が多いのがこの節です。「SPAはクローラがJavaScriptを読めないためSEOに弱い」という説明が、いまも日本語の記事に大量に残っています。結論から申し上げると、その前提は現在のGoogleの記述と食い違っています。ただし「だから何もしなくてよい」わけでもありません。何が変わり、何が残っているのかを、公式ドキュメントの文言と更新日で確かめていきます。

Googlebotの3段階——クロール、レンダリング、インデックス登録

Google検索セントラルの「JavaScript SEO の基本を理解する」(2026年3月4日更新、2026年9月16日確認)は、GoogleがJavaScriptを使ったページを次の3段階で処理すると説明しています。

1. クロール——GooglebotがURLを取得し、HTMLを解析してリンクをたどる
2. レンダリング——順番待ちの列に入ったページを、ヘッドレスのChromiumで実際に描画し、JavaScriptを実行する
3. インデックス登録——描画後のHTMLの内容をインデックスに登録する

同ドキュメントは、Googleが常に最新版のChromiumでJavaScriptを実行していると明記しています。つまり「クローラがJavaScriptを読めない」という前提は、現在の事実ではありません。 この説明は、Googleが2015年に旧来のAJAXクロール方式を廃止する前後の記憶がそのまま流通しているものです。同じくGoogle検索セントラルの「検索関連のJavaScriptの問題を解決する」(2025年12月18日更新)は「AJAXクロール方式は2015年に非推奨になったため、URLフラグメントがGooglebotで機能することを期待できない」と書いています。

それでも起きる問題は3つ——URL、レンダリングの待ち行列、soft 404

JavaScriptが実行されるなら安心か、というとそうではありません。公式ドキュメントが挙げている問題は、主に次の3つです。

1. URLの持たせ方。 SPAの初期の実装では #/products/1 のようにURLの後ろのフラグメント(#以降)で画面を切り替える方式がありました。前述のとおり、この方式はGooglebotには機能しません。Google検索セントラルは、フラグメントではなくHistory API を使って通常のURL(パス)で画面を切り替えるよう求めています。1画面につき1つの実URLがあること——これがSPAのSEOで最初に確認すべき点です。

2. レンダリングは順番待ちになる。 クロールと同時に描画されるわけではなく、待ち行列に入ります。Googleは待ち時間の長さを公表していませんが、HTMLに含まれていない情報は、この列を抜けるまでインデックスに載らないという構造は変わりません。更新の反映を急ぐページでは、これが実害になります。

3. soft 404。 存在しない商品ページを開いたときに、SPAは「見つかりません」という画面を出しつつ、HTTPのステータスコードは200(正常)を返してしまいがちです。Googleはこれを検出し、対処として「404を返すURLへリダイレクトする」か「robots の meta タグを noindex にする」ことを挙げています。なお同ドキュメントは、noindex が付いていると、Googleはレンダリングそのものを省略する場合があるとも書いています。JavaScriptで後から noindex を外す作りは機能しません。

SSR・SSG・CSRの整理と、動的レンダリングの現在地

ここで「SPAはSSRにしないとSEOが効かない」という話が出てきます。用語を整理します。

この3つは対立概念ではなく、1つのサービスの中で画面ごとに使い分けるものです。Nuxtの公式ドキュメント(2026年9月16日確認)は、ルートごとに描画方式を切り替えるハイブリッドレンダリングを標準機能として説明しており、一部の経路だけ ssr: false にして完全なSPAにすることもできると書いています。Angularの公式ドキュメントも、サーバー・クライアント・事前レンダリングの3つのモードを挙げ、アプリケーションの要件に応じて選ぶよう案内しています。

そのうえで、重要な訂正がひとつあります。動的レンダリング(クローラだけに別途生成したHTMLを返す仕組み)は、Googleが推奨していません。 Google検索セントラルの「動的レンダリング」(2025年12月10日更新、2026年9月16日確認)は、次のように書いています。

動的レンダリングは、検索エンジンにおけるJavaScript生成コンテンツの問題に対する回避策であり、長期的な解決策ではありませんでした

同ドキュメントは、代わりにサーバーサイドレンダリング、静的レンダリング、ハイドレーションを使うよう案内しています。提案書に「SEO対策として動的レンダリングを導入します」と書かれていたら、その会社の情報が更新されていない可能性があります。その場でGoogleの当該ページを開いて確認してください。

自社の場合にSEOがどこまで問題になるかの判定

ここまでの内容を、自社の状況に当てはめる形で整理します。

• ログイン後の画面が中心のサービス(SaaS、管理画面、社内システム)——検索エンジンに載せる必要がない画面です。SEOの考慮はほぼ不要で、CSRのままで問題ありません
• 記事・商品ページで検索流入を取るサイト——ここは慎重に判断してください。SSRかSSGを併用するか、そもそもSPAにしない選択が妥当です。サイト制作の依頼先の選び方は「ホームページ制作の外注費用」の記事で扱っています
• 公開ページとログイン後の画面が両方あるサービス——公開ページはSSG/SSR、ログイン後はCSRという使い分けが素直です。前述のハイブリッドレンダリングが、まさにこの形を想定した仕組みです

「SPAはSEOに弱い」は、正確には「SPAで公開ページを作るときは、URLと描画方式の設計をしなければ弱くなる」です。設計する対象が増えるという意味であって、できないという意味ではありません。

URL・履歴・状態管理・認証——SPAで発注前に決める4つの設計

SPAで作ると決めたあと、発注する側が判断に関わるべき論点は4つです。いずれもMPAではブラウザが自動でやってくれていたことが、SPAでは実装側の設計事項に移るという共通点を持ちます。自動でやってくれていたものは仕様書に書かれないので、抜けても気づきにくい。ここが一番の落とし穴です。順に見ます。

URLと履歴——ブラウザが自動でやっていたことが、実装の仕事になる

MPAでは、ページを移動すればURLが変わり、戻るボタンが効き、そのURLを誰かに送れば同じ画面が開きます。ブラウザが勝手にやっていることです。SPAはこの標準の遷移を止めてしまうため、同じ体験を自分で作り直す必要があります。そのための仕組みが History API です。

MDNの「Working with the History API」(2026年9月16日確認)は、この API の目的を次のように説明しています。

これらのAPIの主な目的は、ページ全体を読み込む代わりに fetch() などのJavaScript APIで新しい内容に更新するシングルページアプリケーションのようなWebサイトを支えることである

具体的には、pushState() で履歴に新しい項目を追加し、replaceState() で現在の項目を置き換え、利用者が戻る・進むを押したときに発生する popstate イベントで画面を復元します。MDNは、最初の読み込み時の履歴項目には状態が結びついていないため、replaceState() で状態を持たせておかないと、戻ったときに最初の画面を復元できないと注意しています。

発注する側が確認するのは、コードではなく結果です。次の4点が満たされるかを、受け入れ条件として書いてください。

• 画面ごとに固有のURLがあり、そのURLを直接開いても同じ画面が出る
• 戻る・進むボタンが期待どおりに動く
• 一覧から詳細へ入って戻ったとき、スクロール位置と絞り込み条件が保たれる
• URLをメールやチャットで共有したとき、相手に同じ画面が表示される

3点目のスクロール位置は、実装しなければ保たれません。これを仕様に書き忘れたために、納品後に「使いにくい」と言われる案件を何度も見てきました。

状態管理——「いま画面が持っている情報」をどこに置くか

状態とは、いま画面が持っている情報のことです。ログイン中のユーザー名、カートの中身、検索の絞り込み条件、開いているタブ。MPAならページを読み込むたびにサーバーから取り直しますが、SPAは読み込み直さないので、これらを画面側で持ち続けることになります。この「持ち方」を決めるのが状態管理です。

React公式の「Managing State」(2026年9月16日確認)は、複数のコンポーネントで同じ情報を使う場合の基本を、共通の親へ持ち上げること(lifting state up)と説明し、深い階層へ渡す必要がある場合の仕組みとして Context を挙げています。同ドキュメントは「最も重要な原則は、状態に重複した情報を持たせないことだ」とも書いています。Vueでは Pinia、Angularではサービスとシグナルが同じ役割を担います。

発注する側の関心事は、道具の名前ではなく次の2つです。

1. その状態は、リロードしたら消えてよいか。 消えては困るもの(入力途中の申請書など)は、サーバーかブラウザの保存領域に退避する設計が要ります
2. その状態の正しさは、どこで担保するか。 在庫数や権限のように画面側に持たせると危ないものは、必ずサーバーで検証する必要があります

2点目は見落とされがちです。画面側の状態は利用者が書き換えられます。「画面で制御しているから大丈夫」という説明が出てきたら、サーバー側でも同じ検証をしているかを確認してください。

認証とセッション——トークンの置き場所が決まらないまま作らない

SPAは画面側で動くため、ログイン状態の持ち方が論点になります。よくあるのは、サーバーが発行したトークンをブラウザの localStorage に保存する方式です。実装は簡単ですが、JavaScriptから読めるため、サイトに不正なスクリプトを埋め込まれた場合(XSS)に盗まれます。

MDNの「Set-Cookie」(2026年9月16日確認)は、Cookie の HttpOnly 属性について次のように説明しています。

JavaScriptが Document.cookie プロパティなどを通じて Cookie にアクセスすることを禁じる。(中略)これはクロスサイトスクリプティング(XSS)に対する攻撃を緩和する

あわせて Secure(HTTPSでのみ送信)と SameSite(他サイトからのリクエストで送るかどうか。CSRF対策)が定義されています。一般に、HttpOnly + Secure + SameSite を付けた Cookie でセッションを持つほうが、localStorage にトークンを置くより安全側です。

当社では、決済アプリの新規構築でStripe連携・二要素認証・ウォレット・PDF出力を実装した際、この置き場所と有効期限の設計を要件定義の段階で確定させました。認証は後から変えると影響範囲が全画面に及びます。オフショア開発での情報の扱いについては「オフショア開発のセキュリティ対策」の記事で詳しく書いています。

4点を提案書に書けているかの確認リスト

ここまでの4つを、提案書・見積書の確認項目に落とすと次のようになります。

• URL設計: 画面ごとの実URLの一覧があるか。フラグメント(#)方式になっていないか
• 履歴と復元: 戻る・進む、スクロール位置、絞り込み条件の保持が仕様に書かれているか
• 状態管理: リロードで消してよい情報と、消してはいけない情報が区別されているか。サーバー側の検証が二重に用意されているか
• 認証: トークンやセッションの置き場所、有効期限、失効の手順が明記されているか

この4つが書かれていない提案書は、金額が安く見えても、あとで追加になります。逆に4つとも書いてある会社は、SPAの実装経験があると判断してよいと考えています。

React・Vue・Angular と Next.js・Nuxt——選択肢の地図

提案書には、たいてい技術の名前が並びます。React、Vue.js、Angular、Next.js、Nuxt。これらが並列の選択肢に見えるため、発注する側は「どれが一番よいのか」と考えてしまいがちです。しかしこの5つは並列ではなく、2つの層に分かれています。層の違いが分かれば、比較すべき対象がぐっと減ります。

3つのフレームワーク——公式ドキュメントが自ら書いている位置づけ

React・Vue・Angularは、画面を部品(コンポーネント)に分けて組み立てるための道具です。MDNもSPAで広く使われるものとしてこの3つを挙げています。それぞれの公式ドキュメントが自ら書いている位置づけを、2026年9月16日時点で確認しました。

3つとも、SPAしか作れない道具ではありません。どれもSSRや事前生成に対応しており、「Reactだから検索に弱い」といった図式は成り立ちません。選択の実質的な差は、開発者の確保のしやすさ、既存資産との相性、社内やパートナーの習熟度です。

メタフレームワーク(Next.js・Nuxt)——SPAとSSR/SSGを1つの仕組みで扱う

Next.jsはReactの上に、NuxtはVueの上に載る枠組みです。この層が引き受けるのは、ルーティング(URLと画面の対応)、描画方式の切り替え、データの取得と再利用、ビルドと配信の設定といった、アプリを1本のサービスとして成立させるための共通の仕事です。

React公式は、推奨するフレームワークについて「いずれもCSR・SPA・SSGに対応し、サーバーなしでCDNや静的ホスティングへ配信できる。加えて、必要な経路にだけサーバーサイドレンダリングを追加できる」と書いています。Nuxtの公式ドキュメントも、経路ごとに事前生成・SSR・クライアント専用を切り替えるハイブリッドレンダリングを標準機能として説明しています。

ここが実務上いちばん大事な点です。SPAかSSRかは、サービス全体で1つ選ぶものではなく、画面ごとに選べます。 公開している料金ページはビルド時に静的生成し、ログイン後のダッシュボードはブラウザ側で描く。この使い分けを1つの仕組みで扱えるようにしたのがメタフレームワークです。

なお、Next.jsの公式ドキュメント(v16.3.5、2026年8月25日更新、2026年9月16日確認)は、静的に生成した部分を先に返し、残りを後から流し込む方式(部分事前レンダリング)を説明したうえで、ボットやクローラについてはユーザーエージェントで判別し、完全なHTMLを必要とするため、ページ全体をリクエスト時に描画してから返すと記載しています。フレームワーク側がクローラ向けの扱いを持っているということです。

発注者が決めることと、開発会社に任せてよいこと

技術選定は開発会社の領分です。発注する側が「Reactにしてください」と指定する必要はありませんし、指定してもよい結果にはつながりません。代わりに、次の3つを要件として伝えてください。

1. どの画面を検索エンジンに載せたいか。 これが描画方式の選択を決めます
2. 初回表示の目標。 「3秒以内に主要な内容が見えること」のように、測れる形で書きます
3. 将来、誰が保守するか。 社内に引き取る予定があるなら、社内で採用しやすい技術を選ぶ理由になります

当社はReact・Vue.js・Next.jsでの開発実績があり、この3つのいずれでも対応できます。そのうえで案件ごとに、上の3つの条件から逆算して提案しています。技術の名前から入る提案は、たいてい要件の整理が終わっていません。要件を聞かずに技術名だけを並べてくる提案書は、その場で差し戻してよいと考えています。

SPAにすべきか——向くサービス・向かないサービス、SPA化の落とし穴、費用と体制

ここまでの内容を、自社の判断に落とします。SPAは「新しいから採る」ものでも「古いから避ける」ものでもありません。1回の訪問でどれだけ画面を行き来するか、そのサービスの使われ方で損得が決まります。向く場合と向かない場合を並べ、既存サイトをSPA化するときに実際に起きることと、費用が変わる要因、そして外部チームで作る場合の体制まで書きます。

SPAが向くサービス——操作が続き、滞在が長い画面

次の条件に多く当てはまるほど、SPAの投資が回収できます。

• 1回の訪問で多くの画面を行き来する(一覧と詳細の往復、タブの切り替え、絞り込みの繰り返し)
• ログイン後が中心で、検索エンジンからの流入を前提にしない
• 入力や編集の作業が続き、途中で画面が切り替わると作業が中断する
• リアルタイムに近い更新がある(通知、チャット、進捗の反映)
• 同じ画面を毎日使う利用者がいる(業務システム、SaaSの管理画面)

具体的には、SaaSの管理画面、社内の業務システム、予約や在庫の操作画面、地図や分析のダッシュボードが該当します。当社が継続開発を担当している介護記録SaaSのCareViewerも、現場の職員が1日に何度も記録画面と一覧を行き来する使われ方です。日本語対応のブリッジSE1名とフルスタックエンジニア2名の体制で、週次で優先順位を判断しながら開発を進め、コストは従来の半分以下に収まっています。

SPAが向かないサービス——読んで離脱するページが中心のサイト

逆に、次に当てはまる場合はSPAにする理由がありません。

• 記事やコラムを読んで離脱する(オウンドメディア、ニュースサイト)
• 検索エンジンからの流入が主要な導線になっている
• ページ数が10ページ程度で、更新頻度も高くない(コーポレートサイト、採用サイト)
• 1回の訪問で1〜3画面しか見ない
• 社内に保守できる人がおらず、外部にも継続依頼する予定がない

とくに4番目が効きます。3画面で離脱するサイトでSPAにすると、初回の読み込みが重くなる不利だけを受け取り、差分描画の利点をほとんど受け取れません。メディアサイトのSPA化は、当社では基本的にお勧めしていません。静的サイト生成(SSG)とヘッドレスCMSの組み合わせのほうが、表示速度でも運用でも有利な場合がほとんどです。

そもそも作らずに済む場合もあります。予約受付や簡単な業務フローであれば、既製のツールで足りることがあります。判断の前提として「ノーコードとは」の記事と「スクラッチ開発とは」の記事を確認しておくと、作る・借りる・作らないの選択肢が揃います。

既存サイトをSPA化するときの4つの落とし穴

いま動いているサイトをSPAに作り替える場合、新規開発とは別の問題が出ます。相談を受けるなかで繰り返し見てきたものを4つ挙げます。

1. URLが変わって検索流入が落ちる。 既存URLをそのまま引き継げば防げますが、画面の切り方を変えると1対1で対応しなくなります。移行前にURLの対応表を作り、変わるものには301リダイレクトを設定してください。これを設計に含めていない見積もりは要注意です。

2. 更新運用が難しくなる。 これまでCMSの管理画面から編集できていた箇所が、SPA化によって「開発者が直す箇所」に変わることがあります。誰がどこを更新するのかを、画面単位で先に決めてください。

3. 計測が合わなくなる。 ページが切り替わらないため、アクセス解析の標準設定ではページビューが記録されません。画面遷移のたびに計測用のイベントを送る実装が別途必要です。MDNもSPAの欠点として、意味のある性能計測が難しくなる点を挙げています。

4. 全面刷新にしてしまう。 全画面を一度に置き換えると、期間も費用も膨らみ、切り戻しもできません。効果の大きい画面(遷移の多い業務画面)から段階的に置き換えるほうが、投資の判断を途中で見直せます。

開発費用が変わる5つの要因

SPAにすると費用がどう変わるかは、次の5つで決まります。

一般論として、同じ機能をMPAで作るより、SPAのほうが初期費用は上がります。土台づくり(ルーティング、状態管理、認証、ビルド設定)が先に必要になるためです。一方で運用段階では、画面の追加が部品の組み合わせで済むようになり、1画面あたりの追加コストは下がる傾向があります。初期と運用を分けて比べてください。費用の考え方そのものは「アプリ開発・システム開発の費用相場」の記事で、人月×単価×期間の形に分解しています。ビルドと本番反映の流れは「デプロイとは」の記事で扱っています。

SPAを外部チームで作るときの体制——当社の場合

SPAは画面側とサーバー側が分離するため、職種を分けてアサインできる作りです。当社は2,000名以上のIT人財データベース(日本語N1〜N2相当を含む)から直接アサインしており、協力会社を経由しないため仲介マージンが乗りません。公開している単価は実務3年目安で1,500USD(約22.5万円、1USD=150円換算目安)、5年で2,000USD、10年・ブリッジSEで3,000USD。当社調べで市場相場の約1/2にあたります。最小構成は日本人PMがフロントに立ち、2〜3人月で月額約80万円からです。

体制は2パターンあります。パターンAは日本人PMまたはブリッジSEにエンジニアを組み合わせる形で、SPAのように設計判断が多い案件ではこちらを推奨しています。パターンBはエンジニアのみの構成です。1名から開始でき、最短2週間で稼働、増員は約1週間、縮小・交代は1か月単位で調整します。

品質は3点で担保しています。日本人PMによる設計レビュー、Gitのプルリクエストによるコードレビューの標準化、リリース前のダブルチェックです。SPAの場合、前述した4つの設計(URL・履歴・状態管理・認証)が設計レビューの主な確認対象になります。実行環境はAWS認定11冠のメンバーが対応し、AI活用開発体制で進めます。日本との時差は2時間、契約と支払いは日本国内法人・日本法準拠で、海外送金は不要です。

実績としては、React・Vue.js・Next.jsでの開発に加え、LLMを組み込んだAIチャットボット(24時間対応)、求人プラットフォーム(ATS)、ヘッドレスCMSを使ったWebサイト構築などを手がけています。CareViewerのお客様からは「想像以上にエンジニアのレベルが高い」という評価をいただきました。

ただし、繰り返しになりますが、メディアサイトや数ページのコーポレートサイトをSPA化する案件には、当社はお勧めしないとお伝えします。合わない案件を受けても、費用に見合う結果が出ないためです。

【FAQ】SPA開発に関するよくある質問

最後に、実際のご相談でよくいただく質問を5つ挙げます。いずれも提案書を比較する場面で出てくるもので、回答には公式ドキュメントの記述か、当社が公開している事実のみを使っています。判断の材料としてお使いください。

Q1. SPAとSSRは対立する概念ですか。

いいえ、対立しません。SPAは「1枚のHTMLを読み込んで中身を書き換える作り方」、SSRは「HTMLをサーバー側で作って返す方式」で、別の軸の話です。実際、Nuxtの公式ドキュメントは経路ごとに描画方式を切り替えるハイブリッドレンダリングを標準機能として説明しており、Angularもサーバー・クライアント・事前レンダリングの3モードを用意しています。最初のHTMLはサーバーが作って返し、そのあとの遷移はSPAとして画面側で処理する——これが現在の一般的な構成です。

Q2. 既存のWordPressサイトをSPAにできますか。

技術的には可能です。WordPressを記事の保管と編集にだけ使い、表示側を別に作る構成(ヘッドレス化)を取ります。当社もヘッドレスCMSを使ったWebサイト構築の実績があります。ただし記事を読んで離脱する使われ方のサイトでは、費用に見合いません。既存URLの維持、プラグインで実現していた機能の作り直し、更新運用の変更が発生します。表示速度が目的なら、SPA化ではなく静的サイト生成(SSG)やキャッシュの見直しを先に検討してください。

Q3. SPAにするとサーバー費用は下がりますか。

構成によります。ブラウザ側で描画する構成(CSR)だけなら、サーバーはデータを返すだけになり、画面はCDNや静的ホスティングから配信できるため、サーバーの負荷と費用は下がる傾向があります。Nuxtの公式ドキュメントも、クライアントサイドレンダリングの利点として静的サーバーで配信でき、サーバー側にJavaScriptの実行環境が不要になる点を挙げています。一方でSSRを入れると、リクエストのたびに描画するサーバーが常時必要になり、その分の実行環境と監視の費用が増えます。下がるか上がるかは、どの画面にSSRを使うかで決まります。

Q4. 社内にフロントエンド経験者がいなくても保守できますか。

保守そのものは外部に委託できます。ただし、発注する側に「どの画面がどのURLに対応し、どの情報をどこで持っているか」を把握している人が1人は必要です。ここが空白だと、開発会社を変えるときに引き継ぎができません。当社では日本人PMがフロントに立ち、設計レビューとGitのプルリクエストによるコードレビューを標準化して、判断の記録が残る形で進めています。将来的に社内へ引き取る予定があるなら、その前提を最初に共有してください。技術の選び方が変わります。

Q5. SPAで作ったあと、あとからSSRを足せますか。

足せますが、費用は「最初から設計に入れておく場合」より確実に高くつきます。SSRでは同じコードがサーバーとブラウザの両方で動くため、ブラウザ固有の機能に依存した書き方をしていると、その箇所をすべて洗い出して直す必要があるからです。Nuxtの公式ドキュメントも、サーバーとブラウザの環境の違いに注意が要ることを、ユニバーサルレンダリングの短所として挙げています。現実的な対処は、公開する必要がある画面を最初に洗い出し、その画面だけSSRかSSGで作っておくこと。検索流入を取る計画が少しでもあるなら、初期の設計で決めておくべき項目。

まとめ: SPAは「速くする技術」ではなく、どこに時間を使うかを選ぶ技術

SPA(シングルページアプリケーション)は、1枚のHTMLを読み込んだあと、画面の中身だけを書き換えていくWebアプリの作り方です。2回目以降の遷移が速くなる代わりに、最初の1回が重くなります。つまり速さは差し引きであり、1回の訪問で何画面を行き来するかで損得が決まります。操作が続く管理画面や業務システムには向き、記事を読んで離脱するメディアサイトや数ページのコーポレートサイトには向きません。

「SPAはSEOに弱い」という通説は、2026年9月16日時点のGoogle検索セントラルの記述とは食い違っています。Googleはクロール・レンダリング・インデックス登録の3段階で最新版のChromiumを使いJavaScriptを実行すると明記し、かつて対策とされた動的レンダリングについては「回避策であり、長期的な解決策ではない」と書いています。正しくは「公開ページをSPAで作るなら、実URLを持たせ、SSRかSSGを併用する設計が要る」です。設計する対象が増えるという意味であって、できないという意味ではありません。

発注する側が決めるのは技術の名前ではなく、URL・履歴、状態管理、認証、そして初回表示の目標という4点です。この4点が提案書に書かれているかどうかが、SPAの実装経験を測るいちばん確実な物差しになります。画面側とサーバー側の分担そのものはフロントエンドとバックエンドの違いで、費用の分解の仕方はアプリ開発の費用相場で整理しています。

現在の体制と要件をお聞かせいただければ、SPAで作るべきかどうかも含めて概算見積もりでお答えします。合わない案件にはその旨も率直にお伝えします。