EC-CUBEと基幹・在庫システムを連携する方法｜API・CSV・定期同期の選び方と設計ポイント

この記事でわかること
EC-CUBEと、基幹システムや在庫管理システムを連携したい——このとき、「API・CSV・定期同期のどれを選ぶか」で迷うことがあります。ただ、この選択は、方式そのものよりも、何を・いつ・どちら向きに同期するかという業務要件によって変わります。この記事では、連携方式を選ぶ考え方と、設計のポイントを、BtoB-ECの視点も交えて解説します。

この記事の位置づけ（APIの基礎を知りたい場合）

この記事は、EC-CUBEと基幹・在庫システムなどを連携する際の、方式選定と設計に絞って解説します。「そもそもEC-CUBEのAPIとは何か」「どんな外部サービスと連携できるのか」といったAPIの基礎については、EC-CUBE APIとは？特徴・メリット・利用方法で解説しています。あわせてご覧ください。

まず決めるのは「APIかCSVか」ではない

連携の相談で、いきなり「APIで連携したい」「CSVでいいですか」と、手段から入ることがあります。ただ、手段を先に決めると、後から要件と合わないことがあります。先に整理したいのは、次の3点です。

• 何を連携するのか（商品・在庫・価格・顧客・受注・出荷・請求など）
• いつ同期するのか（即時・定期・手動）
• どちら向きに連携するのか（EC→基幹、基幹→EC、双方向）

この3点が整理できると、適した手段が絞り込みやすくなります。手段は、要件を満たすための選択肢であって、目的ではありません。

連携対象を整理する

まず、何を連携するのかを洗い出します。データの種類によって、必要な頻度も方向も変わります。

すべてを同じ方式・同じ頻度で連携する必要はありません。データごとに、必要な頻度と方向を考えることが、過不足のない設計につながります。

同期タイミングを選ぶ

次に、それぞれのデータを「いつ」同期するかを考えます。タイミングは、大きく次の3つです。

• 即時：データが変わった時点で同期する。在庫のように、リアルタイム性が求められる場合に向く
• 定期：一定間隔（数分ごと・時間ごと・夜間など）で同期する。リアルタイム性が不要なデータに向く
• 手動：担当者が任意のタイミングで実行する。頻度が低い・確認を挟みたい場合に向く

ここで大切なのは、「即時＝API」「定期＝CSV」と決めつけないことです。APIを定期的に実行することもできますし、CSVファイルを自動生成・自動転送して定期同期することもできます。タイミング（いつ）と手段（何で）は、別々に考えられます。

連携手段を選ぶ

連携対象とタイミングが整理できたら、手段を選びます。EC-CUBEでの主な選択肢は、次のとおりです。

どれが優れているということではありません。基幹側がどんな連携の受け口を持っているか（APIがあるか、ファイル取り込みか）によっても、選択肢は変わります。基幹側の仕様を確認することが、手段選びの出発点になります。

Web APIを使う場合の設計ポイント

EC-CUBE4系でWeb APIを利用する場合、公式のWeb APIプラグインを利用する方法と、要件に応じて独自の連携処理を実装する方法があります。

EC-CUBEの公式Web APIプラグインは、GraphQLによるWeb APIを提供し、OAuth 2.0による認可、Query（取得）やMutation（更新）といった仕組みを持ちます。商品・受注・顧客の取得や、在庫・出荷ステータスの更新などが、公式の仕様として用意されています。標準の仕様で足りない場合は、要件に応じて、Web APIの拡張や、独自の連携処理を設計します。

API連携を設計する際に、確認しておきたいポイントは次のとおりです。

• 認証・認可：誰が・どの範囲にアクセスできるか
• 対象データと方向：何を取得し、何を更新するか
• エラー処理・再実行：通信が失敗したとき、どう検知し、どう再実行するか
• ログ：いつ・何を同期したかを記録し、追跡できるようにする

特に、エラー処理と再実行の設計は見落とされやすい部分です。連携は「正常に動くとき」だけでなく、「失敗したときにどうするか」まで設計しておくことが大切です。

CSV・ファイル連携を使う場合の設計ポイント

CSVなどのファイル連携は、古い方式というわけではありません。基幹側がファイル取り込みを標準で持ち、一定間隔の同期で業務上十分であれば、合理的な選択肢になることもあります。設計時に確認したいポイントは次のとおりです。

• ファイル形式・文字コード：項目の定義、区切り、エンコード
• コード体系：商品コード・取引先コードが、ECと基幹で揃っているか
• 取り込み順序：依存関係のあるデータの、処理する順番
• 再処理・重複：取り込みに失敗したときの再処理、二重取り込みの防止

ファイル連携は仕組みがシンプルな一方、コード体系や取り込み順序について確認しておきたい部分でもあります。この後で述べるマスタ整合とあわせて、設計しておくことが大切です。

基幹連携で早い段階に確認したい「マスタ整合」

API・CSVのどちらを選ぶ場合でも、基幹連携で早い段階に確認しておきたいのが、マスタ体系の整合です。商品コードや得意先コードなどのデータ定義の違いは、方式そのものより、連携時の問題の原因になることがあります。

• 商品コードが、ECと基幹で一致しているか
• 得意先コード・顧客コードが、対応づけられているか
• 受注ステータスなどの区分が、両システムで対応表として整理されているか

ECと基幹で、商品や取引先の管理方法が異なる場合は、変換ルールや例外処理を設計する必要があります。マスタ整合を後回しにすると、連携の実装が進んでから問題が発覚し、手戻りになることがあります。連携を検討する段階で、マスタの持ち方を確認しておくことをおすすめします。

BtoBで追加で確認したい論点

BtoB-ECでは、既存の販売管理・在庫管理・会計システムなどとの連携が必要になるケースがあります。BtoB特有の要素として、次のような点も、連携設計に関わってきます。

• 顧客別価格・契約価格を、どちらのシステムで管理し、どう連携するか
• 掛売・与信の情報を、基幹とどう連携するか
• 承認フローを経た受注を、どのタイミングで基幹に渡すか
• 得意先単位の取引条件を、どう反映するか

これらは、単なるデータ連携ではなく、業務ルールに関わる部分です。BtoBの連携設計は、業務の流れとあわせて考えることが大切です。BtoB固有の設計論点は、EC-CUBEでBtoBサイトを構築する際の注意点9選でも整理しています。

連携方式を選ぶときの比較軸

ここまでを踏まえ、連携方式を選ぶときの比較軸を整理します。「どちらが優れているか」ではなく、自社の要件でどう変わるかという視点で見てください。

これらを整理すると、API・CSV・外部サービス連携のどれが要件に合うかが見えてきます。多くの場合、答えは「どれか一つ」ではなく、データごとに使い分ける形になります。

まとめ

EC-CUBEと基幹・在庫システムを連携するとき、大切なのは「APIかCSVか」を先に決めることではありません。まず、何を・いつ・どちら向きに同期するかを整理し、そのうえで、基幹側の受け口や要件に合った手段を選ぶことです。そして、どの方式を選ぶ場合でも、マスタ体系の整合が、連携の成否に関わる重要な部分になります。

連携は、技術的な実装だけでなく、業務の流れと、既存システムの仕様を踏まえて設計することが大切です。私たちサンクユーは、業務内容と既存システムを伺ったうえで、連携方式の選定から設計・実装まで対応しています。基幹連携を検討されている方は、お気軽にご相談ください。