通販サイト/システムのリアーキテクチャのパッケージ/クラウド製品一覧

通販サイト/システムのリアーキテクチャは、決済・定期課金、カート・カタログ、APIゲートウェイの3つに分けて検討します。

主要6製品を、その3つの役割ごとに並べました。各テーマの詳細は、関連記事でも確認できます。

▼全体ガイドの記事
・通販サイト/システムのリアーキテクチャの完全ガイド

Webサービス開発の種類・工程・費用・会社選定までの全体像については、無料ホワイトペーパー「Webサービス開発の完全ガイドブック」で詳しく解説しています。

パッケージ型とクラウド型で異なる委譲の考え方

パッケージ型は、自社環境への導入や個別構築を含む広い意味で使われます。一方、クラウド型は、ベンダーが運用するサービスをインターネット経由で利用する方式です。

リアーキテクチャで比べやすいのは、クラウド型が中心です。そのため、この記事では現行のクラウドサービスを対象にします。

汎用サブドメインがクラウド型への委譲に向く理由

決済処理や定期便請求（サブスクリプション課金）は、業種を問わず共通する汎用サブドメインです。そのため、委譲の対象として考えやすい領域です。

• 継続的な基準対応：PCI-DSSなど厳しいセキュリティ基準に、常に対応し続ける必要があります。
• 更新への追随：クラウド型SaaSに委譲すると、法改正や基準変更への対応をベンダーの機能更新に任せられます。
• 監査範囲：委譲によって、監査の対象を絞り込めます。

コアドメインの自社開発と周辺基盤の選定

同梱物選定や頒布会・スキップ制御は、自社独自の価値を生むコアドメインです。既製品では、細かな業務ルールを表現しきれないことが一般的です。

紹介する製品は、コアドメイン自体を代替するものではありません。

自社で作り込む領域の周辺に、決済・定期課金基盤やAPIゲートウェイを組み合わせます。

製品を比較するときの共通軸

自社のリアーキテクチャに合うかを見るには、機能一覧とは別の観点が必要です。

候補を同じ条件で比べるため、課金・注文モデルとAPI連携、料金、セキュリティを共通の質問にします。

対応する課金・注文モデルの幅

頒布会や定期購入は、スキップや休止、同梱物による金額の変動で契約の形が変わります。候補製品がその形にどこまで対応するかは、次の4点で見ます。

• 状態変化：スキップ・休止・再開の扱い
• 金額変動：同梱物によって変わる請求額への対応
• 休止後の再開：休止中の課金停止と、再開時の自動課金
• 課金方式：従量課金と定額課金の組み合わせ

「サブスクリプション対応」と書かれていても、実際の契約パターンに合うかは分かりません。そのため、自社で扱う条件に沿って動作を確かめます。

API連携のしやすさとセキュリティ対応

自社のシステムとつながるかは、連携の作りで決まります。API連携とセキュリティは、次の点で比べます。

• API連携の設計：同梱物選定・在庫サービスとのAPI連携や、コールセンター連携APIのDTO設計を見ます。
• 並行検証：モックサーバーを使った並行検証のしやすさも、比べる材料になります。
• 決済のセキュリティ：決済・定期課金では、PCI-DSSなどへの対応状況を確かめます。
• APIゲートウェイの機能：認証・レート制限・ログ監査の機能を、デモや仕様書で確認します。

選定の詳しい進め方は、通販サイト/システムのリアーキテクチャの選定ポイント/選び方/種類で整理しています。

通販・定期購入リアーキテクチャで検討したい主要6製品

2026年7月時点で現行の公式ページを確認できた6製品を、決済・定期課金、カート・カタログ（コンポーザブルコマース）、APIゲートウェイの3つの役割に分けて紹介します。

掲載順はランキングではありません。いずれも、同梱物選定や頒布会制御といった自社のコアドメインと組み合わせる構成要素です。

Stripe Billing

Stripe Billingは、定期便請求（サブスクリプション課金）を汎用サブドメインとして外部に任せたい企業の候補です。

• プラン設計：Stripe公式サイトによると、サブスクリプション課金と従量課金を組み合わせられます。
• 請求・回収：Invoicing（請求書発行）や売上回収の自動化に対応します。
• 料金例：2026年7月時点の公式サイトには、ユニットあたり0.07ドル、1,000ユニットごとに2円の例があります。
• 適用条件：取引内容で変わるため、見積もり時点の最新料金が必要です。

Zuora

Zuoraは、複数の製品を組み合わせた「Quote-to-Cashプラットフォーム」として提供されています。

• 製品：Zuora Billing、Zuora Revenue、Zuora Payments、Zuora Collectionsなどがあります。
• 料金モデル：サブスクリプション課金に加え、使用量ベースやハイブリッド型も一気通貫で管理したい企業向けです。
• 頒布会の管理：周期や内容が変わる定期便では、請求（Billing）と収益認識（Revenue）を分けて管理できるかが比較の材料になります。
• 料金確認：具体的な料金は公式サイトに掲載されておらず、問い合わせによる見積もりが必要です。

commercetools

commercetoolsは、カート・カタログの領域を組み替えたい企業の候補です。

• 基盤：ヘッドレスコマースの統合基盤をAPIで提供し、カート・カタログ・検索などをコンポーザブルアーキテクチャで組み替えられます。
• 実績：公式サイトによると、年間GMV（流通取引総額）100億ドル超、6億件超の注文を処理してきたエンタープライズ向けの基盤とされています。
• 自社機能との分担：同梱物選定や頒布会ロジックは自社で別に実装し、本製品はカート・カタログ側のAPI基盤として組み合わせる想定です。
• 料金確認：料金は非公開のため、問い合わせによる見積もりが必要です。

BigCommerce

BigCommerceは、カート・カタログの領域でcommercetoolsと並んで挙がる候補です。

• 機能：B2B Commerce、マルチストアフロント、オムニチャネル対応を含むコンポーザブル／ヘッドレス基盤です。
• トライアル・見積もり：公式サイトでは、カード不要の無料トライアルと、Enterprise向けの個別の料金提示が案内されています。
• 複数ブランドの運用：マルチストアフロントが、ブランドごとの管理にどこまで対応するかを確かめます。
• 料金確認：本ページに具体的な料金はなく、問い合わせによる確認が必要です。

AWS API Gateway

AWS API Gatewayは、既存のモノリスから新しいマイクロサービスへ段階移行する場面で使う候補です。

• 配置と移行：ストラングラーフィグパターンで既存モノリスの前段に置き、コールセンター連携APIなどを新しいマイクロサービスへ段階的に振り分けます。
• 課金：最低料金や初期費用はなく、APIリクエスト数とデータ転送量に応じた料金体系です。
• 料金差：HTTP APIは、REST APIより最大71%安いと記載されています。

2026年7月時点の公式サイトには、最上位ティアの料金例として、100万リクエストあたり0.90ドルが掲載されています。

Kong Gateway

Kong Gatewayは、複数の環境にAPIゲートウェイを置きたい企業の候補です。

• 提供形態：オープンソース版・エンタープライズ版・クラウドホスト版（Kong Konnect）の3形態です。
• 配置環境：オンプレミス、クラウド、Kubernetes、サーバーレスなどに置けます。
• 選定場面：特定のクラウドに依存せず、オンプレミスと将来のクラウド移行を見据える場合や、オープンソース版で小さく検証する場合が該当します。
• 料金確認：本ページには具体的な料金プランがなく、Pricingページか問い合わせでの確認になります。

委譲方針別に候補を絞る方法

6製品を一度に細部まで比べるより、最初に手を付ける範囲と必須要件を決めてから候補を絞る方が効率的です。優先する製品の種類は、取り組む領域によって異なります。

決済・定期課金の委譲を優先したい場合

決済・定期課金を外部に任せ、同梱物や頒布会という自社コアドメインの設計に開発リソースを集中したいなら、Stripe BillingやZuoraが候補になります。従量課金の透明性を重視するならStripe Billingが候補です。一方で、Quote-to-Cashまで一気通貫で管理したい大規模組織では、Zuoraを検討します。

自社の請求モデルがどの程度複雑かによって、候補の絞り込み方が変わります。

カートのコンポーザブル化・段階移行を優先したい場合

カート・カタログを組み替えるなら、commercetoolsやBigCommerceが候補になります。複数ブランドや頒布会の運用実態に合わせて、絞り込みます。

既存のモノリスを稼働させたまま段階移行する場合は、AWS API GatewayやKong Gatewayが候補になります。AWS中心のインフラか、マルチクラウドやオンプレミスを見据えるかで選び分けます。

料金・契約前に確認すべきこと

公開されている料金の一部だけを見て安いと判断すると、取引件数やAPI呼び出し数が増えたときや、サポート費用がかかる場合などに、想定外のコストが生じることがあります。

そのため、料金表の単価だけでなく、導入準備・移行・運用・将来の乗り換えまで含めた総保有コストで比べます。

課金単位の違い

課金単位は製品によって異なります。決済・定期課金では取引件数や決済金額が、コマース基盤では取扱高やアカウント数が基準になります。

APIゲートウェイでは、API呼び出し数やデータ転送量などが課金単位になります。そのため、現在の受注数に加えて、頒布会拡大時やセール時のピーク想定件数を各社に提示します。

各社には同じ条件で見積もりを依頼します。料金が非公開の製品では、確認できていない金額を推測で比較表に入れないようにします。

データの正本と解約時の取り出し方

決済・定期課金をSaaSに委譲する場合は、契約と課金履歴のどちらを正本にするか、返金や補償トランザクションをどちらが処理するかを、契約書で確認します。

将来の乗り換えに備えて、契約・注文・請求の履歴を一般的な形式で取り出せるか確認します。解約時のデータ返却や削除の条件も、契約前に質問しておく必要があります。

デモとPoCによる製品の最終候補への絞り込み

資料で候補を絞ったら、実際の契約条件や注文条件を使って、デモまたはPoCを行います。

開発チームに加えて、法務やカスタマーサポート、可能であればコールセンターの担当者にも参加してもらうと、導入後の行き違いを減らせます。

スキップ・休止・再開の通しの動作確認

決済・定期課金基盤のPoCでは、休止の申請から決済の停止、再開時の自動課金まで、一連の操作を試します。加えて、返金や取り消しの補償トランザクションが正しく連鎖するかを確かめます。

在庫・同梱物選定サービスとのAPI連携は、どこまで連携できるかを検証します。そのうえで、エラー時にどちらの処理を優先するかも確かめます。

一部トラフィックでの先行検証

APIゲートウェイのPoCでは、全トラフィックを一度に切り替えず、コールセンター連携APIなど影響範囲を限定した経路から新サービスへ振り分けます。

レイテンシやエラー率、ロールバックのしやすさを見ます。また、ストラングラーフィグパターンで計画どおりに段階移行できるかを、小さく検証してから対象を広げます。

通販サイト/システムのリアーキテクチャの製品選定で押さえておきたいポイント

製品を選ぶ際は、機能数やブランド力だけでなく、自社の同梱物選定や頒布会ロジックとどう組み合わせるかも含めて判断します。

1製品で代替できる範囲の限界

紹介した製品は、決済・定期課金、カート・カタログ、APIゲートウェイのいずれかを担うものです。一方で、同梱物選定や頒布会・スキップ制御といったコアドメインは代替できません。

自社で作る範囲と外部に委譲する範囲を分けたうえで、必要な製品を組み合わせて検討します。

委譲方針で変わる適した製品

全企業に共通する1位の製品はありません。決済・定期課金、カートのコンポーザブル化、段階移行のどれを優先するかで、適した製品が変わります。

最初に着手する範囲を決めたうえで、同じシナリオのデモまたはPoCで比べます。

最新の公式情報による料金の再確認

本記事の料金情報は、2026年7月時点で公式サイトに掲載されていた内容です。従量課金の単価や無料枠の条件は、変わる可能性があります。

契約の前に、各社の公式サイトか営業担当へ、最新の料金体系を確認します。

まとめ

通販サイト/システムのリアーキテクチャでは、役割ごとに製品を組み合わせて検討するのが現実的です。

決済・定期課金は、PCI-DSSなどへの対応が求められる汎用サブドメインです。そのため、Stripe BillingやZuoraのようなSaaSへの委譲を検討します。

カート・カタログは、commercetoolsやBigCommerceのようなコンポーザブル基盤で組み替えます。また、段階移行は、AWS API GatewayやKong Gatewayといったゲートウェイを使い、ストラングラーフィグパターンで進めます。

委譲方針を決めたうえでの2〜3製品への絞り込み

まず、決済・定期課金の委譲、カートのコンポーザブル化、段階移行のどこから着手するかを決めます。そのうえで、候補製品を2〜3製品に絞ります。

課金・注文モデルとAPI連携を中心に、同じ質問で比べれば、機能一覧の多さに左右されずに選べます。

スキップ・休止・再開の実案件による最終確認

PoCでは、資料上の機能数より実案件での動きを重視します。

• 定期便の操作：自社特有のスキップ・休止・再開の動きを確かめます。
• 処理と連携：補償トランザクションと在庫・同梱物サービスとの連携を確かめます。

同梱物選定や頒布会ロジックは、既製のクラウド製品では吸収しきれません。

riplaは、フルスクラッチ開発の立場から、製品比較で見えた不足機能の整理と、自社業務に合わせたコアドメインの構築を支援しています。

▼全体ガイドの記事
・通販サイト/システムのリアーキテクチャの完全ガイド

▼開発を相談する前に読みたい無料ホワイトペーパー
・Webサービス開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック

会社紹介

株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

株式会社riplaの会社HPはこちら

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール

張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。