EC構築で在庫連携が抜けていた失敗事例｜発注時に確認すべきだった項目 2026

2026年3月30日

長谷川奈津

この記事のポイント

✓EC構築在庫連携失敗で検索したあなたへ
✓在庫連携が抜けたまま公開してしまう典型事例と
✓発注時に確認すべきだった契約項目

先日、あるECサイトの店舗オーナーさんから相談を受けました。「制作会社にECサイトを作ってもらったのに、実店舗の在庫と連携していなくて、売り切れ商品が普通に注文できてしまう」と。結論から言うと、これは要件定義の段階で在庫連携の範囲が発注者と制作会社の間で共有されていなかったことが原因です。つまり、見積書に「在庫管理機能あり」と書いてあっても、それが実店舗のPOSシステムやモール型ECとリアルタイム連携するのか、それとも単にECサイト内だけの在庫カウントなのかで、意味がまったく違うんです。「ec構築在庫連携失敗」と検索してこのページにたどり着いたあなたは、おそらくすでに何らかのトラブルに直面しているか、これから外注する前に同じ失敗を避けたいと考えているはずです。この記事では、在庫連携が抜け落ちる典型パターンと、発注時に必ず確認すべきだった項目、そして費用相場まで、行政書士としてフリーランスや制作会社との契約トラブルを見てきた立場から整理していきます。

EC構築における在庫連携トラブルの実態

まず現状を俯瞰しておきましょう。経済産業省の電子商取引に関する市場調査によれば、日本国内のBtoC-EC市場規模は右肩上がりで拡大を続けており、中小企業や個人事業主による自社EC立ち上げも年々増えています。しかし市場が拡大するほど、システム構築を外部に依頼するケースも増え、要件定義の粗さに起因するトラブルの相談件数も比例して増加している印象があります。

ECで在庫を効率的に管理して機会ロスや過剰在庫のリスクを低減するためには、複数の販売チャネルの在庫情報を一元管理するために、リアルタイムの在庫連携が求められます。本記事では、自社ECに在庫連携機能を導入するための3つの方法を紹介します。出典: ebisumart.com

この引用にある通り、在庫連携は単なる「あれば便利な機能」ではなく、機会損失や過剰在庫という実際の金銭的損失に直結する仕組みです。にもかかわらず、私が相談を受けた案件の多くは、発注書や見積書に「在庫連携」という言葉こそあるものの、それが「どの範囲まで」「どのタイミングで」「どんな精度で」同期されるのかが明文化されていませんでした。つまり、言葉は共有されていても、認識は共有されていなかったわけです。

「これ、知らない人が本当に多いんです」。ECサイトの構築を依頼する側は、システムの内部構造まで理解している必要はありません。ただし、在庫連携という言葉が指す範囲を、発注書の段階で具体的に文章化しておく必要があります。この点を怠ると、納品後に「思っていたのと違う」というトラブルに発展しやすくなります。

在庫連携が抜け落ちる典型的な失敗パターン

失敗1：ECサイト内在庫と実店舗在庫の連携範囲を確認していなかった

最も多い失敗が、ECサイト単体の在庫カウント機能と、実店舗やバックヤードの在庫管理システムとの連携を混同するケースです。制作会社側は「ECサイト内で在庫数を管理できる機能」を作ります、と説明しているつもりでも、発注者は「実店舗の在庫がリアルタイムで反映される」と理解していることがあります。これは典型的な認識のズレです。

ECで在庫を効率的に管理して機会ロスや過剰在庫のリスクを低減するためには、複数の販売チャネルの在庫情報を一元管理するために、リアルタイムの在庫連携が求められます。出典: ebisumart.com

つまり、実店舗とEC、あるいは複数モール（Amazon、楽天市場、Yahoo!ショッピングなど）を横断して在庫を一元管理したいのであれば、その旨を要件定義書に明記し、どの在庫管理システムやAPIを介して連携するのかまで具体的に取り決めておく必要があります。「在庫連携」の一言で済ませず、「何と何を、どの頻度で、どちらが正として同期するのか」を文書化することが最初の防波堤になります。

失敗2：在庫の同期頻度（リアルタイムかバッチか）を確認していなかった

在庫連携には大きく分けて、注文が入るたびに即座に反映される「リアルタイム型」と、1日数回など決まった間隔で反映される「バッチ型」があります。この違いを知らずに発注すると、実際には1時間おきの同期しか実装されていなかった、というケースが起こります。1時間のタイムラグでも、人気商品であれば複数件の売り越し(オーバーセル)が発生し得ます。

セール期間中やSNSでバズった直後など、短時間で注文が集中する場面では、バッチ型の同期では対応しきれません。リアルタイム連携を希望するのであれば、見積もり段階で「リアルタイム同期が可能か」「対応できるシステム構成はどれか」を明確に質問し、回答を書面やメールで残しておくことをおすすめします。口頭でのやり取りだけだと、後から「言った言わない」の水掛け論になりがちです。

失敗3：複数モール展開時の在庫連携先を限定していなかった

自社ECだけでなく、Amazon、楽天市場、Yahoo!ショッピングなど複数モールに出品する事業者は少なくありません。この場合、在庫連携の対象を「自社ECのみ」なのか「全モール横断」なのかを最初に決めておかないと、後から追加費用が発生して見積もりが膨らむトラブルに発展します。

ほとんどのSaaS型在庫管理サービスには、Amazonや楽天市場、Yahoo!ショッピング、Qoo10などの大手ECモールとの在庫連携機能が用意されているので、低コストかつ短期間で在庫連携機能を実装できます。出典: ebisumart.com

この引用にあるように、既存のSaaS型在庫管理サービスを活用すれば低コストで実装できる場合も多くあります。ただし、それを制作会社が提案してくれるかどうかは会社次第です。発注者側から「複数モールを展開する予定があるので、SaaS型の在庫連携サービスとの接続実績があるか」を質問しておくことが重要です。

失敗4：在庫連携に必要なマスタデータの整備を後回しにしていた

在庫連携を実現するには、商品コード（SKU）や在庫管理番号を、ECサイト側と在庫管理システム側で統一しておく必要があります。ところが、実店舗の在庫管理台帳が手書きやExcelで、統一されたコード体系がない状態で構築を依頼してしまうと、連携そのものが技術的に困難になります。

商品点数が500点を超えるような事業者の場合、マスタデータの整備だけで数週間かかることも珍しくありません。この作業は制作会社側の担当範囲外とされることが多く、発注者自身が事前に準備しておく必要がある工程です。見積もり段階で「マスタデータの整備は誰が担当するのか」を明確にしておかないと、納期直前になって作業が滞る原因になります。

失敗5：在庫連携の保守・運用体制を契約に含めていなかった

在庫連携システムは、構築して終わりではありません。ECモール側のAPI仕様変更、在庫管理システムのバージョンアップ、決済システムとの連動など、継続的な保守が必要です。しかし発注時の契約が「構築一式」のみで、保守運用の条件が含まれていないケースが目立ちます。

構築後にAPI連携が突然止まってしまい、慌てて同じ制作会社に問い合わせたところ、「保守契約を結んでいないので追加費用がかかる」と言われるケースがあります。これは契約上、決して不当な請求ではありません。だからこそ、発注段階で「保守運用は月額いくらで、対応範囲はどこまでか」を確認し、契約書に落とし込んでおくことが自分を守る手段になります。

EC構築と在庫連携を外注する際の費用相場

在庫連携機能を含むEC構築を外注する場合の費用感を整理しておきます。あくまで目安ですが、案件の複雑さによって大きく変動します。

構築内容	費用相場	特徴
ASP型カート(在庫連携は簡易)	10万円〜30万円	低コストだが連携範囲は限定的
パッケージ型EC(在庫連携カスタマイズあり)	50万円〜200万円	実店舗POSやモール連携が可能
フルスクラッチ型EC(在庫連携含む基幹システム連携)	300万円〜	複雑な業務フローに対応
在庫連携保守運用(月額)	2万円〜10万円	API仕様変更対応や障害対応を含む

この相場を見て、「思ったより幅が広い」と感じた方も多いはずです。この幅は、在庫連携の範囲(自社ECのみか、複数モール横断か、実店舗POSまで含むか)によって大きく変わります。見積もり比較をする際は、金額だけでなく「その金額に何が含まれているのか」を項目ごとに突き合わせることが欠かせません。

ここで一つ、発注する側としての気付きを共有します。私自身、以前ある業務システムの構築を外注した際、複数社から見積もりを取ったものの、単純に総額の安さだけで比較してしまい、後になって「保守費用は別途」「在庫連携は追加オプション」という条件が抜けていたことに気づいた経験があります。安さだけで選ぶと、後から想定外の追加費用が発生するというのは、決して珍しい話ではありません。見積もりの内訳を項目単位で並べて比較し、「この金額に何が含まれ、何が含まれないか」を書面で確認する。この一手間が、後のトラブルを防ぐ最大の防御策になります。

在庫連携で失敗しない外注先の選び方

ポイント1：在庫連携の実装実績を具体的に確認する

「在庫連携システムの構築実績があります」という説明だけでは不十分です。どのモールと連携した実績があるか、どの在庫管理システム(SaaS型か自社開発か)と接続した経験があるかまで、具体的な事例を聞くことをおすすめします。実績のポートフォリオを見せてもらい、可能であれば導入企業に直接話を聞ける機会を作ってもらうのも有効です。

ポイント2：要件定義書を必ず作成してもらう

在庫連携を含むEC構築において、要件定義書の有無は品質を左右する最重要ポイントです。「何を、どこまで、どの頻度で連携するか」を文書化してもらい、双方で合意した上で契約を締結することが基本です。要件定義書がないまま「口頭の説明」だけで進めてしまうと、認識のズレが起きても検証する術がありません。

ポイント3：保守運用の条件を契約書に明記する

構築費用だけでなく、保守運用の費用体系(月額固定か、対応都度の従量課金か)、対応時間(平日日中のみか、休日夜間も含むか)、障害発生時の対応スピード(SLA)まで、契約書に落とし込んでおきましょう。「口頭では対応すると言っていたのに、実際は追加費用を請求された」というトラブルは、契約書に明記していないことが根本原因であるケースがほとんどです。

ポイント4：中間マージンの有無を確認する

制作会社によっては、実際の開発作業を別のフリーランスエンジニアや協力会社に再委託しているケースがあります。この場合、発注者が支払う金額には仲介手数料が上乗せされていることが少なくありません。フリーランスのエンジニアやシステム開発者に直接依頼できる体制があれば、中間マージンが発生しない分、同じ予算でより手厚い保守対応や追加機能の実装を依頼できる可能性があります。

「仲介会社を通すと安心感がある一方で、手数料が上乗せされる」という構造を理解した上で、直接依頼という選択肢も比較材料に入れておくことをおすすめします。特に在庫連携のような専門性の高い実装は、経験豊富な個人エンジニアが直接対応してくれるケースも多く、コミュニケーションが直接取れる分、認識のズレも起きにくいというメリットがあります。

在庫連携トラブルが起きた場合の法的な対応

万が一、発注した在庫連携機能に重大な不具合があり、契約通りの成果物が納品されなかった場合、どのような対応が可能でしょうか。基本的には、契約書に記載された「検収条件」に基づいて判断されます。検収条件が曖昧なまま契約している場合、「不具合があるので修正してほしい」という要求が通りにくくなることがあります。

つまり、契約段階で「検収の基準(何をもって完成とするか)」を明確にしておくことが、トラブル時の交渉材料になります。これは、フリーランス保護新法においても重要な考え方です。同法では、業務委託における発注書の交付義務や、給付内容の明確化が求められています。中小企業庁や公正取引委員会は、業務委託契約における適正な取引慣行の普及に取り組んでおり、発注書に業務内容を具体的に記載することの重要性を繰り返し発信しています。

※このケースでは、実際に契約書の内容や不具合の程度によって法的な結論が変わってくるため、深刻なトラブルに発展している場合は弁護士や行政書士に個別相談することをおすすめします。

在庫連携システムの導入で見落としがちな注意点

在庫連携の実装が完了した後も、油断はできません。ここでは実装後に見落としがちな注意点を整理します。

まず、在庫連携システムを導入した直後は、必ず一定期間のテスト運用を行うべきです。少量の注文でテストを行い、実際に在庫数が正しく反映されるか、複数チャネルで同時に注文が入った場合にどちらが優先されるかを確認しておく必要があります。テスト運用を省略していきなり本番稼働すると、初期不具合に気づかないまま在庫のズレが積み重なっていきます。

次に、季節商品やセール時など、通常時とは異なる在庫変動が起きる場面を想定したテストも重要です。通常の同期頻度では対応しきれない急激な注文増加が発生した場合、システムがどこまで耐えられるかを事前に確認しておくことで、繁忙期のトラブルを未然に防げます。

最後に、在庫連携システムの障害発生時の代替フロー(手動での在庫調整方法など)を、担当者間であらかじめ共有しておくことも欠かせません。システムはいつか必ず障害を起こします。そのときに慌てないための運用マニュアルを、構築段階から準備しておくことが、長期的な安定運用につながります。

よくある在庫連携システムの選び方

在庫連携を実現する方法は大きく3つに分けられます。1つ目はECカートシステム(ASPやパッケージ)に標準搭載された在庫連携機能を使う方法、2つ目はSaaS型の在庫管理サービスを間に挟んで複数チャネルを一元管理する方法、3つ目は自社の基幹システムと直接APIで連携するフルスクラッチ型の方法です。

事業規模や取扱商品数、展開しているチャネル数によって適した方法は異なります。小規模な事業者であれば、ASPカートの標準機能かSaaS型サービスの活用で十分対応できるケースが多く、初期費用を抑えられます。一方、複数の実店舗と大規模なEC展開を行う事業者であれば、基幹システムとの直接連携を視野に入れた設計が必要になります。

どの方法を選ぶにせよ、最初にやるべきことは「自社の在庫管理の現状を棚卸しする」ことです。現状の在庫管理がExcelなのか、専用システムなのか、POSレジと連動しているのかによって、実装できる連携方法の選択肢が変わってきます。この棚卸し作業を発注前に済ませておくことで、制作会社との打ち合わせもスムーズに進みます。

独自データ考察：直接依頼がもたらす在庫連携の実装品質

在宅ワーク・業務委託マッチングサービスを長年運営してきた立場から見えてくる傾向があります。それは、在庫連携のように専門性が高く、かつ継続的な保守が必要な業務ほど、単発の作業発注ではなく、特定のエンジニアと継続的な関係を築いた発注者の方が、結果的にトラブルが少ないという実感です。

20年この市場を見てきた立場から言えば、長く安定してシステムを運用できている発注者ほど、「この人に任せておけば安心」という信頼関係の構築に時間をかけています。単に安い見積もりを一度きり発注するのではなく、要件定義の段階から丁寧にコミュニケーションを取り、継続的に保守を依頼できる関係を作ることが、結果的にコスト面でも品質面でも有利に働くというのが、運営者として見てきた現場の実感です。

さらに、中間マージンが発生しない直接取引には、金額の安さ以上に大きな意味があります。同じ予算であっても、仲介会社を挟まない分、発注者はより手厚い保守対応や追加機能の実装を依頼でき、受け手であるエンジニア側も手取りが厚くなる分、長期的な関係構築へのモチベーションが高まります。手数料0%という条件は、単なる値引きではなく、双方が納得して長く付き合える関係を築くための土台になり得るというのが、この市場を運営してきた立場からの一次的な観察です。

在庫連携という専門性の高い実装だからこそ、発注者は「誰に頼むか」を慎重に見極める必要があります。実装実績、要件定義の丁寧さ、保守運用の条件、そして仲介の有無まで含めて比較検討することが、EC構築における在庫連携トラブルを未然に防ぐ最も確実な方法だと言えるでしょう。

在宅ワークの発注先を探す際には、専門性の高いエンジニアに直接依頼できる仕組みを活用するのも一つの選択肢です。例えばアプリケーション開発のお仕事では、EC構築や在庫連携システムの実装に対応できるエンジニアの依頼先を探すことができます。また、在庫連携のようなAPI連携やシステム統合を伴う案件では、AIコンサル・業務活用支援のお仕事のように業務フロー全体を見直す視点を持つ専門家に相談することも有効です。継続的な保守運用まで任せられる相手を探す際は、ソフトウェア作成者の年収・単価相場を参考に、依頼する業務内容に見合った予算感を事前に把握しておくと、見積もり比較の際の判断材料になります。