2026年、銀行のコンプライアンスに適したAIエージェント・ガバナンスプラットフォーム4選

概要

• 主要な統計：2026年の関係当局共同ガイダンスは、エージェント型AIを従来の「モデル」定義の外に置き直しました。企業のAI支出は前年比108%増となり、従業員の最大57%が機密データをAIツールに入力しています。
• 主な学び：エージェント型AIは、もはや2011年のモデルリスク管理の手順書に沿いません。DORA、BaFin、米国の当局はいずれもこれを一般的なオペレーショナルリスクとして扱っており、導入形態の適合性と監査可能性が調達の実質的な関門になっています。
• 主なアクション項目：銀行に必要なのは階層化されたスタックです。構築とガバナンスの層、稼働中のエージェントを監視・制御する層、AI GRCレポーティング、そしてデータガバナンスとアクセス制御であり、ツール呼び出しのトレースと最小権限のログ取得を初日から組み込んでおく必要があります。
• 社内でエージェントワークフローを構築するチームへ： Jinba Flowは、80%がルールベースの構成、オンプレミス導入、ロールベースのアクセス制御（RBAC）とSSO、監査ログをワークフロー層に組み込んでおり、SR 11-7の改訂とDORAの証跡要件に直接応えます。

ショートリスト

• Jinba：オンプレミスまたは外部遮断環境での導入と、決定論的で監査可能な実行を必要とし、エージェントワークフローを社内で構築する銀行とそのエンジニアリングチーム向け
• Fiddler AI：本番環境ですでにエージェントを動かしており、それを観測し、ガードレールをかけ、レポートするためのコントロールプレーンを必要とする銀行向け
• AI GRC・監査証拠プラットフォーム：単一の構築環境ではなく、多数のエージェントツールと事業ラインを横断して規制当局に提出できるレポートを集約する必要があるコンプライアンスチーム向け
• データガバナンス・アクセス制御プラットフォーム：主たるエクスポージャーがDORAやGLBAの第三者リスクとICTの証跡にあり、エージェントが何を出力したかだけでなく、何を読み取り何に触れることを許可されていたかを証明する必要がある金融機関向け

銀行のコンプライアンス部門は、15年かけて習得してきたルールブックが、いま導入しようとしているものを対象にしていないことに気づき始めています。2026年4月17日、OCC、FRB、FDICは、2011年以降米国の銀行を規律してきたモデルリスク管理ガイダンスを書き換えました。この改訂は、生成AIとエージェント型AIを「モデル」の定義から明示的に除外しています。技術が新しすぎて従来のやり方では規制できない、という理由です。ただし、これは容認のサインではありません。専用の枠組みの代わりに、一般的なリスク管理とガバナンスの期待にエージェント型AIが服することになったというだけであり、AI固有のモデルリスクについての関係当局共同の情報提供依頼は今後控えています。一方、EUではDORAが2025年1月から適用されており、データに触れて行動を起こすAIエージェントはすべてICTシステムとして扱われます。ドイツのBaFinは銀行に対し、生成AIとLLMは別個の規制体系ではなく既存のDORAのリスク管理・テスト・第三者管理の枠組みに組み込まれる、と率直に伝えています。結果として生じているのは、除外という体裁をまとったコンプライアンスの空白です。だからこそ銀行はいま、エージェントが実際に何をしているかを統制するためのツール群を、既製品として買うのではなく組み立てているのです。

順位をつける前に、何を比較しているのかを定めておくと役に立ちます。

規制へのマッピング。そのプラットフォームが出力する証跡は、名前のついたどの規制（SR 11-7の改訂、DORA、GLBA、公正融資規則）を実際に満たすのか。そして、銀行が名指しできる規制当局に対応づけられるのか。ここを飛ばすと、召喚権限を持つ相手には準拠して見えないダッシュボードを買うことになります。

導入形態の適合性。クラウド専用か、オンプレミスか、外部遮断環境か。SOC 2の取得状況。データの所在地。Gartner自身がこの市場を整理する際の見立てでは、決め手となる問いはどのプラットフォームが「最良」かではなく、銀行が実際に必要とする導入形態にどのアーキテクチャの形が合うか、というものです。ここを誤ると、そのツールは調達を通りません。

スタックのカバー範囲。エージェントの検出と可観測性、ポリシーの実施とガードレール、AI GRCレポーティング、あるいは構築とガバナンスの層そのもの。ほとんどのプラットフォームはこのうち1つか2つを担うだけで、4つすべてを覆うわけではありません。どの層を埋めるツールなのかを把握しておけば、重複した契約を5つ抱えたり、穴の空いた1つを選んだりせずに済みます。

成熟度と外部からの裏づけ。資金調達、名指しできる規制への適合、あるいはGartnerのようなアナリストのカテゴリーへの掲載が、ベンダー自身のマーケティング以外の情報で裏づけられているか。18か月で消えるガバナンス層は、ガバナンス層がない状態よりも悪いからです。あると錯覚させるだけの存在になります。

1. Jinba：エージェントワークフローを自ら構築・運用する銀行向け

本人確認、融資の引受査定、契約書レビューをエージェントで回している銀行は、SR 11-7の問題の特定の形に直面します。改訂によって狭められた「モデル」の定義（「統計学・経済学・金融の理論を適用して入力を定量的な推計に変換する、複雑な定量的手法、システム、またはアプローチ」）は、決定論的なルールベースのプロセスを明示的に除外しています。これはアーキテクチャ上の本物の分岐点です。確率的なエンドツーエンドのLLMチェーンとして構築されたエージェントは、除外規定ができた後も、旧来の枠組みの趣旨に照らして「モデル」に当たるのかという曖昧さを引きずります。大部分が決定論的なルールベースのワークフローとして構築されたエージェントであれば、その上乗せ規制の外側に位置するという主張がはるかに通りやすくなります。だからこそ、決定論的か確率的かという選択は実装上の細部ではなく、銀行が最初に下すガバナンス上の判断になっています（当社の解説「決定論的ワークフローが監査対応とLLMコストを同時に解決する理由」もご覧ください）。

Jinbaはその分岐点の上に築かれています。SOC 2に準拠したYC出資のワークフロービルダーで、規制産業の大企業（従業員2万人以上の銀行や保険会社が中心的な対象）に向けたものです。そのワークフローは設計上80%がルールベースで、残るエージェント的な層は、本当に判断を要する工程だけに絞られています。この決定論的な中核はコンプライアンスの後付けではありません。銀行のモデルリスク部門がワークフローを指し示し、新たに曖昧になった側ではなく除外される側に近いと主張できる根拠そのものです。導入形態の面では、Jinbaは外部遮断環境向けにオンプレミスで稼働します。これは、生成AIとLLMの利用を既存のICTリスク管理・テスト・第三者管理の枠組みに組み込むというDORAとBaFinの要求に直接効いてきます。オンプレミス導入であれば、その証跡は銀行自身の管理領域の内側に留まり、第三者クラウドを経由して、それ自体がDORA上の第三者リスクになることもありません。同プラットフォームはRBAC、SSO、Active Directory連携、監査ログを標準で備えており、これがDORA第II章とGLBAの双方が証跡として拠り所にするアクセス制御の層になります。

スタックの中でJinbaが位置するのは構築とガバナンスの層であり、すでに別の場所で動いているエージェントを観測する層ではありません。2つの製品、Jinba FlowとJinba Appによって、技術者と準技術者のチームはチャットまたはビジュアルエディタでワークフローを構築し、API、バッチ処理、MCPサーバーとして公開できます。そのうえで、非技術者の業務部門ユーザーが自動生成されたフォームから同じワークフローを実行できます。ワークフローも、その権限設定も、監査証跡も、誰か一人のノートPCの中ではなくチーム全体で共有されます。このチーム単位という違いは、Claude Coworkのようなツールと比べたときに効いてきます。Anthropic自身のドキュメントは、Claude Coworkに監査ログがなく、規制対象の業務向けには作られていないことを認めています。Jinbaの答えは、後から取り付けるのではなく、ワークフロー層そのものにガバナンスと共有を組み込むことです。この比較を具体的に検討している銀行、あるいはオンプレミス導入全般を検討している銀行には、オンプレミスでのClaude導入の選択肢に関するガイドが、導入の論点を直接扱っています。

訴求のもう半分はコストです。2026年、企業のAI支出は前年比108%増となりました。Jinbaの決定論的なアーキテクチャは、規模を広げた状態でワークフローあたり月5〜20ドルで動きます。同じ仕事を確率的なエージェントにやらせれば月300ドル以上です。これは、ClaudeやOpenAIのAPI利用料に対するCFOの反発への、プロンプト調整ではなく構造による答えです。

利点：

• 決定論的で80%がルールベースのアーキテクチャは、2026年の改訂が「モデル」定義からルールベースのプロセスを除外した点と整合する
• オンプレミスと外部遮断環境での導入は、AIリスクを外部クラウドに回さず既存のICT枠組みに組み込めというDORA・BaFinの要求に合致する
• RBAC、SSO、Active Directory、監査ログを標準で備え、DORAとGLBAの双方が求めるアクセス制御の証跡が得られる
• 規模を広げた状態で、同等の確率的エージェントに比べてトークンコストが15〜60分の1

欠点：

• 構築とガバナンスのためのプラットフォームであり、他所で構築・導入されたエージェント向けの独立した可観測性層やGRCレポーティング層ではない。すでに他のツールに散らばったエージェントを抱える銀行は、別途、検出と可観測性の層を併用する必要がある
• 主要市場と事例の厚み（売上のおよそ80%を占める日本）から、米国の銀行規模の導入に関する実績は、カテゴリーが確立した可観測性ベンダーに比べて薄い

適した相手：エージェントワークフローをゼロから構築しており、コンプライアンス上の説明を後付けではなくアーキテクチャに織り込みたい銀行と、それを支えるエンジニアリングチーム。

2. Fiddler AI：すでに本番稼働しているエージェントを統制する銀行向け

Fiddlerが答えようとしている問題は、「このエージェントは初日にコンプライアンスを満たすか」ではなく、「すでに動いているエージェントが実際に何をしたのか、そしてそれを事後に証明できるか」です。これはJinbaが扱う失敗の形とは別物であり、DORAの2026年の執行フェーズがいま直接試しているのはこちらです。監督当局が求めるのは、何をするはずだったかを記した方針文書ではなく、レジリエンスを裏づけるデータ（エージェントが何を読み、何に触れることを許されていたか）です。エージェントの非決定論的な振る舞いは、旧来のモデルリスク体制で監査人を納得させてきた静的な証跡収集を成り立たなくします。同じエージェントが、同じ作業で二度違う経路をたどりうるからです。

Fiddlerはまさにそのギャップに合わせて自社を位置づけ直し、「AI Control Plane」と「エージェントのライフサイクルを支える信頼の基盤」を掲げて3つの製品を展開しています。エージェントのライフサイクル全体にわたる可視性、文脈、制御を提供するAgentic Observability、ガードレールとして機能するPolicy Enforcement、そしてAI GRCです。この3製品構成により、Fiddlerは単一の層だけを担うツールよりも広い範囲を1つの契約でカバーします。検出とトレース、稼働中の制御、その上に載るコンプライアンスレポーティングの3つです。これはGartnerのアナリストがこの市場の実質的な決め手として挙げる「形」の問いにあたります。このカテゴリーは、どれが単純に「最良」かではなく、それぞれ異なる問題に応えるアーキテクチャへと分かれてきているからです。Fiddlerは公正融資と公正な結果という切り口で銀行に的を絞った訴求を行っており、融資、カード、ウェルスマネジメント、不正検知、トレーディングにまたがる金融サービス向けソリューションを明示しています。これにより、エージェントが与信や不正検知の判断を担うことで生じる公正融資上のエクスポージャーに対して、筋の通った答えを持っています。

成熟度の面では、Fiddlerは3,000万ドルのシリーズCを調達し、その用途をAIエージェント向けコントロールプレーンの構築に明示的に充てています。銀行が買おうとしているまさにそのカテゴリーに外部資本が投じられているということであり、ベンダー自身の文面だけで語られている主張ではありません。Fiddlerの公開資料に欠けているのは、銀行規模での具体的な価格と、SOC 2やデータ所在地についての項目立てされた説明です。そのため導入形態の適合性の確認は、ベンダーのページではなく買い手自身のデューデリジェンスで進める工程として残ります。

利点：

• 1つの製品ラインで3つの層（エージェントの可観測性、ポリシーの実施、AI GRC）をカバーし、全体を覆うために必要なベンダー数を減らせる
• 融資、カード、ウェルス、不正検知、トレーディング向けに作り込まれた金融サービス用ソリューションが、エージェントによる判断が生む公正融資上のエクスポージャーに直接対応する
• エージェント向けコントロールプレーンというカテゴリーの構築を目的に3,000万ドルのシリーズCを調達しており、マーケティング上の主張ではなく外部資金という裏づけがある
• セッションとツール呼び出しのトレースにより、DORAの2026年の執行フェーズが実際に求める運用有効性の証跡が得られる

欠点：

• エンタープライズ向けの価格は問い合わせ制のみで、銀行規模の比較に使える公開数値がない
• SOC 2やデータ所在地についての公開された表明がなく、導入形態の確認は買い手自身のデューデリジェンスに委ねられる
• すでに存在するエージェントを統制するために作られており、エージェントを構築・導入するためのものではないため、ゼロから始める銀行にとって構築層の代わりにはならない

適した相手：複数のシステムにまたがってすでにエージェントが稼働しており、ワークフロー構築ツールではなく、トレース・ガードレール・レポーティングを1つにまとめたコントロールプレーンを必要とする銀行とコンプライアンスチーム。

3. AI GRC・監査証拠プラットフォーム：規制当局の検査にそのまま出せるレポートを1本にまとめたいコンプライアンスチーム向け

このカテゴリーが応えるのはアーキテクチャではなく規模の痛みです。社内で構築したエージェント、フィンテックベンダー製のエージェント、基幹処理システムに組み込まれたエージェントを抱える銀行のガバナンス上の問題は1つではなく3つあり、単一の構築ツールも単一のコントロールプレーンも、必ずしもそのすべてを見渡せるわけではありません。2026年6月16日に公開されたGartner初のAIガバナンスプラットフォーム部門のMagic Quadrantは、13社を評価しました。これは「AIガバナンスプラットフォーム」がマーケティング上の呼称ではなくアナリストの定義するカテゴリーになったことを示す、現時点で最も明確なシグナルです。まさにこの集約層に予算を確保するため、コンプライアンス責任者が監査委員会に提示できる引用可能な根拠にもなります。可観測性や実施のツールの上に専用のGRC層が存在する理由は、監査部門と規制当局の検査に対応する部門が、エージェントの活動を具体的な規制上の義務（DORA第II章、GLBAのセーフガード要件、公正融資規則）に対応づけたレポーティングの窓口を1つ必要とするからです。検査の場で3社のベンダーのエクスポートを手作業で突き合わせるわけにはいきません。同じ集約の論理が、銀行向けAIコンプライアンスツールと銀行の規制報告ツールという新たに広がりつつある分野を後押ししています。いずれも、本記事の最初の2つが担うワークフロー層の上に載るものです。

シャドーAIの影響が最も強く出るのもここです。2025年のMenlo Securityの分析では、従業員の57%が機密データをAIツールに入力していることがわかりました。またBarracudaの2026年の調査では、同じ割合の従業員が上司にAIの利用を隠していることがわかりました。GRC層が何かをレポートする前に果たすべき最初の仕事は、検出と棚卸しです。コンプライアンス部門のリストにすでに載っているエージェントを統制するだけでなく、誰も登録していないエージェントを見つけ出すことです。この棚卸しの機能があるからこそ、この層は可観測性ツールの代わりではなく、その上に位置します。コントロールプレーンが生み出すトレースデータを取り込み、検査官が実際に読む、規制に対応づけられたレポートに変えるのです。

利点：

• 複数の上流ツールとエージェントの出所から証跡を集約し、規制当局向けの1本のレポートにまとめることで、単一ベンダーのツールでは埋まらない突合の隙間をふさぐ
• アナリストが定義したカテゴリー（Gartner初のMagic Quadrant）の裏づけがあり、調達と予算の説明にコンプライアンス責任者が引用できる根拠になる
• 検出と棚卸しの機能により、利用中のエージェントがすべて把握済みだと前提せず、シャドーAIの問題に直接対処できる

欠点：

• 上流の可観測性データとアクセス制御データが揃い、十分に計装されていることが前提。何も流れ込まないGRC層は空のレポートしか出せない
• カテゴリー自体が新しく（Magic Quadrantは初回）、評価された13社の間で成熟度とベンダーの継続性のばらつきが大きく、個社レベルの公開情報も乏しい

適した相手：社内の複数のツールと第三者ベンダーにまたがって導入されたエージェントを見ており、検査にそのまま出せるレポーティングの窓口を1つにまとめたいコンプライアンス部門・監査部門。

4. データガバナンス・アクセス制御プラットフォーム：エージェントが何に触れることを許されていたかを証明する用途

最も範囲が狭く、しかし最も省けない層が、エージェントが何に触れることを許されていたのか、そしてその境界の内側に留まったのかを証明する層です。DORAは、データにアクセスして行動を起こすAIエージェントを、第II章の対象となるICTシステムに分類します。BaFinのガイダンスはさらに踏み込み、生成AIとLLMは別個の規制体系ではなく、銀行の既存のDORAのリスク管理・テスト・第三者管理の枠組みに組み込まれると明言しています。この整理が重要なのは、エージェントのデータアクセスをガバナンスの後回しにするという選択肢を消すからです。定義上それはICTリスク管理であり、基幹の銀行インフラと同じ形で検査されます。

ここから生まれる実務上の現実は、銀行のエクスポージャーがエージェント本体より先に第三者を経由することが多い、ということです。ベンダーのAPIを呼び出したり、共有データレイクから取得したり、基幹処理システムの環境内で動いたりするエージェントは、そのベンダーのアクセス制御をそのまま自らの攻撃面として引き継ぎます。GLBAのセーフガード要件も同じデータガバナンスの土台の上にあります。もっとも、現時点で流通している情報の中に、名前のあるエージェントガバナンスのプラットフォームについてGLBA準拠を明示的に主張しているものはありません。つまりGLBAへの適合は、ベンダーのコンプライアンスバッジではなく、アクセス制御とデータガバナンスの層そのもので裏づけることになります。これは、規制が隣接領域にもたらすのと同じ、統制を起点とした見方です。たとえばBSA/AMLコンプライアンスのツールがその例で、監査人が確かめるのは箱に貼られたラベルではなく統制そのものです。これは買い手にとって意味のある違いです。GLBAを名乗らないまま、GLBAに関係する統制（ログ取得、最小権限のアクセス、データリネージ）が強いプラットフォームはありえます。銀行はラベルを待つのではなく、統制そのものを評価すべきです。

利点：

• エージェントをICTシステムと位置づけるDORA第II章に直接対応する。これは将来の提案ではなく、すでに執行されている基準である
• アクセス制御とデータリネージの証跡が、明示的なGLBA準拠の主張がなくてもGLBAのセーフガード義務に対応づけられ、ラベルではなく統制に基づいて承認判断を下せる
• 第三者製やベンダー組み込み型のエージェントまで対象を広げられる。銀行の実際のICTリスクはそこにあることが多い

欠点：

• 設計上カバー範囲が狭く（アクセスと来歴であって、挙動や出力ではない）、エージェントが実際に何をしたかを報告する可観測性層やGRC層の代わりにはならない
• 名前のあるプラットフォームからGLBA準拠の明示的な主張が出ていないため、この層では銀行自身のコンプライアンス部門が統制を法令に対応づける必要があり、ベンダーの認証には頼れない

適した相手：主たるエクスポージャーが第三者製やベンダー組み込み型のエージェントを経由しており、エージェントの挙動全般のレポーティングよりも、データアクセスの境界についてDORAとGLBAが求める水準の証跡を必要とするリスク部門。

4つの比較

実際にエージェントを構築するチームにとっての意味

銀行に代わってこうしたワークフローを構築するAI・機械学習のエンジニアリングチームやフィンテックのソリューション提供者にとって、上記のコンプライアンススタックは買い手向けのチェックリストにとどまらず、構築時の制約条件そのものです。（より広い範囲の銀行向けのエージェント型AIツールを検討しているチームや、銀行のAIガバナンス枠組みをゼロから作ろうとしているチームにも、同じ層モデルがそのまま当てはまります。）エージェントのアーキテクチャが80%決定論的でルールベースであれば、2026年の改訂で除外されたカテゴリーに沿う形になり、あらゆる判断を確率的なモデルにエンドツーエンドで通す設計よりも、コンプライアンスの説明ははるかに容易になります。これは設計時に下すアーキテクチャ上の選択であり、ガバナンスツールで後から付け足せるものではありません。このスタックに向けて計装するチームは、ツール呼び出しとセッションのトレースを最初からエージェントに組み込むべきです。それがDORAの2026年の執行フェーズが求める運用有効性の証跡であり、Fiddlerのような可観測性層が取り込む必要のあるデータそのものだからです。そして、第三者のデータソースやベンダー組み込み型のシステムに触れるエージェントには、検査の直前に慌てて付け足すのではなく、アクセス制御とデータリネージのログ取得を最初から必須要件として持たせるべきです。上に載るレポーティング層が何であれ、DORA第II章とGLBAのセーフガード規則が求めるのは、まさにその証跡だからです。

よくある質問

SR 11-7の除外規定は、銀行がガバナンス上の審査なしにエージェント型AIを導入できるという意味ですか。いいえ。除外規定はエージェント型AIを2011年の特定のモデルリスク枠組みから外すものですが、同じ2026年4月のガイダンスは、生成AIとエージェント型AIが引き続き一般的なリスク管理とガバナンスの期待の下にあることを明記しています。さらに当局には、AI固有の規則制定の手続きが控えています。除外規定を免罪符と受け取ることこそ、改訂自体の但し書きが防ごうとしている誤解です。

EUと米国の銀行は、エージェントのガバナンスについて同じ規則の下にありますか。いいえ。米国では資産300億ドル未満の銀行が、改訂されたモデルリスク管理ガイダンスの中核的な適用範囲から外れました。一方、EUの金融機関は規模をほぼ問わず2025年1月からDORAの下にあり、データにアクセスして行動を起こすAIエージェントは、その銀行の資産規模にかかわらずICTシステムに分類されます。両方の法域で事業を営む銀行は、厳しいほうに合わせたガバナンスの証跡を用意する必要があり、実務上それはたいていDORAです。

検出、可観測性、ポリシーの実施、GRCレポーティングを1つのプラットフォームでまとめて担えますか。近いところまで来ているものはあります（Fiddlerの3つの製品ラインは可観測性、実施、GRCにまたがります）。ただし、現在市場で確認できる範囲では、エージェントを最初に生み出す構築層まで兼ねると謳うプラットフォームはありません。多くの銀行は、すべてを1つで賄うツールを買うのではなく、構築とガバナンスのツールに、コントロールプレーンまたはGRC側の層を少なくとも1つ組み合わせる形に落ち着きます。

コンプライアンス部門に登録されていないエージェントを、銀行はどうやって見つけますか。検出の起点は構築層ではなく、可観測性層とGRC層です。自ら構築していないエージェントを銀行が棚卸しすることはできません。従業員の大半がAIツールを使っている以上、検出のための仕組みは、IT部門が把握済みのワークフローを監査するだけでなく、未登録のエージェントを示すツール呼び出しやAPI利用のパターンをネットワーク全体にわたって探す必要があります。

決定論的でルールベースのエージェントは、自動的にコンプライアンスを満たしますか。いいえ。狭められた「モデル」の定義が決定論的なルールベースのプロセスを除外している以上、アーキテクチャ上は有利な位置にあります。それでも、規制対象のデータに触れて行動を起こすシステムであれば、DORA、BaFin、GLBAが求めるアクセス制御、監査ログ、証跡生成の層は依然として必要です。