Shopifyと基幹システムを連携する3つの方法と費用【CSV〜API】

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

これは「EC化したのに事務が減らない」という、最も残念な失敗の正体です。受注事務の人件費は1名あたり月25〜35万円が相場観。せっかくEC受注を自動化しても、その注文を基幹へ手入力し直しているなら、削れたはずの工数がそのまま残ります。連携設計は地味な後工程に見えて、EC化の投資対効果が出るか出ないかを分ける本丸です。

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

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

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

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

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

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

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

段階3: API連携——リアルタイム化への投資

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

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

近年は、AIエージェントが複数の業務システムを横断して安全にデータをやり取りするための共通規格として「MCPサーバー」という選択肢も登場しています。API連携を自社専用に都度設計する前に、AI活用を前提にした接続の標準化という選択肢を知っておきたい場合はMCPサーバーとはで仕組みと開発の選び方を整理しています。

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

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

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

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

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

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

開発会社が言わない、基幹連携の3つの本音

見積もりを取る前に知っておくと、桁を見誤らずに済むことを正直に書きます。

• 最初からAPIのフル連携が正解とは限らない。受注量が多くリアルタイム性が必須なら合理的だが、多くの中小企業はまずCSV手動や半自動で運用を回し、データの形と業務ルールを固めてからAPIに進むほうが手戻りが少ない。段階1なら費用ほぼゼロで二重入力を消せる
• 見積もりの幅を生むのはShopify側でなく基幹側。販売大臣・弥生販売・奉行などオンプレの基幹ソフトはAPIを持たないことが多く、その場合は中間の仕組みを別途作るため費用が跳ねる。「基幹ソフトの製品名・バージョン・外部連携の口の有無」を先に確認するだけで、見積もりの精度と金額が変わる
• 連携は作って終わりではない。RPAは基幹ソフトのバージョンアップで壊れ、APIもShopify側の仕様更新の影響を受け続ける。連携失敗の大半は技術ではなく「どのデータをどちらの系統を正とするか」の決め漏れで起きる。エラー時に誰が気づき誰が直すかを契約時に決めない発注は避ける

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

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

対策は反映を速くすることだけではありません。実在庫より少なく見せる「安全在庫バッファ」を積んでおけば、反映が遅れている間の注文超過を吸収できます。複数モールや実店舗もあわせて在庫を持つ会社では、チャネルをまたいだ在庫連携の設計そのものが論点になります。複数モールの在庫連携を自動化する方法で在庫マスタ統合の考え方を、欠品と表裏の関係にある過剰在庫の防ぎ方は在庫の予兆管理入門で扱っています。

awai Buildは、Shopify B2Bの構築とあわせて、CSV運用の設計から基幹APIの開発までを段階的に踏む連携設計を支援しています。料金は無料トライアルから始め、削減できる事務コストから逆算して提案する考え方です。連携で受注から請求までのデータが一本につながれば、awai Compassでその数字を経営の意思決定に使うところまで視野に入ります。二重入力の現状を持て余している方は、現状フローについて、無料相談（30分）にてご相談ください。

この論点の前段として基幹連携と二重入力問題、次の一手としてRAGで社内データをLLMにつなぐ方法も参考になります。