株式会社renue
AI導入・DXの悩みをプロに相談してみませんか？
AIやDXに関する悩みがありましたら、お気軽にrenueの無料相談をご利用ください。 renueのAI支援実績、コンサルティングの方針や進め方をご紹介します。
銀行の融資稟議書作成をAIで効率化する方法｜プロンプト設計から導入ステップまで解説
融資稟議書は、銀行の法人営業（RM）が融資案件の審査に必要な情報を体系的にまとめた文書です。取引先の財務状況、融資条件、返済見通し、リスク要因を論理的に記述する必要があり、1件あたり数時間〜半日を要する負荷の高い業務です。
本記事では、融資稟議書作成をAIで効率化する具体的なアプローチを、プロンプト設計の考え方から導入ステップまで実装レベルで解説します。NTTデータは京都銀行向けに融資稟議書作成AIサービスを導入し、審査役評価の合格率が約30%から約95%に向上、年間最大11,700時間の業務削減を見込んでいます（出典：NTTデータ公式ニュースリリース 2026年2月25日、日本経済新聞）。
稟議書作成の現状と課題
稟議書の標準的な構成
融資稟議書は一般的に以下の構成で作成されます。
- 案件概要：融資金額、金利、期間、資金使途、担保・保証の条件
- 取引先概況：企業概要、事業内容、業界動向、経営者の評価
- 財務分析：直近3期分の財務諸表分析（収益性、安全性、効率性、成長性）
- 融資条件の妥当性：融資額と返済原資の関係、担保の十分性
- 回収見通し：返済財源（事業CF、資産売却等）の検討
- リスク要因：業界リスク、経営リスク、財務リスクの洗い出しと対策
- 結論：融資の妥当性に関する総合判断
現状の課題
- 作成に時間がかかる：財務データの分析、業界動向の調査、文書化を合わせると数時間〜半日を要する
- 品質のばらつき：ベテランRMは論理的で審査を通りやすい稟議書を書けるが、若手はそのスキルを短期間で習得できない
- 審査部門からの差し戻し：記載不備や論理の飛躍による差し戻しが発生し、修正→再提出のサイクルで追加工数が発生
稟議書AI化の先行事例
| 銀行 | 技術パートナー | 効果 | 出典 |
|---|---|---|---|
| 京都銀行 | NTTデータ（LITRON Generative Assistant on finposs） | 審査役合格率30%→95%、年間最大11,700時間削減見込み | NTTデータ公式NR、日経新聞 |
| 宮崎銀行 | 日本IBM（Azure OpenAI Service） | 稟議書作成時間95%短縮、約2ヶ月で開発 | 日経新聞、日経クロステック |
| みずほFG | 自社開発 | 稟議作成時間を約10分に短縮 | みずほFG公式DXページ |
AI化のアプローチ｜4つのステップ
ステップ1：入力データの構造化
稟議書AIの精度は「入力データの質」で決まります。以下のデータを構造化された形式で準備します。
- 財務データ：直近3期分のBS/PL/CF計算書の主要項目（売上高、営業利益、経常利益、純利益、総資産、自己資本、有利子負債、営業CF）
- 融資条件：融資金額、金利（固定/変動）、期間、返済方法、資金使途、担保・保証の内容
- 取引先情報：業種、従業員数、設立年、主要取引先、経営者情報
- 面談メモ：RMが取得した定性情報（経営課題、事業計画、資金ニーズの背景）
ステップ2：プロンプト設計の考え方
稟議書AIのプロンプト設計では、以下の3層で構造化します。
第1層：役割の定義
「あなたは銀行の法人営業担当者（RM）として、審査部門に提出する融資稟議書のドラフトを作成するアシスタントです」のように、AIの役割を明確に定義します。
第2層：出力フォーマットの指定
稟議書の構成（案件概要→取引先概況→財務分析→融資条件の妥当性→回収見通し→リスク要因→結論）を具体的に指定します。各セクションで記載すべき内容と文字数の目安を定義します。
第3層：判断基準の提供
「財務分析では、自己資本比率が30%未満の場合はリスク要因として指摘する」「返済原資は営業CFを基本とし、設備投資を加味した実質FCFで評価する」のように、審査部門が重視する判断基準をプロンプトに組み込みます。
ステップ3：RAGによる品質向上
過去の優良稟議書（審査部門から高評価を得た稟議書）をRAG（検索拡張生成）システムに格納します。新規の稟議書作成時にLLMが「過去の類似案件ではどのような記述をしたか」を自動参照することで、ドラフトの品質を底上げします。
京都銀行の事例では、NTTデータのfinposs基盤上でRAG技術を活用し、高いセキュリティ基準を維持しながら稟議書の自動生成を実現しています（出典：NTTデータ公式NR）。
ステップ4：人間のレビューと最終判断
AIが生成したドラフトは必ずRMがレビューし、以下のポイントを確認します。
- 財務分析のコメントが取引先の実態と合っているか
- リスク要因の洗い出しに漏れがないか
- 定性情報（面談で得た情報）が適切に反映されているか
- 結論の論理展開が審査部門の観点で納得感があるか
他業種での類似事例
稟議書のような「構造化された文書のAI自動生成」は、他の業種でも同じフレームワークで実装できます。
| 業種 | 類似業務 | 共通点 |
|---|---|---|
| 保険 | 引受査定意見書 | リスク評価→条件設定→根拠の文書化 |
| 監査法人 | 監査調書 | 手続結果→検出事項→結論の構造化文書 |
| 製薬 | CTD（承認申請書類） | データ→分析→結論の規制文書 |
| 建設 | 技術提案書 | 技術的根拠→提案内容→期待効果の構成 |
導入ステップと注意点
導入の3フェーズ
- Phase 1（1〜2ヶ月）：パイロット導入。特定の支店・部署で試験運用し、AIドラフトの品質と業務フローの適合性を検証
- Phase 2（3〜6ヶ月）：改善と拡大。パイロットのフィードバックを反映しプロンプト・RAGを改善。対象支店を段階的に拡大
- Phase 3（6ヶ月〜）：全行展開。全支店への展開と、業務プロセスの定着化
注意点
- セキュリティ：融資稟議書には顧客の財務データが含まれるため、閉域環境でのAI利用が必須。京都銀行事例では高セキュリティ基準のfinposs基盤を採用
- ハルシネーション対策：AIが事実と異なる記述を生成するリスクに対し、入力データとの照合チェックを組み込む
- 審査部門の理解：AIドラフトの活用を審査部門にも共有し、「AIが書いた部分」と「RMが判断した部分」の区別を明確にする
汎用LLMで実現する｜renue視点
稟議書AI化の本質は、「ベテランRMの判断基準をプロンプトとして構造化し、LLMに移転すること」です。専用の稟議書AIツールを導入する方法もありますが、汎用LLMに「自行の稟議書の書き方」を教えるアプローチでも十分に実現可能です。
宮崎銀行の事例では、Azure OpenAI Serviceの汎用LLMと日本IBMのアセットを組み合わせ、約2ヶ月間で稟議書AIシステムを開発しています（出典：日経クロステック）。専用のAI製品を長期間かけて開発する必要はなく、汎用LLM+RAG+自行の稟議書データという組み合わせで、短期間に実用レベルのシステムを構築できることが実証されています。
重要なのは、「稟議書を書くAI」を作ることではなく、「審査に通る稟議書の構造と判断基準を言語化すること」です。この言語化ができれば、汎用LLMが実用レベルの稟議書ドラフトを生成できます。
まとめ
融資稟議書のAI化は、銀行業務のなかでも最もROIが高い施策の1つです。以下の3つの条件が揃っている業務だからです。
- 構造が標準化されている：稟議書の構成（案件概要→財務分析→リスク→結論）が定型化されており、プロンプト化しやすい
- データが構造化されている：入力となる財務データ、融資条件は数値データとして整理されている
- 効果が定量的に測定できる：作成時間、差し戻し率、合格率という明確なKPIで効果を計測可能
先行事例が示すように、京都銀行では合格率30%→95%（NTTデータ公式NR）、宮崎銀行では作成時間95%短縮（日経新聞）という具体的な成果が報告されています。まずはパイロット導入から始め、効果を検証しながら段階的に展開することが推奨されます。
