この記事で分かること
- 「説明できる状態」は1種類ではなく、顧客・監督当局/監査・社内(審査部と営業)の3層で必要な粒度がまったく違うこと
- 審査フローのどこで主要因を抽出し、どこで人が判断し、何を記録に残せば「なぜ否決したか」を後から再現できるのか
- そのまま使える説明責任チェックリスト16項目と審査記録の様式案、仮設案件での記入例(整数の設例で検算済み)
- 学習データの偏り・代理変数・セグメント間の偏り・データの陳腐化という4つのバイアス点検項目と、法務・コンプライアンス部門への確認の出し方
結論:説明できる状態とは「相手ごとに粒度を変えた説明の材料が、記録として残っている状態」です
与信審査にAIやスコアリングモデルを組み込むと、必ず「なぜこの申込は否決なのか」を問われる場面が来ます。問うのは顧客だけではありません。監督当局、内部監査・外部監査、そして社内の営業担当や審査部も、それぞれ別の理由で同じ質問をします。ここで失敗が起きるのは、多くの場合1種類の説明ですべての相手に対応しようとするときです。顧客にモデルの変数重要度を並べても納得は得られませんし、監査人に「取引年数が長いので加点しました」という個別案件の話だけをしても、モデルの妥当性を説明したことにはなりません。
本記事の立場は明快です。説明可能AI(XAI)とは技術の名前である前に、運用設計の問題です。「顧客への説明」「監督当局・監査への説明」「社内への説明」の3層に分け、それぞれ何を・どこまで・どの資料で説明するかをあらかじめ決めておく。そして、個別案件ごとにその材料(主要因・人の判断・最終結論・説明文)が記録として残る様式を作る。これが「説明できる状態」の実体です。
もう一つ、運用上の重要な帰結を先に置きます。モデルは複雑にするほど精度が上がる可能性がありますが、同時に説明が難しくなります。この二者択一に対する本記事の答えは、「個別案件の主要因を出せないモデルは、審査の最終判断に使わない」です。使うとしても、否決に直結しない優先順位づけやスクリーニングまでに限定します。なお、審査担当者や監査人の判断そのものをAIが代替するという前提は取りません。AIが出すのは判断材料であり、責任を負うのは人と組織です。
関連記事との役割分担
この分野は隣接記事が多いため、先に線を引いておきます。稟議書ドラフトの作り方と「審査判断はAIに委ねない」という線引き自体は与信審査・融資稟議での生成AI活用で、AIに入れてよい情報の区分と社内規程の作り方は「生成AIに入れてよい情報・いけない情報」の記事で、機械学習の過学習やデータリークといった基礎はファイナンスのための機械学習入門で扱っています。本記事はそれらを前提に、「説明できる状態を実際にどう作り、どう記録し、どう点検するか」という実装・運用の部分だけを扱います。信用リスクの指標そのもの(PD・LGD・EAD)についてはクレジットリスク分析入門を、5CやDSCRといった審査の基本枠組みについては信用分析・融資審査の基礎をご参照ください。
全体像:XAIを組み込んだ審査フロー
説明可能性は「モデルを作った後に足す機能」ではなく、フローの一部として最初から組み込む必要があります。実際の流れは次の6段階です。
この図で重要なのは、③の主要因抽出が④の人の判断より前にあることです。順序が逆になると、人が結論を出した後にモデルの数字を「後付けの根拠」として使うことになり、記録の意味が失われます。また⑥から⑦への破線は、個別案件の記録がそのままモデル監視のデータになることを示しています。オーバーライド(人がモデルと異なる判断をすること)の件数と理由が集計できていれば、モデルが実務とずれ始めた兆候を早く捉えられます。
説明の3層:相手が変われば必要な粒度が変わります
本記事の核となる整理です。「説明責任を果たす」という言葉は便利ですが、実務に落とすときは相手を分けないと機能しません。3層に分けると、それぞれ目的も、開示すべき情報の深さも、担い手も違うことが見えてきます。
この3層を分けると、実務でありがちな2つの事故が防げます。1つは顧客への説明が過剰になる事故です。スコアの計算式や変数の重み付けをそのまま伝えると、申込者側が数値を調整して通過を狙う余地を作ってしまいます。顧客に伝えるのは「決算書に載っている事実と、その事実が結論にどう効いたか」までにとどめ、内部のロジックは開示しないのが実務的な線です。もう1つは当局・監査への説明が個別案件の話に矮小化される事故です。「この案件はこう判断しました」を100件並べても、モデルの設計思想・検証・ガバナンスの説明にはなりません。
3層目の社内向け説明は見落とされがちですが、実は最も運用を左右します。営業担当がモデルの効きどころを理解していないと、顧客への説明が「システムがそう出したので」になり、第1層の説明が崩れるからです。クレジットアナリストの役割は、モデルの出力を鵜呑みにすることでも無視することでもなく、モデルが見ていない情報(受注環境、経営者の交代、取引先の集中度など)を持ち込んで結論を組み立てることにあります。
AIに任せる部分と人が判断する部分
工程ごとに線を引くと次のようになります。ここでの原則は「計算と抽出はAI、意味づけと決定は人」です。
| 工程 | AI・システムに任せる | 人が判断する | 記録に残すもの |
|---|---|---|---|
| 入力データの整備 | 決算値の転記、指標の自動計算、欠損の検出 | どの決算期を使うか、決算後の重要事象を反映するか | データ基準日、出所、欠損の処理方法 |
| スコア算出 | スコアと判定区分の出力 | そのモデルを当該案件に適用してよいか(適用範囲の確認) | モデル名・版数・実行日時・スコア |
| 主要因の抽出 | 基準点からの寄与が大きい変数の上位抽出 | 抽出結果が実態と整合するかの確認、説明に使う3つの選定 | 寄与の一覧と、説明に採用した3項目 |
| 追加確認 | 追加で確認すべき項目の候補列挙 | 誰に何を確認するか、確認結果をどう評価するか | 確認事項、確認先、回答内容 |
| 最終判断 | (担当しない) | 可決・減額・否決の決定、条件の設定、例外承認 | 結論、モデル結果との一致/不一致とその理由 |
| 説明文の作成 | 雛形に沿った文面の下書き | 数値の正確性、表現の妥当性、開示範囲の確認 | 顧客に渡した文面(確定版) |
この線引きを規程に落とすとき、AIエージェントのように複数工程を自動で連結する仕組みを使う場合ほど注意が必要です。工程がつながると、どこで人が確認したのかが記録から消えやすくなります。自動連結する範囲は「入力整備〜主要因抽出」までに限定し、その先には必ず人の確認ステップを物理的に挟む設計にしてください。
主要因をどう出すか:仮設案件で通してみる
ここからは架空の設例で具体化します。湾岸みらい信用金庫(架空の金融機関)が、株式会社トヨサキ精密(架空の金属加工業、年商600百万円)から運転資金60百万円の申込を受けた場面とします。単位はすべて百万円です。
| 項目 | 前期 | 直近期 | 今回申込を反映後 |
|---|---|---|---|
| 売上高 | 600 | 600 | — |
| 営業利益 | 24 | 12 | — |
| 減価償却費 | 18 | 18 | — |
| 簡易キャッシュフロー(営業利益+減価償却費) | 42 | 30 | 30 |
| 有利子負債 | 210 | 240 | 300 |
| 簡易的な返済年数(有利子負債÷簡易CF) | 5.0年 | 8.0年 | 10.0年 |
検算しておきます。前期は210÷42=5.0年、直近期は240÷30=8.0年、今回申込60を加えると300÷30=10.0年です。売上高は横ばいですが、営業利益が24から12へ半減(△12、△50%)したため、簡易キャッシュフローが42から30へ下がったことが効いています。
この金融機関のスコアリングモデルは、全申込の基準点70点から加減点する方式(100点満点、否決ラインは60点)という仮設の設計だとします。抽出された主要因は次の3つです。
| 順位 | 主要因(変数) | 当該案件の値 | スコアへの寄与 |
|---|---|---|---|
| 基準 | 全申込の基準点 | — | 70 |
| 1 | 簡易的な返済年数 | 5.0年 → 10.0年(申込反映後) | △12 |
| 2 | 営業利益の前期比 | 24 → 12(△50%) | △9 |
| 3 | 取引年数・延滞履歴 | 取引18年・延滞なし | +3 |
| 合計 | モデルスコア | 否決ライン60点 | 52 |
検算:70-12-9+3=52点。否決ライン60点を8点下回ります。ここで反実仮想(もし〜だったら)を1本だけ計算しておくのが実務上有効です。申込額を60から30に減らすと有利子負債は270となり、270÷30=9.0年。返済年数の寄与が△12から△9へ改善し、スコアは70-9-9+3=55点になります。それでも60点には届きません。この計算をしておくと、顧客に「減額すれば通る」という誤った期待を持たせずに、何が足りないのかを具体的に伝えられます。
ただし注意点があります。この寄与度は「モデルの中でその変数がどれだけ効いたか」を示すものであって、因果関係を示すものではありません。「返済年数が延びたから業績が悪い」のではなく、「業績が落ちた結果として返済年数が延びている」というのが実態です。説明文を書くときは、寄与の大きさを因果の強さとして語らないよう注意してください。
精度と説明可能性のトレードオフ:どこで線を引くか
変数を増やし、非線形の関係や変数間の相互作用を取り込むほど、モデルの予測精度は上がる可能性があります。一方で、個別案件について「どの変数がどう効いたか」を安定して示すことは難しくなります。ここに実務上のジレンマがあります。
本記事が勧める整理は、モデルの用途を3区分に分け、説明可能性の要件を用途ごとに変えるやり方です。
| 区分 | 用途 | 説明可能性の要件 | 顧客の不利益への直結 |
|---|---|---|---|
| A | 審査の最終判断の主要な根拠として使う | 個別案件の主要因を出力でき、再現でき、検証記録がある。これを満たさないモデルは使わない | 直結する |
| B | 参考情報として人の判断に添える | モデル全体の挙動(どの変数が効きやすいか)は説明でき、限界が文書化されている | 間接的 |
| C | 審査の優先順位づけ・事前スクリーニング | 個別の主要因は出せなくてもよいが、否決に直結させない運用が前提 | しない設計にする |
この整理の眼目は「複雑なモデルを使うな」ではなく、用途と説明可能性の要件をセットで決めることです。区分Cで使っていた高精度モデルを、成果が良いからといって現場判断で区分Aに格上げしてしまう——これが最も起きやすい逸脱です。用途の変更は必ずモデル承認の手続を通す、と規程に書いてください。
なお、説明可能性を確保する手段は「もともと構造が単純なモデルを使う」ものと「複雑なモデルに後付けで説明手法を組み合わせる」ものに大別されます。後者を採る場合、説明のために使う手法自体が近似であり、モデルの実際の挙動と完全には一致しない点を文書に明記しておく必要があります。「説明手法の出力=モデルの真の理由」と扱ってしまうと、当局や監査に対する説明が成り立ちません。
バイアス点検:何を、どの手順で点検するか
モデルが特定の属性の申込者に対して不利に働いていないかの点検は、説明責任の一部です。ここでは点検の観点を4つに分けます。
実務上とくに厄介なのが②代理変数です。ある属性を入力変数から外しても、その属性と強く相関する別の変数が残っていれば、結果として同じ影響が残ります。郵便番号、取引開始経路、取引店舗、法人の設立年数などは、意図せず何かの代わりになっていることがあります。点検の手順としては、除外すると決めた属性を「答え合わせ用のデータ」として別途保持し、モデルの入力変数との相関を測る、という方法が取られます。
ここで強調しておきたいのは、この点検の結果が法的にどう評価されるかを、モデル所管部や審査部だけで判断してはいけないということです。数値を出し、どの変数がどのセグメントに効いているかを可視化するところまでがモデル所管部の役割です。それが差別的な取扱いに当たらないか、金融機関としての説明が成り立つかは、法務・コンプライアンス部門に資料を提示して確認を仰ぐべき事項です。本記事も法解釈は行いません。与信管理の規程にこの確認プロセスを組み込み、確認の依頼内容と回答を記録に残してください。
実務成果物①:説明責任チェックリスト(16項目)
モデルを審査に組み込む前と、定期検証のたびに使うチェックリストです。「はい」と言えない項目が残っている状態で区分A(最終判断の主要な根拠)の運用に進まない、という使い方をします。
| No. | 確認項目 | 証跡となる資料 |
|---|---|---|
| 1 | モデルの目的と適用範囲(対象商品・金額帯・業種・使わない場面)が文書化されている | モデル文書 |
| 2 | モデルの位置づけ(区分A/B/C)が規程に明記され、変更には承認が必要とされている | 与信規程・モデル台帳 |
| 3 | 入力変数の一覧と、各変数を使う業務上の根拠が記録されている | 変数定義書 |
| 4 | 使用しないと決めた変数と、その除外理由が記録されている | 変数定義書・議事録 |
| 5 | 学習・検証に使ったデータの期間・件数・出所が特定できる | 開発報告書 |
| 6 | 開発時の検証(精度・安定性・セグメント別の挙動)の記録がある | 検証報告書 |
| 7 | 稼働後のモニタリング指標と頻度が定義され、実績が残っている | モニタリング報告 |
| 8 | 個別案件ごとに主要因(上位3つ程度)を出力し、保存できる | 審査記録票 |
| 9 | 同じ入力から同じ出力を再現できる(モデル版数・パラメータ・実行日時が記録されている) | 実行ログ・モデル台帳 |
| 10 | モデルの変更履歴(いつ・誰が・何を・なぜ)が残っている | 変更管理票 |
| 11 | 開発者・検証者・承認者の役割が分離され、承認記録が残っている | 承認記録 |
| 12 | 人がモデル結果と異なる判断をした件数と理由が集計されている | オーバーライド集計 |
| 13 | 顧客向け説明の雛形と禁止表現が用意され、審査部・法務の確認を経ている | 説明文雛形 |
| 14 | 異議申立て・再確認の受付方法と、社内の再確認手続が定められている | 事務手続 |
| 15 | バイアス点検の実施記録と、法務・コンプライアンス部門の確認結果が残っている | 点検記録・確認回答 |
| 16 | ベンダー提供モデルの場合、説明に必要な情報の提供範囲が契約で確保されている | 契約書・仕様書 |
16番は見落とされがちですが重要です。外部ベンダーのモデルを使う場合、「主要因を出力する機能が契約に含まれていない」「モデルの変更が通知されず版数が特定できない」といった事態が起きると、当局・監査への説明が組織として成り立たなくなります。導入時の要件定義に、モデルのバージョン管理と主要因出力を明示的に入れてください。
実務成果物②:審査記録の様式案
1件ごとに残す記録の様式です。先ほどのトヨサキ精密の設例で記入例を埋めています。
| 欄 | 記入すべき内容 | 記入例(仮設案件) |
|---|---|---|
| 案件ID/受付日 | 一意の識別子と受付日 | 2026-C-0417/2026年7月21日 |
| 申込内容 | 金額・資金使途・期間・担保保証の有無 | 60百万円/運転資金/5年/無担保・代表者保証あり |
| 使用データの基準日 | 決算期・入手日・追加資料の有無 | 2026年3月期決算(2026年6月受領)、月次試算表なし |
| 使用モデル | モデル名・版数・実行日時・用途区分 | 事業性スコアリング v3.2/2026年7月22日 10:14/区分B(参考情報) |
| モデルスコア/判定区分 | 点数と、モデル上の区分 | 52点(否決ライン60点未満) |
| 主要因(上位3つ) | 変数名・当該案件の値・寄与 | ①簡易返済年数 5.0→10.0年(△12)②営業利益 24→12百万円(△9)③取引18年・延滞なし(+3) |
| 人による追加確認 | 確認事項・確認先・回答 | 利益減少の要因を代表者へ照会。主要取引先の内製化による受注減との回答。受注残の資料は未提出 |
| 人の判断 | モデル結果と同じか異なるか、異なる場合の理由 | モデル結果と同方向。受注減が構造的である可能性が高く、追加与信は見送りと判断 |
| 最終結論 | 可決/減額/条件付/否決と条件 | 否決(資料追加の上での再検討は可) |
| 顧客への説明文 | 実際に交付した文面(確定版を添付) | 別紙のとおり(主な理由3点+次の相談事項3点を記載) |
| 異議申立ての案内 | 案内の有無・方法 | 案内済(書面に窓口と受付方法を記載) |
| 記録者/承認者/日時 | 氏名と日時(役割が分かるように) | 記録者:審査部担当/承認者:審査部長/2026年7月24日 |
| 保存年限 | 社内規程上の保存期間 | 規程に定める年限に従う |
この様式の要点は3つです。第一に「人の判断」欄をモデルスコア欄と分けていること。分けないと、後から見たときに人が何を考えたのかが消えます。第二に顧客に交付した文面そのものを保存すること。説明した内容と記録がずれていると、異議申立てを受けたときに説明の一貫性を示せません。第三に用途区分(A/B/C)を毎回記入すること。案件単位で「このモデルを参考情報として使った」ことが記録されていれば、当局・監査への説明も個別案件レベルで裏づけられます。
顧客への説明文を作る:プロンプト例と出力例
顧客向けの説明文は、雛形に沿って書けば生成AIの助けを借りることもできます。ただし実在の申込者の情報をそのまま入力しない前提で設計します。企業名・所在地・代表者名は記号に置き換え、決算数値も必要な項目だけを渡します。入力可否の判断は自社の規程に従ってください。
【役割】 あなたは日本の金融機関の審査部で、顧客向け通知文の文案を作成する担当者です。 【目的】 事業性融資の申込に対する審査結果を、申込者本人に対して分かりやすく通知する文面の下書きを作成する。 【入力資料】 ・審査結果:否決 ・主な理由(社内で確定済み。この3点以外は書かないこと) 理由1:簡易的な返済年数(有利子負債÷(営業利益+減価償却費))が、前期5.0年から、今回の申込を反映すると10.0年になる見込み 理由2:営業利益が前期24百万円から直近期12百万円へ減少(△50%) 理由3:取引年数18年・延滞履歴なしは評価要素だが、上記2点を補うには至らなかった ・今後の相談事項(この3点のみ) a)直近の月次試算表と受注残の資料の提出 b)申込金額の見直し(30百万円の場合、上記の返済年数は9.0年となる見込み) c)返済期間の設定および既存借入の組み替えの相談 ・異議申立て:受付窓口があることを案内する(窓口名は「<窓口名>」と記載) 【単位】 金額はすべて百万円。年数は小数第1位まで。 【出力形式】 ・日本語の敬体(です・ます)、書面としてそのまま使える体裁 ・全体で500〜700字 ・構成:①結果の通知 ②主な理由(3点を箇条書き)③今後のご相談事項(3点を箇条書き)④異議申立ての案内 ・見出しは付けない 【計算方法】 入力資料に記載された数値をそのまま使用する。新たな計算を行わない。 【禁止事項】 ・スコア、点数、モデル名、変数の重み、内部の判定基準を書かない ・「AIが判断しました」「システムが否決しました」といった表現を使わない ・入力資料にない数値・理由・約束(再申込すれば通る等)を書かない ・断定的な将来予測、経営に対する助言を書かない ・専門用語(デフォルト、スコアリング、与信枠 等)を使わない 【不明情報の処理】 入力資料に記載のない事項は「不明」と書き、推測で補わない。 【検算】 出力に含めた数値が入力資料の数値と一字一句一致しているか、出力の最後に「数値照合:一致/不一致」の形で自己申告する。 【レビュー項目】 出力の後に、作成者が確認すべき点を3つ箇条書きで挙げる。
出力例(抜粋)
上記プロンプトで得られる文面の骨子は、たとえば次のようなものです(設例に基づく仮の出力です)。
このたびは、ご融資のお申込みをいただき誠にありがとうございました。 慎重に検討いたしましたが、今回はご希望に沿いかねる結果となりましたので、ご連絡申し上げます。 主な理由は、次の3点です。 ・借入金の残高を、営業利益に減価償却費を加えた金額で割った年数が、前期の5.0年から、 今回のお申込みを反映すると10.0年となる見込みであること ・営業利益が、前期の24百万円から直近期の12百万円へ減少していること ・お取引年数18年、延滞のご履歴がないことは評価しておりますが、上記2点を補うには 至らなかったこと 今後、次の点についてご相談いただけましたら、あらためて検討させていただきます。 ・直近の月次試算表と受注残に関する資料のご提出 ・お申込金額の見直し(30百万円の場合、上記の年数は9.0年となる見込みです) ・ご返済期間の設定、および既存のお借入の組み替えについてのご相談 本件の結果についてご意見・ご質問がございましたら、<窓口名>にてお申し出ください。 数値照合:一致 【作成者が確認すべき点】 ・数値(5.0年/10.0年/24百万円/12百万円/9.0年/30百万円)が審査記録と一致しているか ・「見込み」という表現が、確定した約束と受け取られないか ・窓口名と受付方法が最新の事務手続と一致しているか
この下書きをそのまま送ってはいけません。数値の照合、表現の妥当性、開示範囲(内部基準に触れていないか)を人が確認してから交付します。AIを使った財務モデリングと同じく、生成物は下書きであって成果物ではありません。
日本の枠組み:どれが法律で、どれがガイドラインなのか
この分野は文書が多く、位置づけが混同されがちです。法律なのか、ガイドラインなのか、原則なのか、論点整理なのかを区別して読むことが実務では重要です。以下は2026年8月3日時点で確認した各文書の位置づけです。条文の解釈や個別事例への当てはめは行いません。
| 文書名 | 発行主体 | 位置づけ | 審査実務との関わり |
|---|---|---|---|
| 人工知能関連技術の研究開発及び活用の推進に関する法律(AI法) | 内閣府所管(議員立法) | 法律(2025年6月4日公布、2025年9月1日全面施行) | 基本理念、国・事業者の責務、人工知能基本計画の策定、人工知能戦略本部の設置を定める推進法。個別行為を禁止列挙する形式ではない |
| 人工知能基本計画 | 内閣府(閣議決定) | 政府の計画(2025年12月23日閣議決定) | AI法に基づく初の基本計画。開発力強化・ガバナンス・社会変革の3本柱。毎年見直す方針 |
| モデル・リスク管理に関する原則 | 金融庁 | 原則(プリンシプルベース)(2021年11月12日) | ガバナンス、モデルの特定・インベントリー管理、開発、承認、継続モニタリング、検証、ベンダー・モデルの活用、内部監査の8原則。原則本文では対象金融機関として本邦G-SIBs・D-SIBs等が挙げられている |
| AIディスカッションペーパー(第1.1版) | 金融庁 | 論点整理(規制ではない)(2026年3月3日) | 金融機関等のAI活用実態と健全な利活用に向けた初期的な論点整理。第1.1版でAIエージェントに関する章を新設 |
| AI事業者ガイドライン(第1.2版) | 総務省・経済産業省 | ガイドライン(2026年3月31日) | AI開発者・提供者・利用者の3層でリスクベースの指針を示す。分野横断の基礎文書 |
| 生成AIサービスの利用に関する注意喚起等について | 個人情報保護委員会 | 注意喚起(2023年6月2日) | 個人情報取扱事業者が生成AIサービスに個人情報を含むプロンプトを入力する場合、特定した利用目的の達成に必要な範囲内であることの十分な確認を求めている |
| 金融システムレポート別冊「金融機関における生成AIの利用状況とリスク管理」 | 日本銀行 | 調査レポート(初版2024年10月、更新版2025年9月) | 金融機関の生成AI利用実態とリスク管理体制に関する調査。規制文書ではない |
実務上の含意を2つだけ挙げます。1つ目は、「モデル・リスク管理に関する原則」は対象金融機関が限定されているという点です。原則本文には対象として本邦G-SIBs・D-SIBs等が挙げられています。したがって、対象外の金融機関がこの原則の枠組みを参照する場合は「適用義務として」ではなく「実務の設計を組み立てる際の参照枠として」用いるのが正確な理解です。自社への適用関係は、監督指針や自社の監督当局との関係を含めて、法務・コンプライアンス部門に確認してください。
2つ目は、日本のAI法はEUのAI Actのような個別行為の禁止列挙型ではないという点です。基本理念と体制整備を定める推進法であり、審査モデルの説明可能性について具体的な行為規範を直接に定めるものではありません。だからこそ、説明できる状態をどう作るかは各金融機関の設計問題として残ります。ガバナンス報告の枠組みに乗せて、誰がどこまで責任を持つのかを明文化しておくことが実務的な備えになります。
海外の制度を日本に持ち込まないこと
この分野では海外の議論がよく引用されます。米国には信用取引の拒否に関する通知(adverse action notice)を求める枠組みとして平等信用機会法(ECOA)や公正信用報告法(FCRA)があり、EUにはAIシステムをリスクに応じて規律するAI Actがあります。ただし、これらは海外の制度であり、日本に同じ制度がそのまま存在するわけではありません。海外拠点や海外顧客に関わる場合の適用関係は現地法の問題であり、本記事では立ち入りません。日本語の解説記事で「AIによる与信は理由の説明が義務づけられている」といった記述を見かけたときは、それがどの国のどの制度の話なのかを必ず確認してください。
説明可能性の検証方法
AI出力の検証一般(出典の実在確認、数値の転記、計算の再現、論理整合)については生成AI出力の検証手順で扱っています。ここでは説明可能性に固有の検証項目だけを挙げます。
- 主要因の再現性テスト:同一の入力データを時間をおいて2回投入し、出力される主要因の顔ぶれと順位が一致するか確認します。一致しない場合、その説明は顧客にも当局にも使えません。
- 符号の整合性テスト:スコアを下げた変数が「不利な要因」として、上げた変数が「有利な要因」として抽出されているか。符号が逆転している項目があれば、説明手法の設定か、変数の定義に問題があります。
- 反実仮想の実測:「もし営業利益が◯◯だったら」という説明を文面に含める場合、その値を実際にモデルへ入力し直し、主張どおりの結果になるかを確認します。設例では申込額30百万円のケースでスコア55点を実測し、「減額しても否決ラインには届かない」ことを確かめました。
- 説明文と記録の突合:顧客に交付した文面の数値・理由が、審査記録票の主要因欄と一致しているか。1件ずつではなく、月次で無作為抽出して照合します。
- セグメント別の挙動確認:地域・業種・企業規模の区分ごとに、抽出される主要因の分布が偏っていないか。特定セグメントで常に同じ変数しか出てこない場合、そのセグメントでモデルが実質的に機能していない可能性があります。
- オーバーライドの分析:人がモデル結果と異なる判断をした案件を集め、その理由が特定のパターンに集中していないか確認します。集中していれば、モデルが捉えていない要因がそこにあります。
機密情報・個人情報の注意
審査案件には、申込企業の非公開情報に加え、代表者個人や連帯保証人に関する情報が含まれます。個人情報保護委員会は2023年6月2日付の注意喚起で、個人情報取扱事業者が生成AIサービスに個人情報を含むプロンプトを入力する場合、特定した利用目的の達成に必要な範囲内であることを十分に確認するよう求めています。外部の生成AIサービスに審査案件の情報を入力する運用を検討する場合は、利用形態(学習利用の有無、データの保存先など)を含めて法務・コンプライアンス部門の確認を経てください。入力してよい情報の区分と社内ルールの作り方は生成AIの機密管理と社内ルールで詳しく扱っています。
よくある失敗
- 「AIが否決しました」と説明してしまう:最も多い失敗です。判断の主体は金融機関であり、モデルは判断材料です。この言い方をした時点で、説明責任の所在が不明確になります。顧客向け説明文の禁止表現として明文化しておきます。
- 主要因が毎回同じ変数ばかりになる:抽出される上位3つが全案件でほぼ同一だと、実質的に「説明していない」のと変わりません。セグメント別に主要因の分布を集計し、多様性を確認してください。
- 寄与度を因果として説明する:「返済年数が長いから業績が悪い」といった逆転した説明が文面に紛れ込むことがあります。寄与度はモデル内での効き方であり、現実の因果ではありません。
- モデルを差し替えたのに雛形と手引きが旧版のまま:モデル改訂時に、顧客向け説明文の雛形、審査部の手引き、モニタリング指標の定義を同時に更新する手順がないと、説明の内容と実際の挙動がずれます。変更管理票の必須確認項目に入れてください。
- 除外したはずの属性が代理変数として復活する:入力変数から外しただけでは不十分で、相関の高い変数を通じて影響が残ることがあります。点検を定期化し、結果を法務・コンプライアンス部門に共有する運用にします。
- 記録が「スコアと結論」だけ:人が何を確認し、なぜその結論にしたのかが残っていないと、数か月後に自分たちでも再現できません。追加確認の内容と回答まで記録する様式にしてください。
実務チェックリスト(運用開始前の確認)
説明責任チェックリスト(16項目)がモデルそのものの点検であるのに対し、こちらは運用体制が回るかの点検です。
- モデルの用途区分(A/B/C)が案件画面上で表示され、担当者が認識できるようになっている
- 主要因の抽出結果が、審査記録票に自動で転記される(手入力による転記ミスの余地がない)
- 顧客向け説明文の雛形に、禁止表現の一覧が併記されている
- 営業担当者に対し、モデルの効きどころと苦手分野を説明する研修が実施されている
- 「システムが否決した」と説明した事例が発生した場合の是正手順が定められている
- 異議申立ての受付窓口・受付方法が顧客向け書面に記載されている
- 異議申立てを受けた場合に、当初の判断者とは別の者が再確認する手続がある
- オーバーライドの件数・理由が月次で集計され、モデル所管部に共有されている
- モデル改訂時に、雛形・手引き・モニタリング定義を同時更新する手順が変更管理票にある
- バイアス点検の実施頻度(例:年1回および重大な改訂時)が規程に定められている
- 法務・コンプライアンス部門への確認依頼の様式と、回答の保存場所が決まっている
- ベンダー提供モデルの場合、版数変更の通知を受ける取り決めが契約に入っている
- 審査記録の保存年限と、保存媒体・アクセス権限が規程で定められている
よくある質問(FAQ)
Q. 説明手法を後付けすれば、複雑なモデルでも審査の最終判断に使えますか。
A. 「主要因が出力できる」ことと「その説明が安定して再現でき、当局・監査に対して設計思想と検証結果まで示せる」ことは別です。本記事では、個別案件の主要因を安定して出力できず、再現性と検証記録が揃わないモデルは、否決に直結する最終判断の主要な根拠には使わない(区分Cにとどめる)ことを勧めています。後付けの説明手法は近似であり、モデルの実際の挙動と完全には一致しない点も文書に明記してください。
Q. 顧客にはモデルの計算式まで説明する必要がありますか。
A. 本記事の整理では、顧客への説明に必要なのは「結論・主な理由・次に取るべき行動・異議申立ての窓口」までです。スコアの計算式や変数の重み付けを開示すると、数値を調整して通過を狙う余地を作ることになります。ただし、どこまで開示すべきかは商品性や自社の方針、当局との関係によって変わり得るため、開示範囲の決定は法務・コンプライアンス部門と協議のうえ規程化してください。
Q. 生成AI(LLM)に顧客向けの説明文を書かせても問題ありませんか。
A. 文面の下書きに使うこと自体は、入力する情報の範囲と確認手順を定めれば設計可能です。本記事のプロンプト例のように、社内で確定した理由と数値だけを渡し、新たな計算や推測を禁止し、人が数値照合と表現確認をしてから交付する運用にします。逆に、生成AIに「否決の理由を考えさせる」使い方は避けてください。理由はモデルの出力と人の判断から決まるものであり、文章生成モデルが作るものではありません。
まとめ
「なぜ否決したか」を説明できる状態は、高性能な説明手法を導入すれば手に入るものではありません。説明の相手を顧客・監督当局/監査・社内の3層に分け、それぞれ何をどこまでどの資料で説明するかを決め、案件ごとに主要因・人の判断・最終結論・説明文を記録に残す——この設計と記録の積み重ねが実体です。そして、個別案件の主要因を安定して出せないモデルは、否決に直結する最終判断の主要な根拠には使わない。この一線を規程に書き、用途の変更には承認を求める。それだけで、説明が破綻する場面の多くは防げます。
バイアス点検については、数値を出して可視化するところまでがモデル所管部の仕事であり、それが差別的な取扱いに当たらないかの評価は法務・コンプライアンス部門に確認を仰ぐ事項です。日本の枠組みは、法律(AI法)・ガイドライン(AI事業者ガイドライン)・原則(モデル・リスク管理に関する原則)・論点整理(AIディスカッションペーパー)・注意喚起(個人情報保護委員会)が層をなしており、それぞれ性格が異なります。自社への適用関係は文書の性格を区別したうえで、専門部署に確認してください。
出典・参考(2026-08-03確認)
- 金融庁「モデル・リスク管理に関する原則」(2021年11月12日)https://www.fsa.go.jp/common/law/ginkou/pdf_02.pdf /位置づけ:原則(プリンシプルベース)。8原則で構成。対象金融機関として本邦G-SIBs・D-SIBs等が挙げられている。
- 金融庁「AIディスカッションペーパー(第1.1版)金融機関等におけるAIの活用実態と健全な利活用の促進に向けた初期的な論点整理」(2026年3月3日)https://www.fsa.go.jp/news/r7/sonota/20260303/aidp.html /位置づけ:論点整理(規制文書ではない)。
- 金融庁「金融機関のモデル・リスク管理の高度化に向けたプログレスレポート(2024)」(2024年12月12日)https://www.fsa.go.jp/news/r6/ginkou/20241212/20241212.html /位置づけ:モニタリング結果の公表。
- 総務省・経済産業省「AI事業者ガイドライン(第1.2版)」(2026年3月31日)https://www.soumu.go.jp/main_sosiki/kenkyu/ai_network/02ryutsu20_04000019.html /位置づけ:ガイドライン。
- 内閣府「人工知能関連技術の研究開発及び活用の推進に関する法律(AI法)」(2025年6月4日公布、2025年9月1日全面施行)https://www8.cao.go.jp/cstp/ai/ai_act/ai_act.html /位置づけ:法律(推進法)。条文原文はe-Gov法令検索での確認を推奨。
- 内閣府「人工知能基本計画」(2025年12月23日閣議決定)https://www8.cao.go.jp/cstp/ai/ai_plan/ai_plan.html /位置づけ:政府の計画。
- 個人情報保護委員会「生成AIサービスの利用に関する注意喚起等について」(2023年6月2日)https://www.ppc.go.jp/news/careful_information/230602_AI_utilize_alert/ /位置づけ:注意喚起。
- 日本銀行「金融システムレポート別冊:金融機関における生成AIの利用状況とリスク管理」(初版2024年10月21日、更新版2025年9月30日)https://www.boj.or.jp/research/brp/fsr/fsrb241021.htm /位置づけ:調査レポート。
- ※米国のECOA・FCRA、EUのAI Actは海外の制度として言及したものであり、本記事では条文・適用範囲の詳細には立ち入っていません。適用関係は各法域の専門家にご確認ください。
※本記事は教育目的の一般的な解説であり、法務・税務・会計・投資に関する助言ではありません。実際の判断は専門家にご確認ください。設例は理解のための仮設例です。AI製品の仕様・料金は変更されることがあるため、利用前に各社の公式情報をご確認ください。