​​イオンリテール、Cloud Runでデータ分析基盤内製化 - 顧客LTV向上と従業員主導の分析体制へ

Google Cloudが9月25日に開催した記者説明会では、イオンリテール株式会社がCloud Runを活用し顧客生涯価値（LTV）向上を目指したデータ分析基盤を内製化した事例を紹介。従業員1,000人以上がデータ分析を行う体制を目指し、BIツールによる販促効果分析、生成AIによる会話分析、リテールメディア活用などの取り組みを進めている。

イオンリテール株式会社 デジタル戦略部データソリューションチーム マネージャー今井賢一によると、同社が約1年をかけて開発したデータ分析基盤には、アプリ会員のデータやPOSデータ等の取り込みがすでに完了した。すでに幹部級によってデータ分析基盤が利用されているという。基盤開発はGoogle Cloudの内製化支援プログラム「Tech Acceleration Program」活用することで実現した。今井は「こうしたプログラムは我々非エンジニアにとって有用なプログラムだった」と語った。

基盤開発によって、顧客に対して一意のIDを与え、効果的な消費行動を追いかけることができるようになった。イオングループの総合スーパー事業の中核を担い、「イオン」「イオンスタイル」などを展開するイオンリテールには数千万規模の会員データと、日々数千万の購買データが蓄積されている。

小売業界では珍しいことだが、LTVを重要な指標に据えるようにしている。「従来は1バスケット（一回の購買）の最大化が大きな目的だったが、誰がどこで何を購入して、より長期的な視点でどれくらいの売上につながったかという顧客LTVを最大化する取り組みに変わっている」

LTVはインターネット企業で採用されることの多い指標だった。インターネット企業は、サプライチェーンや実店舗を持たないケースが多く、業態ごとに様々ではあるものの、LTVと顧客獲得費用（CAC）や顧客獲得単価（CPA）のような数値との比較により、ビジネス評価を下すこともある。LTVは1人の顧客の行動を長期的に把握していることを前提としており、データ分析基盤の構築は大きな橋頭堡となったようだ。デジタル・トランスフォーメーション（DX）の文脈においては、多くの企業がテクノロジー企業の手法を採用することが推奨されている。

今井はイオンリテールのデータ利活用を以下の3つの段階と考えているという。

• 第1段階：Looker Studioを使ってデータ可視化。従業員がダッシュボードを使ってデータ分析
• 第2段階：専門家によるAI / 機械学習
• 第3段階：生成AI

従業員1,000人がデータ分析する体制へ

同社はデータ分析に関わる従業員の拡大を目指している。最近、従業員向けのデータ分析プラットフォームのWebアプリケーションを開発し、今年度中には従業員1,000人以上が分析をするようになることを目指している、と今井は言う。

今井が紹介した実例では、とある店舗では南側に競合店が集中的に出店したため、その地域の南側に販促を重点的に行っていた。しかし、ビジネスインテリジェンス（BI）ツールによって販促の効果が出ていないことが判明した。さらに疎かにしていた北側では、競合店が別の施策を打っていることが判明した。この店舗は北側に販促の重点を移すことにして、効果的な販促を打てるようになったようだ。「（その店舗は）現在も進捗確認のためダッシュボードを活用している。このような分析によるPDCAを進めていきたい。部長職の数十名ですでにこのような好事例があるため、これが従業員数千名に広がっていくと、さらに好事例が出てくるでしょう」

「ツールをそのまま渡すのではなく、研修を行う形を取って、まずLTV分析のような手法を伝える。研修の中で何段階に分けて顧客分析に関する理解を深め、そうした分析をするためのツールとしてこれがある、と伝えている」

今井は、生成AI（同社のデータ利活用の目標の第三段階でもある）とリテールメディアという注目を浴びている分野にも言及した。データ分析においては、最終的には生成AIを用いた会話分析を目指しているという。ダッシュボードに不慣れな従業員もおり、最終的には対話形式でデータとインタラクトできるようにすることで「本質に近いデータの民主化が実現できる」と今井は語った（このGoogle Cloud Next Japanの記事でも会話分析の事例に触れている）。

同社が開発する従業員向けの生成AIチャットボットでは「多様な検索拡張生成（RAG）を作っていくことで従業員の意図に対して適切な対応を取る」ことを考えているという。また、イオンリテールのアプリである「イオンお買物アプリ」では、各メーカーからクーポンや広告の出稿を受けており、広告出稿企業に対してより鮮明な顧客データを提供するという試みを検討している。

社内でDX人材を育てる

DXの文脈では、業種業界のドメイン知識とエンジニアリングの融合が必要となる。既存の社員にデジタル技術の専門知識を習得させ、デジタル変革の推進力となる人材へと育成するのが、今井が培って得た教訓だったという。

「私たちのチームはつい数年前まで非エンジニア人材だったが、Cloud Runを活用することで、スピーディで効果的な開発ができるようになった」「ビジネス側の人間を技術側の知識を習得させるほうがDXの推進になる、と数年前に方針転換。イオンリテールには10万人の従業員がおり、いろいろな素養を持つ人がいるため、その中から適した人をDXに当てるようにした」

「将来的には外部の技術的な人材を合わせて、よりDXを拡大していきたい。いま社内人材を育てているのは、外部の人材が入ってきたときにマネジメントできる、技術的な人材がどういう思考をするのかわかる人材を育てる意味合いがある」

Cloud Runを採用した理由

「顧客データを分析することに時間を割きたいところだが、実際にはサーバーの管理に時間を取られることが想像できた。これだと顧客ニーズに対応するために内製化したという我々の意図が薄れてしまう」。このため、今井のチームはインフラの管理を適度に抽象化できるCloud Runの採用に至ったという。今井はCloud Runの利点として、「それぞれ（のアプリケーション）が簡単に構築でき、改修できる」ことに言及。オートスケールにも言及し、他社環境と比較して4分の3のコストカットになりうると話した。

Cloud RunはKubernetes の上にサーバーレス環境を実現する OSS である Knative 互換のサーバレス環境。KubernetesはGoogle が2014年にオープンソース化したコンテナオーケストレーションのデファクトスタンダード。Cloud RunはKubernetesクラスタの構成や管理を必要としないようにより作り込むことで、「マネージド」で「サーバレス」なプラットフォームとして提案されている。開発者は、インフラレイヤーを気にせず、最も重要な作業であるアプリケーションの構築に集中できるようになる。

グーグル・クラウド・ジャパン合同会社 技術部長（インフラ、アプリケーション開発、データベース） 安原稔貴は、Google Kubernetes Engine（GKE）やApp Engineなどとの比較から、開発プラットフォームにおける抽象性と柔軟性のトレードオフについて言及した。GKEはカスタマイズ性が高いものの、すべての開発者にとって必ずしもベストではなく、よりコンテナに手をいれる必要のないCloud Runが好ましいケースもある。

App Engineとの比較については、「App Engineとはコンテナの管理機能が若干違っており、Cloud Runの方がコンテナが扱いやすい形でインテグレーションされていると理解している。CPU Boost機能やGPU への対応のような最新のトレンドに応じた機能の拡張については、Cloud Runに投資が集中している。コンテナ周りのトレンドが立ち上がってきたこともあり、コンテナを使いやすくする機能がCloud Runに載っており、利用しやすくなってきているのが今のポイント」と話した。

安原は、Cloud Runの機能として、トラフィックの変動に応じて自動的にコンテナインスタンスの数を増減させる「オートスケール」や1つのコンテナインスタンスが同時に処理できるリクエストの最大数を設定する「Concurrency（最大同時実行数）」を紹介。その他にもバックグラウンドタスクの実行、サービスメッシュの適用、Stratup CPU Boostのような機能に触れた。イベント駆動型の関数を実行する「Cloud Function」が8月にCloud Runと統合され、「Cloud Run Function」へと進化したことも明らかにした。