グローバル小売のデータ基盤設計実務｜中央統制と各国活用の両立

グローバル小売では、同じ「売上」や「顧客」という言葉でも、国やチャネルによって意味が変わります。
税込か税抜か、返品をいつ控除するか、ポイント値引きをどう扱うか、ECと店舗を同じ顧客として見るか。
本社の経営会議では横並びに比較したい一方、各国のマーケティング担当者は、現地の商習慣、季節、祝日、販促ルールに合わせて数字を見たいはずです。

このずれを放置すると、データ基盤チームは毎月同じような確認に追われます。
本社から見ると各国の数字が比較しにくく、各国から見ると本社の共通ルールが現場の施策に合いません。
AI活用を進める段階では、このずれがさらに大きな問題になります。
AIが売上、在庫、会員、商品カテゴリを別々の意味で解釈すれば、レコメンド、需要予測、CRM施策の提案も前提を誤ります。

従来型とAI時代の違い

従来型とAI時代の違いは、次のように整理できます。

観点	従来型	AI時代
グローバル統合	各国データをDWHへ統合	AIが共通の意味で使える状態にする
ガバナンス	品質、権限、データモデルを管理	AIの参照・判断・実行範囲まで管理
KPI	BIやレポート向けに統一	人間、BI、ML、AIの共通言語にする
マーケティング	CRM・MA向けデータを供給	AIが施策やレコメンド案を支援する
データ・ナレッジ	POS、EC、会員、在庫が中心	SNS、天候、レビュー、業務知見も扱う
意思決定	人間が分析結果を解釈	人間がAIの仮説や施策候補を評価する

重要なのは、AI時代でも人間の判断が消えるわけではないことです。
むしろ、本社、各国責任者、マーケティング担当者、MD、店舗運営責任者が、どの定義で判断するのかを先に決める必要があります。

お問い合わせ

匿名ケースで目指した基盤

ここでは、大手アパレル製造小売企業の匿名化ケースをもとに、基盤づくりの目的を整理します。
実施済みの整備範囲と、将来のAI活用へつながる範囲を分けて読む必要があります。

本社統制と現地活用を同時に満たす

匿名ケースでは、世界各国に店舗を展開する大手アパレル製造小売企業が、グローバルなデータ活用基盤を整備しました。
目的は、日本本社がデータ品質、権限、KPI、顧客・商品・店舗の基本定義を管理しながら、各国や地域の担当者がマーケティング、分析、店舗運営に必要なデータを使える状態にすることでした。

対象は、単なる経営レポート基盤ではありません。
ECと店舗のデータ統合、KPI可視化、CRM・MA連携、マーケティング分析、商品・在庫・顧客分析、店舗運営支援、レコメンド開発の土台まで含みます。
ただし、ここで注意すべきなのは、すべてのAI機能を実装したという話ではないことです。
このケースで整えたのは、将来のレコメンド、需要予測、MD支援、CRM施策提案へ発展できるデータと運用の土台です。

共通化する領域と各国に残す領域

本社が一方的に共通ルールを押し付けると、各国の施策スピードは落ちます。
反対に、各国が自由にデータを加工し続けると、どの売上が正式な数字なのか、どの顧客セグメントが有効なのか、本社が把握できなくなります。
このケースの設計論点は、統制と自由度をどちらかに寄せることではなく、共通化する領域と各国に残す領域を分けることにありました。

扱うデータと利用部門

グローバル小売のデータ基盤は、情報システム部門だけの管理対象ではありません。
商品、顧客、在庫、施策のデータを、どの部門が何に使うのかまで決めることで、基盤の設計粒度が見えてきます。

SKUと商品注釈情報

グローバル小売のデータ基盤では、店舗、EC、商品、在庫、顧客、会員、広告、アプリ、POSなどのデータを横断して扱います。
アパレル製造小売では、SKU単位の商品情報も重要です。
SKUとは、サイズ、色、型などを含めた在庫管理上の最小単位です。
同じ商品名でも、色やサイズが違えば、在庫、売れ行き、レコメンドの判断は変わります。

このケースでは、商品注釈情報も重要な対象になりました。
商品注釈情報とは、色、形、素材、特徴、カテゴリなど、商品を理解するための属性情報です。
たとえば、同じ黒い上着でも、素材、厚み、用途、季節性、シルエットが違えば、顧客へのおすすめや在庫判断は変わります。
AIやレコメンドモデルに商品を理解させるには、商品マスタの品番だけでなく、こうした属性を管理する必要があります。

部門別の使い道

主なデータと利用部門は、次のように整理できます。

データ	利用部門	主な用途
店舗・POS	店舗運営、営業企画	売上分析、店舗支援
EC・アプリ	EC、CRM、MA	行動分析、施策配信
商品・SKU	MD、商品企画	商品分析、在庫判断
顧客・会員	CRM、マーケティング	セグメント、LTV分析
在庫	SCM、店舗、EC	欠品把握、配分判断
広告・施策	マーケティング	効果測定、予算配分

データ基盤チームだけで完結するテーマではありません。
MDが商品をどう見ているか、店舗責任者が現場で何を判断しているか、CRM担当者がどの粒度で顧客を分けたいか。
こうした業務側の判断を入れないと、基盤は整っているのに施策で使いにくい状態になります。

中央統制と各国活用の分け方

中央統制と各国活用は、どちらかを選ぶ話ではありません。
本社が責任を持つ領域、各国に任せる領域、その間をつなぐ領域を分けて設計します。

本社が責任を持つ領域

中央統制で管理すべきものは、全社で比較・監査・再利用するための土台です。
データ品質、セキュリティ、アクセス権限、顧客ID、商品ID、店舗ID、KPIの基本定義、データモデル、更新ルールは、本社またはグローバルの基盤チームが責任を持つ必要があります。
ここが曖昧だと、各国が似た処理を別々に作り、数字が合わなくなります。

各国に残す領域

一方で、各国に残すべき領域もあります。
地域ごとのキャンペーン、現地の祝日や季節性、会員施策、店舗商圏、ローカルセグメント、SNS反応、文化的な嗜好は、本社の共通ルールだけでは判断できません。
各国担当者が素早く仮説検証できるデータマートや分析環境を持たなければ、現場の施策は遅れます。

共通化とローカル拡張の境界

設計上は、次のように分けると整理しやすくなります。

グローバル共通: 売上、返品、会員、商品、在庫、店舗、会計期間、権限、監査ログ
ローカル固有: キャンペーン、季節イベント、地域セグメント、現地販促、チャネル別施策
接続領域: 共通KPIを使いながら、各国が追加指標を定義できるSemantic Layer

「すべてを本社で統一する」設計は、きれいに見えても運用で詰まりやすいです。
「各国に任せる」設計は、短期的には早く見えても、全社比較やAI活用で前提が崩れます。
本社と各国の役割を、データ定義、権限、SLA、変更管理で分けることが現実的です。

people-walking-through-data-center-corridor

AI時代のデータ基盤とは？BI・DWHからAIが使える基盤へ

生成AIやAIエージェントを業務で使うには、ツール選定より先に、自社のデータ、業務文書、会話、KPI定義、権限をAIが安全に参照できる状態へ整える必要があります。この記事では、従来のBI・DWH中心のデータ統合基盤と、AI時代に必要なデータ・ナレッジ基盤の違いを、経営者と実務担当者の双方が判断できる形で解説します。

マーケティング施策ごとに異なるSLA

データ基盤のSLAは、速ければよいというものではありません。
施策ごとに必要な鮮度と許容できる遅延を分けることで、投資すべき処理とそうでない処理を判断できます。

施策別に必要な鮮度を分ける

グローバル小売のデータ基盤では、データの鮮度をすべて同じ水準にそろえる必要はありません。
月次の経営レポート、日次の売上分析、CRMセグメント、MA配信、ECレコメンド、在庫連携、店舗業務支援、キャンペーン効果測定では、求められる更新頻度と許容遅延が違います。
ここを分けずに「リアルタイム化」を目標にすると、費用と運用負荷だけが増えます。

たとえば、経営会議で見る月次指標は、厳密な確定値と説明可能性が重要です。
ECレコメンドでは、顧客行動や在庫の鮮度が成果に影響します。
CRMセグメントでは、配信前に対象者を確定し、除外条件や同意管理を確認する必要があります。
店舗支援では、現場が使う時間帯に間に合うことが重要です。

SLAは業務側と決める

SLAは、技術部門だけで決めるものではありません。
マーケティング、EC、店舗運営、MD、情報システム、法務・セキュリティが、どの施策でどの鮮度が必要かを決めます。
そのうえで、リアルタイム、日次、週次、月次、手動確認ありの処理を分ける。
この切り分けがないと、重要ではない処理まで高コストになり、本当に鮮度が必要な施策に投資しにくくなります。

パイプラインが複雑化する理由

各国や各部門が必要な処理を個別に作ると、短期的には早く進んでいるように見えます。
ただし、後から定義の重複や影響範囲の不明確さが増え、AIが参照するデータの説明もしにくくなります。

個別最適が重複処理を増やす

各国、各部門、各キャンペーンが個別にデータパイプラインを作り始めると、基盤はすぐに複雑化します。
同じ売上データを別々の処理で変換し、同じ顧客セグメントを別々の条件で作り、似たような商品カテゴリを国ごとに持つ。
最初は早く見えますが、数か月後には、どの処理が正しいのか、どの上流データを変えると何が壊れるのか分からなくなります。

よく起きる問題は、重複変換、指標定義の重複、source of truthの不明確さ、上流影響の不明、障害調査の長期化、国別の類似処理、データリネージの欠如です。
データリネージとは、あるデータがどの元データから作られ、どの加工を経て、どのレポートや施策で使われているかを追える状態を指します。

AI活用で説明責任が重くなる

AI活用では、この問題がさらに重くなります。
AIが参照するデータの出所が分からなければ、回答の根拠を説明できません。
需要予測やレコメンドの結果が悪化したときも、商品マスタ、在庫、価格、キャンペーン、顧客データのどこに原因があるのか調べにくくなります。
パイプライン設計では、速く作ることだけでなく、誰が定義を持ち、どこで再利用し、どこから先を各国が拡張してよいかを決める必要があります。

Semantic LayerでKPIをつなぐ

Semantic Layerは、単にBIの指標を見やすくするための層ではありません。
本社と各国、人間とAIが同じ業務用語を使うために、KPIや用語の意味を管理する役割を持ちます。

共通KPIとローカルKPIを階層化する

Semantic Layerは、グローバル共通のKPIと各国固有のKPIをつなぐ層です。
小売では、売上、粗利、返品、値引き、ポイント、会員、アクティブ顧客、在庫評価、営業日、会計期間、商品カテゴリなど、多くの定義が国やチャネルでずれます。
これをすべて単一の定義に押し込むと、現場の意味が消えます。
一方で、すべてを各国定義にすると、全社比較ができません。

現実的には、グローバル共通指標、各国ローカル指標、施策固有指標を階層化します。
たとえば、本社の経営会議で使う売上は共通定義にします。
各国のキャンペーン評価では、現地の商習慣に合わせた追加指標を持てるようにします。
AIやBIが自然言語で質問を受けたときには、「どの売上か」「どの会員か」「どの期間か」を明示できるようにします。

定義すべきKPIと用語

整理すべき論点は、次のようなものです。

KPI・用語	定義で決めること	放置した場合
売上	税、返品、値引き、通貨	国別比較がずれる
会員	登録、購入、休眠、統合ID	顧客数が重複する
在庫	店舗、倉庫、引当、評価額	欠品判断を誤る
期間	営業日、週、月、会計期	施策比較が合わない
商品カテゴリ	グローバル分類、現地分類	レコメンドが粗くなる
施策成果	広告、CRM、MA、EC	効果測定が分断される

AIが同じ業務用語を使える状態にする

Semantic Layerは、BIのためだけにあるわけではありません。
人間、BI、機械学習モデル、生成AIが同じ業務用語を使うための共通言語です。
AIに「先週、休眠会員向け施策で反応がよかったカテゴリを出して」と聞くなら、先週、休眠会員、反応、カテゴリの定義が必要になります。
この定義を持たないままAIを導入すると、回答はもっともらしくても、施策判断には使いにくくなります。

AI時代に追加するデータ

AI活用に進むと、POS、EC、会員、在庫のような構造化データだけでは判断材料が足りません。
ただし、すべてのデータを一度に取り込むのではなく、施策に直結する範囲から追加していく必要があります。

需要予測・レコメンド・MD支援で見るデータ

AI時代の小売データ基盤では、POS、EC、会員、在庫だけを整えても十分ではありません。
天候、SNS反応、レビュー、コラボレーション施策、地域トレンド、文化・季節性、店舗スタッフの報告、VOC、商品企画仮説、MDの知見、経営者の判断履歴も、AIが参照する候補になります。
ただし、何でも取り込めばよいわけではありません。

たとえば、需要予測では過去売上と在庫だけでなく、天候、地域イベント、キャンペーン、商品の季節性が影響します。
レコメンドでは、購買履歴だけでなく、商品注釈情報、閲覧行動、在庫状況、返品傾向も関係します。
MD支援では、商品企画の仮説、レビュー、店舗スタッフの声、SNSでの反応を扱えると、次の商品判断に使いやすくなります。

最初からすべてをAIに読ませない

ここでも、構築済みの基盤と将来活用を分けて考える必要があります。
最初からすべての非構造化データをAIに読ませるのではなく、施策に直結する範囲から始めます。
たとえば、ECレコメンドなら商品属性と在庫、CRMなら会員セグメントと同意管理、MDなら商品企画資料とレビュー、店舗支援なら日次売上とスタッフ報告。
業務ごとに、参照してよいデータ、更新頻度、権限、出典表示、責任者を決めます。

AI活用の成否は、モデルの性能だけでは決まりません。
企業側が、どのデータを正として扱い、どの知見を残し、どの判断を人間が承認するかを設計できるかで変わります。

まとめ

グローバル小売のデータ基盤は、各国データを集めるプロジェクトではありません。

本社が比較・監査・再利用できる共通定義を持ち、各国が地域ごとの施策を素早く試せる余地を残す設計です。

売上、会員、商品、在庫、店舗、期間、施策成果の定義を曖昧にしたままAI活用へ進むと、AIは誤った前提で回答や提案を作ります。

最初に整えるべきものは、ツール名ではなく、責任分界です。

本社が持つKPI、各国が追加できる指標、共通で使うSemantic Layer、施策ごとのSLA、パイプラインの再利用範囲、AIが参照してよいデータと承認が必要な操作を決めます。

そのうえで、CRM、MA、ECレコメンド、需要予測、MD支援、店舗業務支援へ段階的に広げる方が、運用に乗りやすくなります。

Phinxは、グローバルデータ基盤の構想、データガバナンス、ETL/ELT、店舗・EC・商品・在庫・顧客データの統合、KPI・Semantic Layer設計、CRM/MA連携、レコメンドや需要予測の土台づくりまで、業務とデータ定義をつなぐ支援を行います。

詳細について聞く

お問い合わせ