タイヤ・ホイールの通販会社が、車種・年式・型式の問い合わせから適合の記録を OpenSearch で引き、候補と取付けの注意点を返す

処理の起点を決める

起点は2つあります。毎日の適合の表と商品の取り込みと、問い合わせの到着です。

取り込みは、適合の表と商品の管理の仕組みから前日に変わった行を書き出して索引を更新します。確かめた記録が増えたら、翌日には候補に出るようにします。 在庫と価格は変わりやすいので、下書きの直前に照会し、索引の値は使いません。

問い合わせは、「適合の確認」の分類で入ったものを起点に、1件ごとに動かします。モールの「適合を確認する」から来たものは、付いてくる商品の番号をそのまま使います。 分類の無い自由記述は、担当者が分類を付けてから動かします。

入力データを集める

質を決めるのは、確かめた記録の列です。 純正と違うサイズを候補に出せるかは、取付け店の報告がどれだけ入っているかで決まります。

注意点の表は、ベテランが回答に書き添えてきた一文を集めたものです。ここが、答えが担当者で違うことの直し方です。

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

型式とタイヤサイズの書き方のゆれは、normalizer でそろえます。 OpenSearch の公式のドキュメントでは、normalizer は1つのトークンだけを出すもので、keyword の一致の検索に使え、pattern_replace・icu_normalizer・uppercase などを使えますが、同義語の置き換えはできないとされています。型式は先頭の排出ガスの記号を外し、タイヤサイズは「225/45ZR17」「２２５／４５Ｒ１７」を「225/45R17」と同じ形にします。

純正サイズの組を nested にするのが、この構成でいちばん大事なところです。 ふつうのオブジェクトの配列だと、「前：225/45R17」「後ろ：255/40R17」の値が配列ごとにまとめて入り、「後ろで225/45R17」という存在しない組にも一致します。

PUT /vehicles
{
  "settings": { "analysis": {
    "char_filter": {
      "strip_prefix": { "type": "pattern_replace",
                        "pattern": "^[A-Za-z0-9]{2,4}-", "replacement": "" },
      "tire_norm":    { "type": "pattern_replace",
                        "pattern": "[\\s　]|Z(?=R)", "replacement": "" } },
    "normalizer": {
      "model_norm": { "type": "custom", "char_filter": ["icu_normalizer", "strip_prefix"],
                      "filter": ["uppercase"] },
      "size_norm":  { "type": "custom", "char_filter": ["icu_normalizer", "tire_norm"],
                      "filter": ["uppercase"] } },
    "analyzer": {
      "ja": { "type": "custom", "char_filter": ["icu_normalizer"],
              "tokenizer": "kuromoji_tokenizer" } } } },
  "mappings": { "properties": {
    "car_name":   { "type": "text", "analyzer": "ja" },
    "model_code": { "type": "keyword", "normalizer": "model_norm" },
    "year_from":  { "type": "integer" },
    "year_to":    { "type": "integer" },
    "oem_sets":   { "type": "nested", "properties": {
        "grade": { "type": "keyword" }, "position": { "type": "keyword" },
        "tire_size": { "type": "keyword", "normalizer": "size_norm" },
        "load_index": { "type": "integer" }, "inset": { "type": "integer" },
        "pcd": { "type": "float" }, "holes": { "type": "integer" },
        "hub_bore": { "type": "float" }, "seat": { "type": "keyword" } } },
    "verified_sets": { "type": "nested", "properties": {
        "position": { "type": "keyword" },
        "tire_size": { "type": "keyword", "normalizer": "size_norm" },
        "inset": { "type": "integer" }, "note": { "type": "text", "analyzer": "ja" } } } } }
}

検索は bool で組み立てます。 OpenSearch の公式のドキュメントでは、filter は点数に関わらない絞り込みで、should は一致するほど点数を上げ、must か filter があるときの minimum_should_match の既定は0とされています。年式は filter で絞り、型式とグレードは should で上に並べるので、型式の無い問い合わせでも候補が残ります。 nested には inner_hits を付け、一致した組だけを規則に渡します。

AIへ渡す前に整形する

1. 年式を西暦にする … 「H30.1〜R3.5」を2018〜2021にし、月は別の項目に残します
2. 前後の書き方をそろえる … 「F」「フロント」を front、「R」「リア」を rear、前後同じは both にします
3. タイヤサイズを分ける … 「225/45R17 94W XL」を、サイズ・荷重指数・速度記号・XL などの規格の表示に分けて持ちます
4. 空の値を空のまま持つ … ハブ径や座面の形が表に無い行は、値を入れずに残します
5. 問い合わせから個人の情報を外す … 名前、住所、電話番号、車のナンバーは、Claude に渡す前に伏せます

4番目で、空のハブ径に一般的な値を入れないでください。 空なら規則が「記録なし」と出して担当者に回します。埋めると、ハブリングの案内が抜けた回答が「確かめた」顔で出ていきます。 3番目で荷重指数を分けるのは、「純正より小さいものは外す」という自社の決まりを数値で当てるためです。

AIに処理させる

AIの仕事は2つです。 問い合わせを探す条件に読み替えることと、規則で照らした候補と注意点を記録のまま並べて回答の下書きを書くことです。

「計算で入ると言わない」が、この構成でいちばん大事な線です。 外径やインセットの差は数字で出せても、フェンダーやブレーキのキャリパーとの当たりは車ごとに違います。 呼び方を型式に読み替えさせないのも同じで、「80系」には複数の型式があり、読み替えると聞き返すきっかけが消えます。

指示内容を固定する

1回目（問い合わせの読み替え）の指示です。

あなたはタイヤ・ホイールの通信販売の会社で、お客様からの適合の問い合わせを整理する立場です。
【問い合わせ】から、車両の適合の表と商品を探すための条件を取り出してください。

【取り出すもの】
- car_name / maker: 車名・メーカー。書かれたまま
- model_code: 型式。車検証の型式のように書かれている場合だけ。書かれたまま
- nickname: 「30系」「80系」のような呼び方。書かれたまま
- year_raw: 年式。書かれたまま（「H30」「2018年式」など）
- grade: グレード。書かれたまま
- wanted: 希望のタイヤサイズ・ホイールの寸法・インチ数・商品の番号。書かれたまま
- current: いま付いているタイヤ・ホイールの表示が書かれていれば、書かれたまま
- missing: 書かれていない項目の名前

【厳守事項】
- 書かれていない型式・グレードを、車名や呼び方から補わないでください。
- 呼び方（〇〇系）を型式に置き換えないでください。
- タイヤサイズの数字を直したり、別のサイズに言い換えたりしないでください。
- 「付くか」の判断をしないでください。条件を取り出すだけです。
- お客様の名前・住所・電話番号・車のナンバーは写さないでください。

【問い合わせ】{inquiry_text}

2回目（回答の下書き）の指示です。

あなたはタイヤ・ホイールの通信販売の会社で、適合の問い合わせへの回答の下書きを作る立場です。
【候補】は車両の適合の表と商品の記録、規則で照らした結果（fit_basis）と、規則が拾った注意点です。

【書き方】
- 候補ごとに、商品名・サイズ・寸法を記録のまま書いてください。
- fit_basis が same_as_oem なら「純正と同じサイズです」、verified なら
  「取付けを確認した記録があるサイズです」と書いてください。
- fit_basis が not_recorded の候補は、下書きに書かず、担当者への申し送りに入れてください。
- 注意点は【注意点】にあるものだけを、お客様に分かる言葉で書いてください。
- 聞き返す項目があれば、最後にまとめて書いてください。

【厳守事項】
- 「付きます」「問題ありません」「車検に通ります」と書かないでください。
- 外径やインセットの差から、入るかどうかを推し量って書かないでください。
- 記録に無い寸法・注意点を書かないでください。
- 値引き・在庫の確約・納期の約束を書かないでください。

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

「not_recorded は下書きに書かない」を明記しないと、AIは候補をすべて並べ、お客様はそれを「付くもの」と読みます。 また「付きます」を禁じても「お取付けいただけます」と言い換えるので、禁じた言い回しを Lambda で調べ、見つかれば作り直します。

出力形式を固定する

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

{
  "inquiry_no": "",
  "vehicle": { "car_name": "", "model_code": "", "year": "", "grade": "",
               "grade_status": "given | ask_back" },
  "candidates": [
    { "item_no": "",
      "fit_basis": "same_as_oem | verified | not_recorded",
      "position": "front | rear | both",
      "listed": { "tire_size": "", "load_index": "", "rim": "", "inset": "", "pcd_holes": "" },
      "cautions": [""] }
  ],
  "ask_back": [""],
  "handover": [""],
  "draft": ""
}

AWS の公式ページでは、enum が使え、すべての object に additionalProperties: false が要り、数値の minimum・maximum には対応していません。 新しいスキーマは初回の組み立てに最大で約90秒かかり、24時間キャッシュされるので、朝に1回呼んでおきます。 fit_basis と position は規則の結果を写させ、AIには決めさせません。

構造化出力にする理由は、listed を商品の記録と Lambda で照合でき、違えば作り直せることです。 grade_status が ask_back なら、回答は聞き返しを先にします。

システムへ連携する

下書きは内部のメモに返し、お客様には送りません。

人が確認する

1. 車両の特定を見る … 型式・年式・グレードが問い合わせのとおりに取り出され、正しい車両の行が引かれているかを確かめます
2. 前後の組を見る … 前後で違うサイズの車では、候補の position が前と後ろで正しく分かれているかを確かめます
3. 申し送りの候補を判断する … not_recorded の候補を回答に入れるかは、担当者が商品部と相談して決めます
4. 注意点を確かめ、下書きを直して回答する … 在庫と価格の案内は担当者が書き足します

3番目を担当者だけで決めないでください。 一度「付く」と答えたサイズは、次から確かめた記録のように扱われがちです。記録に足すのは、取付け店の報告を受けた商品部です。

例外に対処する

記録を残す

• 問い合わせごとの、問い合わせの文（個人の情報を伏せたもの）、1回目の JSON、担当者が直した箇所
• 引いた車両の行と組、規則の照らし合わせの結果、拾った注意点
• 2回目の JSON、禁じた言い回しの検査の結果、担当者が直した箇所
• 回答した商品と、その後の返品の有無と理由、取付け店からの報告

same_as_oem なのに返品になった組が続くなら、年の途中の変更が表に入っていません。 商品部に行を分けてもらいます。