EC-CUBEのモダンカスタマイズ：UIとロジックを分離する「ハイブリッド・ヘッドレス化」の設計手法
EC-CUBEカスタマイズの選択肢。フロントエンドエンジニアの開発体験を向上させ、保守性と拡張性を両立するアーキテクチャ設計。
この記事の対象者
SaaS型（Shopify等）のカスタマイズ制約に課題を感じている事業者、およびEC-CUBEでモダンなUIを構築したいフロントエンドエンジニア
SaaSのカスタマイズ制約にお悩みの方はこちら（活用シーンへジャンプ）
※本記事はEC-CUBEインテグレートパートナーであるタイガーテックが、実際のシステム構築現場における知見をもとに解説しています。
本記事の結論（サマリー）
- 背景・提案: 「画面遷移時のリロードを無くしたい（ゼロロード）」「アプリのようなリッチなUIにしたい」といった要件を望まれることがあります。それらを実現する選択肢として、タイガーテックでは「ハイブリッド・ヘッドレス構成」カスタマイズをご提案しています。
- アーキテクチャ: Astro等のBFF（Backend For Frontend：フロントエンド専用の中継サーバー）を挟むことで、公式のセキュアなAPI仕様を守りつつヘッドレス構成を実現します。
- 留意点: 「ハイブリッド・ヘッドレス構成」カスタマイズを行う場合、BFF層の設計難易度や、要求される技術スタック（スタッフコスト）が高くなるというトレードオフが存在します。
アーキテクチャの特性と、ヘッドレス化というアプローチ
EC-CUBEのテンプレート（Twig）は、フロントエンド（画面表示）とバックエンド（サーバー処理）が一体化したアーキテクチャです。
「画面遷移時にページが白くならない（ゼロロード）体験を作りたい」「スマホアプリのようなリッチでインタラクティブなUIにしたい」といった要件を実現する場合、以下の特性を考慮する必要があります。
一体型のアーキテクチャは、リンク遷移やデータ更新のたびにサーバーへリクエストを送り、HTML全体を再描画（フルページリロード）する仕組みであるため、ページ遷移時の「画面のちらつき（フリッカー）」や「画面が白くなる待機時間」をゼロにすることは難しいと考えます。
これらの要件に応えるための手法として、「ヘッドレス化（フロントエンドとバックエンドの分離）」をご提案しています。
フロントエンド側で画面の描画（レンダリング）を行い、裏側の通信（API）で必要なデータのみをやり取りすることで、リロードを伴わないシームレスなアプリ的体験を実現します。
フルヘッドレス化のハードルと、ハイブリッド構成のメリット
すべての画面をヘッドレス化（フルヘッドレス）しようとした場合、ログインやカート以降の領域において、以下のようなバックエンドやフロントエンド、および開発体制のハードルが生じます。
フルヘッドレス化でコストとリスクが跳ね上がる要因
- EC-CUBE側へのAPI開発（バックエンド）： 公式のWeb APIプラグインは標準でチェックアウト（購入完了）までの全フローを網羅していません。そのため、商品一覧とは異なり、チェックアウトフロー（ポイント利用、複数配送先の指定、決済処理など）をすべて外部から安全に操作・検証するための専用APIを、EC-CUBE側に独自開発する必要があります。
- 複雑な状態管理とUI構築（フロントエンド）： 独自のAPIと連携し、セキュアなトークン管理や、決済エラー・在庫不足時のハンドリングなど、フロント側でも高度な実装が要求されます。
- 高度な技術スタックとセキュリティ担保（開発体制）： 分離されたフロントとバックを不整合なく同期させ、既存のEC-CUBEと同レベルの堅牢なセキュリティを担保するには、極めて難易度の高い設計力（人間側のコスト）が必要となります。
このように、標準で備わっているセキュアな機能を破棄し、「API開発」「状態管理」「高度な開発体制」のすべてをゼロベースで用意することは、開発コストの肥大化と失敗リスクを招くと考えています。
💡 現実解としての「ハイブリッド・ヘッドレス構成」
トップページや商品一覧といった「UIの柔軟性と表示速度が重視される領域」のみをヘッドレス化し、ログイン・マイページ・カート・購入フローなどの「セキュアな領域」はEC-CUBEのテンプレート（Twig）をそのまま利用します。
既存機能の作り直しを避け、EC-CUBEの堅牢性とヘッドレスの恩恵を両立させるアプローチです。
セキュアなAPI通信を実現する「BFF (Backend For Frontend)」
EC-CUBEのWeb APIは「OAuth2」という認証方式を採用しています。そのため、フロントエンド（ブラウザ）から直接APIを呼び出そうとすると、通信のための「秘密の鍵（クライアントシークレット）」をブラウザ上に持たせることになります。
これは例えるなら、「お店の裏口を開けるマスターキーを、来店したお客さん全員に見える場所に置いてしまうようなもの」です。ブラウザのソースコードは誰でも閲覧できるため、悪意のあるユーザーに鍵を盗まれ、不正にデータを操作される重大なセキュリティリスクが生じます。
そこで、ブラウザとEC-CUBEの間に「中継サーバー」を立て、安全なAPI通信を担保するアプローチとして「BFF」アーキテクチャをご提案しています。
ブラウザ
Astro SSR / Node.js
Web API プラグイン
🛡️ BFFの重要な役割（APIゲートウェイ）
- マスターキーの隠蔽： ブラウザから直接EC-CUBEと通信せず、間にBFFを挟むことで「秘密の鍵（クライアントシークレット）」をサーバー側（BFF）の安全な金庫に隠蔽します。フロントエンド（ブラウザ）へは、JavaScriptから読み取れないセキュアなCookie（HttpOnly）として認証セッションを渡します。
- 安全なサーバー間通信： BFFからEC-CUBEへのAPI呼び出しは、ユーザーの目に触れない安全な「サーバー間通信」として実行されます。
- データ整形（アグリゲーション）： BFFが複雑なAPI処理を肩代わりし、ブラウザには「画面描画に必要な最低限のデータ」のみを渡すことで、過剰なデータ取得による情報漏洩を防ぎます。
- 不正リクエストのフィルタリング： アクセス頻度の制限（レートリミット）や不正なパラメーターのブロックなど、EC-CUBE本体に攻撃が届く前にBFFが関所として弾きます。
- CSRF・Bot攻撃対策： BFF側で独自のトークン検証（CSRF対策）やreCAPTCHA等のBot判定処理を行い、機械的な不正ログインやスパムを遮断します。
【実証デモ】Astro × EC-CUBE API の「ゼロロード遷移」
「EC-CUBE 4.3」と「Astro」を連携させたデモUIをご用意しました。
以下のボタンからデモを起動し、スマホ画面を操作してみてください。商品一覧から詳細へ、画面のちらつき（ページリロード）が一切発生しないシームレスな遷移が体験できます。同時に、裏側でEC-CUBEと行われているAPI通信（JSON）のログがリアルタイムに表示されます。
✅ ご確認いただける挙動
- View Transitions API を用いたMPA（Astro）のシームレスな遷移（商品一覧画面⇔詳細画面間の操作）
- 右側ターミナルでのBFF API通信ログのリアルタイム同期
ヘッドレス化のデメリット
ヘッドレス化には明確なデメリット（課題）も存在します。導入を検討する際は、以下の3点に注意する必要があります。
1. インフラ構成の複雑化
中継サーバー（BFF）とアプリケーションサーバー（EC-CUBE）を用意するため、サーバーの管理コストやデプロイフローが複雑になります。障害時の原因切り分け（どちらのサーバーでエラーが起きているか）も難しくなります。
2. 設計の難易度上昇（ロジックの配置）
ビジネスロジックを、フロントエンド・BFF・バックエンドのどの層に配置すべきか、全体像を見据えたアーキテクチャ設計が求められます。
3. 開発体制（要求スキル）のハードル上昇
ヘッドレス化を行う場合、従来の「PHP（Symfony）とTwigが書ける」スキル要件では開発が完結しません。新たにヘッドレス開発に長けたフロントエンドエンジニアと、API連携を設計できるミドルウェア層（BFF）の人材確保が必要となり、チームに求められるスキル要件が多くなります。
EC-CUBEのハイブリッド構成が活用できるシーン
例えば、ShopifyなどのSaaS型プラットフォームを利用してヘッドレスECをスタートし、順調に売上が拡大したとします。
事業が成長するにつれて、「基幹システムと独自の連携をさせたい」「特殊なBtoBの商習慣（掛け払いや価格計算）に対応したい」「管理画面（バックオフィス）の業務フローを自社に合わせてカスタマイズしたい」といった独自要件が生まれることがあります。
しかし、SaaS型のプラットフォームは裏側のシステム（バックオフィスや決済画面）のカスタマイズに制限があるため、こういった要件が壁にぶつかるケースが少なくありません。
そのような「事業成長に伴うシステムの限界」を迎えたとき、または最初から自社独自の業務要件が想定されているときに、選択肢となるのが「EC-CUBEのハイブリッド構成」です。
SaaS型（Shopify等）とパッケージ型（EC-CUBE）のアーキテクチャ比較
SaaS型は「用意されたシステムに自社の業務を合わせる」というスタートアップ期には適していますが、パッケージ型であるEC-CUBEは、「自社の独自の業務要件に合わせて、バックオフィスから購入画面まで作り込める」というカスタマイズ性が特徴です。
事業フェーズを見据えたシステムの選択
「最新のフロントエンド（UI/UX）」と「裏側のカスタマイズ性（バックオフィス）」の両方が必要になったとき、EC-CUBEを用いた構成は、ビジネスの成長を支える土台として機能します。
おわりに：目的と体制に合った手法の選択を
ヘッドレス化はそれ自体が目的ではなく、「フロントエンドのUI/UXの向上」と「バックエンドの柔軟な拡張」を両立するための一つの手段です。
自社のビジネス要件や、社内チームの技術スタック（フロント/バックエンドの得意領域）と照らし合わせ、SaaSの利用やフルスクラッチ、あるいは本記事で紹介した「EC-CUBEのハイブリッド・ヘッドレス化」といった選択肢の中から、最適な手法をご検討ください。
タイガーテックのEC-CUBE支援と目安金額
タイガーテックでは、EC-CUBE公式パートナーとしての知見を活かし、ヘッドレスアーキテクチャの導入に向けた以下のようなご支援を提供しています。
- まずはお気軽にご相談から： 既存システムのヘッドレス化の是非や、BFF層のアーキテクチャ設計など、現在のシステム課題やビジネス要件のヒアリングから承っております。
- 開発・システム構築： ヘッドレス化に必要なフロントエンド・BFF・APIの開発。要件の規模や複雑さに応じて、数百万〜1千万円以上の費用目安となります。