ギフトの販売店が引き出物や内祝いの相談に、予算・用途・贈る相手から OpenSearch でカタログを引き、避けるべき品を除いた候補を出す

処理の起点を決める

取り込みは定時、検索は担当者が相談の内容を貼ったときに動きます。 商品の情報は毎晩、在庫は1時間ごとに更新します。在庫だけ間隔を短くするのは、引き出物のように数十個単位の相談では、昼のうちに在庫が足りなくなることがあるからです。

取り込みは、商品管理システムが書き出したCSVが S3 に置かれたことをきっかけに Lambda を動かします。商品の書き出しは全件、在庫は差分で取ります。 商品の廃番や価格の改定を差分で追うと、索引に古い情報が残ります。

検索は、担当者が相談の画面に聞き取りのメモかメールの本文を貼り、「候補を出す」を押したときに動きます。電話の相談は、担当者が聞き取りながら画面のメモ欄に打ちます。 通話の録音を文字にする部分はこの構成に入れません。

入力データを集める

質を決めるのは、2行目までの商品の記録のタグと、3行目と4行目の表です。 用途タグと避ける品のタグが付いていない商品は、絞り込みで正しく扱えません。新しい商品を登録するときに、タグを付ける欄を必須にします。

贈る相手の名前と住所は入力に入れません。 候補を出すのに要らないので、担当者がメモに書かないよう画面に注意を出し、貼られた本文からも電話番号とメールアドレスの形の文字列を消してから生成AIに渡します。

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

言い換え辞書は、OpenSearch Service のパッケージとして登録します。 テキストの辞書を S3 から取り込んでドメインに関連付け、analyzers/<パッケージID> を synonyms_path に指定します。検索用の分析器に updateable を付けておくと、季節の商品の入れ替えで辞書を足したときに、索引を作り直さずに反映されます。

在庫の差分は、商品番号で索引の文書を部分的に更新します。商品の全件の作り直しと在庫の更新が同じ時間に重ならないよう、全件の作り直しは新しい索引を作って別名を付け替える形にします。

AIへ渡す前に整形する

1. 相談の本文から個人の情報を消す … 電話番号、メールアドレス、郵便番号の形の文字列を消します。氏名は消し切れないので、画面で書かないよう案内します
2. 用途を店の区分に寄せる … 生成AIが取り出した用途を、店の区分（結婚内祝い、引き出物、出産内祝い、香典返し、快気祝い、法人記念品）の中から選ばせます
3. 予算を価格の幅に直す … 「5,000円くらい」は4,500円から5,500円のように、幅の取り方を店の取り決めとして Lambda に書きます
4. 頂いた額だけが分かっている場合 … 「3万円頂いた」は、お返しの目安の割合を担当者が確かめてから予算を入れ直します。自動で予算にしません
5. 届ける日を日数に直す … 届ける日から今日までの営業日を数え、発送までの日数の上限にします
6. 要望の言葉を条件に直す … 「日持ち」は賞味期限の日数が何日以上、「軽い」は重さが何g以下、のように要望の言葉の表で直します

4番目を自動にしないのは、お返しの割合に決まった答えが無いからです。 相手との関係や地域で変わり、お客さまが「半分くらい」と言っても、実際の予算は別の事情で決まることがあります。 頂いた額から予算を計算して検索すると、お客さまが考えていない価格帯の候補が並びます。

6番目で、表に無い言葉は条件にしません。 「おしゃれな」「喜ばれる」は数値に直せないので、説明文に対する言葉の検索にだけ使います。

AIに処理させる

させるのは2つです。相談の内容から条件を取り出すことと、見つかった商品の記録から理由を写すことです。

要望の言葉を、表の一覧から選ばせるのが要です。 構造化出力のスキーマで、要望の言葉を enum（決まった値の一覧）にします。一覧に無い言葉はスキーマの上で返せないので、AIが新しい条件を作ることがありません。 一覧に当たらない要望は other_requests に言葉のまま入れさせ、説明文の検索にだけ使います。

理由の写しでは、商品の記録の文字列をそのまま写させます。 「年配の方にも食べやすい」と書かれていれば、それを写します。写した文字列は Lambda で商品の記録と照らし、見つからなければその理由を消します。

指示内容を固定する

条件の取り出しの指示：

あなたはギフトの専門店の相談窓口で、お客さまの相談の内容から、
商品を探すための条件を取り出す担当です。

【取り出す項目】
- purpose：用途。次の区分から1つ選ぶ。
  wedding_return（結婚内祝い）／wedding_favor（引き出物）／
  birth_return（出産内祝い）／funeral_return（香典返し）／
  recovery_return（快気祝い）／corporate（法人記念品）／unknown
- budget_text：予算について話された言葉をそのまま
- received_amount_text：頂いた額について話された言葉をそのまま
- quantity：個数。分からなければ null
- delivery_text：届ける日・持ち帰りかについて話された言葉をそのまま
- recipient_text：贈る相手の様子について話された言葉をそのまま
- requests：要望の言葉を、決められた一覧から選ぶ
- other_requests：一覧に当たらない要望を、話された言葉のまま
- avoid_text：避けたいと言われたもの
- allergy_text：アレルギーについて話された言葉

【厳守事項】
- 頂いた額から予算を計算しないでください。
  received_amount_text に言葉のまま入れてください。
- 用途が相談の内容から分からなければ unknown にしてください。
  予算や相手の様子から推し量らないでください。
- 相談に出てこない条件を足さないでください。
- 贈り物としての作法や、避けるべき品についての意見を書かないでください。
- 相手の名前・住所・電話番号を出力に入れないでください。

【相談の内容】{consultation_text}

候補の理由の写しの指示：

あなたは相談窓口で、検索で見つかった商品の記録を読み、
相談の条件に当たる理由を写す担当です。

【相談の条件】{conditions_json}
【検索で見つかった商品の記録】{hits_json}

【やること】
1. 商品ごとに、相談の条件（相手の様子・要望・避けたいもの以外の希望）の
   どれに当たるかを見る
2. 当たった条件ごとに、記録のどの欄（name / description / tags）に
   何と書かれていたかを、記録の文字列のまま写す
3. 当たらなかった条件は not_found とする

【厳守事項】
- 記録に書かれていない特長を書かないでください。
- 写す文字列は記録の文字列のままにしてください。言い換えないでください。
- 価格・在庫・発送の日数・賞味期限は、こちらで添えるので書かないでください。
- 贈り物としてふさわしいか、のしをどうするかは書かないでください。

1つ目の「頂いた額から計算しない」を書かないと、半分の額を予算として返します。 その数字が正しいかどうかではなく、担当者が確かめていない予算で検索されることが問題です。

2つ目の「価格は書かない」は、ずれを防ぐためです。 価格は Lambda が記録から添えます。AIが写すと、改定前の価格や税抜きの価格を取り違えたときに見分けがつきません。

出力形式を固定する

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

{
  "purpose": "funeral_return",
  "budget_text": "",
  "received_amount_text": "1万円",
  "quantity": 30,
  "delivery_text": "四十九日の前の週に届くように",
  "recipient_text": "年配の方が多い",
  "requests": ["long_shelf_life", "individually_wrapped"],
  "other_requests": ["かさばらないもの"],
  "avoid_text": "",
  "allergy_text": "小麦がだめな方が1人いる"
}

requests の値は、要望の言葉の表と同じ一覧（long_shelf_life、lightweight、individually_wrapped、name_printing、for_elderly、for_families など）を enum にします。

検索は、この条件を Lambda が次の bool クエリに組み立てます。

避ける品を must_not に、価格や日数を filter に置くのは、点数に関わらせないためです。 どちらも当たるか当たらないかの条件で、filter と must_not は点数に加わらず、結果が使い回されて速くなります。 並び順は should の当たり具合だけで決まります。

filter があると、should は1つも当たらなくても候補に出ます。 相手の様子の言葉が説明文に1つも無くても、価格と用途が合う商品は並びます。候補が少なすぎることを防ぐための置き方です。

候補の一覧は、次の形で受け取ります。

{
  "candidates": [
    {
      "item_no": "",
      "reasons": [
        { "condition": "recipient | other_request",
          "status": "matched | not_found",
          "field": "name | description | tags",
          "quote": "" }
      ]
    }
  ]
}

Bedrock の構造化出力は数値の範囲や文字列の長さの制約に対応していません。 個数や予算の範囲の確かめは、Lambda の側で行います。

システムへ連携する

受注のシステムへは書き込みません。 候補はあくまで提案の材料で、お客さまが決めた品を登録するのは担当者です。

人が確認する

候補をそのままお客さまに送ることはしません。 担当者が次の順で確かめます。

1. 取り出した条件を見る … 用途の区分、予算、届ける日。用途が unknown なら、お客さまに聞き直します
2. 頂いた額が書かれていたら、予算を入れ直す … お返しの目安を担当者が確かめて、予算の欄に入れて引き直します
3. 除いた品の件数を見る … 避ける品の決まりで何点除かれたかが画面に出ます。0点なら用途の区分の取り違えを疑います
4. 候補の価格・在庫・日数を見る … 記録から添えた値で確かめます
5. 作法を添えて伝える … のしの表書き、贈る時期の目安、地域の習わしを、担当者の言葉で添えます

3番目を省かないでください。 香典返しの相談で除かれた件数が0なら、用途が別の区分になっています。避ける品が混ざった候補を出すのは、この構成でいちばん避けたい失敗です。

目標は1件6分です。 条件を確かめ、候補から3〜5点を選び、作法を添えて返事にするまでの時間です。

例外に対処する

下から2行目が大事です。 避ける品のタグが空の商品を候補に入れると、must_not で除かれずに出てきます。タグが付いていないことは「避けなくてよい」ことではないので、出さない側に倒します。

記録を残す

• 相談ごとの取り出した条件、直した価格の幅と日数、除いた品の件数とタグ
• 送った bool クエリと、返ってきた商品番号と点数
• 生成AIの出力の全文と、商品の記録と照らして消した理由
• 担当者が選んだ候補と、お客さまが決めた品
• 避ける品の決まりの表・要望の言葉の表・言い換え辞書の版

除いた品のタグを残すのは、後から「なぜこの品が出なかったか」を説明するためです。 お客さまから「あの商品は無いのか」と聞かれたときに、決まりで除いたのか、在庫が無かったのかを分けて答えられます。

一覧に当たらなかった要望の言葉は、毎月まとめて見ます。 繰り返し出てくる言葉は、要望の言葉の表に足す候補です。