古着のリユース店の本部が、客の「90年代っぽい、ゆったりめ、緑系」のような言い方から全店の在庫を探し、取り置きと店間の移動の候補を返す

処理の起点を決める

起点は2つあります。1時間ごとの在庫の取り込みと、担当者の検索のボタンです。

在庫の取り込みは、在庫の管理の仕組みから入荷・売約・移動が変わった在庫を書き出し、索引を更新します。古着は1点ものなので、売れた服が候補に出続けると、そのまま「あります」と答えてしまいます。 1時間の間に売れた服に備えて、回答の前に販売の状態だけは在庫の管理の仕組みに照会します。

取り込みのたびに、説明文の変わっていない在庫までベクトルを作り直さないようにします。 OpenSearch の公式のドキュメントでは、text_embedding の処理に skip_existing の設定があり、true にすると、同じ ID の文書の入力の文が変わっておらずベクトルが既にあれば、モデルを呼ばずに既存のベクトルを写すとされています。ドメインの版でこの設定が使えるかを確かめ、使えなければ Lambda の側で説明文の変わった在庫だけを送ります。

検索のボタンは、本部の担当か店舗のスタッフが客の言い方を貼った後に押します。店舗のスタッフが直接使えるようにすれば、本部に回す前に全店を探せます。

入力データを集める

質を決めるのは、説明文です。 雰囲気の近さで探せるのは、説明文に雰囲気が書かれている服だけです。「Tシャツ 黒 L」としか書かれていない服は、雰囲気の検索では上に来ません。 入荷の登録で、素材の感じ・シルエット・色の出方を一言書く決まりを作ることが、この構成の土台です。

客の名前と連絡先は、生成AIに渡しません。 取り置きのための連絡先は、店舗の顧客の台帳で持ちます。

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

2つの探し方は、hybrid の問い合わせでまとめます。 OpenSearch の公式のドキュメントでは、hybrid の問い合わせは複数の問い合わせの点数を1つにまとめるもので、句は最大5つ、文書はどれか1つの句に合えば結果に入り、点数は検索のパイプラインでまとめられます。filter はすべての句にかかり、1つの問い合わせの形で渡す必要があるので、複数の条件は bool にまとめます。

点数のまとめ方は、normalization の処理で決めます。 公式のドキュメントでは、語の検索とベクトルの検索は点数の尺度が違うため、normalization-processor が句ごとに点数をそろえてからまとめます。min_max は句ごとに0〜1にそろえ、arithmetic_mean は weights で句ごとの重みを付けられます。注意が要るのは、片方の句にしか出てこなかった服は、もう片方の点数が0として平均に入り、点数が半分になることです。

PUT /_search/pipeline/clothing-hybrid
{ "phase_results_processors": [ { "normalization-processor": {
    "normalization": { "technique": "min_max" },
    "combination": { "technique": "arithmetic_mean",
                     "parameters": { "weights": [0.4, 0.6] } } } } ] }

GET /stock/_search?search_pipeline=clothing-hybrid
{ "query": { "hybrid": {
    "filter": { "bool": { "filter": [
      { "term":  { "stage": "available" } },
      { "term":  { "item": "open_collar_shirt" } },
      { "terms": { "color_group": ["green"] } },
      { "range": { "chest_cm": { "gte": 58, "lte": 66 } } } ] } },
    "queries": [
      { "bool": { "should": [
          { "match": { "description": "70s 柄 レーヨン" } } ] } },
      { "neural": { "description_vector": {
          "query_text": "70年代風の総柄で、ゆったりした落ち感のある開襟シャツ",
          "model_id": "{model_id}", "k": 50 } } } ] } } }

重みは、雰囲気の句を少し重くしています。 雰囲気の言葉で探すことがこの業務の目的だからです。ただし、重みは最初から決め打ちせず、第8章の30件で語の句だけ・雰囲気の句だけ・両方の順位を比べてから決めます。

AIへ渡す前に整形する

1. ブランドの表記をそろえる … ブランドの表記の表で、在庫の登録のブランドをそろえた名前にします
2. 色を色の群にする … 在庫の色を色の系統の表で群（green、blue など）にし、1点に複数の群を持たせてよいことにします
3. 実寸を数値の項目にする … 着丈・身幅・肩幅・袖丈、ウエスト・股下・わたりを、それぞれ数値の項目にします。測っていない項目は入れません
4. 説明文のベクトルを作る … 取り込みのパイプラインの text_embedding で、説明文から description_vector を作ります
5. 問い合わせから個人の情報を外す … 客の名前・電話番号・メッセージのアカウント名は、Claude に渡す前に伏せます

3番目で、測っていない実寸に0や表記サイズからの推定値を入れないでください。 入れると、range の絞り込みで外れるか、合わない服が残ります。実寸の無い服は絞り込みで外れるので、件数が少ないときだけ実寸の条件を外した検索をもう一度行い、「実寸の記録なし」と印を付けて出します。

AIに処理させる

AIの仕事は2つです。 客の言い方を条件と雰囲気の文に読み替えることと、規則で照らした候補を在庫の記録のまま並べることです。

「年代を言い切らない」「本物かどうかに触れない」が、この構成でいちばん大事な線です。 年代の見立ては、タグの形や縫製から店のスタッフが判断したもので、客に「90年代の本物です」と伝われば、それは店の保証になります。 AIの下書きがその言い方をすれば、確かめた人がいないまま店の約束が生まれます。

指示内容を固定する

1回目（言い方の読み替え）の指示です。

あなたは古着のリユース店の本部で、客からの在庫の問い合わせを整理する立場です。
【問い合わせ】から、在庫を探すための条件を取り出してください。

【取り出すもの】
- brand / item / era_words（年代の言い方。書かれたまま）
- color_words: 色の言い方。書かれたまま（「緑系」「くすんだ青」など）
- size_words: サイズの言い方。書かれたまま（「W32くらい」「ゆったりめ」など）
- mood_query: 雰囲気の言葉を、古着の説明文に近い書き方の1文にまとめたもの
- must: 客が「絶対」「でないとだめ」と言った条件の名前

【厳守事項】
- サイズの言い方を cm やインチの数値に直さないでください。書かれたまま写してください。
- 色の言い方を特定の色の名前に決めないでください。
- 問い合わせに書かれていない希望（ブランド・価格・年代）を足さないでください。
- mood_query には、問い合わせに無い年代やブランドを入れないでください。
- 客の年齢・性別・好みの理由を推し量って書かないでください。

【問い合わせ】{inquiry_text}

2回目（候補の並べ方）の指示です。

あなたは古着のリユース店の本部で、全店の在庫の候補を担当者に示す立場です。
【候補】は在庫の記録と、条件との照らし合わせと、取り置き・移動の候補です。

【書き方】
- 候補ごとに、管理番号・店舗・ブランド・アイテム・色・表記サイズ・実寸・状態のランク・価格を、
  在庫の記録のまま書いてください。
- 年代は「スタッフの見立て：70s」のように書いてください。
- 外れた条件（色の群が違う、実寸が幅の外、実寸の記録なし）をはっきり書いてください。
- 取り置き・移動の候補は、規則の結果のまま書いてください。

【厳守事項】
- 「90年代のものです」「本物です」「ヴィンテージとして価値があります」と書かないでください。
- 在庫の記録に無い実寸・状態・素材を書かないでください。
- 状態を「きれい」「美品」などと評価しないでください。
- 移動の日数や取り置きの期限を、規則の結果に無いのに約束しないでください。

【問い合わせの条件】{conditions}
【候補】{candidates}

「サイズの言い方を数値に直さない」を明記しないと、AIは「W32」をウエスト81cmと書きます。 ヴィンテージのジーンズはタグと実寸が違うことが多く、その換算は本部の表で決めるべきものです。AIが決めた数値で絞ると、表で決めた幅と食い違い、同じ問い合わせで結果が変わります。

出力形式を固定する

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

{
  "inquiry_no": "",
  "candidates": [
    { "stock_no": "",
      "store": "",
      "listed": { "brand": "", "item": "", "color": "", "tag_size": "",
                  "measurements": "", "grade": "", "price": "" },
      "era_by_staff": "",
      "unmatched": ["color_group | measurement_out | measurement_missing"],
      "action": "hold_at_store | transfer_to_store | visit_suggested" }
  ],
  "summary_for_staff": ""
}

AWS の公式ページでは、outputConfig.textFormat に JSON スキーマを渡すと応答がスキーマに沿い、enum が使えます。すべての object に additionalProperties: false が要り、数値の minimum・maximum には対応していません。unmatched と action は Lambda の規則の結果をそのまま渡して写させ、AIには決めさせません。

1つ目の理由は、listed を在庫の記録と照合できることです。 listed の値が記録と同じかを Lambda で確かめ、違えば一覧を出さずに作り直します。 記録に無い実寸を書いた一覧は、ここで止まります。

2つ目は、action で店長に回す依頼の形が決まることです。 取り置きと移動の依頼を、店舗・管理番号・理由の決まった形で店長に送れます。

システムへ連携する

検索のときの雰囲気の文のベクトルも、OpenSearch が同じモデルで作ります。 neural の問い合わせに model_id を渡すと、渡した文からベクトルを作って近い文書を探します。索引のときと検索のときで同じモデルを使うことが前提で、モデルを替えたら全在庫のベクトルを作り直します。

人が確認する

1. 読み替えを見る … サイズと色の言い方が書かれたまま取り出され、表で正しく幅と群になっているかを確かめます
2. 写真で確かめる … 候補の写真を開き、色の出方と雰囲気が客の言い方に合うかを見ます
3. 客に伝える … 年代は見立てとして伝え、本物かどうかの質問には店舗のスタッフが答えます
4. 店長の承認を得る … 取り置きと移動は、在庫のある店舗の店長に依頼し、承認を得てから客に約束します
5. 実寸の記録なしの候補は、店舗に測ってもらう … 客に勧める前に実寸を確かめます

4番目を省かないでください。 店長が知らないうちに店頭の1点が取り置かれると、その店で同じ服を見ていた別の客に売れなくなります。

例外に対処する

4行目の記録が、入荷の登録の決まりを直す材料になります。 雰囲気の句に出てこない服が多い店舗は、説明文の書き方が短いということです。

記録を残す

• 問い合わせごとの、言い方（個人の情報を伏せたもの）、1回目の JSON、表で読み替えた実寸の幅と色の群
• 検索の条件、hybrid の重み、候補と規則の結果、2回目の JSON と照合の結果
• 担当者が写真で外した候補と理由
• 取り置き・移動の依頼と、店長の承認の結果、客の購入の有無

担当者が写真で外した候補は、重みと説明文を見直す材料にします。 雰囲気の句で上に来たのに外された服が多いなら、重みが雰囲気の句に寄りすぎているか、説明文が実物と違っています。