2026-01-13 24:02

生成AIにタイムセール価格設定をさせて気が付いたデータ整備と言語化の重要性

ストアレコードのデータを活用し、生成AIにタイムセールの価格設定を試行した事例について議論します。在庫数や販売予測などのデータをAIに読み込ませ、消化優先や利益確保といった経営判断基準に沿ったオフ率の算出方法を検証しています。AI導入の前提として、データ整備の重要性や意思決定ロジックの言語化が不可欠であることを指摘し、実務の効率化と再現性を高めるための具体的なワークフローについて解説します。



⁠https://note.com/bizgem_1220/n/na7273062dcff

■番組内容

この番組は、中小小売企業の取締役経験のあるふたりがそのリアルについてゆるくお話します。


人事に軸足をおいたジェネラリスト戸部祐理が、2度のM&A経験がある連続起業家、樋口幸太郎に話を聞いていきます。

既に小売企業を経営している方、これから小売ビジネスで起業を考えられている方に役立つ情報を楽しく語っていきます。


■MC紹介

樋口幸太郎 / 山梨県甲府市出身。株式会社Bizgem代表取締役。新卒で伊藤忠商事入社→就職活動生向けWebメディアで起業→人材系ベンチャー企業にM&Aで売却→子供服D2Cブランド「pairmanon」運営会社の取締役就任→アダストリアグループにM&Aで売却。


小売企業向け経営データ一元管理SaaS「ストアレコード」提供中


⁠⁠⁠⁠⁠https://service.storerecord.jp/⁠⁠⁠⁠⁠


戸部祐理 / 株式会社デジタリフト HR・PR / アパレル企業で取締役→アパレル×ITスタートアップ→現職 / 11年在籍したアパレルでは店舗現場からバイイング、ブランド立ち上げ、バックオフィスにも広く携わり5年間取締役


■ご質問・メッセージ

ご質問・メッセージは下記URLからお気軽にご連絡ください。


⁠⁠⁠⁠⁠https://docs.google.com/forms/d/e/1FAIpQLSePaafkg7l4K-cm-SSZkQZGYJFfT4xscc6eH_3ws-xTCVKohA/viewform?usp=sf_link⁠⁠⁠⁠⁠


listen https://listen.style/p/retailtalk?B6krF6iu

サマリー

このエピソードでは、生成AIを活用したタイムセールの価格設定において、データ整備の重要性が強調されています。また、セール設定の背景や必要なデータについて詳しく掘り下げ、実務改善に役立つアプローチを探ります。生成AIを利用した価格設定において、データ整備と意思決定基準の言語化が重要であることが伝えられています。このプロセスでは、在庫管理や販売戦略の明確化が求められ、生成AIの出力を鵜呑みにせず、適切な判断が必要であることが指摘されています。さらに、自動化の可能性や業務効率化に向けた取り組みについても語られています。

生成AIの活用方法
この番組は、中小小売企業の取り締まり役経験のある2人が、そのリアルについてゆるくお話しします。
人事に軸足を置いたジェネラリスト、私戸部有利が、2度のM&A経験がある連続企業家、樋口幸太郎さんに話を聞いていきます。
既に小売企業を経営している方、これから小売ビジネスで企業を考えられている方に役立つ情報を楽しく語っていきます。
リテールトーク95回目です。よろしくお願いします。
お願いします。
今日は、ストアレコードのデータをもとに、生成AIにタイムセール価格の設定をやらせてみたというテーマです。
2026年明けましておめでとうございます。
おめでとうございます。
目松ねーし何してました?
目松ねーしは旅行、実家旅行って感じだったんで、結構移動してました。
いいっすね。どこ行ったんですか?
旅行、一発目は下野子と2人でホテル三日月、千葉。
2人で。なんか良さそう。
めっちゃ寒かったです、プールが。
プールって外ですか?
プールは外もあるんですけど、さすがにこの時期はなくて中なんですけど、
外に隣接するプールなんで、隙間風でめっちゃ寒いっていう。
プールも温水なんですけど、31度くらいなんで、生ぬるいっていうか。
外に出てトイレに行くとめちゃくちゃ寒いんで、初日だけにしようって言って、
あとは2泊したんですけど、ずっとゲーセンとか行ってました。甘やかしました。
全種類やりました、たぶん三日月にある。
すごい、合流じゃないですか。
合流しました。合流って言ってもですけど。
で、一原蔵の国とか行ってっていうのが1回目。
久しぶりに高校時代の友人と飯食うぜみたいな話あったんで、帰って、
その後家族でグランピング。
死ぬほど寒かったです、グランピングも。
この季節に行くもんじゃないなっていう。
まあ、そうっすよね。
上の子と下の子は寒すぎて寝れなかったって言ってました。
えー、そうなんだ。
身を寄せ合って寝たけどダメだって。
とべさんは何してたんですか。結構長かったですよね、今回。
長かったですね。逆にどこも行ってなくて、
年末年始どっかに行くっていう選択肢をあんま持たない感じで来ちゃってるんで行ってないんですけど、
だから友達の家行ったり映画館行ったりみたいなのらりくらりで9日間過ごしましたけど、
まあ、疲れましたね。
はっはっは、のんびりすんのも大変。
9連休ぐらいやりましたっけ、今回。
そうなんですよね。疲れました。
別の意味で。
今年もよろしくお願いします。
はい、よろしくお願いします。本題行きましょう。
テーマはStore Recordのデータをもとに生成AIにタイムセール価格の設定をやらせてみたということですが、
データの重要性
年末年始から初売りとか在庫とか値付けの部分振り返りたい時期かなと思うのでタイムリーかもしれないですね。
そうで、もともと生成AIなんかうまく使えないかな、プロダクトに組み込めないかなと思ってたんですけど、
壁打ちの相手とか相談相手みたいなところとか仕様の実装のヒントくれとか、
APIのドキュメント読んでちょっと要件定義してとかっていうのではよく使うんですけど、
小売業に汎用的に何か使えないかなっていうところで、
ユースケースがあんま特定できずにプロダクトに組み込むっていうのできなかったんですけど、
いろいろヒアリングしていて、自社でも運用代行とかしているんで、
その中でいいかなと思ったのが、
終時でタイムセールの設定って発生していて、
いわゆる初売りとかそういうセールだけじゃなくて、タイムセール価格みたいなのを結構イージモールだと設定して、
毎週のようにやるんで、この業務いいんじゃないかなと思ってやろうと思ったっていうのがきっかけです。
生成AIに品番ごとのオフ率を提案させて、
オフ率だけじゃなくて設定した根拠みたいなところもアウトプットしてもらって、
セール設定の実務の整備にもなったし、課題面も見えてきて、どういうふうに実装すればいいかも見えてきたんで、
ちょっとその話したいなと思ってます。
私はもともとアパレルの時代は店舗中心でモールとかはやってなかったんで、タイムセールとかはないですけど、
12月がシークレットセールで顧客向けのセールがあって、年収が本セールだったんですよね。
結構品番数が多い業態だったので、
12月のシークレットセール向けとその反応を見て本セールでオフ率2回、
自分で設定をするんですけど、結構俗人的な業務でなかなか大変だったんですよね。
だからそこのオフ率だけでもロジカルに仮決めみたいなのができたら、
それだけでも結構助かりそうかなみたいなふうに思ってます。
とはいえ、信頼できる結論がAIが出せるのかみたいなのは若干、
今時点では怪異的だなと思ってて、やっぱりちゃんと読み込ませるデータを揃える必要がありそうですね。
そうなんですよね。どんなデータが必要なのかも生成AIと議論しながらやろう。
自分の中で一応これかなっていうのを持ちながらも、生成AIも何欲しいの?みたいなのを聞いてやってました。
必須項目としてジェミニちゃんが言ってたのが、品番、SKUと商品名、定価、減価、
あとは現在の在庫数、これ必須ですと。あると望ましいものとして、発売日、直近の販売数、お気に入り登録数、
カテゴリーとシーズンみたいな形でもらったので、これらはそうだろうなと思っていたので、
ソフトウェアレコードに入っているデータの中でも、このデータがいいんじゃないかなみたいなので、
特に1クライアントさん向けでまずやってみようみたいな感じでやったので、
僕の方からもこれもらって、その上でもっとこうした方がいいんじゃないかなみたいなデータを出してピックアップしました。
品番、商品名、カテゴリー、定価、減価、あとは在庫数みたいなところは共通してあって、
セール設定のプロセス
あとは販売開始日も入れました。
加えて販売終了日、売り切れ予測日、7日間の販売数と平均オフ率、在庫日数。
それに加えて30日間の販売数、平均オフ率、在庫日数。
このデータがあればいいんじゃないかなっていうので、提案してやることにしました。
すごい、そんだけ参考値を与えれば確かに一定信頼できる結果が出そうな気持ちにはなりますね。
今挙げてもらったやつって何を考えるために必要なのかってちょっと聞きたいかも。
品番、商品名、カテゴリー、定価、減価、在庫数に関してはあんまり説明の必要がないのですっ飛ばして、
他の項目を話すと、販売開始日はいわゆるいつ販売したかのデータで、
ジェミにも言っているように、商品の新鮮度を測るためのデータなのと、
販売開始から1ヶ月はセールしないみたいな、そういうブランドさんも結構多いと思うので、
販売開始から間もない商品については様子見ようみたいな、そういうこともできるので入れたほうがいいかなと思って入れました。
あとは販売からだいぶ経過していて在庫日数が多いものについては、
最初から大胆なオフ率を提案してもらうために入れたという形です。
次に販売終了日はいわゆる年度高度とシーズン高度に相当するもので、
冬物だったら2026年の2月28日までに売り切りましょうみたいな、そういう設定をするためのものですと。
この販売終了日があることによって、販売終了日から逆算して、
今の現時点だと1日あたり、ないし1週間あたり、何枚販売する必要があるのかに対して、
今なんて売れているのかみたいなところが明確になるので、
このデータがあることでAIでも今の販売数とオフ率が十分なのかどうかみたいなところが、
判断する明確な指標になるかなと思って入れました。
ちなみに弊社のクライアントさんでもアパレルとかではなくて、
数年で売れる雑貨みたいなものを扱っている季節詳細じゃない場合は、
販売終了日の代わりに在庫日数、最適在庫日数みたいな形で、
60日分の在庫を常に持っておきたいとか、90日分の在庫を持っておきたいみたいな、
そういった形の詳細もあると思うので、
アパレルとかそういう季節詳細じゃない場合には、
最適在庫日数みたいなところを入れてもらうのがいいかなと思っています。
プラスして売り切れ予測日。
これはストアレコードの中で計算している需要予測のデータを基に、
その品番がいつまでに売り切れるかっていう日を計算しています。
これをAIに渡せば、売り切れ予測日が販売終了日よりも前であれば別にオフする必要ないし、
それが遥かに遅い場合には結構オフを深めないと売り切れないよね、
みたいな判断が可能になるので入れました。
その上で直近1週間でどのぐらい売れているか、
販売数と平均オフ率と在庫日数と、
直近1ヶ月30日間の販売数、平均オフ率、在庫日数を比べてもらうと、
販売が加速しているのか、鈍化しているのか、
加速している要因はオフを深めているからなのか、
もしくは需要が伸びてきているのか、みたいな判断ができるので、
これらのデータを入れることにしました。
前職だとこれに近いデータをスプレッドシートに入れて、
在庫日数が多いものについては条件付き書式を入れて赤くして、
順調なやつは緑にしてオフしなくていい、みたいなのをシート作って、
このシートを作るのに1、2時間かけて、
セール設定するのに2時間ぐらいかけて、みたいなことをやって、
設定根拠は一応一言コメント残して、
引き継ぎにも役立つように、みたいなことをやったような記憶が残っています。
すごい、設定根拠を残すのすごいいいですね。
再現性があるとか偉すぎますね、それ。
めっちゃでも適当ですけどね。
加速している、オフ深めない、みたいな。
いや、でもこの人こう考えたんだっていうのが残ってると、
その公認も考えやすいですよね。
で、終始で全部ファイルを残してたんで、
11月はこういうことを考えている、12月はこうなってる、
12月になって焦ったな、みたいな、そういうコメントも分かるっていう感じでした。
素晴らしいですね。
そのままデータを品番ごとに全部まとめてCSVでダウンロードして、
セール設定して、みたいな感じで投げると、ちゃんとやってくれました。
ここからちょっとAIの回答をそのままサマリーして読み上げると、
販売終了日までに売り切ることを最優先目標として、
品番ごとの推奨オフ率を出しましたと。
ロジックは危険水域、要注意、微調整、順調利益確保の4パターンに分けて設定してますと。
生成AIによるタイムセールの活用
危険水域のものは売り切れ予測日がもう本当に翌々年以降、
もしくは販売終了日より半年以上遅れてる。
こういうのはもう大幅なオフ率アップをします、みたいな形で。
消化遅れ、やや遅れ、利益確保はそれぞれこういう定義です、みたいなのを回答してくれて、
さらに気が利くのかご確認いただきたい点、みたいな形で赤字判定を入れました。
一部消化を優先しすぎて減価を下回る設定になっているものがあるので、
そこは赤字判定列を入れました、みたいなところと、
これは結構気が利くというか、やってくれてるな、みたいな感じで思いました。
またトレンドとして7日間の平均オフ率をベースに計算しているけれども、
直近で大型イベントとかあった場合は数値が高く出ちゃうから注意してね、
みたいな注意喚起もしてくれて、結構気が利くなと思いました。
これ与えているデータがそれだからですけど、
単純に在庫量だけじゃなくて時間軸がしっかり入っているのがいいですよね。
いつまでに売り切るかっていうのがゴールで、
それに対して進捗を見て修正しているみたいなニュアンスですよね。
そうなんですよね。回答を見ると分かる通り、何を優先しているか。
今回の場合だと販売終了日までに売り切ること、
あらり無視して赤字出てでも売り切るのを優先しましたっていうのは、
明確に出してくれたのが良くて、
各品番ごとに赤字なのか黒字なのか判定しているので、
それもある程度分かりやすいなと。
結構この結果をもとにクライアントさんと話したんですけれども、
ブランドによってはやっぱり最大の値引き率っていうのが50%までみたいな設定をしていて、
それでも売り切れない場合は翌年にかけて消化していく。
ないし、アウトレットとかサイジでさばいちゃうみたいな、
そういうブランドさんもあったので、
この辺りは別にプロンプトでこういう設定にしてくださいみたいなのを、
ちゃんと設定しておけばそこは神してくれるんだろうなと思いました。
データ起点で出してくれるの結構いいですよね。
データを見ながら人がやるっていう場合も、
人間の頭の中で今言ってもらったデータを全て網羅するのって結構無理があるじゃないですか。
そもそも逆に言うとデータが出る環境になってても、
それを効果的に使い切れてないみたいな企業さんもあるかもしれません。
一方でやっぱり怖さとしては、
タイムセールのセール設定をする人が、
ロジックをちゃんと言語化して理解していないと、
生成AIが出したものでいいやになっちゃうのは怖いなって思いました。
データ整備と意思決定基準
もう完全に思考停止して、生成AIが出したやつでそのまんま設定したら、
とんでもない赤字になりましたであったり、
在庫帯流がすごかったですみたいなところがあるので、
ここはロジックとどういうタイミングでどういう意思決定をするかみたいなのを、
結構明確に意識してないとうまくいかないなっていうのを感じてたときに、
飲み友の渡さんいるじゃないですか。
渡さんのツイートが流れてきて、
やっぱりエンジニアの採用とかエンジニアの開発の界隈でも、
AIが出したコードなんで正直中身わかんないですみたいなまんま、
プルリクっていう提出をして、
それを読む人が大変みたいなそんな話が上がってきたので、
これ同じことが生成AI使ってタイムセール設定するときも起きるだろうなっていうのをタイムリに思いました。
私が今携わっている採用系のツールでのAIのプロダクトもあったりするんですけど、
それでも同じですけど、やっぱり生成AIが出してくれるのは結構確かな仮説であって、
それをもとに人が決定するみたいなプロセスは結構大事にした方が良さそうだなと思いますね。
そうなんですよね。
これやりながらやっぱ重要だと思ったのが2点あって、
1個目がそもそもデータ整備されてないといけない。
データ整備の重要性と意思決定基準の言語化。
その前チャンネルトークのリオさんと話したときも出てきたと思うんですけど、
やっぱり言語化されてないとうまく使えないっていうのはあるかなと思いました。
1個目のデータ整備の重要性みたいなところでいくと、
品番ごとの販売終了日を明確に設定するであったり、
品番ごとの販売予測をちゃんと行っていて、
売り切れ予測日なんかを品番単位で持っておく。
あとは直近1週間と30日間の品番ごとの販売数、
オフ率、在庫日数みたいなのがパッとデータで出せるみたいな環境にないと、
生成AIに投げるっていうことすらできないかなと思っていて、
このデータの取得すら生成AIならできるんでしょうみたいな、
何でしたっけ、ラグでしたっけ、このデータを検索させてみたいな、
そういうAI周りの技術もあるんですけど、
それをやろうとすると、開発コストとランニングコストがものすごいかかるんで、
データの整備の前さばきみたいなところは、
事前にやっとく必要があるかなっていうのをすごい思いました。
データ整備の重要性と密接に結びつくけど、
そもそも何を元に意思決定するんだっけっていうところの言語化が
すごい大事かなと思いました。
販売開始から1ヶ月なのか2ヶ月なのか、
いつまでプロパーで販売して、
タイムセールにかけるタイミングはいつなのか、
タイムセールでは何パーセントオフまで許容するのか、
オフ率の幅がジェミニじゃなくてチャットGPTにやったら、
1パーセント刻みでめっちゃ細かくやってきたんで、
1パー刻みなのか1パー刻みなのかも決めとかないといけないなと。
そもそも販売終了日まで在庫金額をいくらまで減らすのを目標にするのかであったり、
在庫金額を減らすことを優先するのか、
あらりを確保することを優先するのかみたいな、
経営の意思決定の基準とそこに紐づくタイムセールの設定基準みたいなのを
明確に言語化しておかないと、
AIも困っちゃいますよねというのがあるので非常に重要だと思いました。
企業の具体的な運用例
例えば全職の子ども区は、今思うとタイムセール設定の方針は結構言語化しているというか、
こういう風にやろうみたいなのを決めていて、
やっていたので、これそのまま入れるとある程度、
全職と同じような運用できるかなと思ったんでちょっと紹介すると、
1個目が品番の最終仕入れ日から半年後までに総仕入金額の99%を消化すると、
消化率99%をKPIにしているというのはこういう定義でした。
各品番の販売終了日までに90%消化。
その後、だらだら消化じゃないですけど、
販売終了日過ぎてからもオフ深くすると売れる部分もあるので、
最終仕入れ日から半年後までに99%消化するというのが2個目。
詳細ですね。
基本3つ目はセールのオフ率は5%刻みでやっていました。
一方でZOZOの企画タイムセールの条件というのを重視していたので、
そこが41%とか51%とかっていう場合には、
企画タイムセールに条件を載せて見ているというような形です。
販売開始の1週目から実はタイムセールには欠けているというような形で、
ZOZOの企画タイムセールの最低条件に載せて販売動向を計測します。
次がリピート発注をしていたので、
発注算も考慮して売り切れ予測というのを実施していました。
なので今の在庫では順調だけど発注算がめちゃくちゃあるから、
結構予約でも消化しなきゃいけないし、
実在庫入ったタイミングで結構加速させないとやばそうみたいなところも見てました。
オフ率の上限なしです。
99%オフまで理論上いきますと。
上限なしなんですね。
上限なし。上限なしでやって、
最終仕入れ日から半年後まで99%消化することを優先しています。
そうは言っても90%オフまでで売り切れてるかなという感じでしたね。
販売から1ヶ月間はZOZOの企画タイムセールの最低条件で様子を見ます。
1ヶ月経過したら5%以上を刻みで、段階的にオフ率を高めて、
どのぐらいこの7日間と30日間の販売が加速するかを見ますと。
販売動向が看板しくない品番に関しては、
限界利益がゼロになるオフ率まで一気に踏み込む。
それでも売れない品番に関しては、段階的にオフ率をさらに踏み込んで、
赤字でもいいから消化にかかるというような形にしていました。
あとですね、結構あんまりやってない会社が多いかなと思ったのが、
オフ率を深めて販売が加速して踏み込みすぎたなみたいな、
すごい在庫も消化しすぎちゃったみたいな品番に関しては、
翌週以降にオフ率をものすごい緩めるみたいな、そういう運用もしていて、
あまり結構段階的に上げていったら戻さないみたいな運用をしてる会社さんが多いんですけど、
他は結構戻したりっていうのもすごいやってました。
すごい、これめちゃくちゃ有益な言語家だと思うんですけど、
さらっとしゃべってくれましたけど。
ここまで意思決定ロジックがクリアになってる企業さんって、
そんなないんじゃないかなと思ってしまうのと、
個人の頭の中でやってるのと、
形式化されてることで組織のナレッジになると思うんで、
俗人的にオフ率設定してると、癖とかもあると思うんですよね。
それが適正に近づくみたいなこともありそうだなと思いました。
AIに向けようときにプロンプト書けるか書けないかじゃなくて、
自社の意思決定が明確化されることそのものに価値があるし、
それによって経験が少ないメンバーでもAIでも判断できる、
再現性みたいなのが大事ですね。
そうなんですよね。固定先のテクニックじゃないですけど、
プロンプトはこう書きましょうとか、こういうのを入れるとAIが賢くなるみたいなところには本質はないかなと思っていて、
自分たちの意思決定基準が明確に言語化されるみたいなところが、
やっぱり再現性もって、とべさんおっしゃっていただいた通り、
組織に根付くのかなと思ってます。
一方でこの辺のタイムセールであったり、
カラリーに対する方針って、もう全然言語化されてないかなと思ってます。
なんなら今年はもう営業黒字にできそうだから過剰な値引きは抑えてねって言ってたら、
翌月にやっぱり営業利益黒字になんなそうだから在庫消化しようみたいな、
データ整備と自動化の重要性
こういう触れ幅の大きい方針の変更をしてしまっている会社が、
おそらく多いんじゃないかなと思っているので、
やっぱり会社として経営として何の指標をどういう風に重要視するのか。
前職でいくと消化率99%っていうのを達成した上で、
BSが一回転、在庫が一回転して出たPLっていうのが成績表みたいな、
そういう考え方を強く持っていたので、
これはちょっとやりすぎかなと思うんですけど、
消化90%みたいなのを決めて、そこが第一です。
次にあらりです。限界利益です。みたいな、
そういう経営の、KPIの優先順位の明確化にもつながることかなというのは思います。
黒字化するためにやっぱみたいな話は、
めっちゃあるんじゃない?
経営人とかその上の人の鶴の一声で困ってる現場みたいなのも結構何個か目に思い浮かんで。
聞きますよね。
あると思います。
そうして、自動化される未来がちょっと見えた感じがしたなぁと思いました。
これね、僕自動化できると思ってて、今それ開発しようとしてるんですけど、
ちょっと大変かも、意外にいけるかもみたいなところのセットギアなんですけど、
前職で行くとやっぱこのタイムセール設定って本当に月曜の朝に数時間かけて資料を作って、
品番ごとのオフリスもまた1時間とかそういう時間をかけてうなりながらやってたんで、
そもそもこの資料を作る、分析収集する時間っていうのはいらなくなるっていうのは思う。
ちょっと開発を検討しながらヒアリングをクライアントさんにしてるんですけど、
ワークフロー機能をStore Recordに実装しようかなと思っていて、
どういう機能かというと、Store Recordとスプレッドシートを自動連携して、
毎週月曜日の朝9時に特定のスプレッドシートをコピーして、
名前をYYYYMMDDセール設定みたいな名前に変更をして、
Store Recordの特定のデータを連携させますみたいな、そういうことが可能そうですと。
そのスプレッドシートに先生が提案するオフ率をR列と何とか列に
設定根拠とオフ率を出してくれるみたいな形にして、
担当者はそれを見て、このオフ率そのままでいいやつはそのままにして変えてしまって、
そうするとセール設定のシートが変わっていて、
ポチッと押すとShopifyに飛んでセール設定が完了する、
のぞに飛んでいってセール設定が完了するみたいな、
そこまでは行ける未来が見えましたね。
すごい。
なので、相当多くない?年内に行けるんじゃないかな?どうかな?みたいな感じで思ってるんですけど、
やっぱり最終的にはスプリとかExcelで判断したいっていうニーズはすごく大きいと思っていて、
で、ただそこまでの自動化っていうのと、
あとは判断する手前の合理的にロジック組んでAIが提案してくれるっていうのは、
結構省力化につながるんじゃないかなと思っていて、
前々からこういう生成AI×自動連携みたいなところで業務の効率化できないかなと思っていたので、
今回その実験をちょっとやってみて解像度が高まったので、すごい良かったなと思っています。
すごい。ロジカルな背景で意思決定ができるだとか、
そこの業務の効率化で作業時間が短縮されるみたいなところはすごい良いですね。
改めてデータ整備の大事さとか意思決定プロセスの言語化の大事さとか、
AIの活用した未来みたいなのを感じるお話でした。
意識の違いと聞き取り
1個気になったのが、私はジェミニ君と呼んでるのに対して、
樋口さんはジェミニちゃんと呼んでて、異性を思い浮かべるもんなんかなみたいなのが1個気になりました。
タクトGPTちゃんですね、確かに。
そうなんだ。私はチャッピーと呼んでますけど、君の設定でしたね。
なるほど。異性かどうかあんまり意識してなかったですけど、ちゃん呼びしてますね。
ちょっとこれは人に聞いてみたいな。
ありがとうございます。
今日はストアレコードのデータを基に、
生成AIにタイムセル価格の設定をやらせてみたというお話でした。
ありがとうございます。
ありがとうございます。
リテールトーク、ここまでお聞きいただきありがとうございます。
番組の詳細欄にGoogleフォームのURLがあるので、質問やメッセージはそちらからお送りいただけると嬉しいです。
番組内でご紹介させていただくかもしれません。
次回もぜひよろしくお願いします。
24:02

コメント

スクロール