金融分野におけるAIの説明可能性と監査可能性

著者: Jane Ha · 更新日: 2026年10月11日

金融AIにおける説明可能性と監査可能性とは、2つの別々の約束を意味します。1つは、システムがある結果を出した理由を説明できること（説明可能性）、もう1つは、システムが何をしたのか、どの入力で、どのバージョンで、誰がレビューしたのかを後から証明できること（監査可能性）です。 規制当局、監査人、顧客は、それぞれ異なる側を重視します。与信を申し込んだ人は、否決の理由を知りたいと考えます。監査人は証拠の流れを求めます。モデルリスクチームは両方を求め、さらに独立した第三者がモデルに異議を唱えた証拠も求めます。

本記事は、与信、不正検知、予測、決算、報告の業務にAIを導入しているCFO、コントローラー、リスク責任者、財務マネージャー向けです。手法そのものの平易な定義が必要な方は、説明可能なAIとはをご覧ください。本記事では金融特有の部分、つまり何を、誰に対して説明しなければならないのか、そして何を保管しておく必要があるのかを扱います。

重要なポイント

• Regulation Bは、与信拒否の理由の通知は「具体的であり、主たる理由を示すものでなければならない」と定めており、社内基準や与信スコアリングのしきい値未達に基づく説明では不十分です（12 CFR 1002.9）。
• 2026年4月の関係当局共同のモデルリスクガイダンスSR 26-2は、SR 11-7に代わるものであり、総資産が300億ドルを超える銀行組織に最も関連が深いと見込まれています（Federal Reserve）。
• このガイダンスは生成AIモデルとエージェント型AIモデルを適用範囲の外に置いていますが、その原則は従来型の統計モデルと、生成型でもエージェント型でもないAIに適用されます（SR 26-2 attachment）。
• EU AI Actは、自然人の信用力を評価する、または信用スコアを設定することを目的としたAIシステムを高リスクに分類し、そうしたシステムには、稼働期間を通じてイベント（ログ）を自動的に記録できる技術的機能を求めています（Annex III、Article 12）。
• NISTは2つの概念を区別しています。説明可能性はシステムの動作の根底にある仕組みの表現であり、解釈可能性は設計された目的の文脈におけるその出力の意味です（NIST AI RMF 1.0）。

金融がAIに高い基準を求める理由

ほとんどの事業部門は、機能はするが理由を説明できないモデルでも許容できます。ところが財務では、たいていそうはいきません。理由は3つあります。

意思決定には法的義務が伴います。 貸し手が申込者を断る場合、米国の規則は具体的な理由を求めています。その理由は、一般的なラベルではなく、実際に決定を左右した要因を反映していなければなりません。

数字は、人々が頼りにする財務諸表に反映されます。 モデルが引当金を設定したり、増減分析の説明文を作成したり、元帳の項目を照合したりする場合、その数字がどう生まれたのかを監査人に示せなければなりません。その統制面はAIと内部統制で扱っています。本記事で扱うのはその下の層、つまり統制をテスト可能にする文書と記録です。

誤りは高くつき、見つけるのに時間がかかります。 予測のドリフトやバイアスのあるスコアリングモデルは、誰かが気づくまで何か月も動き続けることがあります。何が起きたのかを再構築する唯一の方法は、記録を残しておくことです。

規制当局と監査人が実際に期待していること

期待される内容は、法域やユースケースによって異なるため、分けて整理すると役立ちます。

与信判断（米国）。 平等信用機会法（Equal Credit Opportunity Act）を実施するRegulation Bは、貸し手に対し、断った申込者へ主たる理由を具体的な言葉で伝えることを求めています。この規則では、貸し手は完全な申込書を受領してから30日以内に、とった措置を申込者に通知しなければなりません（12 CFR 1002.9）。AIにとっての実務上の帰結は次のとおりです。責任を持てる理由をモデルが出せないのであれば、モデルの精度がどれほど高くてもコンプライアンス上の問題になります。事後的な説明ツールはモデルを再現するのではなく近似するものなので、その近似が忠実かどうかをチームが確認できなければなりません。

モデルリスク管理（米国の銀行）。 2011年のガイダンスSR 11-7はSR 26-2に置き換えられました。SR 26-2はリスクベースのアプローチをとり、実効的なチャレンジとは、適切な専門性、十分な独立性、変更を実現させる立場を備えた人々が行う、客観的な専門家による批判的な分析であると述べています。また、実効的なモデル台帳には個別と全体の両方のレベルでモデルリスクを理解するのに十分な情報が含まれること、そして適切な文書化が効果的なモデルリスク管理を支えることも述べています（SR 26-2）。このガイダンスは生成AIとエージェント型AIを適用範囲から除外していますが、対象外のツールについては銀行自身のガバナンス慣行が統制の指針になるべきだとも述べています。小規模な金融機関や事業会社の財務チームであれば、これを規則集というより、実績のあるテンプレートとして扱ってください。

ベンダーのモデル。 同じガイダンスは、ベンダーがコードやデータを開示しない場合でも、ベンダーモデルの概念的な健全性、設計、開発データ、パフォーマンスを理解し、その結果を監視することが健全な実務に含まれると述べています（SR 26-2）。「ベンダーが精度は高いと言っている」というのは文書化ではありません。

EU。 自然人の信用スコアリングは、AI ActのAnnex IIIのもとで高リスクの用途にあたり、高リスクシステムには稼働期間を通じた自動ログ記録を技術的に可能にすることが求められます（Annex III、Article 12）。この法律のスケジュールは改正されており、現在の統合版テキストでは、Annex IIIのシステムの適用日は2027年12月2日とされています（Article 12）。それぞれの状況での扱いは法務チームが確認すべきですが、エンジニアリング上の教訓はどちらでも同じです。後から組み込むほうが難しいので、ログ記録は今のうちに構築してください。

財務報告の監査人。 外部監査人が求めているのは、モデルの内部構造そのものではありません。AIの処理が、文書化されたプロセスの中の既知で担当者のいる部分であること、そして誰かが出力を確認した証拠があることを知りたいのです。

職種別に見る、「説明された」とは実際に何を意味するか

「説明可能」は1つのものではありません。適切な説明は、誰が尋ねているのか、何がかかっているのかによって変わります。

この表に共通するパターンは同じです。説明はドライバーと根拠に関するものであり、監査可能性は記録に関するものです。モデルはどちらか一方だけを備えることもあります。単純なルールベースのスコアラーは説明しやすくても、何も記録しなければ監査人には役に立ちません。

説明手法の道具箱と、その限界

複雑なモデルでは、2つの手法がたびたび登場します。SHAPは「特定の予測に対して、各特徴量に重要度の値を割り当てます」（Lundberg and Lee）。LIMEは、予測の近傍に単純で解釈可能なモデルを当てはめることで個々の予測を説明し、元のモデルをブラックボックスとして扱います（Ribeiro et al.）。

どちらも「なぜこの結果になったのか」という問いには役立ちます。ただし、ガバナンスの代わりにはなりません。理由は3つあります。

• 説明するのは予測であり、モデルの適合性ではありません。 バイアスのあるスコアを明快に説明できたとしても、バイアスのあるスコアであることに変わりはありません。
• 近似にすぎません。 出力はモデルの実際の推論ではなく、検証すべき証拠として扱ってください。
• それだけでは、顧客に出せる理由は作れません。 要因の寄与度を、通知に正確に記載できる主たる理由に対応づける作業が必要です。

重要度の高い意思決定では、より単純なモデルでも精度がほとんど落ちないかどうかを試す価値があります。直接中身を確認できるモデルのほうが、近似しなければならないモデルより擁護しやすいからです。

通用する文書化：モデルカードと台帳

モデルカードは、モデルに付随する短い文書です。最初の提案では、カードを、さまざまな条件下でのベンチマーク性能、想定される利用の文脈、評価の実施方法を記した文書と説明しており、利用者がそのモデルの有効な場面と無効な場面を把握できるようにするものです（Mitchell et al.）。著者らは視覚と言語に焦点を当てつつ、この考え方は学習済みのあらゆるモデルに当てはまると述べています。財務チームにとって、この考え方はそのまま移植できます。一般的な形式についてはAIモデルカードをご覧ください。

金融版には、次のような項目を含められます。

1. 目的と責任者。 どの意思決定やプロセスを支えるのか、そして事業側の責任者の氏名。
2. 想定する用途と対象外の用途。 たとえば「個人向け無担保ローンの申込を採点します。中小企業向け融資には使いません」。
3. データ。 学習に使った出典、期間、既知の欠落、適用した除外条件。
4. 手法の1段落での説明。 モデルの種類、主な特徴量、出力が意思決定にどう変換されるか。
5. パフォーマンス。 精度の指標、許容範囲、セグメント別の結果、実績に対するバックテスト。
6. 説明の手法。 理由やドライバーをどう生成するか、そしてそれがどの程度忠実であると示されたか。
7. 限界と既知の失敗モード。 弱い部分と、手作業での対応に切り替わる条件。
8. 統制。 レビュー担当者、しきい値、停止時の代替手段、変更履歴。
9. 検証。 誰が、いつ異議を唱え、何が見つかったか。

カードと併せて台帳も用意してください。使用中のすべてのモデルとAIツールを、責任者、目的、階層、カードの保管場所とともに1つにまとめた一覧です。SR 26-2自体も、実効的な台帳にはモデルリスクを理解するのに十分な情報が含まれると述べており、自社の台帳に当てはめるべき基準はそれです。ベンダーのツールでは、カードの一部が空になります。空欄のままにせず、そのことを記録したうえで、そのギャップがリスクに照らして許容できるかを判断してください。

監査証跡：実際に起きたことの記録

文書は、システムが何をするはずなのかを示します。監査証跡は、ある日に実際に何をしたのかを示します。EU規則のログ記録の原則は、一般的な基準としても優れています。システムの稼働期間を通じてイベントを記録し、監視と調査を支えられる形にするというものです（Article 12）。AIがシステム内で操作を実行する場合の証跡については、AIの実行アクションに対する監査証跡でさらに詳しく扱っています。

実用的な財務の監査証跡では、AIが影響を与えた重要な項目ごとに、次の内容を記録します。

• 入力： システムが受け取ったデータや文書、またはそれへのポインタ
• バージョン： そのときに有効だったモデル、プロンプトまたはルールセット、設定
• 出力： 生成されたスコア、仕訳、フラグ、テキスト
• 説明： 出力と併せて生成されたドライバーや理由
• 人の対応： 誰がレビューし、何を変更または上書きし、いつ行ったか
• 後続の結果： その後に続いた決定、転記、通知

保管期間は、それが支える記録に合わせてください。与信ファイル、仕訳の裏づけ資料、監査調書を何年保管しなければならないかを記録管理部門と法務部門に確認し、AIのログがそれより早く削除されないようにします。これらのログのデータの扱いは別のテーマであり、AI財務データのセキュリティで扱っています。

説明可能性と監査可能性をステップごとに構築する方法

1. 財務で使うすべてのモデルとAIツールを棚卸しします。 既存システムの中で有効化されているベンダー機能も含めてください。見つけていないものは文書化できません。

   

2. 影響の大きさで階層分けします。 顧客の与信結果や引当金を決めるモデルは、社内向けの要約を下書きするツールよりも厳格な階層に属します。

3. 階層ごとに説明の要件を定めます。 誰が、どれだけ速く、どのような形式（顧客への通知、アナリスト向けの画面、監査人向けの調書）で説明を得られなければならないかを明記します。

4. 要件を念頭にモデルを選びます。 最上位の階層の用途では、ブラックボックスを受け入れる前に、より透明なモデルがほぼ同等の精度を出せるかを試します。

5. 本番稼働の前にモデルカードを書きます。 稼働承認の条件を、完成したカードと名前の挙がった責任者にします。

6. 独立したチャレンジを受けます。 適切な専門性と独立性を持つ人が、モデルとその説明手法をレビューし、変更を求められるようにします。

7. 初日からログ記録をオンにします。 入力、バージョン、出力、説明、人の対応を記録します。1件の意思決定をログだけで最初から最後まで再構築できるかをテストしてください。

8. 再構築の演習を実施します。 過去の意思決定を無作為に10件選び、構築チームの外にいる人に、記録だけを頼りにそれぞれを説明してもらいます。抜けはすぐに見つかります。

9. 監視し、文書を更新します。 精度、ドリフト、上書き率を追跡します。モデル、データ、用途が変わったらカードを更新し、改めてチャレンジを受けます。監視のヒントは財務におけるAIの精度管理をご覧ください。

よくある落とし穴

• モデルは説明しても、意思決定は説明していません。 全体の特徴量重要度では、なぜこの申込者が否決されたのか、なぜこの仕訳がフラグされたのかは分かりません。
• 一般的な理由です。 実際のドライバーが別のものであるのに、最も近いチェックリストの理由を送ると、Regulation Bの具体性の要件を満たしません。
• 説明ツールを盲信しています。 事後的な手法は挙動を近似するものです。既知のケースに対してテストしてください。
• モデルカードが一度きりのPDFです。 モデルが変わってもカードが変わらなければ、虚偽の記録になります。
• バージョンのないログです。 どのモデルやプロンプトが出したのかが分からなければ、出力が何だったかを知っていても役に立ちません。
• ベンダーの不透明さを既定で受け入れています。 「独自仕様」は、成果をより厳しく監視する理由であり、文書化を省略する理由ではありません。
• 証拠のないレビューです。 承認はしても、何を確認したかの記録を残さないレビュー担当者では、監査人がテストできるものが何もありません。
• 説明可能性を稼働後に作っています。 ログと文書を後から組み込むには、最初から設計に盛り込むよりずっと大きなコストがかかります。

測定すべき指標

• カバレッジ： 責任者、階層、最新のカードを備えたモデルとAIツールの割合
• 再構築率： ログだけで完全に説明できる、抽出した意思決定の割合
• 説明の品質： レビュー担当者や検証者が、生成された理由を不正確または曖昧だとして却下する頻度
• 上書き率： 人が出力を変更する頻度と、その理由
• 鮮度： 各カードと検証が最後に更新されてからの経過時間を、変更履歴と照らして確認したもの
• 指摘事項の解消： 検証と監査の指摘事項を解決するまでの時間

次に読む記事

まず台帳の作成と階層分けから始め、最上位の階層のカードを書いて、再構築の演習を1回実施してください。AIをどこに適用できるかをまだ整理している段階であれば、金融・会計におけるAIがより広い視点を提供します。