ECシステム論

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

今回のテーマ

Yahoo!ショッピングは、
楽天市場と何が違ったのか。

第2回は、日本のもう一つの代表的なモールとして、Yahoo!ショッピングを取り上げ、楽天市場と並べて読み解きます。二つは違う入口から始まりました。しかし税、値引き、ポイント、定期購入という条件が増えるにつれ、向き合う問いは似ていきます。そこには、商売の変化だけでなく、消費税率や税制度など、モールの外側から与えられた問いもありました。それでも、どの単位で計算し、どの項目として持ち、誰が使う仕様として渡すかには、違いが残ります。本稿で述べる設計上の特徴は、両社が公式に掲げた一つの言葉を紹介するものではありません。サービス開始時の公開資料、現在確認できる受注項目、そして私自身の実務経験から読み取ったものです。

楽天市場が始まったのは、1997年5月でした。その約2年4か月後の1999年9月9日、Yahoo!ショッピングがサービスを開始します。どちらも、複数の店舗が参加するモール型ECです。しかし、同じモール型であっても、二つのサービスが最初に前面へ出したものは違っていました。そして2004年ごろ、私はその違いを、実際の受注・売上データの中で見ることになります。1999年の公開資料、2004年ごろに私が扱った売上データ、そして現在確認できる受注仕様から、その変化をたどります。

第1章　楽天市場の約2年4か月後に生まれた、もう一つのモール

Yahoo!ショッピングの開始時の出店数は17店舗、商品数は約1万5,000点でした。楽天市場は13店舗から始まっています。店舗数だけを見れば、二つのサービスに大きな差はありません。

どちらも、一つの企業がすべての商品を仕入れて販売するのではなく、複数の店舗が参加するオンラインショッピングモールです。商品を販売する主体は、それぞれの出店店舗でした。Yahoo!ショッピングの開始時には、アスクル、石橋楽器店、オルビス、サンリオ、千疋屋總本店、ノジマ、ファンケルなどが参加していました。

基本構造は、楽天市場と同じです。モールが利用者を集め、店舗が商品を販売する。しかし、同じ構造を採用しながら、二つのサービスは少し違う場所から始まりました。

第2章　楽天市場は、「店」から始まった

楽天市場は、店舗がインターネット上で商売をする場所として始まりました。楽天グループの公式資料では、地方の小さな商店でも、コンピューターに強くなくても、誰でも簡単に店を開けるようにしたいというコンセプトで楽天市場を開設し、13店舗でスタートしたと説明されています。

楽天市場に並んでいたのは、単なる商品データだけではありません。そこには「店」がありました。

現在の楽天市場にも残る、長い商品ページや店舗ごとの個性は、この出発点とつながっています。楽天市場という一つのサイトの中に、多数の店舗が、それぞれの売り場を持つ。

楽天市場が最初に前面へ出したのは、
商品だけではなく、店舗が商売をすることだった。

第3章　Yahoo!ショッピングは、「商品を探すこと」から始まった

一方、Yahoo!ショッピングのサービス開始時の説明では、店舗の存在だけでなく、商品の探しやすさが強く打ち出されていました。開始時の商品は、分かりやすいカテゴリーに分類されていました。利用者はカテゴリーをたどり、欲しい商品を探すことができます。さらに、商品検索機能を使い、ブランド名などのキーワードから商品を見つけることもできました。

これは、Yahoo! JAPAN らしい出発点です。Yahoo! JAPAN は、もともとインターネット上の情報を分類し、検索し、利用者を目的の情報へ案内するポータルサイトでした。その会社がショッピングを作れば、店舗を一軒ずつ訪ねることだけでなく、欲しい商品を、どのように見つけるかが重要になります。

楽天市場が、店舗を集めた市場だったとすれば、Yahoo!ショッピングは、商品情報を集め、分類し、検索できる売り場として始まったように見えます。ここに、二つのモールの最初の違いがあります。

楽天市場

店舗がインターネット上で商売をする市場。

Yahoo!ショッピング

多数の商品から、利用者が目的の商品を探せる売り場。

もちろん、楽天市場にも商品検索はあり、Yahoo!ショッピングにも店舗があります。どちらか一方にしか存在しない機能ではありません。違うのは、サービス開始時に、何を前面へ出したかです。

その後、Yahoo!ショッピングは大きく方向を変えます。1999年の開始時には、出店する店舗を厳選することで、信頼と安心を作ろうとしていました。しかし2013年には「eコマース革命」を掲げ、ストア出店料と売上ロイヤルティーを無料化し、個人にも出店の入口を広げます。

入口で店舗を選ぶ市場から、商品情報を増やし、検索やデータによって整理する市場へ。この変化も、Yahoo!ショッピングが商品と流通を前面に置いてきたように見える理由の一つです。

第4章　2004年、私は二つの違いをデータで見ていた

私が Yahoo!ショッピングを、楽天市場とは少し違うモールだと感じたのは、現在のAPI仕様を調べてからではありません。2004年ごろ、私は、食品専門店や食品メーカーを含む複数の企業のECに関わり、楽天市場と Yahoo!ショッピングから出力された受注・売上データを、別のシステムで利用できる共通形式へ変換するプログラムを作りました。

同じ企業が、楽天市場と Yahoo!ショッピングの両方に出店し、同じように商品を販売していました。購入者から見れば、どちらもオンラインショッピングモールです。しかし、モールから出てくるデータは同じではありませんでした。違うのは、項目名だけではありません。

特に難しかったのは、注文全体に置かれた金額と、商品明細の金額を、どのように結びつけるかでした。モール上では一つの注文として成立していても、外部の基幹システムでは、商品売上、送料、手数料、値引き、税を、それぞれ別の意味を持つ金額として処理しなければなりません。

商品明細だけを合計しても、注文全体の金額と一致しないことがあります。残る金額が、送料なのか、包装料なのか、手数料なのか、調整額なのか、値引きとの相殺後の金額なのか。その構造を理解しなければ、基幹システムへ正しく取り込むことはできません。モールが違えば、出力されたデータを、そのまま一つにまとめることはできませんでした。二つのデータが何を意味しているのかを読み取り、共通する形へ変換する必要がありました。

当時の私は、それを設計思想の違いとは呼んでいませんでした。それぞれの仕様が違うから、変換が必要なのだと思っていました。当時、二つのモールのデータは、同じ取引を違う形で表していました。しかし現在の受注項目を見ると、両者が扱っている問題は驚くほど似ています。

違う入口から始まった二つのモールが、
なぜ同じ問いへ向き合うようになったのか。

ここからが、今回の本題です。

第5章　合計と内訳を分けなければ、取引を説明できない

Yahoo!ショッピングの注文APIでは、注文全体の合計金額を取得できます。同時に、商品単価、数量、送料、手数料、値引き、利用ポイントなど、その合計を構成する情報も取得できます。

楽天市場の受注データにも、請求金額、消費税、送料、手数料、割引金額、利用ポイント、商品単価、数量など、取引を説明するための項目があります。両者は項目名や持ち方が同じではありません。しかし、どちらも、注文全体の結果だけを持てば済むわけではありません。

例えば、注文金額が分かっても、その中に送料がいくら含まれているのか、ポイントがいくら使われたのか、値引きがどこへ反映されたのかが分からなければ、会計、返品、売上分析へ正しく渡すことができません。一つの合計と、その合計を構成する内訳。両方が必要になります。

Yahoo!ショッピングの仕様では、注文全体のクーポン値引額と、商品別のクーポン値引額を確認できます。合計があり、内訳があり、両者を突き合わせられる。

合計と内訳を分けることは、Yahoo!ショッピングだけの特殊な思想ではない。
取引を後の業務へ渡す受注データが、満たさなければならない条件だ。

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

合計値だけを渡せば、受け手は簡単に利用できます。しかし、その数字がどのように作られたのかは分かりにくくなります。内訳まで渡せば、受け手は自社の会計、在庫、分析の仕組みに合わせて検算し、再構成できます。その代わり、項目の意味と計算方法を理解する責任も、受け手側に生まれます。

第6章　同じ商品でも、計算の目的によって使う金額が変わる

商品には、販売価格があります。しかし、実際の注文では、一つの価格だけを持てば済むわけではありません。

同じ商品であっても、税、値引き、ポイントが参照する金額は同じとは限りません。例えば、税込1,100円の商品に、税込100円のクーポンを利用したとします。値引き後の税込価格は、1,000円です。値引きだけを見るなら、1,100円から100円を引けば終わります。しかし、ポイントを税抜価格を基準に計算するには、値引き後の税込金額から、税抜の基準額を求めなければなりません。1,000を1.1で割ると、整数にはなりません。

同じ一つの注文の中に、税込価格から差し引かれる値引き、税抜金額を基準にするポイント、税率によって計算される税額が同居します。Yahoo!ショッピングでは、2022年12月1日から、PayPayポイントの付与対象金額が、商品価格から消費税額を除いた金額へ変更されました。商品価格は一つでも、計算の目的によって参照する金額は一つではありません。だから受注データには、税込価格、税抜価格、値引き額、ポイント基準額など、複数の金額が必要になります。

端数を生んだのは、計算式そのものではない。
異なる基準を、一つの取引の中で使う制度だった。

第7章　継続する取引には、時間の情報が加わる

単発の購入と、定期購入や頒布会は、同じ商品を買う取引であっても、必要な情報が違います。単発購入では、その注文一回を処理すれば終わります。しかし定期購入では、何回目の購入なのか、どの周期で届けるのか、次回はいつなのか、通常購入と同じ価格なのか、どのポイント倍率を使うのか、という時間の情報が加わります。

Yahoo!ショッピングでは、定期購入について、次のような項目を持っています。

楽天市場でも、通常購入、予約商品、定期購入、頒布会を注文種別として区別しています。継続する取引を、一度きりの注文と同じ情報だけで表すことはできません。一回の注文に加えて、回数、周期、購入形態、適用条件という時間の軸が必要になるからです。

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

これは会員システムや継続課金にも通じます。同じ会員が、同じ商品を購入しているように見えても、契約開始日、継続回数、配送周期、価格、ポイント倍率が異なれば、同じ条件の取引として扱うことはできません。

第8章　仕様変更の履歴は、商売と制度の変化を記録している

現在の注文APIは、最初から現在の形だったわけではありません。仕様の変更履歴を見ると、その時代に、どのような条件が新しく加わったのかが見えてきます。Yahoo!ショッピングでは、2022年から2023年にかけて、次のような項目が追加されています。

この並びは、単なるプログラム改修の記録ではありません。定期購入が加わった。ポイント計算の基準が変わった。クーポンの内訳が必要になった。個別の販売条件が増えた。商売や制度に新しい条件が加わるたびに、それを表すためのデータ項目も増えています。

ポイント計算基準の変更と項目追加の関係は、その分かりやすい例です。Yahoo!ショッピングは2022年8月1日、同年12月ごろから、PayPayポイントの付与対象金額を、商品価格から消費税額を除いた金額へ変更する予定を告知しました。11月1日の案内では、実施日時が12月1日12時と確定しています。その後、商品税抜単価やポイント計算基準額が、注文データの項目として追加されました。

APIの変更履歴は、単なる技術更新の記録ではない。
その時代に、システムが何を新しく説明しなければならなくなったのかを記録した履歴でもある。

第9章　制度は問いを決める。しかし、答え方までは決めない

楽天市場とYahoo!ショッピングは、違う入口から始まりました。しかし、取引が増え、税、ポイント、値引き、定期購入を扱うようになると、両者は似た問いへ向き合います。

同じ問いへ向かったことは、日付にも表れています。楽天市場を含む楽天の対象サービスでは、2022年4月1日から、ポイント進呈対象金額に消費税を含めない方式へ変更されました。Yahoo!ショッピングも、同年12月1日から、ポイント付与対象を、商品価格から消費税額を除いた金額へ変更しました。

楽天市場は2022年4月1日。Yahoo!ショッピングは2022年12月1日。
八か月の差で、二つのモールが同じ方向へ動いた。

しかし、これを軽減税率への対応とだけ捉えると、時系列が合いません。軽減税率が始まったのは、2019年10月です。楽天が変更を発表したのは、その約2年後の2021年10月。実施は2022年4月でした。楽天が見ていたのは、過去に行われた一度の税制変更だけではなかったと考えられます。楽天の発表を報じた資料では、消費税率や将来の税制度の変更に影響されにくいポイント運営にすることや、事業者側の処理負担を軽減することが目的として説明されています。

年表を並べると、流れが見えます。

楽天が行ったのは、軽減税率への二年遅れの対応ではありません。税率や税制度が変わるたびに、楽天、店舗、提携先がポイントの設定や処理を直さなければならない構造から、ポイント制度を切り離す変更でした。

ただし、ここで証拠の強さを区別しておく必要があります。楽天PointClubの公式告知は、変更内容と適用条件を説明しています。一方、楽天の発表を報じた記事には、税率や税制度の変更に影響されにくいポイント運営へ移行する狙いが記録されています。Yahoo!ショッピングの公式告知も、変更内容、対象金額、計算方法を中心に説明しています。確認できた範囲では、その変更目的を詳しく伝える資料は見つかりませんでした。

つまり、両社の公式告知は、どちらも変更内容を中心に説明しています。楽天については、その変更目的が複数の報道に記録されています。Yahoo!ショッピングについては、確認できた範囲で同様の説明は見つかっていません。同じ問いに対する答え方の差は残りますが、それは公式告知同士の差というより、変更目的が公開情報として残っているかどうかの差です。

軽減税率が見えやすくしたもの

税込を基準にすると、税率で付与ポイントが変わる

軽減税率は、変更の直接原因とは言えません。しかし、税込金額をポイント基準にすることの弱さを、分かりやすくした出来事ではあります。税抜1,000円の商品で考えます。軽減税率8％なら、税込価格は1,080円です。標準税率10％なら、税込価格は1,100円です。

税込価格の1％をポイントとして付与し、小数点以下を切り捨てるなら、1,080円の商品は10ポイント、1,100円の商品は11ポイントになります。税抜価格は同じ1,000円でも、適用される税率だけで、付与ポイントが1ポイント変わります。税抜1,000円を基準にすれば、どちらも10ポイントです。

複数税率は、税込基準のポイント制度が税制変更の影響を受けることを、目に見える形にしました。ただし、これは本稿での読みです。楽天の発表を報じた記事に残る狙いは、将来の税率や税制度の変更に影響されにくいポイント運営へ移行することであり、Yahoo!ショッピングは、確認できた告知では変更理由を明示していません。

制度が二つのモールに突きつけた問いは共通していました。消費税を、ポイントの進呈対象に含め続けるのか。しかし、制度が決めるのは、解かなければならない問いまでです。その問いを、どの計算単位で処理し、どの項目として持ち、どのように店舗や開発者へ伝えるかには、各社の判断が残ります。

例えば、継続取引です。楽天市場では、通常購入、予約商品、定期購入、頒布会を注文種別として区別し、購入形態に応じた計算方法を持ちます。一方、Yahoo!ショッピングでは、定期購入フラグ、継続回数、配送サイクル、定期購入ポイント倍率などを、個別の項目として持ちます。両者が向き合っている問いは同じです。継続する取引を、一度きりの注文と同じ形では扱えない。しかし、購入形態によって注文種別や計算方法を切り替えるのか、継続回数・周期・倍率を個別の項目として表すのか、という答え方には違いがあります。

もう一つ違うのが、仕様の主な宛先です。楽天市場の受注仕様は、出店者や、店舗から許諾を得た連携事業者が利用するRMSを中心に提供されています。Yahoo!ショッピングの注文APIは、開発者向けサイトでAPIの種類や機能が説明されています。ただし、本番環境で注文関連APIを利用できるのは、所定の条件を満たす出店ストアです。

したがって、「Yahoo!は開かれており、楽天は閉じている」という単純な差ではありません。違うのは、仕様をどのような入口から説明し、利用者へ届けているかです。同じ受注情報でも、誰が使うことを前提に、どのような受け渡し口を設けるかには、設計上の選択が残ります。

制度は、問いを決める。
しかし、答え方までは決めない。

第10章　何が違い、何が同じになったのか

ここまで見てきた違いと共通点を、一つの表に並べます。

比較項目楽天市場Yahoo!ショッピング
出発点店舗が商売する市場商品を分類・検索する売り場
初期に前面へ出たもの店舗、店長、売り場商品、カテゴリー、検索
2004年に私が見たもの店舗運用を受け止めるデータ商品と注文を整理するデータ
現在向き合っている条件税、ポイント、値引き、継続取引税、ポイント、値引き、継続取引
公式告知の内容変更内容、適用条件、クーポンや定期決済の扱いを説明変更内容、対象金額、計算方法を説明
変更目的に関する公開情報税制変更に影響されにくい運営などの狙いが報道に残る確認できた範囲では、目的を詳しく伝える資料は未確認
継続取引への答え方購入形態で注文種別や計算方法を切り替える継続回数、配送周期、倍率を別項目として持つ
仕様の届け方RMSを中心に出店者・連携事業者へ提供開発者向けサイトで説明し、利用は出店ストアを対象とする

横スクロールで全項目を表示

四行目までは、二つのモールが、同じ商売上・制度上の問いへ向き合っていることを示しています。しかし、五行目以降を見ると、答え方や伝え方まで同じになったわけではありません。

THE CORE IDEA ── 設計思想
入口が違っても、制度と商売の変化は、異なるシステムに共通の問いを突きつける。

楽天市場とYahoo!ショッピングは、異なる入口から始まりました。その後、税、値引き、ポイント、定期購入という共通の問題に向き合います。制度や商売の変化によって、解かなければならない問いは似ていきました。

しかし、購入形態によって計算方法を切り替えるのか、倍率や周期を別項目として表すのか、店舗運用の中で使う仕様として提供するのか、開発者向けの入口から外部連携を説明するのか。その答え方には、違いが残りました。制度は、問いを決める。しかし、答え方までは決めない。

この設計が実現したことと、その代わりに複雑になったこと

設計上、区別しているもの実現できることその代わりに複雑になること
合計と内訳金額を検算し、会計・返品・分析に利用できる項目の関係と計算式を理解する必要がある
税込・税抜・値引き後価格税、値引き、ポイントを異なる基準で計算できる一つの商品に複数の金額が存在する
通常・予約・定期・頒布会購入形態ごとの処理ができる回数、周期、倍率、計算単位が増える
店舗運用向け仕様と外部連携向け仕様利用者に応じた運用と連携ができる同じ情報でも名称や取得方法が異なる

商売の条件を正確に扱おうとするほど、必要な情報は増えます。外部の制度へ正確に対応しようとするほど、計算基準や項目も増えます。しかし、どの情報をどの単位で持ち、誰へ渡すかは、一つの答えに決まりません。そこに、システムごとの判断が残ります。

まとめ　私が当時揃えていたもの

2004年ごろ、私は楽天市場とYahoo!ショッピングの売上データを、一つの形式へ変換していました。当時、二つのデータは違って見えました。項目名も違う。金額の置き場所も違う。注文と明細の分け方も違う。それぞれの会社が、独自の仕様を作っているのだと思っていました。

しかし二十年以上たった現在、両者が扱っているものを見ると、税、値引き、ポイント、定期購入という、同じ商売上・制度上の条件が並んでいます。異なる入口から始まっても、同じ取引を正確に処理し、同じ制度へ対応しようとすれば、解かなければならない問いは似てくる。それでも、どの単位で計算し、どの項目として持ち、誰に向けて情報を渡すかには、違いが残る。

私が当時揃えていたのは、二つの会社の独特な仕様ではなかったのかもしれません。

共通の問いに対する、二つの答えだった。

NEXT ── 次回予告
Amazonは、同じ問いにどのような答えを出したのか。

第1回で楽天市場、第2回でYahoo!ショッピングを見てきました。二つのモールは、異なる入口から始まりながら、制度と商売から突きつけられた共通の問いへ向き合いました。次回はAmazonです。Amazonもまた、税、値引き、出荷、決済という問いを避けることはできません。しかし、その答え方は、日本の二つのモールとは異なっていました。買うまでの摩擦を減らすために、Amazonは何を共通化し、何を利用者から見えなくしたのか。制度が問いを決める中で、Amazonはどのような答えを選んだのか。その設計判断をたどります。

連載の続きを見る

エビデンス・参考資料

一次資料・公式情報
変更目的を伝える報道

本文で述べた「税制変更に影響されにくいポイント運営」という変更目的は、公式告知ではなく報道に記録されています。読者が無料で検証できるECのミカタを主資料としています。

参照日：2026年7月27日
※楽天が公表したポイント制度変更の目的と、報道による補足説明は、本文で区別して記載しています。※軽減税率は、楽天市場およびYahoo!ショッピングのポイント基準変更の直接原因とは断定していません。本稿では、税込基準のポイント制度が税制変更の影響を受けることを見えやすくした制度的背景として扱っています。※楽天市場の受注項目を根拠とする箇所については、参照した連携仕様資料の提供会社名、正式な文書名、版または更新日を、公開前に参考資料欄へ追加する必要があります。現時点で未確認の書誌情報を推測して記載することはしていません。本連載は、公表されている技術仕様・公式ドキュメントと、筆者の長年の実務経験および考察をもとに構成しています。Yahoo! JAPAN および楽天グループ内部の設計やアルゴリズムを、推測によって断定するものではありません。

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

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

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

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