re:Invent 2025: MUFGが語るビジネス主導のAI活用を実現するデータ戦略とsemantic layer
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
re:Invent 2025 の書き起こし記事については、こちらの Spreadsheet に情報をまとめています。合わせてご確認ください
📖 re:Invent 2025: AWS re:Invent 2025 - Strategy First: Empowering the Business to Lead in the AI Era (AIM348)
この動画では、StarburstのAdrian EstalaとMUFGのRaja Palanis wamyが、ビジネスチームによるAI活用を実現するためのデータ戦略について議論しています。重要なのは、Federation、semantic layer、AI活用という3層のアプローチです。MUFGでは、物理的統合から論理的なデータプロダクト作成へとピボットし、ビジネスプロダクトレンズに基づくsemantic layerを構築しました。コアデータプロダクトと機能別データプロダクトを整理し、ビジネスデータプロデューサーがセルフサービスでデータをキュレーションできる環境を実現しています。ビジネスメタデータを含むデータプロダクトをLLMに供給することで高精度な分析が可能になり、「18ヶ月で1つのAIプロジェクト」ではなく「10週間で10個のAIプロジェクト」を目指す実験的アプローチを推進しています。
※ こちらは既存の講演の内容を最大限維持しつつ自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますのでご留意下さい。
本編
ビジネス主導のAIイノベーションを実現する3つのレイヤー：Federation、Semantic Layer、AI活用
私はAdrian Estalaで、Starburstのフィールド チーフ データ&AI オフィサーです。Starburstに入社する前も同様の職務を担当していたので、このようなディスカッションを見るときは、Starburstの視点だけではなく、エコシステムの視点からアプローチしています。Starburstを含めた、より広い戦略についての会話をお持ちしたいと思っています。皆さんにお会いできて光栄です。
Rajaさん、自己紹介をしていただけますか？ 私はRaja Palanis wamyで、MUFGで働いており、エンタープライズデータを管理し、現在チームのデータ戦略を推進しています。素晴らしいですね。開始前に、会場を回って、ここにいる人たちが誰で、どのような関心を持っているのかを把握する機会がありました。プロダクトを担当するチーフプロダクトオフィサーがいることがわかりますし、ビジネス側での採用を推進し、ビジネスセルフサービスを推し進めることに本当に関心を持っているチームもいます。これらは2つの素晴らしいトピックです。
今日のこの会話で私たちがしたいことは、ビジネスチームがAIソリューションを推進するときに、彼らが力を与えられていると感じることの重要性を明らかにすることです。AIと言うとき、私はGenAI側、Agentic側、会話型AIについて話しています。機械学習については話していませんし、ビジネスチームにML opsを推進させるつもりもありません。しかし、ビジネスチームがより創造的に関わり、AI機能の可能性の芸術を所有するようになると、魔法が起こります。
私が直接協力している多くの顧客やビジネスチームは興奮して、一緒にソリューションを構築しています。今朝のクラウドセッションに参加していたなら、それは素晴らしいことです。スキルがどのように組み合わさってソリューションを解決するかを作成し、構築し、理解する能力—これらはすべて、ビジネスチームが自分たちで所有し、推進できるべきものです。しかし、ギャップがあります。ギャップがあり、一部の企業はその力を与えることを推進するのに苦労しており、そのギャップは本当にあなたのデータを理解し、あなたのデータにアクセスできることに帰着します。
私はこれを3つのシンプルなブロックで描いており、RajaはそれをMUFGで下っています。ここで私がしたいことは、3つのシンプルなレイヤーで会話の基礎を設定し、その後Rajaの経験とMUFGで彼らがしていることと、ビジネス主導のAIイノベーションを推進するために彼らがしている仕事を掘り下げることです。まず基礎から始めましょう。あらゆる基礎の最初の部分は、データを取得するという課題です。私たちがすることは、チームがデータが存在する場所でデータを取得できるようにすることです。それがクラウドにあるのか、オンプレミスにあるのかは気にしません。レイクにあることが望ましいのですが、常にレイクにあるわけではありません。
Federation は長い間、Starburst が有名になった理由です。私たちが長い間得意としてきたことで、それは素晴らしいことです。しかし、データが置かれている場所に直接アクセスでき、クラウドであれオンプレミスであれ、データを移行する必要がなければ、この次のブロックが最も興奮することです。semantic layer の周りで多くのバズを聞いていますよね。これはビジネス向けの semantic layer で、本当のゲームチェンジャーです。データが置かれている場所にアクセスでき、移行する必要がなく、そのデータをビジネスチームが理解できる論理的なデータプロダクトに整理し始めることができれば、私は Raja にこれを前に言ったことがあります。ビジネスチームが部屋に入ってきたときに、彼らが自分たちのデータを認識するような体験を作りたいのです。それは家族の中に入るようなものです。あなたは自分のいとこを知っています、あなたは自分の家族を知っています。あなたは自分のデータを認識します。それは理解しやすいのです。
これらの論理的なデータプロダクトを作成できれば、データがどこに置かれているかは気にしません。ビジネスが理解できるパッケージに整理することができ、それは本当のゲームチェンジャーです。これは真の semantic layer で、レガシーの複雑性を抽象化し、ビジネスチームが使用できるものを提供しています。それを行うと、ビジネスチームは部屋に入ってきて、「Amazon や他のシステムで新しいエージェントをテストしたい。データを取得するだけで済みます」と言うときに、はるかに自信を感じます。
彼らは非常に迅速にアイデアを出すことができます。なぜなら、彼らは「これの少し、これの少し、これの少しが必要です。これらのガバナンスされた、キュレーションされた、セキュアなデータプロダクトをエージェントに持ち込んで、分析演習を行うために使用したいです」と言うことができるからです。データはすでにそこにあり、セキュリティと可用性の観点でアクセス権を持っているため、彼らはそれを行うことができます。これらが 3 つのレイヤーです。AI のためのビジネス有効化に到達するためのブリッジが何かを考えたいのであれば、Federation を通じてデータへのアクセスを取得することです。ビジネスチームが理解できるビジネス向けの semantic layer を作成することです。多くの場合、私はこれをビジネスチームと一緒に構築します。Raja はあなたに、私たちが彼のビジネスチームと一緒にこれを構築してきたことを教えてくれるでしょう。3 番目のレイヤーは、これらのデータプロダクトを採用し、BI または AI ソリューションで直接使用することです。これが私が話すのが好きなフレームワークです。私から聞きたくないですよね。Raja から聞きたいのです。
申し訳ありません、長いイントロで申し訳ありませんが、Raja、ステージを設定しました。いくつかの質問に飛び込む前に、私が今話したことで修正したいことや追加したいことはありますか？
MUFGにおけるデータ戦略の転換：ビジネスの自給自足を実現するデータプロダクトアプローチ
データは AI が必要で、AI はデータが必要です。それはサイクルです。私たちは従来のデータ戦略で旅を始めたと思います。そこではすべてを物理的な統合に統合し、データを移動し、データをキュレーションし、データをプロファイルし、それからそれに応じて物事を行います。私たちはそれをピボットして、「わかりました、論理的な方法でデータプロダクトを作成できますか？」と言いました。そしてそれらのデータプロダクト、または Adrian が話したことに、私が追加するのは semantic layer は何もビジネスプロダクトレンズからのものです。企業の世界では、corporate banking から来ている場合、lending があり、term loans などのいくつかのビジネスプロダクトがあります。私たちはビジネスプロダクトとデータプロダクトを同じになるように調整したため、ビジネスユーザーが来ると、ビジネスデータプロデューサーがいて、彼らは semantic layer からこれらのキュレーションされたデータセットを作成して、彼らが作成できるようにします。例えば、commercial loan operations があり、そのチームはローン予約のデータ品質を見たいと考えています。彼らは本当にコアプロダクトからデータをキュレーションでき、その後、彼ら固有の機能データモデルまたはデータプロダクトを作成できます。
ビジネスユーザーに対して、Adrian の指摘を踏まえて、3 つのペルソナを用意しました。具体的には、IT や CDO ではなく、ビジネスデータプロデューサーと呼んでいます。データエリートはビジネスの中にいるので、同じ言語を知っていて話すことができます。彼らはデータを理解できるので、私たちにとっては、ビジネスの自給自足をどのように実現するかという点が重要でした。IT やデータエリートのところに行って、どんなデータがあるのか、それが製品とどう関連しているのか、どうやってそのデータにアクセスするのかを理解する必要はないはずです。Starburst は、分散環境であれ、SaaS であれ、PaaS であれ、Salesforce のような組み込みシステムであれ、複数のデータソースからデータを引き出す機能を提供してくれました。そのデータを引き出して、キュレーションされたデータプロダクトを作成しました。それにより、ビジネスがセルフサービスで対応できるようになりました。
データ戦略を見直すきっかけになった出来事はありましたか？どの時点で「よし、何か違うことをしなければならない。ビジネスに近づく必要があるかもしれない。セルフサービスを推進する必要がある。ビジネスチームにもっとデータを信頼してもらう方法を見つける必要がある」と言ったのですか？MUFG で古いデータ戦略を見直すきっかけになったのは何ですか？
時間対効果が重要だったと思います。ビジネスをどのように実現するか。ビジネスは今、お金を稼いでいるわけですが、ビジネスの中にいる収益生成者の能力をどのように高めるか。時間対効果です。IT や CDO のところに来るのではなく、ビジネスが自分たちでデータを準備できるようにするために、どのくらい早くデータを提供できるか。ビジネスが自給自足できるようにデータを準備する能力をどのように実現するか。それがこの取り組みを始めるきっかけになった重要なポイントでした。
セマンティックレイヤーがどのようなものかについて、秘密をあまり明かさずに、視聴者に説明してみましょう。ビジネスチームが理解できるセマンティックレイヤーについて話すと、MUFG では、コアデータプロダクトと機能別データプロダクトという概念があります。機能別データプロダクトはコアの派生物と考えることができます。コアデータプロダクトはよくキュレーションされています。100 のソースからデータを取得して、それらを少数のコアデータプロダクトに整理しました。顧客用に 1 つ、チャネル用に 1 つ、バンキング用に 1 つ、そして私の異なる大きなもの用に 1 つあります。その後、機能別については、例えば、レンディングチームが「これの少し、あれの少し、あれの少し必要だ」と言って、自分たちの機能内で独自の派生物を構築して、特定の機能的な質問や分析ニーズに答えるようなことを想像できます。これが MUFG で構築しているモデルです。では、機能側のコンシューマー、ビジネスチームについて教えてください。彼らは力を与えられていると感じていますか？皆が飛び込んでいるのか、それともどのような状況ですか？
これは一つの旅です。ビジネスユーザーは様々です。データを見て非常に興奮している人もいます。「わかりました、途中まで進めてください。データを理解する必要があります」という人もいます。ですから、データリテラシープログラムと組み合わせて、どんなデータがあるのか、どのようにアクセスできるのかを教育できるようにしました。半々くらいで、混在しています。パワーユーザーの中には非常に積極的に関わっている人もいると言えます。
パワーユーザーの中には「50個の異なるシステムから必要なデータを揃えることができて満足している」と言う人もいますし、彼らは自分たちで進めていくことができます。彼らは自給自足できているんです。私たちはビジネスチームが必要な方法でデータを整理できるようにしているんです。では、3番目のボックス、AI のボックスに戻りましょう。これが本当に話したいところです。キュレーションされたデータプロダクトを構築できれば、秘訣はビジネスメタデータなんです。技術的なメタデータだけからデータを構築するのとは別の話です。
カラムレベル、テーブルレベル、ロールレベルでビジネスメタデータを含むデータプロダクトを構築すれば、そのデータプロダクトの実際のビジネス上の説明を持つことになります。それを LLM の前に置くと、非常に正確な分析が得られ、非常にパフォーマンスの良い分析が得られます。例えば、ビジネスチーム、貸付チームと一緒に座って「ここがあなたの貸付データプロダクトです。さあ、やってみてください」と言うことができます。彼らが永遠に所有することになるソリューションを与えているのではなく、彼らが進化させていく能力を与えているんです。
ビジネスチームがその能力を見て「ちょっと待って、これはできる？あれはできる？もしこのスキルを追加したら？もしあのスキルを追加したら？」と言えるようにしたいんです。魔法が起きるのは、ビジネスチームがデータを理解して、AI で作業する自信を得たときです。何かを壊してしまうことを恐れません。なぜなら、データプロダクトでは、このデータだけを公開しているからです。それだけです。他には何もありません。ロックインされたシステムでは、本当に明確なガイダンス、ガードレール、ガバナンスがあります。彼らに実験するためのガードレール、ガバナンス、ガイダンスを与えているんです。
結局のところ、実験にかかる時間を短縮し、実験にかかるコストを削減しているんです。私はいつも「18ヶ月で1つの AI プロジェクトではなく、10週間で10個の AI プロジェクトをやりたい」と言っています。すべてが成功するわけですが、3つで成功させて先に進み、7つで失敗することができます。それはおそらく私たちが皆望む正しい失敗ではありませんが、実験しているときの現実です。すべてがうまくいくわけではありません。
AI時代のデータ活用：データをAIに使い、AIをデータに使う双方向アプローチ
AI 側では、これらのデータプロダクトのための基盤を構築し始めたばかりだと思っています。将来、Agentic フロントエンドについてどのように考えていますか？私たちは AI ランドスケープを2つの形で見ています。1つは、すべてのデータ管理を活用し、データ管理機能を有効にすることです。プロファイリングであれ、リネージであれ、またはそれらのいずれかであれ。2つ目は、ビジネスユーザーがデータとチャットを始めるようにしたいということです。ビジネスユーザーが「OK、ミッドマーケットのバンキングカスタマーをすべて教えてくれる？」と言えるようにしたいんです。
私たちはそのような機能を提供し、その後リストを提供したいと考えています。また、認証メカニズムと統合されていることを確認します。中堅銀行の顧客が認可されていない人に晒されることは望みません。チャットを取得し、AI を使ってデータ製品を有効にし、系統図を取得し、プロファイリングを取得し、カタログ化し、タグ付けするといったことの組み合わせです。これが第一部です。Starburst を使用することで、50 の異なるシステムを行き来する必要がなく、1 つの場所に行くことができるようになります。
もう一つの側面は、人々が Starburst に来るとすぐに、クリックできるということです。Amazon Bedrock や他の機能を使用できる Agentic 機能を使用して、そのデータとチャットを呼び出したいのです。すべてが 1 つのボックスに入っているので、Real Data Marketplace と呼ばれるものに来ることができます。これがその目的です。
ここで強調したい点があります。それは 2 つの側面でのアジリティです。ビジネスチームと一緒に構築したセマンティックレイヤーがあれば、そのセマンティックレイヤーはデータがどこから来るかを論理的には気にしません。そこに置いておくことができます。それに接続することができます。また、そのセマンティックレイヤーの前面でのアジリティもあります。つまり、エージェントを構築できるということです。周りを見回すと、本当にたくさんのクールな AI や Agentic タイプのソリューションがあります。もし私が CEO なら、それらすべてを試してみたいのですが、それらのすべてが何らかのコアプラットフォームに接続されていれば、それは高くつきます。
それらのすべてが特定の方法でデータをモデル化することを要求すれば、それは高くつきます。データ製品をどのエージェントにも配信でき、ビジネスチームに対して、ガードレール、ガバナンス、ガイダンスがあり、データを配信すると言うことができれば、おそらくフロントエンドで任意のエージェントを構築して試すことができます。気にしません。どのエージェントでも構築してください。正しいデータを確実に取得できるようにします。任意のソースを使用してください。正しい方法で接続することを確認します。これは信じられないほどの柔軟性と信じられないほどのアジリティであり、最終的には長期的により良い選択をする機会を提供します。
付け加えるとすれば、このジャーニーにおいて、ビジネスは極めて重要な役割を果たしています。
ビジネスはデータ機能全体を強化するために私たちとパートナーシップを組んでいます。これは信頼構築のシナリオを通じて実現されており、私たちはデータを準備することを許可し、すべてのデータを持つ一元化された場所があり、そこで本当にデータをキュレーションして次のレベルに進めることができます。実際のところ、Starburstを通じてデータを引き出すことで私たちのデータ品質インデックスを改善しており、それが AI のモデリングに供給されるときには、はるかに豊かなデータ品質を持つようになります。
先ほどおっしゃったことが好きです。「データを AI に使い、AI をデータに使う」とおっしゃいましたね。それについて少し説明していただけますか？「データを AI に使う」というのは、LLM モデルを通じて組織内にある全体的な豊かなコンテンツを学ぶためです。それが構造化データであれ、ディール ファイルに存在する非構造化データであれ、またはシステムに存在する構造化データであれ、そのデータを AI に供給して、より多くのインサイトについて学ぶことができます。
もう一方は AI をデータに使う必要がある場合です。タグ付けの目的で AI を使いたいのです。ラインエッジ作成のために AI を使いたいのです。プロファイリングのために AI を使いたいのです。これらはそれらのインサイトを作成できるものです。つまり、データを AI に使い、AI をデータに使うということです。素晴らしいですね。本当に素晴らしい。ここで一旦停止して、何か質問がないか確認させていただきたいと思います。
お時間をいただきありがとうございました。本当にご関心をお寄せいただき感謝いたします。ここのホールをちょっと下ったところ、550 番地にブースがあります。もっとお話しすることができれば幸いです。ありがとうございました。ありがとうございました。
※ こちらの記事は Amazon Bedrock を利用し、元動画の情報をできる限り維持しつつ自動で作成しています。
Discussion