ECシステムを会社に頼む前に｜一元管理ツールで足りない部分・受注と在庫と出荷の連携・費用【2026年10月】

この記事は、楽天・Amazon・Yahoo!ショッピングなどのモールと自社サイトで売っていて、一元管理ツールを入れたのにセット商品・予約販売・卸の掛け売り・倉庫への出荷指示で手作業が残っている運営責任者向けです。基本の順番は、一元管理ツールを残して設定と既製アプリで減らせる分を先に減らし、それでも合わない例外だけを周りに作り足すことです。システム会社に頼む場合の当社の価格は、既存システムの改修が100万円〜、PoC（試験導入）が300万円〜、本開発は個別見積です（いずれも税別。クラウド・外部APIの利用料は別）。

「ec システム 会社」で調べると、上位には売り場（ECサイト）を作る会社の一覧や比較ページが並びます（2026-10-18 時点）。この記事で扱うのは売り場の裏側、つまり受注・在庫・出荷・卸・会計をつなぐ部分です。サイトのデザインや集客を頼む会社選びはこの記事の対象ではありません。

この記事の進め方が合う場合・合わない場合

先に、開発会社に相談しなくてよい場合をはっきりさせておきます。

EC事業の業務システムは5つの持ち場に分かれる

出典: Shopify 公式サイト

「ECシステム」という言葉は、売り場から会計までまとめて指すことがあります。発注先と相談するときは、どの持ち場の話かを分けておくと、作る範囲を絞れます。下の分け方は、この記事で説明のために使う整理です。

例に挙げた製品の記載は公式情報で確かめた範囲のもので、順位や優劣を示すものではありません。

既製ツールで足りる範囲と、作り込みが要る範囲

手で直している作業を1つずつ、下の表に当てはめてみてください。「作るなら何を作るか」は大きく3つに分かれます。

• 周辺の小さな連携: ツールの外で、CSVの変換・突き合わせ・通知などを自動にする
• ツールのAPIを使った追加: 一元管理ツールや倉庫システムの公開API（外部のプログラムからデータを読み書きする窓口）を使い、足りない処理を外側に作る
• 基盤の作り替え: 在庫や受注を持つ仕組みそのものを入れ替える

自社用の記入欄（空欄のまま印刷・コピーして使えます）

「ツールの設定・アプリで解決できないか確認したか」の列が空のまま開発会社に相談すると、作らなくてよいものまで見積に入ることがあります。ツールのサポートへの問い合わせは、開発の相談より先に済ませておくのが安全です。

モール・カートのAPIでできること・できないこと

出典: Shopify 公式（Shopify Dev Docs）

連携を作るときの最初の制約は、モールやカートのAPIで何が取れて、何を返せるかです。APIで取れない・返せない処理があると、どの会社に頼んでもその部分は手作業かCSVのやり取りになります。2026年10月18日に公開情報で確かめた範囲を並べます。

予約注文・ステータス更新のように APIの側で対応していない処理は、開発しても完全には自動にならないことがあります。その場合は「CSVを決まった場所に置けば後は自動」「更新が要る注文の一覧だけを毎朝出す」のように、人の作業を短くする作りにします。見積の前に、この表の「手作業が残る点」が自社のどの業務に当たるかを書き出しておくと、作る範囲とできない範囲を最初の相談で分けられます。

連携用のキーに期限がある売り場（上の楽天の例では90日）では、期限切れで連携が止まったときに誰が気付き、どう手作業へ切り替えるかも決めておきます。止まったことに気付けない連携は、手作業より危険です。

倉庫・会計への受け渡しをどこで持つか

出典: LOGILESS 公式サイト

受注と在庫は一元管理ツールに任せても、その先の倉庫と会計へのデータの渡し方で手作業が残ることがあります。

倉庫: 在庫の「正」をどこに置くか

一元管理ツールと倉庫システムをつなぐと、在庫数が2か所にできます。どちらを正とするかを決めないまま使うと、数が合わなくなったときに直す基準がありません。

倉庫システム側のヘルプには、具体例が書かれています。ロジクラのヘルプでは、ロジクラで作ったセット品を出荷した場合、構成品の商品が連携していてもネクストエンジンの在庫は減らない、と案内されています。また、連携済みと未連携の商品が1回の出荷に混ざると、連携済みの商品の在庫だけが減ります（ロジクラ ヘルプセンター、2026-10-18 確認）。これは連携の仕様として案内されている動きです。セット商品を倉庫側で組む運用なら、この差を埋める処理か、毎日の照合が要ります。

決めておくことは次の3つです。

在庫の照合だけを自動にしたい場合は、棚卸・在庫の突き合わせを自動化する記事も参考になります。

会計: 売上・手数料・ポイントをどの単位で渡すか

会計への受け渡しは、まず既製の連携アプリで足りるかを確かめます。freee会計は全プランで外部連携用の公開APIを使えると案内されています（freee ヘルプセンター、2026-10-18 確認）。既製アプリで足りないのは、モールごとに手数料・ポイント・クーポン・返品の扱いが違い、それを自社の勘定科目や部門に分けて仕訳したい場合です。会計への連携を作る費用の考え方はfreee と連携するシステム開発の記事で詳しく扱っています。

リプレイスか、周辺の追加か

「ECシステムのリプレイス（入れ替え）」を考え始めたら、作り替える前に周辺の追加で済まないかを確かめます。作り替えは移行と並行稼働の手間が大きく、販売を止めずに切り替える準備が要るためです。

作り替えを選ぶ場合は、見積に次が入っているかを確認します。

• データ移行: 商品マスタ・SKU・セットの構成・取引先・過去の受注のうち、何をどこまで移すか（システムの入れ替えとデータ移行の記事）
• 並行稼働: 新旧を同時に動かす期間と、その間の在庫の正をどちらに置くか
• 切替日の在庫: 切替の当日に在庫数を止めて数え直すか、差分を後で合わせるか
• 戻し方: 切替後に問題が出たとき、旧システムに戻す手順と判断する人

費用の目安

既製ツールの月額（公開料金表から計算した説明用の試算）

ネクストエンジンと LOGILESS は、どちらも受注件数で月額が変わります。下の表は、2026年10月18日に各社の公式料金ページで確認した料金表に、架空の月間受注件数を当てはめて当社が計算した値です（税抜）。2つの製品は持っている機能の範囲が違う（ネクストエンジンは受注・在庫の一元管理、LOGILESS は倉庫の出荷管理までを含む）ため、どちらが安いかを比べる表ではありません。件数で月額がどう増えるかを見るための表です。

• ネクストエンジン: 初期0円、月額基本3,000円（200件まで）、201件からは件数の区分ごとの従量（201〜400件は1件35円、401〜1,000件は30円、1,001〜3,000件は25円、3,001〜5,000件は20円 など）。契約1年後から年間保守15,000円、有料アプリは別。キャンセル注文・過去の注文の取込も課金対象（料金ページ）。1,000件・3,000件の値は公式の料金例と一致
• LOGILESS: 初期0円、スタンダードは月25,000円（1倉庫・500件まで）、超過は5,000件までが1件25円。ライトは月20,000円（300件まで）。オプションは別見積（料金ページ）
• 卸の受発注を既製で持つ場合の例として、Bカートは初期80,000円、月額9,800円〜79,800円（プランにより商品数・会員数の上限が違う）、エンタープライズは個別見積（税別、料金ページ）

各社の情報は確認日時点の公式サイトの記載です。最新は各社に確認してください。

開発を頼む場合の依頼の形

既製ツールで足りない部分を作る場合、当社では次の3つの形で受けています（既存システムの改修・PoCの価格と進め方）。

見積の金額は、APIの有無（CSVしか無い売り場が多いほど手間が増える）、例外のルールの数、照合とテストの範囲、移行するデータの量で変わります。

手で直している時間の試算（仮定に基づく試算）

作るかどうかを決めるには、今の手作業にいくらかかっているかを自社の数字で出すのが早道です。下は架空の事業者を置いた試算です。

時給3,000円（社会保険料などを含めた仮定の人件費）で計算すると、月約8.6万円、年約103万円です。この規模で既存システムの改修（100万円〜）を頼むと、手作業が全部なくなったとしても回収に約12か月（100万円÷月8.6万円）かかります。実際には人の確認が残り、連携の利用料や保守の費用も別にかかるため、回収はもっと延びます。まずツールの設定と既製アプリで減らせる分を減らし、残った時間で判断するのが順番です。逆に、例外の件数がこの数倍あり、担当者が複数いる場合や、在庫のずれによる欠品・売り越しが起きている場合は、作る価値が高くなります。売り越しの損失（キャンセル対応・店舗の評価）も、分かる範囲で並べて比べてください。

自社でAIを使って進められる部分と、会社に頼む部分

いまは、ChatGPT や Claude などのAIを使って、社内の担当者がかなりの作業を進められます。全部を外に頼む前に、自社で進める部分を分けておくと、依頼の範囲と費用を絞れます。

会社に頼む価値があるのは、主に例外が重なったときの設計、在庫の正しさの検証、止まったときの戻し方と運用です。社内でAIを使って作った試作やスクリプトがある場合は、それを残して本番で使える形に直す依頼もできます。

説明用の構成例（当社のEC案件の実績ではありません）

当社にはEC事業の公開できる事例はありません。以下は、作る範囲を考えるための説明用の構成例です。

状況（架空）: モール3店舗と自社サイトで販売。一元管理ツールと外部の倉庫を使用。セット商品は倉庫で組み、予約商品が毎月あり、卸先が20社。

この例では、まず①を既存システムの改修として作り、②③は例外のルールを書き出してから範囲を決めます。

大量の明細を取り込んで突き合わせ、人が確認する画面を作るという型は、当社の公開実績（通信事業の数万件の請求情報の取込・集計・確認画面）と近い作りです。ただし業界も業務も違い、ECでの実績として示すものではありません。

相談の前に揃えておくもの

最初の相談で依頼の範囲を早く絞るために、次のものがあると話が進みます。

• 月の受注件数（売り場ごと）と、手で直している注文の件数の目安
• 使っているツールの名前（売り場・一元管理・倉庫・会計・卸）とプラン
• 手で直している作業の一覧（上の記入欄で十分です）
• やり取りしているCSVの見本（購入者の氏名・住所などの個人情報を消したもの）
• 社内でAIを使って作った試作・スクリプトや、既存の自社システムの仕様書があれば、その有無

本番のログイン情報やAPIキー、実際の購入者データは送らないでください。

当社の初回相談は無料・30分（オンライン）で、要件が決まっていなくても大丈夫です。自社でAIを使って進める部分と、任せる部分を一緒に切り分けます。相談後に、業務の棚卸し表・効果の見立て・簡易モックと、依頼範囲の候補・進め方・費用の目安をまとめた相談メモを無料でお送りします（簡易モックは画面のイメージで、動くシステムではありません）。

今の受注・在庫・出荷の流れと使っているツールを共有して、作る範囲を相談する

受注処理だけ・商品登録だけを自動にしたい場合は、EC受注処理の自動化、EC商品登録の自動化の記事の方が近い内容です。卸の受発注を中心に作りたい場合はBtoB受発注サイトの開発も参考になります。

よくある質問

ECサイトを作る会社に、受注・在庫の連携もまとめて頼めますか？

会社によって違います。売り場のデザイン・構築を中心にしている会社と、裏側の業務システムや連携を中心にしている会社があるため、見積を取るときに「どのツールとどうつなぐか」「在庫のずれをどう確かめるか」を質問して、答えの具体さで確かめてください。売り場と裏側を別の会社に頼む場合は、どちらが連携の不具合を受け持つかを契約の前に決めておきます。

一元管理ツールを別の製品に乗り換えれば、手作業はなくなりますか？

乗り換え先の標準機能で、自社の例外（セット・予約・卸など）が扱えるかによります。モール側のAPIで取り込めない注文（予約注文をCSVで取り込む必要がある例など）は、どのツールでも残ることがあります。乗り換えの前に、手で直している作業の一覧を乗り換え先の候補に見せ、標準でできるか・アプリが要るか・できないかを1行ずつ答えてもらうのが確実です。

自社のスタッフが ChatGPT や Claude で作った連携を使い続けても大丈夫ですか？

小さな変換や点検の道具なら、そのまま使えることもあります。本番の在庫や受注を書き換える処理に使う場合は、失敗したときに気付けるか、同じ処理が二重に走ったときに在庫が二重に減らないか、APIキーをどこに保存しているか、作った人が不在でも直せるか、を確かめてください。当社では、こうした試作を残す部分と直す部分に分けて本番で使える形にする依頼も受けられます。

開発した連携が、モールやツールの仕様変更で動かなくなったらどうなりますか？

モールやツールの仕様は予告のうえで変わることがあり、その都度の修正が必要になります。発注の前に、仕様変更の告知を誰が確認するか、修正を保守契約に含めるか都度の依頼にするか、止まっている間はどの手作業で回すかを決めておきます。連携を作るときには、止まったことを担当者に知らせる通知を入れておくと、気付かずに在庫がずれる事態を避けられます。

予算が100万円に届かない場合、何から始めればよいですか？

まず、一元管理ツールのサポートへの問い合わせと、既製アプリの試用から始めてください。並行して、社内でAIを使い、CSVの変換や毎朝の在庫の照合のような小さな道具を作れます。当社の受託は既存システムの改修で100万円〜（税別）のため、それより小さい範囲は自社で進める方が合っています。どこまでを自社で進められるかの切り分けは、初回相談でも扱います。

購入者の個人情報を開発会社に渡す必要はありますか？

見積や最初の相談の段階では要りません。個人情報を消したCSVの見本と項目の一覧で十分です。開発やテストで本番に近いデータを使う場合は、渡す範囲・保管する場所・作業後の削除を契約で決め、モールの規約で外部に渡してよい範囲も確かめてください。テストには、できるだけ架空の購入者データを使います。

一元管理ツールで足りる部分は残し、合わない例外だけを作る。その範囲を決めるために、今の受注・在庫・出荷の流れと使っているツールを伺い、依頼範囲の候補と費用の目安を相談メモでお返しします。初回相談は無料・30分（オンライン）です。

今の受注・在庫・出荷の流れと使っているツールを共有して、作る範囲を相談する