生成AIのモデルリスク管理｜モデル台帳・変更の影響度判定・再検証トリガー

結論：AIを入れた後の仕事は「変わったことに気づいて、判定して、記録する」の3つ

AIを業務に組み込むところまでは、多くの組織がたどり着きます。難しいのはその先です。自社は何も変えていないのに、ある日から出力の質が変わる。これが生成AIに固有の問題で、従来の統計モデルの管理手順では捕まえられません。

開発→検証→承認→運用→モニタリング→再検証という管理フローの全体像は金融リスク管理でのAI活用で扱っています。本記事はそのうち運用フェーズだけ、それも「変わったときにどうするか」に絞ります。定義はモデルリスク（モデルの誤りや不適切な使用による意思決定が悪影響をもたらすリスク）を参照してください。

結論は3つです。第一に、変更の種類と重要度の2軸で判定基準を先に表にしておくこと。変更が起きてから「これは再検証が要るのか」を議論し始めると、毎回結論が変わり記録も残りません。第二に、バージョンを固定しても問題は消えないこと。固定版はいずれ提供終了します。固定は解決ではなく時間稼ぎで、その前提の移行計画を台帳に書く必要があります。第三に、「何も起きなかった」ことこそ記録すること。差が出なかったという記録がないと、後から見て「監視していなかった期間」と区別がつきません。

運用フェーズで実際に回すサイクル

運用に入った後にやることは、定点観測・検知・影響度判定・再検証・承認・台帳更新の6つです。一巡して初めて「監視している」と言える状態になります。

従来の統計モデルと生成AIで、何が変わるのか

本記事の出発点はここです。スコアリングモデルの管理をしてきた人ほど、生成AIに同じ枠組みを当てると噛み合わない箇所が出ます。統計モデル側の設計論は信用リスク予測にAIを使う、判断根拠の提示は説明可能AI（XAI）と金融審査に譲り、ここでは管理実務の差だけを並べます。

これに加えて、外部提供のモデルは提供終了・仕様変更が起こりうるため、台帳に代替手段を書いておく必要があります。特に2行目が実務を変えます。従来のモデルガバナンスは「変更したら検証する」という変更起点の設計でしたが、生成AIでは自社が何もしていない期間にこそ変化が起きうるため、時間起点の定点観測を足さないと成立しません（機械学習モデル一般の性質も参照）。

金融庁「モデル・リスク管理に関する原則」をどう参照するか

日本では金融庁が「モデル・リスク管理に関する原則」（令和3年11月12日公表・全15ページ）を公表しています。押さえるべき事実は3つです（出典は記事末尾、確認日2026-08-16）。

1. 法令ではなく「原則」です。モデル・リスク管理には画一的な手法が存在しないことに留意し、ルール・ベースではなく原則ベースのアプローチを採用していると記載されています。
2. 対象金融機関が限定されています。適用対象は「金融システム上重要な金融機関」、具体的には本邦G-SIBs、本邦D-SIBs、FSB選定G-SIBs（本邦G-SIBsを除く）の本邦子会社であって金融庁のモデル承認を受けている先と記載されています（今後の拡大もあり得る旨も併記）。対象外の金融機関や一般事業会社に直接適用されるものではありません。
3. 8つの原則で構成されています。①ガバナンス、②モデルの特定・インベントリー管理及びリスク格付、③モデル開発、④モデル承認、⑤継続モニタリング、⑥モデル検証、⑦ベンダー・モデル及び外部リソースの活用、⑧内部監査。

運用フェーズに関係が深いのは原則2・4・5・6・7です。要点を編集部の言葉で整理すると、インベントリーに記録してリスク格付を付ける（2）、使用開始時だけでなく重要な変更時・再検証時にも内部承認を要する（4）、使用開始後は第1線が継続モニタリングを行い陳腐化を捕捉する（5）、再検証の頻度や深度はリスク格付と整合させる（6）、ベンダー・モデルは仕様が非公開でも自社の管理態勢の下に位置づけ、入手可能な情報の範囲で検証し、使えなくなった場合に備える（7）という組み立てです。

最後の原則7は、外部提供の生成AIを使う状況をよく言い当てています。ただし、これは同文書の対象金融機関に向けて書かれたものです。「金融庁が求めているから」という説明は対象外の組織では正確ではありません。本記事は、対象外の組織にとっては設計の参考になる枠組みとして扱う立場を取ります（本記事の見方であり、当局解釈ではありません）。

モデル台帳（インベントリ）の様式

運用管理は台帳がなければ始まりません。「どこで何が動いているか分からない」状態では、更新の告知が来ても影響範囲を答えられません。以下は本記事が提案する14項目です（公的な様式ではありません）。

各項目の書き方を、後述の設例（架空の「霞ヶ浦みらい銀行」MR-003）で示します。

⑧を強調します。台帳に書いた版と実際に呼ばれている版が食い違うのはよくある事故です。アプリケーション側が「最新を使う」設定だと、台帳は更新されないまま中身だけ入れ替わります。呼び出しログにモデル識別子を必ず残し、月次で台帳と突き合わせることを定点観測に含めてください。

重要度は3区分にする

格付を細かくすると運用が止まります。3区分に割り切るのが現実的です（定義と間隔は本記事の提案です）。

格付はモデルではなく用途に付ける点に注意してください。同じモデルでも顧客向け文面の生成はA、個人メモの整形はCです。だからこそ管理番号は用途単位で採番します。

変更の5類型と、影響度の判定基準

ここが本記事の核です。運用中に起きる変更は次の5つに分類できます（分類は本記事の整理です）。

1. プロバイダによるモデル更新：提供側が中身を差し替える。利用者が制御できないのが決定的な特徴で、告知があるとも限りません。
2. 固定版の提供終了・固定の解除：固定していた版が使えなくなり、強制的に移行が発生します。
3. プロンプト・システム指示の変更：自社側の変更ですが、事実上のモデル仕様変更です。
4. 参照文書（RAG）の更新：モデルは同じでも、読ませる社内規程や商品要項が変われば出力は変わります。
5. 利用範囲の拡大：同じ仕組みを別部門・別業務に広げる。新しい用途は新しいモデルとして扱うのが原則です。

①プロバイダによるモデル更新：制御できないことをどう扱うか

従来型の変更管理と最も違う点です。自社の変更申請書もリリース判定会議も存在しないまま、ある日から挙動が変わりうる。したがって「気づく仕組み」と「気づいた後の既定路線」を先に作るしかありません。経路は3つです。(1) プロバイダの更新・提供終了（デプリケーション）の案内ページを購読し担当者を決める、(2) 呼び出しログのモデル識別子を月次で台帳と照合する、(3) 評価セットを定期実行して数値で変化を捕まえる。主要なプロバイダはモデル一覧や提供終了の公式ページを持っているので、自社が使う事業者のページを台帳の⑨欄にURLごと書いておいてください（対象の版名や時期は変わりうるため本記事では記載しません）。

②バージョン固定は「解決」ではなく「時間を買う行為」

版を固定できるなら固定すべきです。比較可能性が保たれ、再検証の頻度を下げられます。ただし副作用が二つあります。第一に、固定版はいずれ提供終了します。そのときは自社の都合と無関係に、しかも複数の用途で同時に移行が発生します。第二に、固定している間に陳腐化します。したがって固定する場合は、台帳に「固定版の想定利用期限」と「移行時の再検証計画」を併記することを提案します。移行という将来の作業を、固定を選んだ時点で負債として計上する考え方です。

このマトリクスの価値は判定を議論の対象から外すことにあります。変更が起きたら表を引いて既定のアクションを実行し、違う扱いをしたい場合だけ理由を書いて例外承認を取る。担当者の熱意ではなく仕組みで回ります。なお「30日以内」は本記事の提案で、業務の重要性や体制に応じて各社で設定してください。

ドリフトの検知で何を定点観測するか

告知がないまま挙動が変わる場合、頼れるのは数字だけです。観測点は入力側・出力側・評価セット・運用ログの4群に分けると漏れません。

閾値は必ず観測を始める前に決めてください。数字を見てから決めると「今回は例外」の連続になり、監視は形だけになります。評価セットそのものの作り方（ケースの集め方、採点ルーブリック、合否ライン）は金融AIのEvals設計に譲り、本記事ではいつ再実行を起動するかだけを扱います。

再検証トリガー一覧（10件）

社内規程の別表としてそのまま使えるよう、検知方法と既定アクションを付けています（トリガーと期間は本記事の提案です）。

10番の定期トリガーは、他の9個が1つも発火しなかった場合の最後の砦です。「何も起きなかった年」にこそ回してください。なお、関連する規制・ガイドラインや社内規程の改訂も、用途の許容性を再確認する契機になります。リスクが低いモデルについては定期の再検証を行わず、性能低下の兆候が見られた場合に不定期で実施する設計も考えられます（金融庁の原則6.5にも同旨の記載があります。適用対象が限定されている点は前述のとおりです）。

設例：台帳15件の金融機関でモデル更新が起きたら

架空の地域金融機関「霞ヶ浦みらい銀行」を想定します（実在の金融機関とは関係ありません）。生成AIの用途を台帳に登録したところ15件あり、重要度はA＝4件、B＝6件、C＝5件でした（4＋6＋5＝15件）。

ステップ1：更新の影響を受ける行を特定する

外部LLMのプロバイダから、当行が使う汎用モデルの更新告知が届きました。台帳15件のうちそのモデルを使っているのは10件、内訳はA＝3件、B＝5件、C＝2件（3＋5＋2＝10件）。残り5件は別プロバイダか社内完結の仕組みで対象外です（15−10＝5件）。

ステップ2：マトリクスで判定する

変更の種類は①プロバイダによるモデル更新なので図3の1行目を引きます。A＝即再検証（3件）／B＝簡易確認（5件）／C＝記録のみ（2件）。「即再検証が必要な件数は3件」がここで確定します。

ステップ3：工数を積み上げる

1件あたりの標準工数を次のように置きます（設例上の仮定です）。

検算：16×3＝48時間、6×5＝30時間、1×2＝2時間。48＋30＝78、78＋2＝80時間。1人日8時間とすると80÷8＝10.0人日、担当2名なら5営業日です。告知から適用まで30日の猶予があるなら期間内に収まります（猶予期間は設例上の仮定です）。

ここでリスクベースの格付が効いていることを確認します。15件すべてを重要度Aとして扱っていたら16時間×15件＝240時間＝30.0人日。2名では15営業日、30日の猶予の半分を1回の更新に費やす計算です（240÷8＝30人日、30÷2＝15営業日）。安全側に倒すと制度そのものが回らなくなります。これが3区分に割り切る理由です。

ステップ4：合格率が下がったケースの判定

再検証の結果、MR-003（重要度B、評価セットEV-CR-01は40ケース）の合格率が次のように動いたとします。

• 前回（更新前）：40ケース中34件合格＝85.0%（34÷40＝0.850）
• 今回（更新後）：40ケース中29件合格＝72.5%（29÷40＝0.725）
• 低下幅：85.0−72.5＝12.5ポイント（件数では34−29＝5件、5÷40＝12.5%で一致）

重要度Bの閾値は「10ポイント超の低下」なので12.5＞10でトリガー該当。継続使用は自動承認せず、原因分析と対応（プロンプト修正、参照文書の追加、別の版への切り替え）を行ったうえで再承認を取ります。同じ低下幅でも重要度Cなら閾値20ポイントで該当せず、記録して次回定期検証で確認する扱いです。同じ数字でも重要度によって結論が変わる。これが格付を先に決めておく意味です。

同時に入力側のドリフトも観測されていたとします。月次の入力文字数の中央値が1,200字→2,040字（＋840字、＋70.0%）、不明回答率が8.0%（500件中40件）→2.4%（500件中12件）。前者は閾値±30%超（70.0%＞30%）、後者は閾値3ポイントを超える5.6ポイントの低下です。合格率低下の原因が「モデルが変わったこと」なのか「現場が長い資料を投げるようになったこと」なのかは、この2つを並べないと切り分けられません。合格率だけを見ていると、モデルのせいにして終わります。

AIに任せる範囲と、人が判断する範囲

この管理業務自体にもAIを使えますが、任せてよい範囲は限られます。

右側を渡してはいけない理由は単純で、評価される側が評価の可否を決める構造になるからです。金融庁の原則でも、独立した立場からの検証という考え方が示されています。実行する人と承認する人を分ける、という一点だけは崩さないでください。

プロンプト例：更新告知から影響範囲の一次整理を作らせる

あなたは金融機関のモデルリスク管理担当者を補助するアシスタントです。

【目的】外部AIプロバイダの更新告知を読み、当行のモデル台帳のうち影響を受けうる行を
一次的に洗い出し、担当者が判定するための材料を整理する。

【入力】
1) 更新告知の本文（原文をそのまま貼付）
2) モデル台帳の抜粋（管理番号／用途／重要度／モデル名と版／依存する外部サービス／
   評価セットID／最終検証日。※機密区分「社外秘」以上の具体的な業務内容は含めない）
3) 当行の判定マトリクス（変更の種類×重要度の3択表）

【出力形式】次の4見出しで、日本語・箇条書き。
A. 告知の要点（変更対象の版・変更内容・適用日・利用者側の選択肢）
   ※告知本文にない日付や版名は書かず、なければ「記載なし」とする
   ※各項目に告知本文の該当箇所を30字以内で引用して添える
B. 影響を受けうる台帳の行（管理番号・重要度・影響が疑われる理由）
C. 判定マトリクスに当てはめた機械的な結果（3区分と件数）
D. 判定を確定する前に人が確認すべき点（3〜7個）

【計算方法】Cは区分ごとに件数を数え、合計が入力した台帳の行数と一致することを示す。
一致しない場合は「不一致」とだけ明記し、原因を推測しない。

【禁止事項】
- 判定を「確定」と表現しない。すべて「案」と明記する
- 告知本文にない仕様・期日・価格を補わない。推測した内容は書かない
- 台帳に記載のないモデルや部門を新たに登場させない

【不明情報の処理】判断に必要な情報が入力にない場合は、D欄に「不足情報」として列挙する。

【検算】出力の最後に「台帳行数＝入力N行／分類済み合計＝N行」を明記する。

【レビュー項目】D欄には最低限、次の観点を含める。(1) 告知の適用日と当行の再検証所要期間の
関係 (2) 固定版を使っている行の有無と提供終了予定の記載有無 (3) 依存する外部サービス側の変更

このプロンプトで重要なのは「判定を確定させない」という禁止事項です。これがないとAIの出した区分がそのまま議事録に載り、誰も判定していない判定が成立してしまいます。出力はあくまで判定材料であり、区分を決めるのは人です。

再検証プロセス自体の検証方法

AI出力一般の検証手順は生成AI出力の検証手順に譲り、ここでは「再検証という作業がきちんと行われたか」を確かめる項目を挙げます。内部監査や第2線の点検観点でもあります。

1. 対象版の一致：再検証したモデル識別子と本番で実際に呼ばれている識別子が同一か。ここが違えば以降の検証結果はすべて無効です。
2. 評価セットの同一性：前回と同じケース集か。追加した場合は旧セットのみの集計も併記して比較可能性を残しているか（作り直すと前回と比較できません）。
3. 条件の同一性：プロンプト、システム指示、添付資料、出力形式の指定、実行回数が前回と揃っているか。揃っていない項目は差分の原因候補として記録されているか。
4. 差分と判定根拠の記録：合格率が動いた場合、どのケースが落ちたかまで特定されているか。「全体で下がった」だけの記録は原因分析に使えません。あわせて合否の理由、閾値との比較、判定日、判定者が残っているか。
5. 承認の独立性：承認者が第1線から独立しているか。同一人物が実行と承認を兼ねていないか。
6. 差なしの記録：変化がなかった場合も「実施日・実施者・差なし」が記録されているか。空欄は「未実施」と区別できません。
7. 不合格時の追跡と台帳への反映：不合格の後どうしたか（制限付き承認・使用停止・修正と再々検証）まで追えるか。最終検証日・次回検証日・版・判定結果が台帳に書き戻されているか。書き戻しのない再検証は次の判定に使えません。

この項目群は、そのまま内部監査のテスト手続に流用できます。特に承認の独立性と「差なし」の記録は指摘されやすい箇所です。

機密情報・個人情報の注意

モデル台帳そのものが、自社のAI利用状況を一覧にした機微な文書です。用途欄に顧客名や案件名を書かない、評価セットに実データを使う場合は入力の機密区分を台帳に明記する、といった運用が要ります。評価セットや再検証のログには過去の実業務データが含まれがちで、保管期間と閲覧権限を決めないまま蓄積されると、それ自体が漏えいリスクになります。入力してよい情報の線引きは生成AIに入れてよい情報・いけない情報を参照してください。個人データを含む入力を外部サービスへ渡す場合は、個人情報保護委員会の注意喚起等をふまえ法務・コンプライアンス部門の確認を経てください。

よくある失敗

1. 台帳を作って満足し、更新されない。初回の棚卸しは盛り上がりますが、半年後には実態と乖離します。対策は台帳更新を再検証の完了条件にすること（図1の⑥）。書き換わっていない再検証は未完了として扱えば、放置は起きません。
2. バージョンを固定して安心する。固定は有効ですが期限付きです。固定した用途が複数あると、終了時にまとめて移行が発生します。想定利用期限を台帳に書き、手前に移行検証を計画してください。
3. 「更新＝性能向上」と考えて再検証を省く。一般的な性能が上がっていても、自社の狭い用途では劣化することがあります。特に出力形式の遵守や「分かりません」と答える挙動は版によって傾向が変わりえます。方向は測らないと分かりません。
4. 重要度をすべて「高」にする。安全側に倒したつもりが工数は3倍になり（10.0人日→30.0人日）、結局どれも回らなくなります。リスクに応じて統制の深度を変えるのがモデルリスク管理の基本です。
5. 閾値を、数字を見てから決める。「今回は特殊要因だから」が2回続いたら、その監視はすでに機能していません。閾値と例外承認の手続は観測開始前に文書化してください。また、システム指示の1行の追加が出力の性質を変えることがあります。プロンプトはコードと同じ扱いで版管理してください。

実務チェックリスト

• 台帳が用途単位で採番されている（同じモデルでも用途が違えば別行）
• 14項目のうち「次回検証日」「代替手段」「責任者」に空欄がない
• 重要度が3区分で定義され、定期検証の間隔が区分ごとに決まっている
• 変更の5類型×重要度の判定マトリクスが文書化され、例外承認の手続がある
• 呼び出しログにモデル識別子が記録され、月次で台帳と照合している
• 使用中の版に提供終了の告知が出ていないか、購読担当者が決まっている
• 定点観測の項目と閾値が、観測開始前に決まっている
• 評価セットが用途ごとに固定され、IDと件数が台帳に紐づいている
• 再検証を前回と同じ条件（プロンプト・添付・実行回数）で実行している
• 承認者が第1線から独立し、「差なし」の結果も不合格時の措置も記録されている
• 台帳・評価セット・ログの保管期間と閲覧権限が定められ、使用停止分の行も一定期間残している
• 年1回、台帳の網羅性（未登録の利用がないか）を点検している

日本の金融機関・事業会社での留意点

• 金融庁の原則は対象先が限定されており、法令でもありません。参考にする場合は自社が任意に採用した枠組みとして社内規程に位置づけるのが素直です。
• 生成AIが自社の定めた「モデル」に当たるかは、まず定義の問題です。金融庁の原則はモデルを「定量的な手法であって、理論や仮定に基づきインプットデータを処理し、アウトプット（推定値、予測値、スコア、分類等）を出力するもの」と定義し、該当・非該当の最終判定は第2線が担うと整理しています。テキスト生成が自社の定義に収まるかを先に決めないと、台帳の範囲がぶれます。
• 与信・審査での利用には、説明可能性の要求が別途かかります。期待損失の考え方はクレジットリスク分析入門、判断根拠の提示は前掲のXAIの記事を参照してください。
• 既存のベンダー管理規程に接続し、導入段階から台帳を作り始めてください。外部委託・外部サービス利用の社内規程はすでにあるはずで、AI固有の管理をゼロから作るより既存の枠組みに項目を足すほうが定着します。本番稼働後に遡って台帳を作ると、誰がいつ何を承認したのかを再現できません。導入の順序立ては金融部門のAI導入ロードマップで扱っています。

よくある質問（FAQ）

まとめ

生成AIのモデルリスク管理が難しいのは、変更の起点が自社の外にあるからです。従来の「変更したら検証する」という設計では、提供側が静かに中身を差し替えた期間を丸ごと見落とします。時間起点の定点観測と、変更時の既定路線を先に作る必要があります。

作るものは3つです。モデル台帳（14項目・用途単位で採番）、変更の5類型×重要度3区分の判定マトリクス、再検証トリガー一覧（10件）。この3点が揃えば、モデル更新の告知が来た日に「対象は10件、即再検証は3件、80時間＝10.0人日」とその場で答えられます。答えられない状態が、いま管理できていないということです。

そして、重要度をすべて「高」にしないでください。設例のとおり工数は3倍になり、制度は静かに形骸化します。厚く見るところを絞り、その分だけ確実に回す。地味な作業ですが、この記録の有無が内部監査や当局対応の場面で決定的な差になります。

出典・参考（2026-08-16確認）

• 金融庁「モデル・リスク管理に関する原則」（令和3年11月12日公表・全15ページ） https://www.fsa.go.jp/common/law/ginkou/pdf_02.pdf ／参照したのは、適用対象、原則ベースのアプローチの採用、8原則の構成、モデルの定義、原則2.2（インベントリー）、2.3（リスク格付）、4（承認）、5（継続モニタリング）、6.5（再検証の頻度）、7.1・7.2（ベンダー・モデル）の各記載です。同文書は法令ではなく、適用対象が限定されています。解釈・適用可否は原文および専門家の確認によってください。
• 金融庁「金融機関のモデル・リスク管理の高度化に向けたプログレスレポート（2024）」（2024年12月12日） https://www.fsa.go.jp/news/r6/ginkou/20241212/20241212.html ／金融庁「AIディスカッションペーパー（第1.1版）」（2026年3月3日公表） https://www.fsa.go.jp/news/r7/sonota/20260303/aidp.html （いずれも存在とURLの確認にとどめ、本文の内容は引用していません）
• 個人情報保護委員会「生成AIサービスの利用に関する注意喚起等について」（令和5年6月2日） https://www.ppc.go.jp/news/careful_information/230602_AI_utilize_alert/ ／総務省・経済産業省「AI事業者ガイドライン」 https://www.soumu.go.jp/main_sosiki/kenkyu/ai_network/02ryutsu20_04000019.html
• 米国の監督ガイダンス（SR 11-7）は名称の言及にとどめました。米国の枠組みであり日本の金融機関に直接適用されるものではありません。
• 台帳の14項目、重要度3区分の定義と検証間隔、変更の5類型、判定マトリクスの各セル、定点観測の閾値、再検証トリガー10件、「30日以内」等の期限、工数の単価は、いずれも本記事が提案するものであり公的基準ではありません。設例（架空の「霞ヶ浦みらい銀行」・台帳15件）の数値も計算手順を示すための仮設例です。AI製品のモデル一覧・提供終了は各プロバイダの公式ドキュメントで公開されていますが、版名・時期は変更されるため本記事では具体名を記載していません。いかなるAI製品についても実測は行っていません。

※本記事は教育目的の一般的な解説であり、法務・税務・会計・投資に関する助言ではありません。実際の判断は専門家にご確認ください。設例は理解のための仮設例です。AI製品の仕様・料金は変更されることがあるため、利用前に各社の公式情報をご確認ください。