生成AIの社内管理を何から始めるか：金融庁のモデル・リスク管理原則を流用する手順
はじめに
「定量的な手法であって、理論や仮定に基づきインプットデータを処理し、アウトプット（推定値、予測値、スコア、分類等）を出力するもの」。金融庁が2021年11月に公表した「モデル・リスク管理に関する原則」が置いた、モデルの定義です。生成AIが話題になる前に書かれた文言ですが、LLM（大規模言語モデル）はこの定義にそのまま当てはまります。定義には続きがあり、インプットやアウトプットの全体または一部が定性的なものも含む、と明記されています。文章を入れて文章を返すシステムを、この定義から除外する読み方のほうが難しいはずです。
生成AIを業務に組み込む話になると、管理の議論は「新しく何を作るか」から始まりがちです。AI利用ガイドラインを新設し、委員会を置き、チェックリストを作る、という順です。一方で金融機関は、間違え方の見えにくい計算装置を意思決定に組み込み、その誤りで損害を出し、管理の枠組みを文書に固めるという経験を、生成AIより先に積んでいます。上の定義はその蓄積の入り口にあたります。
使える部分と作り直しになる部分の境界は、モデルの外側か中身かで引けます。モデルの外側を縛る部分、つまり利用箇所の把握、リスクの格付、独立したけん制、ベンダー統制は、既存のモデル・リスク管理（model risk management）がそのまま使えます。設計し直しになるのはモデルの中身を確かめる検証で、従来の枠組みが暗黙に置いてきた3つの前提が生成AIでは崩れるためです。
対象読者:
- 生成AIの社内ガイドラインや管理態勢の整備を任されている方
- 金融機関でモデル・リスク管理に携わり、生成AIをどう位置づけるか検討している方
- AIガバナンスの議論を、既存のリスク管理の実務と接続して理解したい方
記事のポイント:
- 金融庁「モデル・リスク管理に関する原則」とその源流にあるSR 11-7の骨子を、生成AIの管理に使える形で整理します
- 従来のモデル検証が置いてきた3つの前提（挙動が固定である・入力空間が閉じている・正解が観測できる）を、生成AIがどう壊すかを示します
- 金融機関でない会社も含めて、利用箇所の棚卸しから始める手順を、架空の台帳6件の例とあわせて書きます
銀行の照会ボットを、定義に当てはめてみる
抽象論に入る前に、1件だけ具体的に見ます。銀行の営業店で、行員からの事務手続きの照会に答える社内ボットを考えます。細部は例として組んだ架空のものですが、規程やマニュアルの照会は、後で触れる金融庁のアンケートでも生成AI利用の中心にある形です。
入力は「代理人が来店した預金相続の手続きには、どの書類が必要ですか」という質問文と、参照用に持たせた事務規程・手続マニュアルの文書です。処理はLLMが担い、規程から該当箇所を引いて回答を組み立てます。出力は「戸籍謄本と委任状、相続人全員の同意書が必要です」という回答文です。窓口の担当者はこの回答を根拠に、顧客へ必要書類を案内します。
冒頭の定義に当てると、インプットデータは質問文と規程、理論や仮定は学習済みの言語モデルとプロンプト、アウトプットは回答文で、定義が挙げる「分類等」の定性的な出力に当たります。このボットの間違え方も具体的に書けます。規程が改定されたのに古い版を参照したまま答える、規程に記載のない手続きをあたかも記載があるかのように答える、という2通りがすぐに挙げられます。どちらの場合も、担当者は顧客に誤った案内をし、顧客は書類を揃え直して出直すことになります。モデルの誤りが意思決定を通じて損害になる、という経路がこの1件に揃っています。
以降の節では、このボットを手元に置いたまま、既存の枠組みのどこが流用できて、どこが作り直しになるかを見ていきます。
モデルの誤りで損害を出した経験が、先に文書になっている
出発点は米国にあります。2011年4月、米連邦準備制度理事会（FRB）と通貨監督庁（OCC）が監督文書SR 11-7（Supervisory Guidance on Model Risk Management）を出しました。背景には2008年の金融危機があり、証券化商品の評価モデルやリスク計測モデルの誤りが大きな損失につながった反省から、モデルというもの全般を管理対象とする枠組みが作られました。そこで定義されたモデル・リスクとは、モデルの誤りまたは不適切な使用に基づく意思決定によって悪影響が生じるリスクです。古い規程のまま答えるボットと、それを信じて顧客に案内する担当者を思い出すと、生成AIで心配されていることの大半がこの一文に収まると分かります。
金融庁の「モデル・リスク管理に関する原則」はこの系譜にある文書で、適用対象は国内のG-SIBs・D-SIBs（グローバルまたは国内のシステム上重要な銀行）などですが、書かれているのは特定の業態に限らない管理の骨格です。8つの原則で構成されています。
| 原則 | 求めていること |
|---|---|
| 1. ガバナンス | 取締役会等がモデル・リスクを包括的に管理する態勢を作る |
| 2. 特定・インベントリー管理・リスク格付 | 管理すべきモデルを特定して台帳に載せ、リスクを格付する |
| 3. モデル開発 | 開発プロセスを整備し、手法・仮定・限界を文書化する |
| 4. モデル承認 | 使用開始や重要な変更の前に内部承認を通す |
| 5. 継続モニタリング | 使用開始後も意図どおりに機能しているかを監視する |
| 6. モデル検証 | 開発から独立した立場で検証する |
| 7. ベンダー・モデル | 外部調達のモデルにも統制を及ぼす |
| 8. 内部監査 | 態勢全体の有効性を評価する |
全体を貫く考え方は2つです。1つは実効的なけん制で、作った本人の自己評価だけで終わらせないために、開発・使用（第1線）、独立検証（第2線）、内部監査（第3線）という3つの防衛線で役割を分けます。もう1つはリスクベース・アプローチで、すべてのモデルを同じ深さで管理せず、格付に応じて検証の深度や頻度に濃淡をつけます。
これが生成AIと無関係な過去の文書でないことは、当局自身が示しています。金融庁が2025年3月に公表したAIディスカッションペーパーは、金融機関のAI活用の課題を「従来型AIと共通の課題」「生成AIにより難化した課題」「生成AIがもたらした新たな課題」の3つに分けて整理し、モデル・リスク管理を「難化した課題」に分類しました。新しい問題ではなく、難しくなった問題という位置づけです。では、何がどう難しくなったのかを切り分けていきます。
そのまま使えるのは、モデルの外側を縛る部分
原則2がまず求めるのは、管理すべきモデルを特定し、モデル・インベントリー（特定したすべてのモデルの情報を記載した台帳）に記録することです。生成AIの現状はこの真逆で、部署ごとのAPI直呼びの試作、SaaSに組み込まれたAI機能、個人が業務で使う対話サービスが散在し、どこで何が動いているかの一覧を誰も持っていない状態が多くの会社で現に生じています。金融機関はこの状態を経験済みです。表計算ソフトで作られた評価やレポートのロジックが各部署に散らばって全体を把握できなくなる問題は、EUC（End User Computing）と呼ばれて管理対象になりました。生成AIの散らばり方はこれとよく似ていて、台帳を作るという地味な第一歩の価値も変わりません。
リスク格付も同じ形で使えます。金融庁が2024年に行った金融機関へのアンケートでは、生成AIの利用は文書の構成・添削や社内FAQ検索といった社内業務支援が中心で、顧客向けサービスへの直接利用はごく限られていました。冒頭の照会ボットもこの帯にあり、回答は顧客への案内に使われるものの、途中に担当者の知識と確認を挟みます。同じLLMで顧客からの問い合わせに直接自動返信すれば、誤りは誰の確認も経ずに顧客へ届きます。誤りが意思決定や顧客に届くまでの距離に応じて統制の深さを変えれば、検証のリソースを全件に薄く延ばして態勢ごと止まる事態を避けられます。
けん制の原則も持ち越せます。プロンプトを書いた本人が「動きました」と報告してそのまま本番に入れる流れは、生成AIの現場でよく見ます。従来のモデル開発でこれを許さないために置かれたのが独立検証で、検証者のレポーティングラインを開発から分離するところまで実務の型が固まっています。確かめる人と作った人を分けるという原則に、モデルの種類は関係ありません。
ベンダー・モデルを扱う原則7は、仕様が非公開のモデルを外部から調達する場合の統制です。可能な限り情報の提供を求め、入手できる情報の範囲で検証し、使えなくなった場合に備えたコンティンジェンシープランを持つ、という処方が並びます。外部のLLM APIは、この「中身が見えないベンダー・モデル」の極端な形です。提供者がモデルを更新・廃止する判断に自社は関与できず、情報の提供を求める処方も、巨大な提供者が相手では交渉の余地がほとんどありません。それでも処方は読み替えれば執行できます。情報提供の要求は、モデルカードや更新告知の監視に置き換わります。コンティンジェンシープランの実体は、代替モデルの目星を付けておくことではなく、固定の評価セットと乗り換え評価の手順を先に整備しておくことです。評価セットさえ手元にあれば、提供者が廃止を告知してから、候補モデルで同じ評価を回して移行の可否を判断するまでを数日で終えられます。
検証だけは、前提から作り直しになる
外側の枠組みが流用できる一方、モデルの中身を確かめる工程は事情が違います。SR 11-7は検証の要素として、設計の妥当性の評価（概念的健全性）、使用開始後の継続的モニタリング、実績との突き合わせ（アウトカム分析）の3つを挙げています。この3点は、従来のモデルでは自明すぎて文書に書かれてもいない前提の上に立っています。挙動が固定であること、入力空間が閉じていること、正解が観測できることです。生成AIはこの3つを順に壊します。
「検証済み」という状態が続かない
従来のモデルは、同じ入力に同じ出力を返し、自社が変えるまで変わりません。だから使用開始前に検証を通し、検証済みのモデルとして運用に入る設計が成立していました。検証は一時点の性質の証明として意味を持ちます。
LLMでは、検証した相手が検証した時点のままでいてくれません。同じ入力に対して出力が揺れます。サンプリングの温度を0にしても、推論基盤の並列処理などの要因で完全な再現は保証されないのが実情です。外部APIのモデルは提供者の判断で更新され、旧バージョンは廃止されます。先月検証した相手が今月も同じものである保証がありません。加えて、挙動を決めるのはモデル本体だけではありません。冒頭の照会ボットなら、規程文書の差し替えやプロンプトの1行修正で、モデルに一切触れていなくても回答が変わります。
この最後の点は、モデル承認の運用に直接響きます。従来は重要な変更の前に再検証と承認を挟む決まりでしたが、プロンプトの1行修正が「重要な変更」に当たるのかは自明ではありません。全部を重要な変更として扱えば承認が日常の改善速度に追いつかず、全部を軽微として扱えば統制が形だけ残って中身を失います。現実的な設計は、変更のたびに自動で走る回帰評価（固定の評価セットに対する採点）を最初の関門に置き、スコアが基準を割ったときだけ人の承認に上げる形です。一度の検証で長く保証する設計から、継続モニタリングに重心を移した設計への組み替えになります。
入力の全域を試すという発想が成立しない
信用スコアリングのモデルなら、入力は定義された特徴量のベクトルです。各変数の定義域が決まっているので、代表的な値と境界の値を押さえれば、入力空間の主要な領域を試験で覆えます。従来の検証がテストケースの網羅を語れたのは、入力空間が閉じていたからです。
LLMの入力は自然言語で、事実上無限です。照会ボットに来る質問だけでも、言い回しの揺れ、誤字、複数の論点が混ざった長文まで含めれば列挙できません。すべてを試すことは原理的にできず、検証は全数の点検から標本調査に変わります。標本調査になった瞬間、統計の問題が全部ついてきます。評価セットで合格率95%が出ても、それは「この標本で95%」であり、何件で測ったかに応じた幅を持ちます。改善したはずの差が標本の揺れに埋もれることもあり、評価データセットの件数設計はこの幅を制御する作業です。
平常の入力分布で測った性能は、敵対的な入力について何も言わない点にも注意が要ります。プロンプトインジェクションのような攻撃は、運用データの分布の外から来ます。通常入力での性能評価と、攻撃を意図的に試みる検査（レッドチーミング）は別の作業で、両方を検証項目に置く必要があります。検証報告書の結論も変わります。「このモデルは正しい」という証明は書けず、「この範囲の入力を何件試験し、性能をこの幅で推定した」という統計的な主張が、書ける上限になります。
正解が観測できない業務では、検証の道具もモデルになる
信用リスクのモデルは、時間はかかっても正解が返ってきます。貸せば、返済されたか貸し倒れたかがいずれ観測され、予測と実績を突き合わせるバックテストが成立します。アウトカム分析という検証の柱は、正解がいつか観測されることを前提にした装置です。
文書要約や応答文の生成には、この意味の正解がありません。良い要約の定義は一意に決まらず、人手の評価は高くついて全件には回せません。そこで別のLLMに採点させるLLM-as-a-Judgeが定番になっています。モデルをモデルで確かめる構図自体は、実は新しくありません。従来の検証でも、同じ対象を別の手法で推定するベンチマークモデルとの比較は標準的な道具でした。新しいのは、検証の主装置が被検証側と同種のLLMになり、その判定器自身に、回答の提示順や長さに反応する系統的なバイアスがあると分かっている点です。判定器は「インプットデータを処理してスコアを出力する定量的な手法」そのもので、冒頭の定義に照らせばモデルです。
枠組みの処方はここでも一貫しています。判定器もインベントリーに載せ、格付し、検証の対象にします。判定器の性能は人手評価との一致率という形で、小さい標本なら測れます。全件の人手評価は無理でも、判定器を人手で較正し、較正済みの判定器で全件を見る2段構えなら、コストと信頼性の折り合いが付きます。判定に自信が持てない出力だけを統計的な保証付きで人手に回す方法も使えます。
金融機関でなくても、棚卸しと格付から始められる
原則の適用対象は大手金融機関ですが、文書は15ページで、金融庁のサイトから誰でも読めます。書いてあるのは、誤りが表に出にくい計算の仕組みを組織で使うときの一般的な骨格で、金融固有の計算手法は出てきません。NIST（米国立標準技術研究所）のAIリスク管理フレームワーク（2023年）のようなAI専用の枠組みも整いつつありますが、骨格は同じで、把握し、格付し、検証し、監視し、監査するという並びから外れません。新しいフレームワークの確定を待つ理由にはなりません。
始める順序も原則の並びどおりで足ります。最初は棚卸しです。生成AIが動いている業務を、SaaSの組み込み機能や個人利用も含めて書き出します。モデルに当たるかどうか迷ったら、「この出力を根拠に誰かが判断を変えるか」で判定します。次に格付です。出力が意思決定にどれだけ直接届くかで、3段階もあれば足ります。台帳がどんな姿になるか、架空の6件で示します。
| 利用箇所 | 出力が届く先 | 格付 | 検証の扱い |
|---|---|---|---|
| 社内規程の照会ボット（経費・労務） | 担当者の事務処理の判断 | 中 | 評価セット50問の回帰評価。規程改定のたびに再実行 |
| 会議の議事録要約 | 出席者が確認・修正して配布 | 低 | 台帳に記載するだけ |
| 顧客問い合わせへの自動返信 | 顧客にそのまま届く | 高 | 回帰評価に加えてレッドチーミングと人手のサンプル監査 |
| 営業SaaSの組み込み提案文生成 | 営業担当が編集して使用 | 低 | 台帳に記載し、ベンダーの更新告知を購読 |
| 請求書からの項目抽出 | 会計システムへ自動入力 | 高 | 月次で実績と突き合わせるバックテスト |
| 開発者のコード補完 | エンジニアがレビュー | 低 | 台帳に記載するだけ |
この6件から読み取れることは2つあります。1つは、同じ社内向けでも格付が割れることです。議事録要約は出力を人が確認してから使うので低、規程の照会ボットは出力を根拠に判断が動くので中になります。銀行の相続手続きで見た形は、一般の会社では経費や労務の規程照会として現れます。もう1つは、対話型の目立つ機能より、人の目を通らず下流システムに入る地味な自動化が上位に来ることです。請求書の項目抽出は誰も読まないまま会計システムに書き込まれるので、社外に出ない業務でも高になります。格付を決めるのは技術の新しさではなく、誤りが届く先です。
検証の設計は上位の格付に絞ります。固定の評価セット、変更時に自動で走る回帰評価、監視する指標、提供者のモデル更新が来たときの再評価の手順までを決めます。下位の格付は台帳に載せるだけで止めてよく、この濃淡がリスクベース・アプローチの中身です。件数が増えて格付の判断が割れ始めたら、そのときに基準を文書に落とせば済みます。
信用リスクモデリングの実務にいた頃、検証まわりの書類仕事でいちばん時間を使ったのは、数理の妥当性の説明ではなく、モデルの限界を書き切る作業でした。どの範囲の使い方までが想定内で、どこからが想定外か。この記述があるから、後任もモデルの検証者も、モデルを信じてよい範囲を自分で判定できます。生成AIの現場でいちばん欠けているのはこの文書です。プロンプトは共有されていても、どの用途を想定してどう評価したのかは、書かれないまま使われています。
まとめ
金融庁の「モデル・リスク管理に関する原則」が置くモデルの定義は、生成AIを最初から含んでいます。利用箇所の把握、リスク格付、独立したけん制、ベンダー統制という外側の枠組みは生成AIにそのまま使えます。設計し直しになるのは検証で、挙動が固定である、入力空間が閉じている、正解が観測できるという3つの前提が崩れるため、一時点の証明は継続的な統計監視へ、全数の点検は幅の付いた推定へ、実績との突き合わせは判定器の較正へと、それぞれ形を変えます。
生成AIの管理態勢をゼロから議論すると、金融が損害と引き換えに文書化してきた蓄積を捨てて、同じ結論を遠回りに再発見することになります。まず原則の15ページを読み、自社で生成AIが動いている箇所を10件書き出して、冒頭のモデルの定義に当ててみてください。冒頭の照会ボット1件でやった当てはめを、自社の10件に繰り返すだけです。定義に当てはまるのに、作った本人以外の誰も確かめていないものがあれば、検証の設計はそこから着手できます。
