【ITニュース解説】We moved ERP company pricing from Magento + Redis to commercetools. The cache layer just disappeared.

企業間の取引（B2B）において、取引先企業ごとに異なる価格設定や、購入数量に応じた割引（数量割引）を適用することは一般的である。これらの価格情報は通常、企業の基幹業務システム（ERP）によって管理され、ECサイトなどの販売システムに連携される。この連携の仕組みが複雑になりがちで、運用に手間がかかるという課題が多くの企業で共通して発生している。

かつてのシステムでは、ECサイトプラットフォームとしてMagento（アドビコマース）を使用し、価格情報の管理に複雑な仕組みが用いられていた。ERPから送られてくる企業ごとの価格データは、まずリレーショナルデータベースであるSQLデータベースに格納され、そこから夜間の同期スクリプトによって、企業ごとの価格リストがJSON形式のデータとして作成されていた。このJSONデータは、高速なデータストアであるRedisやKeyDBといったキャッシュ層に保存され、ECサイトは価格APIを通じてこのキャッシュ層から価格情報を取得していた。商品の詳細ページでは、数量割引がプラグインによって適用され、リスト表示の価格はAJAX（非同期通信）という技術でウェブページ全体を再読み込みすることなく動的に読み込まれることで、ウェブサイト全体の表示を高速化するフルページキャッシュという仕組みを維持していた。

この仕組みは一見すると動作していたが、その裏ではERP、SQLデータベース、Redis/KeyDBというキャッシュ層、そしてMagentoという四つの異なるシステムが、単に「この企業がこの商品にいくら支払うか」という一つの情報を返すためだけに複雑に連携していた。特にキャッシュ層の管理は手間がかかり、データの一貫性を保つための同期処理も複雑だった。複数のシステムが動的に連携する中で、どこかで問題が発生すると、顧客に誤った価格が表示されるリスクも常に存在した。

そこで、この複雑なキャッシュ層の管理そのものを不要にするため、システム全体をヘッドレスコマースプラットフォームであるcommercetoolsへと移行する決断がなされた。この移行の根本的な思想は、「キャッシュをそのまま移植するのではなく、価格情報を最初から正しくインポートする」というものであった。commercetoolsには「Standalone Prices」という機能があり、これを用いることで、商品番号（SKU）、価格、通貨、国、販売チャネル、顧客グループ、有効期間、そして数量割引といった詳細な価格情報を、一箇所でまとめて管理できる。

commercetoolsのシステムでは、ECサイトで商品が問い合わせられたり、カートに商品が追加されたりする際に、プラットフォーム自身が自動的に最も条件に合う価格情報（例えば、特定の企業に設定された価格や、数量割引が適用された価格など）を選択する仕組みになっている。これにより、開発者が手動でキャッシュを管理したり、複数のシステム間で価格情報を同期させたりする手間が一切不要となった。ERPからの夜間データ連携は残るものの、以前のようにRedisにデータを流し込むのではなく、commercetoolsが提供するImport API（外部システムからデータを登録するための窓口）に直接、変更があった価格情報だけを書き込むことで、システムのシンプルさが劇的に向上したのである。

commercetoolsを導入するにあたって、いくつかの重要な設計上の考慮点と学習があった。まず、企業の価格リストと消費者の価格リストを区別する方法である。commercetoolsでは、流通経路や販売方法を定義する「チャネル」という概念と、顧客をグループ分けする「顧客グループ」という概念が存在する。企業向けの価格リストには「チャネル」を割り当て、消費者（ログインする顧客）の会員価格などには「顧客グループ」を割り当てるのが最も適切であるという結論に至った。これは、B2B取引において、一人の顧客が複数の会社のアソシエイト（関係者）として購入を行う際に、どの会社の価格で購入するかを切り替えられるようにするためである。顧客グループは顧客個人に紐付くため、会社を切り替えてもグループは変わらない。一方、チャネルは会社や店舗に紐付けられるため、会社を切り替える際に適切なチャネルの価格が適用されるようになる。

次に、commercetoolsのAPI（システム連携の窓口）が、複雑な価格選択ルールにどのように従うかを事前にテストすることの重要性が明らかになった。公式ドキュメントだけを信頼するのではなく、実際に小さなテストスクリプトを書いて、仮の価格情報を作成し、APIがどの価格を返すかを確認する作業が必要であった。例えば、ある商品に対して企業向けの価格と、チャネルに紐付かない一般的な価格の両方が存在する場合、APIはどちらを優先するのか、あるいは企業向けの価格が存在しない場合に一般的な価格にフォールバック（予備の価格が使われること）するのか、といった具体的な挙動を確認した。これにより、システムが意図しない価格を顧客に表示してしまうリスクを未然に防ぎ、開発にかかる時間を大幅に削減できた。

カート機能においては、commercetoolsが自動で数量割引後の単価を計算し、カート内の各商品の価格情報に格納してくれることが分かった。開発者は自分で数量割引を計算する必要がなく、その単価をそのまま利用できるため、実装が非常にシンプルになる。ただし、商品の詳細ページなどで「〇個購入で単価〇円」といった割引情報を表示するロジックは、別途用意する必要がある。

また、意外な発見として、商品自体に設定される「商品割引」と、数量に応じて単価が変わる「数量割引（ティアプライス）」が同時に適用される場合、商品割引の方が優先されるという挙動があった。B2B取引では、数量割引が実質的な割引として機能することが多いため、この優先順位を理解し、商品割引と数量割引のどちらを適用するかを明確に設計することが重要となる。

顧客グループに関連する注意点として、カートが一度作成されると、そのカートに紐づく顧客グループは自動では更新されないという挙動も判明した。もし顧客が後から別の顧客グループに所属変更した場合、既存のアクティブなカートには古いグループ情報が残ってしまう。このため、顧客グループの変更を伴う同期処理では、管理者権限でアクティブなカートにも新しい顧客グループ情報を明示的に設定し直す必要があった。

最後に、システム全体のキャッシュ戦略の見直しも不可欠であった。特に、検索機能においては、顧客グループごとに異なる価格が表示されるため、検索結果のキャッシュも顧客グループごとに分離する必要があった。これを怠ると、会員の顧客が検索した際に、一般顧客向けの価格が表示されてしまう可能性がある。さらに、ゲスト（ログインしていない訪問者）向けのページキャッシュは顧客グループの概念を持たないため、常に一般的な価格を表示し続けることになる点も考慮が必要であった。顧客グループを考慮した価格表示は、ログイン済みの顧客にのみ適用されるため、システム全体のキャッシュ設計を見直す良い機会となった。

このcommercetoolsへの移行により、B2Bにおける複雑な価格設定の課題が劇的にシンプルに解決され、開発・運用コストが大幅に削減された。ヘッドレスコマースプラットフォームのネイティブ機能を最大限に活用することで、既存の複雑な課題を根本から解決できる、非常に良い事例である。