カスタムECサイトの実像：React SPAの隠れたリスクとアーキテクチャ刷新のポイント

はじめに：あるカスタムECサイトの実像

「Reactで作ったSPA（シングルページアプリケーション）＋独自のREST API。これこそモダンなECサイトだ。」

そう思っている開発者やプロダクトオーナーは少なくないでしょう。しかし、実際に動いているサイトを徹底的に解析すると、その「モダンさ」の裏に、SEO、データモデル、運用面で無視できない課題が潜んでいることがわかります。

本記事では、実際に稼働するあるECサイト（フロントエンド：React/Vite、バックエンド：独自REST API、CDN：Cloudflare）のアーキテクチャを、観測可能な事実と技術的な推論に基づいて深掘りします。そして、WooCommerceなどの既存プラットフォームと比較しながら、今後のリライト（書き換え）における最適な戦略を考察します。

※この分析は、特定の企業のコードや内部情報を不正に取得したものではありません。公開されているURL、APIレスポンス、HTML構造から読み取れる事実に基づいています。

第1章：観測されたアーキテクチャの全体像

1.1 三層構造の実態

サイトは以下の三層で構成されていました。

1. Cloudflare (CDN/リバースプロキシ): 全てのリクエストを受け付け、静的アセットを高速配信。動的リクエストはオリジンサーバーへ転送。
2. React SPA (Viteビルド): ブラウザ上で動作するUIの全てを担当。ルーティングや状態管理もクライアントサイドで行う。
3. 独自REST APIバックエンド: カタログ、CMS、ストア設定、クーポン、PayPal決済、お問い合わせ、ニュースレター、レビュー、トラッキングなど、全てのビジネスロジックを提供。

1.2 なぜWooCommerceやShopifyではないと断定できるのか

仮に「ヘッドレスWooCommerce」を利用していれば、WooCommerceのREST APIに特有のエンドポイント構造（/wp-json/wc/v3/productsなど）や、商品データのスキーマ（meta_dataフィールドなど）が現れます。

しかし、観測されたAPIは以下のような、完全に独自設計のものでした。

• 商品一覧:

  GET /api/products?limit=500&active=1

• 商品詳細:

  GET /api/products/<slug>

• ホームページ構成:

  GET /api/homepage

• レイアウト:

  GET /api/layout

• ストア設定:

  GET /api/public/settings

• クーポン:

  POST /api/coupons/validate

• 決済:

  POST /api/paypal/create-order

  ,

  POST /api/paypal/capture

これらのエンドポイント名、JSONレスポンスのフィールド名（section_order, variants, standard_handling_minなど）、そしてバックエンドのルーティング構造は、既存のECプラットフォームのそれとは全く異なります。これは、フロントエンドだけでなく、バックエンドも含めて完全にスクラッチで構築された「カスタムEC」であることを強く示唆しています。

1.3 コア技術スタックの推定（と限界）

• フロントエンド: React + Vite。これは

  <script type="module" src="/assets/index-<hash>.js">

  のような、Vite特有のアセット読み込みパターンからほぼ確定です。
• バックエンド: 現時点では不明。Node.js、PHP (Laravelなど)、Python (FastAPIなど)のいずれの可能性もあり、URLの命名規則やJSONのスネークケースだけでは判断できません。決定的な情報を得るには、レスポンスヘッダー、Cookieのプレフィックス、エラーレスポンスの形式、あるいはデプロイ構成ファイルなどの追加情報が必要です。

ポイント: 技術スタックの推測は、確固たる証拠に基づいて行うべきです。「ReactだからバックエンドはNode.jsに違いない」というような、生態系の類似性だけで結論を急ぐのは危険です。

1.4 初期ロードとデータフロー：見かけ上のスピードの罠

最初のページロード

1. ブラウザがサーバーにアクセスすると、中身が空の

   <div id="root"></div>

   と、JSファイルへのリンクだけが書かれた、ほぼ空っぽのHTMLが返ってくる。
2. ブラウザがJSファイルをダウンロードし、パースし、実行するまで、画面には何も表示されない。
3. Reactが起動し、ルーターが現在のURLを確認して、表示すべきページコンポーネントを決定する。
4. ページコンポーネントが必要なデータを、REST APIを呼び出して非同期で取得する。
5. データが取得できて初めて、DOMが構築され、ユーザーにコンテンツが表示される。

ページ内遷移

• 一度Reactが起動してしまえば、ページ遷移は高速です。ブラウザ全体をリロードすることなく、JavaScriptでDOMの一部だけを書き換えるからです。

重大な問題点：SEOへの悪影響

この仕組みは、検索エンジンにとって大きな問題を引き起こします。

• コンテンツの不存在: Googleのクローラーがアクセスした時、最初に受け取るHTMLには商品名も価格も説明もありません。「JavaScriptを実行しないとコンテンツがわからない」状態です。
• 「ソフト404」のリスク: すべてのURLが同じ空のHTMLを返すため、存在しない商品ページ（/product/存在しないスラッグ）にアクセスしても、HTTPステータスコード200が返ってきます。Googleはこれを「ソフト404」と見なし、インデックス品質を低下させる可能性があります。
• メタデータの問題: タイトルタグやメタディスクリプションもJavaScriptで動的に書き換えられるため、クローラーが正しく認識できない恐れがあります。これにより、検索結果に適切なタイトルが表示されないなどの問題が発生します。

Googleの公式見解: Googleは動的レンダリング（クローラーにだけプリレンダリングHTMLを返す手法）を「あくまで一時的な回避策」と位置づけ、長期的な解決策として**サーバーサイドレンダリング（SSR）や静的サイト生成（SSG）**を推奨しています。

第2章：データモデルの深層と潜在的な脆弱性

観測されたAPIレスポンスやHTMLに埋め込まれたデータ (window.__INITIAL_DATA__ など) を解析すると、データモデルに複数の問題点が見えてきました。

2.1「Product Centric」から「Variant Centric」への転換が必要

現在のデータ構造は、「商品（Product）中心」 であり、「バリエーション（Variant）中心」 ではありません。

• 問題点（例）： stock（在庫数）がバリエーションレベルではなく、商品レベルで管理されている。sizes（サイズ）、colors（色）も商品のプロパティとして配列で保持。
• なぜ問題か？ 実際の在庫は「黒のMサイズ」、「白のLサイズ」といったバリエーションの組み合わせごとに存在します。商品レベルで在庫を管理してしまうと、
  • 「黒のMサイズ」だけ在庫切れという状況に対応できない。
  • 異なるバリエーションが同じSKU（在庫管理単位）を共有できず、正確な在庫管理が不可能。
  • 将来的にSKU数が増えた時、データ構造の拡張が困難になる。

2.2 データの不整合と非正規化

• サイズ表記の揺れ: XXL と 2XL が混在。
• 色名の揺れ:

  ink navy

  と

  Ink Navy

  など、大文字小文字が統一されていない。
• 役割が不明瞭なフィールド: type や isbn といった、一般的なECサイトでは使われないフィールドが存在。これは別のドメインから流用した名残の可能性が高い。

これらの不整合は、フィルタリング機能のバグ、在庫管理システムとの連携エラー、そしてアナリティクスの精度低下を引き起こします。

2.3 ホームページビルダーの柔軟性と課題

ホームページは、API (/api/homepage) から取得した section_order という配列に従って、ブロック（ヒーロー画像、プロモ、商品グリッドなど）を動的に並べ替えられる仕組みになっていました。これは、マーケティング担当者がフロントエンドのコードを変更せずにレイアウトを変更できる、非常に柔軟な設計です。

しかし、その裏で以下のような問題も見られました。

• スキーマのレガシー: ann（announcementの略？）と announcement という、明らかに重複・旧称と思われるキーが混在。
• 状態の不整合リスク: section_order、表示ON/OFFのフラグ、各ブロックのペイロード（画像URL、テキストなど）が別々のオブジェクトで管理されているため、データ不整合が発生しやすい構造でした（例：section_order にはあるブロックが指定されているが、ペイロードが存在しない、など）。

2.4 チェックアウトとペイメント：信頼の要

PayPal決済は、一般的なcreate-order → capture のフローを採用しており、大枠は正しい設計です。

しかし、本番運用で致命的なバグを生まないためには、以下のような高度な考慮が不可欠です。

• 冪等性（Idempotency）: ユーザーが二重クリックした場合や、ネットワークエラーでリトライが発生した場合に、同じ注文が二重に作成されたり、二重に課金されたりしないようにする仕組み。
• 金額のサーバーサイド検証: ブラウザから送られてきた金額を鵜呑みにしてはいけません。サーバー側で必ず、データベースに登録された正しい商品価格とクーポン割引を使って再計算する必要があります。
• 在庫のアトミックな予約: 複数のユーザーが同時に同じ商品を購入しようとした場合、在庫数を超えて販売してしまわないよう、データベーストランザクションやロック機構を用いて、在庫を安全に減少させる必要があります。

第3章：なぜWooCommerceにしなかったのか？比較と考察

3.1 カスタムECの「強み」

• 圧倒的なUIの自由度: Reactのコンポーネントでアニメーションやインタラクションを自由に実装できる。ブランドイメージを完全に制御できる。
• 軽量でピュアなコードベース: WooCommerceのように、使わないプラグインのコードや互換性維持のための複雑なフック（hook）に悩まされることがない。
• マルチチャネル対応が容易: 同じビジネスロジック（カタログ、カート、ユーザー）をREST APIとして提供することで、Webサイトだけでなく、モバイルアプリや実店舗のPOSシステムとも簡単に連携できる。

3.2 カスタムECの「弱み」

• SEOの不利: 前述の通り、初期表示の遅延やソフト404の問題を抱えている。GoogleのクローラーはJavaScriptを実行できるとはいえ、それが保証されているわけではない。
• 高い開発・保守コスト: 商品管理画面、注文管理、クーポン、配送設定、税金計算、そしてセキュリティ対策……これら全てを自前で実装し、テストし、維持する必要がある。
• 属人化リスク: 全てを理解しているのはたった一人の開発者、という「バスファクター（その人がいなくなったらプロジェクトが停止するリスク）」が非常に高い。
• 機能の不足: カスタムECにはWooCommerceのようなサードパーティ製プラグインのエコシステムが存在しない。必要な機能（例えば、高度な在庫管理やマーケティングオートメーション）は全て自分で作るか、開発者を探す必要がある。

3.3 カスタムEC vs. WooCommerce：決断のための10項目比較表

比較項目	カスタムReact SPA	従来のWooCommerce	推奨するNext.js型ハイブリッド
UIの自由度	非常に高い	テーマ/ビルダーに依存	非常に高い
デフォルトのSEO	リスク大（特にCSR）	良好（HTMLがサーバーサイド）	良好（適切に設定すれば）
ページ内遷移の速度	高速	画面全体をリロード	高速（プログレッシブエンハンスメントあり）
ファーストビュー	JS/API待ちで遅延する可能性	HTMLが即座に表示される	HTMLが即座に表示される
管理画面（バックオフィス）	自作が必要	成熟しており充実	自作 or Commerce Engine利用
開発・保守コスト	エンジニアリングコストが高い	プラグイン/アップデート管理コスト	エンジニアリングコストは高いが、アーキテクチャはより堅牢
マルチチャネル展開	容易	REST/Headlessレイヤーが必要	容易
商品数16の小規模サイトへの適合性	オーバーエンジニアリングの可能性	非常にフィット	ブランド戦略次第でフィット
導入スピード	遅い（スクラッチ開発のため）	速い	やや速い（フレームワーク利用）
セキュリティ	自己責任で高められるが、穴を作りやすい	プラグインの脆弱性に注意が必要	フレームワークに準拠するが、実装次第

第4章：最適解を求めて：次世代アーキテクチャへの刷新

今のカスタムECは、「カスタムであること」自体が悪いわけではありません。問題は、その実装方法（Pure CSR SPA） と、将来を見据えたデータモデルにあります。

4.1 推奨するアーキテクチャ：ハイブリッドレンダリング

フロントエンドとしてNext.js（App Router） を採用することを強く推奨します。Next.jsは、以下の3つのレンダリング手法を柔軟に組み合わせられます。

1. SSR（サーバーサイドレンダリング）: リクエストごとにサーバーでHTMLを生成。SEOが重要な商品詳細ページなどに最適。
2. SSG（静的サイト生成）: ビルド時にHTMLを生成。ブログやキャンペーンページなど、更新頻度の低いページに最適。
3. ISR（インクリメンタル静的再生成）: SSGの応用。一定時間ごとにページを再生成し、新しいコンテンツに更新できる。

これにより、「初回表示は高速でSEOに強い」「2回目以降のページ遷移はSPAのようにスムーズ」 という、理想的なユーザー体験と検索エンジン対策を両立できます。

4.2 バックエンドのリファクタリング

• 型安全なAPI: フロントエンドとバックエンドで型定義を共有するか、OpenAPI（Swagger）などの仕様書をベースに、型の不一致によるバグを防ぐ。
• 在庫・バリエーションモデルの再設計: 「バリエーション中心」のデータモデルに変更。Product、Variant（SKU、在庫数、価格、オプション値）、Option（サイズ、色など）という明確な関係性で設計する。
• 決済フローの堅牢化: 冪等性キーの導入、サーバーサイドでの金額再計算、データベーストランザクションの活用、Webhook署名の検証 (PayPal) などを徹底。
• セキュリティの向上:

  GET /api/public/settings

  のように、公開すべきでない情報（例：tax_id）が漏れていないか確認する。お問い合わせやニュースレターのAPIには、適切なレート制限とバリデーションを実装する。
• キューイングシステム: メール送信、Webhookの再試行、アナリティクスデータの集計など、時間がかかる処理や外部API呼び出しは非同期キュー（例：BullMQ）を使って処理し、APIの応答速度を安定させる。

4.3 そして選択へ

• 素早く立ち上げたい、チームが小さい、標準的なEC機能で十分。 → WooCommerce を選ぶべきです。
• ブランド体験を完全にコントロールしたい、マルチチャネル展開が必須、強力な開発チームがいる。 → カスタム開発の道を進むべきです。ただし、現行のPure SPAのままではいけません。 本記事で提案したNext.jsによるハイブリッドレンダリングを軸とした再構築が不可欠です。

「モダンだから」「かっこいいから」という理由で、技術の本質を見誤ってはいけません。 あなたのビジネスにとって、本当に「最適な」選択は何か。本記事がその判断の一助となれば幸いです。

---

参考文献:
Google Developers. “Dynamic Rendering as a workaround.”
Google Search Central. “Understand JavaScript SEO Basics.”
Digital Codex. “JavaScript SEO: How Google Crawls and Indexes JS.”
Fuel Online. “JavaScript SEO 2026: How To Make SPAs & Dynamic Sites Crawlable.”
Incremys. “JavaScript SEO 2026: Rendering, SSR and Pre-Rendering.”
The Growth Terminal. “JavaScript Rendering SEO in 2026: The Framework That Kills Rankings.”
Google Search Central Forum.
Search Engine Land. “Google no longer recommends using dynamic rendering for Google Search.”