ECサイトとERPを正しく連携する方法：実践ガイド（2026年版）

つながっていないシステムが生み出す見えないコスト

月曜日の朝。週末に入った47件の受注がShopifyのダッシュボードに並んでいます。倉庫スタッフは出荷指示を待っています。経理担当者は先月の帳簿を締めなければなりません。そしてERP——弥生、freee、SAP、Odoo、どれであれ——は、その受注が存在することをまったく知りません。

誰かがExcelを開きます。

注文番号、顧客名、商品コード、数量、配送先住所を、ShopifyやBASEや楽天市場から手作業でERPに転記していきます。1行ずつ。1時間、あるいは2時間かけて。そのどこかで、商品コードが1桁ずれ、数量が重複し、あるいは同じ注文が2回入力されます。

水曜日には在庫数が実態と合わなくなっています。金曜日には顧客から「商品はどこですか」という問い合わせが来ます。月末には、経理担当者が一致しない数字を突き合わせながら、誰も原因を説明できない状態に陥っています。

これが「連携の罠」です。成長中のECビジネスが毎年、気づかないうちに何千時間、何百万円もの損失を出している原因です。手作業による転記ミス、在庫の不一致、財務情報の遅延という形で。

朗報があります。ECプラットフォームとERPの連携は、すでに解決策が確立された問題です。自社に合った方法を正しく選べるかどうか、それだけの話です。

3つの連携アプローチ——それぞれの使いどころ

すべてのビジネスに通用する唯一の正解はありません。最適なアプローチは、月間受注件数、ERPの外部接続への対応度、チームの技術的なキャパシティ、そして業務ロジックの複雑さによって変わります。

1. 標準コネクタ（Native Connectors）

主要なECプラットフォームとERPの多くは、あらかじめ用意されたコネクタやアプリを提供しています。ShopifyにはNetSuiteやSAP向けのコネクタがあり、WooCommerceにはOdoo向けのプラグインがあります。弥生やfreeeも、一部のECプラットフォームとの連携機能を持っています。

向いているケース： 標準的な業務フローを持つ中小規模のビジネス。受注の複雑さが低く、カスタマイズ要件が少ない場合。

メリット： セットアップが数日で完了します。初期コストが低い。ベンダーがメンテナンスを担当します。

デメリット： 提供されている機能の範囲内でしか使えません。フィールドのマッピングは固定的なことが多く、柔軟性に欠けます。業務ロジックがコネクタの想定と異なる場合——これは必ず起こります——すぐに限界に達します。複数倉庫、複数通貨、消費税の区分（軽減税率対応など）が絡む場合は特に問題が起きやすいです。

結論： 月間受注が500件以下でデータがシンプルな段階では有効です。ただし、ビジネスの成長とともにすぐに限界を迎えることを想定しておきましょう。

2. ミドルウェアプラットフォーム

Make（旧Integromat）、n8n、Zapierといったツールは、2つのシステムの間に位置するワークフロー自動化の層として機能します。トリガー（「Shopifyで受注が発生したとき」）とアクション（「freeeに売上を記録する」）を定義すれば、ミドルウェアがデータの転送を担います。

向いているケース： コードをすべて自分で書かずに柔軟性を持たせたいチーム。中程度の複雑さを持つビジネスで、開発者でない担当者がワークフローを管理できる環境。

メリット： フルカスタム開発より速く実装できます。ビジュアルなワークフロービルダーがあり、エンジニアでなくても操作できます。本格的な開発に踏み切る前に連携ロジックを検証するのにも適しています。

デメリット： コストは処理件数に比例して増加します（多くのミドルウェアはオペレーション単位で課金します）。リアルタイム同期には制限があり、多くのミドルウェアはスケジュールに従ってデータをポーリングします（5〜15分ごと）。タイムセールやキャンペーン時に在庫の不整合が生じる可能性があります。エラーハンドリングとリトライのロジックが浅いことが多いです。

結論： 月間受注が500〜5,000件の規模では妥当な選択肢です。スケールするにつれてオペレーションあたりのコストに注意が必要です。

3. カスタムAPI連携

連携を自分たちで構築するか、開発チームに依頼します。ECプラットフォームはRESTまたはGraphQL APIを公開しており、ERPはAPIやファイルインポート、データベース直接接続でデータを受け付けます。2つのシステム間でデータを変換・ルーティングするミドルウェア層を、自社の業務ロジックに合わせて構築します。

向いているケース： 複雑な要件を持つビジネス——複数倉庫の在庫管理、カスタム価格ルール、消費税の複数区分対応、大量受注のタイムセール、タイムリーな財務情報の取得が必要なケース。

メリット： フィールドマッピング、業務ロジック、エラーハンドリング、リトライ戦略をすべて自分たちでコントロールできます。イベント駆動によるリアルタイム同期が実現できます。受注量に応じてクリーンにスケールします。

デメリット： 初期の開発投資が必要です。メンテナンスは自分たちの責任になります。いずれかのシステムのAPIが変更された場合——これは起こり得ます——連携の更新が必要です。

結論： 月間受注が5,000件を超えるビジネス、または消費税対応や請求書要件など、標準コネクタでは対応できないコンプライアンス要件を持つビジネスに適した選択です。

同期すべきデータと、しなくていいデータ

最もよく見るミスの一つは、すべてを同期しようとすることです。すべてのフィールド、すべてのレコード、すべてのイベント。これは競合を生み、ERPをノイズで埋め尽くし、デバッグを悪夢にします。

EC/ERP連携で実際に必要なデータの流れはこれだけです。

EC → ERP（ストアからの送信）

受注データ： 注文番号、明細（商品コード、数量、単価）、割引、配送方法と送料、請求先・配送先住所、支払いステータス、販売チャネル（Web、モール、POSなど）
顧客情報： B2B ECの場合、得意先コード、与信条件、価格区分はERPに持つべきです。B2Cの場合は顧客ID＋メールアドレス程度の参照情報で十分なことがほとんどです。
返品・返金： 返品申請（RMA）情報、返金額、在庫戻し指示

ERP → EC（ストアへの受信）

在庫数： 倉庫ごと・SKUごとの手持ち在庫。これが最も重要で、最もリアルタイム性が求められる同期です。在庫情報が古いと過剰販売につながります。
商品・価格の更新： ERPが価格の管理元（B2BやWholesaleでよくあるケース）の場合、価格変更はストア側に反映される必要があります。
出荷ステータス： 出荷確定、追跡番号、部分出荷イベント

通常は同期不要なもの

会計仕訳の生データ（ERPが受注データから自動生成します）
顧客対応メモやCRM履歴（ヘルプデスク・CRM側に置くべきものです）
マーケティングデータ——メール開封率、流入経路、セグメント情報はマーケティングスタックに属します

日本のEC事業者が特に注意すべきポイント

日本市場固有の商慣習や法的要件が、EC/ERP連携の設計に大きく影響します。標準的なグローバルコネクタではカバーしきれない部分です。

適格請求書（インボイス）への対応： 2023年10月に開始されたインボイス制度（適格請求書等保存方式）により、課税事業者は適格請求書発行事業者として登録した番号を請求書に記載する義務があります。EC/ERP連携においては、受注データから適格請求書を自動生成し、登録番号・税率区分・消費税額（10%・軽減税率8%の別）を正確に記録するフローが必要です。

コンビニ払い・銀行振込への対応： 日本のECでは、注文時点と入金時点が大きくずれることがあります。コンビニ払いや銀行振込を選択した顧客は、注文後に別途入金します。ERPへの売上計上タイミングを「入金確認後」に設定するか、売掛として管理するかを、integration設計の段階で明確に決めておく必要があります。

複数モールの統合： 楽天市場、Amazon.co.jp、Yahoo!ショッピング、BASE、自社サイトと複数チャネルで販売している場合、各モールの注文データフォーマットは異なります。integration層でこれらをERPの統一スキーマに正規化する処理が必要です。楽天の受注CSVとShopify APIでは構造がまったく異なります。

弥生・freeeの特性： クラウド会計の弥生やfreeeはAPIを公開していますが、仕訳の登録ルール（借方・貸方の科目体系）や請求書番号の採番ルールは製品ごとに異なります。連携前に各製品のAPIドキュメントを精読し、自社の勘定科目体系との対応を確認することを強く推奨します。

実践的な連携アーキテクチャ

最も堅牢なEC/ERP連携は、定期的なポーリングではなく、イベント駆動型のパターンに従います。

flowchart TD
    EC["🛒 ECプラットフォーム\nShopify / BASE / 楽天市場 / Amazon.co.jp / 自社サイト"]
    MQ["📨 メッセージキュー / バス\nRabbitMQ · AWS SQS · Google Pub/Sub\n\n• 送信側と受信側を分離\n• タイムセール時の急増を吸収\n• 失敗時のデータロスなしでリトライ"]
    WO["⚙️ 連携ワーカー\n受注同期\n\n受注データをERPスキーマに変換\nAPIを通じてERPに売上を登録"]
    WI["⚙️ 連携ワーカー\n在庫同期\n\nERPのAPIをN分ごとにポーリング\nまたはERPからの在庫イベントを受信\n→ ECのAPIに在庫数をプッシュ"]
    ERP["🗄️ ERP\n弥生 · freee · SAP · NetSuite · Odoo"]

    EC -->|"Webhooks\norder.created / order.updated / refund.created"| MQ
    MQ --> WO
    MQ --> WI
    WO -->|"APIで売上登録"| ERP
    WI -->|"在庫数を取得"| ERP
    ERP -->|"在庫更新"| WI
    WI -->|"在庫数をECのAPIにプッシュ"| EC

メッセージキューが重要な理由

受注が発生した瞬間、Webhookが送信されます。キューがなければ、連携ワーカーはそのWebhookを受け取り、今すぐERPに書き込もうとします。ERPが応答遅延、メンテナンス中、またはAPIのレート制限に達していた場合、そのイベントは消えてしまいます。

メッセージキューは2つのシステムを切り離します。WebhookのペイロードはキューにLandingし、ワーカーはERPの準備ができたときに処理します。書き込みが失敗しても、メッセージはキューに残り、指数バックオフで自動リトライされます。タイムセールで10分間に300件の受注が集中しても、キューがスパイクを吸収し、ERPのAPIレート制限を超えることを防ぎます。

在庫同期：イベント駆動型 vs. ポーリング

在庫同期は、このアーキテクチャの中で最も難しい部分です。2つの選択肢があります。

ポーリング： 連携ワーカーがERPの在庫APIをスケジュールに従って呼び出し（5〜15分ごと）、更新された在庫数をECプラットフォームに反映します。実装はシンプルです。欠点は同期の間隔があることで、最終ポーリングから3分後に在庫が切れた場合、最大15分間は過剰販売が発生し得ます。

イベント駆動型： ERPが在庫変更時にイベントを送信し、連携ワーカーがすぐに処理します。同期の精度はずっと高くなります。ただし、ERPがアウトバウンドのWebhookやChange Data Captureをサポートしている必要があります。特にオンプレミスのERPでは対応していないケースがあります。

実際の運用では： 多くのビジネスが両方を組み合わせています。在庫切れや入荷確定などのクリティカルな在庫変更にはイベント駆動を使い、見逃しのセーフティネットとしてポーリングを併用します。

よくある失敗と、その防ぎ方

よく設計された連携でも、予測可能な形で失敗することがあります。私たちが最もよく目にするケースを挙げます。

重複レコード

原因： Webhookが送信され、ワーカーがERPに売上を作成しました。その後、タイムアウトによってWebhookが再送されます。ERPに同一の受注が2件登録されてしまいます。

対策： 連携を冪等（べきとう）にします。すべての受注イベントは一意の外部ID（ECプラットフォームの注文番号）を持ちます。ERPにレコードを作成する前に、その外部IDを持つレコードがすでに存在するか確認します。存在する場合はスキップするか更新します。決して重複作成しません。

消費税の計算不一致

原因： ECプラットフォームが税込価格で商品を管理しているのに、ERPは税抜価格＋消費税額を別々に必要とする場合があります。変換処理なしでそのまま送ると、全受注の消費税分だけ売上が過剰計上されます。

対策： コードを1行も書く前にデータコントラクトを定義します。各フィールドの管理元システム、期待されるフォーマット、消費税の扱いを明文化します。変換ロジックは明示的に実装し、「システムがよしなにやってくれる」には依存しません。

APIレート制限

原因： 商品マスターの一括更新で2,000件のAPIコールが短時間にERPへ送信されます。500件目でERPが制限をかけ、残り1,500件がサイレントに失敗します。

対策： リクエストのバッチ処理（1回のコールで50件ずつ送信）、ERPの公表するレート制限を守るレート制限レイヤーの実装、そしてジッター付きの指数バックオフによるリトライを実装します。

ERPのフィールド定義変更

原因： ERPの管理者が受注登録フォームに必須フィールド（例：部門コード）を追加しました。画面から入力する場合はすでに入力されていますが、連携ワーカーはそれを知らないため、すべてのAPIによる受注登録がバリデーションエラーで失敗するようになります。

対策： ERPのスキーマを外部APIと同じように扱い、変更を変更管理プロセスの一部としてモニタリングします。連携の書き込みが失敗し始めたときのアラートを設定します。フィールドマッピングはハードコーディングせず、設定ファイルとして管理し、デプロイなしで更新できるようにします。

タイムゾーンと日付フォーマットの不整合

原因： ECプラットフォームがタイムスタンプをUTCで保存しているのに、ERP（特に日本のオンプレミスERPに多い）がタイムゾーン情報なしでローカル時刻（JST、UTC+9）を保存している場合、3月24日の22:00（UTC）の受注がERPでは3月25日の注文になります。日次売上レポートに誤差が生じます。

対策： 連携層ではすべてのタイムスタンプをUTCに正規化します。ローカル時刻への変換はエンドユーザーへの表示時のみ行います。

Simplicoのアプローチ

Simplicoでは、Shopify〜NetSuite、WooCommerce〜PEAK、カスタムストアフロント〜SAPまで、タイ・日本・東南アジアのクライアント向けに様々なスタックのEC/ERP連携を構築してきました。

私たちのプロセスには、一貫した原則があります。

データコントラクトから始める： コードを1行も書く前に、システム間を移動するすべてのフィールドをマッピングします。データの出所、各システムでのフィールド名、必要な変換処理、競合が発生した場合にどちらのシステムを優先するか。このドキュメントが連携のソース・オブ・トゥルースとなり、後のデバッグ作業を何週間分も節約します。

失敗を前提に設計する： ハッピーパスは簡単です。難しいのはエラーハンドリングです——繰り返し失敗するメッセージのデッドレターキュー、エラーレートが急上昇したときのアラート、何が同期されていて何が止まっているかをオペレーションチームが把握できるダッシュボード。

段階的にロールアウトする： ゼロから一気に本番同期へ切り替えることはほぼしません。まず読み取り専用の同期から始め、ステージングのERP環境でデータを検証し、次に書き込みを段階的に有効化します——1つの受注タイプ、1つの倉庫、1つの通貨ずつ。

今あるERPで設計する： オンプレミスのレガシーERPは、多くの企業にとって現実です。クリーンなREST APIを持たないERPも少なくありません。フラットファイルのインポート、SFTPでの連携、あるいはデータベースの直接連携が必要なケースもあります。ERPの全面入れ替えを前提条件とせず、現状のシステムに合わせて設計します。

自社のスタックと要件に合った連携アプローチを一緒に検討したい方は、お気軽にご相談ください。Simplicoに問い合わせる →

まとめ

ECプラットフォームとERPの連携は、華やかな作業ではありません。バイラルになるデモも、AI魔法も、「5分でデプロイ」という本番で通用する約束もありません。しかし、成長中のECビジネスにとって、投資対効果の最も高いエンジニアリング投資の一つです。チームが手作業の転記に費やす時間は、ビジネスを成長させる本来の仕事に充てられるはずの時間だからです。

主要な判断は難しくありません。

規模が小さく、業務フローが標準的であれば、まず標準コネクタから始めましょう。
フルカスタム開発なしで柔軟性が必要であれば、ミドルウェアプラットフォームが現実的な選択肢です。
複雑な業務ロジック、大量受注、インボイス対応や複数税率対応などのコンプライアンス要件がある場合は、メッセージキューと冪等な書き込みを備えたイベント駆動型のカスタム連携に投資しましょう。

どのアプローチを選ぶにせよ、コードを書く前にデータコントラクトを正しく定義することを必ず守ってください。それ以降のすべてが、確実に楽になります。

Simplicoはバンコクを拠点とするソフトウェアエンジニアリング＆プロダクトスタジオです。AI/RAGアプリケーション、ECシステム連携、ERPとのシステム統合、モバイル開発を専門とし、タイ・日本・東南アジア市場向けのプロダクト開発を手がけています。詳しくは simplico.net をご覧ください。