中古建機の販売会社が、問い合わせの機種・年式・稼働時間・アタッチメントに合う在庫を、在庫の記述と整備記録から探して提案の候補を並べる

処理の起点を決める

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

夜間の取り込みは、全在庫の台帳と、新しく増えた作業報告を読みます。整備中の機械も入れ、状態の項目で分けます。 整備の完了が納期に間に合えば提案できるからです。

検索のボタンは、営業が問い合わせを貼った後に押します。昼の売約は夜まで索引に反映されないため、販売の状態だけは候補を出すたびに照会します。

入力データを集める

質を決めるのは、型式の対応表です。 台帳のバケット容量は書き方がばらばらで空欄もありますが、型式からクラスを引けば漏れません。 表に無い型式は「未分類」にして、営業に追加を頼みます。

整備記録の「指摘事項」（直していないが気になること）は、作業の内容と別の欄に分け、候補の一覧で必ず出す項目にします。

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

アタッチメントは nested で持ちます。 公式のドキュメントでは、配列の中の1つのオブジェクトの中で条件をそろえて探したいときに nested を使うとされ、通常のオブジェクトの配列は項目ごとに平らにされる、とあります。平らにすると「ブレーカーの配管」と「状態：要修理」が別のアタッチメントのものでも合ってしまいます。 nested は負荷が高いとされているので、使うのはアタッチメントだけにします。

在庫の索引の設定は次のようになります（一部の項目だけを示します）。

PUT /machines
{
  "mappings": { "properties": {
    "machine_no":   { "type": "keyword" },
    "yard":         { "type": "keyword" },
    "maker":        { "type": "keyword" },
    "model_code":   { "type": "keyword" },
    "machine_type": { "type": "keyword" },
    "class_m3":     { "type": "float" },
    "year":         { "type": "integer" },
    "hour_meter":   { "type": "integer" },
    "meter_replaced": { "type": "boolean" },
    "attachments":  { "type": "nested", "properties": {
        "kind":      { "type": "keyword" },
        "spec":      { "type": "keyword" },
        "condition": { "type": "keyword" } } },
    "stage":        { "type": "keyword" }
  } }
}

整備記録は別の索引にし、根拠を行の番号で示せるよう、作業報告を1行ずつの文書にします。

PUT /maint
{
  "settings": { "analysis": {
    "filter": { "part_syn": { "type": "synonym_graph", "synonyms": [
        "足回り, 下回り, アンダーキャリッジ",
        "旋回モーター, 旋回モータ",
        "アワーメーター, アワメータ, 稼働時間計" ] } },
    "analyzer": {
      "ja_index":  { "type": "custom", "tokenizer": "kuromoji_tokenizer",
                     "filter": ["cjk_width", "lowercase"] },
      "ja_search": { "type": "custom", "tokenizer": "kuromoji_tokenizer",
                     "filter": ["cjk_width", "lowercase", "part_syn"] } } } },
  "mappings": { "properties": {
    "report_no":  { "type": "keyword" },
    "line_no":    { "type": "integer" },
    "machine_no": { "type": "keyword" },
    "work_date":  { "type": "date" },
    "kind":       { "type": "keyword" },
    "text":       { "type": "text", "analyzer": "ja_index",
                    "search_analyzer": "ja_search" } } }
}

同義語は検索のときだけ効かせます。 公式のドキュメントでは、synonym_graph は検索の分析器だけで使うものとされ、索引のときに使うと複数の語からなる同義語の後ろの語の位置がずれる、とあります。

AIへ渡す前に整形する

1. 型式からクラスを引く … 型式の対応表で class_m3 を入れます。台帳のバケット容量と違えば、両方を残して印を付けます
2. 数値の書き方をそろえる … 「0.45㎥（JIS）」「0.45」を数値にし、「4,850h」「4850時間」を整数にします
3. 備考からアタッチメントを取り出す … 「B配管」「ブレーカー配管」「1次2次配管」を kind: breaker_piping にそろえます。取り出せない書き方は、元の文を残して「未分類」にします
4. 作業報告を行に分ける … 作業の内容と指摘事項を分け、kind に work／finding を入れます
5. メーター交換の印を付ける … 整備記録に「アワーメーター交換」があれば、meter_replaced を真にします
6. 問い合わせの文から個人の情報を外す … お客様の担当者の名前、電話番号、メールアドレスは、Claude に渡す前に伏せます

3番目の「未分類」は、捨てずに一覧にし、毎週の営業会議で対応表に足していきます。 5番目は値を直さず、候補の一覧に「メーター交換あり」と必ず出すまでにします。 交換前の値が残っていないと、本当の稼働時間は分かりません。

AIに処理させる

AIの仕事は、問い合わせの読み替えと、整備記録から伝えるべき記載を拾うことの2つです。

「状態の良し悪しを判断しない」が、いちばん大事な線です。 「足回りの摩耗 60％」が買ってよい状態かは、お客様の使い方で変わります。

用途からの読み替えには印を付けます。 「解体で使う」からブレーカーの配管を条件にするのは推測で、圧砕機のつもりかもしれません。inferred: true を付け、画面で色を変えて出します。

指示内容を固定する

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

あなたは中古建機の販売会社で、営業の在庫探しを手伝う立場です。
お客様の問い合わせを、在庫を探すための条件に読み替えてください。
問い合わせに書かれていることだけを使い、書かれていない希望を足さないでください。

【読み替えの決まり】
- must: 外れたら提案にならない条件。機種、クラス、年式の下限、
  稼働時間の上限。お客様が「必ず」「以上」「以内」と言ったもの
- want: 外れても他が合えば提案になる条件。アタッチメント、配管、
  ヤード、メーカー
- クラスは【クラスの表】の値に当てる。「0.45クラス」は 0.45 とし、
  幅をどうするかは ask に入れる
- 用途の言葉（解体、法面、浚渫など）から条件を作るときは、
  inferred を true にし、reason に元の言葉と読み替えた理由を書く
- ask: お客様に確かめること

【厳守事項】
- 予算と納期は検索の条件にせず、budget_note と due_note に写してください。
- メーカーや型式を勧めないでください。お客様が挙げたものだけを使ってください。
- 稼働時間の上限を「くらい」「ほど」で言われた場合は must に入れず、
  ask に「稼働時間の上限」を入れてください。
- お客様の会社の規模や資金の状況を推し量って書かないでください。

【クラスの表】{class_table}
【問い合わせ】{inquiry_text}

2回目（候補の整備記録の読み取り）の指示です。

あなたは中古建機の販売会社で、営業が提案の前に整備記録を確かめるのを
手伝う立場です。下の【候補】ごとに、【整備記録の行】を読んでください。

【拾うもの】
- finding: 指摘事項の行は、内容にかかわらずすべて拾う
- related: 問い合わせに関わる部位（【問い合わせの条件】の用途と
  アタッチメントに関わる部位）の作業の行
- meter: アワーメーターの交換・不調の記載

【厳守事項】
- 行の文をそのまま quote に写し、report_no と line_no を付けてください。
  要約で言い換えないでください。
- 状態が良い・悪い、買ってよい・よくない、と書かないでください。
- 記載が無いことを「問題なし」と書かないでください。
  拾うものが無ければ、配列を空にしてください。
- 価格、値引き、保証について書かないでください。
- 【整備記録の行】に無い作業や部品を書かないでください。

【問い合わせの条件】{conditions}
【候補】{candidates}
【整備記録の行】{maint_lines}

「記載が無いことを『問題なし』と書かない」を明記しないと、AIは「特に問題は見られません」と書きます。 そのまま伝えると、記録が無いだけの機械に状態の保証を与えたことになります。

「要約で言い換えない」も同じ理由です。 「旋回時に異音、様子見」を要約すると、「様子見」の意味が消えます。

出力形式を固定する

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

{
  "must": [ { "field": "machine_type | class_m3 | year | hour_meter",
              "op": "eq | gte | lte", "value": "",
              "inferred": false, "reason": "" } ],
  "want": [ { "field": "attachment | yard | maker",
              "value": "", "inferred": false, "reason": "" } ],
  "budget_note": "",
  "due_note": "",
  "ask": [""]
}

2回目は、候補ごとに次の形で受け取ります。

{
  "machine_no": "",
  "findings": [ { "report_no": "", "line_no": 0, "quote": "" } ],
  "related":  [ { "report_no": "", "line_no": 0, "quote": "" } ],
  "meter":    [ { "report_no": "", "line_no": 0, "quote": "" } ]
}

AWS の公式ページでは、すべての object に additionalProperties: false を書く必要があり、数値の minimum・maximum などの制約には対応していません。値の範囲は受け取った後に Lambda で確かめます。新しいスキーマは最初の呼び出しで最大90秒ほどかかるとされているので、待ち時間を長めにしておきます。

1つ目の理由は、must と want がそのまま filter と should になることです。

2つ目は、根拠を機械的に確かめられることです。 quote が該当の行と一字一句同じかを Lambda で照合し、合わなければ一覧に出さず「根拠の照合に失敗」と出します。 写し間違いや別の機械の行の混入に気づけます。

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

システムへ連携する

顧客の台帳とはつなぎません。 商談の記録は営業がいつもの台帳に書きます。

人が確認する

1. 読み替えを見る … inferred の条件とクラスの幅を確かめ、違えば直して探し直します
2. 指摘事項を読む … 指摘事項の行を作業報告の原本で確かめ、伝え方に迷うものは整備の担当に聞きます
3. メーター交換の機械を確かめる … 交換前の稼働時間が残っているかを整備の担当に聞きます
4. 返信を仕上げる … 外れた条件と指摘事項をそのまま書いて返信します

2番目を省かないでください。 指摘事項は、お客様が買った後の修理に直結します。

例外に対処する

3行目がいちばん大事です。 整備記録が無いのは報告が届いていないからで、状態が良いからではありません。

記録を残す

• 検索ごとの、問い合わせの文（個人の情報を伏せたもの）、1回目の読み替えの JSON、営業が直した箇所
• 検索の条件と、外した条件の順
• 候補ごとの2回目の JSON と、根拠の照合の結果
• 営業が提案した機械と、返信に書いた指摘事項
• 取り込んだ台帳と作業報告の写しの時刻

営業が直した箇所は、読み替えの指示と型式の対応表を直す材料にします。