「とりあえずAIを使ってみる」というトライアルのフェーズが一段落し、今多くの開発現場では、システムやインフラを「AI-Ready（AIを安全かつ継続的に活用できる状態）」へ移行させるための基盤作りが急務となっている。

しかし、それを本番環境かつ全社規模で実現しようとすると、セキュリティーとガバナンスの壁に必ず直面する。

この課題に真正面から挑んでいるのが、三菱UFJ銀行が進めるDatabricksを活用した「次期AI共通基盤」の構築プロジェクトだ。強固な統制が絶対条件となるメガバンクでは、いかにして「守り」を担保しながら、制約の多い環境をAI-Readyへと作り変えているのか。

そこで今回、同基盤の海外展開や新機能開発を最前線で担う、三菱UFJインフォメーションテクノロジー株式会社（以下、MUIT）の安平 朔さんにインタビューを実施。AI-Readyな環境構築の裏側にあった、泥臭いプロセスを聞いた。

三菱UFJインフォメーションテクノロジー株式会社
AIソリューション部　※2026年6月時点
安平 朔さん

2025年中途入社。前職では通信システムの開発・保守やAWSのプリセールスを経験。入社以来、MUFGグループが展開するAI共通基盤の海外展開を中心にシステム開発に携わっている

なぜ今メガバンクが「データ基盤の再設計」に挑むのか

ーー三菱UFJ銀行では、次期AI共通基盤としてDatabricksを採用し環境を大きく刷新しました。そもそも、なぜ今「データ基盤の再設計」が必要だったのでしょうか？

その背景には、従来のデータ分析環境やAI環境が抱えていた「サイロ化」という大きな課題がありました。

当行では2017年に初代の分析基盤を構築し、19年にはAWS上にデータレイクを作るなど、データ利活用の土台作りを進めています。しかし、当時は最低限の機能でのスタートだったこともあり、各所に分析基盤が点在してしまっていたんです。

その結果、新しい分析案件やAI案件を立ち上げようとするたびに、インフラの準備、権限の調整、データの収集、環境構築を個別にゼロから実施しなければならず、実際に分析を開始するまでに膨大な時間を要していました。

ーー「AIを使おう」という機運はあっても、インフラや権限周りの準備で足止めを食らってしまう。まさに「AI-Ready」な状態ではなかったわけですね。

さらに近年は、データ量の爆発的な増加や生成AIの活用ニーズが一気に高まり、既存基盤のスケーラビリティーや柔軟性に限界が見え始めていました。

特にネックだったのが、データエンジニアリング、BI、従来の機械学習、そして生成AIの活用が別々の基盤で運用されていたことです。開発サイクル全体が分断されていたため、スピーディーに仮説検証を回して改善していくアジャイルな動きが非常に難しくなっていました。

ーーそこで白羽の矢が立ったのが、Databricksだったと。さまざまなデータ基盤がある中で、Databricksを選んだ決め手は何だったのでしょうか？

単に「処理性能が高い新しい分析基盤が欲しかった」わけではなく、「全社で再利用可能な共通プラットフォームを作りたかった」というのが一番の理由です。

Databricksは、データ統合からBI、機械学習、生成AI活用までを単一のプラットフォーム上で実現できます。分断されていた領域を横断的につなぎ、ワンストップで完結できる点が大きな優位性でした。

しかし、メガバンクとして絶対に譲れなかったのが「セキュリティーとガバナンス」です。金融機関では機密情報や個人情報を扱うため、単に便利なだけでは採用できません。

その点、Databricksは「Unity Catalog」を中心とした一元的なアクセス制御や監査ログの管理など、金融機関レベルの厳格な統制要件に対応できる。ここが、次期基盤として採用する最大の決め手になりました。

オンプレ思想からの脱却と「ガバナンス設計」の難所

ーーとはいえ、メガバンクの厳格な要件を新しいプラットフォーム上で設計・実装していく初期フェーズでは、相当な苦労があったのではないでしょうか？

初期構築のフェーズにおいて技術的に最も時間をかけて議論されたのが、「権限設計とデータ分離の考え方」です。

従来のオンプレミス型システムでは、環境単位やサーバ単位で物理的に境界を分ける設計が一般的でした。しかしDatabricksの場合は、そうしたハードウェア単位ではなく、「データ単位」「カタログ単位」あるいは「ワークスペース横断」といった論理的なアプローチで統制を考える必要があったんです。

ーーインフラという「箱」で分けるのではなく、データそのもののアクセス権で分けるようなイメージですね。

はい。従来のようにシステム単位やストレージ単位でざっくりと権限を管理するのではなく、Databricksではデータカタログ、スキーマ、テーブル、ビューといった細かい単位で一元管理を行います。機能が豊富で柔軟だからこそ、「どこまでを全社で共通化し、どこからを物理的・論理的に分離するべきか」について、プロジェクト内で多くの議論が交わされました。

ーー安全性を最優先するなら、とにかく厳しく制限して、環境ごとに切り離してしまうのが一番簡単だと思います。そうしなかった理由はなぜですか？

今回のデータ基盤導入では、「統制のために制限する」のではなく、「統制されたセルフサービス環境を提供する」という考え方を何より重視していたからです。

安全だからといってガチガチに制限してしまっては、旧環境と同じように「分析を始めるまでに時間がかかる」「アジャイルな検証ができない」という課題に逆戻りしてしまいます。

ですから、利用者が自由に分析できる範囲を明確に定義し、その範囲内であれば必要なデータへ適切な粒度でアクセスでき、可能な限り迅速かつセルフサービスで利用可能にする。この設計を目指したのです。

Unity Catalogによる統合ガバナンスは、この「守り（厳格なセキュリティー）」と「攻め（データ活用の利便性）」を両立させるための中心的な役割を果たしています。

海外展開で直面した「システム認証」のジレンマ

ーー安平さんはこのプロジェクトにジョインしてから、具体的にどのようなミッションを担ってきたのでしょうか。

私が入社した時点では、国内向けの基盤はすでにリリースされており、新機能を追加していくエンハンス開発が進んでいました。その中で、最初にアサインされたのが「海外の分析者向けに基盤を提供する」プロジェクトです。

主な目的は、金融犯罪やマネーロンダリング対策に関する予測・検知を行うための共通インフラを整備し、アメリカ、シンガポール、インドなど各拠点から利用できるようにすることでした。

ーー海外拠点でも、国内と同じようにすぐ使えるものなのですか？

実際には、そう簡単にはいきませんでした。

海外には各国・地域ごとのプライバシールールがあり、データを授受するだけでも手動で分割して送付する必要があるなど、現地の担当者が分析に着手するまでに1カ月ほどかかるケースもあったそうです。

さらに、各拠点で個別に分析環境を構築していたため、ノウハウが蓄積されにくく、コストもかさんでしまうという共通課題がありました。そうした状況を踏まえ、海外拠点でも国内と同じようにスムーズに分析できる環境を整えることが、私のミッションでした。

ただ、その中で大きな課題となったのが「システム認証」の問題です。

当初は、国内で利用している行内の「共通認証」システムを、海外版にもそのまま適用する予定でした。共通認証側から受領するファイルに含まれるメールアドレスなどをキーにして、Databricksへログインさせる方式です。

しかし、テストを進める中で、海外ユーザーの場合、そのファイル内の必須項目が空欄になってしまうケースが多いことが判明しました。

ーー前提となる認証データが渡ってこない、ということですね。システム改修で対応することはできなかったのでしょうか。

影響範囲が大きすぎるので、対応には年単位の大がかりな検討が必要でした。ただ当時は、既に基本設計の終盤に差しかかっており、すぐに構築フェーズへ移らなければならないタイミングだったんです。そのため、急遽、別の認証方式を検討することになりました。

そうしてチームで協議を重ねた結果、Databricksが提供する標準機能を活用する案が候補に上がりました。

ただし、認証はシステムの根幹に関わる重要な領域です。単に「技術的にログインできる」だけでは不十分。利用者、端末、ネットワーク、運用管理を含めた全体として、当行が求める安全性を満たしているかを整理する必要がありました。

ーー具体的には、どのように検討を進めたのですか？

まず、海外拠点の利用者がどのような環境からアクセスするのかを丁寧に確認しました。

利用者は当行グループ内のユーザーであり、管理された端末・ネットワーク環境からの利用を前提としていました。また、端末利用時には所定の認証が行われ、利用者管理やアクセス制御も既存の社内ルールに基づいて運用されています。

その上で、Databricks側の認証機能だけを切り出して評価するのではなく、端末管理、ネットワーク制御、利用者管理、ログ管理などを含めた多層的な統制として、安全性を確認しました。

つまり、単一の機能に依存するのではなく、複数の管理策を組み合わせることで、全体として必要なセキュリティ水準を確保できるかを整理していったのです。

ーーシステム単体ではなく、ユーザーの環境全体を俯瞰して安全性の根拠を示したのですね。

はい。セキュリティー担当部署とも早い段階から相談し、懸念点を一つ一つ確認しながら、必要な統制や運用条件を整理していきました。また、将来的な認証強化の方向性についても説明し、現時点での対応方針と今後の改善余地をセットで提示しました。

その結果、当行のセキュリティー基準に照らして必要な確認を経た上で、海外向け基盤の認証方式として承認を得ることができたんです。

次に見据えるのは「業務システムへのAI統合」

ーーAI共通基盤が定着しつつある今、具体的な成果は数字として表れ始めているのでしょうか？

インフラ面での改善は劇的でした。これまで分析環境のスペック変更には数日を要していましたが、今では即座に対応可能です。環境払い出しの作業工数は90%削減され、ETL（データの抽出・加工・書き出し）の処理時間も55%短縮、分析環境にかかる費用自体も60%の削減に成功しています。

こうした準備の手間やコストが削ぎ落とされたことで、データサイエンティストの生産性は45%向上しました。彼らが仮説構築やインサイトの創出といった、本来の価値創造に時間を割けるようになったことは大きな成果です。

ーーインフラの整備がビジネスの成果に直結しているのですね。具体的なユースケースも生まれていますか？

はい。財務分析結果をもとに提案書をわずか5分で作成するアプリや、社内外のデータを掛け合わせてアライアンス候補先を選定する「M&A AIマッチング」など、実業務での価値創出がすでに形になりつつあります。

こうした成果が出始めたことで、システムを利用する業務部門（ユーザー側）の熱量も非常に高まっています。現場から「この機能を解放してほしい」といった要望が次々と上がり、それを受けて我々が実装していくという、現場主導のポジティブなサイクルが生まれています。

ーーユーザー主導で活用が進む中、目下はどのような開発が動いているのでしょうか。

現在、まさにリリースに向けて対応を進めているのが「モデルサービング」機能の解放です。これはDatabricks上で作成したAIモデルをデプロイし、銀行内の「別の業務システム」から直接呼び出して推論結果を返す仕組みになります。

例えば、口座開設時の「顔認証チェック」をAIモデルで行う場合、フロントのシステムからAI基盤を呼び出し、瞬時に結果を返す連携が必要になります。

AIを単なる分析ツールではなく、銀行のあらゆる業務システムへ完全に組み込んでいく。これこそが共通基盤を構築した本来の目的であり、セキュリティー面の整理が進んだ今、ようやく本格的な実装フェーズに到達しました。

ーーまさに実業務への埋め込みが始まろうとしていると。この先、このAI共通基盤はどのような姿を目指していくのでしょうか。今後の展望をお聞かせください。

自社に眠る膨大なデータをさらなる価値に変えるため、今後は「Agent Bricks」をはじめとするAIエージェント機能の強化を進めていきます。AIエージェントがその能力を最大限に引き出せる基盤へと、このプラットフォームを進化させていく計画です。

AIがあらゆる業務に深く組み込まれることで、定型的な作業や一次処理などはAIに任せ、人間はより高度な判断や価値創造に注力する。そんな「人とAIが協働して本質的な価値を創出する世界」を、この共通基盤を通じて実現していくことが、私たちの見据えるこれからの展望です。

【Check】三菱UFJインフォメーションテクノロジーの中途採用情報はこちらから

撮影／赤松洋太　取材・文／今中康達（編集部）