📝
【失敗談】コーポレートサイトをSPAで作ったら更新即反映もコストも破綻した話
コーポレートサイトをSPAで作った失敗とキャッシュから学んだNext.js設計戦略
はじめに
ある案件でコーポレートサイト／ブランドサイトをSPA（Single Page Application）で構築したときの失敗と、そこから得た学びをまとめます。
最近はJamstackやHeadless CMS（Kurocoなど）とNext.js／Nuxtを組み合わせた構成が一般的ですが、SPAを選択したことで起きた問題と解決策をキャッシュ戦略の視点で共有します。
作った構成（ざっくり）
- フロントエンド：Next.js（App Router）ベースSPA
- CMS：ヘッドレスCMS（APIでデータ取得）
- API呼び出し方法：クライアントフェッチ（fetch API）
- キャッシュ戦略：当初はキャッシュなし → 途中からAPIキャッシュ導入
起きた問題
1. 更新した内容が即反映されない
CMS側でコンテンツを更新しても、キャッシュの影響で反映に時間がかかる。
no-cacheやno-storeを使っても、他のキャッシュの影響を完全に排除できなかった。
2. API従量課金コストが爆増
SPAのためページ遷移やリロードのたびにAPIリクエストが発生。
結果、月間APIコストが爆発的に膨らんだ。
3. キャッシュ制御が破綻
- キャッシュを効かせると更新が反映されない。
- キャッシュを切るとAPIコストが増大する。
- キャッシュ・更新即反映・コストの三すくみ状態に陥った。
キャッシュ戦略の限界とSPAの宿命的欠点
SPAでは「更新即反映」と「APIコスト削減」を同時に実現するのが極めて難しい。
- クライアント側のキャッシュ → ユーザー体験には効果的だが、APIコスト削減には直結しない。
- API側のキャッシュ → コスト削減に効果的だが、更新即反映を阻害する。
SPAを選んだ時点で、このトレードオフは避けられなかった。
どう改善したか
方針転換
- API呼び出しをクライアントフェッチからSSR／ISRに移行。
- ISRのrevalidate制御とon-demand revalidationを採用。
- クライアント全面CSRをやめ、ハイブリッド構成へ。
この失敗から学んだ：Next.js構成パターン早見表（キャッシュ戦略視点）
| 構成 | 初回表示速度 | SEO | 更新反映速度 | APIコスト | キャッシュ制御の柔軟性 | 適した用途 |
|---|---|---|---|---|---|---|
| SSG | ◎（最速） | ◎ | ×（ビルド必要） | ◎（APIコール不要） | ×（更新時に全再ビルド） | 更新頻度が低い固定ページ |
| ISR | ◎ | ◎ | ○（revalidateまたはon-demand） | ◎（更新時のみAPI使用） | ◎（柔軟な再生成制御） | 更新頻度が中程度の一覧・詳細ページ |
| SSR | ○ | ◎ | ◎（即反映） | △（毎回API呼び出し） | ○（サーバーキャッシュ可能） | 高頻度更新ページ・ログインユーザー向け |
| CSR（SPA的） | △（初回遅い） | △（SEO弱い） | ◎ | ×（毎回API呼び出し） | ◎（クライアント側で制御） | アプリ・ダッシュボード |
SPA構成とISR構成のキャッシュフロー比較
なぜSPAではキャッシュ制御が破綻し、ISRでは解決できたのか？
読者にその構造的な違いを視覚的に理解してもらうため、キャッシュ戦略に基づいたフロー図を作成しました。
SPA構成
ユーザーのブラウザ
↓（ページ読み込み／遷移のたび）
クライアントフェッチ（fetch）
↓（キャッシュ無し or クライアントキャッシュ）
APIリクエスト（CMS）
↓（CMS内APIキャッシュ：ヒットすればDBアクセスなし）
データベース
特徴：
- 毎回APIリクエスト発生 → APIコストが増大
- キャッシュを切れば更新即反映 → コスト高騰
- キャッシュを効かせると更新遅延 → UX悪化
- SEO対策が難しい（初回JSロード時間の影響）
ISR構成
ユーザーのブラウザ
↓（初回アクセス）
Next.jsがプリレンダリングしたHTMLを返す（ISRキャッシュ）
↓（revalidate期間内なら同じHTMLを返却）
（revalidate期間終了 or on-demand ISR発火時）
↓
APIリクエスト（CMS）
↓（CMS内APIキャッシュ：ヒットすればDBアクセスなし）
データベース
特徴：
- 初回表示は超高速（CDN＋HTMLキャッシュ）
- APIリクエストは更新タイミングのみ発生 → APIコストを最小化
- 更新反映も制御可能（revalidate秒数／on-demand再生成）
- SEOに強く、コスト効率も良好
今後の推奨構成（キャッシュ戦略付き）
| ページ | 構成 | キャッシュ戦略 |
|---|---|---|
| トップページ | ISR | revalidate: 1時間〜on-demand |
| サービス紹介 | ISRまたはSSG | 月1回程度の更新ならSSG、それ以上ならISR |
| ニュース一覧・詳細 | ISR | revalidate: 10分〜1時間 |
| 店舗情報 | ISR | revalidate: 1時間〜 |
| 問い合わせフォーム・ログイン機能 | CSRまたはSSR | キャッシュせず毎回最新情報 |
最終的な学び
- SPA（全面CSR）はインタラクティブなアプリケーション専用。
- コーポレート／ブランドサイトは基本SSG／ISR＋必要な部分のみCSR。
- APIキャッシュ・ISR・CDNキャッシュを柔軟に組み合わせて「速度・コスト・更新反映」を両立する。
おわりに
当初、SPAを選択したのは「将来の機能拡張やリッチUI対応のため」でしたが、コーポレートサイトにその柔軟性は過剰でした。
今回の失敗を通じて、更新即反映とAPIコスト削減のバランスを取るキャッシュ戦略こそ最重要だと痛感してもらえるかと思います。
ちゃんと記しました。
犠牲者が出ないことを祈ります。
Discussion