ECサイトと基幹・在庫システムの連携開発【2026年】カートはSaaS、繋ぎ目は開発

執筆：Swooo編集部／監修：諸藤 哲耀（株式会社アイビス Swooo）

ECの売上が伸びるほど、現場の仕事は増えていきます。受注データをCSVでダウンロードして基幹システムに手入力する。モールと自社ECの在庫を毎朝手作業で合わせる。月末には会計ソフトと売上の突合に何日も費やす。カートシステム自体はSaaSで十分に戦える時代に、こうした「カートの外側」の作業が事業の成長を静かに圧迫しています。

本記事では、ECサイトと基幹システム・在庫管理・顧客データの連携開発について、発注者の視点で整理します。結論を先に書くと、カートはSaaSのままでいい。作り込むべきは、カートと社内システムを繋ぐ「繋ぎ目」です。どこをSaaSに任せ、どこに開発投資をすべきか、費用感と進め方まで具体的に解説します。

EC周辺システムの整理 早見表——SaaSに任せる領域と開発が効く領域

まず全体像から確認します。EC事業のシステムは「SaaSをそのまま使えば十分な領域」と「自社に合わせた連携開発が効く領域」に分かれます。この切り分けを持たずに検討を始めると、開発会社の得意分野に引きずられた提案をそのまま受け入れることになりがちです。

ポイントは、SaaSと開発を対立させないことです。カートSaaSは使い続ける前提で、SaaSがカバーしない自社固有の部分だけを開発で埋める。これがEC事業のシステム投資でもっとも費用対効果の高い考え方です。「SaaSかスクラッチか」の二択で悩む必要はなく、領域ごとに適した手段を選べばよいのです。以下、順に掘り下げます。

EC市場の現在地——伸びているのは売上だけではない

経済産業省の「令和6年度電子商取引に関する市場調査」によると、日本のBtoC-EC市場は26.1兆円で前年比プラス5.1%、BtoB-EC市場は514.4兆円で前年比プラス10.6%と、いずれも成長を続けています。

この数字が意味するのは、売上の伸びだけではありません。EC経由の取引が増えるということは、処理すべき受注件数・在庫変動・入金消込・問い合わせが同じペースで増えるということです。

しかも近年は、販売チャネルそのものが増えています。自社ECに加えて複数のモールへ出店し、SNS経由の販売や実店舗との併売まで含めると、1つの商品の在庫と売上が複数のシステムにまたがるのが当たり前になりました（自社EC＋モール2〜3つ＋実店舗、という構成も珍しくありません）。チャネルが1つ増えるたびに、受注形式・手数料体系・在庫の持ち方がそれぞれ異なる管理対象が増える。つまり売上の成長は足し算でも、管理の複雑さは掛け算で増えていくのです。

BtoB-ECが前年比2桁の伸びを示していることも見逃せません。企業間の受発注がECに移るということは、発注側・受注側の双方で「Webの注文データを社内の基幹システムへどう流し込むか」という連携の課題が生まれるということです。BtoCに限らず、EC化の進展はそのまま連携開発の需要増を意味します。

売上が2倍になったとき、受注処理の手作業も2倍にできる会社はほとんどありません。人を増やせば人件費と教育コストが増え、増やさなければ出荷遅延や在庫ずれ、計上ミスといった形で品質が落ちます。ECの成長期に多くの企業がぶつかる壁は、集客でも商品力でもなく、バックオフィスの処理能力です。

だからこそ、EC事業のシステム投資は「売場を良くする投資」と「裏側の処理を自動化する投資」を分けて考える必要があります。前者はカートSaaSの機能改善が担ってくれますが、後者は自社の業務に合わせた連携開発でしか解決しないケースが多いのです。

カート自体を自社開発しない方がいい理由

連携開発の話に入る前に、正直に書いておきたいことがあります。カートシステム自体をゼロから開発することは、ほとんどの企業にとって合理的ではありません。

理由はシンプルで、カートSaaSが背負ってくれているものが大きすぎるからです。

• セキュリティ対応：クレジットカード情報の非保持化、脆弱性対応、不正注文対策。攻撃手法は日々変わり、専任チームによる継続的な対応が前提になる
• 決済手段の追加・維持：各種キャッシュレス決済、後払い、ID決済。決済各社との接続と仕様変更への追随をSaaSがまとめて引き受けてくれる
• 法令対応：特定商取引法の表示義務、消費税率やインボイスへの対応など、制度変更のたびに必要な改修がSaaSの標準アップデートに含まれる
• 売場機能の進化：クーポン、レビュー、定期購入といった販促機能が、多数の導入企業からの要望を受けて磨かれ続ける

これらを自社開発で維持しようとすると、開発費よりも維持費が問題になります。1社のためだけにセキュリティと法令対応を続けるコストは、多数の企業で分担しているSaaSに勝てません。カートを独自開発した場合、リリースした瞬間から「決済会社の仕様変更に追随し続ける義務」と「攻撃者に狙われ続ける前提の運用」を自社で抱えることになります。

例外があるとすれば、売場の仕組みそのものが事業の差別化になっている一部の大規模事業者だけです。それでも、決済やセキュリティ基盤は外部サービスを組み合わせる構成が一般的で、「全部を自前で持つ」選択はまず出てきません。

「カートも含めて全部作り替えましょう」という提案は、多くの場合コストに見合いません。カートはSaaSに任せ、開発の投資はSaaSが届かない領域に集中させる。この切り分けができているかどうかが、EC事業のシステム投資の成否を分けます。

SaaSカートの「外側」で起きる4つの問題

では、SaaSカートを使っていても解決しない問題とは何か。EC事業の現場で実際に起きやすいのは、次の4つです。

問題1：受注データと基幹・会計の手作業突合

カートには受注データが溜まりますが、それを基幹システムの売上計上や在庫引当、会計ソフトの仕訳に反映する部分は、カートSaaSの守備範囲外です。

結果として、多くの現場では「カートからCSVを落とす→Excelで加工する→基幹に取り込む（または手入力する）」という運用が生まれます。
受注件数が少ないうちは回りますが、件数が増えるほど作業時間とミスが増え、月次決算の締めが遅れる原因にもなります。キャンセルや返品、同梱・分割配送といった例外処理が入ると、突合の難易度はさらに上がります。

会計側の処理も単純ではありません。モールごとに異なる販売手数料、ポイント値引きやクーポンの扱い、決済代行会社からの入金と売上の消込。これらを商品単位・チャネル単位で正しく仕訳に落とすルールは会社ごとに違うため、汎用の連携機能では吸収しきれず、Excel職人の属人的なノウハウに依存しがちです。その担当者が休むと締めが止まるという状態は、連携開発で解消すべき典型的なサインです。

問題2：複数チャネルの在庫同期

自社ECに加えてモールにも出店すると、在庫の管理は一気に難しくなります。どこかのチャネルで売れたら、他のチャネルの在庫数も即座に減らさないと、在庫切れ商品を売ってしまう「売り越し」が起きます。

売り越しはキャンセル対応の手間だけでなく、モールの評価低下や顧客の信頼喪失に直結します。逆に売り越しを恐れてチャネルごとに在庫を分けて持つと、今度は機会損失と過剰在庫が生まれます。
在庫連携SaaSも存在しますが、セット商品や予約販売、店舗在庫との併用など、自社の在庫の持ち方が複雑になるほど既製の同期機能では粒度が合わなくなり、連携の作り込みが必要になります。

在庫同期の設計で重要なのは、同期の間隔と在庫の持ち方をセットで決めることです。たとえば「同期は数分間隔で十分だが、残り僅かな商品だけは安全在庫を差し引いて各チャネルに公開する」といったルールは、自社の商品特性と販売ペースからしか導けません。ここが、既製品の設定画面では表現しきれない部分です。

問題3：出荷・物流との連携

受注から出荷までの流れも、繋ぎ目の多い領域です。倉庫管理システム（WMS）や物流会社への出荷指示、送り状番号の取り込み、出荷完了メールの送信。この一連の流れのどこかに手作業が挟まると、出荷リードタイムが延び、繁忙期に出荷が詰まります。

倉庫側のシステムと自社の出荷ルール（ギフト対応、同梱物の出し分け、温度帯別の出荷など）が完全に一致することは稀で、そのずれを埋める変換処理が連携開発の主な仕事になります。物流会社やWMSは既製の連携メニューを用意していることが多いため、この領域は「既製連携を土台に、自社ルールとの差分だけを開発で埋める」構成が費用対効果の面で有利です。

問題4：顧客データが分断され、CRMが機能しない

自社ECの会員データ、モールの購入者データ、実店舗のポイント会員、メール配信ツールの登録者。これらが別々のシステムに散らばっていると、「この顧客はどのチャネルで何を買ってきた人か」が誰にも分かりません。

顧客データが分断されたままでは、リピート施策も優良顧客向けの体験設計も打ちようがなく、CRMツールを導入しても入れるデータが揃わないので機能しません。顧客IDを軸にしたデータ統合は、ツール導入ではなく連携設計の問題です。ここが、独自の会員体験を作りたい企業がまず向き合うべき繋ぎ目になります。

実務上の難所は名寄せです。メールアドレスや氏名だけで同一人物を突き合わせようとすると、表記ゆれや複数アドレスの利用で精度が上がりません。どのキーで顧客を一意に識別するか、統合後のIDをどのシステムが正とするかというID設計を最初に固めることが、CRM連携を機能させる前提条件になります。

連携開発の進め方と費用相場

では、こうした繋ぎ目の開発はどう進め、いくらかかるのか。

進め方の基本はAPI連携の設計

主要なカートSaaSやモール、会計SaaSの多くはAPI（外部システムからデータを読み書きする窓口）を公開しています。連携開発とは、このAPIを使って「カートの受注データを基幹の形式に変換して流し込む」「在庫変動を各チャネルに配信する」といった処理を自動化する仕事です。

進め方としては、最初に連携要件の整理を行います。どのシステムのどのデータを、どちら向きに、どのタイミング（即時か、1日1回か）で同期するのか。キャンセルや返品などの例外時にどう振る舞うのか。この設計が連携開発の品質をほぼ決めます。

要件が固まったら、変換ルールの設計（商品コードや顧客IDのマッピング）、実装、そして本番データを使った突合テストへ進みます。連携開発のテストは「正常に流れること」の確認だけでは不十分で、二重送信の防止、途中で失敗した場合の再実行、相手システムのメンテナンス時間帯の扱いまで検証して初めて、安心して任せられる仕組みになります。

なお、RPA（画面操作の自動化ツール）で管理画面の操作を記録して自動化する方法もあります。短期の暫定策としては有効ですが、SaaS側の画面デザインが変わると止まる、エラー時の検知や再実行が弱いという構造的な限界があります。取引量が増える前提なら、APIベースの連携を本命に据えるべきです。

費用相場の目安

EC関連のシステム開発費用は、開発手法によって大きく変わります。当社サイトで公開している相場では、EC系システムの開発はノーコード開発で150万〜500万円、フルスクラッチ開発で1,000万〜3,000万円が目安です。連携基盤や受注管理などの業務システム部分に絞れば、ノーコードで50万〜200万円程度から始められるケースもあります。

さらに、連携で溜まったデータをAIに活かす場合の相場は、LLMのAPIを活用した小規模な仕組み（問い合わせ対応の補助など）で50万〜300万円、自社データを組み込んだRAG構成や業務組み込みで100万〜1,000万円が目安です。

このほか、開発費とは別に見ておくべき費用が2つあります。1つは要件定義の費用で、一般に開発全体の10〜15%が目安です。連携開発では例外処理の洗い出しがそのまま品質に直結するため、ここを削るのはおすすめしません。もう1つは保守費用で、ノーコード開発なら月3万〜20万円、スクラッチ開発なら月10万〜100万円が相場です。連携は相手システムの仕様変更に追随し続ける必要があるため、作った後の保守体制まで含めて予算を組んでください。

見積もりが変動する主な要因は、繋ぐシステムの数、同期の方向（片方向か双方向か）、即時性の要求（リアルタイムか日次バッチか）、そして例外処理の複雑さです。相見積もりを取る際は、この4点の前提を揃えて依頼すると比較しやすくなります。

費用の内訳や見積もりの読み方はWebアプリ開発の費用相場の解説記事で詳しく整理しています。重要なのは、連携開発は「全部でいくら」ではなく、繋ぎ目ごとに区切って見積もれるという点です。だからこそ、次に述べる段階的な進め方が可能になります。

いきなり全部を繋がない——段階的な作り込みが正解

連携開発でよくある失敗は、最初から「基幹も在庫も物流もCRMも全部繋ぐ」構想で始めてしまうことです。対象が増えるほど要件定義が長期化し、どこか1つのシステムの仕様変更で全体が止まるリスクも増えます。

とくに注意したいのが、基幹システムの刷新と連携開発を同時に走らせるパターンです。繋ぎ先の仕様が固まらないまま連携を設計することになり、基幹側の遅延がそのまま連携側の手戻りになります。基幹刷新の予定があるなら、先に現行基幹との暫定連携で手作業を減らし、刷新後に繋ぎ替える二段構えの方が、総コストは高く見えても実際のリスクはずっと小さくなります。

おすすめするのは、手作業の負荷がもっとも大きい繋ぎ目から順に自動化していく進め方です。

• 第1段階：毎日発生していて件数が多い処理（例：受注データの基幹取り込み）を自動化する。効果がすぐ数字に出るため、投資判断もしやすい
• 第2段階：事故になると損失が大きい処理（例：チャネル間の在庫同期）を繋ぐ。売り越し・機会損失という明確なリスクを潰す
• 第3段階：将来の売上を作る基盤（例：顧客データの統合とCRM連携）に投資する。第1・第2段階で整えたデータがここで活きる

段階を分けるメリットは、リスクとキャッシュフローの管理だけではありません。第1段階を運用してみると、「実はこの例外処理が一番手間だった」という現場の実態が見えてきます。その学びを第2段階の設計に反映できるため、一括で作るより最終的な完成度が上がるのです。

また、各段階の起点では「この繋ぎ目は本当に開発が必要か、既製の連携SaaSで足りないか」を毎回問い直すことをおすすめします。既製品で済む繋ぎ目は既製品で済ませる。その判断を積み重ねることが、総投資額を抑えながら自社に合った仕組みを作る近道です。

連携開発の発注先の選び方

最後に、発注先の見極め方です。前提として知っておきたいのは、カート構築が得意な会社と、システム間連携が得意な会社は、必ずしも同じではないということです。カート構築はデザインや売場作りの比重が大きく、連携開発はデータ設計とAPI実装の比重が大きい、性質の異なる仕事だからです。

連携開発を任せる会社を選ぶ際は、次の観点を確認してください。

• 外部API連携の実装実績：意外に思われるかもしれませんが、外部API連携の実装力には開発会社によって大きな差があります。実際、EC以外の案件も含めた開発の引き継ぎ相談では、外部APIをそもそも扱えない業者に発注してしまっていたケースが見られます。過去にどのSaaS・どのAPIと繋いだ経験があるか、具体的に聞いてみてください
• エラーハンドリングの設計方針：連携は「正常に動くとき」より「相手システムが応答しないとき」の設計で差がつきます。タイムアウトの検知、失敗時の再実行、管理者への通知をどう設計するか、提案段階で説明を求めましょう
• データ量を踏まえた設計力：受注や在庫のデータは日々増え続けます。件数が10倍になっても処理が破綻しないか、DB設計とパフォーマンスの考え方を確認してください
• 業務フローへの理解：連携仕様は業務の理解から生まれます。要件を丸投げで受け取る会社より、受注から出荷・計上までの流れを一緒に図解しながら整理してくれる会社の方が、例外処理の漏れが少なくなります
• 納品後の保守体制とドキュメント：連携は納品された後も相手システムの仕様変更に追随し続ける必要があります。保守契約の内容と、連携仕様書・エラー時の対応手順書を納品物に含めてくれるかを事前に確認しましょう。ドキュメントがないと、将来別の会社に引き継ぐ選択肢が事実上失われます

すでに連携の仕組みを作ったものの、エラーが頻発している・処理が遅い・改修を断られたという状況であれば、開発レスキューの解説記事で立て直しの進め方を紹介しています。

また近年は、AIを開発工程に組み込むことで連携開発のスピードとコストが大きく変わりつつあります。データの変換ルールやテストコードの作成はAIとの相性が良く、同じ予算でカバーできる繋ぎ目の範囲が広がってきました。関心のある方はAI駆動開発の解説記事も参考にしてください。開発会社を比較する際に、AIをどう開発工程に取り入れているかを質問してみるのも、実装力を見極める材料になります。

ECと基幹システムの連携に関するよくある質問

今使っているカートSaaSを替えずに、連携部分だけ開発を頼めますか？

可能です。むしろそれが本記事のおすすめする形です。カートがAPIやCSV出力を備えていれば、カート自体には手を入れずに、基幹システムや在庫・会計との繋ぎ目だけを開発できます。まずは現在のカートで何のデータをどう取り出せるかの調査から始めます。カートの乗り換えは移行コストも顧客への影響も大きいため、連携で解決できる課題のためにカートを替えるのは基本的に順序が逆です。

連携開発の費用はどのくらいかかりますか？

繋ぐシステムの数と例外処理の複雑さで変わりますが、目安としてEC系システムの開発はノーコードで150万〜500万円、受注・在庫の管理基盤に絞ればノーコードで50万〜200万円程度からです。繋ぎ目ごとに区切って段階的に発注できるため、最初から大きな予算を確保する必要はありません。

RPAやExcelマクロによる自動化では不十分ですか？

短期の暫定策としては有効です。ただしRPAは画面操作に依存するため、SaaS側の画面変更で止まりやすく、エラー時の検知・再実行の仕組みも作り込みにくいのが弱点です。「止まったことに誰も気づかず、数日分の受注が未処理だった」という事態を防ぐ仕組みを別途用意する必要も出てきます。取引量が増える見込みがあるなら、APIベースの連携への移行を計画に入れておくことをおすすめします。

楽天やAmazonなどモールとの在庫連携もできますか？

各モールが公開しているAPIの範囲で連携を設計できます。ただしモールごとにAPIの仕様・更新頻度の制限・認証の仕組みが異なるため、どのチャネルをどの優先度で同期するかの要件整理が先になります。在庫連携SaaSと個別開発の併用が現実解になるケースもあります。

何から相談すればいいか分からないのですが、要件が固まっていなくても大丈夫ですか？

問題ありません。「受注処理に毎日何時間かかっている」「在庫ずれで月に何件かキャンセルが出ている」といった現状の困りごとが分かれば、どの繋ぎ目から着手すべきかは要件整理の過程で一緒に固められます。現状の業務フローが分かる資料（なければ口頭でも）があれば十分です。むしろ要件を固め切る前に相談した方が、開発ありきではない選択肢（既製SaaSで足りる部分の切り分けなど）も含めて検討できます。

まとめ：カートはSaaSのまま、繋ぎ目に投資する

本記事の要点を整理します。

• カート・決済はSaaSに任せるのが合理的。セキュリティ・決済・法令対応をSaaSが背負ってくれる
• EC市場の成長（BtoC 26.1兆円・BtoB 514.4兆円／経産省）はバックオフィスの負荷増でもあり、成長の壁は繋ぎ目の手作業に現れる
• 受注と基幹の突合・複数チャネルの在庫同期・物流連携・顧客データ統合は、SaaSの外側で起きる代表的な問題
• 連携開発は繋ぎ目ごとに区切って見積もれる。負荷の大きい繋ぎ目から段階的に進めるのが正解
• 発注先は、外部API連携の実装実績とエラーハンドリングの設計力で見極める

EC事業の成長を止めているのが集客ではなく裏側の手作業なら、次の投資先は売場ではなく繋ぎ目です。

Swoooは、東証グロース上場企業の株式会社アイビスが運営する開発チームです。累計50件以上の開発支援の実績があり、Bubble公式Goldパートナー（日本1位）として、ノーコードとAI駆動開発を組み合わせた費用対効果の高いシステム開発を提供しています。

「どの繋ぎ目から手を付けるべきか」「今のカートのままで何ができるか」といった段階からで構いません。連携要件の整理から一緒に進めますので、お問い合わせフォームからお気軽にご相談ください。