ECシステム論

この連載では、ショッピングカート・決済・在庫・ログインなど、ECを支える仕組みが「なぜその形になったのか」を、世界と日本のEC基盤の設計思想から読み解いていきます。仕組みの形をまねるのではなく、その形が生まれた理由まで理解することを目指します。

今回の問い

楽天市場は、なぜ複雑に見えるのか。
その複雑さは、何を守るために生まれたのか。

第1回は、日本のEC基盤の代表として楽天市場を取り上げます。私がECサイトを作り始めた頃と、ほぼ同じ時代に生まれた市場です。楽天市場が創業時に掲げた「小さな商店でも、自ら店を運営できる市場」という構想は、公式資料から確認できます。一方、本稿後半で扱う取引・計算・店舗運用に関する設計上の特徴は、現在公開されている仕組みと、私自身の実務経験から読み取ったものです。

私は最初、楽天市場が税込価格と税抜価格をどう扱っているのかを調べていました。しかし調べを進めるほど、見えてきたのは「税込か税抜か」という違いではありませんでした。約30年という時間が積み重ねた、一つの設計思想でした。

第1章　「一つの大きな店」ではなく、「市場」として始まった

楽天市場は、1997年5月にサービスを開始しました。私がECサイトを作り始めた頃と、ほぼ同じ時代です。

その後、私は神戸市でモール事業の立ち上げに関わりました。当時、モールを考えるうえで、楽天市場の動向は常に意識していました。兵庫県内の商店街へNTT西日本の方と出向き、これからインターネット上の商店街をどう作るのか、楽天市場との違いを説明したこともあります。

いま振り返ると、あのとき比較していたのは、サービスの機能だけではありませんでした。

商店街そのものをインターネットへ移すのか。
一つの共通した売り場を作るのか。
それとも、それぞれの商店が店らしさを残したまま集まる場所を作るのか。

当時は「設計思想」という言葉では考えていませんでした。しかし、モールを立ち上げる側に立つと、最初に決めなければならないのは、画面のデザインでも商品登録の方法でもありません。誰が商売の主体であり、モールはどこまで共通化するのかということでした。

楽天市場は、従業員6人、サーバー1台、出店店舗13店から始まりました。現在のような巨大な経済圏ではありません。

また当時、日本国内にインターネット通販や電子ショッピングモールが、まったく存在しなかったわけでもありません。1990年代半ばには、国内でも個別のネット通販やバーチャルモールの取り組みが始まっていました。ただし、ネット通販はまだ一般化しておらず、実証実験的な取り組みも多い時代でした。

そのような中で楽天市場は、地方の小さな商店や、コンピューターに詳しくない事業者でも、インターネット上に店を持てる場所を目指して始まりました。

ここに、最初の設計判断があります。楽天市場は、一つの販売会社がすべての商品を売る仕組みではありません。複数の店舗が出店し、それぞれの店舗が商品を販売します。購入者から見ると一つの楽天市場ですが、実際の販売主体は、それぞれの出店店舗です。

楽天市場が選んだのは、楽天自身が商品を仕入れ、在庫を持ち、すべてを販売する形ではありませんでした。楽天は市場を用意し、各店舗が商品を登録し、価格を決め、顧客へ販売する形を選びました。インターネットに詳しくない商店主でも、自ら商品ページを作成・更新し、注文を管理できる仕組みを用意しました。現在はRMSと呼ばれる店舗運営システムが、その役割を担っています。

これは単に、小さな商店へ出店機会を提供したというだけではありません。在庫、物流、商品の説明、販売条件、顧客対応の多くを、店舗側に残したということでもあります。楽天市場は、店舗を楽天の支店へ変えたのではありません。店舗が独立した商売の主体であり続けられる市場を作ったのです。この最初の選択が、その後の複雑さにつながります。

楽天市場は「一つの大きな店」ではなく、
「多数の店舗が集まる市場」として始まった。

この構造は、その後の設計にも大きく影響します。店舗ごとに商品があり、価格があり、送料や販売条件があり、発送や返品の対応がある。しかし購入者には、楽天市場全体で使えるポイントやクーポンもあります。店舗ごとの商売と、モール全体の共通機能を、同じ取引の中で成立させなければなりません。楽天市場の複雑さは、ここから始まっています。

売れない店が、サイトを見なくなる

インターネット通販が始まった頃は、現在のように、注文と同時に在庫が正確に引き当てられ、発送予定まで自動的に決まる仕組みが一般的だったわけではありません。商品が売れた。しかし、実際には在庫がなかった。その場合には、店舗が購入者へ連絡し、「申し訳ありません。商品を用意できません」と伝える。初期のインターネット通販は、それが起こり得るものでした。

楽天市場も例外ではありません。多数の店舗が参加する市場である以上、商品情報を登録した店舗が、本当に注文を確認し、購入者へ対応しているかを確かめる必要がありました。私の記憶では、楽天は、出店した店主がきちんと店舗を運営しているかを常に見ていました。理由は、注文処理の知識がなかったからだけではありません。商品がなかなか売れないと、店主が管理画面を見なくなることがあるからです。

最初は期待して出店し、毎日、注文が入っていないか確認します。しかし、何週間たっても注文がない。そのうち、サイトを開く回数が減っていきます。そして、久しぶりに注文が入ったときに気づかない。在庫を確認しない。購入者へ連絡しない。店舗のページが存在していても、店主がそこにいなければ、商売は成立しません。

私が神戸市でモール事業に関わったときも、同じことを考えていました。出店してもらうだけでは終わりません。売れない期間が続いたときに、店舗がサイトを見なくならないようにする。注文が入ったときに、きちんと気づいてもらう。在庫を確認し、購入者へ返事をしてもらう。私は、店舗が本当に対応しているかを見ていました。

いまのECでは、受注通知、在庫連携、発送管理、自動メールなど、多くの部分がシステム化されています。しかし、当時のモール運営では、システムを作ることと同じくらい、店舗に、インターネット上でも商売を続けてもらうことが重要でした。

楽天市場が店舗の運営を支援し、店舗の対応状況を確認していたのは、管理を厳しくするためだけではありません。店舗が独立した商売の主体である以上、その店舗が実際に動き続けなければ、市場全体の信用が失われるからです。購入者から見れば、対応しなかったのは一つの店舗です。しかし、その体験は「楽天市場で買ったのに、返事が来なかった」という、モール全体への評価になります。

店舗を残すということは、店舗に任せて終わることではない。
店舗が動き続けられるように支えることまで含んでいた。

この設計が教えてくれること

仕組みの複雑さは、最初の「何を作るか」で決まります。「店」ではなく「市場」を選んだ瞬間に、店舗とモールの二重構造が宿命づけられました。

第2章　楽天市場の起点と、その後の六つの変化

楽天市場が始まった当時は、現在のようなポイント、クーポン、軽減税率、インボイス制度はありませんでした。しかし、その後の約30年間で、取引に含まれる条件が増えていきます。複雑さは、一度に生まれたのではありません。時代ごとに、少しずつ積み重なりました。

この六つの変化によって、楽天市場の取引には、商品価格・税率・税額・ポイント・クーポン・送料・端数処理・税率別金額・帳票情報が重なるようになりました。

楽天市場が複雑になったのは、単に機能を増やしたからではない。
異なる時代に追加された制度と販促を、一つの注文の中で成立させてきたからだ。

第3章　「価格」は、一つではない

楽天市場を理解するうえで、価格の登録方法は重要です。購入者が商品ページや買い物かごで見る価格は、税込価格です。一方、商品管理上は、商品やショップの設定に応じて税を扱い、税別商品については商品ごとに税込価格が計算されます。

つまり「商品を登録するときの価格」と「購入者に表示される価格」と「ポイント計算に使われる価格」は、必ずしも同じ意味ではありません。整理すると、楽天市場には少なくとも次の価格があります。

同じ「価格」という言葉でも、何を表しているかが違います。ここを区別しなければ、楽天市場上の金額と、自社システム上の金額を正しく対応させることはできません。

価格は誰が決め、誰が値引きするのか

楽天市場では、商品の販売価格を決める主体は、基本的に出店店舗です。しかし、購入者が実際に支払う金額は、店舗が登録した商品価格だけでは決まりません。そこには、店舗が発行するクーポン、楽天市場全体のキャンペーン、楽天ポイントの利用、送料、ラッピング料、支払方法に関係する条件などが加わります。

つまり、価格を決める主体は店舗ですが、注文金額を構成する要素は、店舗だけでは完結しません。店舗の販売条件と、楽天市場全体の販促条件が、一つの注文の中で重なります。購入者には一つの注文として見えていても、その中では複数のルールが動いているのです。

この設計が教えてくれること

「価格」を一つの数字だと思うと、必ずどこかで合わなくなります。大切なのは、その数字が「いつの・何のための価格か」を区別できる設計です。

第4章　計算式だけでは、同じ結果にならない

ポイントは、注文全体ではなく商品ごとに計算する

現在の楽天市場では、通常購入の通常ポイントについて、原則として各商品の「税抜単価×個数」にポイント倍率を掛け、商品ごとに生じた小数点以下を切り捨てます。つまり、同じ注文の中に複数の商品があっても、注文合計に対して一度だけ計算するわけではありません。商品ごとの計算結果を積み上げます。

例えば、通常ポイント1倍の場合、税抜98円の商品Aと、税抜98円の商品Bを1個ずつ購入したとします。それぞれのポイントは 0.98 ポイントです。商品ごとに小数点以下を切り捨てるため、付与ポイントは合計 0 ポイントになります。

一方、同じ税抜98円の商品を2個購入した場合は、98円×2個＝196円 を基準に計算するため、1.96 ポイントの小数点以下を切り捨て、1 ポイントになります。注文全体の税抜金額は、どちらも196円です。しかし、異なる商品を1個ずつ買った場合と、同じ商品を2個買った場合では、通常ポイント数が異なります。

ここから分かるのは、
計算式だけでは、結果を再現できないということ。

商品単位で計算するのか、注文単位で計算するのか。数量を掛ける前か後か。どの時点で小数点以下を切り捨てるのか。そこまで一致して、初めて同じ結果になります。

クーポンは、単なる値引きではない

商品ページに表示されている価格が1万円でも、1,000円引きクーポンを使えば、実際の支払額は変わります。ここで「商品マスターに登録された価格」と「今回の注文で適用された金額」が分かれます。

さらに、注文全体に使うクーポンの場合、その値引額をどの商品へ割り振るかという問題が生まれます。例えば、商品Aが4,000円、商品Bが2,000円、注文全体で500円引きだった場合、500円をどちらの商品から引いたことにするのでしょうか。

楽天市場の通常ポイント計算では、注文全体に使うクーポンを、各商品の価格割合に応じて商品ごとに割り振ります。つまり、単に注文合計から500円を引くだけではありません。値引きを商品へ配分し、その後の商品別金額を使ってポイントを計算します。ここまで来ると、商品マスターの価格だけでは、注文内容を説明できません。商品価格の構成比に応じて配分するこの基本手順は、楽天公式ヘルプに公開されています。ただし、計算上割り切れない端数を最終的にどの商品へ寄せるかなど、内部処理のすべてが公開されているわけではありません。

消費税の端数処理は、ショップによって異なる

楽天市場では、購入者向けには税込価格を表示します。一方、通常ポイントは税抜金額を基準に計算します。そのため、税込価格と税率から消費税額を求め、税込価格から消費税額を差し引いて、ポイント計算用の税抜価格を求めます。公式説明では、税抜商品価格は「税込商品価格－消費税額」として求められます。

楽天公式ヘルプでは、この消費税額に小数点以下が生じた場合の端数処理は、ショップによって異なると説明されています。つまり、同じ税込価格と税率であっても、ショップの端数処理設定によって、ポイント計算に使われる税抜金額が異なる可能性があります。

楽天市場の計算を外部システムで再現するときには、「同じ計算式を使うだけでは足りない」という問題が生まれます。必要なのは、計算対象・計算単位・計算順序・端数処理方法・端数処理のタイミングを一致させることです。1円や1ポイントの差は、計算式の誤りだけでなく、端数を処理する場所の違いによっても生まれます。

購入方法によって、計算の単位そのものが変わる

さらに、楽天市場では、購入方法によってポイント計算の単位そのものが変わります。通常購入では、原則として各商品の税抜購入金額を基準にポイントを計算します。一方、定期購入・頒布会・予約購入では、注文確定時の税抜購入金額を基準にする計算例が、楽天の公式ヘルプに示されています。

同じ楽天ポイントであっても、すべての購入方法が同じ単位、同じタイミングで計算されるわけではありません。ここから分かるのは、計算式だけを合わせても十分ではないということです。

通常購入なのか、予約購入なのか、定期購入なのか。
商品単位なのか、注文単位なのか。購入時なのか、注文確定時なのか。

対象、単位、順序、端数処理、タイミングまで一致して、初めて同じ結果になります。

この設計が教えてくれること

他のシステムと金額を一致させたいなら、式ではなく「単位・順序・端数・タイミング」まで揃える必要があります。連携で生まれる1円のズレは、たいていここに原因があります。

第5章　私が東京で最初に作っていたもの

私が東京へ来て、最初に行っていた仕事の一つが、楽天市場などのモールから出力された売上データを変換するプログラムの開発でした。食品専門店や食品メーカーを含む、複数の企業のECに関わりました。

当時、売上データを変換する目的は、単に一覧表を作ることではありませんでした。一つは、クレジットカード決済を行うためです。もう一つは、成立した売上を企業の基幹システムへ取り込むためでした。

当時の楽天市場では、購入者が入力したクレジットカード情報を含む注文データを店舗が受け取り、店舗が自ら契約しているカード会社や決済会社へ送って、与信や売上処理を行う仕組みがありました。そのため、楽天市場から出力されたデータを、カード決済会社が受け付ける形式へ変換する必要がありました。

そして、カード決済だけで処理は終わりません。決済した売上を、今度は各企業の基幹システムで扱える形式へ変換し、取り込む必要があります。

三つのシステムは、それぞれ異なる目的で作られているため、同じ取引であっても、項目名も、データの単位も、金額の持ち方も同じではありません。私は、その間をつなぐプログラムを作っていました。

当時は、それを楽天市場の「設計思想」として考えていたわけではありません。店舗ごと、カード会社ごと、基幹システムごとに仕様が違うため、それを変換するのが仕事だと思っていました。しかし、いま振り返ると、その仕事そのものが、当時の楽天市場の構造を表していました。

楽天市場は、商品の販売主体を店舗に残していました。それだけではありません。クレジットカード決済についても、店舗がすでに持っている加盟店契約を利用し、店舗自身が決済することを認めていました。

楽天市場がすべての店舗の代わりに商品を販売するのでもない。
楽天市場がすべての決済を一律に処理するのでもない。

店舗は、自ら商品を販売し、自らの加盟店契約で代金を受け取り、その結果を自社の基幹システムへ取り込む。楽天市場は、その取引が始まる場所を提供していました。私が作っていたコンバートプログラムは、この分散した構造を企業の業務へつなぐためのものでした。

決済も、最初から楽天へ集約されていたわけではない

現在の楽天市場では、店舗が購入者のカード番号を直接受け取り、自らカード会社へ送って決済する形にはなっていません。しかし、楽天市場は最初から現在の形だったわけではありません。当初は、店舗がクレジットカード情報を含む注文データを受け取り、自ら契約しているカード会社や決済会社を使って処理していました。これは、店舗がすでに持っていたカード加盟店契約と、入金や経理の業務を優先した構造でもあります。

その後、楽天は、カード決済を楽天側で処理する仕組みを導入しました。ただし、すべての店舗が一度に新しい仕組みへ切り替わったわけではありません。楽天側の決済サービスを利用する店舗がある一方で、それまでどおり、店舗が自ら持つカード加盟店契約を使って決済する方式も併存していました。さらに、カード番号を店舗へ渡さない方式へ移った後も、カード会社との加盟店契約を店舗が持つ方式と、楽天が包括加盟契約を持って決済を代行する方式が、移行期間には併存していました。

つまり、楽天市場の決済は、一度に一つの方式へ切り替わったのではありません。カード番号を誰が扱うのか。カード会社との加盟店契約を誰が持つのか。与信、入金、返金を誰が処理するのか。これらが段階的に楽天側へ移されていったのです。

これは、すでに動いている市場を変更する難しさを表しています。各店舗には、それまで使ってきたカード会社との契約があります。決済手数料があります。入金サイクルがあります。経理処理があります。基幹システムへ売上を取り込む手順もあります。新しい仕組みができたからといって、その日にすべてを切り替えられるわけではありません。店舗の営業を続けながら、従来の仕組みと新しい仕組みを併存させ、段階的に移行する必要がありました。

2005年8月、楽天市場は、店舗へカード番号を渡さない方式へ切り替えました。その後も決済方式の移行は段階的に進み、最終的にはカード情報と決済関連業務が楽天側の共通基盤へ集約されていきました。この変化は、単なる決済機能の追加ではありません。楽天市場が、どこまでを店舗へ任せ、どこからをモール共通の責任として引き受けるか、その境界を引き直した出来事です。

当初は、店舗の独立性を優先し、決済も店舗へ残した。その後は、店舗の営業と既存契約を尊重しながら、店舗別決済と共通決済を併存させた。そして最終的には、カード情報と決済を楽天側の共通基盤へ集約した。

楽天市場は、店舗の自由か、モールによる共通化かを一度だけ選んだのではない。
市場の成長とリスクの変化に応じて、その境界を引き直してきた。

私が東京で最初に作っていたコンバートプログラムは、まさに、その境界の上で動くものでした。楽天市場から売上データを受け取る。店舗の加盟店契約を使ってカード決済へ渡す。処理された売上を、企業の基幹システムへ取り込む。当時は日常的なシステム連携の仕事でした。しかし、いま振り返ると、そこには楽天市場が最初に選んだ「店舗を独立した商売の主体として残す」という考え方が、そのままデータの流れとして表れていたのです。

この設計が教えてくれること

複雑さをどこへ分配するか。その配分は、一度決めて終わりではありません。市場の規模やリスク、制度の変化に応じて、何を店舗へ残し、何を共通基盤で引き受けるのか、その境界を引き直していく必要があります。会員、決済、データ連携の設計でも、同じ問いが繰り返し現れます。

第6章　注文は、一度で終わらない

注文ボタンを押しても、カード請求まで終わっていない

楽天市場の取引を理解するうえで、重要な特徴があります。それは「注文情報を送信した時点で、クレジットカードの売上請求まで完了しているわけではない」ということです。

購入者は、買い物かごで商品、数量、届け先、支払方法などを指定し、注文情報を送信します。しかし、注文ステップではクレジットカードの利用承認は行われません。注文後、カード会社による与信確認が行われます。この与信確認は、自動で行われる場合と、ショップが選択したタイミングで行われる場合があります。クレジットカードについては、与信枠の確認を先に行い、原則として商品の発送後に請求処理が行われます。

つまり、注文情報の送信、ショップによる注文受付、売買契約の成立、カード会社による与信確認、注文内容や金額の変更、商品発送、カード請求、楽天市場上の支払い確定は、同じ処理ではありません。それぞれが別の段階として進みます。

注文ボタンを押した瞬間に、
注文・契約・与信・請求のすべてが確定するわけではない。

注文後に、金額が変わる場合がある

楽天市場では、注文完了後であっても、ショップ側の処理によって注文内容や金額が変更される場合があります。例えば、送料が変更される、数量が変更される、一部の商品がキャンセルされる、返品や交換が処理される、荷物を一つにまとめられず送料が変わる、複数の配送方法が含まれ送料が変わる、といった場合です。その結果、注文金額が増額または減額されることがあります。

ただし、ショップが理由なく自由に金額を変更できるという意味ではありません。注文内容、配送条件、数量変更、キャンセル、返品など、取引上の理由に基づく変更です。重要なのは「注文時に画面へ表示された金額が、常にそのまま最終請求額になるとは限らない」ということです。楽天市場では、最初の注文情報を受け付けた後、ショップによる確認や変更を経て、発送や請求へ進みます。

第7章　システムだけで、すべてを確定しない

楽天市場の特徴は、複雑な計算をシステムで処理していることだけではありません。もう一つ重要なのは「共通システムだけで、すべての取引条件を注文前に確定しようとしていない」ことです。

楽天市場では、購入者が注文情報を送信した後、ショップがその内容を確認します。そして必要に応じて、送料、数量、キャンセルなどの処理を行います。なぜ、最初からシステムですべてを計算し、自動的に確定しないのでしょうか。

理由は、楽天市場に出店する店舗の商売が、すべて同じではないからです。商品も違います。配送方法も違います。送料の決め方も違います。在庫の持ち方も違います。予約商品や取り寄せ商品もあります。複数の商品を一つの荷物にできる場合もあれば、できない場合もあります。

これらをすべて楽天市場共通の自動計算ルールへ組み込もうとすれば、共通システムはさらに複雑になります。あるいは、店舗独自の商習慣や配送条件を認められなくなります。公開されている注文フローを見ると、楽天市場では「共通化できる部分はシステムで処理し、個別判断が必要な部分は各ショップが対応する」構造になっています。

システムは注文を受け付けます。ポイントやクーポンを計算します。カード情報や与信確認を処理します。一方、送料や数量の変更、キャンセル、発送、返品など、個別判断が必要な部分はショップが対応します。つまり楽天市場は、複雑さを完全になくしたのではありません。その複雑さは、楽天市場の共通システム・店舗の日常運用・外部の基幹／会計／在庫システムに分かれて存在しています。

楽天市場は複雑さを消したのではない。
複雑さを、システムと店舗運用へ分配する構造になった。

これは楽天が公式に掲げている設計思想ではありません。公開されている注文、ポイント、クーポン、カード与信、注文変更の仕組みから、私が読み取った特徴です。

第8章　楽天市場が、守ったもの

楽天市場が重視しているように見えるのは、商品マスターに登録された価格そのものではありません。また、購入者が最初に送信した注文内容を、そのまま一切変えずに守ることでもありません。ショップによる受付や必要な変更を経て、発送や請求へ進んだ取引内容を、後から説明できることです。

商品マスターは変わります。価格も、税率設定も、ポイント倍率も、商品説明も変わります。さらに、注文後に送料や数量が変更される場合もあります。そのため、後から注文内容を説明するには、商品登録時の価格、表示された税込価格、ポイント計算に使われた税抜価格、適用税率、適用クーポン、利用ポイント、送料、ポイント付与条件、端数処理、注文後の変更、与信確認、最終請求金額などを確認できる必要があります。

本稿でいう「最終的な取引内容」とは、法律上の契約成立時点だけを意味するものではありません。注文後の確認や変更、発送、請求まで反映された、実際に処理された注文内容を指しています。

THE CORE IDEA ・ 設計思想
最初の表示価格や注文内容ではなく、処理された取引を説明できる構造。

楽天市場の設計上の特徴を一言で表すなら、ショップの確認や変更を経て「実際に処理された取引」を、後から説明できる構造だということになるのではないでしょうか。守ろうとしているのは、完全な自動化ではなく、店舗の多様性と、取引の説明可能性です。

この設計が守ったものと、その代わりに複雑になったもの

楽天市場の設計では、得られたメリットと、そこから生じた複雑さは表裏一体です。

設計によって守られたものできるようになったことその代わりに複雑になったこと
店舗ごとの価格・税設定商品や店舗の事情に応じて、価格と税の扱いを設定できる商品登録価格、税込表示価格、ポイント計算用の税抜価格を区別する必要がある
購入者への税込価格表示購入者が実際に支払う税込価格を確認できる税抜基準のポイント計算では、税込価格から税額と税抜金額を求め直す必要がある
店舗ごとの送料・配送条件地域、商品の大きさ、同梱の可否などに応じた配送ができる注文時点では送料が確定せず、注文後に金額が変わる場合がある
注文後の変更や一部キャンセル在庫不足、配送条件、返品など、実際の取引に合わせて注文を修正できる注文時金額、変更後金額、最終請求金額を分けて管理する必要がある
店舗独自の販促とモール共通施策店舗クーポン、楽天ポイント、モール全体のキャンペーンを同じ注文で使えるクーポン値引き、ポイント利用、店舗側の値引きを区別し、商品別に扱う必要がある
複数税率への対応税率10％の商品と軽減税率8％の商品を、同じ注文で購入できる商品ごとの税率と税額を確認できるようにし、会計や帳票では税率別に分ける必要がある
過去の取引内容商品価格や税率が変わっても、過去の注文を当時の条件で確認できる商品マスターとは別に、注文時の価格、税率、値引き条件を確認できる必要がある
店舗ごとの商習慣や例外処理予約、取り寄せ、分割配送など、多様な商売を受け入れられる共通システムだけでは完結せず、店舗による確認や個別対応が残る
長期間の制度変更への対応消費税率変更、軽減税率、インボイスなどに、営業を続けながら対応できる異なる時代の計算ルールが重なり、計算順序や端数処理が複雑になる
外部システムとの接続基幹、会計、在庫、決済システムと注文情報を連携できる注文後の変更、キャンセル、発送、請求結果を継続的に同期する必要がある

楽天市場では、メリットと限界が別々に存在しているわけではありません。

店舗の多様性を守るほど、価格や注文の状態は増える。
注文後の変更を認めるほど、外部システムとの同期は難しくなる。
長期間の制度変更を受け入れるほど、計算順序と履歴管理は複雑になる。

楽天市場の複雑さは、単に機能を追加し続けた結果ではありません。何を共通化し、何を店舗側に残すかを選び続けた結果、その反対側に生まれた複雑さです。

特に重要なのは、店舗ごとの商売を共通システムへ完全に押し込めず、個別判断の余地を残していることです。すべてを自動化しないことで、さまざまな商品、配送方法、在庫形態、商習慣を受け入れることができます。人の手が残っていることは、単なる古さではありません。店舗の多様性を受け入れるための柔軟性でもあります。

一方で、柔軟性を維持するほど、店舗運用と外部連携は複雑になります。楽天市場との連携では「注文を一度取り込めば終わり」ではありません。最初に受け取った注文が、その後に変更される可能性があります。そのため外部システムでは、最初の注文・変更後の注文・発送された内容・最終請求金額・決済結果・キャンセルや返品を、どの時点でどう同期するかを設計しなければなりません。

まとめ　歴史が作った設計

現在の楽天市場の仕組みだけを見ると、複雑に感じます。しかし、その複雑さには理由があります。楽天市場は、すべてを一度捨てて理想的な形へ作り直せる実験用のシステムではありません。多数の店舗が、毎日商売を続けている稼働中の市場です。

制度が変わっても、店舗の営業を止めることはできません。過去の注文を消すこともできません。店舗ごとの商売を、すべて一つの方法へ統一することもできません。そのため、新しい制度やサービスを加えながら、過去との連続性と、店舗ごとの柔軟性を保つ必要があります。

それは、ただ複雑なだけの設計ではない。
約30年間の取引を引き継ぎながら、制度と商習慣の変化を受け入れてきた設計だ。

私は最初、楽天市場が税込価格と税抜価格をどう扱っているのかを調べていました。しかし、最後に見えてきたのは、税込か税抜かという違いではありませんでした。楽天市場は、すべてを自動化することで複雑さをなくしたのではなく、複雑さを共通システムと店舗運用へ分配する構造になった——ということでした。

それは非効率にも見えます。しかし、店舗ごとの商売を一つの市場へ集めるためには、その余地が必要だったのでしょう。その結果として残ったものは、人の判断です。そして複雑になったものは、店舗運用と外部システム連携でした。

そして、その境界は固定されたものではありません。当初は店舗側に残されていたカード決済は、カード番号の管理、与信処理、加盟店契約、入金や返金といった機能ごとに、段階的に楽天側の共通基盤へ移されていきました。楽天市場の約30年は、店舗の多様性を残しながら、何を店舗へ任せ、何をモール全体で引き受けるのか、その境界を引き直してきた歴史でもあります。

楽天市場の「価格」を、一枚で理解する参照表

最後に、本稿で扱った複数の「価格」を、実務上の参照表として整理します。横に長い表は、スクロールしてご覧ください。

価格・金額何を表すか主な利用場面注意点
商品登録価格ショップが商品へ設定する販売価格商品管理税の扱いや設定条件を確認する必要がある
税込表示価格購入者が商品ページや買い物かごで見る価格購入判断・注文商品登録価格と同じ意味とは限らない
ポイント計算用税抜価格税込価格から消費税額を差し引いて求める金額通常ポイント計算消費税額の端数処理により変わる場合がある
クーポン適用後価格クーポン値引きを反映した商品別金額通常ポイント計算注文全体クーポンは商品別に割り振られる
注文時金額購入者が注文情報を送信した時点の金額注文受付後から送料や数量が変更される場合がある
変更後金額ショップによる変更を反映した金額発送・請求処理最初の注文時金額と一致しない場合がある
最終請求金額カード会社などへ請求される金額決済与信額・注文時金額・入金額とは意味が異なる
ECシステム論 ・ 連載一覧 ECを支える仕組みは、なぜその形になったのか 連載一覧を見る
NEXT ── 次回予告
もう一つの日本のモールは、なぜ違う形を選んだのか。

第1回では、楽天市場が「店舗を残す市場」を選んだことを読み解きました。次回は、その約二年後に生まれた Yahoo!ショッピングへ目を向けます。同じモール型でありながら、なぜ同じ形にならなかったのか。商品と取引を「次に使える情報」として扱う設計をたどります。

連載の続きを見る

エビデンス・参考資料

参照日：2026年7月26日

※本稿の楽天市場に関する沿革、ポイント、クーポン、税計算、商品価格、注文変更、カード与信、請求処理等の説明は、2026年7月26日時点で公開されている公式情報を基にしています。制度、機能、運用条件は今後変更される可能性があります。

本連載は、公表されている技術仕様・公式資料と、筆者の長年の実務経験および考察をもとに構成しています。楽天市場内部の非公開アルゴリズムや処理を、推測によって断定するものではありません。

岸本 健志
岸本 健志
会員ビジネスLab 主任研究員 / ハートランドITイノベーション代表

1997年よりインターネット業界に従事。楽天市場が生まれた頃と同じ時代にECサイトの構築を始め、以来30年近く、EC・メディア・SaaS・コミュニティサイトなど数多くの会員ビジネスの立ち上げと成長を支援。

モールと自社システムの金額の突き合わせ、税・ポイント・クーポンの計算、決済と会計の連携といった「現場で1円が合わない」問題に数多く向き合ってきた経験から、仕組みの形には必ず理由があるという視点で、ECシステムの設計思想を読み解いています。

← ECシステム論 連載一覧へ