ITシニアマネージャーが「ZOZOのデータアーキテクチャ」を解説してみた。

集めて、整えて、分析して、ビジネスに還す。一つの会社の中で「データが循環する仕組み」を、ITの専門知識がなくても追えるように解きほぐします。

データドリブン経営という言葉をよく耳にするようになりました。勘や経験だけに頼らず、事実（データ）にもとづいて意思決定をする経営のことです。とはいえ、言葉だけが先行しがちで、「具体的にどんな仕組みがあれば実現できるのか」は外からは見えにくいものです。

この記事では、ファッションEC「ZOZOTOWN」を運営する株式会社ZOZOを題材に、同社が技術ブログや勉強会で公開している情報をもとに、データ活用の仕組み（アーキテクチャ）を解説します。ZOZOを選んだのは、優れた実践であるだけでなく、中身を惜しみなく公開している数少ない企業だからです。本記事の内容はすべて同社の公開資料に基づいています。

解説は、データの一生（ライフサイクル）に沿って5つのパートで進めます。①なぜ集めるのか、②どう集めるのか、③どう整理・蓄積するのか、④どう分析するのか、⑤何に役立てているのか。まずは全体像を一枚の図で俯瞰しておきましょう。

この図の「上から下への流れ」が本記事の背骨です。以降では各段を一つずつ降りていきます。技術用語は使いますが、初めて出てくるものには必ずふだんの言葉で補足を添えます。

なぜデータを集めるのか ── 経営・ビジネス上の目的

仕組みの話に入る前に、「そもそも何のために」を押さえます。手段から入ると、技術の話に埋もれて目的を見失いがちだからです。ZOZOがデータを集める動機は、大きく3つに整理できます。

• 理由1：一人ひとりに合った買い物体験をつくるため

ZOZOTOWNには膨大な数の商品があり、ユーザーの好みも千差万別です。全員に同じ画面を見せるのではなく、その人が好みそうな商品を出し分ける――いわゆるレコメンド（おすすめ表示）には、ユーザーの行動データ（何を見て、何を買い、何をお気に入りに入れたか）が欠かせません。データは、パーソナライズされた体験の燃料です。

• 理由2：事業の状況を正しく・速く把握するため

「昨日の売上は」「あの施策の効果は」「在庫は適切か」。経営や現場の判断は、信頼できる数字があって初めて成り立ちます。重要なのは、数字が正確であること、そして必要なときに速く手に入ることです。後で見るように、ZOZOがリアルタイムの仕組みにこだわるのは、この「速さ」が事業の競争力に直結するからです。

• 理由3：データそのものをサービスの一部にするため

ZOZOの特徴は、データを「分析して終わり」にしない点にあります。分析でつくった成果を、もう一度サービスの中に組み込んで価値を生む。たとえば「在庫が残り1点になったら、その商品を見ていた人に通知する」「不正な利用を素早く検知する」といった機能は、データが循環して初めて実現します。データは見るものであると同時に、動かすものでもあるのです。

どうデータを集めるのか ── 収集の仕組みとデータソース

次は「集め方」です。一口にデータといっても、ZOZOの中ではさまざまな場所に、さまざまな形で散らばっています。まずはその「源（データソース）」の多様さを押さえましょう。

データの源は20以上に散らばっている

ZOZOのデータは、社内のサーバーにある基幹システム（注文・在庫・会員情報など、事業の根幹を扱う中核システム）や、各サービスのデータベース、外部のSaaS（クラウド上で使うソフト）など、20を超えるソースに分かれて存在します。データベースの種類も、オンプレミス（自社で持つサーバー）のSQL Server、クラウド上のMySQLやDynamoDBなどさまざまです。

ここでいうオンプレミスとは、クラウドではなく自社の設備でシステムを動かす形態のこと。ZOZOTOWNの根幹は長年運用されてきたオンプレのSQL Serverにあり、そこに最も重要な注文や在庫のデータが日々書き込まれています。この「自社サーバーにある大事なデータを、いかにクラウドの分析基盤へ運ぶか」が、収集の主役テーマになります。

「全部まとめて1日1回」と「変わった分だけ、すぐ」の2方式

ZOZOは、性質の異なる2つの運び方を併用しています。これが収集設計の肝です。図2を見ながら読んでください。

方式A：日次バッチ連携（全部まとめて1日1回）
バッチとは「まとめて一括処理する」という意味です。1日1回、基幹システムのデータをごっそりクラウドへ転送します。運ぶ作業にはEmbulk（エンバルク）というデータ転送ツールを使い、処理の段取り（どれを先に、どれを後に動かすか）はDigdag（ディグダグ）というワークフローエンジン（作業の順番を管理する仕組み）で制御します。住所やメールアドレスといった秘密情報は、この転送の途中でハッシュ化（元に戻せない記号列に変換し、中身を伏せること）してから運ばれます。大量データを確実に運べる一方、最大で1日ぶんの遅れが出るのが弱点です。

方式B：リアルタイム連携（変わった分だけ、すぐ）
「残り1点で通知」のような機能には、1日遅れでは間に合いません。そこで、データに変更があったその瞬間だけを捉えて即座に運ぶ仕組みを別に用意しています。SQL ServerのChange Trackingという機能（「どの行が変わったか」を記録する仕組み）で変更点を検知し、Pub/Sub（メッセージを確実に中継する“データの宅配便”のようなサービス）を経由してBigQueryへ流し込みます。全データを毎回運ぶのではなく差分だけを運ぶので、軽くて速いのが特長です。

さらに踏み込むと、ZOZOはこのリアルタイム連携の心臓部（データを変換して送り出すETL層＝Extract/Transform/Loadの略で、抽出・変換・書き出しを担う部分）を、近年Go言語で自作のプログラムに作り替えました。背景には、データ量の増加でメモリ消費やコストがふくらむという現実的な課題がありました。作り替えの結果、この部分のサーバー費用を約3分の1（約67%減）にまで圧縮し、処理の遅延も「全テーブル10分以内」で安定させています。派手さはありませんが、こうした地道な再設計の積み重ねが基盤の体力を支えています。

どのように整理・蓄積するのか－基盤とパイプライン

集めたデータは、そのままでは使えません。形がバラバラだったり、同じ「売上」でも計算方法が微妙に違ったりするからです。この章は、散らかったデータを整理整頓して“使える状態”にする工程です。ZOZOのアーキテクチャでもっとも作り込まれている部分でもあります。

中核となる保管庫「BigQuery」

運ばれてきたデータは、まずBigQuery（ビッグクエリ）という巨大なデータ倉庫に集約されます。これはGoogleが提供するクラウド型のデータウェアハウス（DWH：分析のために大量データをためて高速に集計できる専用の保管庫）です。膨大なデータでも一瞬で集計できるのが強みで、ZOZOの全社データはここに一元化されます。「あらゆるデータが、まずここに集まる」という一点集中が、後の分析を楽にします。

「生のまま」から「使える形」へ ── dbtによる段階的な加工

倉庫に入れただけでは、まだ素材の山です。ZOZOはdbt（ディービーティー）というツールを使って、データを段階的に磨き上げます。dbtは、SQL（データを取り出すための命令文）で書いた加工のルールを整理し、変更履歴を残し、依存関係（どのデータがどのデータを元にしているか）を管理できるツールです。ZOZOは無償のdbt Coreを採用しています。
加工は、いきなり完成品を作るのではなく、レイヤリング（層に分けて段階的に整える考え方）で進めます。具体的には次のような層を通ります。

•      Sources（ソース）：運ばれてきたばかりの一次データ。手つかずの素材。
•      Staging（ステージング）：重複を取り除いたり、表記を揃えたりする下ごしらえの層。
•      Marts（マート）：実際の分析や利用に使う、仕上がった料理。共通の指標を計算する中核層もここに置く。

この層分けの狙いは、「同じ指標は、同じ計算定義を一か所で持つ」ことです。たとえば「会員数」の数え方が部署ごとにバラバラだと、会議で数字が食い違って議論になりません。共通の層で定義を一本化しておけば、誰がどこで見ても同じ数字になる。地味ですが、組織の意思決定の信頼性を根っこで支える設計です。

加工の段取りを自動で回す ── Cloud Composer

これらの加工は、毎日決まった順番で、依存関係を守りながら自動実行する必要があります。その司令塔がCloud Composer（クラウド版のAirflow。多数の処理の順番待ちや再実行を管理するワークフローエンジン）です。たとえば「元データの連携が終わってから、それを使うデータマートを更新する」「途中で失敗した処理だけを自動でやり直す」といった段取りを、人手を介さず回します。

規模感を補足すると、ZOZOのデータ基盤には20以上のソースシステムと1,000を超えるデータマートが存在します。これだけの数になると、依存関係を人が手で追うのは不可能です。dbtで依存関係を機械可読に管理し、Cloud Composerで実行を自動制御する――この組み合わせがあって初めて、巨大な基盤が破綻せずに回ります。

どのように分析するのか ── 分析手法と組織体制

整えたデータを、いよいよ使います。ただしZOZOの面白さは、分析“手法”そのもの以上に、「データを安全かつ便利に使い続けるための組織と仕組み」にあります。順に見ていきます。

用途で分けた3種類の「すぐ使えるデータ」

ZOZOは、加工済みデータ（Core DataMartsと総称）を、利用者の要求に合わせて3種類に作り分けています。「1つの万能データで全員を満足させようとすると、かえって全員が不便になる」という現実への答えです。図3で全体を見てください。

① Analysis DataMarts（即時性重視）
アナリストが「今すぐこの数字が知りたい」に応えるための、ワイドテーブル（必要な項目を横に広げ、面倒な結合をせずそのまま使える横長の表）です。素早く改修できるよう柔軟に保つ代わりに、システムからの参照は原則禁止。頻繁に形が変わるものに本番システムが依存すると、変更のたびに障害を招くからです。

② Data Products（安定性重視）
特定のサービスに組み込むための、要件に100%合わせた専用データセットです。リバースETL（分析基盤で作った成果を、もう一度業務システムへ戻す手法）でサービスに供給されます。責任者と障害時の対応方針がはっきりしているため、安定して動き続けます。

③ Dimensional DataMarts（再利用性重視）
長く使える全社共通の土台です。ディメンショナルモデリング（事実＝売上などの数値と、属性＝商品や会員などの情報を整理して組み立てる、堅牢なデータ設計の手法）を採用し、将来のビジネスの変化にも耐える構造になっています。これが全社のSSoT（Single Source of Truth：唯一の信頼できる情報源）の中核を担います。

分析を支える組織 ── 「3領域 × 複合チーム」

ZOZOは、データマネジメントを役割で3領域に分け、専門家が連携する複合チームで運営しています。

•      Data Platform：基盤そのものの課題解決。データエンジニアがリード。
•      Core DataMarts：データや指標の標準化・モデリング。アナリティクスエンジニアがリード。
•      Data Portal：活用に必要な情報の公開・整理。データマネージャーがリード。

注目すべきは、同社が掲げる「中央集権にしすぎず、適度な分散を意識する」という方針です。すべてを一部署で抱え込むと現場のスピードが落ち、逆に各部署に丸投げすると品質が崩れる。その中間を狙い、共通化すべき部分（指標の定義など）はしっかり統制しつつ、現場の柔軟性は残す。このバランス感覚こそ、ガバナンスを“形骸化させずに機能させる”要諦です。

使えるデータを守る ── 品質とコストの番人

便利な基盤は、放っておくと「品質の劣化」と「コストの膨張」に侵されます。ZOZOはここにも仕組みで対処しています。社内ツールCoppe（コッペ）でデータの品質を監視し、異常があればチャット（Slack）へ自動通知します。共通データへのシステムからのアクセスは許可制にし、「誰が・何の目的で使っているか」を申請ベースで把握。利用ログから、想定外のアクセスや高額なクエリ（集計命令）を日次で検知する仕組みも備えています。

コスト面の象徴的な取り組みが、BIレポートの資産棚卸しです。BI（Business Intelligence）ツールとは、データをグラフや表で可視化する道具のこと。ZOZOではLooker、Power BI、Tableauなどが使われています。便利ゆえにレポートが各所で乱立し、「もう誰も見ていないのに、裏で毎日データ更新が走り続けてサーバー代だけかかる」という無駄が生まれていました。そこで、過去90日間アクセスのないレポートは更新を止めるよう促し、不要なコストを抑制しています。作るだけでなく畳む仕組みまで用意している点が、運用の成熟度を物語ります。

何に役立てているのか ── 具体的な活用事例と成果

最後に、この基盤が実際に何を生んでいるのかを見ます。データが「分析して終わり」ではなく、サービスや経営に還っていく――その具体例です。

事例1：開発スピードを3分の1にした「汎用レコメンド」

ZOZOは、ユーザーやアイテムの特徴を数値の並び（Embedding＝埋め込みベクトル。好みや特徴を、コンピュータが扱いやすい数値の座標に変換したもの）として表現し、似たもの同士を高速に探し出す汎用的なレコメンドの仕組みを構築しました。BigQueryのベクトル検索機能を活用し、施策ごとに作り込んでいた推薦システムを使い回せるようにしたのです。結果、ある施策では構築期間が約10週間から約3週間へと約3分の1に短縮され、メール経由の流入数・購入数の改善も確認されています。整えられたデータ基盤があるからこそ、新しい施策を素早く打てるという好例です。

事例2：在庫が動いた瞬間に届く通知

第2章で触れたリアルタイム連携は、「商品が残り1点になったタイミングで、その商品に関心を持つ人へ通知する」といった機能を支えています。これは1日遅れのデータでは成立しません。速さがそのまま販売機会につながる、データの即時還元の典型です。同じ仕組みは、不正利用の早期検知や、施策のリアルタイムなモニタリングにも使われています。

事例3：全社が同じ数字で会話できる状態

派手さはないものの、もっとも経営インパクトが大きいのがこれです。指標の定義をdbtで一元化し、信頼できるデータを全社で共有する。さらに、散在していたBIレポートをData Portal（社内のデータ情報を一覧・分類して、誰もが目的のレポートにたどり着けるようにした入り口）で整理し、全社へ公開する。これにより、「似て非なるレポートをゼロから作り直す」無駄が減り、組織全体の意思決定の土台が揃います。データドリブン経営とは、結局のところ「全員が同じ正しい数字を見て議論できる状態」をつくることだ――ZOZOの取り組みはそう教えてくれます。

成果を支える数字の一例

本記事で触れた、公開されている定量的な成果を一覧にしておきます。

まとめ ── ZOZOのアーキテクチャ、どこが優れているのか

最後に、本記事で見てきた「優れている点」を5つに凝縮します。

•      目的が明確：「可視化」で止めず、一人ひとりへの還元と速さの追求まで目的に据えている。
•      二段構えの収集：日次の全量とリアルタイムの差分を組み合わせ、確実さと速さを両立。
•      一点集中＋段階加工：BigQueryに集約し、dbtのレイヤリングで「同じ指標は同じ定義」を担保。
•      用途別の作り分け：即時性・安定性・再利用性で3種のデータマートを用意し、全員の不便を解消。
•      形骸化しないガバナンス：適度な分散、品質監視、コストの棚卸しまで、運用を仕組みで支える。

どれも「魔法のような新技術」ではありません。むしろ、当たり前のことを、目的に沿って、地道に作り込み、運用し続けていることが本当の強みです。そして同社がこれらを公開し続けている事実そのものが、データドリブン経営を志す多くの組織にとっての道しるべになっています。自社のデータ活用を見直すとき、本記事の5つの問い――なぜ・どう集め・どう整え・どう分析し・何に還すか――を順に当ててみることを、最初の一歩としておすすめします。

注意:

本記事は、筆者個人の感想および考察にもとづくものであり、株式会社ZOZOならびに関係各社の公式見解を represent するものではありません。

執筆にあたっては、同社が公開している技術ブログや登壇資料などをもとに、できるかぎり正確な情報をまとめるよう努めましたが、筆者の理解不足による誤解や事実の取り違えが含まれている可能性があります。もしそうした誤りがありましたら、あらかじめお詫び申し上げます。

また、本記事で参照した情報は、さまざまな時期に公開されたものを横断的にまとめています。データ基盤は日々進化を続けているため、本記事の内容が必ずしも最新の状態を正確に反映しているとは限らない点にご留意ください。記載された構成や数値は、あくまで「ある時点の公開情報をもとにした概観」とお考えいただければと思います。

そのうえで本記事は、ZOZOの実態を厳密に把握することを目的とするものではありません。むしろ、「データドリブン経営を支えるアーキテクチャは、こんなふうに組み立てられるのか」という一つの参考事例として、読者のみなさまのヒントになれば幸いです。正確な情報や最新の取り組みについては、ぜひ同社の公式な発信を直接ご確認ください。