融資担当が、面談の記録・財務分析シート・資金使途の資料から、融資稟議書の所見欄の下書きを作り、不足している確認事項を挙げる

処理の起点を決める

担当者が確認リストの状態を「下書き依頼」にしたことを起点にします。 「アイテムが作成または変更されたとき」のトリガーは状態以外の変更でも動くので、フローの最初で状態が「下書き依頼」かを確かめ、違えば何もせずに終えます。 下書きを書き戻したら、状態を「下書き済み」に変えます。

資料が置かれたことを起点にはしません。 資料は1つずつ置かれるので、途中で動くと、資金使途の資料がまだ無いのに「資金使途の資料が無い」という確認事項が出ます。そろったと判断するのは担当者です。

担当者が資料を足して状態を「下書き依頼」に戻せば、同じ案件の下書きを作り直します。 前の版は消さずに残します。

入力データを集める

質を決めるのは、審査の着眼点の書き方です。 「資金使途の妥当性を確認する」だけでは、何を確かめれば足りるのかが分かりません。「設備資金なら、見積書の日付が3か月以内か、相見積の有無、導入による増収の見込みの根拠」のように、確かめる事実の単位で書きます。 不足している確認事項は、この行と資料を突き合わせて出ます。

財務分析シートの値は、計算済みのものだけを渡します。 AIに売上と前期の売上を渡して増減率を書かせると、桁や期の取り違えが起きます。増減率も指標も、シートの側で計算した値を渡します。

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

着眼点は全部を渡しません。 運転資金の稟議に設備資金の確認事項を当てると、「相見積が無い」という見当違いの不足が出ます。案件の資金使途の種類で、着眼点の行を絞ってから渡します。

面談の記録は12か月で区切ります。 それより古い記録は、事業の状況が変わっていることが多く、古い発言を今の事実として書く誤りの元になります。

AIへ渡す前に整形する

1. 資料のそろいの確認 … 面談の記録、シートの値、資金使途の資料の3種類があるかを見ます。無いものは、そのまま「資料が無い」としてAIに伝えます
2. PDFの文字の取り出し … 見積書や契約書のPDFから文字を取り出します。取り出せないページ（画像だけのもの）は印を付け、AIには「読めなかった」と伝えます
3. 個人を特定する情報を伏せる … 経営者の自宅住所、個人の資産、家族の情報など、所見に要らない個人の情報を伏せます
4. 面談の記録に番号を振る … 記録ごとに M-01 のような番号と日付を付け、根拠として引けるようにします
5. シートの値に番号を振る … 項目ごとに F-売上-直前期 のような番号を付けます
6. 資料にも番号を振る … ファイルごとに D-01 を付け、ページ番号を残します
7. 申込の金額と資料の金額を並べる … 案件の条件にある申込の金額と、見積書・契約書の合計の金額を、フローが表にして渡します。一致しているかの判定はフローが行い、AIには結果だけを伝えます

4〜6番目が、根拠を付けるための仕掛けです。 番号の無い資料をAIに渡すと、根拠は「面談の記録より」のような大づかみなものになり、担当者が確かめるにはまた全部を読むことになります。 番号を振っておけば、下書きの横に M-07 と出て、その記録だけを開けば済みます。

3番目は、経営者保証の検討で効きます。 保証の要否を考える材料には経営者個人の資産も含まれますが、所見の下書きに個人の資産の明細を書く必要はありません。 下書きに要らない情報は、渡さないほうが確実です。

AIに処理させる

させるのは、所見欄の①〜⑥の下書きを書くことと、不足している確認事項を挙げることです。どちらも、渡した資料の番号を根拠にします。

③で「シートの値をそのまま引く」と書いているのは、第1章の3段落目のとおりです。 下書きに出てくる数字は、numbers_used にすべて書き出させ、フローがシートの値と照らします。

⑤で保証を求める案のときは、理由の下書きを付けます。 金融庁の要請は、保証契約の締結時に、経営者保証に関するガイドライン第4項（2）に掲げられている要素を参照のうえ、資産・収益力については定量的、その他の要素については客観的・具体的な目線を示すなどにより、理解と納得を得ることを目的とした説明に努めることを求めています。下書きでは、どの要素がどの値のために満たされていないと見ているかを、シートの値の番号を付けて書かせます。保証を求めるかどうかを決めるのは担当者です。

不足している確認事項は、着眼点の行ごとに「確かめた資料があるか」を見て出します。 資料の番号が付けられない行が、そのまま確認事項になります。

指示内容を固定する

あなたは銀行の法人営業部で、融資稟議書の所見欄の下書きを作る担当者です。
渡された資料に書かれていることだけを根拠にしてください。

【書くこと】
所見欄の ①資金使途とその妥当性 ②返済原資と返済の見通し ③財務の状況
④事業の状況と経営者 ⑤保全 ⑥総合所見 を、項目ごとに書いてください。
あわせて、審査の着眼点のうち、根拠になる資料が無い事項を挙げてください。

【厳守事項】
- 1文ごとに、根拠にした資料の番号（M-xx、F-xx、D-xx）を付けてください。
  番号を付けられない文は書かないでください。
- 数字は財務分析シートの値（F-xx）をそのまま書いてください。
  足し算・引き算・割り算をしないでください。増減率もシートの値を使ってください。
- 書いた数字は、すべて numbers_used に番号とともに書き出してください。
- 面談の記録に無い見通し・評価を書かないでください。
  「回復が見込まれる」と書くなら、そう述べた面談の記録の番号を付けてください。
- 融資の可否、金額、条件の判断を書かないでください。
  ⑥総合所見は①〜⑤の要点の整理までにしてください。
- 信用格付や債務者区分に触れないでください。
- ⑤で保証の案があるときは、保証を求める理由の下書きを付けてください。
  どの要素が、どの値（F-xx）のために満たされていないと見ているかを書き、
  資産・収益力は値で、その他の要素は面談の記録で具体的に書いてください。
  保証を求めるべきかどうかは書かないでください。
- 資料が無い項目、読めなかった資料は、そのことをそのまま書いてください。
  ほかの資料から補わないでください。
- 確認事項は、着眼点の行の番号と、何を確かめれば足りるかを書いてください。

【案件の条件】{loan_terms}
【所見欄の書式】{memo_format}
【審査の着眼点（資金使途の種類で絞ったもの）】{checkpoints}
【財務分析シートの値】{financials}
【面談の記録】{meeting_notes}
【資金使途の資料】{documents}

「番号を付けられない文は書かない」が、この指示の中心です。 根拠を求めるだけだと、AIは文を書いたあとに近そうな番号を付けます。書く前に番号があるかを問う形にすると、根拠の無い文そのものが減ります。

「足し算・引き算・割り算をしない」まで書くのは、「計算しない」だけでは足りないからです。 「前期比で約1割の増収」のような丸めた言い方で、計算した値を書きます。

出力形式を固定する

次の形のJSONで受け取ります。 Azure OpenAI の構造化出力を使い、JSON Schema に沿った形で返させます。

{
  "case_id": "",
  "sections": [
    {
      "section": "use_of_funds | repayment | financials | business | collateral | summary",
      "sentences": [
        { "text": "", "sources": ["M-07", "D-02"] }
      ],
      "missing_note": ""
    }
  ],
  "guarantee_reason_draft": {
    "applicable": true,
    "sentences": [ { "text": "", "sources": ["F-12"] } ]
  },
  "missing_checks": [
    { "checkpoint_id": "", "what_to_confirm": "", "why_missing": "no_document | unreadable | not_in_notes" }
  ],
  "numbers_used": [ { "source": "F-03", "value_in_text": "" } ]
}

1つ目の理由は、文と根拠を同じ要素に持たせられることです。 sentences の1要素に text と sources を並べるので、確認リストでは文の横に根拠の番号が並びます。 担当者は番号を押して、その記録だけを開きます。

2つ目は、section と why_missing を enum で縛れることです。 構造化出力は enum に対応しているので、書式に無い項目が増えることも、不足の理由が自由な文になることもありません。 不足の理由は「資料が無い」「読めなかった」「面談で聞いていない」の3つに分かれ、担当者が次に何をすればよいかが決まります。

3つ目は、すべての項目が必ず返ることです。 構造化出力ではすべての項目を必須にし、任意の項目は null との組み合わせの型で表します。保証の案が無い案件でも、guarantee_reason_draft は applicable: false として返ります。

numbers_used の照合は、フローが行います。 source の番号でシートの値を引き、value_in_text と一致するかを見ます。構造化出力は数値の範囲や文字列の形式の指定には対応していないため、値の正しさは後段で確かめます。

システムへ連携する

稟議のシステムには書き込みません。 下書きを所見欄に入れるのは担当者です。AIの下書きがそのまま稟議に載る経路を作らないためです。

数字の照合で不一致が出たら、その文に印を付けて書き戻します。 文を消さずに印を付けるのは、担当者がシートの側の誤りに気づくこともあるからです。

人が確認する

担当者が見るのは全件です。見る順番を決めておきます。

1. 数字の照合で印が付いた文を見る … シートの値と違う数字が書かれた文です。直すか、消します
2. 不足している確認事項を見る … no_document は顧客に資料を依頼し、not_in_notes は次の面談で聞きます
3. 根拠の番号を見ながら下書きを読む … 根拠の記録が自分の把握と違えば、その文を消します
4. 保証の理由の下書きを見る … 値と記録が理由として足りているかを確かめます。顧客への説明にそのまま使えるかの目で読みます
5. ⑥総合所見の結論を書く … ここは担当者が書きます

2番目を3番目より先にするのは、不足の事項が顧客を待たせる作業だからです。 先に依頼を出しておけば、下書きを直している間に資料が届きます。

課長は、担当者が直した後の所見を読みます。 下書きと担当者の直しの差分も見られるようにしておくと、どこを直したかで担当者の判断が分かります。

目標は、60件をならして1件40分です。 下書きの手直しと確認事項への対応を含めた時間で、根拠の番号が付いていることで、資料を開き直す時間がなくなることを見込んでいます。

例外に対処する

上から4行目は、AIが番号を作ってしまう場合への備えです。 渡していない番号が出たら、その文の根拠は存在しないので、文ごと外します。

金額の不一致の行も、よく起きます。 申込の金額に諸費用や予備費を含めていることが多く、差額そのものは誤りではありません。ただし、何を含めたかが所見に書かれていないと審査部は問い合わせを返すので、確認事項として必ず出します。

記録を残す

• 下書きを作ったときに渡した資料の一覧と、それぞれの版
• AIに渡した入力の全文（伏せた後のもの）と、返ってきたJSONの全文
• 数字の照合の結果と、不一致の文
• 担当者が直した後の所見と、下書きとの差分
• 不足している確認事項と、それに対して担当者が行ったこと（依頼した日、届いた日）
• 保証の理由の下書きと、顧客に説明した内容の記録

最後の行は、記録の求めに対応します。 金融庁の要請は、保証人等へ適切な説明を行い、その結果等を記録した件数を報告できる態勢を求めており、記録は営業日報等で代用するなど既存の枠組みでの対応でも差し支えないとしています。下書きの理由と、実際に説明した内容を同じ案件に結び付けて残しておけば、件数の把握にもそのまま使えます。