Future Tech Blog
フューチャー技術ブログ
Businessカテゴリ

買い物で人をつなぐ

Stable Diffusion先生に出力してもらったコンセプトアート

はじめに

このブログは、Google社によるパートナー企業向けのアプリケーション モダナイゼーションに関するテクニカルブログ投稿の集中キャンペーン兼大人の夏休みの宿題の成果になります。

Google社から、初夏某所、下記のようなお題でテックブログを書いてみませんか？ というお誘いが来ました。

サーバーレス製品を活用し、下記のテーマから選択いただいた社会課題を解決するためのアプリケーションアーキテクチャを投稿してください。

●対象テーマ: サーバーレス技術を活用した社会課題の解決策
○空き家問題
○買い物難民問題
○東京一極集中
○フードロス問題

そこでFutureの村田、鈴木、原木の有志三人で定期的に検討会を開き、「買い物難民問題」を解決するためにどのようなサービス、アーキテクチャが好ましいか検討しました。

お題「買い物難民問題」とそのモチベーション

私たちのチームでは「買い物難民問題」を選択しました。理由としては、私が今住んでいる関東郊外のとある地域には周囲五キロにスーパーがないという、まさに「買い物難民」当事者だったこと、だからこそ、生協やネットスーパーのようなサービスが今どきあるから既に「問題」じゃないのでは？ といった疑問に答えられると思ったからです。

「買い物難民問題」という言葉を聞いたことがないという人は少ないと思います。しかし、この問題について調べる前の私たちがそうであったように、単純に「買い物」ができるようになれば解決する話ではないことを知る人はそう多くないのではないでしょうか。

「買い物難民問題」に関して、当事者からヒアリングを行った経済産業委員会調査室の笹井かおり氏による『「買い物難民」問題 ～その現状と解決に向けた取組～』を読むと、単純に解決できない難しさの一端が見えてきます。

本資料では、関東近辺の高度経済成長期時代に山間部に造成されたニュータウン住民を取り上げています。

  • 高齢者数が全体の1/4を占める
  • 過去に地域内にあったスーパーが不採算のまま撤退
  • 70代の住人は家族のために細い未舗装路を自転車で20~30分かけてスーパーで移動している
  • 元々山を切り開いたところなので道路環境が悪い(Google Mapsで見る限り、坂も多そう)
  • 現役時代には、都心に通勤し、早朝に家を出て深夜に帰宅する生活を送っていたという高齢者が多い。 したがって、住民は地域との接点が薄く、住民同士の横の付き合いも希薄なため、住民の連携が不足している。
  • 今後、高齢の夫婦だけの世帯 や一人暮らしの住民が更に増加することが想定されるため、団地の外まで買い物に行けなくなる人が増加するおそれがある
    ※ブログ著者強調

こうしてみると、買い物難民は買いたいものが買えればOKでは決してありません。当時の時代背景ではあまり重視されてこなかった、地域コミュニティといったコミュニケーションの乏しさから来る「関係性の希薄さ」が「買い物難民であること」と表裏一体で問題であることが見えてくるのではないでしょうか。また、それが社会問題として全体化しているとはいえ、地域性の強い問題であり、人によって感度の違いはあると思います。

これらを踏まえた上で、私たちのチームでは全員にとって買い物難民問題を捉えやすくするために、地域の格差を取り払い(かつ将来現実化するかもしれない！？）世界を想定して、「買い物を通じて人との繋がりを生み出す」ための仕組みを考えてみました。

舞台設定

これから話す世界では、現実にはない、どこか少し不思議な世界です。そこでは自動運転が発達しており、キャンピングカーのような移動躯体に乗って生活することが当たり前の世界です。「お隣さん」という概念がもはや古くなって久しく、一か所に集まらないことが普通になった世界で、顔を突き合わせたコミュニケーションは過去のものになっていました。

しかし、こちらの世界で「昭和レトロ」が流行っているように、あちらの世界でも昔のものが形を変えて何度もリバイバルすることはよくあります。最近耳にしたのが、昔ながらのコミュニケーション方法、つまり知らない人と直接会って会話を交わすことが一部で圧倒的な人気を得ているという情報でした…

サービス概要

私たちのチームでは、「買い物」x「人との繋がり」x「(あちらの世界の)レトロ」という軸で、買い物をきっかけに人との繋がりを生み出す新しいサービスを提案します。

ビジネスモデル

主なシステム要件

  • 各ユーザーは手元のアプリから「欲しいもの」「受け取りたいエリア」「受け取りたい時間帯」「一緒に受け取りたい他のユーザーの属性情報」を登録できる
  • アプリは複数のユーザー「受け取りたいエリア」をベースに、配達先を設定する
  • 自動宅配車が欲しい物を指定の時間・場所へ届け、各ユーザーはそこにて交流の機会を得る
  • 各ユーザーに別途入力されたプロフィール情報を元に、交流のテーマを設定する
    ※たとえば自家製パンの製造を趣味にしている人で集まることで食材などをある程度共通化する
  • 一定人数が揃わないと空けることができないコンポーネントなどを設けることで「まとめ買い」による販売を促進する

システム全体の概要図

全体概要図

ポイント1: 位置情報のリアルタイム更新

位置情報のリアルタイム更新

本サービスでは物理的に直接会えることが重要なので、地理情報を予め分割した状態で永続層に持たせることで、「ユーザーの現在の場所」「商品受け取り場所(合流地点)」を更新、索引できるようにする必要があります。

位置情報の検索処理を検討する上で、課題の1つがどのように位置情報をデータベースに格納すれば効率的か？ ということです。”移動躯体”がラピュタのように空を飛んでいるのではなく、地上を走行することを考えた場合、地上データは密にデータを管理する必要がありますが、海上や湖上という場所はそんなに必要ないかもしれません。

こちらの世界で、マッチングサービスとして稼働しているTinderでは、Googleが提供しているジオメトリライブラリであるS2 Geometry Libraryを活用することでジオシャーディング(地理情報のインデックス化)を行い、Elasticsearch クラスターに入れているようです。そのロジック自体非常に興味深い内容ではあるのですが、本ブログでは割愛させていただきます。なにかしらの方法でジオシャーディングを行ったデータをデータベースに格納し、ビジネスサービス用アプリケーションと繋がっているとします。

ここでは、「ユーザ（ここでは移動躯体）」の位置情報は定期的にクラウドと同期され、Google Cloud上にデジタルツイン(現実世界の情報がクラウド上に再現されること)が構築される状態を実現します。定期的な位置情報の更新に合わせ、各ユーザの所属するジオシャードは常に更新される仕組みを考えました。

デジタルツインを実現するためには、定期的な位置情報更新が必要ですが、それを裏で支えるために、パフォーマンスはなくてはならないポイントです。位置情報は利用者に合わせて同期的に送られるため、ビジネスのスケールに応じて多くのトラフィックを処理しなくてはいけないかもしれません。そのためにキューイングをクライアントとデータベースの間に噛ませることで、混雑を緩和させます。

こちらの世界で身近なところでいえば、タクシー用のシステムは上記要件と近しいと思われます。たとえば、タクシーアプリ『Go』を開発しているチームではアーキテクチャを公開しており、中でも位置情報を捌く「動態収集・配信システム」は興味深い実装をしています。メインシステムはGoogle Cloud上で動かしていますが、ManagedServiceであるGoogle Cloud Pub/Subを使わずに、Pub/SubをGKE上のアプリケーション、キュー情報をMemorystore for Redisで管理するようにしています。おそらく、Pub/Subにおいてデータ加工等の業務要件があり、採用できなかったのだと思われます。現在でしたらCloud Pub/Subとネイティブ結合されたDataflowを用いるなど別の選択肢がありえたかもしれません。

以上を踏まえて、本サービスでは位置情報の更新処理にあたり、Cloud Pub/SubサービスとElastic Cloud(ElasticSearchのManagedService、 非GoogleCloud)を採用させていただきました。

ポイント2: マッチングサービス

マッチングサービス

今回のシステムの要は、「買い物」を契機としたマッチングサービスです。上記で検討した位置情報検索サービスを元に付近のユーザーを探し、一緒に買い物をする場所を提供します。

単に近い場所にいるユーザーであればいいというわけではありません。マッチングするための要素として最も重要視しているのが、「買い物」対象について同じ指向を持つユーザー同士を引き合わすための仕組みです。※あえて嗜好ではなく指向と書いています

異なる食文化が摩擦を生み出す経験は、私もかつて卵焼きに砂糖を入れたことで、すれ違いという苦い思いをしたのでよくわかるのですが、それゆえにすり合わせは重要です。「買い物」を契機としてユーザー同士がつながりをもってもらうために、買い物対象はある程度傾向が同じであることが望ましいです。ビジネスサイドから見ても、多くの重複があることで食材の品種をある程度絞れるので、効率的な調達や配送ができることからメリットは大きいでしょう。

それでは、マッチングサービスの実装はどうなるのでしょうか？ Googleのテックブログでは、今回によく似た事例として「Vertex AI を利用して強化学習レコメンデーション アプリケーションをビルドする」として強化学習を行うための仕組みが紹介されています。この仕組みでは、ユーザーが試行を重ねることで精度を上げられるため、聞き放題のような試行回数を気軽に重ねられるシステムでは非常に有効ですが、本サービスでは残念ながらそのままブログの内容を流用できません。しかし、本質的なところは同じです。ユーザーの指向を特徴量として抽出したりベクトル化した上で、似たユーザーを引き合わすことが目標になります。

プラットフォーム上ではどんなレコメンデーションアルゴリズムを動かせば良いでしょうか。今回のブログでは、その詳細まで踏み込みませんが、参考文献をいくつか取り上げます。

たとえば、Alibabaクラウドのテックブログ「Basic Concepts and Architecture of a Recommender System」ではマルチチャンネルマッチング(複数のレコメンデーションアルゴリズムを元に三者協議する仕組み)とランキング(マッチングの条件にあてはまるものを優先度に応じて並び替えること)がEコマースにおいて重要だと伸べています。

今大きな隆盛を見せているディープラーニングも候補に入るでしょう。ZOZOさんのテックブログではディープラーニングを活用したレコメンデーション用アルゴリズムをいくつか紹介していますが、こちらも参考になりそうです。

マッチングの中には禁忌の組み合わせが考えられます。マッチングサービスにおいて論争になりそうな組み合わせ(先ほどの卵焼きにおける塩/砂糖問題)はルールベースで記載しておいて、ファインチューニングで定期的にモデルから取り除く努力が必要そうです。

上記を踏まえて、本サービスでは下記のような処理を検討しました。

  1. 注文を受注する「注文サービス」から、ユーザーの購買履歴やサービスの閲覧ログなどを「パーソナルデータ」として保存します
  2. パーソナルデータから、ユーザーを特定する機微情報などを取り除いた「レコメンド向け購買データ」をBigQueryに保存します
    a. このデータはマッチングサービス以外にも、購買予測や調達システムなどでも使用します
  3. 「レコメンド向け購買データ」をVertex AIの機械学習処理にかけて、どういった購買履歴を持つユーザー同士なら親和性が高くなりそうか、推論エンジンを作成します
  4. 注文後、マッチングを待つ「マッチングウェイティングサービス」から、下記条件で絞り込みを行い、マッチングを成立させます
    a. 「ジオシャード」から取得した位置情報
    b. 推論エンジンによるユーザー親和性判定

その他のポイント

本ブログでは書ききれなかった、アプリケーションアーキテクチャの考察ポイントであった議論をこちらで供養します

  • 「グループマッチング」と「受取地点・時間確定」の順番

今回のサービスは、「グループマッチング」した後で、「受取地点・時間確定」を決めていましたが、その逆もありえたかと思います。単純に落ち合う場所を最初に確保するだけではなく、街コンのようにテーマを決めた上で参加するような形式も今後このサービスが発展した上でありえるかもしれないと議論になりました。

最終的に「この世界では皆が自由なんだ。場所に縛られたくない」という、異世界転生者の一言で「グループマッチング」→「受取地点・時間確定」の順番になりました。

  • 自動運転車の走行を支えるためのシステム。あるいは自動運転を裏で支える機械学習プラットフォームのデザイン

機械学習のモデル構築は重要な作業ですが、そもそもそのためのトレーニング環境をいかに自動化するかというのも大きなポイントです。たとえば、「自律走行車のための継続的インテグレーションと継続的デリバリーを Google Cloud で構築する」を見ると、現実かゲームか？ と見間違うような仮想環境、そして道路上で起こりうるイベントを人手を介さずに自動で構築し、自律走行のためにトレーニング環境として活用しているかわかります。E2Eテストの延長線上に広がっている世界に戦慄しました。

  • 「支払い」を支えるためのシステムデザイン

PSP(決済代行業者、クレジットカード会社とユーザーの間に入って決済処理を代わりに行ってくれる企業)を用いて決済を行った場合、ユーザーが買い物をした後決済が完了するまでには一定の待ち時間が発生します。それをどういったロジックで吸収するのか、アーキテクチャ図を元に議論しました。

  • 地図における最適な経路を決めるナビゲーションシステムのデザイン
  • 買い物対象を、JITで調達するためのサプライチェーンマネジメントシステムのデザイン
  • 無人配送車から商品を安全に受け取るための本人確認/認証に関するシステムデザイン

今回は議論できませんでしたが、興味深いテーマです。

最後に

以上、「買い物を通じて人と人を繋ぐ」サービスとそのアプリケーションアーキテクチャの紹介でした。

今回の取り組みで最初に論点になったのが、こちらの世界で既にある既存サービスとの競合をいかに避けるかという点でした。最終的に異世界転生でいいんじゃないか？ という発想で解決しましたが、その結果、自由にシステムデザインを行うことができて良かったのではないかと思います。

最後に、こちらの世界で行われている取り組み、事業を紹介します。

「買い物難民問題」でよく問題が表面化するのが、「採算が取れずに近所のスーパーが撤退してしまった」ことです。その隙間を埋める1つに、一事業所のカバー領域が広く、人口密度が低い田舎であっても採算を確保できるネットスーパーがあります。しかし、すべての人の助けになるかといえば難しく、一部のデジタル化から取り残された高齢者、地方密着型スーパーのような新たな追加投資が難しい事業者の淘汰という新たな問題が生じました。

そこで最近名前を聞くようになったのが、「とくし丸」です。「移動スーパー「とくし丸」はなぜ“独走”しているのか　1000台突破の舞台裏」にあるように、地方のスーパーと協業したフランチャイズモデルを確立することで、採算性という大きなネックを解決しつつ、ネットスーパーではフォローできなかった人たちへの支えとなりました。

もちろん、官公庁でも「買い物難民問題」を座して解決を待っているわけではありません。農林水産省では「食料品アクセス（買い物弱者・買い物難民等）問題ポータルサイト」を立ち上げて、解決に向けた施策を実施、事業支援を行っています。地域に応じた各地での買い物支援の取組では、様々な事例が紹介されており、今回のサービスでも、ビジネスの種として参考にさせていただきました。

中でも印象深かったのが兵庫県神河町・寺前楽座 「 まちの灯り 」 の事例です。地区唯一のスーパーが運営難により閉店後、地元企業や住民出資により運営会社「株式会社 寺前村振興公社」を自ら設立し、再建されたスーパーになります。

消えたまちの灯りを取り戻すべく屋号は「まちの灯り」に決定。また寺前11集落全世帯から1万円を支援金として募り、地区住民自ら意識を持ってスーパーの経営、運営にあたるべく代表を一人、監査役として同公社に配置されたそう。
引用元: https://iimono.town/topic/life/18862/

さらには前のスーパーが閉店したときに勤めていた店長・従業員全員を新しい店舗でも再雇用したとのことで、地域でスーパーを守っていくという強い意志が感じられる取り組みでした。

再建後、四年経ちましたが、Googleの口コミでも、小さめなスーパーだが地域に密着した良いスーパーだと評判は良いようです。そこ目当てで旅行するには敷居が少々高そうですが、最寄りの寺前駅から播但線で更に北上すれば、天空の城で有名な竹田城跡があります。寄り道にはちょうどいいのではないでしょうか。

参考資料