銀行の融資稟議書をAIで効率化するには？事例・プロンプト・RAGと導入評価

融資稟議書への生成AIの活用は、資料の収集・整理、記載事項の確認や素案作成を支援する取り組みです。文章が整うことと、融資条件や返済可能性を適切に判断できることを分け、担当者・審査部門の確認へつなげます。2026年10月24日時点で確認した銀行・技術提供者の公式発表と金融庁の資料を基に、先行事例、入力・プロンプト、RAGと導入評価の進め方を整理します。

先行事例の見方：導入時期・文書評価・時間削減を区別する

事例を比較するときは、発表日、対象の業務と利用者、試行か本番か、実績か見込みかを確認します。文書の品質、素案を作る時間、確認を含めた業務全体の時間、融資の判断結果は異なる指標です。他行の割合や導入期間を、そのまま自行の達成目標や必要期間へ置き換えず、同じ条件で何を測ったかを確かめます。

京都銀行：若手行員の試行結果と、年間削減時間の見込み

NTTデータの2026年2月25日の発表は、京都銀行へ同年7月からサービスを提供するとしています。若手行員の試行では、手作業に比べた作成時間の約半減、稟議書に対する審査役評価の合格ライン到達率の約30％から約95％への向上を報告しています。後者は融資の承認率ではなく、最大年間11,700時間は業務削減効果の見込みです。

これは当時の提供計画と検証結果を述べた発表です。この発表だけから、確認日時点の全営業店での利用範囲や、導入後の年間削減実績まで確定したとは扱いません。行内の情報収集と素案作成を組み合わせた仕組みであり、文章生成だけで同じ効果が出るという比較でもありません。

宮崎銀行：一部店舗から、その後の全店展開へ

日本IBMの2024年6月13日の発表は、同年4月に宮崎銀行の一部店舗で本番利用を始め、稟議書作成の作業時間を95％削減したとしています。既存の実証済み生成AIアセットを使った約2か月の開発であり、全ての銀行が同じ期間で全店へ導入できる根拠ではありません。

その後、宮崎銀行の2025年3月期決算説明資料「当行の取り組み②」は、2024年12月に全店へ展開したと説明しています。古い発表の「一部店舗」を現在の範囲として据え置かず、後続の公式資料と合わせて読みます。作成時間の削減を、審査や融資業務全体の同率削減とは読み替えません。

自社の導入判断では、何をAIへ任せたか、入力の準備と確認・修正を誰が行ったかも整理しましょう。発表に対象件数や測定方法の詳細が示されていない部分は、推定で補って比較表を完成させず、比較できる範囲を明らかにします。

入力とプロンプト：事実・計算・未確認事項と判断を分ける

最初に、使う稟議書の様式、必要な情報、確認担当と承認経路を整理します。案件概要、取引先、財務情報、資金使途や返済に関する資料、条件やリスクなどを、自行の様式と業務に合わせて確認します。全ての銀行・案件で同じ章立てや直近3期分が必須と決めず、必要な資料と対象期間を担当部門で合わせます。

入力の数字と根拠資料を対応させる

財務情報には、会社、連結・単体、決算期、通貨と表示単位、実績・計画、資料の出典と改訂を付けます。数値のゼロと未取得を区別し、面談で得た説明と財務諸表で確認した事実も分けます。同名の会社や古い計画を取り違えたり、千円と百万円、月次と年度の値を混ぜたりしないよう、生成前にも確認します。

比率や差額を使うなら、分子・分母、対象期間、使用する値と計算方法を固定し、計算結果を別に照合できるようにします。生成された文章中の数字だけを正解としません。また、「自己資本比率が特定の割合未満なら一律に融資不可」などの共通基準を本記事から与えるのではなく、自行が承認した基準と案件の条件に従って担当者が判断します。

素案の役割、使用できる情報、出力と不足時の扱いを指定する

プロンプトには、AIの役割、対象の案件、参照してよい資料、必要な項目、出典の示し方、不足や矛盾がある場合の扱いを含めます。以下は設計を考えるための簡単な例です。実顧客の情報を公開サービスへ貼り付ける手順ではなく、利用環境と送信できる資料を確認したうえで、自行の様式へ合わせて評価します。

役割：担当者が確認する融資稟議書の素案作成を補助する。
使用資料：この案件について利用を許可された資料と、その版・対象期間。
出力：指定した各項目に、記載案、根拠資料と位置、未確認事項を分けて示す。
制約：資料にない事実・数値・面談内容を補わない。矛盾や不足は確認事項として残す。
判断：融資の可否・条件を確定せず、担当者・審査部門が確認する論点を示す。

役割を「ベテラン審査担当者」と書くだけで、経験や審査責任がAIへ移るわけではありません。必要な観点がそろうか、根拠が追えるか、未確認事項を隠していないかを、案件ごとの出力で確認します。プロンプトの修正理由と版も残し、変更前後で記載がどう変わるかを検証しましょう。

RAGの設計：過去の承認結果を、新規案件の判断根拠にしない

RAGは、必要な情報を検索し、その結果を生成時に参照する方法です。モデルの重みを調整するファインチューニングとは区別します。金融庁のAIディスカッションペーパー第1.1版も、RAGとモデルの再学習を別の方法として説明しています。過去の稟議書を検索できることだけで、判断基準が正しく実装されたとは考えません。

規程・様式・過去事例と、現在の案件情報を分ける

参照資料には、出典、適用日、改訂、対象業務や案件の識別を付けます。現行の規程と廃止済みの様式、参考にする過去の記述と今回の顧客情報を混ぜないようにします。過去の承認案件だけを「正解」として集めると、記載不足や条件の違いを見落とすおそれがあるため、参考にする範囲と確認する観点を決めます。

NTTデータのRAG実装に関する公式解説も、データの整理、専門知識を持つ人の確認と更新の担当を重視しています。検索対象の量を増やすだけで品質が上がるとせず、必要な資料を見つけられるか、その箇所で記述を裏付けられるかを分けて評価します。記事中の汎用的な資料検索の例を、融資判断へそのまま適用しないようにします。

利用者の権限を、検索結果と出力にも反映する

資料を閲覧できる権限と、AIが検索・参照できる範囲をそろえます。MicrosoftのCopilot StudioのRAG仕様でも、認証や検索結果の権限制御は接続先によって異なります。ある接続方法で権限制御があることを、全てのデータソースや別の自作システムにも備わっていると考えないよう、利用者を変えて検証します。

原文が見つからない場合や資料間で値が違う場合は、もっともらしい説明で埋めず、確認が必要と示す出力を評価します。引用が表示されていても、引用先の文章と生成内容が一致するかは確認が必要です。検索文書に含まれる指示が、利用者の権限や処理範囲を変更しない設計も検討します。

海外の製品の仕様は、日本の金融機関に適用する法令や自行の内規そのものではありません。採用する接続、保存先、委託先、利用するモデルと運用条件に応じて確認します。参照の根拠、説明と業務上の責任を対応付ける考え方は、デジタルトラストと業務の確認にもつながります。

導入評価と運用：確認・修正を含めた時間と品質を測る

PoCでは、対象とする案件、入力資料、出力項目、正しさの評価方法、扱わない範囲を決めます。通常の例に加え、資料不足、改訂の違い、数値の矛盾、対象外の依頼なども、実際の業務に合わせて試します。学習や調整に使った例と最終評価用の例を区別し、検証に使える資料か、誰が結果を見るかを先に確認します。

文書の評価と、業務全体の効果を分けて記録する

必要事項の充足、数値と根拠の一致、未確認事項の表示、確認・修正の内容を記録します。時間は素案生成だけでなく、入力準備、確認、修正と提出までを測り、現行業務と条件をそろえて比べます。評価者、対象件数、案件の構成と測定期間も残し、融資の承認率を文章作成AIの単純な成功指標にしません。時間を金額へ換算するときや費用を比較するときは、費用対効果・ROIの計算と、時間の換算額と支出削減の違いも確認しましょう。検証の設計は、PoCの評価基準と本番移行の判断で整理できます。

金融庁の第1.1版の公表案内と本文は、AI利活用の初期的な論点を整理する位置付けです。全ての金融機関に同じ環境構成や対応一式を義務付ける規定とは区別し、適用する法令・監督指針・契約と自行のルールに照らして導入条件を確認します。

権限・保存・変更と、担当者が戻せる手順を整える

顧客情報の送信範囲、保存と削除、追加学習等への利用、アクセス権限、必要な履歴と閲覧者を整理します。モデルや検索資料、指示文を更新するときは再評価し、誤りや参照できない資料が見つかった場合に、誰へ報告してどの作業へ戻すかも決めます。閉域やクラウドという設置形態の名称だけで、データの扱いと業務の確認が済んだとは判断しません。

生成AIの導入では、人が最後に見るという一言で済ませず、原本へ戻れる画面、確認する項目、修正・差し戻しの担当を用意します。審査上の判断を行う部門と、実装・運用の担当が、対象範囲と変更条件を共有します。モデルやシステムの障害で使えないときの代替手順も検討しましょう。

素案作成と既存業務の連携、システムの診断を相談する

入力・参照・確認から既存システムへの受け渡しまで実装したい場合は、renueのFDEによる要件整理・設計・実装・運用支援へ相談できます。利用できる資料、様式、確認・承認の流れ、連携先と権限を整理し、効果を確かめる範囲を具体化します。特定銀行向けの融資判断システムを導入済みであるという説明や、審査結果の保証ではありません。

認証・権限や外部との接点、既存コードの弱点の診断・改修が必要な場合は、AIセキュリティの診断・対策・システム刷新へつなげられます。対象と許可された環境、確認する範囲を合意して検討します。脆弱性診断の結果だけで、生成内容の正確性や金融規制への適合、融資可否の判断まで確認済みにはしません。