日本のECは、 どこで世界と分かれたのか　第1回

2004年から2012年に、何が起きていたか 日本と海外の併走年表から、その源流をたどる。
海外のEC業界の議論を追っていると、いつも同じところで引っかかる。

向こうで交わされているのは「AIエージェントに、商品と在庫と決済を、どのAPIで見せるか」という話だ。日本の会議室で交わされているのは「次のリプレースはいつ、いくらでやるか」という話である。同じ産業の話をしているとは思えない。

日本のECソフトウェアは、世界の標準から決定的に遅れている。これは印象論ではない。20年分の年表を並べると、どこで分かれ、なぜ差が開き続けたのかが、はっきり見える。

そして、この遅れは、これから致命傷になる。AIが実装作業そのものを引き受けはじめた今、どの基盤に乗っているかが、開発の速さと事業の伸びを直接左右するからだ。

日本と海外のECテクノロジーが分かれたのは、技術力の差ではない。2004年から2012年にかけて、「新しい機能が、誰のお金で増えるか」という仕組みが、両者で別のものになったからだ。

その差が20年かけて複利で開いた。年表を1段ずつ見ていきたい。

併走年表 ／ 海外と日本はどこで分岐したか

1994–2003　黎明とパッケージの時代

解説01　出発点は、ほとんど同じだった

1994年から95年にかけて、アメリカでAmazonとeBayが生まれる。同じくアメリカのNetscapeがSSLを実装し、「Webでカードが使える」という前提がようやく成立した。

そのあと登場したのは、重厚なECパッケージだ。ATG Dynamo（米国）、BroadVision（米国）、そしてIntershop（ドイツ）。高額なライセンスを買い、SIer——一社ごとに要件を聞いて、その会社専用にソフトを作り込むベンダーのことだ——が構築する。海外のECも、最初から身軽だったわけではない。

ただ、日本と決定的に違ったことが一つある。海外では、日本ほどモール型のECが成功しなかった。eBayはオークションサイトとして始まっており、店舗が軒を並べる場所にはならなかった。売りたい会社は、自分のサイトを自分で立てるしかない。その需要に応えて、自社サイトを構築するためのソフトウェアが、次々に生まれた。

もっとも、当時のそれは高価だった。しかもSI（システムインテグレーション。買った製品の上に、その会社専用の追加開発を重ねる仕事のこと）が前提である。つまり2000年前後の海外のECは、いまの日本のECとよく似た環境にいた。いま日本のEC事業者が立っている場所を、海外は20年以上前に通り過ぎている。

日本はどうか。1997年に楽天市場が開業する。1999年にYahoo!ショッピングが始まる。世界的に見ても早い立ち上がりで、しかも商業的に大成功した。日本のECは、出遅れるどころか先行していた。

ただ、この成功には構造がひとつ埋め込まれていた。楽天もYahoo!も、集客と決済という、EC事業でいちばん重い2つの機能をモール側が持つ設計だった。店舗は「出店する」だけで商売が成立する。

店舗にとって、これは合理的な選択だった。だが同時に、店舗が自分の技術基盤に投資する動機を、構造として消した。投資しなくても売れる場所に、投資する理由は生まれない。

そして、この構造は今も続いている。日本のEC事業者の多くは、いまも売上の大半をモールで作っている。自社サイトを主戦場として運営できている事業者は、少数だ。多くの会社にとって自社サイトは、モールの補完であって、経営の主戦場ではない。

振り返ってみれば、この初期のモール型ECの成功こそが、日本のECテクノロジーの成長を妨げた最大の要因をつくった。主戦場でない場所の技術に、経営が本気の投資をするはずがない。そして、本当に効いたのはその先だ。投資が起きなければ、自社サイト向けECソフトウェアの市場そのものが小さいままになる。市場が小さければ、ソフトウェア会社は研究開発に金をかけられない。製品が良くならなければ、事業者はますます自社サイトに投資しない。

買い手が投資しないから市場が育たず、市場が育たないから製品が良くならず、製品が良くならないから買い手が投資しない。この循環が、20年回り続けた。

併走年表 ／ 分岐点

2004–2012　分岐点　SaaS化 vs 作り込み

解説02　分岐は、2004年から2012年に起きた

2004年、アメリカでDemandwareが創業する。ECを売り切りのパッケージではなく、SaaSとして提供する会社だ。創業者のStephan Schambachは、その前にドイツでIntershopを創業した人物である。さきほど挙げた、重厚なパッケージの一つだ。自分が作ったモデルの限界を、自分で最初に見限った。

2006年、カナダでShopifyがローンチする。同じ年、アメリカのAmazonがAWSを立ち上げ、「サーバーを持たずにサービスを作る」前提が揃う。2008年にMagento 1.0（米国）、2009年にShopify App Store。

これはアメリカだけの話ではない。ドイツ、カナダ、アメリカ。ソフトウェアを製品として売る文化のある国が、それぞれに同じ方向へ動いた。一国の偶然ではなく、産業構造の転換である。

確立したのは、単なる新製品ではない。「プラットフォーム＋アプリのエコシステム」という、OSに近い事業構造である。売り切りから継続課金へ。作って納めて終わり、から、継続的に進化させ続けることへ。ソフトウェア会社の稼ぎ方そのものが入れ替わった。

同じ時期、日本で何が起きていたか。2004年前後にMakeShopやカラーミーショップといったASPカートが中小事業者に普及する。2006年にはオープンソースのEC-CUBEが登場する。エンタープライズ層では、ecbeing、コマース21、W2といった国産パッケージに個社カスタマイズを重ねる形が標準になった。

日本の事業者が国産パッケージ＋カスタマイズを選んだのは、当時としては合理的な判断だった。技術がなかったわけでも、目が曇っていたわけでもない。日本市場の要件に、日本のソフトウェアが正面から応えた結果である。

だが、その間に、海外の標準は別のものになっていた。カスタマイズ無しで使える標準機能と、アプリで足りない分を足す仕組み。日本のECテクノロジーの遅れは、ここで決定的になった。

解説03　決定的だったのは、「機能が誰のお金で増えるか」

では、何が決定的だったのか。

日本が個別カスタマイズ前提のECパッケージという商売を広げていたころ、海外のソフトウェア会社同士は、血みどろの戦いをしていた。一社ごとに作り込まない世界では、勝ち方が違う。評判が広がってデファクトになれば、一気に大きなシェアが取れる。取れれば、そのまま巨大な事業になる。

Demandware、Magento、Shopify、そしてその他大勢が、同じ顧客を奪い合った。勝つには、機能で差をつけるしかない。だから各社は、ある顧客が要望した機能を、次のリリースで全顧客向けの標準機能として実装した。取り込んで、追加費用なしで全員に配って、また次の差別化を探す。これを10年やり続けた。

その競争は、いまも同じ速さで続いている。Shopifyは年2回、新機能をまとめて公開する。直近の一回（2026年のWinter Edition）で出た新機能・改善は150件以上、12の領域にわたる。App Storeのアプリは17,600本を超え、直近30日だけで564本増えた。いずれも、すでに使っている事業者が、追加の開発費を払わずに受け取るものである。

1社が要望を出す。ベンダーがそれを製品に取り込む。次のリリースで、全顧客に配られる。この回路が20年回り続けた結果が、半年で150件という数字だ。

海外の事業者は、ベンダーが競争で消耗した分の成果を、追加の開発費を出さずに毎年受け取り続けた。自分では1円も払っていない機能が、勝手に増えていく。iPhoneのOSアップデートで、頼んでもいない新機能が毎年降ってくるのと同じ構造だ。

日本ではどうだったか。同じ「こういう機能が欲しい」という要望が、個社カスタマイズという形で処理された。開発費を払うのは、要望を出した1社。出来上がった機能を使えるのも、その1社だけ。

同じ要望なのに、片方では業界全体の標準機能になり、もう片方では一社の追加開発費で終わる。これが年に何百件、10年続いたらどうなるか。想像するまでもない。

しかも日本側の構造には、もうひとつ厄介な性質がある。カスタマイズを積むほど、そのシステムは他社製品に乗り換えにくくなる。乗り換えにくいということは、ベンダーは競争にさらされにくいということだ。競争にさらされないベンダーには、一社のための開発を全顧客向けの標準機能に作り直す動機が生まれない。

海外では競争が製品を進化させ、日本では受注が製品の進化を止めた。誰かが手を抜いたわけではなく、そういう構造だったということだ。

併走年表 ／ API経済とヘッドレス

2013–2019　API経済とヘッドレス

用語ノート

ヘッドレス：お客が見る画面（ヘッド）と、商品・在庫・決済を処理する裏側を切り離す作り方。裏側を触らずに画面だけ作り替えられる。

APIファースト：製品を「画面つきのシステム」ではなく「APIの集合」として設計する考え方。他社のサービスに部品として組み込まれることを前提にする。

解説04　目的が違えば、20年後の到達点は違う

2013年以降、海外では話が一段上がる。アメリカのStripeに代表されるAPIファースト企業——API（ソフト同士がデータをやり取りする窓口。人が画面を操作しなくても、機械どうしが直接つながる）を製品の本体として売る会社だ——が台頭し、ドイツのcommercetoolsが「コマース機能をすべてAPIで提供する」というモデルを示した。2016年にSalesforce（米国）がDemandwareを約28億ドルで、2018年にAdobe（米国）がMagentoを約17億ドルで買収する。ECが「サイトを作るツール」から、企業のITスタックの中核部品へと格上げされた瞬間である。

日本にも変化はあった。2012年にBASEとSTORESがロングテール層を開拓し、2017年にはShopifyの日本法人ができた。だが、エンタープライズ層の構造はほぼ無傷のまま残った。大手の自社ECは今も、パッケージのカスタマイズと、数年がかりのリプレース案件が主流である。

ここで、日本のEC刷新プロジェクトの要件定義書を思い出してほしい。ページ数の大半を占めているのは何か。基幹システムとの連携。在庫マスタの同期。会計への計上。既存の業務フローの再現。

日本のEC刷新は、売上を増やすためのプロジェクトではなく、社内システムと正しくつながるためのプロジェクトになっている。

これは担当者が悪いのではない。発注が情報システム部門から出て、評価軸が「止まらないこと」「既存業務が変わらないこと」になっていれば、要件定義書はそうなるしかない。

海外は違う。ECは売上を作る装置であり、機能追加の速さがそのまま売上に効く。だから評価軸は「どれだけ速く試せるか」になる。ヘッドレスもAPIファーストも、思想として美しいから広まったのではない。画面を作り替える速さが、そのまま売上に直結したから広まった。

同じものを買っているように見えて、買う目的が違う。目的が違えば、20年後の到達点が違うのは当然だ。

この20年、日本がECテクノロジーに投じた金額は、決して少なくない。だが、その大半は「売上を増やすため」ではなく「社内とつなぐため」に使われた。ここが、いちばん取り返しのつかない差だと僕は考えている。

併走年表 ／ Composable・MACHの制度化

2020–2023　Composable / MACHの制度化

用語ノート

MACH：Microservices（機能を小さな部品に分ける）、API-first、Cloud-native（クラウド前提で作る）、Headlessの頭文字。基盤を選ぶときのチェック項目として使われる。

コンポーザブル・コマース：ECを一枚のシステムとして買わず、検索・決済・在庫などを別々の製品で組み合わせ、要らなくなった部品だけ差し替える買い方。

マイクロサービス：大きなシステムを、独立して動く小さなサービスの集まりとして作る方式。一部だけ直しても全体を止めずに済む。

解説05　語彙すら、輸入されていない

2020年6月、MACH Allianceが設立される。中心にいたのは、ドイツのcommercetools、アメリカのcontentstack、アメリカのEPAM、フランスのValtechだ。Microservices、API-first、Cloud-native、Headless——この4語の頭文字がMACHである。技術者の合言葉ではない。企業がECの基盤を買うときの、調達基準の語彙になった。

いま、この団体に名を連ねているのは、外資のEC専業ベンダーだけではない。AWS、Google Cloud、Stripe、PayPal（いずれも米国）といったインフラ・決済の大手、Accenture、Deloitte Digital、Publicis Sapientといった大手のシステム構築会社まで入っている。認定メンバーとパートナーは、あわせて124社（2026年8月時点）。つまりこれは、一部のベンダーが掲げた理想ではなく、業界の側が制度としてつくったものだ。

同じ頃、アメリカのGartnerがコンポーザブル・コマースを提唱する。コロナ禍のEC急拡大で、作り込んだ一枚岩（モノリス。一つのソフトが単一のコードベースでできていて、保守がしにくく、機能を足すのにも時間がかかる作り）の「変更の遅さ」が、誰の目にも見えるようになった。2023年にはカナダのShopify自身がCommerce Componentsを出し、この要求に応えている。

日本ではどうか。

コンポーザブルという語は、たまに目にする。ただし、その大半は外資ベンダーが自社製品を説明する資料の中だ。日本の事業者どうしの会話で自然に出てくる語には、なっていない。MACHに至っては、日本語のまとまった解説を探すこと自体が難しい。

設立から6年が経つ。これほど重要なECテクノロジーの動きが、日本語ではまともに紹介されていない。日本のECがガラパゴス化していることを示す、いちばんわかりやすい証拠である。

解説06　輸入されなかったのは、語彙ではなく買い方だ

日本には、この語彙が輸入されなかった。そして、その裏にあった調達様式の転換は、なおさら輸入されなかった。

RFPを書き、要件を定義し、検収し、5年から10年使う。この買い方そのものは、20年前とほとんど変わっていない。海外で起きたのは、アーキテクチャの変化である以上に、買い方の変化だった。買い方が変わらなければ、どんなに新しい製品を入れても、結局は同じ形に作り込まれる。

国産SaaSはどうか。ecforceのような国産SaaSは、確かに伸びている。買い切りではなく月額で、機能も継続的に増えていく。海外が2004年から2012年にやったことを、日本のD2C領域で実装したものだと言っていい。

ただし、そこで増える機能は、日本市場向けに最適化された機能だ。世界中の事業者が要望を出し合って厚くなっていく海外プラットフォームとは、母数が違う。国産SaaSの台頭は、ガラパゴスの中でのSaaS化であって、ガラパゴスからの脱出ではない。

そして、そのガラパゴスの起点は、1997年にある。楽天とYahoo!ショッピングは、確かに成功した。だがそれは、日本の消費者と日本の店舗にとっての成功であって、日本のECソフトウェアにとっては、世界から切り離される起点だった。モール型ECの成功は、日本のEC産業がガラパゴス化した最初の一例である。

併走年表 ／ 現在地

2024–現在　Agentic Commerce 

用語ノート

AIエージェント：人間の指示を受けて、調べる・選ぶ・申し込むといった一連の作業を自分で進めるAI。従来のAIが「答える」のに対し、こちらは「動く」。 ACP／AP2／UCP：AIが人間に代わって商品を選び、決済まで済ませるための通信の取り決め。要するに、AIが買い物をするための規格。いま複数の陣営が競っている。 AIコーディング：AIにプログラムを書かせる開発の進め方。実装作業そのものを大幅に短縮できるが、効きの大きさは基盤によって差が出る。

解説07　いま、論点は入口そのものに移っている

2024年12月、Microsoft（米国）のサティア・ナデラCEOが、ポッドキャストでこんな趣旨のことを言っている。SaaSアプリケーションというのは、要するにデータを出し入れする仕組みと業務ルールの塊にすぎない。エージェントの時代には、その概念そのものが溶けていく、と。

そして2025年9月、アメリカのStripeとOpenAIがACPを、同じくアメリカのGoogleがAP2を、相次いで発表した。どちらも、AIエージェントが人間に代わって商品を選び、決済まで済ませるための取り決めである。要するに、AIが買い物をするための通信規格だ。2026年1月にはカナダのShopifyとGoogleのUCPが出て、その一方で2026年3月には、ACP経由のInstant Checkoutが撤退している。

正直に言えば、僕にもどれが勝つかはわからない。半年単位で前提が組み替わっている最中だ。

ただ、論点が何に移ったかははっきりしている。「サイトをどう作るか」ではなく、「エージェントに商品・在庫・決済をどのAPIで見せるか」だ。買い物の入口そのものが、作り直しの対象になっている。

日本ではどうか。生成AIの議論は、サイト内検索やAI接客といったフロントの改善に留まっているのが主流だ。エージェントに対して自社の商品データや在庫をどう露出するかが経営会議の議題に上がったという話を、僕はまだほとんど聞かない。

議題に上がらないのは、関心がないからではない。目の前にあるのが、5年使った基盤をどう作り直すかという話だからだ。入口の設計を考える前に、入口の工事の稟議が回ってくる。

まとめ ／ 30年で、何が積み上がったか

結論 ／ 次の5年で、差はもっと速く開く

僕は、過去の意思決定を愚かだったと言うつもりはない。1997年の判断も、2004年以降に日本の多くの企業がそれを踏襲した判断も、当時としては合理的だった。日本の商習慣に応えた国産パッケージ群がなければ、日本のECは今の規模になっていない。

疑うべきなのは、その最適化がとうに前提を失っているのに、同じ最適化を続けている今の判断のほうだ。

そして、いちばん警戒すべきなのはここから先である。AIにコードを書かせると、開発は確実に速くなる。ただし、速くなる度合いは基盤によってまるで違う。

Shopify、Magento、commercetools。海外のプラットフォームは、技術資料が公開されている。コードもGitHub——世界中の開発者がプログラムを置いて共有している場所だ——に載っている。そして、AIはそこを学習済みである。だから海外プラットフォームの上でAIにコードを書かせると、AIは「この製品では、こう書くのが定石だ」を知った状態で書き始める。

国産パッケージには、それがない。技術資料は契約した会社にしか渡らず、コードは公開されていない。AIはその現場のコードを読んで手伝うことはできる。だが、定石を持っていない。参照できる実例が、世界のどこにもないからだ。

つまり、これまで「乗り換えにくいから」という理由で温存されてきた作り込みが、これから先は「AIの恩恵を受けにくいから」という理由で、はっきりコストになる。20年かけて開いた差が、次はもっと短い期間で開く。

ただし、これは絶望の話ではない。20年前、日本の事業者には海外プラットフォームを選ぶ理由がなかった。日本の商習慣に応えられなかったからだ。今は違う。海外プラットフォームは日本の決済にも配送にも対応し、日本語での実装事例も積み上がった。熨斗や複雑な同梱ルールのように、いまも国産のほうが強い領域はある。だが、「日本の要件に合わないから使えない」という20年来の言い訳は、もう成立しない。

日本の失われた30年は、誰かが間違った決断をした結果ではない。決断を先送りにし続けた結果だ。ECテクノロジーで、同じことを繰り返してはいけない。

だから、次のリプレースの稟議書で問う質問を変えてほしい。「いくらかかるか」ではなく、この2つを問う。

次の稟議で足す、2つの問い

1. この基盤を選んだ場合、5年後に、我々が1円も追加で払わずに増えている機能はいくつあるか。
2. この基盤の上でAIにコードを書かせたとき、AIが参照できる公開情報は、世界にどれだけあるか。

1つめに、ベンダーがすぐ答えられるか。ゼロだと答えるなら、その5年間の進化のコストは全部こちら持ちだということだ。2つめに答えられないなら、その基盤の上では、これから起きる開発コストの低下を受け取れない。

質問を2つ足すだけだ。大きな改革の話ではない。だが、この2問は、20年分の構造の差と、これから5年で開く差を、まっすぐ突いている。次の稟議から始められる。

次回は、この「機能が誰のお金で増えるか」の差が、実際にどれだけの開きになっているのかを、具体的な数字で見ていきたい。

宗像 淳 / イノーバCEO

経歴

福島県立安積高校、東京大学文学部卒業。ペンシルバニア大学ウォートン校MBA（マーケティング専攻）。

1998年に富士通に入社し、北米ビジネスにおけるオペレーション構築や価格戦略、子会社の経営管理等の広汎な業務を経験。MBA留学後、楽天で物流事業、ネクスパス（現トーチライト、博報堂DYグループ）でソーシャルメディアマーケティング事業の立ち上げを担当。ネクスパスでは、事業開発部長として米国のベンチャー企業との提携を主導した。

2011年、マーケティング支援会社である株式会社イノーバを設立、代表取締役に就任。日本におけるコンテンツマーケティング/BtoBマーケティングの第一人者として、15年以上にわたり5000社以上の経営課題やマーケティング・営業課題を分析し、幅広い業界で企業の事業成長に貢献。「事業を伸ばすには実行力が重要であり、実行力とは組織・人である」という哲学で、人にこだわった支援会社づくりに取り組んでいる。

2026年2月、最新刊『いちばんやさしいAI時代のコンテンツマーケティングの教本』（インプレス）を上梓。著書に『商品を売るな　コンテンツマーケティングで「見つけてもらう」仕組みを作る』（日経BP社）、『いちばんやさしいコンテンツマーケティングの教本』（インプレス）。
X（旧Twitter） ｜ Facebook ｜ LinkedIn ｜ note