銀行にはAIの問題があるのではなく、データプラットフォームの問題がある

テーマ「Make Headway」のもと、CBA Live 2026には、複雑さを打破しイノベーションを推進することに焦点を当てた数百人のリテールバンキングリーダーが集まりました。

しかし、リスク、コンプライアンス、債権回収、預金増加といったあらゆるセッションで、同じ根本的なテーマが繰り返し浮上していました。

強力なデータとガバナンスの基盤なしには、AIイノベーションはスケールしない。

デモやロードマップの裏側で、共通のパターンが現れてきました。真に進歩している銀行は、最も派手なAIを持っている銀行ではありません。

彼らは、最もクリーンで、最も管理され、最もリアルタイムなデータ基盤を持っている銀行なのです。

トーンを設定したシナリオ：

CBA社長のLindsay Johnson氏の基調講演では、シンプルで避けられないように聞こえる近未来の消費者体験が描写されました。

消費者が給料日に目を覚ます。彼女がスマートフォンに手を伸ばす頃には、すべてが終わっています。請求書の支払い、貯蓄の割り当て、サブスクリプションの更新、さらには海外への送金まで。

アプリなし。ログインなし。意思決定なし。

AIエージェントがすべてを処理しました。

それが銀行が目指して構築している未来です。

しかし、ここでステージでは語られなかった、不快な質問があります。

その体験を実際に機能させるために、銀行内に何が必要とされるでしょうか？

なぜなら、これは単なるより良いデジタル体験ではないからです。これは根本的に異なるオペレーティングモデルです。外部エージェントがリアルタイムで、複数の商品にわたって、完全なコンテキストで、一貫性や遅延に対する許容度がゼロの状態で、あなたのシステムと対話するモデルです。

そして、ほとんどの金融機関にとって、それがギャップが現れる場所です。

野心や構築しているモデルではなく、それを現実にするために必要なデータ基盤にあります。

セッションで聞いたこと：

様々なセッションを通して、具体的なデータ課題は機能によって異なりましたが、根本的なテーマは一貫していました。

AIリスクとコンプライアンス：ガバナンスのギャップは現実のもの

複数の金融機関のパネリストは、モデルドリフト（AIモデルが学習した実世界の母集団が変化するにつれて静かに劣化すること）が、銀行のAIにおいて最も過小評価されているリスクの1つであると語りました。平均FICOスコア750の申請者プールで学習したクレジットスコアリングモデルは、申請者の構成が650にシフトした場合、静かに失敗する可能性があります。これを継続的に監視する自動トリガーが必要です。ほとんどの銀行にはそれらがありません。

AIガバナンスに必要なデータ品質の規律は、多くのコンプライアンスチームが予想していたよりも要求が厳しいです。内部監査は、ビジネス部門の証明を受け入れるだけでなく、データリネージを独立してテストする必要があります。規制当局は、「フィンテックパートナーがモデルを所有している」という回答を受け入れません。

リレーションシップバンキング：あらゆる業界で最も豊富なデータが眠っている

複数のセッションで、銀行は他のほとんどの機関よりも顧客に関する豊富なデータを持っているという同じ観察がなされました。医師よりも、ファイナンシャルアドバイザーよりも。彼らは、ジムの会員資格、定期的な医療費の支払い、支出の変動性、雇用主からの入金パターンについて知っています。しかし、その洞察のほとんどは、リアルタイムで互いに通信しないシステムに断片化されて眠っています。

これにより生じる摩擦は現実のものです。あるパネリストは、顧客を十分に理解し、まだ税金を申告していないことを検出し、まさに適切な瞬間にその洞察を提示するという目標を説明しました。そのようなパーソナライゼーションには、クリーンで統合され、リアルタイムでアクセス可能なデータが必要です。それは後付けできる製品機能ではありません。

デフォルト管理：基盤が鍵

債権回収におけるAIに関するセッションでは、データ基盤が適切であれば何が可能になるかが説明されました。新たに延滞した口座が回復するまでの日数を、延滞初日から85%の精度で予測すること。そのような早期のシグナルは、債権回収リソースの割り当て方を完全に変えます。

そこに到達するには、内部口座データだけでなく、デジタルエンゲージメントシグナル（顧客が支払わずにウェブサイトを訪問したか？）、信用情報機関の移行データ、預金行動、過去の解決パターンを、すべて管理され監査可能な方法で結びつける能力が必要です。これをうまく行っている機関は、まずデータインフラを構築しました。AI機能はその後についてきました。

フロントラインAI：汎用モデルに基づいたAIは劣化する

バンク・オブ・アメリカのEricaに関するセッションは、本番環境のAIが実際にスケールするとどうなるかのマスタークラスでした。Ericaは2018年のローンチ以来、32億件以上の顧客インタラクションを処理し、その過程で数千もの変更を加えてきました。8年間の本番AIからの教訓は、これが「設定して忘れる」テクノロジーではないことが明らかでした。継続的なデータチューニング、継続的な監視、そしてエッジケースを読み取りモデルを更新することが仕事であるチームが必要です。

別のセッションでは、異なる角度からこれを補強しました。ほとんどの銀行のコンタクトセンターエージェントは、単一の顧客の質問に答えるために10〜15個のアプリケーションを切り替えています。その問題を解決するAIエージェントは、銀行自身のデータに基づいたものです。汎用LLMではなく、銀行のポリシー、製品、顧客関係でトレーニングされたツールです。

ベンダーの現実チェック：

最も記憶に残るセッションの1つは、AIベンダーの状況に関する率直な評価でした。大手機関でAI戦略を率いた経験のあるスピーカーは、大規模なベンダー監査から、現在AI機能を主張している数千のベンダーのうち、実際にAIを製品に搭載しているのは約5%に過ぎないという発見を共有しました。残りは、ロボティックプロセスオートメーションや標準的な自動化ロジックをAIと再ラベル付けしています。

銀行のテクノロジーバイヤーにとっての実用的なガイダンスは、具体的に質問することです。ベンダーがどのようにAI機能を構築したか尋ねてください。どのようなLLMオーケストレーションを使用しているか尋ねてください。完全なAPIとMCPカバレッジがあるか尋ねてください。ワークフローオートメーションがコモディティ化された場合、3年後のビジネスはどうなるか尋ねてください。これらの質問に具体的に答えられない場合、それが答えです。

なぜこれが重要で、どこで機能しているのか：

CBA Liveから出てきたテーマは新しいものではありませんでした。それらは、断片化されたデータ環境、限定されたガバナンス、そしてパイロットフェーズから本番環境への移行に苦労しているAIイニシアチブといった、銀行顧客との継続的な会話で私たちが見るのと同じ課題を密接に反映しています。

これは、私たちが日々関わる機関全体で浮上し続けるパターンを裏付けています。限界要因はAI機能ではなく、それをサポートするために必要な基盤となるデータとガバナンスです。

私たちが聞いたテーマとDatabricksがそれらにどのように対応するかを結びつけましょう。

データ基盤の問題

銀行は、顧客、リスク、製品データが断片化され一貫性がないため、AIのスケールに苦労しています。DatabricksのLakehouseはバッチおよびストリーミングデータを一元化し、Unity Catalogは1つのガバナンスレイヤー（権限、リネージ、分類）を追加するため、すべてのチームが同じ信頼できるビューから作業できます。

Lakeflowを使用すると、銀行は壊れやすいポイントツーポイントパイプラインに依存するのではなく、データを信頼性の高い方法で取り込み、キュレーションされたレイヤーに変換できます。Lakebaseは、この基盤をトランザクションワークロードに拡張し、完全に管理されたPostgresエンジンを同じガバナンスプラットフォームにもたらします。これにより、運用アプリケーションとAIエージェントは、個別の不透明なOLTPエステートを作成することなく、分析とデータを共有できます。

モデルドリフトと監視の問題

SR 11-7のようなガイダンスの下で、規制当局は現在、フルライフサイクルモデルリスク管理を期待しています。初期検証だけでなく、継続的な監視、ドリフト検出、および重要なモデルの定期的な再検証です。

Databricks上では、MLflowとModel Registryが実験と承認済みバージョンを追跡し、Model MonitoringとDelta Lakeが時間の経過とともに予測、入力、および結果をキャプチャします。これにより、SR 11-7スタイルの検証と継続的なパフォーマンスチェックが、スクリプトやスプレッドシートの寄せ集めではなく、プラットフォームの標準的な一部となります。延滞予測や不正セグメンテーションを推進するような高影響モデルでは、これらの機能は「高度な」機能ではなく、急速に必須のものになりつつあります。

リアルタイムパーソナライゼーションの問題

顧客と「その場で」つながるためには、銀行は、一晩の集計だけでなく、新鮮で低レイテンシーな機能を必要としています。DatabricksのOnline Feature Storeは、ミリ秒単位で事前計算された特徴量（プロペンシティ、リスクフラグ、セグメント）を提供し、Lakebaseは同じガバナンス境界内で、最近のトランザクションなどの最新の運用コンテキストを提供します。

典型的なフローは、イベント（カードのスワイプ、アプリのログイン、通話）が、Online Feature Storeから特徴量を読み取り、Lakebaseコンテキストと結合し、チャネル全体で一貫して次の最善のアクションを返す意思決定サービスをトリガーするようなものになります。最前線の担当者向けに、Genieは、同じガバナンスされたデータとメトリクスを自然言語で公開するため、銀行員やエージェントは、チケットやアドホックな抽出なしに「この顧客の90日間の預金トレンドは何ですか？」といった質問をすることができ、Unity Catalogはその下でポリシーとリネージを強制します。

エージェンティックAIの問題

銀行におけるエージェンティックAIとは、エージェントが制約されたアクションを実行できることを意味します。例えば、コレクションワークフローを進めたり、KYCステップを開始したり、厳格なガードレールと監視の下でサービスコールをオーケストレーションしたりすることです。

Databricks上では、Agent Bricksがこれらのエージェントとツールコールをオーケストレーションします。Databricks Appsは、それらが接続するセキュアなUIとワークフローをホストします。Lakehouse + Unity Catalogは、エージェントがどのデータを見ることができるかを制御し、完全なリネージと監査証跡を提供します。Online Feature Storeは、リアルタイムの行動およびリスクシグナルを提供し、Lakebaseは低レイテンシーの読み取り/書き込みのための運用状態ストアとして機能し、すべて同じセキュリティとガバナンスの境界内にあります。

これにより、銀行は、すべての操作を記録し、説明可能で監査可能なままであるプラットフォーム上で、エージェンティックワークフローをスケーリングできます。

説明可能性とコンプライアンスの問題

規制当局は、モデルがどれほど「高度」であるかよりも、銀行がその使用を説明、管理、および証拠立てできるかどうかを重視します。

Databricksは、ガバナンスとリネージをファーストクラスの機能にすることで、この問題に対処します。

Unity Catalogは、データ、特徴量、モデルアーティファクト全体で、権限、リネージ、および監査履歴を統合します。Delta LakeとDatabricks SQLは、バージョン管理された再現可能なパイプラインを提供し、MLflow Model Registry + Model Monitoringは、モデルのバージョン、承認、およびパフォーマンス/ドリフトを時間の経過とともにキャプチャします。

これにより、銀行は、データがどのように流れるか、モデルがどのように構築および検証されたか、そしてそれらがどのように意思決定に影響を与えたかについての、完全で再構築可能な記録を持つことができ、説明可能性とコンプライアンスを、より速く、より安全で、責任あるAI展開の実現要因に変えます。

最終的な見解：

銀行にはAIの問題があるのではなく、データプラットフォームの問題があるのです。

ポイントソリューションは初期の有望性を示すというパターンは明らかですが、強力でガバナンスされたデータ基盤なしでは停滞します。真の成果を上げているのは、まずプラットフォームに投資し、すべてのAIユースケースの展開をより速く、信頼しやすく、規制当局に説明できるようにした組織です。プラットフォームは後から決めることではなく、出発点なのです。

チームに持ち帰って議論する価値のある質問：

• 単一のガバナンスされた信頼できる情報源はありますか、それともチームはデータの異なるバージョンで作業していますか？
• 本番環境のモデルが誤動作した場合、どのくらいの速さで検出できますか？
• AIによって駆動された意思決定を、エンドツーエンドで規制当局に説明できますか？

これらの質問に対する答えが明確でない場合、次の投資は別のユースケースではなく、基盤です。

• Databricksが、銀行がどのようにデータ、ガバナンス、AIを大規模に統合するのに役立つかをご覧ください
• 実際の銀行のユースケースとアーキテクチャを探索してください
• データプラットフォーム戦略について話し合うために、私たちチームにご連絡ください

免責事項：私たちはサンディエゴで開催されたCBA Live 2026に参加しました。この投稿の観察は、参加したセッションや会議全体で行われた会話から得られた、私たち自身のものです。

(このブログ記事はAI翻訳ツールを使用して翻訳されています) 原文記事