小売店のスタッフが客から聞かれたあいまいな言葉で、商品の説明・売場の場所・過去の問い合わせ記録を探し、根拠付きで答える

処理の起点を決める

取り込みと検索で、起点が2つあります。

取り込みは毎晩です。 商品マスタの新規・廃番・説明文の変更、棚割の変更、前日の問い合わせ記録を読み込みます。棚替えは閉店後に行われることが多く、翌朝の開店までに新しい棚が引ければ足ります。

言い換え辞書の更新は月に1回です。 毎晩足すと、誤った言い換えが翌日には全店に広がります。月に1回、本部が候補をまとめて見て、採用したものだけを足します。

検索は、スタッフが端末に言葉を入れて送ったときに動きます。 客の前に立ったまま使うので、送ってから数秒で返ることを目標にします。 Claude の呼び出しが遅れたときは、検索の結果だけを先に表示します（例外処理）。

入力データを集める

質を決めるのは、商品の説明文です。 意味の近さで探すとき、比べる相手は説明文です。説明文が空の商品は、品名の略称だけで比べることになり、客の言葉には届きません。 取り込みのときに、説明文が空の商品の数を部門ごとに数えます。

問い合わせ記録は、導入前のノートも取り込みます。 店ごとに書き方は違いますが、「客の言葉」と「最後の商品」の2つが拾えれば使えます。

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

商品マスタ、棚割、在庫は、既存の仕組みから毎晩の書き出しを受け取ります。在庫だけは、検索のたびにその店のその商品の数を引き直します。 夜の在庫数では、昼に売り切れた商品を「在庫あり」と答えることになるためです。

索引は2つに分けます。

棚割と在庫は索引に入れません。 店ごとに違い、日々変わるからです。検索で商品が決まってから、その店の通路と在庫を Lambda が引いて付けます。 商品の索引を全店で1つにできるので、30店舗の説明文のベクトルを店の数だけ作らずに済みます。

説明文のベクトルは、取り込みのときに作ります。 公式の手順では、取り込みのパイプラインに text_embedding の処理を置き、指定した項目の文章からベクトルを作って別の項目に入れます。 埋め込みのモデルは、Amazon Bedrock の Cohere Embed を ML Commons のコネクタでつなぎます。公式のチュートリアルでは、多言語が要る場合は cohere.embed-multilingual-v3 を使えるとされています。コネクタは、Bedrock を呼ぶための権限（IAM のロール）を持たせて作ります。

問い合わせの索引は、商品の索引と同じ客の言葉で別に引きます。 当たった記録を解決した商品のJANコードごとにまとめ、件数の多い順に3件までを候補の材料にします。「見つからなかった」の記録は候補にしませんが、同じ言葉で何度も見つからなかったことは、答えに添えます。 スタッフは、その質問が店で答えられていない種類だと分かります。

AIへ渡す前に整形する

1. 品名の半角カナをそろえる … kuromoji の解析は、最初に cjk_width の文字の処理で半角カナを全角カナに、全角英数を半角に変えます。品名の略称は、この処理で客の言葉と同じ文字になります
2. 長音の揺れをそろえる … kuromoji の解析は、4文字以上のカタカナの語の末尾の長音（ー）を取ります（「ドライバー」と「ドライバ」が同じになる）
3. 説明文が空の商品に印を付ける … 部門ごとの件数を本部に返します
4. 廃番を外す … discontinued の商品は検索の絞り込みで外します。在庫が残っている店のために、索引からは消しません
5. 問い合わせ記録の個人の情報を外す … 取り寄せの記録に書かれた客の名前や電話番号は、取り込みで消します
6. 辞書の候補を作る … 毎月、「見つからなかった」の記録と、解決したが辞書に当たらなかった記録を集めます

1番目と2番目は、自分で処理を書かなくても kuromoji の解析の中で行われます。 公式のドキュメントでは、kuromoji の解析は cjk_width、辞書による分割、活用形を基本形に戻す処理、助詞などの除去、長音の除去、英字の小文字化をこの順に行うとされています。

AIに処理させる

AIの仕事は、検索で出た商品と問い合わせ記録を読んで、候補を3件に絞り、根拠と聞き返しを書くことだけです。 商品を探すのは検索基盤で、売場と在庫を付けるのは Lambda です。

3行目が、いちばん起きやすい失敗です。 問い合わせ記録に「3番通路にあった」と書かれていると、AIはそれを写します。棚替えの後では、その通路に商品はありません。 売場の場所は、AIの文章の外で、その日の棚割から付けます。

2行目も外せません。 ドラッグストアの売場で「喉が痛いときの」と聞かれたとき、効き目の説明を端末の答えから読み上げることは、資格者の相談の代わりになりません。 該当する部門の商品なら、答えに「薬剤師・登録販売者へ」と必ず添えます。

指示内容を固定する

あなたはホームセンターの売場で、スタッフが客の質問に答えるのを手伝う係です。
渡された検索結果だけを根拠にしてください。一般的な商品の知識で補わないでください。

【客の言葉】{asked_text}
【検索結果】
products：商品の候補（品名、規格、部門、説明文）
inquiries：過去に似た言葉で聞かれ、解決した商品の記録

【書くこと】
1. 候補を3件まで。JANコード、品名、なぜ候補か（説明文の一節か、問い合わせ記録の番号）
2. 候補を分けるための聞き返しを1文だけ
3. 合う商品が無いときは「候補なし」と書き、近い部門を1つ

【厳守事項】
- 検索結果に無い商品を書かないでください。
- 売場の場所（通路・棚）、在庫、値段を書かないでください。別の仕組みが付けます。
- 問い合わせ記録に書かれた通路や棚を写さないでください。
- 効き目、安全性、使ってよいかの判断を書かないでください。
  医薬品・医療機器・農薬・電気工事に関わる候補には「資格者に確認」と添えてください。
- 端末の画面は小さいので、1件を40文字以内でまとめてください。

「問い合わせ記録の通路や棚を写さない」を明記しないと、AIは親切に場所を書きます。 根拠として渡した記録の中に場所が書かれているためで、禁じないと、検索結果の中のいちばん具体的な情報として前に出てきます。

検索結果は、Claude の検索結果ブロックで渡します。 商品1つ、問い合わせ記録1件をそれぞれ1つの search_result にし、source にJANコードか記録の番号を入れます。答えの候補が、どの商品と記録から来たかを端末で辿れます。

出力形式を固定する

商品の検索は、次のように組みます。

GET /products/_search?search_pipeline=store-hybrid
{
  "size": 20,
  "_source": { "exclude": ["description_vec"] },
  "query": {
    "hybrid": {
      "filter": { "term": { "discontinued": false } },
      "queries": [
        { "multi_match": { "query": "壁の穴をふさぐやつ",
            "fields": ["name_full", "name_kana", "description"] } },
        { "neural": { "description_vec": {
            "query_text": "壁の穴をふさぐやつ", "model_id": "<model_id>", "k": 20 } } }
      ]
    }
  }
}

store-hybrid は、点数の正規化の処理を持つ検索パイプラインです。 公式のドキュメントでは、重みを省くと2つの検索が同じ重さになり、片方の検索にしか出なかった商品は、もう片方の点数が0として平均されるため、点数が半分になります。 品名に当たらず説明文の意味でしか拾えない商品が下がりすぎるときは、weights で意味の側を重くします。重みは足して1.0にする必要があります。

索引の解析は組み込みの kuromoji のままにし、言い換え辞書は検索のときだけ効く解析に置きます。

"analysis": {
  "filter": { "store_synonyms": { "type": "synonym_graph",
      "synonyms_path": "analyzers/F111111111", "updateable": true } },
  "analyzer": { "ja_search": { "type": "custom",
      "tokenizer": "kuromoji_tokenizer",
      "filter": ["cjk_width", "kuromoji_baseform", "kuromoji_stemmer",
                 "store_synonyms", "lowercase"] } }
}

updateable: true は検索の解析にだけ使えます。 AWS の公式の説明では、辞書のファイルをパッケージとして S3 から取り込んで更新し、検索の解析だけで updateable を有効にしていれば、索引の更新は自動で行われるとされています。毎月の辞書の更新で索引を作り直さずに済みます。

端末に返す形は、次のJSONです。

{
  "asked_text": "壁の穴をふさぐやつ",
  "candidates": [
    { "jan": "4900000000000", "name": "", "reason": "説明文：石膏ボードの小さな穴を埋める",
      "source": "product", "aisle": "12", "shelf": "B", "level": 3, "stock": 8 },
    { "jan": "4900000000001", "name": "", "reason": "問い合わせ記録 Q-2026-0412-03",
      "source": "inquiry", "aisle": "12", "shelf": "C", "level": 2, "stock": 0,
      "orderable": true }
  ],
  "ask_back": "穴の大きさは、指より小さいですか、大きいですか",
  "needs_qualified": false,
  "no_match": false
}

1つ目の理由は、aisle・shelf・level・stock をAIの文章と別の項目にできることです。 場所と在庫はその日の値を Lambda が入れ、AIの文章に紛れ込みません。

2つ目は、source で根拠の種類を見せられることです。 説明文から来た候補と、過去に同じ言葉で解決した記録から来た候補では、スタッフが客に勧めるときの確かさが違います。

3つ目は、needs_qualified で資格者への引き継ぎを画面の色で出せることです。

システムへ連携する

人が確認する

この構成の確認は、条件付きです。 売場の案内は、スタッフが商品を手に取って客に見せるところで確かめられます。候補が外れていても、客がその場で違うと言えば済みます。

1. 聞き返しを客にする … 候補が複数あるとき、画面の1文で客に聞きます
2. 商品を手に取って見せる … 棚で実物を確かめ、客に見せます
3. needs_qualified の候補は資格者へ … 医薬品などは、薬剤師・登録販売者に引き継ぎます
4. 解決したかを押す … 解決した商品か「見つからなかった」を押します

4番目を省かないでください。 この1回が、次のスタッフの検索の根拠と、毎月の辞書の候補になります。押されなかった質問は、解決したのかどうかが分かりません。 押された割合を店ごとに見て、低い店には使い方を伝え直します。

1件あたり2分を目安にします。 画面を読んで聞き返しをするのに数十秒、棚で実物を確かめて解決を押すのに残りの時間です。

本部は毎月、辞書の候補を確かめます。 「見つからなかった」が多い言葉と、解決したが辞書に当たらなかった言葉を並べ、採用する言い換えを決めます。 1つの言い換えが全店に効くので、ここは必ず人が決めます。

例外に対処する

5行目で検索結果をそのまま出すのは、客の前で待たせないためです。 AIの整理が無くても、候補と売場は出ます。

記録を残す

• 客の言葉、検索の結果、Claude の答え、返した場所と在庫
• スタッフが押した解決の結果（解決した商品、または見つからなかった）
• 辞書の候補と、本部が採用・不採用にした記録
• 店ごと・部門ごとの「見つからなかった」の件数

2つ目は、商品の説明文を直す材料にもなります。 同じ商品がいつも問い合わせ記録の側からしか拾われないなら、その商品の説明文に客の言葉が入っていないということです。

最後の行は、品揃えの見直しの材料になります。 同じ言葉で「見つからなかった」が続くなら、探し方の問題ではなく、その店に置いていない商品を客が求めているということかもしれません。月に1回、部門の担当に返します。