「ヘッドレスコマース」がEC業界の最注目ワードの一つに
最近話題になることが多い「ヘッドレスコマース」とは何でしょうか？
ヘッドレスコマースは、元々Amazonが採用していたと言われるシステムアーキテクチャでECフロントとAPIを分割して構築します。(図参照)このためECフロントと機能群であるAPIを分割して開発できる、分割に伴い柔軟性が上がったり、顧客体験が向上すると言われています。一方ECのフロント用環境をわざわざ別途契約したり、開発の複雑度が増すなどもあり、このメリット・デメリットについては、おって詳細を紹介します。
このヘッドレスコマースに注目が集まっており、資金調達を行うベンチャーが増えています。ここではStoreFrontとSWELLの二社を紹介します。
Vue StoreFront
Vue StoreFrontはShopifyやMagento、BIGCOMMERCEといった既存ECシステムのAPIと通信してECサイトのフロントを作るvue.jsのフレームワークを提供します。現状オープンソースとして開発されています。既存ECプラットフォーム製品(Shopify Magento BIGCOMMERCE)のAPIと連携して、ECサイトのフロント部分を提供するというのがポイントになります。
※Vue StoreFrontはYコンビネーターの出資を受けています。
参考：話題のヘッドレス通販の触媒を目指すY/Cが支援するVue Storefront
SWELL
SWELLは、柔軟性があるAPI提供をうたっています。機能表ページ下部を見ると、SWELLとShopify Plus、Magento、BIGCOMMERCEとAPI機能や仕様の違いについて触れています。他社製品と連携して柔軟なフロント画面を提供することに注力しているVue StoreFront と違い、APIそのものに注力しているのがわかります。
参考：ヘッドレスコマースのSwellが約3.7億調達、柔軟性に富むバックエンドを目指す
このように同じヘッドレスコマースと呼ばれるセグメントのベンダーでも、フロント部分に注力したり、より高機能なAPI提供を目指したり、得手不得手があることがわかります。
後述しますが、2021年度時点でヘッドレスコマースは、いまだ黎明期であり、各社注力している部分が異なるため、ひとくくりにするには難しいところがあります。安易に製品を選択せず、自らの事業にあった選択が必要です。
今回は、このヘッドレスコマースの2021年時点での最新情報と、どういった点に注意して取り組むべきなのか紹介していきたいと思います。
そもそもヘッドレスコマースとは
ECサイトの構築手法
ヘッドレスコマースとはECサイトを構築する手法で、バックエンドを中心に機能をAPI化し、フロントエンド(HTMLやJSフレームワークを多用)はAPIを呼び出す形で実装する、別々のシステムアーキテクチャとする手法を指します。
フロント(ヘッド)がなく、機能を提供するAPIがあるという(ヘッドレス)が起源となっていますが、ヘッドレスコマースのセグメントに入る製品でもフロント機能とAPI両方を持っているケースが大半です。
最も重要なのはECシステムのAPI化
ヘッドレスコマースの重要かつ必須条件としては、ECシステムのAPI機能提供になります。ECシステムのAPI化はこの数年世界的に注目が集まっている分野であるとともに、ECシステムのフロント画面構築や外部連携をもっと自由にしたいというEC事業側のニーズもあって、ヘッドレスコマースという形で脚光を浴びていることは先述しました。
図にあるように、古いアーキテクチャのECサイト構成はUIと機能ロジックが一体となっていましたが、ヘッドレスコマースではUIと機能ロジックが分離されています。機能はAPIを通して利用することができます。
一般的にどのようなAPIがあるか、何社かのAPIを見ると以下のようなものがあります。
- カート情報(商品、支払い方法、配送先、特典、計算)の取得や設定
- 会員(会員情報、パスワード)の取得や設定
次に一般的に言われているメリット、デメリットや実態について紹介します。
メリット１「様々なフロント形態を共通バックエンドで実現可能」
上記の図のように、スマートフォンサイト、PWA、アプリ、SNS連携といった多様なフロントの共通バックエンドとしてAPIが利用出来るようになります。フロント部分の違いによってロジックを作り直したりする必要はありません。
最も期待される内容としては、今注目が集まっているPWA(プログレッシブ、ウェブ アプリケーション)化が容易になる点です。 今後ECサイトをアプリ化したり、スマートウォッチやその他デバイスの中で起動させたいニーズがより高まってきた場合、PWAの需要が高まることが期待されています。フロントPWAでヘッドレスコマースAPIとの組み合わせは、その際の最適な手段となる可能性が高いです。
ただし2021年4月時点、スマホアプリではWebViewで埋込み型になっているケースが圧倒的に多く、PWAの需要はそこまで高くなっていません。これはアプリ開発が比較的高コストになる事を踏まえて埋め込みという妥協が多かったとも言われており、ヘッドレス化に伴いPWAでアプリを作り直して顧客体験を良くしたいと考えている方も潜在的にいます。
メリット２「フロントエンドとバックエンドを個別に開発できる」
ヘッドレスコマースはAPIとフロントシステムでシステムアーキテクチャが別々になっているので、個別に開発することが可能です。実態はどうなのでしょうか。
●効率は良くも悪くもなる
マイクロサービス的な手法でいうと、それぞれ別々に開発するので開発効率が上がるケースもあります。逆に新しい機能を開発する際にAPI側と画面側の開発がうまく連携できないと開発効率が下がるケースがあります。
また、APIをリリースして、画面側をリリースするなど運用上の制約も出てきますので、制約を前提とした運用ルールの確立も必要です。
●学習コストは高め
フロントエンドの開発手法(JSの開発フレームワークを習得、JSでAPIを呼び出して、画面を自分で実装すること)を学ぶ必要があります。特集ページや商品ページのHTMLをメンテナンスできるレベルより、もう一段レベルの高いちゃんとした開発部隊が必要になります。フロントエンドの開発速度が早くなると言われていますが、APIの使い方に関するノウハウと、フロント実装の専用技術が必要になることは覚えておきましょう。
●問題が起きた際の原因判定が難しくなる場合もある
運用で問題が起きた際の原因判定が、フロント側なのかAPI側なのか複雑になります。カートインがうまく行かないけど、フロント側でJSがエラーとなっているのか、カートのAPIがうまく機能していないのか分からないケースなどが発生し、技術者が判断する必要が出てきます。
●本来は内製したい企業向き
あえて分割して開発するメリットですが、外部のシステム会社に頼むと言うよりは、内製化の範囲をECフロントサイトに限定したいEC事業者に向いているアーキテクチャになります。実際海外で先に話題になっているのも、海外では内製化するほうが主流ということもあります。バックエンドまで含めると内製化範囲は大きいので、フロント画面に限定するのは一つの方針になるでしょう。そしてフロント画面にこだわりが大きかったり、アプリ提供で体験を良くしたい企業の内製化の手段としては非常に有用です。
メリット３「フロントエンドの顧客体験が豊かになる」
顧客体験が豊かになるとメリットを解くヘッドレスコマースベンダーが多いですが、こちらは、必ずしもそうとは限りません。
まず、フロントエンドの豊かさとは何でしょうか？どこでもカートインできたり、どこでもカートの内容を表示できたりすることでしょうか？ワンクリック決済が可能なことでしょうか？CRMとの連携でクーポンを柔軟に呼び出せることでしょうか？検索処理が快適なことでしょうか？それぞれ実現方法について考えてみます。
- 「どこでもカートイン、カート表示が可能」
→これは、カートをAPI等で呼び出しやすい仕様になっている必要があります。実態としてはAPIがあれば良いので、必ずしもヘッドレスである必要はありません。 - 「どこでもワンクリック決済が可能」
→こちらも、決済をAPI等で呼び出すことができれば実現可能です。重要なことはヘッドレスではなく決済用のAPIがあることです。 - 「CRMとの連携でクーポン表示」
→CRMのツール側にAPIがあり、フロント側のHTMLからJS呼び出しなどで連携することができれば可能です。ヘッドレスである必要はありません。 - 検索が快適(例えばファセットなど)
→高機能な検索ツールを導入すれば可能です。高機能な検索ツールにはAPIがあるので、そちらをフロントのHTMLから呼び出すことができれば可能です。
このようにフロントのCMSが柔軟で、APIが充実していれば、わざわざヘッドレスを導入しなくてもフロントエンドの顧客体験は豊かになります。重要なのはAPIが備わっているかという点であることを念頭に置きましょう。
フロントエンドの顧客体験についてはバズワード的な部分があり、ヘッドレスというアーキテクチャに必ずしも拘る必要はないので、注意しましょう。
デメリット１「フロントエンドとバックエンドでデータが分かれるケース」
API側に必要なデータがない場合は、フロント側で別途データを管理する必要があります。例えばですが、
- A＝フロント側のシステム 店舗のデータ、記事コンテンツ
- B＝バックエンドのシステム 商品データ
- C＝AとBを紐付けする情報
そして、バックエンド側にないAの情報、またAとBの両者を紐付けする情報Cはどこで持つべきか？という課題も発生します。うまく作り込まないと運用が難しくなるケースが多いです。このようにフロント構築の際にAPIにないデータとAPIを別々に管理してマージする必要があるので設計をうまく行わないと逆に体験を悪くすることもありえます。
デメリット２「自在なカスタマイズ」できないケース
自在なカスタマイズについても、ECの機能をAPI呼び出しできればフロント画面は比較的柔軟にすることは出来るのですが、ロジックについては自在なカスタマイズが難しいケースがあります。
●ロジックの処理順序やその内容を変えたい場合
ロジックの処理順序を変えたいケースはどうでしょうか？カート決済の途中に、利用可能なポイントがいくつあるかリアルタイムで確認したい場合、ヘッドレスのアーキテクチャだと以下のような処理を行いたい場合に
- API側でカートの中身の決済のバリデーションを行う
- POS側で利用可能ポイントを確認する
- API側でカートの中身の決済を確定する
- POS側で利用可能ポイントを減産する
このAPIの処理順序を修正可能にするようなアーキテクチャを提供できている企業は少ないです。 Commerbleにはあります。ロジックのカスタマイズについては柔軟なカスタマイズはできないAPIも多いということに注意するようにしましょう。
●バックオフィスの最適化への考慮が足りない
ヘッドレスコマースの多くではまだ、バックオフィスのAPI化が進んでいません。
受注のステータスを配送済みに変更しながら、決済を確定するといったことの自動化が、決済代行業者別に柔軟に対応しているわけでは有りません。また、WMS側が配送済みステータスを連携するには十分なインターフェースが提供されていないケースも多いです。
今後は、バックオフィスにおける様々な業務ユースケースに対応したAPIが求められるでしょう。
●スケーラビリティ
APIは万能なものではなく、API自体にも呼び出し回数の制限やスケーラビリティがあります。
呼び出し回数が無限となっているものでも、例えば検索結果の一覧で一商品毎に付加情報を呼び出したりするような形にしてしまうと１ページ表示するのにAPIが数十回呼ばれるケースがあります。そのようなページに大量のトラフィックが押し寄せた場合どうなるでしょうか？APIの応答が遅くなりサイトが重くなります。
実態「ECシステムに求めれる柔軟性」とは？
●機能的柔軟性と実装的柔軟性
ECサービスを「柔軟性」の観点から評価する際に、「機能的柔軟性」と「実装的柔軟性」の2つに二分することができます。
- 機能的柔軟性：送料や税をはじめとするECロジックにおいてどれだけの選択肢が提供されるか
- 実装的柔軟性：そのECサービスを利用してECを構築するにどれだけの選択肢が提供されるか
ヘッドレスコマースの未来とは
ECのAPI化、柔軟なAPI呼び出しが出来ることは非常に有用です。ただ、単純にフロントとバックエンド分けることだけを考えてしまうと、サービスベンダーが分かれたり、データの保存場所が分かれたり、処理の詳細まではカスタマイズできなかったり等いくつか問題があります。
Commerbleでは上記問題点をカバーしたヘッドレスコマースを包含し、超えるようなアーキテクチャを保有しています。
具体例の一つだとCMSの中でAPIが呼び出せるようになっているので、フロント側のサービスを別途契約しなくてもフロント側とAPI側を柔軟に組み合わせた実装が可能です。
ヘッドレスコマースの未来は
- APIと柔軟に組み合わせることが可能なCMS
- APIの途中に処理を挟むことが可能なパイプライン
Commerbleではこれらの機能を有したEC形態をPaaSとして提供しています。
ぜひお問い合わせください。
