オープニングと番組紹介
この番組は、中小小売企業の取り締まり役経験のある2人が そのリアルについてゆるくお話しします。
人事に軸足を置いたジェネラリスト、私戸部有利が インドのM&A経験がある連続企業家、樋口幸太郎さんに話を聞いていきます。
既に小売企業を経営している方、これから小売ビジネスで 企業を考えられている方に役立つ情報を楽しく語っていきます。
リテールトーク101回目です。よろしくお願いします。
お願いします。
101回目ですね。すごい。
すごい。2年間まるっと続いてます。
すごい続いてます。2年以上か。
ですよね。たぶん毎週やってたら52週だから104回なの。 4回僕が忙しくてスキップしたり、なんかできなかったのがあったけど、
日本コンスタントにやってますね。
すごい。継続してますね。なんか他に継続してることってあります?
マラソンと酒飲むことぐらいです。
マラソンは継続していると言っていいと思うんですけど、酒飲むことって継続になるんですかね?
断酒してないかもしれないですね。しばらく。休館日がないかもしれないですね。
私も一応20歳と言いますけど、20歳から妊娠期間だけ断酒して、他はほぼ365日飲んでますね。
飲んでますね。
走るのは結構コンスタントに毎月100キロ以上走って、これは継続してますね。
すごい。それ継続してるのがすごいですね。
これやるとでも酒がうまくなるんで、酒は止まらないんですよ。
めちゃくちゃご飯も美味しいんで。
酒のために頑張ってるんですね、やっぱみんな。
酒のために頑張ってます。
私も週に2回ぐらい飲みの予定が必ず入ってるんですけど、そこをターゲットに生きてますもんね、どうしても。
そうですよね。逆算してこの日いっぱい食べるからちょっと走る量を増やそうかみたいなことをやってます。
えらい。101回なので200回目指していきましょう。
頑張りましょう。
本題です。
AIツールの活用事例：Claude CodeとShopify Sidekick
今日はテーマがAIが使えるデータの作り方、小売企業のデータ基盤を考えるというタイトルです。
そうなんですよ。クロードコードを触りました?
触ってなくて、触れそうなノートみたいなやつも見るんですけど。
めっちゃ話題になってるんで、そろそろ今後仕入れてAIみたいなのやるかみたいな。
ChatGPTとかGeminiとかもやっているんで、コードの開発とかそういうのに活かそうみたいな感じでクロードコードを触ってみたんですけど、同日で。
すごい開発できちゃって感動したんで。
めっちゃ気になる。
ストアレコードの開発でちょっと進捗遅れてるな、この部分だったら大丈夫かなみたいな感じでフロントエンドのコードだけを触る感じでやってました。
僕自身全然意味わからずにクロードコードにお願いして書いてもらって反映してローカル環境で動くことを確認したらそのままプルリクエストって言って反映するような形で送って、
エンジニアさんにレビュー依頼して本当に本番環境に反映させてもらいました。
エンジニアさんはちょっとAIが書いたコードを樋口さんが投げてきた、見るのめんどくさいなみたいな感じで嫌そうだったんですけど、
データとかを持ってこないとか表示は変になってないみたいな感じだったんで、
もうフロントエンドのそういった部分は僕が責任を取るから公開しちゃっていいですよっていう感じで言って渋々公開してもらいました。
すごいちゃんと動くものできちゃうんですね。やっぱりこれでエンジニアさんに頼めればすごい早いわけなんですよね。
何がいいかっていうと結構あるのがお客さんから例えば商品ページにこういうリンクがあって発注の一覧に飛んでこの商品の一覧が見れると嬉しいみたいな、
そういう簡単な修正依頼、僕自身でもHTML触れば何とかなりそうかなみたいなそういう依頼があった時にものすごい早く反映することができますと。
エンジニアさんのトゥールタスクみたいな感じでチケット管理してるんですけど、
これまでだと聞いた僕がチケットをノーションで作成してエンジニアさんに依頼してエンジニアさんが今のタスク完了したタイミングでそのタスクに取り掛かってレビュー依頼してOKだったらリリースするみたいな感じだったんで、
場合によってはそういう簡単な修正にも1週間かかるとか、業務的なエンジニアさん5人ぐらいいらっしゃるんですけどみんな今の業務があるから挟み込めないみたいな感じになると結構対応に時間がかかったり、
タスクが溜まって無視されてるそういうのもあるみたいな感じだったのが、僕が聞いてクロードコードにパッて投げて修正して次のリリースでそれが反映されるみたいな、そんなフローになったのでそれが一番大きいですかね。
制度が信頼できるんだったら割と事業のスピードみたいなところにも影響ありそうですね。
そうなんですよね。今フロントエンドの簡単な修正に留めているものを責任を持てる範囲を広げていったり、安全にAI使って開発できるみたいなところをどこに設定するかによってかなりスピードにも影響ありそうで、結構検討したいなと思いながら、バインドシェアめっちゃ持ってかれるんですよね。
あれやっときたいなとか、そことの兼ね合いでそこに僕がリソースを使ってもいいのかっていうのはちょっと考えないとなと思ってます。
うんうん、なるほど。自然言語でできるっていうのが大きいですよね。
もうそこがめちゃくちゃ大きいですね。
ECの現場とかでもデータ分析とかできたらめちゃくちゃよさそうですね。
あれ触ったことないですか?ショッピファイのサイドキック。
私ショッピファイとか触ってないんですよ。
なるほど。
全然わかんないんですよ。
ショッピファイのサイドキックって自然言語でお願いできるAIなんですけれども、すごい優秀で、ショッピファイの注文データ、商品データ、サイコデータみたいな、ありとあらゆるデータにアクセスして自然言語でやり取りして回答できますと。
僕らもクライアントさんのショッピファイ入らせてもらって分析とかで使ったり、またサイトの構築じゃないですけど、どういうふうに修正すればいいかとか、ヘルプ的にも使えて顧客分析、ストア分析、ストア構築が簡単にできて、ショッピファイ触ってる人はかなり使ってるんじゃないかなと思ってるんですよね。
すごい良いですね。
一方でなんでこれできるかっていうと、ショッピファイの中でしかできないですよと。
ZOZOに行った瞬間、ZOZOにもいるんですよ、AIの猫ちゃんみたいなやつが。
いるんだ、猫ちゃん。
ZOZOの管理画面に猫ちゃんいるんですけど、ちょっと1ヶ月前使った時はポンコツすぎて、これは使えないなっていう感じで、もしかしたらすみません、めちゃくちゃ進化してて、ZOZOの方聞いたらもう今そうじゃないですよって言われるかもしれないんですけど、当時はサイドキックと比べちゃうとめちゃくちゃポンコツでしたと。
ショッピファイの中だけでできますよと。
なんでこれできるかっていうと、商品と注文と顧客と決済データがちゃんと紐づいていて、それをベースにちゃんと優秀なAIにつなぎ込みをして分析できてるから、みたいなところなんで、結論データベースがちゃんとリアルタイムで相当整えられてないとできないなっていうのが思ったところです。
なるほど、そのAIが優れてるっていうよりかはデータ構造がちゃんと整ってるっていうのが本質っていう感じですかね。
一方でZOZOのを見るとAIも相当優れてるんだなと思いますね。
そっかそっか。
ZOZOもデータは整ってるんで。
分けるデータの品質の良さみたいな、この2軸かなと思います。
小売企業におけるデータ基盤整備の課題
これでショッピファイだけの分析じゃなくて、他のチャンネルも統合したデータで分析できたら一番理想かなと思うんですけど、統合したデータをどう整備するかっていうとやっぱデータをどう整えておくかっていうのが課題になりそうですね。
データの課題はそう、僕がストアレコード始めた理由でもあって、中小企業が一番悩んでるポイントだなっていうのをクライアントさんのデータを見ても本当に思うところなんでやっていきたいなと思ってます。
やっぱり一元管理する場所がないんですよね、中小企業にとって。
だいたいExcelとかスプレッドシートをデータベースとして使うので、データの関連性っていうのがシートで切れちゃってるっていうのが大きくて。
それ解決しようっていう時にパッケージの基幹システムみたいなERPを入れようっていう風になると業務のオペレーション全部変えなきゃいけないので、もう重い選択になりがち。
費用もかなり重い。結構ITリテラシーの高い取締役とか経営人がいるような会社だと、セールスフォースとかキントーンでスプラッチで開発しましょうみたいな感じでやってる会社あるんですけれども、
これは結構やれる会社は限られる。ITリテラシー、相当高い経営人がいて、さらに外注先、ベンダーさん、ないしエンジニアさんがちゃんと確保できてみたいなところ、
プラス要件定義してみたいなところで、コースが相当重いなと思ってます。
なんでそういったところができない企業向けにある程度簡単に業務データの蓄積が可能なものを提供したいなと思って始めたのがStore Recordで、
これが本当にAIがすごい伸びてきたタイミングでうまくつなげられるんじゃないかなみたいなのは思ってます。
頑張ってまとめようとしないとやっぱり各々のシステム上にデータがあるっていう感じになっちゃいますもんね。
そうなんですよね。僕が基本的にクライアントさんとして、または想定顧客として考えている会社さんとかだと、
リアルで10億前後の小売企業ですと、リアルやってたらポスガスマネジとか使っていて、クラウドのポス使っていて、自社ECショッピファイでやって、
楽天市場とAmazonで販売していて、OMSがNextEngineとかロジです、WMSがロジザドみたいで、発注と納品はExcel管理ですみたいな形でいくと、
統合したデータベース全くないですよというようなのが想定のお客さんです。
こういう状況だとAIで分析したいって言っても無理なんですよね。
そもそもデータがバラバラだし、SKUの統合もされてないし、
AIに依頼しようとしても、AIもどのファイル読んでいいか分かんないし、そもそもファイルにアクセスできないみたいな形なので、
AIが何でも解決してくれるっていうところからは相当遠いみたいなところが、多くの会社がいる現在時点かなみたいなのを思ってます。
そうするとやっぱりデータベースの基盤整備っていうのと、そのデータを置いておく場所みたいなのは絶対必要になるなっていう形で思ってます。
データサイロ化とExcel管理の限界
ツールに最適化されてて全体非最適みたいな状態になってますよね。
これデータがサイロ化してるとAI分析以前の問題ですよね。
具体的なクライアントさんがストアレコードを導入前にやってた業務でいくと、タイムセールの設定っていうのをZOZOTOWNって毎週できるので、
それに向けてタイムセールの設定をしているんですけれども、ZOZOだけじゃなくて他のサイトの売れ行きも加味したいので、
全ての販売サイトから注文データを各30日分ダウンロードしますと。
発注さんと入荷予定のデータを見ながら在庫が重くなりすぎてないかみたいなのを判断するために、
発注管理をしているExcelからCSVでダウンロードしてきますと。
在庫データもZOZOとOMSに分かれているので、OMSからCSVでダウンロードして、
この会社さんは売り上げ結構ある会社さんなので、注文データ30日分とSKUごとの在庫データで相当重いっていう感じです。
お気に入り数も各サイトから楽天、ZOZOTOWNみたいなところからダウンロードして反映させて、
各品番ごとに過去30日と7日間の販売数と入荷予定の数量と在庫数量とお気に入り数をばーって並べていくみたいなことをやっていると、
ファイルがですね、100MBを超えてたんですよね。
これ送ってこられたんですけど、開けなかったんですよね。
エクセル100MB。
ハラスメントだな、データハラスメント。
めちゃくちゃ右まで行っちゃってて重いとかそういうのじゃなくて、単純に詰まったデータだったんですね。
右までも行ってますし、タブもすごい量あって、CSV貼り付け用のタブがものすごくあって、各タブも重い。
色付けもすごいし、参照の式と計算式と関数が盛り盛りなんで、
開くのもつらいし、よく共有してもらえたんだっていうぐらいの、ギガファイル便とかで送られたのかもしれないです。
これでもすごいわかりみが深いと思ってて、
私も自前で何とか連携するシステムを作りたくて、
5店舗ぐらいある店舗のELタイム在庫をクラウドを使ってデータリンクをしてファイル連携してたんですよね。
何個もデータ開かなきゃいけなくて、開くまでとにかくめちゃくちゃ時間がかかる。
重いエクセル開けるようにPCのスペックを上げるっていう話もしてました。
それめちゃくちゃ本末転倒感だと思って。
10MB超えるエクセルは使っちゃダメって言ってますね。
その会社さんに導入していただいて、100MBあった同じデータが数百キロバイトで済むように、
スマレコードのカスタムダッシュボードとか各種ダッシュボードを使ってダウンロードしてもらうと、
同じまではいかないですけど、近しいデータが数百キロバイトで見れるんで、
回数も増えるし、意思決定の速度と回数が増えるみたいな形で喜んでもらったのかなというふうに思ってます。
確かにそう考えるとすごい神システムかもしれないですね。
いやー100MBが数百キロバイトになる。
AIによるデータ分析の可能性と民主化
でも意思決定のスピードと回数が上がるってすごい良いと思うんですけど、
在庫消化のためのセールとか目の前のことだけじゃなくて、多角的な分析とか試作検討みたいなのができそうですね。
そうなんですよ。加えてAIで自然言語で分析すると、スマレコードもそうですけど、
こういう分析できるかもって思ってデータをダウンロードしてみたいな、
目的がはっきりしてないとこういうデータベースを扱うって難しいなと思っていて、
さらにそのデータをクエリ関数とか叩いてとかSQLで見たりになると、
さらにできる人少なくなるのを、現場の人が自然言語で何を聞けばいいのかわからない状態で
こういうデータ出せるかなみたいなやり取りの中でデータに触れる機会ができるっていうのが
結構分析の民主化じゃないですけども、起こせるんじゃないかなみたいな感じで思っていて、
データベースちゃんと設計して運用コストを考えながらあらゆるデータを入れていくと、
結構分析の精度も高くなるし、現場の方でも使い勝手いいんじゃないかなっていうのが思っています。
これって具体的には何を任せられそうなんですかね?
それすらももうAIに聞いちゃおうかなと思っていて、
クルーズフォードコードにストアレコードのデータベース元に
どんな分析とかができるのとか得意なのみたいな話で出すといろいろ出してくれて、
1個目が発注ミスを検出します。発注したけれども消化率が低いみたいなSKUを抽出して出しますみたいなところから、
推奨発注数量みたいなのを打ち出しているので、その精度を検証してSKUごとに良かった悪かったみたいなところを出しながら、
どういうカテゴリーのアイテムだったら精度が高くて低いのかみたいなところから修正していくみたいなこともできますみたいなのから、
2つ目が販売パターンみたいな感じで所属がめちゃくちゃいい品番なのか、後からじわじわ売れていくのか、年から年中平均的に売れているのかみたいな販売パターンを分類して、
それをブランドごとに分析するみたいなそんなのもできますとか。
また店舗間の比較分析みたいなので、とある店舗で異様に売れている商品があるかないかであったり、
異様に売れてない商品を持っちゃってる店舗があるかみたいなところも抽出できるみたいな形でした。
また大量在庫の検出なんか得意です。
あとはSK別の荒利分析もパッとできるし、発注ミスの検出に近いんですけれども発注数が適切かみたいなところで、
消化の数量と発注数から発注しすぎているものと足りなかったものを抽出して振り返るみたいな、そんなことは全然パッとできそうっていう形でしたね。
すごい、守りもできるし、攻めにも使えそうやなっていう感じがしました。
私クロードコート使ったことないんですけど、普通に会話ベースでいけるんですか?
AIの得意・不得意とデータ整備の重要性
ただ画面を黒いエンジニアがよく使うカーミナルでやらなきゃいけないので、そこのハードルはありそうかなと思いながらも、
普通の会話ベースで使えますと。
どんな感じで使えるの?みたいな話をしたら、MDの方が今シーズン在庫で気になることがある、みたいなのをクロードに投げたら、3点気になる動きがあります。
1つ目、SKUこれは400枚の納品されたけれども、4週経過で消化率18%です。
同カテゴリーの平均は35%なので大きく下回ってます、みたいな回。
2つ目のSKUが過去3年間で5回在庫切れを起こしています。
在庫がある日の日版は平均12枚なんで、機械損失は推定180枚です。
3つ目は、仕入れ先Xから直近2回の納品リードタイムは25日で、設定値が14日とあるけれども廃離してます。
なので、この仕入れ先Xの設定値は良くない可能性があります、みたいな。
そんなことを検出してくれそうということです。
すごいですね。
ダッシュボードみたいなリアルタイムの可視化は既存のBIツールが向いてるけれども、
ワークロードとかAI使うときは何を見るべきかわかんないとか、
ちょっと探索して深くやりたいみたいなときに強いって回答で、
これまさにストアレコードやるとき僕やりたいなと思っていた、
社長の右腕になるようなサービスにしたいなと思っていて、
よく社長が経営企画室長とか右腕っぽい人に、この分析したいんだけど、みたいなのとか、
これってどうなってるのって聞くっていうのが結構あるなと思っていて、
AIでそこを回答するっていうのはできるようになるだろうなと思ってたのが、
クロードコードをちゃんと触るようにして、まだ1週間も経ってないですけど、
明確に未来がイメージできたんで、ちょっと開発しようかなっていうのが今って感じです。
これいいなと思うのが、多分樋口さんとかは数字見たらパパッとなんか視差があって、
じゃあこうしたらいいんちゃうかとか浮かぶと思うんですけど、
普通の現場レベルだと数字見てもそこから何を読み取ればいいかわかんないとか、
読み取りの年度とかも習熟してないと、そもそも仮説の持ち方がわかんないとか、
数字からストーリーを想像できないっていうのが現場レベルの普通なのかなと思ってて、
私も今採用の数値を見たときに、ある程度分析から打ち手まで思い浮かびますけど、
ECの数値見ていい視差出せる自信全然ないんで、ここの壁打ちができるっていうのはめっちゃいいなと思いました。
嘘もつくんで使いどころとあれは考えながらですけど、
まさにその壁打ちとそのデータのどういうふうに認識するかみたいなところはすごい得意なのかなっていうことでした。
逆に苦手なこととかやれないことみたいな話をクロードコードAIに聞いたら、
定性的な分析ができないですと、このデザインは来年も売れるかみたいな感覚的な予測はやっぱりデザイナーとか、
これは今シーズン終わりだよねみたいなのはやっぱりできないと。
ストアレコードの中にデータがないと外部要因分析はできませんと。
SNSでバズったりテレビで取り上げられた競合の動向によってこうなったみたいなところは難しいと。
あとは因果の特定もできないって言っていて、ある特定の商品が発注ミスで売れなかったのか、
商品自体の問題なのかみたいなところの因果の特定っていうのはできないらしくて、
やっぱりデータだけでわかることについては強いけれども、
こういう判断が必要な部分みたいなのは苦手っていうのは正直に言ってました。
AI君はデータだけのものを見て、これが原因でしたって言ってきちゃいそうだから、
そこを信用しきらないみたいな、そのAIに頼るべきこと、頼らないべきこと、
ちゃんとこっちが認識している必要がありそうですね。
マスターデータ整備の具体例と将来設計
そうなんですよね。改めて感じたのは、結構ストアレコードのお問い合わせが増えてきて導入を進めてるんですけれども、
とにもかくにも商品マスターの統一を頑張ってほしいっていうのがすごいあって、
やっぱり商品マスターが整っていないと原価のデータがないので分析できないみたいなところから、
販売サイトごとにSKUが異なっているのでマッピングが必要になるみたいな形で、
販売データの集約もできないと。
なので各サイトごと販売しているところでのSKUとマスターのSKUを紐づける、
そういったところはものすごい大事で最初の一歩かなと思ってます。
すごい地味ですけどね、ここの土台がないとAIみたいにレバレッジも効かないし、土台が大事ですね。
この土台がないと本当にできなくて、ここから取引先のマスターであったり、
ブランドマスター、カテゴリーマスター、店舗マスター、あとは余日とか文文分析する場合は文文マスターみたいな感じで、
分析したい単位の整理がすごい重要だなと思ってます。
カテゴリーマスターの整備っていうのはこれ結構大事ですよって言っていて、
なかなかちょっとまだ整備しきれてない会社さんが多いんですけど、
前も言ったかもしれないですけど、例えばTシャツっていう分類しちゃうと、
長袖もあれば半袖もあって、ハーフスリーブとか一部だけとかもあるんで、
年から年中売れちゃうみたいなカテゴリーになっちゃうので、
これをちゃんと季節需要に応じて分けないと正しい分類にならないですよねみたいな形で、
そういったところまで目を光らせて、分析が正しくなるようなマスター設計するっていうのが結構肝かなと思ってます。
確かにそこのカテゴリー設計一つで需要予測の精度みたいなのがめっちゃ変わりそうですもんね。
それこそ事件を始める時って規模小さいからカテゴリーを詳細まで分けなくても大丈夫って思っちゃいそうですけど、
将来的に分析軸この方がいいんじゃないみたいなのを見据えた設計できてると良さそうですね。
めちゃくちゃ大事で、後からもちろん整える意思決定をして地道にやっていくみたいなことが、
そのタイミングが売上10億ぐらいなのかもしれないなと思ってます。
まさに分析とかって規模が大きくなればなるほど意思決定に対するインパクトが大きくなってくるので、
規模が大きくなったタイミングでやるのがいいかなと思っていて、
それまではやっぱり業務の都合優先みたいになっちゃうんですよね。
ZOZOが売上のメインだからZOZOに合わせて登録しよう。
楽天のカテゴリーをカテゴリーとして商品マスターにも持っておこうみたいな感じだと思うので、
それをこういう意思決定をしたいから、さらにAIにこういうことを判断してほしいからこういう設計にするっていうのを
売上10億ぐらいの規模になったら真剣に考えると、
どんどんどんどんレバレッジが効く意思決定ができるのかなというふうに思いました。
結論とエンディング
結論、AIはすごいけど、その前にデータを整備しろって話ですね。
そうですね。間違いない。
はい、ありがとうございます。
今日はAIが使えるデータの作り方、小売企業のデータ基盤を考えるという話でした。
ありがとうございます。
ありがとうございます。
ディテールトーク、ここまでお聞きいただきありがとうございます。
番組の詳細欄にGoogleフォームのURLがあるので、質問やメッセージはそちらからお送りいただけると嬉しいです。
番組内でご紹介させていただくかもしれません。
次回もぜひよろしくお願いします。
