ミッション！エンドユーザが買い物しやすいECサイトを目指そう！
今回のユースケースでは、ECサイトの担当者として、エンドユーザのニーズを収集・整理して、より使いやすい・買いやすいサイトを目指すことがミッション。ECサイトはCXが売上に直結しそうですし、ちょっとした使いづらさが機会損失につながりそう。
たとえば、CXに問題があるサイトの課題として「検索ができず、欲しい商品が見つからない」「人気の商品はすぐに品切れで買えない」「購入までのフローが分かりにくい」などが挙げられていました。
顧客体験（CX）に問題画あるWebサイトの例
……うん。ここまでそろうと、途中であきらめてほかのECサイトで探すパターンになるやつですね。これでは、よほど商品力がない限り、売上アップは厳しそう。
ここまでのサイトはそうそうないのでは……という疑問が頭をよぎっていきますが、あくまでも例！サンプル！分かりやすく解説するためのユースケースですから！
さて、一般的にこれらのニーズをECサイトに盛り込むとなると、エンジニアに実装を依頼することになりますが、AIサービスを使ってある程度自分でできたらいいですよね？ね？（念押し）
まずは、課題に優先順位をつける。考えるべき3つの“軸”
では、いろいろある課題のどれから手をつけるか、まずは優先順位をつけていきましょう。ここで軸となるのが「ビジネスインパクト」「データの入手性」「機械学習への適用性」の3つ。
課題を解決しても、ビジネスインパクトがあまり期待できないならば優先度は低くなりますし、どんなに売上アップにつながるとしてもデータがなければ後回しです。あとは、すぐに使える機械学習サービスがあるかどうかもひとつの判断基準になります。
ビジネスインパクトはちょっと測りづらい気がしますが、下記のような計算式が紹介されていたので、これを参考に算出してみるのもいいでしょう。
（もともとの作業に必要な工数 ― 機械学習導入後に必要な工数）×時給＝機械学習の価値
さて、この3つの軸で、課題を整理すると下表のようになります。
表はスライドできます
| 課題 | ビジネスインパクト | データの入手性 | 機械学習の適用性 |
|---|---|---|---|
| ユーザの動線を可視化したい | 中 | 安易 | Amazon CloudWatch RUM |
| 売れた/売れなかった原因を分析したい | 低 | 中 | Amazon Lookout for Metrics |
| 商品検索できるようにしたい | 高 | 安易 | Amazon Kendra |
| 過去の実績をもとに発注数を決めたい | 高 | 困難 | Amazon Forecast |
とりあえずここに挙がった課題はどれもAWSのサービスを使って実現できそう、ということで、ビジネスインパクトとデータ入手性の2軸でマッピングすると、こんなイメージです。
ビジネスインパクト・データ入手性で見る課題の位置づけ
ここでは、データ入手が難しい「過去実績をもとに発注数を決める」はいったん対象外とし、残りの3つを順にためしていきます。
Amazon CloudWatch RUMで、ユーザ動線を可視化する
まずは「ユーザ動線の可視化」から。ユーザがWebサイト内でどのように動いているかを把握することで、「フローが複雑になっていないか」「分かりにくいところはないか」「ユーザがサイト内で迷子になっていないか」などが見えて、改善につなげられる、という理屈ですね。
ここで使うのが「Amazon CloudWatch RUＭ」。AWSのモニタリングサービス「Amazon CloudWatch」の機能のひとつで、リアルタイムユーザモニタリング（RUM）を実現します。要するに、エンドユーザのWebアプリケーションでの動線を可視化するということ。数行のスクリプトで、アクセス数だけでなく、動線分析もでき、どの順番にページにアクセスしたかを確認できるようになります。「カートに入れてから購入までに複数ページを行き来していて、どこから購入するかが分かりにくい。カートに入れたあとそのまま購入ページに遷移するリンクを追加することに」とかそういう改善ができる……ということでしょうか。あまりにシンプルな例でアレですが……。
ちなみにこのサービス、いきなりですがAIサービスでは“ありません”。AI/ML Editionなのに！？と思っちゃいますが、なんでもかんでもAIでやろうと思うのではなくて、AIまで使わなくても解決できる課題があるよ、という一例ということでひとつ……。
数行でWebサイトのアクセス分析！動線解析！というサービス自体はもはやそれほど珍しいものではありませんが、こういうサービスもAWSが揃えにきているんだ、というところが新しい気づきでした。
Amazon Kendraで、サイト内に検索機能をつける
次は商品の検索機能です。ここで使うのがAmazon Kendra。少し前のコラム（ゼロETL、Amazon KendraなどAWS re:Invent 2022で見たデータ分析系サービスの進化）でも取り上げたもので、すぐに試せるインテリジェントサーチエンジンです。re:Invent 2022のレポートでは、社内用検索エンジンとしての用途を紹介しましたが、要するに対象を限定して使える検索エンジン、ということでしょう。ECサイトの商品検索にも展開できるようです。
Amazon Kendraでは機械学習が活用されていて、キーワードと合致したものを挙げるのではなく、検索クエリの“意味”をもとに結果を並べてくれるのだとか。たとえば「トマト 育てやすい」と検索すると、トマトの種よりも、初心者向け栽培キットを上位表示する、といったイメージになるのだと。
ECサイトに限らず、サイト内の検索はちゃんと機能しないと、「見つからないからいっそGoogleで検索してしまえ」となりがちで、離脱につながりかねないもの。こうやって「ほしいものにちゃんとたどり着けて、すぐに買える」検索機能は重要な気がします。
売り切れる・売れ残る原因をAmazon Lookout for Metricsで分析する
では最後に在庫適正化、いってみましょう。AWSには売上予測のAIサービスもありますが、それはデータをそろえる難易度が高くなるので、まずは「売り切れや売れ残りが出てしまう原因を分析する」ところから。そしてそれを実現するのが、時系列データの異常値分析をおこなう「Amazon Lookout for Metrics」です。一般的に、異常値検出をおこなうには、データサイエンティストが閾値などを設定する必要がありました。それでも、たくさんの商品の販売データから、特定の異常値を見つけるとなるとかなり大変。閾値を設定し、リアルタイムに把握するには経験者の勘が頼り……ということに。
ところが、Amazon Lookout for Metricsを利用すれば、機械学習により、自動でグルーピングと異常値検出をおこなえるのだと。購入データを投入すれば、売れ行きの傾向が分かり、その知見を商品開発や在庫管理に役立てれば、品切れ・売れ筋以外の在庫削減につながる……ということ、らしい。
ですが、「異常値検出がなぜそれにつながるのか」がさっぱりピンときません。いろいろと調べてみまして、おそらく、「アクセス数に対する売上がほかの商品と比べて低い」などを“異常値”として検出できて、それによってアクセス元によって売上が変わっているとか、スマホからのアクセスだと売上が落ちるとか、そういうのが分かる、ということかなぁ、といったん理解しています。
ひととおりユースケースを紹介してきまして、「非エンジニアでもこれで解決だよね♪」と言われても、本当にそうかな……みたいな気持ちではありますが、やってみるだけなら簡単にできそうだなという気はしました。
顧客体験（CX）の向上は、いまやどの企業でも大きな課題。もちろんこのパターンをそのまま適用できるとは思いませんが、探せば自社の課題にあったサービスがすでにあるかもしれないし、そのまま使える可能性もあるのかもしれない、とは思いました。
ソニービズネットワークスでは、AWSのAI/MLサービスの導入支援もおこなっており、ソニー独自のAIサービス「Prediction One」も提供しています。気になるサービスを試してみたい、自社のデータと連携させて使いたい、などあれば、ぜひご相談いただければと思います。以上、シイノキでした！
