AI統制の枠組み比較：NIST、ISO 42001と銀行の要件

概要

• NIST AI RMFは任意のリスク枠組みです。一方、ISO/IEC 42001は認証可能なAIマネジメントシステム規格です。銀行には両方が必要なことがよくあります。
• 金融サービス向けAI RMFは、230の統制目標でNISTを拡張しますが、必要な証拠を定義するだけで、生成はしません。
• 実際のガバナンスはワークフロー層にあります。実行ごとの監査ログ、RBAC/SSOによる役割別のアクセス制限、規制対象の判断における決定論的な出力です。
• 銀行は、現在のAIツールがこれらの統制を標準で提供するか監査すべきです。Jinba Flowは、枠組みが期待する監査ログ、アクセス統制、80%がルールベースの決定論的な実行を提供します。

AIガバナンスの実務上の意味を理解するには、枠組みの文書を読むだけでは足りません。銀行や金融機関にとって、引用している枠組みが、AIワークフロー実行時に起きることを実際に管理するのか、それともガバナンスが方針の層で止まり、実行は制御されないままなのかが問題です。

この隔たりは現実のもので、現場の担当者によって十分に記録されています。AIリスクの議論で繰り返し見られるのは、ガバナンスは導入で終わる一方、リスクはそこで始まるというパターンです。モデルは変化し、チームの人員は入れ替わり、稼働開始後は誰もシステムを所有しません。問題が起きると、責任の所在は曖昧です。これは枠組みの原則の失敗ではありません。実運用に落とし込めていないことの失敗です。

本記事は、主要な2つの枠組み、金融機関が実際に使う業界固有の層、そして枠組みが要求するものの大半の基盤が提供しないワークフロー単位の統制を説明します。

NIST AI RMFとISO/IEC 42001：全体像

この2つは、競合する代替案ではありません。異なるレベルで機能し、異なる目的を果たします。

ISO/IEC 42001は、認証可能な初のAIマネジメントシステム規格です。情報セキュリティのISO 27001と同様に、組織は要件に沿ってAIマネジメントシステム（AIMS）を構築し、正式な認証を取得できます。鍵となるのは認証です。ISO 42001は、検証・監査可能な資格を提供し、契約上の義務を満たし、規制当局に適切な注意を払っていることを示し、DORAのような業界規則やSOC 2のような保証制度と並んで機能できます。

一方、NIST AI Risk Management Frameworkは任意のリスク管理枠組みで、認証可能な規格ではありません。統治、把握、測定、管理という4つの中核機能が、システムのライフサイクル全体でAIリスクを特定・管理する体系的な基準を提供します。米国の規制当局は、基本的な期待水準として参照することが増えていますが、認証を付与するものではありません。

実務上、金融機関は一方を選んで他方を無視するのではありません。大規模な機関は、市場や規制当局への訴求価値からISO 42001認証を目指しながら、NIST AI RMFを社内リスクプロセスの構造的な基盤として使う場合があります。ただし、どちらも単独では、銀行固有のリスク特性に対して十分ではありません。

銀行が実際に使うもの：FS AI RMF

一般的な枠組み比較は、金融機関に最も重要な仕組みを省いています。金融サービスAIリスク管理枠組み（FS AI RMF）は、CyberRisk Instituteが、100超の金融機関の意見を取り入れ、NISTに整合させて開発しました。一般的な枠組みが十分にカバーしない、偏り、不透明さ、サイバーセキュリティの危険、金融サービス固有のシステム間依存のリスクに対応します。

FS AI RMFは構造上NIST AI RMFに整合し、230の統制目標で拡張しています。地域銀行や信用組合から、国内・多国籍銀行、保険会社、投資会社、そしてそれらの外部提供者まで、金融機関全体を明確に対象として設計されています。

実装は、単一の方針文書ではなく、段階的なツールキットを通じて行います。

1. AI導入段階の質問票：金融機関全体の現在のAI成熟度を評価します。
2. リスクと統制のマトリクス：導入段階ごとに整理された230の統制目標を含みます。
3. ガイドブックと統制目標の参照ガイド：統制の例を示し、各目標の有効な証拠となるものを指定します。

最後の「有効な証拠」という言葉が重要です。FS AI RMFは、監査担当者や規制当局が何を見ることを期待するかを定義します。その証拠は生成しません。統制は、記録、監督、説明責任の要件を説明します。AIワークフローを動かす基盤が、それらを生成しなければなりません。

欠けている層：方針から運用のガバナンスへ

枠組みは文書です。ガバナンスは行動です。現場で一貫して見られるのは、承認で止まり、実行をほとんど管理しない枠組みが多すぎるというパターンです。統制は書類上にありますが、必要な証拠はシステムにありません。

これは理論上の懸念ではありません。EU AI Actは、高リスクAIシステムの監査可能性を厳格な法的要件にしています。第12条は記録の保持を義務付けます。第19条は、提供者に自動ログ保持の義務を課します。この法律は、監査可能なログが存在し、システムの運用期間を通じて保持されることを前提とします。信用スコアリング、KYC処理、融資審査など、金融サービスのAIは、この分類で日常的に高リスクに該当します。

コンプライアンスの隙間は構造的です。銀行がISO 42001認証を取得し、FS AI RMFの230の統制を参照していても、AIツールがログを生成しなければ、これらの統制やEU AI Actが求める実行ごとのログを生成する仕組みを欠いたままになります。

欠けているのは、ワークフロー単位のガバナンス層です。枠組みは説明しても、実現の仕組みはほとんど指定しない、3つの運用要件からなります。

• 実行ごとの監査ログ：すべてのワークフロー実行の変更不能な記録で、入力、出力、行った判断、適用したモデルやルール、実行を開始したユーザーを保存します。これがFS AI RMFの求める「有効な証拠」です。これがなければ、コンプライアンス審査は記憶に基づく再構成となります。
• 役割で制限されるワークフローのアクセス：構築と実行を厳格に分けます。技術チームが設計、テスト、バージョン管理を行い、業務ユーザーは制御された画面で承認済みのワークフローのみを実行します。RBAC、SSO、ディレクトリ連携で強制されるこの分離が、稼働後に誰もモデルを所有しなくなることで生じる責任の隙間への、運用上の回答です。
• 決定論的な出力：KYC確認、融資計算、コンプライアンス審査などの規制対象プロセスでは、同じ入力に対して出力が一貫し、再現可能でなければなりません。サンプリングの設定によって出力が変わる確率的なAIエージェントは、構造上、これらのワークフローに適しません。ガバナンスには、毎回同じ結果を生成するルールベースのロジックが必要です。

この3要件は理想論ではありません。規制当局が監査を期待し、FS AI RMFのような枠組みが有効な統制の証拠と定義するものです。AIを導入するすべての銀行が問うべきなのは、基盤がこれらを標準で生成するのか、それともガバナンスが運用上の裏付けのない方針上の主張にとどまるのかです。

ワークフロー層でガバナンスを運用する

Jinbaは、大規模な規制対象企業向けに作られた、SOC II準拠のAIワークフロー構築ツールです。銀行と金融機関を主な対象にしています。枠組みが要求しても、多くのAIツールが実装しない運用上のガバナンス層を提供する設計です。

基盤は構築と実行を分けます。Jinba Flowは、技術系および一定の技術知識を持つチームがワークフローを設計、テスト、バージョン管理、導入する環境です。Jinba Appは、業務ユーザー向けの制御された実行画面で、内部のロジックにアクセスせず、対話画面から承認済みのワークフローを呼び出します。この構成は、ガバナンスの枠組みが構築者と運用者に割り当てる役割を直接反映する、職務分離を強制します。

上記の運用ガバナンスの3要件に対して：

監査可能性：Jinba Flowは、ワークフローを実行するたびに包括的な監査ログを提供します。各実行は、入力、出力、実行ユーザーの記録を生成します。これは、FS AI RMFの統制目標参照ガイドが期待し、EU AI Actの第12条が義務付ける証拠の層です。事後に再構成するのではなく、自動的に生成されます。

アクセス制御：役割に基づく権限、SSO、Active Directory連携が基盤に組み込まれています。ワークフローへのアクセスは個別に管理せず、チーム単位で役割により制限します。これにより所有の隙間を埋めます。承認済みのワークフローは、ガバナンスの証跡のない個人のノートPC上のツールではなく、アクセスが定義された共有資産です。

決定論的な実行：Jinbaの構成は80%がルールベースです。ワークフローは、同じ入力に対して一貫した再現可能な出力を生成します。これにより監査可能で、規制対象の判断に適し、出力の一貫性を保証できない確率的AIエージェントとは構造的に異なります。決定論的な構成には、大きな費用優位性もあります。大規模運用では月額$5〜$20で、同等の確率的エージェントの$300以上に対し、LLMトークン費用は15〜60分の1になります。企業のAI支出に対するCFOの懸念に直接対処します。

隔離環境が必要な金融機関に向けて、Jinbaはオンプレミスとプライベートクラウドへの導入をサポートします。AWS Bedrock、Azure AI、自社運用モデルによる非公開のモデル運用も含まれます。

枠組みを超えて、管理された実行へ

金融機関の有効なAIガバナンスは、単一の枠組みの選択ではなく、3つの部分からなる構造です。

1. NIST AI RMFと、認証が必要な場合はISO/IEC 42001を使い、方針の基礎を確立します。
2. FS AI RMFの230の統制目標を通じて、業界固有の統制層を実装します。
3. それらの統制をワークフロー単位で実運用に落とし込む基盤を導入します。監査ログを生成し、アクセス規則を強制し、規制当局や監査担当者が検査する決定論的な出力を提供します。

どの枠組み文書を棚に置くかという議論より、本番で動くシステムが監査可能な証拠を生成するかが重要です。ガバナンスの劣化は現実にあり、測定可能です。実行インフラに組み込まれない統制は、チームの変更、モデルの更新、ワークフローの修正のたびに弱まります。枠組みはこのリスクを挙げます。基盤はそれに対処しなければなりません。

AIガバナンス戦略を構築・見直しする銀行の実務的な出発点は、現在のAIツールが実行ごとの監査ログを生成し、チーム単位で役割に基づくアクセスを強制し、規制対象の判断に決定論的な出力を提供するかを、率直に評価することです。どれか1つでも答えが「いいえ」なら、方針の層で枠組みに準拠しても、隙間は埋まりません。

枠組みへの整合から、管理された本番運用へ移るため、JinbaのAIコンサルティングチームは、無料のAI戦略評価を提供します。MUFGとMitsubishi Bankを含む約70件の企業導入実績に裏付けられ、戦略と、動く監査可能なワークフローに至る導入の道筋の両方を扱います。

金融サービスのAIガバナンスに関するよくある質問

NIST AI RMFとISO/IEC 42001はどう違いますか？

NIST AI RMFは、統治、把握、測定、管理を軸に整理された任意のリスク管理枠組みです。一方、ISO/IEC 42001は認証可能なAIマネジメントシステム規格です。銀行はNISTを社内リスク管理の基盤として使い、契約上・規制上の保証のためにISO 42001認証を目指すことがよくあります。

AIを使う銀行に、ISO/IEC 42001認証は必須ですか？

いいえ。ISO/IEC 42001認証は、現在、銀行に一律に課される法的要件ではありません。ただし、適切な注意を払っていることを示し、規制当局の信頼を支え、顧客や取引先が認証済みのAI管理統制を求める場合に、契約上の義務を満たせます。

金融サービスのFS AI RMFとは何ですか？

FS AI RMFは、金融機関向けに設計された、NIST AI RMFの業界固有の拡張です。偏り、不透明さ、サイバーセキュリティ、システム間依存を扱う230の統制目標を含み、銀行、保険会社、それらの外部提供者向けに実装ツールキットを提供します。

AIガバナンスで、実行ごとの監査ログが重要なのはなぜですか？

実行ごとの監査ログは、各AIワークフロー実行の変更不能な記録を作り、入力、出力、判断、開始したユーザーを含みます。FS AI RMFのような枠組みや、EU AI Actのような法的要件の下で、規制当局と監査担当者が期待する中核的な証拠です。

銀行は、AIの方針から運用のガバナンスへどう移れますか？

銀行は、自動監査ログ、構築者と運用者を分ける役割別アクセス制限、規制対象の判断のための決定論的な出力という統制をワークフロー層に組み込むことで、AIガバナンスを実運用に落とし込みます。枠組みの要件を、方針文書ではなく監査可能な本番の証拠に変えます。

EU AI Actで高リスクとなる銀行のAI用途は何ですか？

信用スコアリング、KYC処理、融資審査、および類似の金融サービスAIシステムは、一般にEU AI Actで高リスクと分類されます。これらの用途には、より厳格な記録保持、ログ記録、人による監督の義務が生じます。

決定論的な出力とは何で、銀行のAIに重要なのはなぜですか？

決定論的な出力とは、同じ入力に対して一貫し、再現可能な結果です。確率的なAIエージェントは変動する結果を生成し、監査可能性、一貫性、規制上の説明を難しくするため、規制対象の銀行ワークフローで重要です。

銀行は、ガバナンスのためのAI基盤に何を求めるべきですか？

銀行は、内蔵された実行ごとの監査証跡、SSOまたはディレクトリ連携を備える役割に基づくアクセス制御、決定論的なワークフロー実行を求めるべきです。基盤は証拠を自動生成し、必要に応じてオンプレミスやプライベートクラウドなどの導入方式をサポートすべきです。