検索から、
AIエージェントへ。

ユーザーはもう、聞いて決めることに慣れてしまいました。

条件をひとことで言えば、AIが聞き返して、絞って、理由をつけて出してくれる。この体験に慣れた人が、そのままの期待を持って自社サイトに来ます。そこにあるのが検索窓とフィルタだけだったとき、ユーザーの感覚ではそれは「不便」ではなく「古い」です。

それは「不便」ではなく、
「古い」です。

このとき差がつくのは、3つだけです。

私たちが担当するのは、この3つすべてです。データだけ整えて渡す会社でも、UIだけ作る会社でもありません。

この先のページは、①データ → ②エンジン → ③UI／UXの順に説明します。これは、そのまま作る順番でもあります。読み終えたところで、いま自社がどこにいるかを確認できるようにしてあります。
なお、ここで整えたものは外部のAIに聞かれたときにも効きますが、私たちが主に担当するのは自社サイト・アプリの中の体験です。

基幹システムをそのままつないでも、
AIは答えられません。

そこには「正確な値」はあっても、「意味」が書かれていないからです。誰向けの商品なのか、どんな時に使うのか、いま在庫があるのか ── AIが判断に使える形になっていません。間に、読んで判断できる層をつくります。

ここでいう中間データとは、基幹システムとAIの間に置く、AIが読んで判断できる形のデータのことです。構造（商品の意味づけ、FAQ・規約の構造化、在庫と価格の即時参照、出してはいけない条件）と、量（誰が何を見て何を買ったかの行動ログ、聞かれたことと選ばれたものの対話ログ）の2つで構成します。
この中間層の設計は、配信のために整えるデータと大部分が重なります（→ MA用データ開発（SERVICE 03））。CRMのために整えたものが、そのままエージェントの土台になります。

構造は、あとからでも作れます。
量は、始めた時点からしか貯まりません。

いきなりAIから始めません。

「レコメンドを入れたのに、人気商品しか出てこない」

レコメンドには段階があります。データが薄い段階で高度な手法を入れても、当たりません。いまのデータ量と、出したい場面から選びます。

「まずAIで」と始めると、検証も説明もできないまま止まります。説明できる仕組みから入れて、データが貯まった順に置き換えるのが、結果的にいちばん早いです。新規顧客や新商品でデータが無い状態（コールドスタート）にはコンテンツベースで対応し、行動が貯まってから協調フィルタリングへ寄せます。どの段階に進めるかは、いま持っているデータで決まります（→ MA用データ開発（SERVICE 03））。
次の章では、これを③どう聞いて、どう返すか ── 聞き方と返し方の設計に進みます。

レコメンドとエージェントは、
置き換えではありません。

よく「レコメンドとエージェント、どちらを入れるべきか」と聞かれます。これは二択ではありません。レコメンドは「何を出すか」を決める判断で、エージェントはそこに「聞く力」と「説明する力」を足したものです。使い分けを決めるのは、機能ではなくお客様の状態です。

この順番には理由があります。対話は、出すものが決まっていないと成立しません。先に「何を出すか」を説明できる状態にしてから、聞き方と返し方を設計します。逆から始めると、よく喋るけれど的外れなものが出来上がります。

対話は、出すものが
決まっていないと成立しません。

次にやることは、いる場所で変わります。

①データ・②エンジン・③UI／UXは、独立した選択肢ではありません。下から積み上がる3段です。いま止まっているのは、どの段ですか。症状を左に、先にやることを右に並べました。同じ「うまくいっていない」でも、段によって先にやるべきことは正反対になります。

下の段が空いたまま上を作ると、よく喋るけれど的外れなものができます。いちばん多いのは、①を飛ばして③から始めてしまうケースです。

いちばん惜しいのが、③UI／UXまで作ったのに①データが空いているケースです。UIは動いているのに、渡すものが無いせいで答えられない。ここでプロンプトやモデルを調整しても直りません。AIは、渡されたデータの質以上には賢くなりません（→ MA用データ開発（SERVICE 03））。

PoCで終わらせません。1つの導線から、本番に出します。

検証だけして終わる案件を、いちばん多く見てきました。最初から本番の1導線に出し、増分で判断します。

何をどの順で打つかの設計からご相談の場合は CRM戦略設計（SERVICE 01）から。

ご検討時に、必ず聞かれること。