2026年のモデルリスク管理：改訂された官庁間ガイダンスに関するバンカー向けガイド

2026年4月MRMガイダンスの変更点

2026年4月17日、連邦準備制度理事会（FRB）、連邦預金保険公社（FDIC）、通貨監督庁（OCC）はSR 11-7、OCC 2011-12、FIL-22-2017および関連するBSA/AML発行物を廃止し、モデルリスク管理のための、より明確にリスクベースで原則主導のフレームワークに置き換えました。

これは狭い技術的アップデートではありません。モデルが銀行の意思決定の中心であり、モデルリスクは信用リスクや市場リスクと同じように真剣に管理されなければならないという、より広範な見方を反映しています。

銀行内の実務担当者にとっては、具体的な期待事項となります。インベントリは重要度別に階層化され、管理策は比例配分され、ライフサイクルはエンドツーエンドで防御可能であるべきです。

従来のスタックでは、その対応はスプリント作業の2〜3四半期分に相当します。インベントリ移行、検証テンプレートの書き直し、新しい監視パイプライン、ドキュメントの更新、ベンダーモデルのオンボーディング、そして現在監督当局が原則として範囲内と見なしているGenAIおよびエージェンティックシステムのための並列ワークストリーム。すべてのワークストリームはプロジェクトであり、変更チケットであり、監査上のリスクとなります。

本当の質問は「このガイダンスへの準拠をどう構築するか？」ではありません。それは「次のガイダンス変更、そしてその後の変更を、プログラムではなく設定作業にするプラットフォームの決定は何であるか？」ということです。

新しいMRMフレームワークが実際に要求すること

2026年の改訂は、管理策の書き直しというよりも、それらを適用する方法の再区分化です。実務担当者にとって重要な5つのシフトがあります。

1. リスクベースのテーラリング — すべてのモデルは、固有のリスク、エクスポージャー、および目的を反映したティアに配置される必要があります。ティア1の重要モデルは完全なライフサイクル監視を受けますが、下位ティアは比例配分された軽量な管理策で対応します。ただし、そのティアリング自体を証明できる場合に限ります。
2. ライフサイクル思考 — 開発、検証、デプロイ、監視、および廃止は、1つの管理されたチェーンです。監督当局は、ハンドオフポイントでのスナップショットではなく、すべてのリンクにわたる系統性を期待しています。
3. 効果的なチャレンジ — チャレンジャーモデル、結果分析、ベンチマーク、および感度テストは、バージョン管理され、再現可能である必要があります。単なる一時的なメモではありません。
4. 継続的な監視 — パフォーマンスのドリフト、データのドリフト、および安定性は継続的に追跡され、しきい値は重要度に合わせてマッピングされる必要があります。
5. 原則はAIにも拡張 — GenAIおよびエージェンティックシステムは正式には範囲外ですが、原則を継承します。監督当局および内部監査は、LLMベースの引受支援、AMLトリアージエージェント、および顧客対応コパイロットに、すでに類推によってMRMの期待を適用しています。

共通の糸：証拠は、モデルが構築された方法の副産物として生成されなければならず、事後的に再構築されるものではありません。それはプラットフォームの問題であり、ポリシーの問題ではありません。

私たちの取り組み

私たちは規制の意図を前提とします。ガイダンスについて議論するのではなく、それが示唆する運用モデルに焦点を当てます。

• 銀行は、リスク階層化、比例配分、および効果的なチャレンジを、手動ではなく、体系的にどのように行うことができるでしょうか？
• 優れたガバナンスの証拠は、日々のモデル作業から自動的にどのように生成できるでしょうか？
• 次のガイダンス更新を、数四半期にわたるプログラムから設定変更に変えるプラットフォームの決定とは何でしょうか？

この記事の残りの部分では、Databricks上のリファレンスアーキテクチャの概要を説明します。これは、MRMが排除しようとしている断片化を、ポイントソリューションのコレクションから信頼性高く構成できないため、単一の管理された基盤でそれらのニーズを満たすように設計されています。

私たちは、改訂されたMRMの期待を具体的なDatabricksの機能にマッピングし、銀行がLakehouse上でこれらの原則をどのように運用できるかを示します。

MRMのためのDatabricksリファレンスアーキテクチャ

以下のアーキテクチャは、「単一の系統グラフ」を単なるスローガン以上のものにします。すべてのライフサイクルステージは、Unity Catalog内の管理されたオブジェクトに解決されます。古典的なMLとGenAIには同じプリミティブが使用されるため、MRMチームは2つではなく1つのフレームワークを運用します。

4つのレイヤー、1つの基盤

アーキテクチャのアンカー

ガバナンスレイヤーは、最後に付け加えられるものではなく、他のすべてのレイヤーが書き込む対象です。だからこそ、ティアの変更は移行ではなくメタデータの更新となり、検査官は単一のシステムから単一の回答を得られるのです。

MLライフサイクルとMRM証拠のマッピング

各ライフサイクルステージは、新しいガイダンスが期待する特定の種類の証拠を生成します。Databricksアーキテクチャは、その証拠を通常の作業の構造化された副産物として扱います。最後のコンプライアンスパスとして別途行うものではありません。

個々の機能はポイントツールから組み立てることができます。アーキテクチャ上のポイントは、Databricks上ではそれらが1つのリネージグラフであるということです。「どのデータでこのモデルをトレーニングしたのか、誰が検証したのか、どのようにドリフトしたのか、そしてどの本番の意思決定で使われたのか？」という問いは、チーム横断的な証拠収集作業ではなく、単一のトラバーサルで回答できます。

主要なガバナンスパターン

5.1 メタデータとしての重要度階層化、移行ではなく

レジストリ内のすべてのモデルには、重要度階層、事業部門、ガイダンスバージョン、担当検証者、最終検証日などの構造化されたタグが付与されています。これらのタグは装飾ではなく、アクセスポリシー、監視しきい値、ポートフォリオレベルのMRMダッシュボードによって読み取られます。

監督者が重要度定義を更新したり、内部ポリシーが更新されたりすると、階層が変更されます。このアーキテクチャでは、階層の変更はタグの更新であり、数分で適用され、すべての下流コントロールに可視化されます。再プラットフォーム化、パイプラインの書き直し、ドキュメントの再作成は不要です。

5.2 ABACによる比例原則の強制

比例原則はガイダンスの中心的な原則であり、歴史的に証明が最も困難でした。Databricks上では、これは階層タグに紐づいた属性ベースのアクセスルールになります。

実際には、これはUnity Catalogオブジェクトに対する単純なABACポリシーのように見えます。例えば：

• Tier-1重要モデル：本番環境への昇格には、独立したMRM検証者グループからの承認が必要です。二重管理が強制され、推奨されるだけではありません。

• Tier-2標準モデル：チームリーダーと検証者で昇格できます。監視は軽くなりますが、監査は可能です。

• Tier-3低重要度モデル：モデルオーナーが自身のワークスペース内で昇格できます。監視しきい値は緩く、ドキュメント要件は軽減されます。

銀行は、比例原則がどのように機能するかを説明するポリシー文書を必要としません。アクセス制御ログが、すべてのモデル、すべての昇格について、監査保持期間が続く限り、それを説明します。

実際には、これはUnity Catalogオブジェクトに対するABACポリシーロジックに直接変換されます：

IF model.tier = 'Tier1'

THEN require_approver_role IN ('MRM_Validator', 'Model_Risk_Committee')

AND require_dual_control = TRUE

同じ階層タグは、モデルごとのカスタムコードなしで、より厳格な監視しきい値や短い検証サイクルを駆動することもできます。銀行は比例原則を説明するための別のポリシー文書を必要としません。アクセス制御ログと設定が、モデルごと、昇格ごとにそれを実証します。

5.3 情報アーキテクチャとしてのMRMカタログ

クリーンなカタログ階層は、最も過小評価されているガバナンス上の決定です。実用的なパターンは、インベントリと証拠をモデル自体から分離します：

• インベントリカタログ — モデルメタデータ、検証者の承認、インベントリオーバーレイ、検証者キューテーブルを保持します。

このカタログの主要なテーブルは単純なパターンに従います：

• models.inventory — モデルバージョンごとに1行。tier、owner、guidance_version、intended_use、dependent_processesなどのフィールドがあります。

• models.validation_log — 検証イベントごとに1行。model_version_idでキー化され、validator_id、validation_scope、issues_found、residual_risk_ratingが含まれます。

• クラシックMLカタログ — クレジット、AML、不正、資本モデルなどのビジネスラインごとのスキーマ。

• GenAIカタログ — LLMエンドポイントとエージェント。ファーストクラスモデルとして登録され、ツールレジストリを備えています。

• 監視カタログ — Lakehouse Monitoringによって生成されたドリフト、パフォーマンス、公平性メトリックテーブル。

• 証拠カタログ — チャレンジャー実行、検証成果物、モデルカード、廃止モデルアーカイブ。

この分離により、MRMリーダーシップは、トレーニングデータへのアクセスを公開することなく、証拠と監視への読み取り専用アクセスを付与できます。これは、試験準備における一般的な難点です。

クラシックMLとGenAIを1つのフレームワークで

銀行は両方を同時に実行しています。数十年のMRM実践によって管理されているPDモデルと、まだ誰もガバナンス方法を確立していないLLMベースのAMLトリアージアシスタントです。従来の考え方は、2番目のモデルタイプのために2番目のフレームワークを構築することです。それはコストを2倍にし、監査サーフェスを2倍にし、乖離を保証します。

Databricks上では、クラシックMLとGenAIは同じレジストリ、同じライフサイクルステージ、同じ証拠パターンを共有します。モデルタイプが要求するレイヤー固有の機能も備えています。

監督者がMRM原則をGenAIに拡張する場合（既に行われています）、私たちは2番目のフレームワークを立ち上げるのではなく、最初のフレームワークを適用します。

3つの構成要素、1つのプラットフォーム

データサイエンティスト & モデル開発者 — 手抜きなしの速度

• トレーシング、リネージ、特徴量登録が自動で行われる、管理されたノートブック環境で作業します。コンプライアンスチェックボックスを後から追加するのではなく。

• AutoMLとAgent Bricksを使用して、ベースラインとエージェントパターンを迅速に反復処理します。すべての反復は記録され、再現可能です。

• プロモーション、監視、ドキュメントが同じワークフローに組み込まれているため、より迅速に出荷できます。別チームへの引き継ぎではありません。

MRM & 独立検証者 — 完全なコンテキストでのレビュー

• モデルを生成した正確なトレーニングデータ、特徴量バージョン、コードへの読み取り専用アクセス。データコピーや陳腐化はありません。

• チャレンジャーおよびベンチマーク実行はチャンピオンとバージョン管理され、感度分析はオンデマンドで再現可能です。

• 署名はレジストリ内のファーストクラスの成果物であり、モデルバージョンに紐づいています。メールスレッドに添付されたメモではありません。

• Databricks Appsは、キュー、コメント、署名、エスカレーションなどの構造化されたレビューワークフローを提供します。すべて監査可能です。

リスク & コンプライアンスリーダーシップ — ポートフォリオ規模での防御可能な監視

• インベントリ全体の単一ダッシュボード：階層分布、検証ステータス、監視健全性、未解決の問題。5つのGRCエクスポートを貼り合わせたものではありません。

• ABACポリシーによって強制される階層と所有権。比例性はポリシー文書ではなく、監査ログを備えたアクセスルールです。

• サードパーティおよびGenAIモデルは、内部モデルと同じ方法で登録されます。カバレッジのギャップは、審査官が見つける前に可視化されます。

審査官のRFI、エンドツーエンド

監督レビューからの代表的な質問を考えてみましょう。「信用PDモデルの過去12か月間の検証証拠、本番パフォーマンス、およびドリフト履歴を、ビジネスライン別にスライスして提示してください。」

断片化されたスタックでは、これはレジストリ、データレイク、BIツール、およびGRCシステム全体にわたる2週間の証拠収集作業です。それぞれが独自のIDモデルとデータの鮮度を持っています。Databricks参照アーキテクチャでは次のようになります。

• 検証証拠はインベントリカタログにあり、モデルバージョンに関連付けられています。

• 本番パフォーマンスとドリフト履歴は、Lakehouse Monitoringによって継続的に書き込まれるモニタリングカタログにあります。

• ビジネスラインはモデルのタグであり、モニターのスライス次元です。

• MRMカタログ上のGenieスペースが、行レベルのアクセスフィルターにより審査官が権限のあるものしか見られないようにしながら、自然言語で質問に答えます。

所要時間は数週間から数時間に短縮されます。さらに重要なのは、証拠が銀行自身のMRMチームが使用するものと同じであるため、銀行が内部で報告するものと審査官に示すものの間に矛盾がないことです。

Databricksを採用する理由 — 銀行側の5つの理由

1. ポリシー変更はメタデータ変更になる — マテリアリティ定義、ティアしきい値、またはバリデーターの役割が変更された場合、Unity Catalogのタグとアクセスポリシーが更新されます。再プラットフォーム化、パイプラインの書き直し、ドキュメントの更新は不要です。
2. 7つではなく1つの監査証跡 — データ、特徴量、モデル、モニタリング、ドキュメントは1つの基盤上にあります。審査官の質問は、データウェアハウス、特徴量ストア、レジストリ、BIツール、GRCプラットフォームを横断するのではなく、1つのシステムでエンドツーエンドで追跡されます。
3. 比例性は強制可能 — Tier-1モデルには厳格な管理が、Tier-3モデルには軽量な管理が行われます。どちらも同じABACポリシーによって強制されます。比例性は、擁護可能で監査可能な事実となります。
4. GenAIは並列宇宙ではない — クラシックな信用、AML、不正、LLMエンドポイント、およびエージェンティックシステムは、同じ評価、モニタリング、およびドキュメントハーネスを備えた1つのレジストリを共有します。カバレッジのギャップは、2番目のツールチェーンに隠されるのではなく、可視化されます。
5. コミットする前にリハーサルする能力 — 高速なプロトタイプは、新しい制御パターンを数週間で1つのTier-1モデルでテストし、MRMで洗練させてからスケールできることを意味します。規制対応は、銀行がすでにすべてを実行している方法である、反復的なエンジニアリングになります。

リスク管理のシフトレフト

2026年のガイダンスでは、銀行に「シフトレフト」が求められており、リスク管理をモデルライフサイクルの非常に早い段階に移行させます。Spark Declarative Pipelines (SDP)を使用することで、ガバナンスは手動のハードルではなく、データフローの自動化された一部となります。モデル構築後に監査するのではなく、SDPは組み込みの品質期待値を使用して、Model Registryに到達する前に非準拠データや不安定な特徴量をブロックします。これにより、Medallion アーキテクチャ内のすべての資産が設計上準拠していることが保証され、完全な監査証跡が開発の自然な副産物として生成されます。これらのパイプラインを通じて「効果的な異議申し立て」を自動化することで、MRMチームは手動のデータ収集に費やす時間を減らし、より高度な監視に時間を費やすことができます。

キャパシティに関する議論

すべての規制対応は、MRMアナリスト、モデル開発者、およびバリデーターの有限のプールから引き出されます。そのキャパシティがどのように費やされるかが、役立つプラットフォームと足を引っ張るプラットフォームの違いです。統合された基盤からは、3つの構造的な利点が得られます。

• 統合にキャパシティが消費されなくなる — 断片化されたスタックでは、限られたMRMキャパシティが統合作業に消費されます。ツール間のインベントリの調整、モニタリングの再構築、ツールがすでに知っていることの再文書化などです。
• 人々は判断に集中し、配管作業に集中しない — 統合されたプラットフォームでは、人間だけができる作業、つまりマテリアリティに関する判断、モデル設計に関する効果的な異議申し立て、審査官との会話にキャパシティが解放されます。
• ガバナンスはプロジェクトではなく副産物になる — リネージ、ドキュメント、モニタリング、アクセス制御は、モデルがどのように構築およびデプロイされるかの副産物として生成されます。最終的な個別のコンプライアンスパスとしてではありません。

Databricksの構造的な利点は、このガイダンス変更をより速く処理すること（それはそうですが）ではなく、次の変更、そしてその次の変更を、プログラムから設定に変換することです。

組織的な価値ドライバー

銀行のAIロードマップにおける顕著な制約は、コンピューティングやデータだけでなく、モデルリスクチームとCenter of Excellence (CoE)の人員能力です。現在のガイダンスは「モデルのような」システムの定義をGenAIやエージェンティックワークフローにまで拡大しているため、検証リクエストの量は、資格のある実務家のヘッドカウントを上回るでしょう。

「初回パス」自動化レイヤー

すべてのLLMプロトタイプに個別の手動レビューが必要になる代わりに、DatabricksはCoEが銀行の標準を最初のパス自動化レイヤーにコード化することを可能にします。

• セルフサービストリアージ — 開発者は、自動的に実行される標準化されたMLflow評価レシピ（毒性、グラウンデッドネス、PII漏洩）を使用します。最初のパスを通過できないモデルは、CoEのデスクに到達しません。
• 標準化された証拠 — プラットフォームは共通のリネージとドキュメントスキーマを強制するため、CoEは証拠のクリーニングに数週間を費やす必要がありません。数時間かけてレビューします。

実用的な問題はよく知られています。ビジネスユニットは4週間でLLMアシスタントをリリースしたいと考えていますが、CoEには6か月のバックログがあります。

Databricksは、CoEが制御を維持しながら実行を委任できるようにすることで、これを解決します。CoEは、監視、モデルカード、および監視を反復可能にするメトリクスである自動化ハーネスを提供します。ビジネスはGenAIのスピードで進みます。2026年のガイダンスは、ボトルネックからガードレールに変換されます。

結論

2026年4月のガイダンスは、このサイクルで私たちが目にする最後の監督上のシフトではありません。エージェンティックAIの原則、サードパーティモデルの監視、および気候リスクモデリングはすべて進行中です。問題は、私たちのプラットフォームがそれらのそれぞれを3四半期のプロジェクトにするのか、それとも4週間のプロトタイプにするのかということです。その選択は一度だけ行われます。

(このブログ記事はAI翻訳ツールを使用して翻訳されています) 原文記事