re:Invent 2025: SageMaker Unified Studioによるデータ・AI統合基盤の構築
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
re:Invent 2025 の書き起こし記事については、こちらの Spreadsheet に情報をまとめています。合わせてご確認ください
📖 re:Invent 2025: AWS re:Invent 2025 - Architecting the future: Amazon SageMaker as a data and AI platform (ANT351)
この動画では、次世代Amazon SageMakerの機能とSageMaker Unified Studioについて解説しています。データプロデューサー、コンシューマー、ガバナーの3つのペルソナに対応し、データ取り込みからAI活用までをエンドツーエンドで支援します。新機能として、IAMベースのドメイン、ポリグロット対応の新しいノートブック体験、Spark Connect統合、AIアシスタントによるデバッグ機能、完全サーバーレスのApache Airflowサービスが紹介されました。S3 TablesによるIceberg管理、SageMaker Catalogでのガバナンス、Visual ETLによるローコード開発が可能です。デモでは金融サービスのユースケースを通じて、Snowflake連携、MLflowでのモデル管理、AutoMLによるトレーニング、GenAIモデルのデプロイまでを実演しました。Carrierの事例では、Icebergベースのデータレイクハウス構築により実装コストを66%削減し、AI精度を38%向上させた成果が共有されました。
※ こちらは既存の講演の内容を最大限維持しつつ自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますのでご留意下さい。
本編
データとAIの民主化における課題：役割の境界線の曖昧化とガバナンスの必要性
今の時期、ティーンエイジャーの男の子にとって何より大切なことは、ファンタジーフットボールリーグで優勝することです。うちの息子もそれに夢中です。ドラフトの準備を手伝ってくれるウェブサイトがたくさんあって、すべての選手を見て、クォーターバック、ラッシングヤード、パッシングヤード、タッチダウンをすべてチェックして、誰を指名すべきか判断するのを手伝ってくれます。でも、みんなそういったウェブサイトを使ってますよね。だから、もし利用可能なすべてのNFLデータを集めて、予測分析を実行して、数ラウンド後に彼が指名する人たちを見つけるのを手伝うことができたら、どんなに素晴らしい父親になれるでしょう。
Good morning. 私の名前は Brian Ross で、SageMaker Unified Studio のエンジニアリングを担当しています。昨年の Matt の Keynote で次世代の Amazon SageMaker をローンチしました。私のチームと私は、データを活用して分析と AI を推進しようとしている、様々なお客様のニーズに対応するために、このプラットフォームを進化させるために懸命に取り組んできました。本日は、Saurabh Bhutyani と一緒にいます。彼は皆さんのようなお客様と直接協力して、AI の取り組みを成功させています。そして、特別ゲストとして、Carrier でデータプラットフォームを運営している素晴らしいお客様の Justin McDowell をお招きしています。
本日は、次世代の Amazon SageMaker についてお話しし、お客様が直面してきた課題の種類についてお話しします。それが、私たちがこのプラットフォームを構築した理由です。その後、SageMaker を使ってアーキテクチャを構築し、皆さんが成功するための方法についてさらに詳しく説明します。その後、Saurabh がデモを行います。今週ローンチしたばかりの新機能をたくさん含めています。最後に、Justin が Carrier の SageMaker との取り組みについてお話しします。
データランドスケープは根本的な変化を経験しています。AI はすべての企業戦略の中心舞台に立っています。McKinsey が今年初めに実施した調査では、78 パーセントの企業がビジネスのすべての部門にわたって AI に大きく投資していることがわかりました。しかし、その 3 分の 4 以上は、収益またはコスト削減のいずれかに対して、意味のある影響を見ていません。誰もがこれを機能させたいと思っていますが、スケールでそれを行う方法を理解することができません。お客様から何度も同じことを聞いています。
皆さんは基本に立ち返って、まず強力なデータ基盤を構築し、AI を推進するための良いデータを公開するために取り組んでいます。そうする中で、多くの課題に直面しています。 まず第一に、かつては明確に区別されていた役割の線引きがぼやけてきているのを見ています。データエンジニア、データアナリスト、データサイエンティスト、AI エンジニアです。もはや一つのグループが何かをして、別のグループに引き継ぐのではなくなっています。第二に、お客様は最先端のテクノロジーを採用したいと考えていますが、すでに持っているものをすべて捨てたくはありません。データプラットフォームを構築するために、時には数百万ドルを投資してきました。AI の利点と、今後登場する新しいテクノロジーの利点を得ながら、それをすべて引き出して、より高い価値のために最適化する必要がないようにするには、どうすればよいでしょうか。
最後に、AI は信頼できるデータに左右されるということです。エンドツーエンドの AI ガバナンス戦略を立てて、信頼できる成果につなげるにはどうすればいいでしょうか。お客様とお話しする中で、データの取り込みから分析や AI に至るまでの過程には、大体 3 つの異なる役割があることがわかりました。ただし、これらの役割は同じ人が担当することもあります。データプロデューサーは、運用データストアや外部システムからデータを取り込むことに時間を費やしています。データをクリーニング、変換、キュレーションし、クリーンなメタデータを提供して、組織内の他の人が利用できるようにします。これらは Apache Spark のようなエンジンを使用するデータエンジニアであることが多いですし、ドラッグアンドドロップの体験を求める ETL エンジニアであることもあります。
一方、データコンシューマーはそのデータを消費して、実際のビジネス上の問題を解決するソリューションを構築しています。モデルをトレーニングするデータサイエンティストかもしれませんし、意思決定を促進するための再利用可能なダッシュボードを構築するアナリストかもしれません。あるいは、エージェントを動かすためのナレッジベースを構築しているかもしれません。最後に、データガバナーは企業のルールとコンプライアンスを実施する責任があり、データ分類やデータ品質、ガードレールといった期待に沿った出力になっていることを確認します。
データプロデューサー、コンシューマー、ガバナーが直面する具体的な課題
今日、これらの各ペルソナは大きな課題に直面しています。
まず第一に、データ取り込みは難しく、昔からずっと難しいのです。データがどこにあろうとも、すべてのデータにアクセスするためのネットワークパスを見つけて作成する必要があります。すべての認証情報を管理し、様々な形式のデータを取得して、それを比較したり結合したりできるように正規化する必要があります。そして、これを行うときに、大規模なデータセットに対して ETL をスケーリングするのは本当に難しいのです。対処すべきインフラストラクチャがたくさんあり、インフラストラクチャをスピンアップして管理する方法を理解できたとしても、合理的なコストでそれを行いたいし、必要のないものにお金を払いたくないのです。
次に、ビジネスメタデータをこれから生成する方法という問題があります。単なる技術的なデータではなく、実際にそれを使う人たちが理解できるカラムや行、テーブルをどのようにして持つのかということです。そしてそれをすべて理解した後、それを何度も実行できるようにプロダクション化するにはどうすればいいでしょうか。その間、あなたがいなくても実行できるようにする必要があります。そして、それを監視して、入ってくるデータが進化するにつれて、日々どのように変化しているかを見る必要があります。
同時に、データコンシューマー側にも独自の課題があります。誰もが、必要なデータが組織のどこかにあることは知っていますが、それはどこにあるのか？どうやって見つけるのか？そして、それを見つけたとしても、どうやってアクセスするのか？エンジニアと科学者がプロジェクトで一緒に働いているかもしれませんが、どうやって一緒にコラボレーションするのか？そして、分析を終えた後、自分たちと同じシステムにアクセスできない、または、そのシステムの使い方を理解するスキルセットを持たないかもしれない他の人たちと、どうやってそれを共有するのか？
AIをやろうとしている場合、事前に訓練されたファウンデーションモデルをすべて見つけて、自分たちのニーズに合わせてカスタマイズするにはどうするのか？または、アクセス権を持っているデータを使って、エージェントに公開するナレッジベースを構築するにはどうするのか？彼らがこれらの問題に対処している一方で、データガバナンスの担当者にも課題があります。特に大規模な組織では、誰もがデータへのアクセスを民主化しようとしています。しかし、適切なコントロールを維持しながら、どうやってそれを実現するのか？ルールをどうやって適用するのか？データが見ることを許可された人にだけプロビジョニングされ、その後、彼らがそれを必要としなくなったら取り消すことができるようにするにはどうするのか？そして、組織で使用されているデータが、期待を満たす品質であることをどうやって確保するのか？
次世代Amazon SageMaker：データ分析とAIのための統合プラットフォーム
このような問題を解決するために、私たちは次世代の Amazon SageMaker、Center for Data Analytics and AI を構築しました。次世代の SageMaker には、高速 SQL 分析、ビッグデータ処理、データ準備、データ統合、モデル開発、トレーニング、生成 AI のための事実上すべてのツールが含まれており、すべてが一箇所にあり、エンタープライズデータの単一ビューを備えています。
SageMaker Unified Studio による単一の開発環境と、S3、Redshift、外部システム、SaaS アプリケーション、他のクラウド、またはオンプレミスなど、すべてのデータへのアクセスを統一するレイクハウスアーキテクチャが得られます。SageMaker Catalog が組み込まれているため、データと AI ワークフローのエンドツーエンドガバナンスが得られます。
異なるペルソナと異なるスキルセットをサポートするために、Unified Studio は、仕事を完了するために必要なすべてのツールにアクセスするための単一の場所です。これには、クエリエディタ、ノートブック、ビジュアルエディタがすべて一緒に含まれており、ツールはすべてのサービス全体で一貫しています。どこにあるかに関わらず、アクセスするすべての SQL データベースに対して 1 つのクエリエディタを考えてください。ワークロードを一緒に構築し、一緒にテストし、他の人と一緒にコラボレーションし、その後、本番環境での使用のために一緒にデプロイできます。数ヶ月前にヨーロッパのある銀行と会っていて、彼らがこれのデモを見たとき、彼らは「AWS がついに私たちのためにこの問題を解決してくれるのを何年も待っていました」と言いました。
データプロデューサーワークフロー：取り込みから品質管理、公開まで
それでは、プロデューサーのワークフローについてもう少し詳しく見ていきましょう。 次世代の Amazon SageMaker は、データエンジニアとアナリストが、エンドツーエンドのワークフローを完成させ、消費者向けの高品質で使用可能なデータを生成するのを支援します。これには、Amazon のサービスや他のプロバイダーのサービスなど、様々なデータソースからのデータ取り込みが含まれます。それを取り込んだら、私たちの ETL 機能を使用します。ゼロ ETL または通常の ETL を通じて実行できますし、どちらを選択しても、コンピュートは最大規模で最も複雑なワークフローにも対応できるようにスケールします。シンプルなドラッグアンドドロップを使用することもできますし、Python を書くこともできますし、SQL を書くこともできます。
すべてが EMR や Athena、Glue といった非常に柔軟なエンジンによってサポートされています。完全にサーバーレスで一時的にすることもできますし、カスタマイズされた永続的なクラスタを自分で管理することもできますが、すべてのツールは同じように機能します。すべてを完了して、シルバーデータを生成しました。
次に、データの人間が読める説明を自動生成したいとします。AI を使用してデータの理解を生成し、それを自動的に生成することができますし、もちろん必要に応じて手動キュレーションの力も与えます。このステップの重要性を過小評価しないでください。私たちがこの旅を始めたとき、皆さんも同じように感じていると思いますが、ビジネスメタデータは人間がどのようなことが起きているのかをよりよく理解するためのドキュメンテーションでした。しかし AI の時代では、データのセマンティック理解を形成するために、技術メタデータとビジネスメタデータの両方が必要です。なぜなら AI はこれら両方のセットの消費者だからです。ですから、これを正しく行うことは今や重要です。
次に、自動データ品質評価と異常検出を実行したいとします。これにより、ルールをカスタマイズして、時間経過に伴う品質を追跡し、品質がしきい値を下回った場合はデータの更新を防ぐことができます。これでゴールドコピーが完成しました。 これでデータを公開し、メタデータを組織内の他のユーザーが利用できるようにし、エンタープライズ内でそのメタデータの可視性を制御することができます。また、消費者へのアクセス権を簡単に付与することもできます。 その過程で、パイプラインを本番環境まで自動化するための反復可能なサーバーレスワークフローと、ステージ全体にデプロイするための DevOps パイプラインが必要です。
そして、これらのステージのどの段階にいても、完全な系統は自動的にキャプチャされ、表示できるようになるため、データライフサイクル全体の可視性を得ることができます。 これで、クリーンで高品質なデータが使用可能な状態になりました。データアナリストとデータサイエンティストは、これを使用してリアルタイムダッシュボードを構築したり、モデルをトレーニングしたり、ナレッジベース、エージェント、その他のようなものを公開したりする準備ができています。
データコンシューマーワークフロー：発見からモデル開発、エージェント構築まで
SageMaker はこのためのツールも提供しています。まず、必要なすべてのデータを検索して発見します。メタデータ、ビジネスメタデータ、そして私が話した技術メタデータを確認します。「これが私の問題を解決するために必要なデータだ」と言って、そのデータへのアクセスをリクエストします。自動的に、データオーナーがそのリクエストを確認して、データセット全体へのアクセスか、またはそのサブセットへのアクセスを承認できます。承認されたら、新しいノートブックを使ってデータ準備やアドホッククエリを実行し、ビジュアライゼーションを生成できます。
ただし、発見はデータだけで終わりません。事前学習済みモデルも発見でき、既に取得したデータを使ってそれらをカスタマイズし、ビジネスに対応するように訓練できます。これらのモデルの中からいくつか選んで、MLflow で実験を実行し、最良のものを選んで登録し、SageMaker inference を通じてデプロイします。これでこのすべてのデータを使って、Amazon AgentCom のようなものにエージェントを構築してデプロイし、実際の用途に使用できます。これでプロデューサーフローとコンシューマーフローが本当にビジネスに機能するようになります。
S3 TablesとIcebergによるデータレイクハウスアーキテクチャの実現
ずっと unified studio がいかに簡単にデータを取り込み、処理し、分析と AI に利用できるようにするかについて話してきました。Unified Studio は、どこにあるかに関わらず、すべての運用データを取り込むことができる組み込みのコネクタセットを提供します。しかし、このすべてのデータはどこに行くのでしょうか。どこに保存するのでしょうか。効率的でパフォーマンスが高く、かつコスト効果的な方法でどのように行うのでしょうか。
長年にわたって、この質問への答えは Amazon S3 でした。顧客は Amazon S3 を無制限のスケーラビリティ、耐久性、低コストのために愛用しています。現在までに、顧客は S3 上に 1000 万以上のデータレイクを構築しています。今日、S3 に保存されている Parquet ファイルだけで文字通りエクサバイト単位のデータがあります。Parquet はこのデータを保存するための事実上の標準となり、S3 で最も急速に成長しているデータタイプの 1 つです。オープンテーブルフォーマットの出現により、S3 のスケールと経済性を活用して、ペタバイト規模のテーブルを数兆行で簡単に作成できるようになりました。
Apache Iceberg は今や誰もが選ぶデフォルトの選択肢です。うまくいけば、誰もが今 Iceberg 上にデータレイクを構築しています。Iceberg メタデータは、トランザクションサポート、タイムトラベル、スキーマを段階的に進化させる機能など、本当にクールな多くの機能のための堅牢なフレームワークを提供します。昨年の re:Invent で、私たちは S3 Tables を導入しました。S3 Tables は Iceberg を使ってタビュラーデータを保存するために特別に設計されており、完全に管理された Iceberg オファリングです。S3 Tables は、今日 S3 上で Iceberg を自分で管理している場合に直面する可能性のあるいくつかの問題を解決します。
まず、S3 tables は通常の S3 上の Iceberg テーブルと比べて約 10 倍のスループットを実現し、パフォーマンスを最適化します。さらに、テーブルレベルでのシンプルなセキュリティコントロールが得られ、Lake Formation grants を使用することもできます。そして最も重要なのは、自動ストレージ最適化とコンパクション、ガベージコレクションが組み込まれており、プロセスやその背後のインフラについて心配する必要がないということです。SageMaker Unified Studio のすべてのツール（新しいノートブック、ビジュアル ETL エディタ、SQL エディタを含む）は、S3 tables と完全に互換性があります。
S3 tables が Iceberg データを保存するのに最適な場所だと考えていますが、すでに数千の顧客が S3 上で Iceberg を使用して独自にデータレイクを構築し、進化させ続けています。Unified Studio は、使用したい任意の Iceberg ベースのデータに対して完全にサポートしています。既存の S3 データと Glue データカタログを使用して、Unified Studio のすべてのツールを使用できます。Lake Formation セキュリティの有無を問わず対応しています。実は、外部で管理されている Iceberg REST カタログがある場合、それに直接接続することもできるようになりました。リモートカタログ内のテーブルを AWS が提供するすべての分析エンジンで読み取ることができ、Studio 内で Lake Formation を使用してそれらに権限を適用できます。
SageMaker Catalogによるエンドツーエンドガバナンスとデータメッシュアーキテクチャ
つまり、選択肢は本当にあなた次第です。AWS にデータレイクを管理してもらう S3 tables を選ぶこともできますし、S3 上の Iceberg で自分で管理することもできますし、外部で管理してもらうこともできます。どのオプションを選んでも、Unified Studio は素晴らしいツールです。カタログについて言えば、次はデータガバナンスについて話す時間です。次世代の SageMaker には、データと AI ガバナンス用の組み込みカタログがあります。これは Studio と完全に統合されており、IT の介入なしに、簡単なパブリッシュ・サブスクライブワークフローを通じて、承認されたすべてのデータ、コンピュート、AI アセットを安全に発見してアクセスできます。
すべてのデータアセットやモデルにアクセスする必要があるすべての人に対して、管理者がアクセス権を提供する必要はありません。データコンシューマーはアクセスをリクエストでき、データオーナーはそれを付与し、後で取り消すことができ、さらに使用方法を監視することもできます。生成 AI メタデータを活用したセマンティック検索、データ品質と機密データ検出からの包括的な監視、さらには完全なリネージ追跡が得られます。これはデータだけではありません。モデルでも同じことができ、カタログ内で管理・ガバナンスしているアセットの数は実際に増え続けています。
優れたガバナンスシステムはこれを提供する必要がありますが、毒性検出、バイアス検出、ハルシネーション削減など、AI の独特なニーズにも対応する必要があります。このために、SageMaker Unified Studio とカタログに組み込まれた guardrails があります。自然言語を使用して、組織内で確実に対応したいことのタイプを説明できます。例えば、顧客についての質問がある場合、個人情報を出すことはできません。顧客がどのようにあなたの製品を使用しているか、売上などについて話すことはできますが、名前や住所などは提供しないでください。そして、それは結果の AI で尊重されます。
では、顧客がこれをどのようにエンタープライズガバナンスのアーキテクチャに活用しているのか、もう少し詳しく見てみましょう。 私たちの顧客はみんなデータへのアクセスを民主化したいと考えています。インサイト獲得までの時間を短縮したいのですが、同時にコントロールを維持し、安全な方法で共有する必要があります。企業はますますデータメッシュアーキテクチャを使ってこれを実現しようとしています。しかし、データメッシュアーキテクチャは本当に難しいんです。正直に言うと、非常に複雑で、それを構築した人たちでさえ、どのように機能しているのか理解していません。私は数年前からお客様にデータメッシュアーキテクチャの使い方を紹介してきましたが、正直なところ、私自身もよく理解していないと思います。
ビジョンを実現するには、ある程度の思考と計画が必要なので、私たちはそれをできるだけ簡単にしようとしています。ここでのアドバイスは、これを複雑にしすぎないということです。あなたの目標は、コンプライアンスを確保しながら、データワーカーにイノベーションの自由を与えることです。
SageMaker モデルにより、チームは自分たちのアカウント内で自律性と柔軟性を持って作業できます。SageMaker Unified Studio をチームで使用すれば、取り込んだり、準備したり、作成したりしたデータを、チームの他のメンバーと自由に共有できます。準備ができたら、そのデータをエンタープライズカタログに公開すれば、他の人がメタデータを見て、サブスクリプションをリクエストするかどうかを決めることができます。
これにより、必要に応じてより集中的なコントロールが可能になる一方で、ガバナーはビジネス用語集を定義し、メタデータの割り当てを強制し、メタデータの可視性をコントロールできます。これをどのようにアーキテクチャするかは、本当にあなた次第です。本当に必要であれば、このスライドに示されているものよりも複雑なアーキテクチャを選択することもできますが、シンプルに保つことができれば、データエンジニアもデータサイエンティストも、自分たちの仕事ができると感じられるようになり、あなたのことを嫌いにならずに済みます。
同時に、エンタープライズに入ってくるすべてのデータに、適切なデータ分類が適用されていることを確認できます。機密データであるか、PII を含んでいるかなど、多くのチームが独立して作業していても、それが無法地帯にならないようにすることができます。目標は、誰もがインフラストラクチャやガバナンスについて考えることなく、自分たちの仕事ができるようにすることですが、これらのことは目立たない方法で適用されます。
新機能の紹介：IAMベースドメイン、ネイティブノートブック、サーバーレスAirflow
この1年間、私たちのチームは本当に一生懸命働いて、 SageMaker Unified Studio に新機能を継続的にデリバーしてきました。その中には、つい最近リリースされたものもいくつかあります。それらについてご説明します。お客様からお聞きしたことの一つは、Unified Studio をローンチした時、私たちは非常に素晴らしく、美しく、シンプルなアプローチを取ったのですが、お客様は人間のエンドユーザーのアイデンティティとグループを使ってデータへのアクセスをプロビジョニングしたいと考えていました。彼らはデータアーキテクチャについて考え抜いて、本当に素晴らしく、シンプなソリューションを構築したいと思っていました。
しかし、ほとんどの人にとって、これらのジャーニーは本当に長いものです。なぜなら、既存の IAM ロールへのデータプロビジョニングに10年以上投資してきており、それらの IAM ロールへのフェデレーションを管理しているからです。お客様は、私たちとこのジャーニーを一緒に進みたいと思っていましたが、すぐに始めて、すぐに生産性を上げたいと考えていました。そこで私たちは IAM ベースのドメインをローンチしました。これにより、既に持っている既存のフェデレーテッド IAM ロールを使用して、Unified Studio ですぐに始めることができます。2分以内に、オンボーディングプロセスを経ることなく、既に持っている権限を使ってデータをクエリしています。
Unified Studio での私たちの中核的な目標は常に、ビルダーにデータとモデルを扱う本当に使いやすく、没入感のある、そして充実した体験を提供することでした。そして、私たちはここで全く新しいネイティブノートブック体験でバーを上げました。ノートブックはすぐに起動し、完全にポリグロットです。つまり、Python、SQL、PySpark で書くことができ、これらすべてで書くだけでなく、様々なエンジン間でデータを送る方法について考えることなく、データをシームレスに交換することができます。それは自動的に起こります。
Spark Connect が組み込まれています。クラスタがスピンアップするのを待つ必要はありません。コーディングを始めるだけで、Spark がそこにあり、自動的にデータのニーズに合わせてスケールします。素晴らしいビジュアライゼーションがあり、AI アシスタンス用の全く新しいデータエージェントがあります。これは、任意のモデルやコードデバッグから期待するコード生成だけでなく、クラスタのインフラストラクチャ構成をデバッグすることもでき、完全な高度な計画を行うこともできます。
あなたの使用例全体を説明することができます。私が fantasy football draft picker でしたように。もちろん、SageMaker プラットフォームの残りの部分と密接に統合されています。これらの新しいノートブックについてさらに詳しく知りたい場合、また SageMaker 内で CI/CD フローを構築することについても、このセッションが終わった後、30分後に、ANT 21214 の1階上に行くことをお勧めします。そこでは、これについてさらに詳しく掘り下げるチョークトークがあります。もっと詳しく知りたい場合は、ぜひそこに来てください。
では最後に説明するのは 、プラットフォームをローンチした時に、私たちは反復可能なワークフローに対して素晴らしいサポートを提供していました。
その基盤として Apache Airflow を選択しました。なぜなら、反復可能なデータワークフローを構築するための最良で、最も広く採用されており、最も柔軟な方法だからです。私たちは AWS の Apache Airflow マネージドサービスである MWAA に依存していて、その上に SageMaker Unified Studio 内にビジュアルエディターと監視機能を構築しました。しかし、顧客からはもう少し改善してほしいというリクエストをもらいました。彼らは環境をプロビジョニングして、30分待ってから、その後ずっとそれに対して料金を払い続けるようなことはしたくないということでした。
そこで私たちは、世界初で唯一の完全にサーバーレスな Airflow サービスをローンチしました。そしてそれは SageMaker Unified Studio に組み込まれています。今では、ワークフローをビジュアルで作成することもできますし、コードで作成することもできます。どちらでも好きな方を選べます。そしてそれをスケジュール設定すると、すぐに起動して、すぐに実行されます。すべての結果を確認して監視することができます。そして、ワークフローが実行されている時間分だけ料金を払うことになります。これはワークフローを単純化するだけでなく、コスト管理をより良くしてくれるものになると思います。顧客がこれを手に入れることができるようになるのが、本当に楽しみです。
実践デモ：金融サービス企業のグローバルポートフォリオ分析ユースケース
私たちは、組織が直面している問題と、次世代の Amazon SageMaker がどのようにそれらの問題を解決するのに役立つかを見てきました。それは、すべての主要な機能と役割にわたっています。私はちょうど今それについて説明してきて、いくつかのアーキテクチャスライドを見せてきました。しかし、百聞は一見に如かずです。ですから、私の同僚の Sarah Bhutyani を招待したいと思います。彼女は分析分野のプリンシパルソリューションズアーキテクトで、実際にそれを皆さんに見せてくれます。
Brian、SageMaker で行ってきたすべての最新のアップデートについて教えてくれてありがとうございます。最近ローンチした新機能のすべてについて、本当に興奮しています。そして、デモでそれが実際に動作しているのを見せたいと思います。 ですが、デモに入る前に、今日のデモの一部として構築しようとしているユースケースが何であるかを理解しましょう。
本日のデモの一部として紹介するユースケースは、金融サービス企業の架空の顧客ユースケースです。これはグローバルな投資ポートフォリオ分析と AI/ML のユースケースになります。この企業全体の主なユースケースは、複数の地域にわたって顧客ポートフォリオを管理することです。また、リスク指標と規制コンプライアンスも見ており、リスク検出とポートフォリオ最適化のための ML モデルを構築したいと考えています。
本日のデモで見ることになるさまざまなペルソナを見てみましょう。これらは主に SageMaker で作業し、自分たちの仕事を成し遂げようとするデータワーカーのペルソナです。まず、ビジネスアナリストがいます。ビジネスアナリストは通常、データの探索と検証を行います。彼らはビジネスメトリクスと KPI を定義したいと考えています。SageMaker でビジネスアナリストがどのように相互作用し、仕事をするかを見ることになります。
次に、データエンジニアがいます。彼女は ETL パイプラインを構築して変換を行いたいと考えています。彼女は複数のテーブルを持っており、それらを結合して別のアプリケーション用にフラット化されたテーブルを作成したいと考えています。次に、ML サイエンティストが登場します。ML サイエンティストは SageMaker の一部として利用可能なさまざまなモデルを探索し、機械学習モデルと推論エンドポイントを構築してデプロイします。
最後に、GenAI ビルダーが登場します。彼は SageMaker の一部として利用可能なさまざまなファウンデーションモデルを見て、自分たちの組織の一部としてモデルをデプロイできるかどうかを検討します。しかし、これらすべてのデータペルソナに入る前に、Brian が話していたように、IAM ベースのドメインを使用して体験を簡素化しました。プラットフォーム管理者がこのプロセス全体をセットアップするのがいかに簡単かを少し紹介したいと思います。
アーキテクチャを見てみましょう。左側を見ると、このプロセスの一部として SageMaker Unified Studio と相互作用する 4 つの異なるペルソナがすべてあります。SageMaker Unified Studio の一部として、Amazon EMR、Glue、SageMaker AI、MWAA など、本日のデモで使用するすべての既知のサービスがあります。そこから、ペルソナは S3 バケットと SageMaker Lakehouse の一部として Iceberg 形式で S3 に保存されたテーブルと相互作用し、Glue Catalog を通じて、その後、Lake Formation を介して権限が制御されます。
また、このユースケースの一部として Snowflake に保存されているデータを見ることができます。そして、データワーカーが Snowflake に接続してそのデータを利用することがいかに簡単かを見ていきます。
では、プラットフォーム管理者の部分に入りましょう 。プラットフォーム管理者が SageMaker IAM ドメインをセットアップしてプロジェクトを作成したいと考えています。それを実際に見てみましょう。私は AWS コンソールにいます。ここから Amazon SageMaker をクリックします。ここに来ると、get started というオプションが見えます。それをクリックします。ここから SageMaker Unified Studio をセットアップするオプションが見えます 。SageMaker に役割を作成させるか、S3 テーブル 、Glue カタログ、およびこの特定のユースケースに必要な他のリソースへのアクセス権を持つ既存の IAM 役割を指定することができます。ですので、これらすべてのリソースへのアクセス権を既に持っている役割の 1 つを選びます。 それに加えて、S3 テーブル統合がデフォルトで有効になっていることがわかります。ですので、そのままにしておいて、セットアップをクリックします。セットアップが完了したことが見えます。
セットアップが完了したので、管理者プロジェクトで迎えられます。左側には、私が利用できるさまざまなツールが見えます。ユーザープロフィールをクリックして、私が持っている IAM 役割とフェデレーション役割を確認できます。管理者としてドメイン管理に進んで、異なるユースケース用に異なるプロジェクトを作成できます。 今日のデモ用に既に作成されているポートフォリオ最適化プロジェクトが見えます。わかりました。では、ポートフォリオ最適化に進んで、最初に見るペルソナは ビジネスアナリストです。
ビジネスアナリストとして、私の責任は、このユースケースの一部として、未実現損益による上位のパフォーマンス証券を分析することです。わかりました。では、ビジネスアナリストとして SageMaker Unified Studio に入ります。ビジネスアナリストとして最初にしたいことは、このユースケースの一部として利用可能な異なるテーブルが何であるかを調べることです 。ですので、検索に進んで、検索用語として「financial」と入力します。利用可能なさまざまな Glue テーブルが見えます。利用可能なモデルもあります。テーブルの 1 つをクリックして進むことができます。テーブルをクリックすると、データカタログビューが開き、テーブルのスキーマを確認できます。また、プレビューをクリックして データを実際に見ることもできます。そして、詳細をクリックして、フォーマットなどの高度なプロパティを含む、テーブルに関するさまざまな詳細を確認することもできます 。
完璧です。次に見たいことは、ビジネス分析の一部として監査テーブルである Iceberg を備えた S3 テーブルがあることです。 このテーブルは、このユースケースの一部としてユーザーが実行しているアクションに関連するすべてのメトリクスを保存しています。ですので、それを開いてクエリをクリックします。 クエリをすると、クエリエディタが開き、クエリがそこに開き、ここで結果を確認できます。ビジネスアナリストとして、これらの結果をダウンロードしたい場合 、それを行って、必要に応じて管理職にメール経由で送信することができます。また、チャートビューをクリックして簡単な可視化を行うこともでき、X 軸や Y 軸などのさまざまなパラメータを変更して、他のいくつかのことを行うことができます 。
さらに、これは SQL ノートブックで、マークダウンと SQL を追加するオプションが提供されています。異なるカタログを選択して作業することができますし、SQL ノートブックのワンクリックスケジューリングも可能です。最後に、これを保存して、ビジネス分析の一部として実行したい最終的なクエリを実行できます。それは、パフォーマンスの高いポートフォリオの質問です。ここに結果が表示されていますが、ビジネスアナリストとしての私の仕事はここまでです。このノートブックをさらにスケジュール設定したい場合は、そうすることもできます。
次に、データエンジニアのペルソナを見てみましょう。データエンジニアとして、私のタスクは、このユースケースのために Portfolio Advisor という Web アプリケーションを構築することです。そして、このウェブアプリケーションの一部として使用される内部データプロダクトまたはフラット化されたテーブルを構築したいのです。では、データエンジニアの実際の動きを見てみましょう。データエンジニアとして、左側にはさまざまなツールが利用可能ですが、ETL パイプラインを視覚的に構築できるローコード、ノーコードのオプションがあるかどうか確認したいのです。では、それを実際に見てみましょう。Visual ETL をクリックします。これは私たちの ETL ツールです。ここで job を作成できます。
そうすると、プロンプトとして ETL パイプライン全体を説明するオプションもあります。ただし、今日のデモでは、ドラッグアンドドロップでパイプラインを構築します。まず、Glue カタログから Financial Services DB とカスタマーズテーブルを取得します。そして、このテーブルにはヌルレコードがないようにしたいのです。このテーブルから削除されるので、使用するときにクリーンなテーブルになります。これが私のクリーンデータカスタマーズ ETL パイプラインです。ドロップナルズの一部として、カスタマー ID がいかなる時もヌルにならないようにしたいと言っています。ですね？もしそれがヌルであれば、それらのレコードを削除します。それを保存して、トランザクションテーブルについても同じことをします。そして、実行をクリックします。
それに加えて、スケジュール設定を作成するオプションもあります。ですね？ですから、このETL パイプラインをスケジュールに従って実行することができます。また、ビュースクリプトをクリックすることもできます。これは Visual ETL の背後で生成されるコードを表示します。これは、Visual ETL の一部として背後で生成されるオープンソースの Spark コードです。ノートブックとしてクローンして、ダウンロードすることもできます。
ビューランをクリックしましょう。実行が成功したことが表示されています。では、次に何をするかを見てみましょう。Visual ETL に戻ると、構築した両方の ETL ジョブが表示されています。トランザクション、カスタマーズ、ホールディングステーブルのフラット化されたジョインである最終的な ETL ジョブを構築して、実行しました。実行中に、ここでテールのような出力ログが生成されているのが見えるので、ジョブで何が起こっているかも確認できます。
でも待ってください、ここで何が起きたんでしょう？エラーが出てしまいました。どうしたらいいでしょう？AI でトラブルシューティングするというオプションがあります。 AI でトラブルシューティングするというのは、問題がどこにあるのかを教えてくれるだけでなく、問題のあるコードも教えてくれるんです。問題は、同じ列名を持つ 2 つのテーブルを結合しているということなので、列の 1 つの名前を変更する必要があります。 holdings テーブルの quantity 列を holdings_quantity に名前変更します。それをして、ジョブを保存して、もう一度実行します。 ジョブの実行が開始されました。戻って view runs をクリックすると、ジョブが成功したことが確認できます。 つまり、AI がその問題を解決するのに助けてくれたわけです。
これで 3 つのジョブをすべて構築したので、これをスケジュール設定できるようにオーケストレーションを作成したいと思います。Brian が話していたように、Apache Airflow サービスが SageMaker Unified Studio に統合されています。 ですから、それを活用します。workflows に行って、create new workflow と言います。create new workflows をクリックします。 create new workflow です。そうすると、Airflow の様々なオペレータのオプションが表示され、SageMaker Unified Studio オペレータもあります。data processing オペレータを使用すると、Glue タスクのオプションが表示されます。ここで、clean data for customers など、Glue ETL ジョブの一部として行ったタスクに名前を付けることができます。 そうして、ここでワークフローを最終的に構築します。actions の下で、コードを見ることもでき、1 行のコードも書かずに Airflow DAG 全体を作成してくれたことが確認できます。 本当に素晴らしいですね。必要に応じてこれをダウンロードして、別の場所で実行することもできます。
そして、ここからこのワークフローをスケジュール設定することができます。新しくフラット化されたテーブルとデータ製品を毎晩作成して更新したい場合は、ここで設定を行うことができます。 素晴らしいですね。データエンジニアがどのように仕事をするかが見えました。では、次のペルソナである ML scientist に移りましょう。 ML scientist として、私の仕事はまず、このユースケースの一部として顧客ポートフォリオ全体でどのようなリスクが発生しているのかを理解することです。リスクを理解したら、これらの顧客ポートフォリオのポートフォリオ最適化を行うことができる ML モデルを構築したいと思います。 そして、最終的には、顧客ポートフォリオの変化に応じてリアルタイム予測を行うためにこのモデルをデプロイしたいと思います。
では、ここに戻ります。ML scientist として、私が見ているのは、Glue catalog や S3 テーブルではなく、Snowflake に保存されているデータもあるということです。Snowflake Horizon catalog に保存されているんです。では、実際にそれを見てみましょう。ML scientist がどのように Snowflake に接続してそのデータを利用できるかを見てみます。今、私は Snowflake にいます。 Horizon catalog で financial portfolio analysis データベースを検索すると、そのデータベースが表示されます。 それをクリックすると、analyst ratings、currency exchange rates、economic indicators など、public domain の下にある様々なテーブルが表示されます。 それに接続したいので、SageMaker Unified Studio で connections に行き、create connection をクリックします。Snowflake を含む様々な接続オプションが利用可能です。 それをクリックして、パラメータを入力することができます。ここではスキップしましたが、接続が作成されます。
では、data catalog に戻ります。connections の下で、Unified Studio 内で Snowflake からの 3 つのテーブルすべてが表示されます。sample data をクリックすると、Snowflake からのデータがここに表示されます。 また、data scientist として、通常は S3 bucket で作業してファイルをアップロードまたはダウンロードしたいと思います。data catalog にも良いオプションがあり、bucket を確認してそれを行うことができます。わかりました。では、data scientist は通常 notebook experience で作業しますね。彼らはそれが大好きです。Brian が話していた新しい notebook experience があり、様々なオプションがある polyglot notebook experience があります。その中から 1 つを選択できます。 クエリを実行して、ここで結果をフィルタリングできます。また、結果をすばやくソートすることもできます。そして、Python 自体を使用してこのデータの上に可視化を行うこともできます。 ここからチャートタイプを簡単に pie chart に変更でき、それが非常に簡単にできるようになります。
では次に、接続した Snowflake データに対してクエリを実行しています。右側に見えるように、SQL の隣で Snowflake 接続タイプを選択しています。
データが見えるようになりました。ここで行うことは、これら両方のセルからの出力を取得することです。Glue テーブルをクエリして 、Snowflake もクエリして、これら 2 つを Python を使って結合しています。ノートブックに両方のデータセットからのデータが見えています。ここでこのデータの出力を使用して 、チャート型の新しいセルを作成したい場合、Python から出てきた Pandas データフレームである dataframe を選択することでそれができます。そして簡単な可視化ができます。これは素晴らしいです。複数のデータセット全体ですべての可視化とすべてのクエリを実行できます。データがどこにあるかは関係ありません。その後、リスク分析を続けます 。顧客ポートフォリオサマリーを地域別に見るなど、他のテーブルをクエリしています。また エラーが発生してしまい、助けが必要です。そこで「Fix with AI」をクリックすると、データエージェントが動作を開始して出力を始めます。
データエージェントが機能します 。このセル全体で何が起こっているのか、そしてなぜエラーが発生したのかを分析します。実は、Python でクエリを実行しようとしていますが、テーブルは実は Glue にあるため、このクエリを実行するには Athena SQL に対して実行する必要があることを理解しています。それを理解して、セル内のエラーを修正します。このセルを受け入れるか、受け入れて実行するか、または拒否するかを選択できます。バージョンの違いを含むすべての変更が見えます。それらのオプションを受け入れます。タイプが Athena SQL に更新されたことが見えます。このクエリを実行できます。このクエリを実行しましょう。AI が優秀であれば成功するはずです。結果が見えます。これで成功しました。では分析の残りの部分を続けます。これは高速で進めます。ノートブックで ML サイエンティストとして Plotly グラフなどを作成しています。これらすべての機能とライブラリはすでに標準で利用可能です。最後に、これらの顧客ポートフォリオのリスク評価を計算し、値による最もリスクが高い顧客トップ 10 を確認します。これらすべての結果が見えます。これを Spark コードとして実行していたため、Spark UI を見て何が起こっているかを分析したいと思います。Spark UI へのワンクリックオプションがあり、Spark UI に入ります。典型的な Spark 開発者として、何か問題が発生した場合に備えてドライバーログも確認したいので、それもできます。すべてを実行するのは非常に簡単です。
では次に、ML サイエンティストとして行うことは、モデルの構築を開始することです。そのために、実験が MLflow で追跡されていることを確認したいです。ここで MLflow にいて、MLflow サーバーのすべての詳細を追加しています。すべて良好です。では、ノートブックに戻って、SageMaker を使用してポートフォリオ最適化と推奨を行うモデルの構築を開始します。最初に行うことは、ノートブックを持っていて、プロジェクト詳細と S3 バケットなどを取得するためのボイラープレートコードを実行することです。次に、別のテーブル、ポートフォリオ最適化からいくつかのデータを選択し始めます。そして再び、MLflow に接続するときにエラーが発生します。AI が私のプロジェクトに MLflow サーバーがあることを検出しましたが、名前が異なり、それを修正しました。非常に良いです。次に、SageMaker AutoML ジョブを続けます。AutoML 機能を使用してジョブを構築します。MLflow での更新が見えます。では MLflow に行き、ここに AutoML ポートフォリオジョブが作成されていることが見えます。それを確認できます。さらに、左側に、不正検出など、これまで行ってきた他のジョブもあります。これらのオプションのいずれかをクリックして、モデルメトリクスも確認できます。MLflow にジャンプしてすべてのメトリクスを確認するのが非常に簡単になります。SageMaker で AutoML を使用したため、起動されたトレーニングジョブがあるはずなので、トレーニングジョブ UI に行ってすべてのジョブを確認できます。当然のことながら、トレーニング後に推論エンドポイントをデプロイしたいです。では推論エンドポイントに行き、エンドポイントがデプロイされていることが見えます。では最後に、エンドポイントがデプロイされたため、リアルタイム推論を実行してテストしたいです。では再びノートブックに行き、ここにいくつかのサンプルデータがあり、推論エンドポイントとモデルをテストするために行きます 。本番モードに入れる前に。では実行して、ポートフォリオ推奨事項の一部としてスコアが出力されるのが見えます。これは素晴らしいです。ML サイエンティストとして、モデルを構築し、リスク分析を行い、可視化を行い、Spark を使用し、Python を使用し、Snowflake に接続し、すべてを SageMaker Unified Studio の一部としてシームレスに行うことができました。
では次に、GenAI ビルダーペルソナに進みます。GenAI ビルダーとして、金融サービスドメインとプロジェクトで作業しているため、公開されている GenAI モデルを使用できないという制限があります。私の組織は、データエンジニアが構築している Web アプリケーションの一部としてチャットボットエージェントに電力を供給するために使用される内部モデルをデプロイするよう私に指示しました。
SageMaker Unified Studio でどのようなオプションが利用できるのか見てみたいと思います。ここに入ると、GenAI builder として、AI/ML の下に models というオプションがあるのが見えます。それをクリックします。 Meta、Hugging Face、OpenAI など、様々なプロバイダーからの様々なモデルがリストアップされているのが見えます。私のアプリケーション用に Mistral Lite モデルに興味があります。 それで検索して、それをクリックします。ライセンスの詳細とペイロードの使い方を含む概要が見えます。また、これをノートブックで開くこともできます。
それで、そうします。ノートブックでコードを開いて、それを実行します。モデルが作成されて推論エンドポイントとしてデプロイされているのが見えます。数秒以内に、 それが見えるはずです。デプロイ中に、インスタンスタイプなど、モデルがどのようなもので デプロイされているかといった詳細を見に行くこともできます。 それを閉じて、ここに戻ってリフレッシュすると、サービス中になっているはずです。Mistral Lite モデルが利用可能になったようなので、これに対して推論を実行できるようになりました。
ノートブックに戻ると、predictor があり、エンドポイントを呼び出すオプションがあるのが見えます。SageMaker Unified Studio が提供してくれたこのノートブックの一部として、ペイロードの例があり、 それが正常に機能しているのが見えます。入力と、このモデルの一部として期待していた出力が得られました。 最後に、このモデルからの出力が気に入らず、別のものを使いたい場合は、この推論エンドポイントを削除しに行くことができます。
このデモでご覧いただいたように、複数のペルソナが新しい SageMaker IEM ベースのドメインと、新しいノートブック体験の一部として提供される素晴らしい機能を、組み込みデータエージェントとともに使用できます。これは、組織の将来の状態アーキテクチャとデータ戦略を構築するのに役立つことができます。今日のデモの目的のために、私は 1 行のコードも書きませんでした。すべてはノートブックの一部としてデータエージェントを使用して生成され、デモを作成しました。それでは、Carrier の Justin に彼らの成功事例について話してもらいたいと思います。
Carrierの成功事例：Icebergベースのデータレイクハウス「Nexus」による変革
私の名前は Justin McDowell で、Carrier のデータプラットフォームとデータエンジニアリングをリードしています。Carrier は、インテリジェント気候およびエネルギーソリューションのグローバルリーダーです。私たちの歴史は 2002 年に Willis Carrier が現代的なエアコンディショニングを発明したときにさかのぼります。今日、私たちはほぼ 160 の国で事業を展開しており、48,000 人の従業員と 35 のブランドのポートフォリオを持っています。 そのスケールは、私たちに大規模で複雑なデータランドスケープをもたらし、私たちのモダナイゼーションジャーニーの舞台を設定しています。
当社のデータ戦略は、4つのビジネス優先事項をサポートする必要がありました。顧客中心性、つまりより深い洞察とより充実したサービスの提供です。エネルギーエコシステム、当社の製品とサービスがますます統合されている領域です。デジタルソリューション、接続されたデバイスがリアルタイムデータのニーズを推進しています。そして利益率の拡大、効率性が必要で、ロックインを回避する必要があります。これらの優先事項は、すべてのアーキテクチャ上の決定を形作りました。そのコンテキストから、3つのコア課題が明らかになりました。1つ目は、データの分散で、システムが断片化され、レガシーウェアハウスのコストが増加していることです。ガバナンスの問題で、系統、アクセス、データ品質が一貫していません。そして最後に、オペレーションのスケーリングで、すべてのプロジェクトがパイプラインをゼロから再構築していました。
これらの課題により、当社はデータプラットフォームへのアプローチを再考することになり、社内ではこれを Nexus と呼んでいます。これらの課題に対処するために、AWS 上の Iceberg ベースのデータレイクハウスを採用しました。データは SAP、JDE、Salesforce などのシステムから Qlik Replicate、Amazon Kinesis Data Streams、AWS Glue zero ETL を通じてフローします。インジェスションアカウントは、プロデューサーをガバナンスされたレイクから分離します。データレイクアカウントでは、Glue、SageMaker Catalog、Iceberg が raw、bronze、silver、gold レイヤー全体のスキーマ、ガバナンス、ACID テーブルの作成を管理します。
SageMaker Unified Studio は、これらのレイヤーに対して、系統とアクセス制御を1つの場所で提供します。ウェアハウスが必要なワークロードについては、Snowflake を削減されたキャパシティのコンシューマーとして統合しています。
では、これをどのようにスケールするのでしょうか。1つ目の方法は、各事業部門が独自の AWS アカウントを取得することです。これらのプロデューサーはすべて Nexus Lake House の標準に従い、raw データ、Glue で公開されたデータ、データ品質、Lake Formation がすべて組み込まれています。一元化されたガバナンスアカウントが、アクセス、系統、メタデータの単一ポータルになります。チームはカスタムエンジニアリングなしで、一貫してデータプロダクトを公開および消費できます。これにより、制御を伴うフェデレーションが実現します。
では、このようなものにはどのくらいの時間がかかるのでしょうか。当社は re:Invent の直後の12月に開始し、Amazon スタイルの PRFAQ とアーキテクチャワークショップを行いました。3月までに、非本番環境が最初のモデルデータプロダクトとともにライブになりました。5月に最初の本番ワークロードをオンボードしました。今年の残りの期間は、プロダクト、プロジェクト、開発者体験のオンボーディングに焦点を当て、チームがデータプロダクトを構築および公開しやすくしています。
Nexus はすでに測定可能な成果を生み出しています。レガシーパターンと比較して、実装コストを 66% 削減することに成功しました。標準化されたパイプラインにより、デリバリーが加速し、再利用が可能になっています。また、自然言語から SQL へのエージェントの精度が 38% 向上しました。クリーンで統治されたデータは、すぐに成果をもたらします。
次のステップは、このプラットフォーム上のインテリジェンスレイヤーに力を入れることです。より多くのドメインをカバーするために、より多くの MCP サーバーを統合することに注力しており、AWS サービスとのより緊密な統合を進めています。また、系統図の自動化、品質チェック、パブリッシングを自動化するエージェンティックワークフローをデプロイしています。これにより、デリバリーが加速し、同時にガバナンスが強化されます。
このプロセスから得られた 3 つの重要な教訓をお伝えしたいと思います。第 1 の教訓は、オープンフォーマットを選択することです。テクノロジーが進化する際に柔軟性をもたらします。第 2 は、ガバナンスは後付けではなく、初日から組み込むべきということです。そして最後に、AI エージェントを責任を持って使用することです。自動化は、ヘッドカウントを増やさずにガバナンスと品質をスケールさせる唯一の方法です。これらの原則が、私たちが下したすべての決定を導いてきました。
特に、この旅をサポートしてくれた AWS アカウントチームの Bobby、Keith、Yanni、Sachin に感謝の意を表したいと思います。本朝、ご参加いただきありがとうございました。Amazon SageMaker についてお持ち帰りいただけるような学びがあったことを願っています。
※ こちらの記事は Amazon Bedrock を利用し、元動画の情報をできる限り維持しつつ自動で作成しています。
Discussion