Shopifyと基幹システムを連携する方法と費用｜3つの方式

Shopifyで受けた注文を、担当者が販売管理システムにもう一度手で打ち直しています。EC経由の受注が増えた会社ほど、この二重入力が新しいボトルネックになります。受注は自動になったのに、その先の在庫引当・出荷指示・請求は基幹システムの中にあり、間を人がつないでいる状態です。

連携の方式は3段階あります。注文CSVを書き出して取り込む「CSV手動連携」は費用がほぼかからず、その作業をRPAやスクリプトで自動にする「半自動連携」、APIで注文や在庫をリアルタイムに流す「API連携」の順に費用が上がります。基幹ソフトが対応していれば、既製の連携アプリを月額で使う手もあります。各方式の費用の目安は後半の比較表にあります。

「EC化したのに事務が減らない」という状態の多くは、基幹への二重入力が原因です。再入力が1件5分でも、月1,000件なら約83時間になります。EC受注を自動化しても、その注文を基幹へ手入力し直しているなら、削れたはずの工数が残ります。連携設計は後工程に見えますが、EC化の投資対効果が出るかどうかはここで決まります。

中小企業の基幹側は、販売大臣・弥生販売・奉行シリーズといったオンプレミス（自社のPCやサーバーに入れて使う型）のソフトが今も現役です。クラウドで動くShopifyとは生まれた時代が違うため、「つなぐ」には設計が要ります。ただし最初から大がかりな開発が必要なわけではありません。連携には段階があり、費用も1桁ずつ違います。決めるのは「どの段階から始めるか」です。

段階1：CSV手動連携（費用ほぼゼロ、まずここから）

Shopifyの注文データはCSVで書き出せます。これを基幹側の取込形式に変換して読み込ませるのが第一段階です。変換用のExcelやスプレッドシートを1枚作れば、追加費用はほぼかかりません。1日1回、担当者が10分の作業で二重入力を消せるなら、出発点として十分な投資対効果があります。

弱点は、人がやることです。取込忘れ・列ズレ・文字コードの事故は起こりますし、担当者が休むと止まります。受注が1日数十件を超えるあたりから、次の段階を検討する意味が出てきます。

段階2：半自動連携（数十万円規模で「人が起動する」を消す）

第二段階は、CSVの書き出し・変換・取り込みを、RPA（PC操作を自動で再現するソフト）や定期実行のスクリプトで自動化する方法です。基幹ソフト側に手を入れないため、オンプレの販売大臣や弥生販売でも成立しやすい構成です。費用感は内容にもよりますが数十万円規模から検討でき、毎日の手作業と取込忘れが消えます。

留意点は、画面操作を前提にしたRPAは基幹ソフトのバージョンアップで壊れることがある点です。作った後も保守が要るため、誰が面倒を見るかという担当を発注時に決める必要があります。

第三段階が、ShopifyのAPI（システム同士が直接データをやり取りする窓口）を使った連携です。注文が入った瞬間に基幹へ流す、基幹の在庫をECの表示に反映する、得意先マスタを双方向で同期するといった、リアルタイム性の要る連携はこの段階になります。費用感は連携する項目数と基幹側の受け口の有無で大きく変わり、小さく作れば百万円前後から、在庫・出荷・請求まで含む本格構成では数百万円規模まで幅があります。

見積もりの幅を生む最大の要因は、Shopify側ではなく基幹側です。オンプレの基幹ソフトはAPIを持たないことが多く、その場合はデータベースや連携用ファイルを介する中間の仕組みを作ることになります。開発会社に相談する前に「基幹ソフトの製品名・バージョン・外部連携の口があるか」を情報システム担当か販売代理店に確認すると、見積もりの精度が一気に上がります。

近年は、AIと業務システムをつなぐ共通規格のMCP（Model Context Protocol）に沿って、基幹のデータをAIから読み書きできる「MCPサーバー」を用意する選択肢も出てきました。将来AIで受注や在庫を扱う予定があるなら、API連携を自社専用に設計する前にMCPサーバーとはで仕組みと開発の選び方を確かめてください。

第4の選択肢: 既製の「連携アプリ」を使う

CSV・半自動・APIの3段階は自社専用に作る場合の話でした。もう一つ、Shopifyアプリストアにあらかじめ用意された「連携アプリ」を使う方法があります。対応する基幹・在庫管理システムが決まっていれば、開発をせず月額の利用料で動かせる場合があり、対応済みの組み合わせなら半自動やAPIより早く動き始められます。

対応表に自社の基幹ソフトが載っていない、あるいは在庫引当や与信管理に独自ルールがあるなら、連携アプリは選択肢から外れます。最初に対応可否を確認し、載っていれば試す価値があります。

連携設計の中核は「どちらを正とするか」を決めること

連携の失敗の多くは、技術の問題より、データの主導権を決めていないことから起きます。着手前に、項目ごとに「どちらのシステムを正とするか」を1枚の表にしてください。ここが決まっていれば、方式がCSVでもAPIでも設計は成立します。

あわせて、同期の失敗をどう検知するかも決めます。件数の突合（ECの1日の注文件数と、基幹に取り込まれた件数が一致しているか）を毎日自動で確認すれば、連携事故の多くは翌日中に気づけます。この確認の担当者がいないまま運用を始めるのは避けます。

発注前に決めるべきは「どのデータを・どちら向きに・どの頻度で」

• 対象データ: 注文だけか、在庫・商品マスタ・得意先マスタ・請求まで含むか
• 方向: Shopifyから基幹への一方向か、在庫を戻す双方向か
• 頻度: 1日1回で足りる業務か、リアルタイムでないと困る業務か

この3点の答えで、必要な段階と費用感はほぼ決まります。逆にここが曖昧なまま「基幹と連携したい」とだけ伝えると、最大構成の見積もりが返ってきて話が止まります。全部をリアルタイムにする必要はありません。注文は自動、在庫は1日1回、請求は月次バッチというように、業務ごとに頻度を変えると費用対効果が高くなります。

見積もりの前に確認したい、基幹連携の3つの注意点

見積もりの桁を見誤らないために、次の3点を確認します。

• 最初からAPIのフル連携が正解とは限らない。受注量が多くリアルタイム性が必須なら合理的だが、多くの中小企業はCSV手動や半自動から始め、データの形と業務ルールを固めてからAPIに進むほうが手戻りが少ない。段階1なら費用ほぼゼロで二重入力を消せる
• 見積もりの幅を生むのはShopify側でなく基幹側。APIを持たないオンプレの基幹ソフトでは中間の仕組みを別途作るため、費用が上がる。段階3で挙げた製品名・バージョン・外部連携の口の有無を、見積もり依頼に添える
• 連携は作って終わりではない。RPAは基幹ソフトのバージョンアップで壊れ、APIもShopify側の仕様更新の影響を受け続ける。失敗の原因として多いのは、どのデータをどちらの系統で正とするかの決め漏れ。エラー時に誰が気づき誰が直すかを契約時に決めない発注は避ける

在庫データの二重販売リスクをどう防ぐか

どの方式を選んでも、受注から基幹への反映が完了するまでの間は、基幹側の在庫数が実態とズレます。この区間に同じ商品への注文が重なると、基幹の在庫は残っているのに実際は欠品という二重販売が起こります。CSV日次連携なら最大1日、半自動でも数分〜数時間、API連携でも通信のタイムラグはゼロにはなりません。

対策は2つあります。反映を速くすることと、実在庫より少なく見せる「安全在庫バッファ」を積むことです。バッファがあれば、反映が遅れている間の注文超過を吸収できます。複数モールや実店舗もあわせて在庫を持つ会社では、チャネルをまたいだ在庫連携の設計が論点になります。在庫マスタを統合する考え方は複数モールの在庫連携を自動化する方法に、バッファの量を決める安全在庫の計算式は欠品対策は予兆管理からにあります。

連携の設計は、EC構築の後に別プロジェクトとして扱われることの多い工程です。しかし二重入力が残ったままでは、EC化の投資対効果は出ません。受注から請求までのデータが一本につながると、その数字を経営の意思決定にも使えます。自社がどの段階から始めるかは、現行の業務フローと受注件数が分かれば判断できます。

連携の前に商品・得意先マスタをそろえる手順と費用対効果の計算はECと基幹システムを連携して二重入力をなくす方法で詳しく扱いました。つないだ受注・在庫データを社内のAI検索に使う段階では、RAGとはが役立ちます。

基幹ソフトの製品名・受注件数・現行の業務フローが分かれば、awai BuildがCSV・半自動・連携アプリ・APIのどこから始めるかを選び、Shopify側の構築と連携の実装、公開後の保守運用までを担当します。項目ごとにどちらを正とするかの表と、件数突合の仕組みも最初の設計に含めます。