通販サイト/システムのリアーキテクチャとは？｜考え方/特徴/仕組み/目的を解説

通販や定期購入(頒布会・サブスクリプション)を扱う企業では、都度購入型のECサイトと同じ発想でシステムを刷新しようとすると、休止・スキップ・再開といった契約特有の状態変化をうまく設計に落とし込めず、開発が長期化することがあります。通販サイト/システムのリアーキテクチャとは、既存システムの見た目や業務フローを保ったまま、内部の構造をマイクロサービスやドメイン駆動設計の考え方で組み替え、契約と受注のライフサイクルを分離して扱えるようにする技術的な再設計を指します。

本記事では、通販サイト/システムのリアーキテクチャの基本的な考え方、近接する刷新用語との違い、マイクロサービス化を支える技術的な仕組み、定期購入・頒布会に特有の設計論点、段階移行を支える主要な仕組み、導入目的として期待できる効果までを順に解説します。すでにモダナイゼーションや刷新プロジェクトを検討している担当者の方が、通販・定期購入業態に特有の技術的な論点を把握できるよう、実務に即して整理します。

本テーマに関する全体ガイドは、以下の記事をご覧ください。

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

通販サイト/システムのリアーキテクチャとは何か

通販サイト/システムのリアーキテクチャは、外部から見える画面や業務フローを大きく変えずに、内部のシステム構造を組み替える取り組みです。単発の注文で完結する都度購入型ECとは異なり、通販・定期購入業態では契約情報と個々の受注情報を分けて管理する必要があるため、リアーキテクチャの設計対象もこの二層構造を前提に考える必要があります。

都度購入型のECでは、注文を受け付けてから在庫を引き当て、決済し、出荷するまでの一連の処理が一つの取引として完結します。一方、頒布会や定期購入では、顧客との継続的な契約(サブスクリプション)がまずあり、その契約にもとづいて毎月や毎回の受注(オーダー)が生成されるという二層構造になります。この二つのライフサイクルを一つのモデルとして扱ってしまうと、契約の休止や解約と個別の受注処理が絡み合い、どちらか一方を変更したいだけなのにもう一方まで影響してしまう状態が生まれやすくなります。

リアーキテクチャでは、契約の状態管理と受注処理を別々の責務として切り分け、それぞれが独立して変更・スケールできるようにドメインの境界を引き直します。モノリスの内部で密結合していたこの二つの概念を、データベースのテーブル構造だけでなくコードの責務としても明確に分離することが、設計上の出発点になります。

多くの通販システムでは、長年の運用の中で、深夜バッチが定期購入データを読み込み、翌日分の受注をまとめて生成する処理が中心的な役割を担ってきました。この「Pull型」の仕組みは実装しやすい一方で、バッチが完了するまで状況を確認できず、スキップや休止の反映にも翌営業日までの時間差が生じるという制約を抱えています。

リアーキテクチャに着手する前に、まずこの深夜バッチがどれだけ複雑な条件分岐を抱えているかを可視化する作業が必要です。頒布会の周期変更、同梱物の出し分け、特売期間中の例外処理などが一本のバッチ処理に積み重なっている場合、そのロジックをドメインごとに解きほぐすだけでも数週間から1.5か月程度を要することが一般的です。

隣接するシステム刷新の考え方との違い

通販サイト/システムの刷新を検討する際には、モダナイゼーション、システム刷新、システム更改、システムのリニューアルといった近い言葉が使われることがあります。それぞれ主眼を置く観点が異なるため、リアーキテクチャがどの部分を担うのかを整理しておくと、社内でプロジェクトの位置づけを説明しやすくなります。

通販サイト/システムのモダナイゼーションは、リホスト、リプラットフォーム、リファクタリング、リビルド、リプレースといった複数の手法から自社に合う進め方を選ぶ、HOW(どう進めるか)の総論にあたります。システム刷新は、会員基盤や受注実績という資産価値を根拠に投資判断を行う、WHY・WHENの経営判断が主眼です。システム更改は決済代行の旧APIやOS・ミドルウェアのサポート終了といった外圧型のトリガーを起点にした契約・調達の話であり、システムのリニューアルはマイページの使い勝手や同梱チラシのデザインといったUX・UI起点の改善を指すことが多くなります。

これに対して通販サイト/システムのリアーキテクチャは、選んだ進め方(モダナイゼーションの一手法)を実際にどう技術的に実装するか、つまりアーキテクチャそのものの再設計に踏み込む領域です。経営判断や契約更改のタイミングと並行して、内部構造をどう組み替えるかという技術的な設計論点を扱います。

ECリアーキテクチャという言葉は、都度購入型の一般的なECサイトを対象に、ヘッドレスコマースやMACHアーキテクチャといった技術によってカート・決済・在庫・検索という共通ドメインを刷新する取り組みを指すことが一般的です。都度購入は「注文→在庫引当→決済→出荷」という単発の処理(Saga)で完結するため、設計上の主な関心は各処理の疎結合化やAPI化に置かれます。

一方、通販・定期購入業態のリアーキテクチャでは、契約と受注のライフサイクルが分離しているという構造上の違いがあり、休止・スキップ・再開という契約期間中に恒常的に発生する状態変化を、補償トランザクションを含めてどう設計するかが固有の論点になります。都度購入型ECの技術知見をそのまま適用するのではなく、頒布会や同梱物選定という通販特有の業務ロジックをどのドメインに配置するかを個別に検討する必要があります。

リアーキテクチャを支える技術的な仕組み

通販サイト/システムのリアーキテクチャでは、モノリスとして一体化していた機能を、ドメインごとの境界にもとづいて分解し、必要に応じてマイクロサービス化します。どこで機能を分割するかを決めるドメイン駆動設計(DDD)の考え方と、処理をどう伝播させるかを決めるイベント駆動の設計が、技術的な仕組みの中心になります。

ドメイン駆動設計では、業務領域を「コアドメイン」と「汎用サブドメイン」に分類し、どこに自社独自の価値があるかを明確にします。通販・定期購入業態においては、同梱物の選定ロジックや頒布会・スキップ制御といった、自社の商品構成や顧客対応方針に強く依存する領域がコアドメインにあたり、決済処理や定期課金の管理といった業種を問わず共通する処理は汎用サブドメインに位置づけられます。

この分類を先に行わずにマイクロサービス化を進めると、本来独立してよいはずの機能同士が暗黙のうちに依存し合う「分散モノリス」に陥り、サービスを分けたメリットである独立デプロイやスケーリングの自由度を失ってしまいます。境界の引き方を誤らないためには、既存のバッチ処理やコードを机上で分割するのではなく、実際の業務フローに沿ってどのイベントが誰の責務で発生するかを洗い出す作業が欠かせません。

モノリス時代の深夜バッチによる「Pull型」の処理を、イベントが発生するたびに後続処理へ伝播させる「Push型」のイベント駆動アーキテクチャへ切り替えるかどうかは、リアーキテクチャにおける大きな設計判断の一つです。Push型に切り替えると、スキップや休止の反映がほぼリアルタイムになる一方、イベントの順序保証や重複配信への対処など、Pull型では意識する必要がなかった課題に新たに向き合うことになります。

すべての処理を一律にPush型化する必要はなく、即時性が求められる処理と、数分から数時間程度の遅延が許容できる処理を区別したうえで、どちらの方式を採用するかをドメインごとに判断することが現実的です。この判断を誤ると、本来コストを抑えられるはずの処理にまで高価なイベント基盤を適用してしまい、運用コストだけが増えてしまいます。

定期購入・頒布会に特有の設計論点

通販サイト/システムのリアーキテクチャで最も技術的な難易度が高いのは、契約期間中に恒常的に発生する状態変化と、頒布会・同梱物という自社独自の業務ロジックをどう分散システムの中に位置づけるかという論点です。

定期便のスキップ・休止・再開という操作は、決済、在庫、配送手配など複数のサービスにまたがる一連の処理を、途中で取り消したりやり直したりする必要がある点で、一般的な都度購入の注文処理よりも複雑です。こうした分散トランザクションには、各サービスが自分の処理を実行した後、失敗が起きた場合に「補償トランザクション」によって処理を打ち消していくSagaパターンが用いられます。

たとえば、休止を申し込んだ後に決済の取り消しは成功したものの、すでに出荷準備が進んでいた在庫の解放が間に合わないといったケースでは、どちらの処理を先に確定させ、どちらを補償対象にするかをあらかじめ設計しておく必要があります。同じ休止処理が連続してクリックされた場合にも二重に取り消し処理が走らないよう、冪等性(同じ処理を何度実行しても結果が変わらない性質)を担保する仕組みも欠かせません。

頒布会や同梱物の選定ロジックは、購買履歴や継続回数にもとづいて内容を決めるという点でレコメンドエンジンに近い複雑さを持ち、自社の商品戦略や販促方針を色濃く反映するコアドメインです。この処理をどのサービスの責務として実装するかを誤ると、本来独立させたかった注文処理や決済処理と結び付いてしまい、機能追加のたびに関係のないサービスまで改修が必要になる「分散モノリス」の状態を招きます。

また、同梱物選定エンジンが停止した場合にチェックアウトや決済まで巻き込まれて注文が完了できなくなる事態を避けるため、障害分離の設計も重要です。同梱物選定でエラーが発生しても、あらかじめ定めたデフォルトの同梱内容で注文を継続できるようにフォールバックを用意しておくことで、コアドメインの複雑さが基幹となる購入処理の安定性を損なわないようにできます。

段階移行を支える主要な仕組み

通販サイト/システムのリアーキテクチャは、一度にすべてを作り替えるのではなく、既存システムを稼働させたまま特定の機能から段階的に移行していく進め方が一般的です。この段階移行を技術的に支えるのが、API Gatewayを使ったストラングラーフィグパターンと、コールセンターなど既存業務との連携APIです。

ストラングラーフィグパターンは、既存のモノリスの前段にAPI Gatewayを配置し、リクエストの一部を新しいマイクロサービスへ、残りをそのまま既存システムへ振り分けることで、システム全体を止めずに機能を少しずつ新しい構造へ移し替えていく進め方です。名称は、他の樹木に絡みついて徐々に取って代わる植物に由来しており、一気に置き換えるのではなく、既存システムを残したまま新旧が共存する期間を計画的に設けることが特徴です。

通販・定期購入業態のリアーキテクチャでは、まずコールセンター連携用のAPIなど、特定のトラフィックだけを新しいサービスへ振り分けるところから始めることが多く、影響範囲を絞りながら実際の本番トラフィックで検証できる利点があります。

通販・定期購入業態では、電話でのコールセンター受注が一定の比率を占める企業が多く、この経路をどうシステムに組み込むかもリアーキテクチャの重要な論点です。API-first設計、つまり実装よりも先にAPIの仕様(DTOの構造など)を確定させる進め方を採用すると、バックエンドの完成を待たずにフロント側やコールセンターシステムの改修を並行して進められるため、実装の複雑度を抑えられます。

一方で、オペレーターが電話で在庫を確保している最中に、同じ商品がWebサイトから購入されてしまうといった競合が起こり得るため、楽観的ロックなど在庫確保の排他制御をあわせて設計する必要があります。コールセンター連携は、API-first設計によって実装複雑度を中程度に抑えられる領域ですが、在庫の同時アクセスという論点を見落とすと想定外の二重販売につながります。

導入目的と期待できる効果

通販サイト/システムのリアーキテクチャに取り組む目的は、見た目を刷新することではなく、負荷が集中する処理だけを独立してスケールできるようにし、機能追加のたびにシステム全体を止めずに改修できる状態を作ることにあります。

通販・定期購入業態には、月末の定期受注確定日やセール時期にトラフィックとバッチ処理が極端に集中するという特性があります。同梱物・頒布会最適化のように高いCPU負荷を要するロジックを独立したサービスに切り出しておけば、その処理だけを需要に応じてスケールさせることができ、システム全体を一律に増強するよりも無駄なリソースを抑えられます。

一方で、機能を細かく分割するほど、サービス間の通信や監視、デプロイの管理といった運用オーバーヘッド(いわゆるマイクロサービス税)も増えていきます。負荷が集中する処理を見極めずにすべてを細分化してしまうと、スケーラビリティ以上に運用の複雑さが増してしまうため、どこを独立させる価値があるかを見極めることが前提になります。

定期便請求(サブスクリプション課金)のように、PCI-DSSなどのセキュリティ基準への対応が求められる処理を独立したサービスに切り出しておくと、監査対象の範囲をその部分に限定でき、他の機能への影響を抑えながら監査対応を進めやすくなります。決済や定期課金といった汎用サブドメインを外部のSaaSに委譲する構成も、この監査範囲の限定という観点から選ばれることがあります。

また、コールセンター連携やフロントの改修を、バックエンドの完成を待たずに並行して進められる体制が整うことで、業務側からの追加要望にも段階的に対応しやすくなります。ただし、独立したサービスが増えるほど、どのサービスがどのデータの正本かを管理する体制も必要になるため、リアーキテクチャの効果は技術的な設計だけでなく、運用体制の整備とあわせて評価する必要があります。

通販サイト/システムのリアーキテクチャ導入前に確認しておきたいポイント

通販サイト/システムのリアーキテクチャは効果の大きい取り組みですが、組織の規模や既存システムの状態によっては、マイクロサービス化以外の選択肢の方が現実的な場合もあります。着手前に確認しておきたい論点を整理します。

エンジニアチームの人数がおおむね10〜15名に満たない組織では、マイクロサービス化によって増える運用・監視・デプロイ管理の負荷が、独立スケーリングによって得られるメリットを上回ってしまうことがあります。この場合は、内部の責務は明確に分離しつつも、デプロイ単位は一つにまとめる「モジュラーモノリス」に留めておく方が、限られた人数で無理なく運用できる現実的な選択になります。

長年蓄積された定期購入バッチが、頒布会の周期変更や特売期間の例外処理をどれだけ抱え込んでいるかによって、ドメイン分析・境界設計に必要な期間は大きく変わります。着手前にこのバッチのロジックを洗い出さずに一括して移行計画を立ててしまうと、想定していなかった例外処理が後から見つかり、スケジュールの見直しが繰り返される原因になります。

補償トランザクションを含むSagaパターンは、実装した後も、決済は成功したが在庫が確保できず出荷が失敗するといった例外ケースに継続的に対応する運用体制を必要とします。こうした運用を担えるSRE人材が社内に不足している場合、外部の専門チームと連携する体制をあらかじめ検討しておくことが望まれます。

すべてのドメインを同時にマイクロサービス化しようとすると、検証すべき分散トランザクションの組み合わせが膨大になり、プロジェクト全体の見通しが立てにくくなります。定期便のスキップ処理とコールセンター連携の一部など、影響範囲を絞った垂直スライスから着手し、実際の運用で得られた知見を踏まえて対象を広げていく進め方が、通販・定期購入業態のリアーキテクチャでは有効です。

まとめ

通販サイト/システムのリアーキテクチャは、都度購入型ECの技術知見をそのまま流用するのではなく、契約(サブスクリプション)と受注(オーダー)のライフサイクルが分離しているという通販・定期購入業態特有の構造を前提に、ドメイン駆動設計とSagaパターンによる補償トランザクションで内部構造を組み替える取り組みです。同梱物選定や頒布会制御という自社のコアドメインをどう境界設計するか、決済や定期課金という汎用サブドメインをどこまで外部のSaaSに委譲するかを見極めることが、成否を分ける重要な論点になります。

ストラングラーフィグパターンによる段階移行は、既存システムを止めずに新しい構造へ移行できる有効な手段ですが、Sagaパターンの運用を支えるSREスキルや、エンジニアチームの規模に見合った移行範囲の設定とあわせて計画する必要があります。一括した刷新を急ぐのではなく、影響範囲を絞った垂直スライスから着手し、検証を重ねながら対象を広げていくことが、通販・定期購入業態特有の複雑さに対応する現実的な進め方です。

決済や定期課金のように汎用的な処理は外部のSaaSに任せられますが、頒布会・同梱物選定・スキップ制御といった自社独自の業務ロジックは、既製のパッケージだけでは十分に表現しきれないことが少なくありません。riplaはフルスクラッチ開発の立場から、こうしたコアドメインのドメイン分析・境界設計や、既存の基幹システム・コールセンターシステムとの連携を含む構築を支援しています。具体的な選定の進め方は通販サイト/システムのリアーキテクチャの選定ポイント/選び方/種類で解説しています。

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

株式会社riplaでは、IT事業会社出身のプロフェッショナルが「Impact-Driven型支援」を通じて、プロダクトやシステムの納品・提供を目的とせず、お客様と同じ目線で、事業成果の達成をゴールとして、高品質なDX/開発支援をいたします。

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

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

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

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

執筆者プロフィール

張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。IT事業会社出身のプロフェッショナルが集う株式会社riplaにおいて、「Impact-Driven型支援」を掲げ、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の実現に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。