Media > AI活用ユースケース > 営業 > 中古車販売店の営業が、お客様のあいまいな要望(予算・用途・色・装備)から在庫の車両を探し、条件に合う度合いと外れた条件を添えて示す

中古車販売店の営業が、お客様のあいまいな要望(予算・用途・色・装備)から在庫の車両を探し、条件に合う度合いと外れた条件を添えて示す

実装ステータス:構成例 技術的に実現可能な構成として設計したもの。自社未検証

お客様の「予算は200万円くらい、子どもが3人、スライドドアで白っぽい色」といった要望を、必ず守る条件とできれば満たしたい条件に分けて読み替え、全店の在庫から合う車両を探します。候補には、合った条件・外れた条件と、要望をどう読み替えたかを添えます。

サマリー
生成AI
Azure OpenAI Service/Claude/Gemini
AIサービス
Azure AI/Google Vertex AI/OpenSearch
対象業界
EC/その他/小売
対象部門
営業
対象業務
情報検索/比較検討
主な課題
営業フォローが追いつかない/属人化している/情報が見つからない
AIで行う処理
検索(RAG)
主な効果
対応スピード向上/検索時間短縮/機会損失防止
導入難易度
★★★☆☆
実装レベル
本格構成
費用感
RAG・個別開発(大)
人間の確認
条件付き
現在工数
64h/月
AI導入後
24h/月
想定削減
63%
年間削減
480h
モデル条件による試算値です。実在企業の実績ではありません。

01導入前 / 導入後の業務フロー

導入前(Before)
  1. お客様の要望を聞き、メモを取る
  2. 要望を在庫管理の画面の項目に置き換える(ボディの形、価格の上限、色)
  3. 絞り込んで探し、0件なら条件を外して探し直す
  4. 候補の車ごとに、装備の欄と写真を見て、要望の装備があるかを確かめる
  5. 他店の在庫も同じように探す
  6. 候補を3〜5台に絞り、お客様に提案する
導入後(After)
  1. 自動1時間ごとに、在庫管理の仕組みから車両の情報を取り込み、色の系統と装備の書き方をそろえて索引に入れる
  2. 人営業が、お客様の要望を画面に打ち込む(Webの問い合わせなら本文を貼る)
  3. 自動Claude が要望を、必ず守る条件・できれば満たしたい条件・お客様に確かめること、に読み替える
  4. 人営業が読み替えを見て、違っていれば直す
  5. 自動OpenSearch が、必ず守る条件で絞り、できれば満たしたい条件の合う数で並べる
  6. 自動候補が少なければ、できれば満たしたい条件を外す順を決めて探し直し、外した条件を一覧に書く
  7. 自動候補ごとに、販売の状態(商談中・売約済み)を在庫管理の仕組みに問い合わせる
  8. 人営業が候補を選び、お客様に確かめることを聞いたうえで提案する
各工程の詳しい説明を読む
  1. お客様の要望を聞き、メモを取る
  2. 要望を在庫管理の画面の項目に置き換える(ボディの形、価格の上限、色)
  3. 絞り込んで探し、0件なら条件を外して探し直す
  4. 候補の車ごとに、装備の欄と写真を見て、要望の装備があるかを確かめる
  5. 他店の在庫も同じように探す
  6. 候補を3〜5台に絞り、お客様に提案する

(a)要望の置き換えが人によって違う。 「子どもが3人」をミニバンと読む営業もいれば、5人乗りのSUVも候補に入れる営業もいます。どちらが正しいかはお客様に聞かないと分かりませんが、読み替えた事実が記録に残りません。

(b)0件と多すぎるの間を行き来する。 項目で絞ると0件、1つ外すと40件。どの条件を外せばよいかを、営業が1つずつ試しています。

(c)色と装備の書き方がばらばら。 色はメーカーごとの色名(「パールホワイト」「ホワイトパール」「白(パール)」)で入っており、装備は「ナビ」「純正ナビ」「メモリーナビ」と書き方が揃っていません。「白」で絞るとパールの車が漏れます。

(d)予算の言い方があいまい。 お客様の「200万円くらい」が支払総額なのか車両の価格なのか、200万円を少し超えてもよいのかは、聞かないと分かりません。

(e)Webの問い合わせへの返事が遅れる。 情報サイトで見た車が売れていたとき、代わりの車を探して返すまでに時間がかかると、お客様は同じサイトで他の販売店の車に問い合わせます。 返事の速さが、そのまま商談の数になります。

  1. 【自動】 1時間ごとに、在庫管理の仕組みから車両の情報を取り込み、色の系統と装備の書き方をそろえて索引に入れる
  2. 【人】 営業が、お客様の要望を画面に打ち込む(Webの問い合わせなら本文を貼る)
  3. 【自動】 Claude が要望を、必ず守る条件・できれば満たしたい条件・お客様に確かめること、に読み替える
  4. 【人】 営業が読み替えを見て、違っていれば直す
  5. 【自動】 OpenSearch が、必ず守る条件で絞り、できれば満たしたい条件の合う数で並べる
  6. 【自動】 候補が少なければ、できれば満たしたい条件を外す順を決めて探し直し、外した条件を一覧に書く
  7. 【自動】 候補ごとに、販売の状態(商談中・売約済み)を在庫管理の仕組みに問い合わせる
  8. 【人】 営業が候補を選び、お客様に確かめることを聞いたうえで提案する

4番目を人が行うのは、読み替えが推測だからです。 「子どもが3人」から乗車定員を決めるのはAIの推測で、お客様が5人乗りでもよいと考えているかは、営業が聞くまで分かりません。

7番目で販売の状態を探すたびに問い合わせるのは、売約が1日に何度も入るからです。 1時間ごとの取り込みでは、売れた車を提案することがあります。

営業が画面を開くのは、お客様と話しながらのことが多いはずです。 来店のお客様の前で要望を打ち込み、読み替えをその場で見せて「この条件で探してよろしいですか」と確かめる使い方もできます。読み替えをお客様と一緒に見ることが、そのまま確かめの手順になります。

02今回想定するシステム構成

構成図
在庫管理の仕組み(車両の情報)
   ▼【トリガー】1時間ごとの取り込み
AWS Lambda ── 色の系統をそろえる、装備の書き方をそろえる
   ▼
Amazon OpenSearch Service
   │   数値:支払総額・車両価格・年式・走行距離・乗車定員(range)
   │   区分:ボディ・ドア・駆動・色の系統・修復歴(keyword)
   │   装備:text + 検索のときの同義語(synonym_graph)
   ▼【人】営業が要望を打ち込む
AWS Lambda
   ├──▶ Claude(Amazon Bedrock)── 要望を条件に読み替える(構造化出力)
   ├──▶【人】読み替えを確かめる
   ├──▶ OpenSearch ── 必ず守る条件で絞り、満たしたい条件で並べる
   ├──▶ 在庫管理の仕組み ── 販売の状態
   ▼
候補の一覧 ──【人】選んで提案
役割想定する製品代替候補
検索基盤Amazon OpenSearch Service(range、bool、synonym_graph)Azure AI Search、Vertex AI Search(Agent Search)
生成AIClaude(Amazon Bedrock の Converse API、構造化出力)Azure OpenAI(Microsoft Foundry)、Gemini API
連携AWS Lambda(取り込み、要望の読み替えと検索の呼び出し、販売の状態の照会)AWS Step Functions
保管Amazon S3(取り込んだ在庫の写し、要望と読み替えと候補の記録)社内のファイルサーバー

在庫管理の仕組みには、この構成から書き込みません。 車両の情報と販売の状態を読むだけで、商談中の登録は営業がいつもの画面で行います。

価格は「支払総額」を軸にします。 自動車公正取引協議会の資料では、中古車の販売価格は2023年10月1日から「支払総額」の名称で表示し、内訳として「車両価格」と「諸費用」を示すことになっています。諸費用は保険料、税金(法定費用を含む)、登録等に伴う費用で、支払総額は登録の時期や地域などに一定の条件を付けた価格である旨を表示することになっています。お客様の予算は支払総額で比べるのが自然ですが、その条件から外れる費用があることも一覧に書きます。

03どうやって実装するのか

Step1

処理の起点を決める

起点は2つあります。1時間ごとの取り込みと、営業の検索のボタンです。

取り込みは、在庫管理の仕組みから全車両の情報を書き出して索引を入れ直します。仕入れて展示の準備中の車も入れ、状態の項目で「準備中」と分けます。 準備中の車は、お客様の希望によっては提案できるからです。

検索のボタンは、営業が要望を打ち込んだ後に押します。Webの問い合わせで特定の車が売れていたときは、その車の情報を要望の代わりに使う「この車に近い車を探す」のボタンも置きます。 そのときは、元の車の支払総額・ボディ・定員を条件の材料にします。

Step2

入力データを集める

データ中身取得元
要望お客様の言葉のままのメモ、またはWebの問い合わせの本文営業が打ち込む・貼る
車両の情報店舗、メーカー、車種、グレード、年式、走行距離、支払総額、車両価格、乗車定員、ボディ、ドア、駆動、色名、装備の欄、修復歴、保証の有無、点検整備の有無在庫管理の仕組み
色の系統の表メーカーの色名と色の系統(白、黒、銀・灰、青、赤、茶・ベージュ、緑、黄、その他)の対応営業で作る表
装備の同義語の表装備の言い方の組(「ナビ、カーナビ、ナビゲーション」「バックカメラ、バックモニター」)営業で作る表
販売の状態販売中・商談中・売約済み在庫管理の仕組み(探すたびに照会)

質を決めるのは、色の系統の表です。 メーカーの色名は数百あり、「パールホワイトⅢ」「ホワイトパールクリスタルシャイン」は、どちらもお客様にとっては「白」です。取り込みのときに色名から系統を引き、color_family に入れます。 表に無い色名は「未分類」にして、営業に表への追加を頼みます。

修復歴と保証・点検整備の有無は、必ず持たせます。 公取協の資料は、定期点検整備の実施の有無と保証の有無を明瞭に表示するとしています。候補の一覧でも、この3つは常に出します。

Step3

データの取得方法を決める

取るものどこからどう取るか
必ず守る条件に合う車車両の索引bool の filter に range(支払総額の上限、定員の下限)と term(ボディ、ドア、駆動)
できれば満たしたい条件車両の索引bool の should に term(色の系統)と match(装備)
予算を少し超える車車両の索引支払総額の上限を1割上げた range で別に探し、別の欄に出す
販売の状態在庫管理の仕組み候補の車両番号ごとに照会

索引の設定は次のようになります(同義語の組は一部だけを示します)。

PUT /stock
{
  "settings": { "analysis": {
    "filter": {
      "equip_syn": { "type": "synonym_graph", "synonyms": [
        "ナビ, カーナビ, ナビゲーション",
        "バックカメラ, バックモニター",
        "両側電動スライドドア, 両側パワースライドドア" ] }
    },
    "analyzer": {
      "equip_index":  { "type": "custom", "tokenizer": "kuromoji_tokenizer",
                        "filter": ["cjk_width", "lowercase"] },
      "equip_search": { "type": "custom", "tokenizer": "kuromoji_tokenizer",
                        "filter": ["cjk_width", "lowercase", "equip_syn"] }
    }
  } },
  "mappings": { "properties": {
    "stock_no":     { "type": "keyword" },
    "store":        { "type": "keyword" },
    "maker":        { "type": "keyword" },
    "model":        { "type": "keyword" },
    "total_price":  { "type": "integer" },
    "vehicle_price":{ "type": "integer" },
    "year":         { "type": "integer" },
    "mileage_km":   { "type": "integer" },
    "capacity":     { "type": "integer" },
    "body":         { "type": "keyword" },
    "slide_door":   { "type": "keyword" },
    "drive":        { "type": "keyword" },
    "color_name":   { "type": "keyword" },
    "color_family": { "type": "keyword" },
    "equipment":    { "type": "text", "analyzer": "equip_index",
                      "search_analyzer": "equip_search" },
    "repair_history": { "type": "boolean" },
    "warranty":     { "type": "keyword" },
    "inspection":   { "type": "keyword" },
    "stage":        { "type": "keyword" }
  } }
}

同義語は検索のときだけ効かせます。 公式のドキュメントでは、synonym_graph は検索の分析器だけで使うものとされ、索引のときに使うと複数の語からなる同義語の後ろの語の位置がずれる、とあります。索引のときに同義語を効かせたいなら synonym のフィルタを使うとされています。この構成では、同義語の表を直しても索引を作り直さずに済むよう、検索の側に置きます。

探す形は次のとおりです。

POST /stock/_search
{ "query": { "bool": {
    "filter": [
      { "range": { "total_price": { "lte": 2000000 } } },
      { "range": { "capacity":    { "gte": 6 } } },
      { "term":  { "slide_door": "both_sides" } },
      { "terms": { "stage": ["on_sale", "preparing"] } } ],
    "should": [
      { "terms": { "color_family": ["white", "silver_gray"] } },
      { "match": { "equipment": "ナビ" } },
      { "match": { "equipment": "バックカメラ" } } ] } },
  "size": 20 }

公式のドキュメントでは、range は gte・gt・lte・lt で数値の範囲を指定できます。filter の条件は点数に関わらず、外れた車を落とします。 should は点数を上げるだけで、外れた車も残ります。

Step4

AIへ渡す前に整形する

  1. 色名から系統を引く … 色の系統の表で color_family を入れます。2色の塗り分けは、主な色で1つ、color_family を配列にしてもう1つを入れます
  2. 装備の欄をそろえる … 全角・半角をそろえ、「・」「/」で区切られた装備を1つずつにします
  3. 価格を数値にする … 「198.0万円」を円の整数にします。支払総額が空の車は、total_price を入れずに印を付けます
  4. ドアの形を区分にする … 「両側電動スライド」「片側スライド」「ヒンジ」を3つの値にします
  5. 要望の文から個人の情報を外す … お客様の名前、電話番号、住所の番地を、Claude に渡す前に伏せます

3番目で支払総額の空の車に印を付けるのは、価格の条件で漏らさないためです。 支払総額が入っていない車は range の条件に合わず、一覧から消えます。画面に「価格未設定の車がN台あります」と出し、営業が在庫管理の画面で確かめます。

Step5

AIに処理させる

AIの仕事は、要望の文を検索の条件に読み替えることだけです。 探すのも、並べるのも、外す条件の順を決めるのも、規則と索引の仕事です。

させることさせないこと
予算・定員・ボディ・ドア・駆動を、必ず守る条件として取り出す書かれていない条件を足すこと
色・装備・年式・走行距離の希望を、できれば満たしたい条件として取り出す希望を必ず守る条件に格上げすること
用途の言葉(「子ども3人」「雪道」)を条件に読み替え、読み替えた理由を書く読み替えを事実として書くこと
確かめることを挙げる(予算は支払総額か、超えてよいか)車種や特定の車を勧めること
色の言葉を色の系統の値に当てる系統の表に無い値を作ること

「読み替えを事実として書かない」が、いちばん大事な線です。 「子どもが3人」から定員6人以上とするのは推測で、お客様は5人乗りで十分と考えているかもしれません。 読み替えた条件には inferred: true を付け、画面で色を変えて出します。

予算は、言い方で扱いを分けます。 「200万円まで」は上限、「200万円くらい」は上限を決めずに確かめることに入れ、仮の上限として扱います。どちらの場合も「支払総額か車両価格か」を確かめることに入れます。

Step6

指示内容を固定する

あなたは中古車販売店の営業を手伝う立場です。
お客様の要望の文を、在庫を探すための条件に読み替えてください。
要望に書かれていることだけを使い、書かれていない希望を足さないでください。

【読み替えの決まり】
- must: 外れたら提案にならない条件。予算の上限、乗車定員、
  ボディの形、ドアの形、駆動。お客様が「絶対」「必ず」と言ったもの
- want: 外れても他が合えば提案になる条件。色、装備、年式、走行距離
- 用途の言葉(家族の人数、雪道、通勤の距離など)から条件を作るときは、
  inferred を true にし、reason に元の言葉と読み替えた理由を書く
- color_family は【色の系統】の値のどれかに当てる。当てられなければ使わない
- ask: お客様に確かめること。予算が支払総額か車両価格か、
  予算を超えてよいか、読み替えた条件でよいか

【厳守事項】
- 「くらい」「ほど」「前後」の予算は must に入れず、
  budget_hint に書いて ask に「予算の上限」を入れてください。
- 特定の車種、メーカー、グレードを勧めないでください。
  お客様が名前を挙げた車種だけを条件に入れてください。
- 色や装備の希望を must に入れないでください。
  お客様が「必ず」と言った場合だけ must にしてください。
- 修復歴、保証、点検整備について、お客様が言っていない希望を作らないでください。
- お客様の年齢、家族の様子、収入を推し量って書かないでください。

【色の系統】white, black, silver_gray, blue, red, brown_beige, green, yellow, other
【要望】{request_text}

「色や装備を must に入れない」を明記しないと、AIは「白がいい」を必ず守る条件にします。 白の車が無ければ0件になり、白以外は全部合っている車を見落とします。

Step7

出力形式を固定する

Bedrock の Converse API の outputConfig.textFormat に JSON スキーマを渡し、次の形で受け取ります。

{
  "must": [ { "field": "total_price | capacity | body | slide_door | drive | model",
              "op": "lte | gte | eq", "value": "",
              "inferred": false, "reason": "" } ],
  "want": [ { "field": "color_family | equipment | year | mileage_km",
              "op": "eq | gte | lte | has", "value": "",
              "inferred": false, "reason": "" } ],
  "budget_hint": "",
  "ask": [""]
}

公式のドキュメントでは、Converse API の outputConfig.textFormat に JSON スキーマを渡すと応答がスキーマに沿い、enum が使えます。一方で、数値の minimum・maximum などの制約には対応していません。 予算や定員の値の範囲は、受け取った後に Lambda で確かめます(定員は2〜10、予算は10万円以上など)。

1つ目の理由は、must と want がそのまま filter と should になることです。 Lambda は配列を読んで検索の条件を組み立てるだけです。

2つ目は、inferred で読み替えを画面に出し分けられることです。 営業は色の変わった条件だけを見て、お客様に確かめます。

3つ目は、候補が少ないときに外す順を決められることです。 候補が3台未満なら、want を後ろから1つずつ外し、それでも少なければ inferred の must を1つずつ外して探し直します。お客様が言った must は外しません。

画面に出す候補の一覧は、検索の結果から Lambda が作ります。

列中身
車両店舗、車種、グレード、年式、走行距離、色名
支払総額支払総額と内訳(車両価格・諸費用)
合った条件want のうち合ったもの
外れた条件want のうち外れたもの、外して探した must
必ず出す項目修復歴、保証の有無、点検整備の有無
販売の状態販売中・商談中・準備中

「外れた条件」の列が、この一覧でいちばん大事な列です。 営業はこの列を見て、「白ではありませんが、他はすべて合っています」と説明できます。

Step8

システムへ連携する

つなぎ先方式内容
在庫管理の仕組み車両の情報の書き出し(1時間ごと)、販売の状態の照会(読み取りのみ)車両の索引の元、売約の確かめ
Amazon OpenSearch ServiceLambda からの索引への登録と検索車両の索引
Amazon BedrockConverse API(Claude)要望の読み替え
営業の画面社内の画面要望の入力、読み替えの確かめ、候補の一覧

顧客の管理台帳とはつなぎません。 要望と候補の記録は検索の記録として残し、商談の記録は営業がいつもの台帳に書きます。お客様の名前と要望を結び付けて検索の仕組みに残さないためです。

Step9

人が確認する

  1. 読み替えを見る … 色の変わった inferred の条件を見て、お客様の言葉と合っているかを確かめます。違えば画面で直して探し直します
  2. 確かめることを聞く … ask に挙がったこと(予算は支払総額か、超えてよいか)をお客様に聞きます
  3. 外れた条件を伝える … 候補を出すときに、外れた条件をそのまま伝えます
  4. 修復歴と保証を伝える … 一覧の必ず出す項目を、候補ごとに伝えます

2番目を省かないでください。 「200万円くらい」が支払総額か車両価格かで、候補はまったく変わります。

Step10

例外に対処する

起きること対応
候補が3台未満want を後ろから外し、次に inferred の must を外して探し直す。外した条件を一覧に書く
候補が多すぎる(50台を超える)want の合う数の多い順に20台を出し、残りは件数だけ出す
支払総額が空の車がある一覧の上に台数を出し、営業が在庫管理の画面で確かめる
候補が商談中・売約済み売約済みは一覧から外し、商談中は印を付けて残す
色名が系統の表に無い「未分類」として残し、表への追加を営業に頼む
構造化出力が返らない営業が条件を画面の項目で選んで検索だけを使う
定員や予算の値が範囲の外Lambda で弾き、営業に要望の書き直しを頼む
県外のお客様一覧に「支払総額は店舗の条件での価格」と出す

最後の行は、支払総額の条件のためです。 公取協の資料では、支払総額は登録の時期や地域などに条件を付けた価格で、管轄外の登録の費用や納車の費用は、要否がお客様によって違う諸費用として支払総額に含まれない例に挙げられています。県外のお客様に支払総額だけで比べると、後から費用が足されます。

Step11

記録を残す

  • 検索ごとの、要望の文(個人の情報を伏せたもの)、Claude の読み替えの JSON、営業が直した箇所
  • 検索の条件と、外した条件の順
  • 候補の一覧と、営業が提案した車両
  • 取り込んだ在庫の写しの時刻

営業が直した箇所を残すのは、読み替えの指示を直すためです。 同じ読み替えが毎回直されているなら、指示か色の系統の表に足りないところがあります。

04実装レベルの3段階

最小構成:手元のAIサービスで要望を条件に分け、表計算で絞る / 要望の読み替え
半自動化:上記+OpenSearch に在庫を入れ、営業が条件を入れて must と want で探す画面を作る / 全店の在庫の検索と、合う度合いの並べ替え
本格構成:上記+要望の文から条件を読み替え、外す順を決めて探し直し、販売の状態を照会する / 要望の文から候補の一覧まで

半自動化で、1件8分が5分程度になります。 色の系統と装備の同義語で探せるようになり、他店の在庫も一度に見えますが、要望を条件に組み立てる作業が残ります。本格構成で3分になり、この段階が本記事の想定です。 段階を飛ばさないでください。 半自動化の画面を1か月使うと、営業がどの条件を must にし、どれを want にしているかが記録から分かります。それを読み替えの指示に写してから要望の文を読ませるほうが、営業の感覚に合った読み替えになります。経験の長い営業の分け方を指示に写すことが、そのまま属人化の解消になります。

05工数削減シミュレーション

前提値(モデル条件)
対象人数
8 名
月間件数
480 件
1件あたり現在時間
8 分
1件あたり導入後時間
3 分
現在  480件 × 8分 ÷ 60 = 64 時間/月
導入後 480件 × 3分 ÷ 60 = 24 時間/月
月間削減時間
40h
削減率
63%
年間削減時間
480h
年間金額換算(時間単価2,800円)
134万円
モデル条件による試算であり、実際の効果は業務内容・運用方法によって異なります。

自社条件で導入効果を整理したい方へ

このユースケースを自社に当てはめた場合の前提値と削減見込みを、業務ヒアリングをもとに整理します。

AI活用について相談する

06向いている企業・向いていない企業

向いている
  1. 3〜10店舗ほどで数百台の在庫を持ち、来店・電話・Webの問い合わせで「こんな車はないか」と聞かれることの多い中古車販売店。在庫管理の仕組みに車両の情報(支払総額、乗車定員、色、装備、修復歴など)がデータで入っているが、営業が条件を組み立てて探すのに時間がかかり、他店の在庫まで探せる営業が限られている場合。AWS を使える担当か委託先がいる場合。
向いていない
  1. 在庫が数十台で、営業が全台を覚えている場合。在庫の情報がデータになっておらず、紙の台帳や写真だけで管理している場合(先に在庫のデータを整えます)。お客様が自分で使うWebの検索の画面を作りたい場合(この構成は営業が使う前提で、要望の読み替えを営業が確かめます)。なお、どの車を勧めるか、価格の交渉、車両の状態の説明は、この構成では代替できません。在庫のデータから要望に近い車両を探して並べるまでです。

07最小構成で試す方法

  1. 先月の問い合わせのメモから30件を選ぶ(来店・電話・Webを混ぜる)
  2. 営業に、それぞれ最終的にどの車を提案したかを書き出してもらう
  3. 在庫の一覧を表計算に書き出し、色名の横に色の系統の列を足す
  4. 30件の要望を手元のAIサービスに貼り、「必ず守る条件と、できれば満たしたい条件に分け、推測で足した条件には印を付けてください」と指示する
  5. 出てきた条件で表計算を絞り込み、営業が提案した車が残るかを見る

30件は、当時の在庫の写しで試すのが理想です。 いまの在庫で試すと、当時提案した車がもう売れていて比べられないことがあります。在庫管理の仕組みに過去の日付の在庫を書き出す機能が無ければ、売約済みの車も含めて書き出し、当時あった車に印を付けて使います。

2番目の書き出しは必ず先に済ませてください。 営業が実際に提案した車が答えで、それと比べないと「当たった」の意味が決まりません。4番目では、色や装備を必ず守る条件にしていないか、書かれていない条件を足していないかを最優先で見ます。

出てきた内容判断
提案した車が絞り込みに残ったOpenSearch の索引に進む
色や装備を必ず守る条件にした指示の書き方で直る。構成は有効
在庫の装備の欄が空の車が多い在庫のデータの整備が先。 仕入れのときの入力を見直す

08実装時につまずきやすいポイント

問題対策
候補が0件になる色・装備は should に置く。 must にするのはお客様が「必ず」と言ったものだけ
予算を超えた車が上に来る予算は filter の range。超える車は別に探して別の欄に出す
「白」でパールの車が漏れる色名から色の系統を引いて color_family に入れる
装備の言い方で漏れる同義語の表を検索の側(synonym_graph)に置く
同義語を索引の側に置いて位置がずれたsynonym_graph は検索の分析器だけで使う。索引の側なら synonym
支払総額が空の車が消える印を付けて台数を画面に出す
売れた車を提案した販売の状態は探すたびに照会する
読み替えをお客様に確かめないinferred の条件を色を変えて出し、ask を必ず出す

上の2行が、この構成の失敗のほとんどです。 どちらも「どの条件で絞り、どの条件で並べるか」を間違えた形です。索引を作ったら、色と装備を外れた条件にした要望で、候補が0件にならないことを必ず確かめてください。

下の2行も、早いうちに効いてきます。 売れた車の提案は、お客様の信頼をいちばん早く失います。読み替えの確かめを省くと、お客様が望んでいない車ばかり並びます。

同義語の表と色の系統の表は、作って終わりではありません。 新しい色名や装備の言い方は毎月出てきます。「未分類」の色と、装備で0件になった検索の言葉を毎月一覧にして、表に足す作業を決まった担当の仕事にします。

09セキュリティ・AIガバナンス上の注意点

この構成で扱うデータ: お客様の要望(予算、家族の人数、用途)、在庫の車両の情報、販売の状態です。要望の中には、家族の構成や暮らしの様子が書かれることがあります。

  1. 要望の文から個人の情報を外す … お客様の名前、電話番号、住所の番地は、Claude に渡す前に伏せます
  2. 要望を推し量って広げない … 言葉づかいから年齢や収入を推し量る読み替えをさせません。提案の幅を営業の判断の外で狭めないためです
  3. 価格の表示の決まりを守る … 候補の一覧の価格は支払総額と内訳で出し、支払総額に含まれない費用があることも一覧に書きます
  4. 修復歴と保証を必ず出す … 候補の一覧で、修復歴・保証の有無・点検整備の有無を省きません
  5. 勧める車を決めるのは営業 … この構成は要望に近い車を並べるだけです
  6. 記録を見られる人を絞る … 要望と候補の記録には、お客様の暮らしの様子がにじみます。見られる人を営業と店長に限り、保存の期間を決めて消します

誤りが起きた場合のリスクは、お客様の望んでいない条件で絞り込み、合う車を見落とすこと、または予算を超えた車を予算内のように示すことです。 must と want の分け方、読み替えの確かめ、支払総額の扱いの3つで防ぎます。

10まず何から始めるか

1週目:在庫のデータを見る

在庫管理の仕組みから全車両を書き出し、装備の欄と色名、支払総額の空の車の数を見ます。色名の一覧を作り、色の系統の表の下書きを作ります。

2週目:30件で試す

第8章のとおり、30件の要望で、営業が提案した車が絞り込みに残るかを見ます。

3週目:装備の同義語の表を作る

営業から装備の言い方を集め、同義語の組にします。表の手入れをする担当を決めます。 あわせて、must と want の分け方を営業の会議で決めます。「お客様が『必ず』と言ったものだけ must」という決まりを、全員が同じ意味で使えるようにします。

4週目:索引を作る

OpenSearch に車両の索引を作り、営業が must と want を画面で選んで探せるようにします。この時点では要望の文の読み替えは使いません。

2か月目: 要望の文の読み替えと、販売の状態の照会を足します。3か月目以降: 営業が読み替えを直した件数と、候補が0件だった件数を毎月数え、1件8分が何分になったかを実測します。0件の検索が月に数件まで減った時点で、この構成は完成です。


11関連ユースケース

12この仕組みを理解するための記事

13技術仕様の確認日・参考情報

技術仕様確認日:2026-10-15/最終更新:2026-10-23
確認した内容情報源確認日
中古車の販売価格を2023年10月1日から「支払総額」の名称で表示し、内訳として「車両価格」と「諸費用」を表示すること。諸費用が保険料・税金(法定費用を含む)・登録等に伴う費用であること。支払総額は登録の時期や地域などに条件を付けた価格である旨を表示すること。管轄外登録(届出)費用・納車費用などが支払総額に含まれない諸費用の例であること。定期点検整備の有無と保証の有無を明瞭に表示すること自動車公正取引協議会: 中古車の価格は「支払総額」に変わります(パンフレット)2026-10-15
synonym_graph は検索の分析器だけで使い、索引のときに使うと複数の語からなる同義語の後ろの語の位置がずれること。索引のときに同義語を効かせるには synonym を使うこと。synonyms で組を直接書けることOpenSearch: Synonym graph token filter2026-10-15
synonym のフィルタの synonyms・expand の扱い(同じ意味の組を互いに広げること)OpenSearch: Synonym token filter2026-10-15
range で gte・gt・lte・lt を使って範囲を指定できることOpenSearch: Range query2026-10-15
Converse API の outputConfig.textFormat で JSON スキーマに沿った出力が得られ、enum が使えること。数値の minimum・maximum などの制約に対応していないことAWS: Structured outputs(Amazon Bedrock)2026-10-15

どの車を勧めるか、価格の説明と交渉は、営業がお客様と話して行ってください。 本記事は上記の公式ページで確認できた範囲だけを扱っています。

実装ステータス:構成例。 公開仕様に基づいて設計した構成であり、当社で実際に構築・検証したものではありません。工数の数値はモデル条件による試算です。

自社の業務に使えるAI活用候補を整理します

このユースケース(UC-1716)についてのご相談はこちらから。

AI活用について相談する
目次