既製のテンプレートとは異なるカスタムストアフロントで買い物をしたことがあるなら、その裏でヘッドレスコマースAPIが機能していた可能性が高いでしょう。ヘッドレスコマースAPIは、コマースのバックエンドが公開するインターフェースであり、あらゆるストアフロントが、組み込みのテーマに縛られることなく、商品を読み込み、カートを作成し、注文を行うことができます。この解説記事では、それが何を意味するのか、コンポーザブルコマースやMACHとどのように関連するのか、そしてなぜストアフロントチームとパートナーチームがそのAPI契約に左右されるのかを説明します。これは、ソフトウェアがヘッドレス化し、APIが製品となるという考えに基づいています。
コマースにおける「ヘッドレス」とは
従来のコマースプラットフォームは一体型として提供されます。製品カタログ、カート、チェックアウト、そしてそれらすべてを表示するHTMLページは、すべて同じシステム内に存在します。テーマを適用し、調整して、リリースします。
ヘッドレスコマースはこれを2つに分割します。多くの場合コマースエンジンと呼ばれるバックエンドは、カタログ、価格設定、在庫、カート、注文ロジックを保持します。フロントエンド、つまりストアフロントは、自由に構築できる独立したアプリケーションとなります。それらを繋ぐ唯一のものはAPIです。
つまり、「ヘッド」とはプレゼンテーション層のことです。ヘッドレス化するとは、固定されたヘッドを取り除き、コマースロジックであるボディをAPIを通じて公開することを意味します。Reactサイト、ネイティブモバイルアプリ、スマート冷蔵庫の画面、あるいは音声アシスタントなど、すべてが同じAPIを介して通信できるため、同じバックエンドと連携できます。
そのデカップリングこそが本質です。フロントエンドチームは独自のフレームワークを選択し、独自のスケジュールでリリースします。バックエンドチームはコマースルールを管理します。APIはそれらの境界線です。
トレードオフとして、より多くの作業を引き受けることになります。従来のプラットフォームは、すぐに使えるストアをそのまま提供します。ヘッドレス化するということは、ストアフロントを自分で構築し、ホストすることを意味するため、柔軟性にはエンジニアリングコストが伴います。既製のテーマでは必要な体験を提供できない場合や、1つのバックエンドから複数のチャネルに対応したい場合に、チームはヘッドレスを選択します。
ヘッドレス vs コンポーザブル vs MACH
これら3つの用語は互換的に使用されますが、それぞれ異なるスコープを記述します。正直な内訳は以下の通りです。
| 用語 | 説明 | スコープ |
|---|---|---|
| ヘッドレスコマース | フロントエンドが単一のコマースバックエンドからデカップリングされ、APIで接続される | 1つのバックエンド、1つまたは複数のフロントエンド |
| コンポーザブルコマース | スタック全体が交換可能なベストオブブリードサービス（カタログ、検索、決済、PIM、OMS）に分割される | 多くの独立したサービスが組み合わされる |
| MACH | コンポーザブルスタックが従う傾向のあるアーキテクチャ原則のセット | 哲学であり、製品ではない |
ヘッドレスは狭いケースです。ストアフロントがAPIを介して通信する限り、モノリシックなバックエンド1つでもヘッドレスであることができます。
コンポーザブルコマースはさらに進みます。1つのバックエンドではなく、独立したサービスを組み立て、各タスクに最適なツールを選択します。あるベンダーからの検索、別のベンダーからの決済、独立した製品情報管理システムなどです。それぞれが独自のAPIを持つ独自のサービスであり、それらを1つの体験に統合します。
MACHは、ほとんどのコンポーザブルスタックの背後にある原則のセットです。2020年に設立された業界団体であるMACHアライアンスによると、MACHはMicroservices、API-first、Cloud-native SaaS、そしてHeadlessを意味します。APIファーストがまさにその中心にあることに注目してください。MACHの世界では、APIは副次的な機能ではありません。それは各部品が互いに通信する唯一の方法であり、APIを製品として扱うという考えと同じ理由に基づいています。
ヘッドレスコマースAPIが実際に公開するもの
正確な形式はプラットフォームによって異なりますが、ほとんどのヘッドレスコマースAPIは同じ主要な機能をカバーしています。
- カタログと製品。 ストアフロントが商品リストと詳細ページを表示できるように、製品、バリアント、コレクション、メディアを読み込みます。
- 検索とブラウズ。 カタログをクエリ、フィルター、ソートします。
- カートとチェックアウト。 カートを作成し、商品を出し入れし、割引を適用し、支払いに進みます。
- 顧客。 サインイン、アカウント管理、注文履歴の追跡を行います。
- 在庫と価格設定。 在庫レベルと適切な状況での適切な価格を表示します。
一部のプラットフォームでは、これらを一般公開ストアフロントAPIとバックオフィス業務用の別個の管理APIに分割しています。ストアフロントAPIは読み取りが主で顧客向けです。管理APIはカタログ編集、注文管理、設定を処理します。
プロトコルも重要です。多くのヘッドレスコマースAPIはGraphQLを使用しており、これによりストアフロントは1回のラウンドトリップで必要なフィールドだけを正確に要求できます。その他にはRESTを使用するものもあり、両方を提供するプラットフォームもあります。トレードオフを検討している場合は、RESTとGraphQLの比較をご覧ください。
主なプラットフォーム
ヘッドレスコマースの分野は、大まかにSaaSエンジンとオープンソースエンジンに分けられます。よく目にする名前をいくつか挙げます。
- commercetools。 MACHアライアンスの創設メンバーであり、最もよく引用されるコンポーザブルコマースプラットフォームの1つです。設計上APIファーストかつクラウドネイティブです。
- Shopify。 Storefront APIを介したヘッドレス構築を提供しており、その利用のためのReactフレームワークとしてHydrogenがあります。すでにShopifyの世界にいるなら、弊社のShopify APIチュートリアルが良い出発点となるでしょう。
- BigCommerce。 カタログの上にGraphQL Storefront APIとCheckout APIを備えたヘッドレスモードをサポートしています。BigCommerce APIの使用に関するガイドをご覧ください。
- Saleor。 PythonとDjangoで構築されたオープンソースのGraphQLファーストエンジンです。
- Medusa。 Node.jsとTypeScriptで構築されたオープンソースエンジンで、フルバックエンド制御を求めるJavaScriptチームに人気があります。
価格設定、ホスティングモデル、APIカバレッジは変更されるため、コミットする前にプラットフォームの詳細を確認してください。それらすべてに共通するパターンは同じです。エンジンはAPIを介してコマースロジックを公開し、あなたがヘッドを構築します。
チームがコマースAPI契約に依存する理由
ストアフロントがデカップリングされると、APIは配管ではなくなり、誰もがそれに合わせて構築する合意となります。ここでヘッドレスが現実になります。
フロントエンドチームは、製品応答の正確な形状がわからない限り、製品ページをリリースできません。パートナー統合、ロイヤリティアプリ、税務サービス、マーケットプレイスフィードなど、すべてが同じエンドポイントに接続します。モバイルチームはウェブチームと同じ契約を利用します。警告なしにレスポンスの形状が変更されると、それらのコンシューマーすべてが一度に壊れる可能性があります。
それがリスクであり、機会でもあります。明確で安定した、十分に文書化されたコマースAPI契約は、独立したチームが互いに干渉することなく迅速に動くことを可能にします。曖昧な、または不安定なものは、すべてのリリースを調整の混乱に変えます。契約は製品であるため、契約テストを含め、ストアフロント自体と同じ注意を払う価値があります。これにより、破壊的変更がリリースされる前に捕捉されます。
バージョン管理も取引の一部です。製品応答を変更したり、フィールド名を変更したりする必要がある場合、単にエンドポイントを編集して望むだけではいけません。あなたが制御できないコンシューマーがそれを読み取っているからです。したがって、ヘッドレスチームは契約を公約として扱います。可能な限り追加的な変更、明確な非推奨期間、そしてパートナーの統合に到達する前に破壊的な変更を検出するテストです。
Apidogの役割
Apidogはあなたのストアを運営しません。コマースエンジン、CMS、ゲートウェイではなく、あなたのスタックをヘッドレスやコンポーザブルにするわけでもありません。Apidogが果たす役割は、これらすべてにおけるAPIファーストの柱、つまり、他のすべてが依存する契約を設計、テスト、モック、文書化するレイヤーを担うことです。
これはヘッドレスコマースの作業にきれいにマッピングされます。
- まず契約を設計します。 コードが存在する前に、ストアフロントまたは管理APIをApidogでOpenAPI仕様としてモデル化し、フロントエンドとバックエンドが事前に形状に合意できるようにします。
- バックエンドの準備ができる前にモックします。 仕様からモックサーバーを立ち上げ、コマースエンジンがまだ構築中の間に、ストアフロントチームがリアルな製品とカートの応答に対して構築できるようにします。これはデカップリングの約束を実用的なものにするもので、詳細については弊社のモックAPI解説をご覧ください。
- CIで契約をテストします。 Apidog CLIはGUIなしでAPIテストを実行します。これはパイプラインに適合するヘッドレスなテスト実行です。ヘッドレスコマースとの真の概念的調和であり、フロントエンドは不要で、契約が検証されるだけです。
- パートナー向けに文書化します。 自動生成されたインタラクティブなドキュメントは、ストアフロントチームとパートナーチームが統合するAPIの唯一の信頼できる情報源を提供します。
APIが唯一のインターフェースになったときにこれがなぜ重要なのかについて深く掘り下げた記事は、ソフトウェアがヘッドレス化し、APIが製品となるをご覧ください。ワークフローを試したい場合は、Apidogをダウンロードして既存の仕様をインポートしてください。
よくある質問
ヘッドレスコマースとコンポーザブルコマースは同じですか？
いいえ、異なります。ヘッドレスコマースは、APIを介してストアフロントを1つのコマースバックエンドからデカップリングします。コンポーザブルコマースはさらに進み、多くの独立したベストオブブリードサービスを、それぞれ独自のAPIを持つ形で組み合わせて、単一の体験を構築します。すべてのコンポーザブルなスタックはヘッドレスですが、単一のモノリシックなバックエンドを持つヘッドレスな設定が必ずしもコンポーザブルであるとは限りません。
ヘッドレスコマースAPIにはGraphQLが必要ですか？
いいえ、必要ありません。GraphQLは、ストアフロントが1回の呼び出しで必要なフィールドだけを正確に要求できるため一般的であり、製品やカートのレンダリングに適しています。しかし、多くのヘッドレスコマースAPIはRESTを使用しており、一部のプラットフォームは両方を提供しています。プロトコルは、契約が安定していて文書化されていることよりも重要ではありません。
バックエンドが構築される前にヘッドレスコマースAPIをテストできますか？
はい、できます。それがデザインファーストで進める主な理由の1つです。API契約を仕様としてモデル化すれば、リアルな応答を返すモックサーバーを生成できます。コマースエンジンの開発中にストアフロントチームはモックに対して構築とテストを行い、後で実際のAPIエンドポイントに切り替えます。
MACHアライアンスとは何ですか？
MACHアライアンスは、2020年に設立された業界団体で、Microservices、API-first、Cloud-native SaaS、Headlessの原則に基づいて構築されたオープンなベストオブブリードテクノロジースタックを推進しています。commercetoolsのようなベンダーが創設メンバーです。MACHはアーキテクチャ原則のセットであり、購入する単一の製品ではありません。
契約がストアである
ヘッドレスコマースは、価値をテーマからAPIへと移行させます。ストアフロントがデカップリングされると、コマースAPIは、フロントエンド、モバイル、およびパートナーチームが実際に構築する基盤となるものです。コンポーザブルコマースとMACHは、APIファーストを単なる「あれば良いもの」ではなく、コア原則とすることで、それをさらに推し進めます。
これらすべてはApidogに依存するものではありませんが、契約の品質は、それを設計、モック、テスト、文書化する場所があることで向上します。もしあなたのヘッドレスプロジェクトがその方向に向かっているなら、Apidogは基盤となるコマースエンジンであるかのように見せかけることなく、そのレイヤーを提供します。