リースの新しい申込を審査するときに、業種・規模・物件の近い過去の審査記録を探し、当時の判断と条件・その後の延滞の有無を根拠付きで返す

処理の起点を決める

取り込みは2つの起点で動きます。

1つ目は、審査の判断が決裁されたときです。 審査システムが決裁の確定を記録したところで、その案件を1件の文書にして登録します。決裁前の案件は取り込みません。 担当の下書きの懸念点が、決まった判断の理由のように返るのを防ぎます。

2つ目は、毎月の締めのあとです。 債権管理の仕組みが月末の入金を確定させたあと、契約ごとの結果を受け取り、該当する案件の outcome を更新します。延滞は月をまたいで起き、解消もするので、毎月上書きします。 いちばん重かった状態は別の項目に残します。

検索は、担当が申込の画面で「前例を探す」を押したときに動きます。 申込が回ってきた時点で自動で探すこともできますが、審査コメントの下書きが無いと意味の近さで比べる材料が無いので、担当が事業の内容と懸念点を数行書いてから押す形にします。

入力データを集める

質を決めるのは、審査コメントに「懸念点」と「判断の理由」が書かれているかです。 「問題なし」だけの案件は、意味の近さで比べる材料がありません。承認の案件ほど短く書かれがちなので、取り込みで文字数を見て、短すぎるものに印を付けます。

会社名・代表者名・所在地は、索引に入れません。 審査コメントの中に出てくるものも、取り込みで「申込先」「代表者」に置き換えます。前例として見たいのは会社の属性と判断の筋道で、どの会社かではありません。

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

審査システムからは、決裁の確定ごとに案件のデータを受け取ります。画面の表示ではなく、審査システムの持つ出力の仕組み（データの書き出しやAPI）から取ります。 どの方式が使えるかは審査システムによるので、この部分は利用環境に応じた個別の実装になります。

債権管理の仕組みからは、毎月の締めのあとに契約ごとの状態の一覧を書き出してもらいます。 債権管理の側は契約番号で、審査の側は案件番号で管理していることが多いので、契約を起こしたときに両方の番号を持つ対応表を作り、それで結びつけます。 1件の審査から複数の契約が起きることもあるので、結果は契約ごとに持ち、いちばん重い状態を案件の値にします。

索引は1件の審査を1件の文書にします。 審査コメントは長くても数千字なので、節に分けません。

意味のベクトルは、Amazon Titan Text Embeddings V2 で作ります。 公式のドキュメントでは、入力は最大8,192トークンまたは50,000文字、出力は1,024（既定）、512、256次元で、日本語を含む多言語に対応するとされています。

AIへ渡す前に整形する

1. 固有名を外す … 審査コメントの会社名・代表者名・取引銀行名・所在地を、記号に置き換えます
2. 数値を帯にする … 売上・従業員数・業歴・金額を、社内で決めた帯の番号にします。決算の数値そのものは索引に入れません
3. 短いコメントに印を付ける … 審査コメントが一定の字数に満たない案件は、意味の検索の対象から外し、属性だけで引ける形で残します
4. 審査基準の版を付ける … 決裁の日から、その時点の審査基準の版を付けます
5. 否決と取下げを区別する … 否決の案件と、申込先が取り下げた案件を別の値にします。取下げは判断の前例になりません
6. ベクトルを作る … 審査コメントについて、Titan Text Embeddings V2 でベクトルを作ります

2番目で決算の数値を入れないのは、 数値が近いことを似ていることと取り違えないためです。売上が同じでも、利益の出方と借入の重さで判断は分かれます。 数値は担当が決算書で見るもので、前例は判断の筋道を見るために使います。

AIに処理させる

AIの仕事は、新しい申込と前例のあいだの、似ている点と違う点を、審査コメントの引用付きで書くことだけです。 前例を探すのは検索基盤、判断・条件・結果を出すのは記録の値です。

3行目が、いちばん外せない線です。 前例が5件出て、そのうち2件で延滞があれば、AIは「延滞の可能性が高い」と書きがちです。5件は統計ではありません。 延滞は景気や取引先の倒産でも起き、申込先の属性だけで決まりません。結果は記録の値として並べ、どう読むかは審査役に任せます。

「違う点」に審査基準の版を入れるのは、 前例の判断が、いまとは違う基準で行われていることがあるためです。基準を改めた理由が、まさにその種類の案件の延滞だったということもあります。

指示内容を固定する

あなたはリース会社の審査部で、新しい申込の審査のために過去の前例を整理する係です。
渡された検索結果（前例の審査コメント）だけを根拠にしてください。
一般的な業界の知識や与信の知識で補わないでください。

【新しい申込】
業種：{industry}　物件：{asset_class}（{asset_condition}）　規模の帯：{sales_band}
担当の審査コメントの下書き：{draft_comment}

【検索結果】
前例ごとに、案件番号、当たった段（業種の中分類まで一致／大分類まで一致／物件だけ一致）、
審査基準の版、審査コメントが渡されます。

【前例ごとに書くこと】
1. 当時の懸念点と判断の理由（審査コメントの文を引用）
2. 新しい申込と似ている点（事業の内容、申込の背景、物件の使い道）
3. 新しい申込と違う点（業種の細かさ、物件の使い道、背景、審査基準の版）

【厳守事項】
- 申込を承認すべきか、否決すべきかを書かないでください。
- 付けるべき条件を書かないでください。
- 延滞が起きそうか、起きにくいかを書かないでください。
- 判断の結果、付けた条件、契約後の結果には触れないでください。
  これらは画面に別に表示されます。
- 審査コメントに無い申込先の評価を書かないでください。
- 違う点が見つからないときも「違う点：記載から判断できない」と書き、空欄にしないでください。
- 審査基準の版が現在の版（{current_policy}）と違う前例には、必ずそのことを違う点に書いてください。

「判断の結果に触れない」を入れるのは、 値と文章が食い違う経路を消すためです。画面には記録の値があり、AIの文章が「当時は承認」と書けば、言い換えの誤りがあったときにどちらが正しいかで担当が迷います。

審査コメントは、Claude の検索結果ブロックで渡します。 前例1件を1つの search_result にし、source に案件番号、title に当たった段と審査基準の版、content に審査コメントを入れます。公式の説明では、検索結果ブロックは Claude API、Amazon Bedrock、Google Cloud で使え、引用は content の中のテキストブロック単位です。懸念点と判断の理由を別のブロックに分けて渡すと、引用がどちらから来たかが分かります。

出力形式を固定する

1段目の検索は、次のように組みます。

POST /lease-reviews/_search
{
  "size": 8,
  "_source": ["case_id", "decision", "conditions", "outcome", "outcome_worst",
              "policy_version", "decided_on", "comment"],
  "query": {
    "knn": {
      "comment_vector": {
        "vector": [0.017, -0.022],
        "k": 8,
        "filter": { "bool": { "must": [
          { "term": { "industry_mid": "24" } },
          { "term": { "asset_class": "工作機械" } },
          { "term": { "asset_condition": "中古" } },
          { "range": { "sales_band": { "gte": 3, "lte": 5 } } },
          { "range": { "decided_on": { "gte": "now-7y/d" } } }
        ] } }
      }
    }
  }
}

2段目は industry_mid を industry_major に、3段目は業種の条件を外して物件と規模だけにします。 Lambda は1段目で5件に満たなければ2段目を投げ、どの段で当たった案件かを tier として結果に付けます。 1段目の案件と重なるものは2段目から除きます。vector は担当の下書きから作った1,024個の数値です。

画面に返す形は、次のJSONです。

{
  "application": { "industry_mid": "24", "asset_class": "工作機械", "sales_band": 4 },
  "precedents": [
    { "case_id": "RV-2022-03318", "tier": 1, "decided_on": "2022-09-14",
      "policy_version": "2021版", "policy_differs": true,
      "decision": "条件付き承認", "conditions": ["期間短縮", "保証金"],
      "outcome": "延滞なし", "outcome_worst": "延滞なし", "outcome_month": "2026-09",
      "concerns_quoted": "", "same_points": "", "different_points": "",
      "citations": ["RV-2022-03318"] }
  ],
  "relaxed_to": 1,
  "not_found": false
}

1つ目の理由は、decision・conditions・outcome を、AIを通さずに索引から直接入れられることです。 Lambda が検索結果の値を写し、Claude の答えは concerns_quoted・same_points・different_points にだけ入れます。結論に関わる値は、生成の経路を一度も通りません。

2つ目は、tier と relaxed_to で、前例の遠さを画面で示せることです。 3段目まで緩めて当たった前例は薄い色で出し、「物件だけ一致」と見出しを付けます。

3つ目は、outcome と outcome_worst を分けていることです。 いまは延滞が解消していても、一度30日以上延滞した案件は outcome_worst に残ります。

システムへ連携する

審査の意見書には、何も自動で書き込みません。 担当が前例を選び、自分の言葉で意見書に書きます。

人が確認する

この構成の確認は、必須です。 出てくるのは前例の材料で、可否と条件は審査部が決めます。

1. 当たった段を見る … 1段目の前例から読み、3段目の前例は参考にとどめます
2. 審査基準の版を見る … いまと違う版の前例は、基準を改めた理由と照らして読みます
3. 原本を開いて確かめる … 意見書に使う前例は、審査記録の原本を開き、引用された懸念点が原本にあるかを確かめます
4. 使った前例を意見書に書く … 案件番号と、何を参考にしたかを一言添えます

1件あたり10分を目安にします。 前例が5件出れば、当たった段と結果の値を見て2〜3件に絞り、似ている点と違う点を読み、原本を開くのは1〜2件です。

例外に対処する

4行目を見落とすと、前例の読み方が偏ります。 否決した案件には契約後の結果がありません。結果が付いているのは承認した案件だけなので、「延滞なしの前例が多い」は「承認した案件の中では」という意味でしかありません。 画面の結果の欄に「契約なし」をはっきり出すのはそのためです。

記録を残す

• 取り込んだ案件番号と決裁日、取り込んだ日時と審査基準の版
• 毎月付け足した結果と、付け足した月
• 検索の入力（属性と下書き）、当たった段、返した案件番号
• Claude に渡した審査コメントと、返ってきた答えと引用
• 担当が意見書に使った前例と、使わなかった前例
• 前例が見つからなかった申込の属性

5つ目からは、当たった段ごとの使われ方も数えます。 3段目の前例がほとんど使われていなければ、緩める段を2段で止めてよいということです。6つ目は、審査の記録の書き方を直す材料です。 前例が見つからない業種と物件の組み合わせが偏っていれば、その区分の審査コメントが短いか、物件の区分が細かすぎることが多いです。