Shopify外部連携を失敗しない方法｜基幹・在庫・POS・会計の繋ぎ方と着手順

実店舗を開いた、モールにも出した、注文が右肩上がりに増えてきた——事業が伸びるほど、それまで手作業でこなせていた在庫合わせや受注処理に、少しずつ時間が削られていきます。Shopifyは標準機能と手動運用だけでも、日常のEC運営はかなりのところまで回せます。ただ販路や拠点、注文量が一定を超えると、基幹・在庫・POS・会計のどこかで「そろそろ外部連携が要るかもしれない」と感じる場面が訪れます。本記事では、その分岐点がどこにあるのかを4つの業務ごとに整理し、いつ・何を・どうつなぐかを、着手の順番まで含めて見ていきます。自社がいまどの段階にいるのかを確かめる地図として使ってください。

1.手動CSV・アプリ・API開発の3段階｜自由度とコストで選ぶ連携方式

手動運用は、在庫のズレや経理の転記が増えてくると限界が見えてきます。そのサインが出たら、次に考えるのが繋ぎ方です。方法は大きく3つあります。Shopifyのデータをファイルに書き出して手でやり取りする方法、アプリやOMSを導入する方法、APIで作り込む方法です。この3つをコスト・導入スピード・自由度・運用負荷の4軸で見比べると、自社に合う方式が浮かび上がります。

1-1. 手動CSV・アプリ／OMS・API開発｜それぞれの仕組みと境界線

3つの方式は、つきつめると既製品を設定して使うか、自分で作るかの違いです。手動CSVとアプリ／OMSは前者、API開発は後者にあたります。同じ「連携」でも、その仕組みを誰が用意して保守するのかが根本から変わります。

手動CSVは、Shopifyから注文や在庫のデータをファイルに書き出し、相手のシステムに取り込む方法です。特別な仕組みは要らず、人がファイルを動かします。

アプリ／OMSは、既製のサービスを契約し、設定の範囲内で使う方法です。両者を1つにまとめているのは、どちらも既製品を契約・設定して使う点が共通しているからです。違いは大きさにあります。単機能のアプリに対し、OMS（受注・在庫・出荷をまとめて管理するシステム）は複数の業務を一手に引き受けます。月数千円のアプリと、ネクストエンジンのようなOMS。規模こそ違っても、自分で開発しない点では同じグループに入ります。

API開発は、Shopifyのデータを読み書きするプログラムを自分で、または外注で作る方法です。ここで言うAPIとは、システム同士がデータをやり取りするための窓口のことです。ShopifyにはAdmin APIという窓口があり、ここを通じて注文・在庫・商品の情報を出し入れできます。あわせてWebhookという仕組みを使うと、注文が入った瞬間に外部システムへ自動で知らせることもできます。これらを組み合わせ、自社専用の処理を作り込むのがAPI開発です。

両者の境界線は、シンプルな問いで見分けられます。やりたいことが、アプリの設定画面のどこかに項目として存在するか。存在すれば、アプリやOMSの設定で足ります。存在しない独自の処理が必要になったとき、はじめてAPI開発が視野に入ります。OMSはこの境界の手前を広くカバーしてくれる存在で、たいていの定型業務はここで収まります。

つまり3つの方式は、横一列に並んだ別物ではなく、既製品をそのまま使う方式から、自分で作り込む方式へと段階的に変わる濃淡です。手動CSVとアプリ／OMSで対応できる範囲は思いのほか広く、API開発が要るのは、その既製品では届かない領域に踏み込むときです。

1-2. 手動・アプリ／OMS・API開発を4軸で比較する

4つの軸で並べると、コストと自由度が裏返しの関係にあると一目で分かります。安く手軽な方式ほどできることは狭く、自由度が高い方式ほど初期の負担は重い。ただし見落としやすいのが運用負荷の列です。ここを読み飛ばすと、「安いはず」の方式で消耗します。

比較軸	手動CSV	アプリ／OMS	API開発
コスト	初期ほぼ0／追加費用なし	月額制（数千円〜。受注件数や機能で増減）	開発費が高め＋保守費
導入スピード	即日〜	数日〜数週間	数週間〜数か月
自由度・カスタム性	低い（決まった項目のみ）	中（設定の範囲内で柔軟）	高い（独自処理も作り込める）
運用負荷	高い（人がやり続ける）	中（設定後は半自動）	中〜低（自動だが保守責任）

（アプリ／OMSのコスト目安の出典:ネクストエンジン（NE株式会社）料金ページ https://next-engine.net/price/ ／初期費用0円・月額基本料金3,000円〜、受注200件超は従量課金）

運用負荷の列を具体的に見てみます。手動CSVは初期費用こそゼロでも、誰かが毎回ファイルを書き出して取り込む手間がずっと残ります。月の件数が増えるほど、このタダに見えて人件費で払っている部分が膨らみます。

反対にAPI開発は、初期にまとまった費用と数か月の準備が要る代わりに、動き出せば運用の手はほとんどかかりません。ただし作った仕組みは自分たちで保守する責任がついてきます。アプリ／OMSが扱いやすいのは、初期費用と運用の手間の両方を、月額というならした形で引き受けてくれるからです。

表のどこか一列だけを見て決めると、判断を誤りやすくなります。初期費用の安さだけで手動を選ぶと運用で消耗し、自由度の高さだけでAPIを選ぶと保守を抱え込む。4つの軸を並べたうえで、自社がどこを優先するかで読み解くのが出発点です。

1-3. 連携方式の決め手｜頻度・カスタム要件・開発リソースで判断する

どの方式にするかは、値段から考えると外します。先に決まるのは、どれくらいの頻度で繋ぐか・標準やアプリの設定では届かない独自処理が要るか・社内に作って保守できる人がいるか、の3つ。この答えが、自然と方式を絞り込みます。

頻度

まず頻度です。1日に何度も在庫数や注文を合わせたいなら、人手では追いつかず自動連携が前提になります。反対に、月に数回まとめて在庫を更新する程度なら、手動CSVでも十分に回ります。

カスタム要件

次にカスタム要件。自社だけの受注フローや、基幹システム側の特殊な項目など、既製品では扱えない処理があるかどうかです。あれば、API開発が選択肢に入ります。

開発リソース

最後に開発リソース。APIは「作れるか」だけでなく「作ったあと維持できるか」が要点です。社内にエンジニアや保守を任せられる体制がなければ、せっかく作った仕組みも更新が止まり、いずれ動かなくなります。

この3つを当てはめてみると、進む方向が見えてきます。頻度は上がってきたが要件は標準やアプリの範囲で収まる——もしそう判断できるなら、まずアプリ／OMSで始め、どうしても届かない部分が出てきたときにAPIへ広げる。この順序なら、最初から重い開発を抱え込まずにすみ、手戻りも起きにくくなります。

方式は事業の段階で変わります。いまの頻度・要件・体制に見合うものを選び、足りなくなったら見直せば十分です。

2.基幹・在庫・POS・会計｜標準で足りる範囲と外部連携が要る分岐点

連携が要るかどうかは、業務のどこを見るかで答えが変わります。基幹・在庫・POS・会計の4つは、それぞれ標準で足りる時期と外部へ出す時期の境目が違うからです。ここではカテゴリごとに、その境目がどこにあるかと、超えたときに現れるサインを具体的に見ていきます。

2-1. 基幹｜受注・仕入の一元管理が要るのは卸・多事業に広がったとき

店舗が1つで、お客さま向けの販売だけなら、受注も仕入も標準の管理画面で足ります。基幹システムとの連携を考えるのは、卸の取引が増えたり、別事業を並行し始めたりして、Shopifyの外にも受注経路や仕入の流れが広がったときです。

単一店舗のBtoCなら、注文の確認も在庫の引き当ても管理画面で完結します。仕入も件数が落ち着いていれば手作業で追えます。Shopifyは2026年4月に卸（B2B）の基本機能を標準プラン（Basic・Grow・Advanced）へ追加費用なしで開放したため、小口の卸ならShopify内で始められるようになりました。ただし会社・ロケーション単位でカタログを直接割り当てる運用やカタログの無制限化はPlus限定で、標準プランでは全B2Bマーケット横断で最大3カタログまでです。

（出典:Shopify ヘルプセンター「プラン別の Shopify B2B 機能」 https://help.shopify.com/ja/manual/b2b/getting-started/plan-features）

ただし受注の経路がShopify以外にも増えると、話が変わります。電話やFAX、他モールからの注文を別々に管理すると、どこに何件あるかの全体像が見えなくなります。仕入と受注がつながっていないと、発注のタイミングもずれ始めます。

基幹連携を考えるサインは、この全体像が一望できなくなった感覚です。注文がどの経路で何件入ったかを集計するのに手間がかかる、仕入と販売の数字が別々の表に散らばっている。こうなってきたら、受注・仕入を1か所に集める仕組み（基幹システムやOMS）との連携が効いてきます。

卸を始めたからといって、すぐに連携が要るわけではありません。小口のうちは標準で粘り、注文経路と仕入の集計が手に負えなくなった頃にOMSや基幹システムを検討すれば、十分に間に合います。

2-2. 在庫｜モール併売で生じる売り越しを防ぐ

楽天に出した翌週、自社サイトでは在庫があるはずの商品が売り越した——モール併売を始めると、こうした在庫のズレが現れ始めます。在庫は売り場が1つなら標準＋手動で十分に回りますが、楽天・Amazon・Yahoo!のようなモールと併売すると、Shopifyはこれらと在庫を自動同期しないため、外部連携が要ります。

単一販路なら、注文が入れば在庫が自動で減り、ゼロになれば売り切れ表示に切り替わります。補充だけ手作業でも、件数が多くなければ問題なく回ります。

モール併売はこの前提を崩します。Shopifyとモールは在庫がつながっておらず、片方で売れても他方は減りません。手動で合わせていると、必ずどこかでズレが出ます。

このズレが表に出たものが売り越しです。在庫はあるはずなのに別の販路で先に売れていて、欠品のまま注文を受けてしまう。これが増えてきたら、在庫を自動同期するアプリ／OMSの出番です。ネクストエンジン・ロジクラ・StockSync・シッピーノなどが、複数販路の在庫を1つの数字に束ねます。注文量で見ると、Raboの実務上の目安では月500件あたりから手作業の在庫・出荷管理が苦しくなり始めます。

（出典:ネクストエンジン（NE株式会社）公式サイト（楽天市場・Amazon・Yahoo!ショッピング等の在庫を自動連携） https://next-engine.net/）

実店舗との併売は事情が違います。Shopify POSで売れば店頭の在庫がそのままECに反映されるため、ここは標準で完結します。

判断材料は、販路がオンラインで何面に広がったか。モールを1つ足すなら、その時点で自動同期をセットにしておくと、売り越しに後追いで対応せずにすみます。

2-3. POS｜Shopify POSは標準内、外部レジは連携が要る

実店舗とECの在庫・売上を1つにまとめたいなら、Shopify POSで標準の範囲に収まります。判断が要るのは、いま使っている外部レジを残す場合。その間をつなぐ連携が必要になります。

Shopify POSの基本機能（対面販売機能・POS Lite）は、すべての有料プランに追加料金なしで含まれます。店頭で売れた分がECの在庫にそのまま反映され、売上も同じ管理画面に集まります。実店舗とECを別々に数えなくてよくなるのが利点です。

（出典:Shopify ヘルプセンター「Shopify POSを始める」 https://help.shopify.com/ja/manual/sell-in-person/getting-started）

より進んだ機能はShopify POS Proの領分です。オンライン購入・店舗受取（BOPIS）、店舗からの出荷、スタッフごとの権限管理などはProに含まれ、ロケーションごとに月額13,000円（年払い）がかかります。

（出典:Shopify「POSシステムの料金」 https://www.shopify.com/jp/pos/pricing）

外部レジを使い続ける選択もあります。既存のレジ資産やオペレーションを変えたくない場合です。ただしその場合、店頭とECで在庫が別管理になり、放置すると同じ商品を二重に数えたり、店頭で欠品が出たりします。これを防ぐには、レジ側の売上と在庫をShopifyと突き合わせる連携が要ります。判断の軸は、レジをShopify POSに入れ替えるか、いまのレジを活かして連携するかの二択です。

店舗をこれから持つならShopify POSが入り口として素直で、すでに別のレジが回っているなら連携でつなぐ。どちらを選ぶかは、入れ替えのコストと現場への習熟度で決まります。

2-4. 会計｜注文が増えるほど効いてくる記帳の自動化

注文が月に数十件のうちは、会計は手動でも十分に回ります。連携が効いてくるのは件数が増えてから。記帳の手間と入力ミスが目に見えて減ります。

少ないうちは、Shopifyから注文データをCSVで書き出し、会計ソフトに手入力すれば足ります。月末の作業も短時間ですみます。

件数が増えると、この手入力が重くなります。売上・送料・決済手数料を一件ずつ転記していると、件数に比例してミスが増え、月末に数字が合わずに原因を探す時間も延びます。

この転記と突合の膨張が経理の手戻りです。ここで会計連携アプリが効きます。freeeは「かんたんfreee会計データ連携」で、売上・送料・割引・決済手数料・消費税をそれぞれ別の勘定科目に分けて自動記帳できます。ただし返品やキャンセルが発生した場合は、別途手作業での調整が必要になることがあります。

（出典:Shopify App Store「かんたんfreee会計データ連携」 https://apps.shopify.com/freee?locale=ja）

マネーフォワード クラウドはShopifyとの直接連携を終了しており、現在はCSV出力やサードパーティ製アプリを介して取り込む方法があります。

（出典:マネーフォワード クラウド会計サポート「『Shopify』とのデータ連携終了について」 https://biz.moneyforward.com/support/account/news/important/20230614.html）

まずは手入力で始めて構いません。月末の締めが半日仕事に変わってきたら、freeeなどの連携アプリに切り替えることで、その手間の多くが消えます。

3.連携を成功させる進め方｜着手順・並行運用・移行リスクの対処

どこを繋ぐか決まっても、繋ぎ方の順番を誤ると効果が出る前に疲れてしまいます。連携でつまずく原因の多くは、一度に全部実施しようとすること、またはベンダーに丸投げして中身を把握しないことのどちらかです。

3-1. 連携の着手順｜効果が見えやすい在庫・会計から始める

連携は在庫と会計から着手すると無理がありません。この2つは効果が数字に表れるのが早く、続ける手応えをつかみながら次へ広げられるからです。

在庫を先に繋ぐと、売り越しや欠品が減ったかどうかが、すぐ受注の現場で手応えとして表れます。会計を繋げば、月末の作業時間が短くなったことを翌月に実感できます。どちらも変化が数字に出るぶん、社内で連携の価値を共有しやすくなります。

発生頻度の低い処理や、まだ要件が固まっていない業務は、急いで繋がず後回しでかまいません。

進め方のポイントは、繋ぐ範囲を小さく区切って、1つずつ検証することです。在庫が正しく同期するか、会計の科目が想定通りに振り分けられるか。ここを確かめてから次に進めば、後からまとめてズレが見つかって全部やり直す、という事態を避けられます。

着手順に唯一の正解はありませんが、迷うなら効果の見えやすい在庫・会計が起点になります。小さく始めて確かめながら広げる順序が、現場の納得を得ながら連携を定着させる近道です。

3-2. 並行運用・移行・ベンダー撤退｜つまずきやすい点と備え

連携の失敗は、たいてい切り替え方と任せ方で起きます。旧来のやり方をいきなり止めること、ベンダーに丸投げして中身を把握しないこと。この2つを避けるだけで、つまずきの多くは防げます。

切り替えで効くのが並行運用です。新しい連携を動かし始めても、しばらくは従来の手作業も並走させ、両方の数字が一致するかを見比べます。問題がないと確認できてから、手作業を畳んでいきます。

移行のときに見落としやすいのが、最初のデータ合わせです。連携を始める時点での在庫数や顧客情報がずれていると、その誤差が後々まで尾を引きます。項目同士の対応づけ（どのデータをどこに渡すか）も、最初に確かめておく必要があります。

もう1つ、契約前に押さえておきたいのがベンダー撤退への備えです。使っているサービスが終了したり、乗り換えたくなったりしたとき、自社のデータを持ち出せるか。これを最初に確認しておかないと、いざというとき動けなくなります。あわせて、設定内容と運用の手順は社内に記録として残しておきます。担当者しか分からない状態だと、その人が抜けた瞬間に連携が止まります。

連携は入れて終わりではなく、長く回し続ける仕組みです。並行運用で安全に切り替え、データと要件を自社で把握し、撤退の道も確保しておく。この3つを備えておけば、連携を入れたあとに慌てる場面を大きく減らせます。

4.まとめ

Shopifyは標準機能と手動運用だけでも、日常のEC運営はかなりのところまで回せます。連携を考えるのは、その手作業が追いつかなくなったとき。在庫がズレて売り越しが出る、月末の経理で同じ数字を何度も触っている。そうしたサインが、繋ぎどきの合図です。

もう一点、見落とされがちな視点があります。連携の巧拙は、何を繋ぐかよりも何を繋がないかで決まります。仕組みは増やすほど、設定の手間も、不具合が起きたときの切り分けも、保守の対象も増えていきます。いま繋がなくても困らない領域をあえて手動のまま残す判断が、事業の身軽さを保つうえで効いてきます。全部を自動化した状態がゴールではありません。自社にとって必要なところだけを繋ぎ、残りは手動のまま残す。その線引きこそが、連携を長く続けられる運用体制を作ります。

自社の段階を確かめるなら、以下の3ステップで現状を確認できます。

1. 直近1〜3か月で「売り越し」と「経理の手戻り」が月に何回起きたかを書き出す（現状の数値化）
2. 起きていれば、まず在庫か会計のどちらか1領域に絞る（一度に全部やらない）
3. その領域で、連携の頻度・独自要件の有無・社内の保守体制の3点を確認し、手動CSV／アプリ・OMS／API開発のどれが見合うかを当てはめる

この3ステップを通すと、「いま繋ぐべきか」「繋ぐなら何から、どの方式で」が、自社の数字をもとに見えてきます。

着手順の判断にお困りの場合は、現状をお聞きした上で、着手順の整理をご支援いたします。

下記フォームからお問い合わせください。