ERP、CRM、ECサイト連携アーキテクチャ：フロー別設計ガイド

このガイドは、ストア・ERP・CRMがすでに稼働しており、それらを一体として連携させる必要があるCTO、ITマネージャー、ECサイト担当者を対象としています。エンタープライズシステム統合ガイドでは、レコードオーナーシップ・統合パターン・障害対応設計の基本原則を説明しています。このページでは、それらをコマーストライアングルに適用し、フローごとに解説したうえで、トポロジーの選択とロールアウト計画で締めくくります。

このガイドの目次

• 3つのシステム、5つのフロー
• リファレンスアーキテクチャ
• 5つのフローの設計
• B2Bのルールが設計をどう変えるか？
• トポロジー：代替案と選択基準
• 統合レイヤーにおけるAI
• ロールアウト計画
• Netbaseの納品実績
• どのような納品実績があり、何がないか？
• このガイドの限界は何か？
• よくある質問
• 次のステップ

3つのシステム、5つのフロー

大半のコマース環境では、中心に同じ3つのシステムが存在します。ストアは販売と決済を担い、ERPは商品・在庫・価格・フルフィルメント用受注および帳簿を管理し、CRMは取引先・連絡先・見積もり・サービス履歴を保持します。その周辺には決済プロバイダー、倉庫またはキャリア、そして多くの場合PIMが配置されています。

このトライアングル内の統合作業のほぼすべては、次の5つのフローに集約されます：

このテーブルは、ツールを選定する前に自社の環境に合わせて作成してください。2つのシステムが同じ行のオーナーを主張する場合、オーナーを決めるのは統合担当者ではなくビジネス側です。1レコード1オーナーが重要な理由はピラーガイドで説明しています。このページの残りでは、オーナーが確定した後に各フローが必要とすることを説明します。

リファレンスアーキテクチャ

堅牢な設計は、どの製品が実装しても同じレイヤーを持ちます。

• システムごとのアダプター。各ストア・ERP・CRMは、そのシステムのAPIとデータモデルに対応する専用アダプターを持ちます。MicrosoftのArchitecture Centerはこれを腐敗防止レイヤー（Anti-Corruption Layer）と呼んでいます：あるシステムのセマンティクスが別のシステムに漏れ込まないようにするための変換レイヤーです。ERPが置き換えられる際は、そのアダプターだけを変更します。
• 1つの共有データモデル。アダプターは互いに直接変換するのではなく、商品・顧客・受注・請求書の正規モデルへと変換します。Enterprise Integration Patternsカタログが説明するように、共通フォーマットがあれば、新しいシステムを追加する際にパートナーごとに変換ペアを用意するのではなく、1つの変換ペアだけで済みます。
• 識別子クロスリファレンス。小さなストアが各レコードのキーを全システムで対応付けます（ストアの注文番号、ERPの販売注文、CRMのオポチュニティ）。名前やメールアドレスによる照合は行いません。
• 耐久性のあるイベント。変更はそれを行う同一のデータベーストランザクション内に記録されてから発行されます（トランザクショナルアウトボックスパターン）。これにより、クラッシュが発生してもERPが更新されてストアに通知されないという状態を防ぎます。
• マルチステップフローのオーケストレーション。受注から売掛金（Order-to-Cash）は4つのシステムにまたがります。1つのコンポーネントがシーケンスとその補償処理を担うため、ステップがwebhook全体に散在することはありません。
• 監視と照合。すべてのフローにダッシュボード、アラート、オーナーとコピー間のカウントと合計の日次比較があります。

各レイヤーの障害対応ルール（べき等性のある書き込み、バックオフ付きリトライ、デッドレターキュー）はピラーガイドに記載されており、変更なく適用されます。

5つのフローの設計

カタログと価格。変更をオーナーからイベントとしてプッシュし、夜間に完全比較を実行してください。価格のイベントが漏れた場合は遅延より悪い結果になるためです。ERPが請求しない価格をストアに表示しないよう、価格には有効期間を付けて発行します。

在庫。生の在庫数ではなく、在庫状況（手持ち在庫マイナス引当済みマイナス安全在庫）をチャネルごとに送信します。注文作成時に在庫を引き当て、キャンセル時に解放することで、2つのチャネルが最後の1個を二重販売することを防ぎます。

顧客とアカウント。B2BではCRMがアカウントと連絡先を通常オーナーとし、ERPが与信条件を管理します。ストアは両方を受け取り、新規Webユーザーはまずオーナーシステムで作成されてからコピーされるため、1人が3件のレコードになることはありません。

受注とステータス。ストアは支払い承認まで受注を管理し、以降はERPがフルフィルメントを担い、ステータス・出荷・追跡情報が返送されます。受注はストアからべき等キーを持ちます。RFC 9110がPOSTをべき等でないと定義しているため、再試行された作成が2番目の販売注文にならないようにする必要があります。

支払い・請求書・返金。決済プロバイダーがトランザクションを管理し、ERPが請求書とクレジットノートを管理し、CRMがアカウントチームに両方を表示します。入金済みの支払いを毎日請求書と照合し、返金はERPまたはそのAPIからのみ開始できるようにします。

B2Bのルールが設計をどう変えるか？

企業向けの販売には、消費者向けストアでは発生しないルールが追加され、それぞれがどこにロジックを置くかを決定します：

• 顧客固有の価格リストと契約価格はERPまたはCRMに置き、数千の商品バリアントとしてコピーするのではなく、アカウントごとに取得します。
• 与信限度額と支払い条件はチェックアウト時にERPに対して確認します。限度額を超えた受注は失敗するのではなく承認待ちになります。
• 見積もりはCRMで作成され、再入力なしに受注に変換され、ERP受注に見積もり参照が維持されます。
• 購買注文と承認はバイヤー側からのものを受注とともに保存し、請求書がバイヤーの経理チームの期待と一致するようにします。

トポロジー：代替案と選択基準

4つの基準で決定します：データとルールがどれほど標準的か、2年後に予想されるシステムとフローの数、誰がロジックを所有・変更しなければならないか、そして誰が夜間に運用するか。多くの環境はコネクターから始め、エラーハンドリングと可視性が限界に達したときにハブに移行します。統合ハブはそのステップの所有版です。マルチベンダーストアには出品者への支払いとベンダーカタログが追加されます。これらはマーケットプレイスプラットフォームアーキテクチャで説明しています。ストア自体が変更される予定であれば、まずカスタムECサイトプラットフォームガイドでそれを確定させてください。

Netbaseの納品実績

• リワードショッププラットフォーム（クライアント非公開）。ドバイを拠点とするロイヤルティ企業のために、Netbaseはヘッドレスのマルチストアプラットフォーム（Magento 2）をクライアントのポイントミドルウェア、受注サービス、商品カタログと接続しました。クライアントのシステムがポイントと受注のオーナーで、webhookが変更を伝達し、スケジュール同期がフェイルオーバーです。リワードショップの記録をご覧ください。
• 米国クライアント向けクラウドERP（非公開）。2020年からオフショア開発およびマネージングパートナーとして、Netbaseはテナントがすでに使用しているシステムへのCRMおよびAPI統合を最初のフェーズに含むマルチテナントクラウドERPを構築しています。クラウドERPの記録をご覧ください。
• Cloodo Workspace。NetbaseのビジネスDivisionで、CRM・HRM・クラウドERP・AIモジュールを1つの製品に統合したワークプレイスです。同期ではなく1つのシステムにレコードが存在します。Cloodoの記録をご覧ください。

Netbaseは、カタログ・在庫・受注・顧客のAPI同期を通じてクライアントのストアとERPを接続した実績もありますが、それらのクライアントは非公開です。

どのような納品実績があり、何がないか？

• あるもの。上記の記録はスコープと設計を説明しています：どのシステムが接続されたか、どのシステムがどのデータを所有するか、変更がどのように伝達されるか。Netbaseの製品化モジュールにはCRMとB2B営業エンジン、ワークフロー自動化ツールキット、Smart ERP Lightが含まれ、納品プラットフォームにはWooCommerce・Magento 2・Laravel・ヘッドレスコマースが含まれます。
• ないもの。これらの記録のいずれも、統合の期間・メッセージボリューム・エラー率・ビジネス上の成果を公開しておらず、数値の証拠として提示するものはありません。ERP統合のクライアントは非公開です。

このガイドの限界は何か？

• フローテーブルはB2CおよびB2Bコマースのデフォルトです；マーケットプレイス・サブスクリプション・製造業は独自のフローを追加します。
• パターンは公開されている説明から引用しています；適用することで、実際のデータに対するテストなしに統合が正しくなるわけではありません。
• 最小権限キー・転送中のTLS・保存時のAES・管理アクセスへのMFAなどのセキュリティ対策はリスクを軽減しますが、保証ではありません。

次のステップ

ストア・ERP・CRMの情報、最も頻繁に問題が発生するフロー、および締め切りをお知らせいただければ、ソリューションレビューを予約してオーナー・フロー・トポロジーをマッピングします。システムおよびAPI統合やERPおよびCRM開発、またはNetbaseのインサイトもご覧ください。

関連サービスとソリューション