検索
ニュース

三菱UFJ銀行は「データ活用の“四重苦”」をどう解消した? “食わず嫌い”しないデータサイエンティストが語る

三菱UFJ銀行は、「データ活用が止まる“四重苦”」をどう解消したのか。データサイエンティストがMLを含むAIを搭載するアプリケーションを開発する意義や取り組み内容とともに見ていこう。

Share
Tweet
LINE
Hatena

 「内製したアプリケーションが思ったほど使われていない」「データ活用があらゆる問題により進まない」――多くの企業が直面する課題に、三菱UFJ銀行は独自のアプローチで挑戦している。

 同行では、データサイエンティストが従来の役割を超えてアプリケーション開発を手掛けることで、事業部門との距離を縮め、真の業務変革を実現しようとしている。2025年度には、生成AI運用基盤の構築とデータガバナンスの強化により、AI活用のさらなる拡大を目指している。

本稿は、Amazon Web Services(AWS)が開催した「AWS Summit Japan」(2025年6月25〜26日)で三菱UFJ銀行の福田晃平氏(市場企画部 市場エンジニアリング室)が「生成AI時代の業務変革実現とAI/MLチームの進化〜三菱UFJ銀行市場部門の内製開発ジャーニー」というテーマで講演した内容を編集部で再構成したものです。

なぜ「データ活用が止まってしまう」のか?

 三菱UFJグループは世界50カ国以上で事業を展開している大手の金融グループだ。福田晃平氏が所属する市場企画部 は、2000人の従業員が100万社の法人顧客を担当し、顧客の課題や財務状況、事業戦略を踏まえた金融商品を提案している。

 福田氏は2022年に新卒入社した若手従業員としてモデル開発やMLを搭載したアプリケーション開発、MLOpsの文化の導入、関連ツールの検証と技術導入を担当している。福田氏が所属するチームは大手ベンダーのイベントへの登壇やLangChainコミュニティへの貢献、海外を含む技術系カンファレンスへの参加など、対外的にも積極的に活動している。

 福田氏のチームが事業部門と相談の上、MLを含むAIを搭載したデータを活用するためのアプリケーションを開発し、事業部門に展開することでビジネス変革を図っている。

 しかし、データ活用の理想的なサイクルである「データ蓄積」「データ分析」「MLを含むAIの活用」「業務高度化」「業務拡大」は停滞していたという。

図1 止まっていたデータ活用のサイクル(出典:福田氏の講演資料)
図1 止まっていたデータ活用のサイクル(出典:福田氏の講演資料)

 「そもそもデータ蓄積の段階でデータが集まらず、使える状態にないという状況が多く見られました。分析の工程でも試行が停止し、業務高度化の段階では事業部門がツールを活用してくれません。こうした結果として業務拡大が続かず、モデルの精度も低下してしまうのです」(福田氏)

 こうした“四重苦”を解決するために三菱UFJ銀行は何をしたのか。さっそく見てみよう。

 福田氏はこのサイクルを速く確実に回すためには「文化×組織×基盤」の3要素が重要だと強調する。同行のデータサイエンスチームは「DATA」をコアバリューに掲げ、ビジネスラインと直接コミュニケーションを取りながら課題定義からPoC、運用まで一貫して対応している。

図2 「DATA」をコアバリューに掲げる市場部門データサイエンスチームの概要(出典:福田氏の講演資料)
図2 「DATA」をコアバリューに掲げる市場部門データサイエンスチームの概要(出典:福田氏の講演資料)

 チームは2021年に立ち上がった比較的若い組織でありながら、3年でアプリケーション開発まで到達した。

セキュアな環境でのAWS活用アーキテクチャ

 三菱UFJ銀行では、顧客データの安全性を確保しながら迅速な開発を実現するため、AWSに独自の内製開発基盤を構築している。

 「金融機関としてさまざまなセンシティブデータを扱う中で、お客さまのデータ保全を重視しながらも、早くプロジェクトを進められる環境を整備しました。インターネットから完全に遮断された環境で、データサイエンティストが安全に分析開発を行っています」(福田氏)

 プロダクション環境では、以下のAWSサービスを組み合わせた統合的なアーキテクチャを採用している。

図3 内製開発基盤の概要(出典:福田氏の講演資料)
図3 内製開発基盤の概要(出典:福田氏の講演資料)

 このアーキテクチャの特徴は、データサイエンティストのみがアクセスできるセキュアな環境と、事業部門が利用するプロダクション環境を明確に分離している点にある。開発環境では外部接続を完全に遮断することで顧客データの安全を保証し、プロダクション環境ではさまざまなデータやモデルをECS(Elastic Container Service)でシームレスに統合している。

3つのアプローチで実現するAI活用の拡大

 従来、データサイエンティストは特徴量エンジニアリングやモデル構築、APIデプロイを担当し、ユーザーインタフェースは別チームが開発していた。この分業体制にはAPIレイヤーとアプリケーションレイヤーを独立させるという利点がある一方で、重大な課題もあった。

 「APIだけを提供する形では、ユーザーからのフィードバックや潜在的なニーズの収集が困難でした。特にLLMの台頭により、ユーザーはAIとインタラクティブにやりとりし、RAG技術では実際のエビデンスドキュメントの確認を求めるようになりました。モデルの改良だけではなく、業務アプリケーションにも踏み込んでユーザーのニーズに応える必要があると考えました」(福田氏)

アプローチ1:データサイエンティストによるアプリケーション開発

 市場ビジネスは変化が激しく、データの移り変わりも早い。こうした環境では、アジャイル開発のフレームワークが重要になる。グラフの見方を変更したいという要望は、一見するとフロントエンドの課題のように思えるが、グラフを表示するためのデータソースの配置や、そのデータをモデルにどう組み込むかまで考慮すると、フロントエンドの仕様だけでなくバックエンドも含めた俯瞰(ふかん)的な設計が必要になる。

 データサイエンティストがフロントエンド開発に参画することで、モデルの挙動に詳しいという強みを活かしながら、ユーザーの要求の実現可否を迅速に判断できるようになった。

 フロントエンド開発のノウハウの習得に当たっては、AWSを核としたクラウド総合支援サービスを提供するクラスメソッドが支援した。まずフレームワークやライブラリの選定から着手し、ユーザー体験と開発生産性を考慮してフルスタックのWebアプリケーションフレームワーク「Next.js」を採用した。Next.jsはサーバサイドレンダリングやAPIルート機能を持ち、バックエンドの実装も可能な点が決め手となったという。UIコンポーネントの開発には、カスタマイズ性とトレンドを考慮して「shadcn/ui」と「Tailwind CSS」を選択し、型安全性を確保するためTypeScriptを採用した。

 AWSでのデモアプリケーション開発を通じて、ディレクトリ構成や実装方法を学習し、並行して開発していたアプリケーションに適用した。特にAI搭載アプリケーション特有のテスト方法については、AIを呼び出すテストではコストが増えるため、効率的なテスト戦略を検討したという。

 2024年10月にローンチした財務分析アプリケーションでは、AIの分析結果にハルシネーション報告機能を実装した。事業部門の従業員が誤りを指摘した箇所をマーカーで可視化し、関連グラフと併せて表示する仕組みを構築した。誤った情報はデータベースに蓄積され、今後の分析や改善に活用される予定だ。

 「潜在的なユーザー数が10倍に増加し、開発期間も概ね1カ月以内に短縮できました。お客さまに出力結果を見せた際は、『面白い取り組みだ』と評価いただきました」(福田氏)

アプローチ2:生成AI運用基盤(GenAI Ops)の構築

 従来型のMLでは、「Amazon SageMaker Pipelines」や「MLflow」などのツールスタックが存在している。同行でも、これらのツールを基本として関連技術やサービスを適宜導入してきた。一方で、生成AI特有の運用課題に対応するため、新たな基盤構築が必要となっている。

 「エージェント評価フレームワークやLLMに評価者の役割を与える『LLM as a Judge』による自動評価の仕組みが必要です。また、オンデマンドで分析が走る場合も、事前にチューニングした結果と整合性が取れているかどうか自動計測する必要があります」(福田氏)

 生成AIの運用では、エージェントの評価が特に重要だ。前述の通り同行のアプリケーションにはハルシネーションをユーザーが報告する仕組みを組み込んだ。

 同行は基盤構築に当たって「Amazon Bedrock」のマネージドサービスを活用することを検討している。同時に、エージェント評価フレームワークなど技術の移り変わりが早い領域については、サービスを限定せず、柔軟に技術を検証する環境が必要だ。そのため、「Amazon EKS」でのセルフホスト環境も視野に入れ、迅速な技術検証が可能なアーキテクチャを構築しようとしている。

アプローチ3:Apache Icebergによるデータガバナンス強化

 生成AIの活用に当たっては、データソースの正確性が重要だ。AIによる出力を実際のビジネスに適用する際、ユーザーは必ず根拠となるエビデンスが正しい情報であることを確認する必要がある。

 しかし、同行でも次のような理由により、データベースに誤りが混入するケースが存在していたという。

  • 前処理のミスや外部データの予期しない更新
  • 非構造データのETL(抽出・変換・格納)処理における精度限界(100%の精度が困難)
  • 複合キーの一部欠損によるデータ識別の困難

 「各データベースの断面に対してスナップショットを発行することで、簡単にロールバックできるようになりました。どのデータが上書きや追加、削除されたのか、レコードレベルで認識可能です」(福田氏)

 これらの課題に対し、同行は「Amazon S3」「AWS Glue」「Apache Iceberg」を組み合わせたデータベース運用の高度化を実現した。具体的なフローとしては、まずデータの前処理を実施し、マージする前に品質チェックのジョブを実行する。レポートや各種統計値を確認しながらテーブルマージの可否を判断し、問題なければ各データベースの断面に対してスナップショットを発行する。

今後の取り組み

 三菱UFJ銀行のデータサイエンスチームは、2021年の立ち上げから3年でアプリケーション開発を実現した。今後は開発したアプリケーションの海外拠点への展開、GenAI Opsとデータガバナンスのバックエンド基盤強化、自律的エージェントやアンビエントエージェントなどの次世代AI活用を計画している。

 「データサイエンティストが『食わず嫌い』せず、さまざまな領域で一貫したソリューションを構築することで、事業部門やエンドユーザーであるお客さまのためになる取り組みになると考えています」(福田氏)

Copyright © ITmedia, Inc. All Rights Reserved.

ページトップに戻る