IT/FinTech

2026年10月19日

金融機関のAI導入に関する12の実務慣行とは？FinTech企業が確認すべきAIガバナンスと法的リスク

FSB最終報告書を踏まえ、取締役会監督・AI台帳・人による監督・サイバー・AIベンダー契約を実務から整理

法令・公的資料確認基準日：2026年10月19日　｜　柳澤法律事務所

先に結論

  • 2026年10月15日、金融安定理事会（FSB）は、金融機関による責任あるAI導入のための12の「Sound Practices（健全な実務慣行）」を最終化しました。金融庁も10月16日に公表を案内しています。
  • FSBの12慣行は、それ自体が日本の金融機関・FinTech企業に新たな罰則付き義務を直接課すものではありません。一方、FSBは取締役会・経営陣に対し、AIガバナンス、リスク管理、統制の整備・見直しに際して参照することを強く推奨しています。
  • 実務上の核心は「AIポリシーを作ること」ではなく、AI利用を台帳化し、重要性・リスクに応じて承認、データ管理、説明可能性、性能監視、人による監督、サイバー対策、外部AIベンダー管理を一つのライフサイクルとして回すことです。
  • 金融機関向けにAI・SaaS・APIを提供するFinTech企業やAIベンダーも、FSBの直接の義務主体と同一ではありませんが、第三者AI依存の管理を通じて、性能・透明性・データ品質・再委託・サプライチェーン・事業継続・監査協力等の説明や契約条件を求められる場面が増えることが想定されます。

1　FSB最終報告書が確定した意味

2026年10月15日、FSBは「Sound Practices for Responsible Adoption of Artificial Intelligence (AI): Final report」を公表しました。6月の市中協議文書を最終化したもので、金融機関がAIの便益を活かしつつ、AI固有のリスクを適切に管理するための12の実務慣行を示しています。金融庁も翌16日に公表を案内しました。

今回の最終報告書は、生成AI（GenAI）やエージェント型AI（agentic AI）を含むAIの急速な高度化を背景に、単発のモデル審査ではなく、組織全体のガバナンスとAIライフサイクル全体の管理を重視しています。FSBは、取締役会・経営陣が事業戦略、技術導入、リスク管理を検討する際に12慣行を参照することを強く推奨しています。

もっとも、12慣行は非拘束的・非処方的な実務ツールキットとして位置付けられています。各金融機関が、自社の規模、業務、AIの利用目的、リスクプロファイルに応じて比例的に取り込み、既存のサイバー・第三者リスク管理等の枠組みへ統合することが想定されています。したがって、「12項目を満たさなければ直ちに違法」という制度ではありません。

2　12の実務慣行を一覧で確認する

FSBの12慣行は、①組織全体のAIガバナンス（1～4）と、②AIライフサイクルのリスク管理（5～12）の二群に整理されています。実務では、次のように読み替えると社内統制へ落とし込みやすくなります。

※各Sound Practiceの日本語表記は、本稿による実務上の要約です。

No. FSBの実務慣行 企業実務への落とし込み
1 戦略的方向性と監督 取締役会・経営陣がAI導入を事業モデル、リスクアペタイト、経営戦略と整合させる。
2 ガバナンスと説明責任 責任者・承認権限・第一線／第二線／監査の役割を明確にする。
3 AIリスクの統合と利用記録 既存のリスク管理へAIリスクを組み込み、AI利用・評価・判断の記録を残す。
4 組織の適応力 技術・利用形態・事故・規制の変化に応じて統制と人材能力を更新する。
5 重要性・リスク評価 導入時だけでなく運用後も、用途の重要性とリスクを体系的に評価する。
6 AI選定プロセス 業務目的、技術要件、重要性、リスクを踏まえてモデル・システムを選ぶ。
7 データガバナンス 学習・テスト・利用データの正確性、完全性、一貫性、信頼性、安全性を管理する。
8 説明可能性と透明性 AIの説明可能性の違いを理解し、必要に応じ説明可能なAI又は代替統制を採用し、相手に応じた情報提供を行う。
9 性能管理 重要性・リスクに応じて性能評価、テスト、継続監視を行う。
10 人による監督 AIの重要性、リスク、自律性、複雑性、説明可能性に応じ、実効的な人の監督を設ける。
11 サイバー・ICTリスク管理 AI固有のサイバー・ICTリスクをテスト、演習、監視等に組み込む。
12 第三者AIリスク管理 外部AIについて性能、透明性、データ品質、サプライチェーン、集中リスク、事業継続を管理する。

3　日本企業にとって「新しい法律」ではないが、実務上は無視しにくい

FSBの最終報告書は国際的な実務慣行であり、日本でそのまま法令として直接適用されるものではありません。この点は、金融庁が2026年3月に公表した「AIディスカッションペーパー（第1.1版）」も、分析が初期段階であり、事業者との対話や今後の政策検討の起点と位置付けていることと共通します。

他方、日本では人工知能関連技術の研究開発及び活用の推進に関する法律（令和7年法律第53号。いわゆるAI法）が施行され、AI事業者ガイドライン第1.2版も公表されています。さらに金融機関については、業態ごとの業法・監督指針、個人情報保護、サイバーセキュリティ、外部委託・サードパーティ管理等の既存ルールが重なります。FSBの12慣行は、これら既存の法令・監督実務を置き換えるものではなく、「金融分野でAIをどの粒度で管理すべきか」を横断的に整理するベンチマークとして読むのが適切です。

特に金融庁AIディスカッションペーパー第1.1版は、顧客向けAIサービスについて、提供前の設計・事前検証、提供時の顧客説明・注意喚起、提供後の検証・モニタリング、それらを支えるガバナンスという流れを整理しています。FSBの最終報告書は、この国内の議論と方向性が重なる部分が多く、金融機関やその委託先がAI統制を説明する際の共通言語になり得ます。

4　最初に行うべきは「AI台帳」と重要性・リスク評価

FSBのSound Practice 3と5を実務へ落とすうえで、最初に必要なのは社内AIポリシーの長文化ではなく、AI利用の把握です。金融機関では、部署ごとの生成AI、顧客対応AI、審査・スコアリング、AML・不正検知、RPA・AIエージェント、システム開発支援、コールセンター要約など、AIの利用形態が分散しやすいためです。

AI台帳には、少なくとも利用目的、対象業務、モデル・サービス、提供者、入力データ、顧客・権利への影響、外部システムへの接続、最終判断者、重要性・リスク区分、導入承認、モデル変更、事故・苦情等を紐付けます。

重要性とリスクは同じ概念として一括処理しない方が実務上有用です。例えば、AIの誤りが融資・保険・投資・不正検知・顧客の権利に大きく影響する用途は重要性が高くなりやすい一方、同じAI技術でも社内文書の要約では影響が限定的なことがあります。重要性、データの機微性、自律性、外部影響、説明可能性、代替手段等を組み合わせて統制強度を変えます。

5　取締役会・経営陣は「AIを使うか」ではなく「どのリスクを受け入れるか」を監督する

Sound Practice 1は、AI導入を事業モデル、リスクアペタイト、戦略と整合させることを取締役会・経営陣の役割として明示しています。したがって、経営会議で個別ツールの機能説明だけを受けるのではなく、高影響用途の件数、重要な例外承認、重大事故・苦情、第三者依存、モデル変更、未解決リスク等を監督できる情報設計が必要です。

一方、全てのAI利用を取締役会が個別承認する必要があるという意味ではありません。低リスク用途は事前承認済み環境で運用し、高リスク・高影響用途や重大例外だけを経営レベルへ上げるなど、比例的なエスカレーション設計が現実的です。

6　説明可能性と人による監督は「形式的な最終承認」では足りない

Sound Practice 8は、AIごとに説明可能性の違いを理解し、必要かつ実行可能であれば、より説明可能なAIを採用するか、代替的な統制を検討する考え方を示しています。金融実務では、モデル内部を完全に説明できることだけを目標にするのではなく、判断に利用した主要データ、重要な評価要因、AIの限界、モデル・設定の変更、人がどこで判断したかを追跡できる状態を作ることが重要です。

Sound Practice 10の人による監督も、画面上で担当者が「承認」を押すだけでは十分とは限りません。人がAIの出力を理解・評価でき、必要な権限を持ち、AI判断を覆したり処理を停止したりできることが重要です。監督強度は、AIの重要性、リスク、自律性、複雑性、説明可能性に応じて変えるべきとされています。

特にAIエージェントが送信、取引、顧客通知、データ更新、コード実行等の外部行為を行う場合は、弊所としては、実行権限の上限、承認が必要な行為、金額・件数制限、停止方法、ツール呼出しログ、権限失効、モデル・プロンプト変更時の再評価を明確にすることが重要と考えます。これはFSBの原文をそのまま条文化するのではなく、人による監督とリスクベース管理を実装するための契約・システム上の方法です。

7　性能管理は導入前テストだけで終わらない

Sound Practice 9は、AIユースケースの重要性・リスクに比例した性能評価、テスト、継続監視を求める考え方です。生成AIではモデル更新やRAGデータの変更、プロンプト変更によって出力特性が変わるため、導入時の精度検証だけでは十分ではありません。

例えば、誤回答率、重要な禁止出力、有人切替率、人による修正率、苦情、誤検知・見逃し、モデル更新後の性能差等を、用途に応じたKPI・KRIとして監視します。数値が閾値を超えた場合の停止・縮退・再審査手順も決めておくと、監視が「測るだけ」で終わりません。

8　AIサイバーリスクは従来のITリスクに追加して考える

Sound Practice 11は、AI関連のサイバー・ICTリスクを管理し、必要に応じてAI固有のシナリオをテストや演習へ組み込むことを示しています。金融庁も金融分野のサイバーセキュリティ対策を継続的に更新しており、2026年にはフロンティアAIによる脅威変化やサードパーティ・サイバーリスクへの対応を進めています。

AIでは、従来の不正アクセス・情報漏えいに加え、プロンプトインジェクション、データ汚染、モデル・RAG参照先の改ざん、機密情報の出力、外部ツールへの不正な命令、AIエージェントの権限悪用などが問題になります。契約・技術・運用を分けず、AIの権限、データ、ネットワーク、ログ、停止手段、インシデント対応まで含むシナリオで検証する必要があります。

9　FinTech・AIベンダーに最も影響しやすいのは「第三者AIリスク管理」

Sound Practice 12は、金融機関が第三者AIへの依存リスクを管理する際、性能、透明性、データ品質、サプライチェーン、集中リスク、事業継続を重視することを示しています。ここは、金融機関向けにAI・SaaS・API・基盤モデル・審査支援・不正検知等を提供する事業者にとって特に重要です。

FSBの12慣行はAIベンダーに直接同じ義務を課す文書ではありません。しかし、金融機関が自らSound Practice 12へ対応しようとすれば、ベンダーから必要な情報や契約上の権利を確保しなければ管理できません。そのため、RFP、セキュリティ質問票、AI情報シート、SLA、委託契約、監査対応等に影響が及ぶ可能性があります。

10　AIベンダー契約で確認したい条項

FSB最終報告書を契約実務へ落とす場合、「AIサービスを提供する」という一般条項だけでは不十分です。特に金融機関向けBtoB契約では、次の項目を具体化することが有効です。

契約テーマ 確認したい内容
利用範囲・禁止用途 対象ユースケース、金融判断への利用範囲、顧客向け利用、禁止・制限用途、AIエージェントの権限範囲。
モデル・変更管理 利用モデル、バージョン、重大変更の通知、再評価期間、旧モデル継続可否、機能廃止。
性能・評価 評価指標、既知の限界、テスト資料、品質目標、継続モニタリングに必要なデータ提供。
透明性・説明協力 モデル・機能の概要、主要制約、金融機関の顧客説明・監査・当局照会への協力。
データガバナンス 入力データの利用目的、学習・改善利用、保存、削除、国外処理、データ品質、アクセス管理。
ログ・証跡 入力・出力・モデル版・設定・外部ツール実行等のログ取得可否、保存期間、事故時の提供。
セキュリティ・事故 AI固有リスクを含む安全管理、脆弱性、インシデント通知、原因分析、停止・切戻し、是正協力。
再委託・上流AI 基盤モデル、クラウド、サブプロセッサ等の関係、重要な変更、サプライチェーン管理。
監査・情報提供 質問票、監査資料、第三者認証、監査権・代替的保証、当局・内部監査への協力。
事業継続・出口 障害時の代替、サービス停止、モデル提供終了、データ返還・削除、移行支援、設定・ログの持出し。
責任分担 AI出力の確認責任、禁止用途違反、データ不備、モデル障害、第三者権利、損害・補償の範囲。

11　「ベンダーだから説明できない」は金融機関向けサービスでは弱くなりやすい

外部AIベンダー自身が基盤モデルの内部情報を全て保有しているとは限りません。基盤モデル、クラウド、データ処理、評価ツール等が多層化している場合、金融機関から求められる情報を自社だけでは回答できないことがあります。

そのためFinTech・AIベンダー側でも、上流ベンダーから取得できる情報、顧客へ開示できる範囲、開示できない事項と代替統制を整理しておく必要があります。「モデル内部は非公開」で終わらせず、性能評価、利用制限、セキュリティ、モデル変更、インシデント、ログ、データ処理等について何を説明できるかを標準化すると、金融機関の調達・監査へ対応しやすくなります。

特に複数の金融機関へ同じAI基盤を提供する場合、自社サービスへの集中が高まること自体が顧客側のリスクになり得ます。可用性、冗長化、復旧、代替手段、サービス終了時の移行支援について、技術設計と契約を一致させることが重要です。

12　金融庁AIディスカッションペーパーとの接続

金融庁は2026年3月3日、AIディスカッションペーパー第1.1版を公表しています。そこでは、金融機関におけるAI活用の現状と課題を整理し、金融庁AI官民フォーラムで得られた知見を基に、リスクマネジメント・ガバナンスの取組事例や規制適用上の論点を更新しています。

顧客向けサービスについては、①サービス提供前の設計と事前検証、②提供時の顧客への説明・注意喚起、③提供後の検証・モニタリング、④全体を支えるガバナンスという整理が示されています。FSBのSound Practice 5～10と重ねると、国内の金融実務でも「導入審査だけではなく運用後まで含むライフサイクル管理」が一層重要になっていることが分かります。

もっとも、金融庁ディスカッションペーパーも、そこに書かれた全項目が直ちに一律の法的義務になる文書ではありません。適用される業法・監督指針・個人情報保護法等を別途確認したうえで、FSB・金融庁資料をガバナンス設計と監督対話の参考にすることが重要です。

13　弊所の実務上の視点：「AI統制マトリクス」を一枚作る

FSBの12慣行を12個の別々の規程へ分解すると、現場では運用しにくくなります。弊所では、AIユースケースごとに、重要性・リスク、責任者、データ、説明可能性、人の監督、性能監視、サイバー、第三者依存、契約、変更・事故時の再審査を一枚で確認できる「AI統制マトリクス」を作る方法が有効と考えます。

確認軸 社内で決めること 残す証跡
用途・重要性 誰に何の影響を与えるAIか、禁止用途・条件付き用途 ユースケース登録、リスク評価
責任・承認 事業責任者、モデル責任者、法務・セキュリティ、例外承認者 承認記録、会議記録
データ 入力・学習・参照データ、品質、個人情報、保存 データ台帳、アクセス記録
説明・人の監督 誰に何を説明するか、人がいつ介入するか 説明資料、レビュー・override記録
性能・変更 評価指標、閾値、モデル変更時の再審査 評価結果、変更履歴
サイバー・外部依存 AI固有攻撃、上流モデル・クラウド、BCP・出口 テスト、監査資料、契約、演習記録

14　90日で進める実装ロードマップ

  • 第1段階：AI利用・提供サービスを台帳化し、未把握のシャドーAIを含めて現状を把握する。
  • 第2段階：重要性・リスクに応じてユースケースを分類し、高影響用途とAIエージェントを優先する。
  • 第3段階：取締役会・経営陣、事業、IT、データ、法務・コンプライアンス、セキュリティ、監査の責任分界を決める。
  • 第4段階：高リスク用途について、データ、説明可能性、性能、人の監督、サイバー、第三者依存のギャップを評価する。
  • 第5段階：AIベンダー契約、SLA、セキュリティ資料、AI情報シート、モデル変更・事故通知、出口条項を見直す。
  • 第6段階：KPI・KRI、モデル変更、事故・苦情、法令・ガイドライン改訂をトリガーとする継続モニタリングを開始する。

90日という期間は法令上の期限ではありません。重要なのは、自社のAI利用量・影響度に応じて優先順位を付け、台帳作成だけ、規程作成だけ、ベンダー質問票だけで止めず、実際に継続運用へ移すことです。

15　金融機関・FinTech企業向けチェックリスト

  • 自社で利用・開発・提供しているAIをユースケース単位で台帳化している
  • AIの重要性とリスクを分けて評価し、統制強度を変えている
  • 取締役会・経営陣へ報告する高リスクAI・例外・事故の基準を定めている
  • AIリスクを既存のオペレーショナルリスク、モデルリスク、コンプライアンス、サイバー等の枠組みへ接続している
  • 学習・テスト・利用データの品質、権限、保存、個人情報の取扱いを確認している
  • AIの限界、主要な前提、人の関与、顧客説明をユースケースごとに整理している
  • 人による監督が形式的承認ではなく、介入・停止・差戻しできる設計になっている
  • モデル更新、RAGデータ変更、用途変更、外部接続追加を再審査のトリガーにしている
  • 性能指標、苦情、人の修正率等を継続的に監視している
  • AI固有のサイバーシナリオをテスト・演習へ反映している
  • 外部AIについて、上流モデル・クラウド・再委託先を把握している
  • AIベンダーから性能、制約、データ処理、変更、事故、ログ等の情報を取得できる
  • ベンダー障害・提供終了・集中リスクに備えた代替・出口戦略がある
  • 金融庁AIディスカッションペーパー第1.1版とのギャップを確認している
  • FSBの12慣行を自社統制へ採用しない部分についても、その理由・代替統制を説明できる

16　よくある質問

Q1．FSBの12慣行に従わないと、日本で違法になりますか？

12慣行それ自体は、日本企業に罰則付きの新たな法的義務を直接課すものではありません。ただし、業態ごとの法令・監督指針・個人情報保護・サイバー・委託先管理等は別途適用されます。また、FSBが取締役会・経営陣に参照を強く推奨していることから、金融機関がAIガバナンスの妥当性を説明する際の重要な国際的ベンチマークになり得ます。

Q2．全てのAIに同じ審査・人の確認が必要ですか？

そのような一律運用は想定されていません。FSBは重要性・リスクに応じた比例的な管理を重視しています。低リスクの社内支援AIと、信用・取引・顧客対応に影響するAIでは、承認・監視・説明・人の監督を変えることが合理的です。

Q3．生成AIだけが対象ですか？

いいえ。報告書はAI一般を対象としつつ、生成AIやエージェント型AIの急速な進展も明示的に意識しています。従来型の予測・スコアリングAIも対象となり得ます。

Q4．FinTech・AIベンダーはFSBの12慣行の直接対象ですか？

報告書の中心対象は金融機関です。ただし、第三者AIリスク管理を通じ、金融機関の委託先・AIベンダーには、性能、透明性、データ品質、上流依存、事業継続等について情報提供・契約上の協力を求められる可能性があります。

Q5．人が最終承認すれば、AIリスク管理として十分ですか？

必ずしも十分ではありません。FSBは、AIの重要性、リスク、自律性、複雑性、説明可能性に応じて、適切かつ実効的な人の監督を求める考え方です。人がAI出力を理解・評価し、必要に応じて介入・停止・差戻しできることが重要です。

Q6．AIベンダーがモデル内部を開示できない場合、利用できませんか？

一律に利用できないわけではありません。説明可能性が限定される場合に、代替統制を検討する考え方も示されています。性能検証、人による監督、用途制限、ログ、変更通知、事故対応等を組み合わせて、リスクを管理できるかを評価します。

Q7．金融庁AIディスカッションペーパーとの関係は？

金融庁の第1.1版も、設計・事前検証、顧客説明、運用後の検証・モニタリング、ガバナンスを重視しています。FSB最終報告書は国際的な実務慣行として、国内の議論を補完する形で参照できます。

17　弁護士等への相談を検討すべき場面

  • 融資、保険、投資、与信、不正検知等の重要判断にAIを利用し、説明・人の監督・異議申立ての設計を確認したい
  • 金融機関向けAI・SaaS・APIサービスについて、AIガバナンス質問票や契約条項への対応を求められている
  • 外部AIベンダーのモデル・規約変更が頻繁で、再評価や顧客通知の責任分界を整理したい
  • AIエージェントに顧客通知、取引、データ更新、コード実行等の外部権限を与える予定がある
  • 基盤モデル・クラウド・再委託先が多層化し、上流サプライチェーンや集中リスクを説明しにくい
  • AI事故・誤判断・情報漏えい・顧客苦情が発生し、ログ保全、顧客説明、ベンダー責任、当局対応を整理する必要がある

18　まとめ

FSBが2026年10月15日に最終化した12の実務慣行は、金融機関に新たな一律の法的義務を直接課すものではありません。しかし、取締役会・経営陣による戦略的監督、AI利用の記録、重要性・リスク評価、データ、説明可能性、性能、人による監督、サイバー、第三者AI依存を一つの体系として示した点に実務的な意味があります。

金融機関では、AIポリシーの有無ではなく、AI台帳・リスク評価・承認・監視・契約・事故対応が実際に回っているかが重要です。FinTech・AIベンダーにとっても、金融機関が第三者AIリスクを管理できるだけの情報、契約、ログ、継続性を提供できることが、今後の調達・監査・提携でより重要になると考えられます。

柳澤法律事務所では、金融機関・FinTech企業・AIサービス提供者におけるAIガバナンスの構築、AI利用・提供に関する契約、委託・再委託、個人データ、AIエージェントの権限設計、事故対応等について、実際のサービス構成と業務フローを踏まえて検討します。

関連記事

主要な一次資料・公式情報

金融機関・FinTech企業のAIガバナンスに関するご相談

AI台帳・重要性／リスク評価、取締役会・経営陣の監督、人による監督、性能監視、AIサイバー対策、外部AIベンダー管理、AIサービス契約・SLA・監査対応などを、実際のユースケース・システム構成・委託関係に合わせて整理します。

お問い合わせ