リース会社の財務部が、満了したリース物件の残価と中古売却の実績から、新しい見積の残価の参考になる事例を OpenSearch で探す

処理の起点を決める

起点は2つあります。毎晩の満了した契約の取り込みと、担当の検索のボタンです。

取り込みは、前の日までに満了・売却・買取が確定した契約を書き出し、索引に加えます。売却が確定していない満了の契約も「売却待ち」として入れます。 近い物件が何台返ってきているかも、残価を決める材料になるからです。売却が確定した日に、同じ文書を上書きします。

検索のボタンは、担当が依頼のメールと見積書の文を貼った後に押します。型式の系統の表（第7章「前処理」）と残価の目安表は、財務部が月に1回見直し、見直した日を記録します。

入力データを集める

質を決めるのは、満了時の扱いの区分です。 同じ「売れた額」でも、返却して業者に売ったものと、お客様が買い取ったものでは意味が違います。お客様の買取の額は、契約で決めた額であることが多く、中古の相場を表しません。 区分を必ず持たせ、検索の既定では「返却して売却」だけを使います。

借り手の会社名と担当者名は、索引にも生成AIにも渡しません。 物件の記録と金額と日付だけで、近い事例は探せます。

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

絞り込みは bool の filter に置きます。 OpenSearch の公式のドキュメントでは、filter の句は一致するかどうかだけを決め、関連度の点数には加わらず、結果がキャッシュされうるとされています。物件の種類と期間と満了時の扱いは、合うか合わないかの条件なので、点数に混ぜません。

近さの並べ替えは function_score の減衰関数で行います。 公式のドキュメントでは、減衰関数（gauss・exp・linear）は数値・日付・位置の項目に使え、origin からの距離で点数を下げ、offset の内側は1点、offset に scale を足した距離で decay の点（既定は0.5）になるとされています。取得価額は依頼の額を origin に、売却の日は今日を origin にして、新しい売却ほど上に来るようにします。

ここで、公式のドキュメントの一文に注意します。 減衰関数は、項目が無い文書に1点を返すとされています。売却の日が空の「売却待ち」の契約は、何もしないといちばん新しく売れた事例と同じ点数で上に来ます。そのため、並べ替えの検索では exists で sale_ratio のある文書だけに絞り、売却待ちは別の検索で台数だけを数えます。

GET /lease_contracts/_search
{
  "size": 10,
  "_source": ["contract_no", "maker", "model", "model_family", "cost_yen", "term_months",
              "set_ratio", "sale_ratio", "sold_on", "months_to_sale", "sale_route", "hours"],
  "query": { "function_score": {
    "query": { "bool": {
      "filter": [
        { "term":   { "asset_class": "machining_center" } },
        { "range":  { "term_months": { "gte": 48, "lte": 72 } } },
        { "term":   { "end_type": "returned_sold" } },
        { "exists": { "field": "sale_ratio" } } ],
      "should": [
        { "term": { "model_family": { "value": "A-VMC-500", "boost": 2 } } },
        { "term": { "maker": "A" } } ] } },
    "functions": [
      { "gauss": { "cost_yen": { "origin": 24000000, "offset": 2000000, "scale": 6000000 } } },
      { "gauss": { "sold_on":  { "origin": "now", "offset": "180d", "scale": "730d" } } } ],
    "score_mode": "multiply", "boost_mode": "multiply" } },
  "aggs": {
    "sale_ratio_pct": { "percentiles": { "field": "sale_ratio", "percents": [25, 50, 75] } },
    "set_ratio_pct":  { "percentiles": { "field": "set_ratio",  "percents": [25, 50, 75] } } }
}

分布の集計は、上位10件ではなく、絞り込みに合ったすべての事例にかかります。 公式のドキュメントでは、percentiles は数値の項目の指定した百分位の値を見積もる集計で、既定の百分位は1・5・25・50・75・95・99、値は近似（既定は tdigest）とされています。分布の母集団を決めるのは、並べ替えではなく filter の条件です。

AIへ渡す前に整形する

1. 割合を計算して持たせる … sale_ratio＝売却額÷取得価額、set_ratio＝設定した残価の額÷取得価額を、取り込みの Lambda で小数4桁にします
2. 期間を月数にそろえる … 「5年」「60か月」を 60 にし、再リースの期間は term_months に足さず release_months に分けて持ちます
3. 満了時の扱いを区分にする … returned_sold（返却して売却）、customer_bought（買取）、released_sold（再リースの後に売却）、terminated（途中解約）、awaiting_sale（売却待ち）
4. 型式の系統を付ける … 型式の系統の表から model_family を付けます。表に無い型式は空のまま残します
5. 売却までの月数を出す … 満了日から売却の日までの月数を months_to_sale に持ちます
6. 依頼の側をそろえる … 「2,400万円」を 24000000 に、「5年」を 60 にし、物件の種類を区分の値にします

1番目の割合を取り込みのときに計算するのは、検索のたびに計算させないためです。 割合を索引の値として持てば、percentiles がそのまま集計でき、画面の数字と記録の数字が1対1で対応します。

2番目で再リースの期間を分けるのは、第3章の（b）を防ぐためです。 5年の契約を3年再リースして売った物件は、8年使った物件です。term_months に足すと期間の range に入らなくなり、足さないと5年の物件として混ざります。 分けて持ち、検索の既定では end_type で外します。

AIに処理させる

AIの仕事は2つです。 依頼の文を物件の条件に読み替えることと、上位の事例を記録のまま並べ、依頼との違う点をメモにすることです。

残価の設定率を提案させないのが、この構成でいちばん大事な線です。 生成AIに事例と分布を渡して「適切な残価は」と聞けば、もっともらしい率が返ります。その率には、今の中古の相場も、会社の残価の方針も、お客様の与信も入っていません。 画面に率の提案が出れば、忙しい日ほどその数字が見積に写ります。

平均や中央値を書かせないのも同じ理由です。 分布は OpenSearch の集計の値をそのまま画面に出し、AIの文の中には数字を作らせません。

指示内容を固定する

1回目（依頼の読み替え）の指示です。

あなたはリース会社の財務部で、残価を設定する見積の依頼を整理する立場です。
【依頼】から、過去の契約を探すための条件を取り出してください。

【取り出すもの】
- asset_class: 物件の種類。【物件の種類の区分】から1つ選ぶ。選べなければ空
- maker_raw: メーカー。書かれたまま
- model_raw: 型式。書かれたまま
- cost_raw: 取得価額。書かれたまま（「2,400万円」など）
- term_raw: リースの期間。書かれたまま（「5年」など）
- usage_raw: 使い方。書かれたまま（「2交代」「屋外」など）
- missing: 書かれていない項目の名前

【厳守事項】
- 型式・年式が書かれていなければ空にしてください。推し量らないでください。
- 金額と期間は、単位を直さず書かれたまま写してください。計算しないでください。
- 残価の率や額について、何も書かないでください。
- お客様の会社名・担当者名は写さないでください。

【物件の種類の区分】{asset_classes}
【依頼】{request_text}

2回目（事例の表とメモ）の指示です。

あなたはリース会社の財務部で、残価を決める担当に過去の事例を示す立場です。
【事例】は満了した契約の記録です。数字はすべて記録の値です。

【書き方】
- 事例ごとに、契約番号・型式・取得価額・期間・設定率・売却の割合・
  売却の日・売却の経路を、記録の値のまま書いてください。
- 事例ごとに、【依頼の条件】と違う点を differences に書いてください。
  型式の違い、期間の違い、使い方や稼働時間の違いを、記録にある範囲で書きます。
- 記録に無い項目は「記録なし」と書いてください。

【厳守事項】
- 割合・金額を計算しないでください。平均・中央値・差を書かないでください。
- 今回の残価の率や額を提案しないでください。
- 「高く売れる」「相場が強い」など、記録に無い見通しを書かないでください。
- 事例どうしを比べて、どちらが正しいかを書かないでください。

【依頼の条件】{conditions}
【事例】{hits}

「差を書かない」を入れるのは、2つの割合が並ぶとAIが自分で引き算をするからです。 差は画面の側でプログラムが出します。

出力形式を固定する

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

{
  "request_no": "",
  "conditions": { "asset_class": "", "maker": "", "model": "", "cost_yen": 0,
                  "term_months": 0, "usage": "" },
  "cases": [
    { "contract_no": "", "model": "", "cost_yen": 0, "term_months": 0,
      "set_ratio": 0, "sale_ratio": 0, "sold_on": "", "sale_route": "",
      "differences": [""] } ],
  "missing": [""]
}

AWS の公式ページでは、Converse API の outputConfig.textFormat に JSON スキーマを渡すと応答がスキーマに沿うとされています。すべての object に additionalProperties: false が要り、数値の minimum・maximum は使えません。 新しいスキーマは初回に文法を組み立てるため最大で約90秒かかり、組み立てた文法は24時間キャッシュされるとされています。呼び出しの読み取りの待ち時間は120秒以上にします。

1つ目の理由は、AIが返した数字を索引の値と照合できることです。 cases の contract_no ごとに、set_ratio・sale_ratio・cost_yen が索引の _source と一致するかを Lambda が確かめます。1つでも違えば、その事例の行は索引の値で置き換え、差し替えたことを記録します。

2つ目は、分布の表をAIの出力と分けて持てることです。 画面には、percentiles の集計の結果を次の形で別に出します。

事例の数を必ず並べます。 事例が3件しかない分布と300件ある分布では、同じ50％でも重みがまるで違います。事例が5件未満のときは、分布の行を出さずに「事例が少ない」とだけ出します。

システムへ連携する

担当が決めた設定率は、画面で「見た事例の契約番号」と一緒に S3 に残します。 見積の画面への入力は、担当がいつものとおり行います。この構成から見積や契約の記録を書き換える経路は作りません。

人が確認する

1. 読み替えを見る … 物件の種類の区分・取得価額・期間が、依頼のとおりに取り出されているかを確かめます
2. 事例の数を見る … 分布の事例の数が少なければ、期間の幅や物件の種類の区分を広げて引き直します
3. 事例を選ぶ … 上位の事例のうち、使い方や稼働時間が今回と違いすぎるものを外します
4. 今の相場を足す … 中古の業者からの直近の買取の見積など、索引に無い情報を担当が確かめます
5. 設定率を決めて根拠を残す … 目安表の率から上げ下げした理由と、見た事例の契約番号を残します

4番目を省かないでください。 索引にあるのは過去に売れた額で、満了は5年後です。 売却の日を並べて出すのは、相場の強かった時期の偏りを担当が見て取れるようにするためです。

例外に対処する

4行目は相場の兆しの行です。 返ってきた物件が売れ残っていれば、今の相場は過去の分布より弱い可能性があります。

記録を残す

• 依頼ごとの、依頼の文（会社名を伏せたもの）、1回目の JSON、担当が直した箇所
• 検索の条件、上位の事例、分布の集計の結果と事例の数、売却待ちの台数
• AIの数字を索引の値で置き換えた記録
• 担当が決めた設定率と、見た事例の契約番号、上げ下げした理由
• 型式の系統の表と残価の目安表を見直した日と担当

4つ目が、いちばん残したい記録です。 5年後にその契約が売れたとき、決めたときに見た事例と分布と、実際の売却の割合を並べられます。