ECを始めたら「人間API」が見つかった。― 在庫・価格・売上。基幹システムとECをつなぐ前に考えること

2026.09.25

ECサイトが完成した。

商品も登録した。決済もできる。テスト注文も問題ない。

いよいよ販売開始――。

そこで、こんな話が出てきた。

「この在庫100個、全部ECで売っていいんでしたっけ？」

営業部から声が上がる。

「いや、そのうち20個は得意先向けに残しておきたい」

では、ECで売っていいのは80個なのか。

「店舗でも同じ在庫を売っています」

では、店舗で10個売れたら、ECにはいつ反映するのか。

「ところで営業が電話で受けた注文は、いつ在庫から引かれるんでしたっけ？」

話はだんだんECサイトから離れていく。

もし、こうした問いがECサイト完成後に出てきたのなら、かなり厄介です。

しかし実際には、既存事業からECへ進出するとき、こうした問題は珍しくありません。

そして本来、この問いをするべきなのはECサイトが完成したときではない。

何を作るか決める前です。

ECを作ると、それまで会社の中で曖昧なまま成立していた「商売のルール」が表に出てきます。

在庫だけではありません。

価格は誰が決めるのか
顧客情報はどこを正とするのか
注文はいつ受注になるのか
売上はいつ成立するのか
返品されたら、在庫・売上・決済をどう戻すのか

既存事業者のEC進出は、単なるWebサイト構築では終わりません。

ECという新しい入口を、これまでの商売の仕組みにどう接続するのか。

そこからが、本当のプロジェクトです。

「在庫100個」は、100個売っていいという意味ではない

基幹システムに、

商品A　在庫100個

と登録されている。

では、その100という数字をECへ連携すればよいのでしょうか。

実際には、それほど単純ではありません。

100個のうち20個は大口顧客向けに確保しているかもしれません
店舗でも同じ在庫を販売しているかもしれません
電話注文を受けているものの、まだ基幹システムでは引き当てられていない商品があるかもしれません

返品予定、検品中、取り置き、入荷予定まで考え始めると、「在庫」という一つの数字の意味すら怪しくなってきます。

たとえば、

実在庫 − 引当済在庫 − 安全在庫 − 他チャネル確保分＝ EC販売可能在庫

と定義することも考えられます。

もちろん、実際のルールは会社によって異なります。

重要なのは、これはAPIの仕様だけでは決められないということです。

技術的には、基幹システムから在庫数を取得してECへ渡せば「在庫連携」はできます。

しかし、その前に決めなければならない。

この在庫を、誰に売ってよいのか。

これはシステムの問題ではなく、商売のルールです。

ECを始めると、価格も売上も「当たり前」ではなくなる

価格も同じです。

商品マスターに10,000円と登録されている。それをECに表示すれば済む会社なら、話は簡単です。

しかし既存事業、とりわけBtoBではそうならないことがあります。

A社には10％引き
B社には以前からの特別価格
100個以上なら別単価
この商品だけ営業部長の承認で値引き可能
送料込みの得意先もあれば、別途請求する得意先もある

営業担当者が間に入っていれば、

「このお客さんは、いつもの価格で」

で済んでいた話です。

ところがECには「いつもの価格」が分かりません。

ECは24時間365日、会社に問い続けます。

「結局、この商品はいくらなのですか？」

売上も同じです。

お客様がECで注文ボタンを押した。

この瞬間に売上でしょうか。

まだ決済が完了していないかもしれません。在庫を確保できていないかもしれません。商品も出荷していません。

注文受付
決済承認
在庫引当
出荷
配送完了

EC、基幹、物流、決済、会計では、それぞれ異なる状態を管理します。

さらに厄介なのは、一本道から外れたときです。

欠品した
二つの商品を注文されたが片方しか出荷できない
出荷前にキャンセルされた
出荷後に返品された
交換した
決済だけ失敗した
返金した

たった一つの注文について、

ECでは「キャンセル」
決済サービスでは「返金」
基幹システムでは「返品」
会計では「売上取消」

といった別々の処理が必要になることがあります。

ECと基幹システムの連携で本当に難しいのは、きれいに流れる正常系ではありません。

商売では必ず起きる「例外」を、複数のシステムで矛盾なく扱うことです。

ECを始めたから、価格や受注のルールが複雑になったわけではありません。

もともと複雑だった商売が、ECによって表面化しただけなのです。

なぜ、それでも今まで商売は回っていたのか

ここまで考えると、一つ疑問が出てきます。

それほど曖昧なルールで、なぜこれまで商売が成立していたのでしょうか。

理由の一つは、人間です。

営業担当者が、

「このお客さんなら、いつもの価格でいいですよ」

と判断する。

倉庫担当者が、

「これは急ぎだから先に出しておきます」

と調整する。

経理担当者が、

「この会社は月末まとめて請求です」

と処理する。

商品担当者が、

「これは廃番だから後継品に変えておきます」

と対応する。

システムからシステムへ情報を渡す仕組みをAPIと呼ぶなら、多くの会社ではこれまで、人間がシステムとシステムの間をつなぐ「人間API」として機能してきたとも言えます。

しかも、この人間APIはかなり優秀です。

データが多少足りなくても文脈から判断する。例外にも対応する。昔からの経緯を知っている。分からなければ隣の部署に電話する。

だから多少曖昧なルールでも、商売は回ってきました。

ところがECでは、お客様が夜中の2時に注文するかもしれません。

そのたびに、

「田中さん、このお客さんどうするんでしたっけ？」

とは聞けません。

ECは、これまで人間が吸収してきた曖昧さに対して、

「その判断を、仕様にしてください」

と迫ってきます。

ここに、既存事業からECへ進出するときの難しさがあります。

全部自動化する必要も、全部基幹に合わせる必要もない

では、人間APIがやっていることを、すべてシステム化すればよいのでしょうか。

それも現実的ではありません。

年に数回しか発生しない特殊な返品。特定の大口顧客だけに存在する例外的な取引条件。営業責任者の判断が必要な特殊値引き。

こうしたものまで最初からすべてシステム化しようとすれば、ECと基幹システムの連携はどんどん巨大になります。

一方で、

「既存の基幹システムを正として、ECを全部それに合わせればいい」

という考え方にも注意が必要です。

その基幹システムは、10年前、15年前の商売を前提として作られているかもしれません。

営業による受注、電話やFAX、店舗販売を前提とした基幹システムに、新しいECの仕組みをすべて合わせていく。

一つ一つの判断には合理性があります。

しかし積み重ねた結果、妙なことが起こります。

新しい商売を始めるためのECが、昔の商売を前提にしたシステムに合わせて設計されていく。

かといって、ECだけを自由に作れば、今度は基幹、在庫、物流、会計との間に大量の変換処理や二重管理が生まれます。

「全部自動化する」。
「全部基幹に合わせる」。

どちらか一方に振り切れば解決するほど、既存事業のEC化は単純ではありません。

決めるべきは、「何をシステムにしないか」でもある

だからECの要件定義では、現在人間が行っている判断を一度並べてみる必要があります。

そのうえで、すべてを同じようにシステム化するのではなく、たとえば四つに分けて考えます。

1. ルール化する：毎日、大量に発生する判断で、一定のルールに落とせるもの。たとえば「EC販売可能在庫」をどう算出するか。これはシステム化する価値があります。
2. 分離する：既存業務との統合がすぐには難しいもの。たとえば在庫100個のうち20個を「EC販売枠」として確保し、当面は別管理する。リアルタイム在庫連携が完成するまで、こうした方法を採ることも考えられます。
3. 制限する：すべての既存商売を、最初からECで再現しない。複雑な得意先別価格を持つ商品はEC対象外にする。特定の商品・顧客・取引条件から始める。「ECで何ができるか」だけでなく、「最初は何をECでやらないか」を決めます。
4. 人に残す：発生頻度が低く、ルール化するとかえって複雑になるもの。特殊な返品や例外的な取引については、人が判断する。人間APIをゼロにする必要はありません。

重要なのは、

何をルール化し、何を分け、何をやらず、何を人に残すのか。

その境界を意識して決めることです。

これは妥協ではありません。

移行設計です。

最初から100点の統合を目指してEC開始まで何年もかけるより、将来の姿を見据えながら、どこまでを今回実現するのかを決める。

ECの要件定義では、機能を決めることと同じくらい、今回作らないものを決めることが重要になります。

そしてECは、「商売」をAPI化する入口になる

ここまでは、ECをどう現実的に立ち上げるかという話です。

しかし、もう少し先まで考えてみます。

ECを始めるために、

誰に何を売れるのか
いくらで売るのか
どの在庫を使うのか
注文をどう受け付けるのか
決済や出荷をどう処理するのか

これまで人間の頭の中にあった判断を、少しずつルールとデータにしていく。

これは、自社のECサイトを動かすためだけの仕事なのでしょうか。

一度、商売のルールがデジタルで扱えるようになれば、その入口は自社ECだけである必要はありません。

取引先のシステムから直接注文を受けることもできるかもしれない
代理店や販売パートナーとつなぐこともできる
マーケットプレイスや、これから生まれる新しい販売チャネルから利用することも考えられます

つまり、

「ECサイトを一つ作った」

と考えるか、

「自社の商売を、外から利用できる形にしていく最初の一歩を作った」

と考えるか。

この二つでは、システムの設計も、その後の事業の広がりも変わってきます。

ここでいう「商売のAPI化」は、単に技術としてAPIを実装するという意味ではありません。

商品、価格、在庫、受注、決済、物流といった商売のルールを整理し、他のチャネルやシステムからも利用できる構造にしていくこと。

ECは、その最初の利用者になるかもしれません。

そして将来、EC以外の誰かが、その仕組みを使うかもしれません。

ECで「何をするか」と同じくらい、「何をしないか」を決める

ECと基幹をどうつなぐか。

その問いから始めると、API、データ連携、マスター同期といったシステムの話になりがちです。

もちろん、それらも必要です。

しかし、その前に決めることがあります。

どの在庫をECで売るのか
どこまで既存の価格体系を持ち込むのか
どんな例外まで自動化するのか
何を既存業務から分離するのか
そして、何をまだ人間に任せるのか

ECで何を実現するかと同じくらい、何をまだECではやらないかを決める。

その境界が決まって初めて、ECと基幹システムの「つなぎ方」が決まります。

そして、その設計は今回のECだけのものとは限りません。

きちんと整理された商品、価格、在庫、受注、物流の仕組みは、次の販売チャネルを作るときにも使えるかもしれない。取引先と直接つながるときにも使えるかもしれない。これまで自社だけで使っていた仕組みを、サービスとして外部へ提供することにつながるかもしれない。

EC進出を、

「新しいWebサイトを作るプロジェクト」

で終わらせるのか。

それとも、

「自社の商売を、変えられる・つなげられる構造にしていくプロジェクト」

と捉えるのか。

ECサイトは同じように見えても、その先に作られるものは大きく違ってきます。

EC・基幹連携を、システムだけの話にしないために

ECの新規導入やリプレイスでは、ECサイトの機能だけでなく、既存業務、基幹システム、在庫、価格、物流、顧客、売上、会計まで含めた整理が必要になります。

オーシャン・アンド・パートナーズでは、特定のEC製品や開発会社を前提とせず、発注側の立場から現状業務の整理、要件整理、RFP作成、ベンダー選定、プロジェクト推進まで支援しています。

EC構築の発注前はもちろん、

「既に検討を始めているが、基幹との連携や業務ルールの整理で仕様が決まらない」

という段階からでもご相談いただけます。

この記事を書いた人について

谷尾薫: オーシャン・アンド・パートナーズ株式会社　代表取締役
協同組合シー・ソフトウェア（全省庁統一資格Aランク）代表理事

富士通、日本オラクル、フューチャーアーキテクト、独立系ベンチャーを経てオーシャン・アンド・パートナーズ株式会社を設立。2010年中小企業基盤整備機構「創業・ベンチャーフォーラム」にてチャレンジ事例100に選出。