「現場のスピード」と「コストの壁」をどう突破するか──イオンの店舗向け業務システムSmartHHTが選んだ、データ基盤"いいとこ取り"の再構築とは？ 

イオングループの店舗現場において、いまや従業員の手足となっている「SmartHHT」。在庫確認、売価変更、発注、そしてお客さまへの案内──。かつてはバックルームと売り場を往復していた業務を、ハンディターミナルやスマートフォンといった手元の端末1つで完結させるこのシステムは、現場の生産性を劇的に向上させた。

しかし、その裏側には、エンジニアたちが抱える地味だが深刻な課題があった。それは、現場が求めるデータの鮮度と、それを支えるためのコストと処理性能のバランスだ。約15分に1回という高頻度なデータ更新を実現・維持しようとすれば、データ処理コストは大幅に跳ね上がる。今後、グループ各社へ展開規模を拡大していくなかで、このコスト構造は看過できないリスクとなりつつあった。

イオンスマートテクノロジー（AST）でデータ基盤の開発・運用をリードする奥山淳は、単一の技術に依存するのではなく、適材適所で技術を組み合わせる"いいとこ取り"のアーキテクチャへの刷新を決断する。今回のSmartHHTへ提供するデータ更新処理課題対応のパートナーとして選ばれたのは、データ＆AI企業であるデータブリックス（Databricks）だった。

本記事では、ASTの奥山とデータブリックス・ジャパン株式会社の小出行輝氏に、SmartHHTの裏側で起きていたリアルな困りごとと、その解決に向けたエンジニアリングの軌跡を聞いた。

【目次】

「バックヤードへ走る」を過去のものに。SmartHHTが担う使命

広大なイオンの売り場で、お客さまから「この商品の在庫はありますか？」「色違いはいつ入荷しますか？」と尋ねられたとき、店舗スタッフはどう動くべきか。

かつて、SmartHHTのようなモバイル端末が普及する前は、スタッフはそのたびに売り場を離れ、店の奥にあるバックヤードまで走り、PC端末を操作して在庫を確認しなければならなかった。戻ってくるまでのあいだ、お客さまを待たせることになり、もし在庫がなければ、ただ「ありませんでした」と伝えるために戻ることになる。「SmartHHTの最大の功績は、この無駄な移動と待ち時間を解消したことにあります」と語る奥山自身、かつてはイオンバイクの店舗で販売業務に従事していた経験を持つ。現場の痛みを知るエンジニアだ。

売り場にいながらにして、手元のスマートフォン端末で在庫や売上を確認できる。もし自店になくても『近隣店舗になら在庫がありますよ』と、その場でご案内ができる。これは顧客体験として非常に大きな変化です。（奥山）

この利便性を支えているのが、バックエンドで行われているデータ更新だ。従来のシステムでは、在庫データの更新は1日数回に限られていた。しかし、今の時代、ECと店舗の在庫連動や、ピーク時の激しい商品の動きに対応するには、それでは遅すぎる。

SmartHHTは現在、約15分に1回という高頻度でデータを更新している。画面上は「在庫あり」だが、実際にはないなどといったタイムラグを極限まで減らすためだ。しかし、この15分更新という現場への価値提供は、データ基盤に対して大きな負荷を強いることになった。

正直に言えば、これまで使っていたデータウェアハウス（DWH）製品でも、15分間隔でデータを処理し、現場へ届けるスピードは実現できていたんです。問題は、その維持コストでした。（奥山）

SmartHHTの導入店舗は、今後イオングループ全体へと拡大していく計画にある。店舗数が数百、数千、そして数万店規模へと広がっていったとき、データ量と処理回数は爆発的に増加する。既存の従量課金モデルのままでは、店舗数が増えれば増えるほど、システム維持コストが跳ね上がってしまうリスクが顕在化していたのだ。

現場からは「もっと早く、5分間隔で更新してほしい」という要望さえあります。しかし、今のアーキテクチャのままでは、15分間隔を維持することすら、将来的なコスト負担を考えると限界が見えていました。現場のスピードを守るためには、裏側の仕組みを根本から変える必要があったのです。（奥山）

「銀の弾丸はない」──適材適所を追求する設計思想

コストの壁をどう突破するか。奥山の答えは、特定の製品にすべてを委ねるのではなく、複数の技術を組み合わせるベスト・オブ・ブリードのアプローチだった。

奥山は常々、全ての領域をカバーしているデータ基盤製品は存在しないと口にしている。どんな優れた製品にも、得意な領域と苦手な領域がある。エンジニアはそれを理解し、自分の手元にある"地図"のなかで最適な配置を行うべきという考えだ。

これまでSmartHHTのデータ処理を担っていたSaaS型DWHは、ダッシュボードやアドホック分析など読み取り中心のインタラクティブなクエリやデータ共有に強みを持つ。一方で、15分ごとに発生するような大規模バッチのデータ洗い替えや重い前処理をすべて同基盤上のETL／ELTとして実行すると、コンピュートリソースの利用時間や規模が増えやすく、コストが高止まりするケースも指摘されている。

SaaS製品は運用負荷が低い一方で、中身がブラックボックスになりがちです。コストを下げるためにチューニングしようとしても、主にSQLや仮想ウェアハウスのサイズ設定・スケーリングポリシーなどのレイヤーに依存し、より根本的なリソース制御には踏み込めないもどかしさがありました。（奥山）

そこで目をつけたのが、Databricksだ。Databricksは高速分散処理フレームワークであるApache Sparkをベースにしており、大量データのETLやバッチ処理に強みを持つ。ユースケースによっては、重いETL処理をDatabricks側にオフロードすることで、処理スピードとコストパフォーマンスの両面で有利になるケースが報告されている。

当社でも、フロント部分は変えず、特に負荷の重いETL部分をDatabricksに寄せることで、全体のコスト構造を大きく最適化できるのではないかと考えました。（奥山）

この奥山の構想に対し、Databricksのソリューションアーキテクトである小出氏も、技術的な勝算を感じていた。

ASTは、すでにデータの利活用自体は進んでいるフェーズにありました。次のステップとしてコスト最適化に取り組むのは必然の流れです。

Databricksは、データの保存（ストレージ）と計算（コンピュート）が分離されたアーキテクチャを採用しています。必要なときに必要なぶんだけ計算リソースを立ち上げ、終わればすぐに停止する。この特性が、小売業特有のピーク性の高い処理や定期的なバッチ処理に非常にハマるのです。我々のプラットフォームであれば、ASTが抱えるコストと性能のジレンマを解決できると確信していました。（小出氏）

"安く、速く、うまい"——。奥山と小出氏、2人のエンジニアが共通して口にするDatabricksの評価だ。特に、エンジニアが仕様を理解していれば、クラスターサイズやインスタンスタイプを細かく調整し、自分たちの手でコストをコントロールできる透明性が、奥山にとっては大きな魅力だった。

処理時間は2/3、コストは半減へ

2025年11月、ASTはDatabricksへの移行検証（PoC）に着手した。既存のデータ処理パイプラインの一部をDatabricks上で再現し、実際のパフォーマンスとコストを測定する検証だ。

その結果は、チームの予想を上回るものだった。

まず、処理速度が明確に向上しました。たとえば、売上データの処理において、既存環境では245秒かかっていたものが、Databricksでは151秒で完了しました。約38%の短縮です。在庫データの処理も同様に30%ほど速くなり、トータルで見ても処理時間は大幅に短縮されました。（小出氏）

そして、最大の課題であったコストについても、劇的な改善効果が試算された。

PoCの結果、既存の構成と比較して、コストは約50%削減、つまり半額以下に抑えられるというデータが出ました。さらにサーバーレスコンピュートの最小構成を活用するなど、チューニング次第では最大80%近くまでコストを圧縮できるポテンシャルも確認できています。

既存のDWHではどうあがいても下げられなかったコストの壁を、アーキテクチャを変えるだけでこれほど突破できる。我々の仮説が正しかったことが、数字で証明された形です。（奥山）

今回のPoCで特筆すべきは、その検証スピードだ。通常、データベース製品の移行には、SQLの書き換えや検証に膨大な工数がかかる。しかし今回、Databricks側が提供するコード変換ツールを活用したことで、作業は驚くほどスムーズに進んだという。

準備こそ大変でしたが、いざ変換作業が始まったら一瞬でしたね。「寝て起きたらマイグレーションが終わっていた」という感覚です（笑）。Databricksのエンジニアの方々が、こちらの意図を1言えば10理解して動いてくれたおかげでもあります。（奥山）

奥山さんのプロジェクトの進め方が素晴らしかったことも大きいです。丸投げにするのではなく、「今回のゴールの核心はここだ」「評価ポイントはコストと速度だ」と明確に示してくれた。我々としても、単なるベンダーとしてではなく、同じチームの一員としてどうすれば最短で結果が出るかを考え、ツールを駆使して一気に実装まで持っていけました。（小出氏）

発注側と受注側という壁を超え、エンジニア同士が目的を共有してともに走る。この信頼関係こそが、短期間での成果創出を支えていたのだ。

エンジニアは"地図"を読み解け

PoCでの成功を受け、ASTでは2026年1月以降、本番環境での並行稼働と現新比較を実施し、2月中にはDatabricksへの切り替えを完了させる計画だ。これにより、店舗数が拡大してもコストを抑制し、現場のスピードを守り抜く強固な基盤が完成する。

今回のSmartHHTの基盤刷新は、単なるツールの置き換えではない。事業の成長に合わせ、エンジニアが主体的にアーキテクチャを見直し、再構築した事例だ。奥山は、同じように企業のデータ基盤を支えるエンジニアたちに向けて、自身の仕事論を語った。

データ基盤は、いわば"地図"です。一番大切なのは、自分が住んでいるその地図を、自分自身できちんと見渡せているかどうか。どんな製品を使っていて、どういうアーキテクチャで動いていて、誰が使っているのか。自分の足元にあるその地図を理解してはじめて、数ある選択肢のなかから「ここはこちらの製品のほうが良い」「ここはコストをかけてでもリッチにするべきだ」と選ぶことができます。（奥山）

漫然と1つの製品を使い続けるのではなく、常に新しい技術に触れ、比較し、自分の手札を増やしておくこと。それが"地図の解像度"を高めることにつながる。

最終的に目指しているのは、システムの新しさではありません。店舗でお客さまに「ネイビーの自転車はありますか？」と聞かれたスタッフが、自信を持って「ありますよ」と即答できること。そうした当たり前の体験を守り、さらに良くしていくために、我々エンジニアは裏側で技術を学び、選び続けなければならないのです。（奥山）

銀の弾丸はない。だからこそ、エンジニアは考え続ける。イオンの巨大な商流を支えるSmartHHTの進化は、現場のスピードに合わせて、これからも続いていく。

イオングループでは一緒に変革に挑んでくれる方を募集中です。

どんなことをしているのか気になる方は、お気軽にご連絡ください。カジュアル面談も実施しておりますので、まずはざっくばらんにお話しましょう！