[基礎] Part 7. リリースが終わりではありません：検証とガバナンス、モニタリング

Part 6まで、私たちは良いモデルを作り、そのモデルで政策まで設計する話をしてきました。ところが金融では、ここからが本当のスタートです。

Part 0で「モデルはリリースした瞬間から老化が始まる」、そして「遅いのには理由がある」と短く触れましたが、この回はまさにその理由を詳しく扱う場です。ほかの分野ではモデルをリリースすると決勝線に着いた気分になりますが、信用ではリリースはむしろスタート地点に近いです。作るのに数週間かかったとすれば、そのあと検証し、監督し、見守る時間は数か月、あるいは数年です。

この回で扱うのは次のことです。リリース前に別の人が独立して検証すること、リリースそのものを慎重に行うこと、そしてリリースしたあとも見守り続け、古くなれば再学習させること。さらに、そのすべてを包む文書とガバナンスです。

作った人が検証してはいけません

まず概念を一つ。モデルリスクです。モデルが間違っていたり誤って使われたりして生じる損失や評判の毀損、規制リスクをまとめてこう呼びます。モデル一つが引当金や資本の計算にまで流れていくので(Part 0)、それが間違っていれば会社全体が揺らぎます。だから金融では、モデルをリスクを抱えた資産として扱い、これを管理する枠組みをモデルリスク管理(MRM)と呼びます。

MRMの原則は一つだけ覚えれば十分です。作った人と検証する人が別でなければならない、ということです。よく「3つの防衛線」と呼ばれ、第1線はモデルを開発し運用するチーム、第2線はそれと独立した検証とリスク管理、第3線は内部監査です。「自分で作ったものを自分で検証したら良い結果でした」は、ほかの分野では通っても金融では通りません。作った人は自分のモデルの弱点が見えにくいからです。だから検証は必ず別の目が行います。

検証は何を見るのか

独立した検証者はモデルを受け取ると、だいたい五つを見ます。

一つ目は概念的健全性です。方法論と仮定と変数が、そもそも筋が通っているかを見ます。性能が良くても、「所得が高いほど貸し倒れリスクが大きい」のように常識に反する関係が入っていれば、それはデータの偶然であって、信じられる信号ではありません。

二つ目は定量的検証です。判別と補正と安定性を数字で確認します。Part 5で見たあの三つの軸です。AUCだけ良くてPDは外していないか、時間が経っても安定しているか。

三つ目は感度分析とストレステストです。入力を少し揺らしたときにスコアがぶれないか、そして景気後退のような悪いシナリオでモデルがどう振る舞うかを見ます。良いときだけよく当たるモデルは、いざ必要なときに崩れます。

四つ目はベンチマーキングです。この複雑なモデルが、より単純なモデルや既存モデルより実際に性能が改善するのかを比べます。複雑なのに性能も大きく改善しないなら、その複雑さはただのリスクです。

五つ目は再現性です。同じコードとデータでもう一度回したとき、同じ結果が出るか。再現できないモデルは、検証することも監査を受けることもできません。

一度に切り替えません：シャドーモード

検証を通ったからといって、すぐ実戦に投入することもしません。信用モデルを新しく導入するときの標準的な安全装置が、シャドーモードです。

シャドーモードは、新しいモデルを実際の意思決定には使わず、横でスコアだけを一緒に算出してみることです。実際には従来のやり方で承認し、否決しながら、新しいモデルならどう判断したはずかを数か月にわたって並べて記録します。そうして新しいモデルが安定して動き、従来の結果と大きくずれないことを確認してから、はじめて本当に切り替えます。

似たやり方でチャンピオンとチャレンジャーを並行比較したり、一部の顧客にだけ先に切り替える段階的ロールアウトを行ったりもします。どちらにも共通点は一つです。問題が起きたらすぐ戻せるよう、ロールバック計画を前もって立てておくこと。「性能の良いモデルを早く切り替えよう」ではなく、「間違っても安全に切り替えよう」が原則です。

モデルは老います：モニタリングと再学習

リリースしたら終わりではなく、むしろいちばん長い区間が始まります。Part 0でお話ししたあの老化です。2024年のデータで学習したモデルが2026年の顧客を評価する間に、景気も金利も顧客の行動も変わります。分布が移動し、モデルは少しずつ古くなります。

だからリリース後は、いくつもの観点で見守り続けます。まず入力が学習時とどれだけ離れたかを、PSIとCSIで見ます。Part 5で見たあの安定性の指標です。もちろん性能も追跡します。ただ、ここには信用ならではの難しさがあります。貸し倒れラベルが12〜24か月後にようやく確定するので(Part 0)、性能の劣化をリアルタイムでは知りようがありません。だからラベルが溜まり次第、予測と実際を突き合わせるバックテストを遅ればせながら回し、その間はPSIのような先行指標で異常の兆しを先に捉えます。予測貸し倒れ率と実際の貸し倒れ率が合っているか、特定のセグメントだけ極端にずれていないか、データパイプラインが静かに壊れていないかも一緒に見ます。

そして、モデルが老化したと判断されたら再学習させます。いつ再学習するか、そのトリガーもあらかじめ決めておきます。分布が大きく移動したとき、性能が落ちたとき、政策が変わったとき、新しい商品が出たとき。大切なのは、再学習を思いつきで行うのではなく、周期と手順を事前に定義しておき、そのガバナンスに従うことです。モデルを変えること自体も一つのリスクだからです。

文書こそがモデルです

最後に、モデルに関する内容を文書として残すことです。これが意外にも核心です。

モデル一つには開発文書がついてまわります。何のために、どんなデータで、どんな方法と仮定で作ったのか、限界は何か、検証結果とモニタリング計画はどうなっているのか。ここに、いつ何が変わったのかを残す監査証跡とバージョン管理、変更管理が加わります。

核心はこれです。文書化はモデルを作り終えたあとの後片付けではなく、開発工程の一部です。監督当局が「なぜこのモデルなのか」と尋ねたとき、内部監査が「この決定の根拠は何か」と尋ねたとき、答えになるのがこの文書です。文書で説明できないモデルは、性能がどれほど良くても金融では使えません。

だから、遅いのには理由があります

Part 0で、スタートアップ的な「早くリリースしよう」がここではあまり通らない、遅いのには理由がある、と述べました。その理由を説明したのが、この回です。作った人とは別の人が検証し、慎重に切り替え、老化するのを見守って再学習させ、そのすべてを文書として残すこと。煩わしく見えますが、これは規制が無理やり被せた重荷ではなく、信頼のインフラです。モデル一つが一人の信用を判定し、会社の資本まで揺るがす場所だからです。

予測がうまいのは入場券であり(Part 5)、因果を扱えるのが実力であり(Part 6)、そうして作ったモデルを正直に検証し、長く守り抜くことが信頼です。次回は、この信頼のもう一つの軸、なぜこう判定したのかを説明できなければならないという解釈可能性と公平性、そして規制へと続けます。