- 品ぞろえの多いオンラインストアは、かえって顧客を迷わせます。数点に絞り込む手伝いをしてくれる人がいないからです。
- よい販売アシスタントは、全商品を並べて見せる代わりに、予算、用途、制約を尋ね、2〜3点を理由とともに提案します。
- そのためには、正確で漏れのない商品データが前提になります。システム上の価格や在庫が実際と合っていなければ、提案も間違ったものになります。
従来のWebサイトやアプリの限界
実店舗では、腕のいい店員がいくつか質問をして、2〜3点を選んで見せてくれます。ところがWebサイトでは、検索窓と一緒に100点もの商品を顧客の前に並べています。商品が多いほど顧客は決められなくなり、そのままページを閉じてしまいます。
商品カタログを大きくしても、顧客が選びやすくなるわけではありません。従来の絞り込み機能（フィルター）を使いこなすには商品の専門用語を知っている必要があり、比較も顧客が自分でしなければなりません。そのうえ、価格、在庫、レビュー、取引条件の情報はあちこちに散らばっています。
従来の検索と絞り込みは、買い手が商品名を知っていて、仕様も理解しているときにはよく機能します。しかし多くの顧客は、小さな店を開きたい、今使っているシステムと組み合わせたい、置き場所が限られている、といった「実現したいこと」から考え始めます。結果として、絞り込みの条件を選び間違え、見当違いの点で比較し、見た目はよくても実際の条件に合わない商品を買ってしまうことがあります。
新しい世代のAIコマースアプリは、商品を探す前に、顧客の言葉を要件（Requirement）と制約条件（Constraint）に置き換えるべきです。システムの役目は、利益の大きい商品を押し出すことに限りません。使えない選択肢を除き、トレードオフ（何を得て何をあきらめるか）を説明し、検討の経緯をページや端末をまたいで引き継いだり、販売担当者に渡したりできるようにする必要があります。
| 従来の形 | 新しい世代のAIプロダクト |
|---|---|
| クリック履歴にもとづくレコメンド、人気商品の表示、よくある質問に答えるチャット | パーソナルショッパーが普段の言葉で要望を受け取り、候補リストを作り、トレードオフを説明し、在庫と配送エリアを確認して、顧客が確定するためのカートを用意する |
責任を持って商品を勧めるシステムは、AIとカタログのルール、リアルタイムのデータを組み合わせて動きます。AIは人の言葉を理解する部分を受け持ち、制約エンジン（Constraint Engine）が使えない選択肢を除きます。カートに入れる前には、APIで価格、在庫、条件をもう一度確かめます。
ビジネスに使える新しい機能
つまり、よい商品選びのアシスタントに求められるのは、検索窓の性能よりも、店員のように尋ねる力です。何に使うのか、予算はいくらか、どんな制約があるのかを聞き、候補を数点に絞って、それぞれを選んだ理由も伝えます。
プロジェクトの形
パーソナルショッパーは、SKUからではなく、顧客の課題から始まる買い物の体験です。ユーザーはチャットで相談したり、設置場所の写真をアップロードしたり、予算を選んだりしたあと、比較画面で候補リストを見ます。システムは提案の裏に理屈を隠さず、顧客が制約条件を変えられるようにして、選択肢がなぜ変わったのかをその場で見せるべきです。
主な機能
機能としては、質問による誘導、互換性チェック、セットの組み立て、代替品の検索、比較、理由の説明が考えられます。在庫、価格、プロモーション、配送、返品ポリシーも最新のデータから表示します。商品が品切れのときは代わりの商品を提案し、同等の仕様と、妥協が必要な点もあわせて伝えるようにします。
技術とデータ
モデルそのものより大事な土台は、商品情報管理（Product Information Management）です。商品コード、属性、単位、商品同士の関係が一貫した形で管理されている必要があります。そのうえでハイブリッド検索、制約エンジン、ランキングモデルを組み合わせ、在庫、価格、プロモーション、カートとAPIでつなぎます。システムに覚えさせたい好みのデータについては、顧客の同意を取ります。
ビジネス上の効果
顧客は商品探しにかかる時間が減り、理由が見えるので安心して選べます。企業の側では、種類違いの注文や同じ質問の繰り返しが減り、優秀な販売員の知識を時間を問わず提供できるようになります。顧客が入力した制約条件のデータからは、従来の検索キーワードでは見えなかった品ぞろえの穴や需要もわかります。
- 構造化されたデータをもとに比較し、仕様を作り話で補わない
- 好みは同意を得たうえで記憶し、顧客が修正できるようにする
- 高い商品を押し出さず、予算と用途に合わせてセットを組む
- 購入後も、取扱説明書、保証の申請、正しい型番での再購入までサポートする
架空のケース
具体的な利用場面
あるオフィス用品店では、顧客に人数、スペース、予算、購買規定を入力してもらいます。AIエージェントは3つのセットを理由とともに提案し、在庫を確認して、社内承認用のリストを作ります。ただし、決裁権のある人が確認するまで支払いはしません。
もう1つの架空のケースとして、あるカフェがコーヒーマシンを選ぶ場面を考えます。電源容量、1時間あたりの杯数、カウンターのスペース、予算に制約があります。システムは結果を左右する情報だけを尋ね、電源容量が足りない機種を除いたうえで、グラインダー、フィルター、メンテナンスの周期を含めたセットを組みます。
最適な機種が在庫切れのとき、システムは理由もなく高い機種に切り替えたりはしません。新しい選択肢を比べ、どの仕様が下がるのかを示し、入荷を待つか、代替機種にするか、スタッフに相談するかを顧客に選んでもらいます。それまでの検討内容は、すべて一緒に引き継がれます。
理由を説明できる候補リスト（Explainable Shortlist）
勧める商品にはすべて、なぜ合うのか、どんな場合には合わないのか、データの出どころはどこかを答えられる必要があります。
説明できないときは、推測で埋めずに、顧客に追加で質問させます。
範囲、リスク、効果の測り方
指標はコンバージョンだけを見ず、提案の採用率、相性の不一致による返品、スタッフによる提案の修正、苦情も含めます。売上を伸ばしても返品が増え、信頼を損なうシステムは失敗です。スポンサーや利益率が判断材料に入る提案は、そのことを開示し、互換性のルールを飛び越えてはいけません。
データの欠けや販売目標によって、ランキングがゆがむことがあります。顧客の役に立つ提案とプロモーションを分け、顧客が自分の好みの設定を直せるようにします。
開発チーム向け · 技術指標
追跡すべき指標：Shortlist-to-Cart、Return Rate、Assisted Conversion、Margin Guardrail、Recommendation Override
- Discover：実際の業務を追い、通常のケースと例外の実例を集めます。
- Assist：人が主導権を持ったまま、AIに下書きや提案をさせます。
- Act：テストセットに合格してから、ツールを1つずつ使えるようにします。
- Scale：監視、フォールバック、コスト管理、責任者がそろってから範囲を広げます。
提案でクリックは増えたのに、返品、スタッフによる修正、苦情も増えている場合や、ある機種がどのルールで除外されたのかをチームが説明できない場合は、拡大のペースを落とします。どちらも、ランキングの工夫が商品データの正確さより先走っているサインです。
BUSINESS & PRODUCT READINESS
AIに販売員の代わりに提案させる前に、商品データはどこまで整えておくべきか
開発チーム向け · 技術的な詳細
パーソナルショッパーが信頼できるものになるのは、商品データがすべて同じ構造にそろっているときです。商品名、型番、価格、単位、在庫、互換性（Compatibility）、制約のそれぞれにIDと責任者が必要です。Webサイトとマーケットプレイスで記載が食い違い、PDFには古い価格が残っているような状態では、エージェントは矛盾したデータから選ぶことになります。モデルを調整する前に、まず商品データの整備状況（Product Data Readiness）から手をつけるべきです。
開発チーム向け · 技術的な詳細
もう1つはシステムの目的設定です。目標がコンバージョンだけだと、システムが高い商品を押し出したり、欠点を隠したりするおそれがあります。返品率（Return Rate）、苦情（Complaint）、提案の修正（Recommendation Override）をガードレールとして加え、通常の提案とプロモーションを分けます。顧客が理由を確認し、比較し、好みの設定を変えられるようにします。
まずは1つの商品カテゴリーについて属性辞書（Attribute Dictionary）を作り、単位、意味、許容される値、責任者を決めます。たとえば「ヘビーユースに対応」という表現は、確認できる条件に置き換える必要があります。データが欠けている商品には印をつけ、AIに推測で仕様を補わせないようにします。
判断のロジックは、絶対条件（Hard Constraint）と好み（Preference）にはっきり分けます。互換性、安全性、法規制はAIが破ってはならないルールです。色やスタイル、好みの優先順位については、ランキングにモデルを使って構いません。この2層を分けておくと、チームは提案の理由を説明でき、実際にテストもできます。
販売員の知識を、規模を広げられる商品選びの体験に変える
DNA Makerは、商品企画、マーチャンダイジング、営業、サービスの各チームと一緒に、優秀な社員の商品の選び方を整理し、Product Decision Map（商品選びの判断マップ）に落とし込みます。どの仕様が誰に関係するのか、どの選択肢は組み合わせられないのか、どんな場合に顧客へ注意を促すべきかを確認していきます。AIが商品の理屈を欠いたまま、セールストークだけをまねることのないようにするためです。
次にプロダクトデザインのチームが、ニーズを尋ねる流れ、候補リスト、比較、セット、理由の説明（Explain-why）までの体験を形にし、顧客に試してもらいます。質問は十分に短いか、顧客が制約条件を直せるか、説明が本当に判断の助けになっているのか、文章を増やしているだけなのかを測ります。
DNA Makerは、提案の理由が目に見える画面の設計をお手伝いします。要件のまとめ、候補リスト、横並びの比較、セットから、カート、担当者への引き継ぎまでが対象です。アーキテクチャは、商品データ、ルール、コンテンツをプロンプトから切り離す形にします。そうすれば、お客様のチームは会話の仕組みを作り直さずに、属性や条件を変更できます。
試験はシャドーモードから始められます。システムが作った候補リストを顧客には見せず、スタッフの提案と比べる運用です。そのあとで、小さな商品カテゴリーから公開します。私たちは実際の質問から評価用のケースを作るお手伝いをし、互換性、理由の妥当性、返品、検討にかかった時間を測ります。より複雑なカテゴリーへ広げるかどうかを決めるのは、その結果を見てからです。
開発面では、ECサイトやアプリ、商品情報レイヤー、AIパーソナルショッパー、在庫・価格API、カートと承認の機能、購入後サポートのアシスタントを構築できます。どの提案がどのデータを使ったのかはログに残し、管理者はルールを変更したり、リスクのある提案を確認したりできます。
商品の選択肢が多く、スタッフが機種を勧める前に顧客へいくつも質問しなければならない場合は、1つのカテゴリーから始めてみてください。私たちがデータを評価し、候補リストのプロトタイプ（試作版）を作って、決済（チェックアウト）につなぐ前に実際の会話で試します。まずはご相談ください。
SOFTWARE ENGINEERING GLOSSARY
ソフトウェア開発用語集
ここに挙げる用語は、商品データやランキングから承認までをカバーしています。システムが制約条件をどこから知るのか、提案の理由をどう説明するのか、カタログのデータが欠けているときに誰が責任を持つのかを尋ねるときに使ってください。
| 用語 | 意味 | わかりやすい例 | 開発チームへの質問 |
|---|---|---|---|
| Product Feed | システムが使うために渡す商品データ。よいフィードには商品コード、仕様、単位、価格、在庫、更新日時が一貫して入っていて、どの販売チャネルも同じデータを参照できる | 価格、在庫、仕様、商品コード | データを最新に保つ担当者は誰ですか？ |
| Recommendation | 状況に合わせて選択肢に順位をつけること。使えない選択肢を除くルールと順位づけの理由が必要で、言葉の上で似ているかどうかだけに頼るべきではない | 利用人数と予算に合わせて機種を選ぶ | この基準は顧客のためのものですか、売上のためのものですか？ |
| Preference | ユーザーの好みや制限。状況によって変わるもので、絶対のルールとして扱うべきではない。システムは、記憶した内容をユーザーが確認、修正、消去できるようにする必要がある | 据え付け工事が必要な商品は避けたい | 顧客は自分の好みの設定を確認して、削除できますか？ |
| Structured Output | 決まったデータ形式で返されるAIの出力。形式が決まっているので、プログラムで欠けている項目をチェックし、データを次に渡せる。自由な文章から事実を抜き出す場合のリスクも減る | SKUの一覧と理由を、別々の項目として返す | データが欠けているとき、システムはどう動きますか？ |
| Approval Flow | 取引の前に承認を得るための経路。金額、リスク、例外の有無に応じて承認者を決め、判断の理由と日時を記録して後から確認できるようにする | 上司が会社のカートを承認する | どの金額から、誰の承認が必要になりますか？ |
関連資料（原典）：https://ai.google.dev/gemini-api/docs/function-calling