ValidMindが作る検証記録とは？｜金融のAI監督の線

「生成AIの案件が増えて、モデルの検証の文書を書く人が足りない」「AIで検証の報告書を作れるなら、検証の担当はもう要らないのでは」——銀行や保険会社でAIの導入とリスク管理を担う部署から、聞こえてくる二つの声です。金融庁は2021年に「モデル・リスク管理に関する原則」を公表し、モデルの使用を始める前と重要な変更のたびに、開発から独立した立場で検証し、その結果を文書に残すことを求めてきました。生成AIでモデルの数が増えるほど、この文書づくりが追いつかなくなっています。ただし、答えは「検証の担当をAIに置き換える」ではありません。AIに作らせてよいのは記録の下書きで、検証の所見と承認は人が持つという線を先に引くことが本題です。この記事では、米国の ValidMind を例に、検証記録のどこをAIに作らせ、所見と承認を誰が持ち、監督や監査に出せる形をどう保つかを整理します。

ValidMind は何をする製品か

ValidMind は、モデルのリスク管理を仕組みにする米国の基盤です。2026年10月時点の公式サイトでは、銀行や保険のような規制のある業種のために作ったAIガバナンスの基盤と説明しています。扱う対象は、従来の統計のモデルに加えて、機械学習のモデル、生成AI、AIエージェントまで広げています。

中心になる機能は3つあります。一つは、モデルの台帳です。公式の文書では、AIガバナンスの記録の置き場と位置づけ、台帳の階層や依存の関係、統制のルールを会社ごとに定義できるとしています。二つめは、テストの自動化です。開発者や検証者が用意されたテストや自前のテストを回し、その結果を台帳のモデルに結びつけて取り込みます。

三つめが、この記事の主題である文書づくりの自動化です。取り込んだテストの結果や図から、モデルの説明書や検証の報告書の下地を組み立てます。さらに公式の文書では、大規模言語モデルを使った機能として、テストの結果を読み解いて要約する機能、文書の節ごとにリスクの評価を作る機能、検証の報告書を規制の要件と照らして確かめる機能が挙げられています。

つまりこの製品が速くするのは、テストを回す、結果をまとめる、文書の形に整える、という記録づくりの工程です。どの結果を問題と見るか、モデルを使ってよいかを決める工程は、製品の外、つまり使う会社の側に残ります。この線が、導入を考えるときの出発点になります。

どんな会社で、国内でまだ知られていない理由

ValidMind は、モデルのリスク管理とAIガバナンスの基盤を作る米国のスタートアップです。公式サイトでは、カナダの銀行や米国の大手銀行の事例を掲げており、主な顧客は北米の金融機関です。日本語で紹介した記事は、2026年10月時点で資金調達の報道が1本見つかる程度でした。

国内でまだ知られていない理由は、確かめた範囲で3つあります。一つは、公式サイトが根拠として挙げる規制が、米国の連邦準備制度の監督の指針、英国の健全性監督機構の指針、カナダの金融機関監督庁の指針、欧州のAI法で、日本の金融庁の原則には触れていないことです。

二つめは、対象の規模です。金融庁の原則が直接の対象としているのは、国際的・国内的に重要な大手の金融機関で、そうした会社はすでに自前の仕組みや大手の監査法人の支援でモデルのリスク管理を回しています。専用の基盤を外から入れる需要は、まだ大手の一部にとどまっていると考えられます。三つめは、日本語の管理画面や国内の窓口が公式サイトで確かめられないことです。

それでもこの製品を取り上げるのは、生成AIの普及で、モデルの数が大手以外の金融機関でも急に増えているからです。金融庁の2024年12月のプログレスレポートは、原則の対象外の金融機関にも原則を任意に活用する動きがあると書いています。検証の文書を誰がどう作るかは、大手だけの問題ではなくなりつつあります。

モデルリスク管理とは：金融庁の原則を短く

モデルリスク管理は、モデルの誤りや誤った使い方で損失が出る危険を、組織として管理する考え方です。金融庁の「モデル・リスク管理に関する原則」（2021年11月12日公表）は、価格を付けるモデルやリスクを測るモデルのほか、マネーロンダリング対策で使うモデルなども含み得るとし、特定の種類に限らず広くモデルを対象にしています。

原則は8つあります。ガバナンス、モデルの特定と台帳とリスクの格付け、開発、承認、継続的な監視、検証、外部のモデルと外部の資源の活用、内部監査です。この記事に関係が深いのは、検証の原則です。検証は開発から独立した立場で行い、使用を始める前、重要な変更のとき、使用を始めた後の再検証を含むとされています。

さらに原則は、検証の結果を適切に文書化し、承認の判断基準として考慮すべきだとしています。検証の項目には、モデルの記述書、手法、仮定、データ、開発の証跡、実装、使用、継続的な監視の評価などが例として挙がっています。検証で欠陥が見つかったモデルについては、検証の側が使用の制限や停止を求める権限を持つべきだとも書かれています。

原則の本文には、AIや生成AIに限った規定はありません。ただ、モデルがリスクをもたらし得る限り管理すべきという考え方に立っているので、生成AIを使ったモデルも、この枠組みの外にあるとは考えにくいでしょう。顧客向けの生成AIに関する金融庁の論点整理は別の記事（金融庁のAI論点整理を社内に落とす）で扱っているので、ここでは立ち入りません。

生成AIで、検証の文書づくりが追いつかなくなる理由

従来の信用のスコアのモデルなら、1本のモデルを数か月かけて作り、検証の報告書も年に一度の見直しで更新すれば足りました。生成AIを使った業務では、この前提が崩れます。

理由の一つは数です。問い合わせの要約、文書の分類、不正の兆しの検出と、用途ごとにモデルや指示文の組み合わせが生まれ、台帳に載せる単位が一気に増えます。二つめは変わる速さです。外部の基盤モデルは提供元の都合で更新され、自社が何も変えていなくても、重要な変更に当たるかを判断し直す必要が出てきます。

三つめは、検証の中身そのものが従来と違うことです。生成AIの出力は毎回同じとは限らず、正解の数字と比べる過去データによる検証が使いにくい場面があります。どの観点で何件を試せば足りるかの考え方から作る必要があり、そのぶん文書に書く説明も長くなります。

こうした状況で、検証の担当が報告書の体裁づくりに時間を取られると、本来の仕事である結果の読み解きと判断に割ける時間が減ります。ValidMind のような基盤が狙うのは、記録を作る時間を減らして、判断に使う時間を取り戻すことだと捉えると、導入の目的を取り違えずに済みます。

開発・検証・承認の三者をどう分けるか

金融庁の原則は、役割の分け方として3つの防衛線の考え方を示しています。第1線はモデルを所管し開発や使用に直接責任を持つ部門、第2線は第1線をけん制して独立した立場から監視と検証を行う部門、第3線は内部監査部門です。承認は、検証の結果を踏まえて行う別の手続きとして位置づけられています。

検証の文書をAIで作るとき、この三者のどこに何が入るかを先に決めておくと、後で記録の持ち主が曖昧になりません。

役割	持つもの	AIに任せてよい作業	人が持つ判断
開発（第1線）	モデルの記述書、開発の証跡、性能のテストの結果	テストの実行、結果の取り込み、記述書の下書き	モデルの目的と使用の制限の記述、開発の完了の判断
検証（第2線）	独立した検証の結果、所見、使用の制限の提案	検証テストの実行、結果の集計、規制の要件との照合の下書き	所見の判定、使用の制限や停止の要求、再検証の要否
承認	使用開始の可否、条件付きの承認の条件	承認の記録の整理、期限の通知	承認するかどうか、条件と期限の決定
監査（第3線）	管理の態勢全体の評価、監査の所見	記録の抜き出し、手続きの漏れの候補の提示	態勢が有効かの評価と報告

表の右から二つめの列は、ValidMind のような基盤が速くできる作業の範囲です。一番右の列は、どの役割でも人が書いて人が決めることになります。この線が文書の上で見える形になっていれば、AIで作った部分と人が判断した部分を、監督や監査で分けて説明できます。

開発者と検証者を、同じ人にしない

文書づくりが自動化されると、起きやすくなる失敗があります。開発の担当が、自分でテストを回し、自分で検証の報告書の下書きを作り、そのまま提出してしまうことです。仕組みのうえでは、テストの実行と文書の生成は誰でもボタン一つでできてしまうからです。

金融庁の原則は、検証者が第1線から十分に独立してけん制を発揮できる態勢を求め、その独立性はレポーティングラインの分離や評価の仕組みで確保することが考えられるとしています。第1線が検証を行うことも許容されますが、その場合は第1線の検証結果を第2線が評価すべきとされています。

基盤を入れるときは、この分離を権限の設定で表します。開発の役割の人は、検証の報告書の所見の欄を書けない、承認の操作ができない、という形です。ValidMind の公式の文書でも、管理者・開発者・検証者で入口を分けて説明しています。小さな会社で人が足りない場合でも、同じ人が開発と検証の両方の欄に署名する状態だけは作らないことが最低限の線です。

人が足りずに分けきれないなら、検証の一部を外部の専門家に委ねる、重要度の低いモデルだけ第1線の検証を認めて第2線が評価する、といった手当てを原則の考え方の範囲で選びます。どの手当てを選んだかも、記録に残します。

AIに作らせてよい記録と、人が書く記録

検証の文書は、一つの報告書のように見えて、性格の違う記録の束です。AIに作らせてよいかどうかは、記録の性格で決めると線を引きやすくなります。

記録	性格	AIの役割	人の役割
テストの結果の一覧と図	事実の記録	実行と集計と整形	対象と条件が正しいかの確認
テストの結果の要約	事実の言い換え	下書き	要約が結果と食い違っていないかの確認
規制の要件との照合表	当てはめ	対応する箇所の候補の提示	当てはまるかの判断
節ごとのリスクの評価	評価	候補の提示まで	評価の確定と根拠の記述
検証の所見と結論	判断	使わない	書く・署名する
使用の制限・承認の条件	判断	使わない	決める・記録する

上の2行は、AIが作っても中身が変わりにくい事実の記録です。下の2行は、検証者と承認者の判断そのもので、AIが作った時点で「独立した検証」の証拠ではなくなります。難しいのは真ん中の2行で、AIの候補を人が確かめた跡を残すことで初めて判断の記録になります。

ValidMind の公式の文書にある、節ごとにリスクの評価を作る機能や、報告書を規制の要件と照らす機能は、ちょうどこの真ん中の行に当たります。提供元のAI利用方針も、出力は誤りや不適切な内容を含み得るとし、人の確認なしに出力だけで判断しないよう利用者に求めていることは押さえておきたい点です。

所見とAIの下書きの境目で起きる失敗

真ん中の行で起きる失敗には、決まった形があります。どれも、AIの下書きがそのまま判断の記録に変わってしまう形です。

• AIが作ったリスクの評価の文章を、検証者が読んだだけで所見の欄に貼り付ける
• 規制の要件との照合で「該当なし」とAIが出した項目を、根拠を確かめずにそのまま閉じる
• テストの結果の要約が元の数字と食い違っているのに、要約の側だけを報告書に載せる
• 誰がAIの下書きを確かめたかが記録に残らず、作成者の欄に基盤の名前だけが残る

これを防ぐには、AIの下書きと人の所見を、文書の上で別の欄に置くのが確実です。下書きの欄はAIが作ったと分かる形で残し、所見の欄は検証者が自分の言葉で書く。下書きを書き換えて所見にする運用にしないことで、後から読む人がどこまでが人の判断かを見分けられます。

もう一つの手当ては、AIの下書きが外れた例を記録しておくことです。どの種類のモデルで、どの節の下書きが人の判断と食い違ったかが溜まると、AIに下書きを任せる範囲を狭めるか広げるかの判断材料になります。

検証の基盤に何が渡るか

金融機関が外部の基盤を入れるとき、最初に問われるのはデータの行き先です。2026年10月時点の公式の文書では、ValidMind は顧客のデータセットやモデルそのものを保持しないとしています。

文書づくりのために基盤に取り込まれるのは、データセットとモデルのメタデータ、品質と性能の指標、テストの出力、テストで作った図だと説明されています。また、テストを回すライブラリの窓口からは個人を特定できる情報を送らないとしています。生のデータを外に出さずに、結果だけを基盤に集める設計です。

ただし、確かめられなかった点もあります。大規模言語モデルを使う機能で、テストの結果や台帳の情報がどの提供元のモデルに渡るのか、その提供元で学習に使われるのか、機能を止められるのかは、公式の文書と利用方針の範囲では書かれていませんでした。利用方針には、AI機能とのやり取りは品質や安全のために記録・監視されるとあります。

配置の形は、複数の会社で共用するクラウド（アマゾン、マイクロソフト、グーグルの基盤の上）と、他社と資源を共有しない専用の環境の2つが示されています。テストの出力そのものに顧客の情報が混ざらないかは、基盤の説明とは別に、自社のテストの作り方の問題として確かめる必要があります。図の中に個別の取引が写っている、といった形で混ざることがあるからです。

監督や監査に出せる形を保つ

検証の記録は、作った時点ではなく、数年後に監督や監査で読まれたときに役目を果たします。そのときに問われるのは、報告書の出来ばえより、誰が、いつ、何を見て、何を決めたかがたどれるかです。

AIで作った記録を含む文書でたどれるようにするには、少なくとも4つを残します。テストを回した日時と、使ったモデルとデータの版。AIの下書きを作った機能と、その時点の設定。下書きを確かめた人と、確かめた範囲。所見を書いた人、承認した人、その日付と条件です。

このうち最初の2つは基盤が自動で残せる種類の記録ですが、後の2つは人の操作の記録です。確かめた人の欄が空欄のまま承認まで進めない、という流れを承認の手続きの側に組み込んでおくと、記録の抜けを仕組みで防げます。ValidMind の公式の文書にも承認の流れを組む機能の案内がありますが、どの欄を必須にするかは使う会社が決めることです。

保存の期間は、監督の対応と社内の規程で決めます。基盤との契約が終わったときに、記録をどの形で取り出せるかも契約の前に確かめておきます。基盤をやめたら検証の記録が読めなくなる、という状態は、監督の対応では致命的です。

モデルが更新されるたびの再検証

生成AIを使うモデルで一番手間がかかるのは、最初の検証より、その後の再検証です。金融庁の原則は、重要な変更が加えられる場合に検証の必要性を第2線が検討すべきとし、再検証の頻度と優先順位はモデルのリスクの格付けと整合させるべきだとしています。

外部の基盤モデルを使う場合、変更は自社の外から来ます。次の順番で流れを作っておくと、更新のたびに慌てずに済みます。

出力が変わる前提で業務を止めない組み方そのものは、別の記事（モデルが更新されても業務を止めない方法）で扱っています。ここで大事なのは、再検証の要否と結論は、テストを自動で回せるようになっても人が決めるという点です。

外部のモデルと生成AIの基盤モデルの扱い

金融庁の原則は、外部のベンダーのモデルや外部の資源を使う場合にも、適切な統制を行うべきだとしています。ベンダーのモデルは仕様の詳細が公開されていないことが多く、手法や仮定やデータについて限られた情報しか持てないことが多いが、それでも自社のモデル・リスク管理の枠組みに入れるべきだ、という考え方です。

生成AIの基盤モデルは、まさにこの状況に当たります。中身を検証することはできないので、自社の用途での振る舞いを、自社のテストで確かめることが検証の中心になります。ValidMind のような基盤は、このテストを回して記録する道具として使えます。

ここで注意したいのは、検証の基盤そのものも外部の資源だという点です。基盤のAI機能が作った下書きを検証の材料にするなら、その機能の誤りの傾向も把握しておく必要があります。検証に使う道具を、検証しないまま信じる状態は、原則の考え方から見て説明しにくくなります。

実務では、基盤のAI機能について、どの種類のモデルの、どの節の下書きに使うかを決め、外れた例を記録する、という最小限の管理から始めるのが現実的です。前の節で触れた外れた例の記録が、そのまま基盤の評価の材料になります。

エージェントの統制へ広げる動き

ValidMind は、モデルの検証からAIエージェントの統制にも手を広げています。2026年6月22日の報道では、エージェントの行動を統制するオープンソースの Atryum をGitHubで公開し、その上に作った企業向けの ValidMind Agent Authority の早期提供を始めたとされています。

報道によれば、Atryum はエージェントの実行の経路に入り、外部の道具を呼び出す操作を受け止めて方針と照らし、必要なら人に判断を回し、判断ごとに監査用の記録を残す仕組みです。資格が正しいかだけでなく、その行動がエージェントの役割と権限に合っているかを見るとされています。

ただし、企業版の機能として報じられている項目には計画中のものが含まれ、早期提供の段階でどこまで使えるかは確かめられませんでした。早期提供の機能は、検証の文書づくりの判断材料には数えないのが安全です。この記事の主題は検証の記録なので、エージェントの統制はここまでにとどめます。

金融以外の会社に当てはまる範囲

金融庁の原則が直接の対象としているのは大手の金融機関ですが、考え方の一部は金融以外の会社にもそのまま使えます。特に当てはまるのは、AIの出力が顧客への判断や価格、採用、与信に近い判断に使われる場合です。

取り入れやすいのは3つです。一つは、作った人と確かめた人を分けること。二つめは、確かめた結果と使ってよいという判断を、別々に記録すること。三つめは、外部のモデルが更新されたときに、確かめ直すかどうかを決める人を決めておくことです。専用の基盤がなくても、この3つは表計算と承認の手続きで始められます。

逆に、そのまま持ち込まないほうがよいのは、文書の量と形式です。金融機関の検証の報告書は監督の対応を前提に作られているので、同じ厚さの文書を全部のAIの用途に求めると、現場は使うこと自体を避けるようになります。リスクの高い用途だけに厚い記録を求め、低い用途は簡単な記録で済ませる、という段階の付け方を決めておきます。

社外の取引先からAIの中身の説明を求められる場面では、同じ便で扱った社外向けの説明資料の記事（Cranium の AI Card）が参考になります。検証の記録は社内の判断の証拠、社外の説明資料は取引先への開示、と役割が違うので、同じ文書で両方を済ませようとしないことが大切です。

よくある質問

検証の報告書をAIで作ったら、監督の対応で問題になりますか

原則は、検証が独立して行われ、結果が文書化されて承認に使われることを求めています。AIで下書きを作ること自体を禁じる規定は見当たりませんが、所見と結論を誰が判断したかが記録から分からなければ、独立した検証の証拠として説明しにくくなります。個別の当てはめは、監督の窓口や専門家に確かめてください。

テストを回すのも検証者でなければいけませんか

テストの実行そのものは、仕組みに任せても、開発の側が回しても構わない場合があります。大事なのは、テストの対象と条件が妥当かを検証者が確かめ、結果の読み解きと所見を検証者が書くことです。

小さな金融機関でも、この種の基盤は要りますか

モデルの数が少ないうちは、台帳と承認の記録を表計算と社内の手続きで持つ方法でも回ります。モデルの数が増え、再検証の手間が人の手で追いつかなくなった時点が、基盤を検討する目安になります。

基盤のAI機能を止めて、テストと記録だけを使えますか

2026年10月時点の公式の文書と利用方針では、AI機能を止める方法は確かめられませんでした。AI機能を使わない運用を前提にするなら、契約の前に提供元に確かめてください。

まとめ

金融庁の原則は、モデルの検証を開発から独立した立場で行い、その結果を文書化して承認の判断基準にすることを求めています。生成AIでモデルの数と変更の頻度が増えるほど、この文書づくりが追いつかなくなり、ValidMind のように検証のテストと文書づくりを自動化する基盤が出てきました。公式の文書では、顧客のデータセットやモデルは保持せず、テストの結果と指標と図を取り込むとしていますが、AI機能のデータの行き先や止め方は確かめられませんでした。テストの実行・結果の集計・文書の下書きはAIに任せ、検証の所見・モデルの承認・使用の停止は人が持つ。開発者と検証者を同じ人にせず、AIの下書きと人の所見を別の欄に置き、更新のたびの再検証の要否を人が決める。この3つを決めてから、どの記録をAIに作らせるかを選んでください。

• 製品の機能と提供状況は、ValidMind の公式サイト・公式の文書（概要・大規模言語モデルの機能・データの扱い）・AI利用方針を2026年10月23日に確かめた範囲と、2026年6月22日の報道に基づきます
• 金融庁の原則の内容は、2021年11月12日公表の「モデル・リスク管理に関する原則」と2024年12月12日公表のプログレスレポート(2024)の範囲で書いています
• 料金の体系、日本語の管理画面と国内の窓口、AI機能のデータの行き先と学習利用、AI機能の止め方は公式の資料で確かめられなかったため、契約の前に提供元に直接確かめてください

※本記事にはAIが活用されています。編集者が確認・編集し、可能な限り正確で最新の情報を提供するよう努めておりますが、情報の完全性、正確性、最新性、有用性等について保証するものではありません。本記事の内容に基づいて行動を取る場合は、読者ご自身の責任で行っていただくようお願いいたします。