re:Invent 2024: LennarのAWSによるデータ・AI基盤近代化事例
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2024 - Building for the future: Enterprise-scale AI and analytics (AIM125)
この動画では、Lennar HomesがAWSを活用してデータとAIプラットフォームを近代化した事例が紹介されています。Data and AnalyticsのSenior Vice PresidentのLee Slezakらが、レガシーシステムからの脱却と、AWS SageMakerベースのAIプラットフォーム構築について解説しています。Medallionアーキテクチャの採用やDBT、Icebergなどの最新技術の統合により、データ更新頻度を1日2-3回から1時間ごとに改善し、クラウドコストを60-70%削減しました。また、MLOpsプラットフォームの実装により、予測分析や異常検知などのAIユースケースをスケール可能にし、約13,000人のエンドユーザーのうち5,000人以上が新プラットフォームを活用するまでに成長した具体的な成果が示されています。
※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
※ 画像をクリックすると、動画中の該当シーンに遷移します。
re:Invent 2024関連の書き起こし記事については、こちらのSpreadsheet に情報をまとめています。合わせてご確認ください！
本編
Lennar HomesとPwCによるAWSデータ＆AIプラットフォーム構築の概要
本日はご参加いただき、ありがとうございます。まずは簡単な自己紹介からさせていただきます。私はLennar HomesのData and AnalyticsのSenior Vice PresidentのLee Slezakです。私はLennar HomesのData and AnalyticsのSenior DirectorのVarun Kumarです。はい、この写真は私ですが、かなり昔に撮ったものです。私はMilo Ackermanで、PwCのData and AIプラクティスのSenior Solutions Architectをしています。
皆様、こんにちは。Thanksgivingは楽しく過ごせましたでしょうか。本日のセッションにお越しいただき、ありがとうございます。このセッションが有意義なものとなり、いくつかの学びを持ち帰っていただければと思います。簡単に自己紹介させていただきますと、私はPwCのData and AIプラクティスのManaging DirectorのRohit Sinhaです。当社のAWS関連のData and AIのすべてを担当しています。私たちは1年以上にわたってLennarと協力してきました。本日は、LennarでのモダンなAWS Data and AIプラットフォームを構築し、AIをスケールさせるための包括的な変革について、実例を交えながらリーダーシップの皆様とご紹介できることを大変嬉しく思います。
アジェンダを簡単にご説明させていただきます。まず、8-10ヶ月前の状況から始めて、約10ヶ月でこのプロジェクトをどのように開始し完了したかをお話しします。次に、SageMakerをベースとし、LennarのAIの大部分をスケールする私たちのプラットフォームを含む、アーキテクチャとパターンの詳細を見ていきます。そして、現在の移行の進捗状況と、このセッションがどのように皆様のお役に立つか、特に組織のモダナイゼーションの途中にある方々や、次世代のAIユースケースをスケールさせるためのモダンなData and AIプラットフォームの活用方法、さらにはGenAIユースケースの基盤としてのプラットフォームの可能性について触れていきます。それでは、Leeに引き継ぎたいと思います。
Lennarの課題とAWSプラットフォーム構築の戦略
ありがとう、Rohit。そして本日ご参加いただいた皆様にも感謝申し上げます。Lennarについて少しお話しさせていただきます。私はLennarに入社してほぼ1年半になりますが、先ほど申し上げた通り、Data and Analyticsが私の担当分野です。私がLennarに入社した理由の一つは、エンタープライズレベルのスケールを実現するための変革を推進することでした。当社は急速に成長しており、アメリカ最大級のホームビルダーとして非常に成功を収めています。そして毎年、より多くの住宅を建設し、規模を拡大し続けています。
将来を見据えたとき、私たちは現在の基盤に改善の余地があり、テクノロジー、データ、AIの面で目指すべき姿に到達するためには取り組むべき課題があることを認識しました。Rohitが言及したように、私たちのアプローチは調査から始まりました。私はRohitと1年以上一緒に仕事をしてきましたが、私たちが見たのは、サイロ化されたデータアプローチでした。多くのレガシーシステムが存在し、過去の統合の試みは成功せず、それらが並行して稼働していました。そのため、まず現状を把握し、そこからどこに向かうべきかを見極める必要がありました。
また、多くの運用上の問題も見られました。常にデータ品質の問題やデータの遅延の問題が発生していました。私に寄せられる問い合わせのほとんどは、どこかでデータが表示されないというものでした。ソースからターゲットまでの経路が多すぎて、トラブルシューティングや管理が非常に困難でした。興味深いことに、私が着任した初日に、以前のデータプラットフォームのMVPがリリースされました。それを見たとき、一見良さそうで、良いスタートを切れたと思いましたが、実際にはただのデータウェアハウスでした。Data Lakeの側面もなく、モデル化されたデータもなく、すべてが非常にフラットな幅広いテーブルでした。私の懸念は、時間とともにこれが本当にスケールしないだろうということでした。Rohitとチームと協力して、新しいソリューションを並行して導入し、徐々に移行していく方法を考え出しました。
Rohit、私たちのアプローチについて少し話してもらえますか？Leeが言及したように、私たちのアプローチの主なポイントは、どのようにプロジェクトを開始したかということでした。私たちは最終的な成果を念頭に置き、Lennarの現在のレポーティングとAnalyticsの大部分をサポートしているレガシーシステムから脱却したかったため、定められた期間内に移行を完了する必要がありました。Analyticsと言っても、ほとんどが既定のレポートについての話でした。AIやAIベースのアプリケーションを構築している部門もありましたが、主に必要だったのは、ユースケースをサポートするためにスケール可能で、大規模なデータの堅牢性を提供できるプラットフォームでした。
また、迅速に進める必要があったもう一つの重要な理由は、このような種類のプロジェクトの半減期と、経営陣が投資を継続する許容度には限界があり、できるだけ早く価値を示す必要があったからです。皆さんのチームと私たちのチームとのパートナーシップを通じて、迅速に進めることができました。データの部門横断的な視点が欠けていたため、マーケティングデータが優れた状態にあったとしても、建設から土地取得、リードの全体的な journey を通じてリードをどのように転換しているかといった情報を結びつける方法が不足していました。これらすべてが、大規模なデータの統合された価値を提供できるプラットフォームを考える上で不可欠となります。
私たちが話し合ったように、プログラムの実行において、最新のプラットフォームのすべての機能を確認する戦略的な最初のユースケースを特定し、テクノロジーとビジネスのリーダーシップとの信頼関係を構築し、ドメインベースの移行を行うというアプローチが重要でした。これが重要なのは、段階的に最新のプラットフォームにユースケースとユーザーをオンボーディングできるからです。プラットフォームを立ち上げる際には、3つの主要な要件がありました。最も重要なのは、より低いレイテンシーまたはリアルタイムに近い情報へのアクセスで、エンドユーザーが消費するためのキュレーションされた確認済みのデータを1時間以内に提供することが絶対的な最低条件でした。
2番目の考慮事項は、Lennarには多様なエンジニアリングチームがあり、プラットフォーム上で複数のビルダーが存在することでした。プラットフォーム全体で作業できるマルチユーザープラットフォームを実現する必要があり、これはCI/CDとDevOpsに支えられたマルチユーザー開発環境を意味します。プラットフォームの立ち上げ時から、GitによるCI/CD統合と明確に定義されたブランチ戦略、そしてProductionへのシームレスなコードのマージプッシュをサポートするTerraformモジュールで構築しました。これにより、Productionへの展開をどれだけ迅速に行えるか、そしてProductionへの展開がどれだけシームレスに行えるかが決まります。
AWSデータ＆AIプラットフォームのアーキテクチャと主要機能
これら全ての基盤となるのは、スケーラブルなアナリティクスを実現することです。プラットフォームは、データのスケール、情報の低レイテンシー、そして細かなアクセス制御に裏打ちされた、全員のためのクロスファンクショナルなデータビューをサポートする必要があります。誰もがデータにアクセスできますが、無制限に広範なアクセスを許可するわけではありません。LakeとSnowflake環境での細かなアクセス制御の実現は、私たちにとって非常に重要でした。これらが、ソリューションを構築する際の3つの重要な要件でした。ここで、アーキテクチャの核となる原則について少しお話ししたいと思います。6つの重要な要素を見ていくと、クロスファンクショナルなデータアクセスが非常に重要でした。
私たちは、クロスファンクショナルなインサイトを構築するために、LakeとSnowflakeにわたってRole-Based Access Controlを含む細かなアクセス制御を実現しました。データ品質とデータリネージは、私たちが構築するデータプラットフォームの基礎的な部分でした。AWS上でAscccamaを実装し、データ品質の監視とソースから消費までのリネージを実現しました。Ascccamaの機能を考えると、データ品質ルールからServiceNowチケットやアラートによる通知まで、プラットフォーム上のデータ可観測性の構築に役立ちます。特定のジョブやプロセスが予定より遅れている場合、データが利用できないことを発見する前に、エンドユーザーやデータ消費者に遅延を事前に通知することができます。
AWS のコンポーネント、特にGlue、Lambda、EMR、DBTの統合方法は、データ量のスケーリングとソリューションのスケーリングを実現する上で非常に重要でした。クラウドプラットフォームのコストオーバーランを避けるためにソリューションをスケールアップ・ダウンする方法を考えると、クラウド使用量の最適化は不可欠です。レガシープラットフォームをクラウドに近代化する際には、総保有コストがビジネスケースの重要な推進力となるべきです。プラットフォームを構築する際、コンポーネント全体でオートスケーリングをどこで有効にできるか、そしてプラットフォームが稼働していない時や高負荷でない時にはスケールダウンするようにしました。
コストを最適化するために、Snowflakeプラットフォームでの不要なコストを避けるため、Snowflakeから Lake HouseやLakeレイヤーへの消費を分離しました。これにLake HouseとSnowflakeを組み合わせることで、Leeが話した元のプラットフォームと比較してクラウドコストを60〜70%削減することができました。これらはすべて、LennarでのスケーラブルなAIの実現に焦点を当てています。私たちが構築してきたもの、構築中のもの、そして構築を検討しているものすべては、データとAI、そして関連するユースケースの将来的なスケーリングを目指しています。
アーキテクチャを見ると、非常に標準的なMedallionアーキテクチャのように見えますが、ツールの選択と統合方法がこれを特別なものにしています。もう一つの重要なポイントは、私たちがチームと共にプラットフォームを構築していることです。サポートが難しかったり、運用が困難なプラットフォームは作っていません。サポートと運用に移行した際に、簡単に対応できるソリューションセットとなるよう意識して構築しています。そのため、特にGlue、Lambda、DMSによる統合、DBTをスケーラブルに実行するためのEMR、そしてオープンストレージフォーマットのIcebergなど、AWSのベストオブブリードなネイティブサービスの使用など、意図的に選択した部分があります。Icebergを採用した理由は、データをSnowflakeにパイプする必要がなく、External Tableを使用してIcebergから直接読み取ることができ、Icebergフォーマットによるパフォーマンス上の利点があるなど、いくつかのメリットがあるためです。
ストレージレイヤーの下にあるボックスを見ると、先ほど簡単に触れたAscccamaについて説明されています。私たちがデータ品質を統合した方法は、データ品質のビジネスルールとデータの鮮度チェックをプラットフォーム全体に組み込むことでした。これをAscccamaで構築したデータリネージと組み合わせることで、エンドツーエンドの可視性を実現し、システムのバックボーンとして機能しています。
このリネージは、モダンなプラットフォームを構築する上で非常に重要です。アラートとリネージを結びつけることで、データプラットフォームの可観測性を理解することができるからです。また、再利用可能なPythonベースのユーティリティである独自のAudit Balance and Control Frameworkも備えています。これはジョブの統計、エラー、警告を捕捉し、各ジョブの開始から照合までを追跡し、読み取られたデータと書き込まれたデータの量を測定します。この照合とバランシングは、財務・会計の観点から、また重要なデータセットにおいて特に重要です。
ジョブの統計情報とリネージを結びつけるAscccamaを重ね合わせることで、カスタム開発によって可観測性プラットフォームとしてすぐに機能させることができます。データフローを見ると、次のスライドで説明する複数の取り込みパターンがあります。データが複数の取り込みパターンとS3ベースのイベントトリガーを通じてRawバケットであるBronzeレイヤーに入ってくると、Silverレイヤーである Prestageに直接ロードされます。データは生の形式で利用可能で、リアルタイムでクレンジングされ、キュレーションされてアクセスできます。そこから、ドメイン固有のDBTモデルが起動し、データをドメインまたはターゲット中心の構造にロードします。
同じパイプラインはSnowflakeまで続き、そこではディメンションとファクト、および集計されたレポーティングテーブルが用意されています。これらすべては30分間隔で実行されます。なぜなら、ソースでのデータ生成から消費レイヤーでのデータ利用可能までを1時間未満というSLAを満たす必要があるからです。また、Customer、Vendor、Itemなどの主要ドメインをマスターするためのマスターデータプログラムも進行中です。このキュレーションされたマスターデータは、全体的な分析とデータ品質向上のためにプラットフォームに投入されます。Enrichedレイヤーには、Amazon SageMakerのボックスがあります。これは私たちのMLプラットフォームを表しており、MPSがどのようにデータレイクレイヤーを使用してモデルを構築、管理、デプロイしているかを見ていきます。
Serveレイヤーには、Power BI、Tableau、そしていくつかのSSRSカスタムレポートによるレポートとダッシュボードが含まれています。Node.jsで書かれたカスタムアプリケーションもありますが、これらはすべてSnowflakeまたはレイクレイヤーからデータを取得しています。さらに、Palantir Foundryは、Palantir Foundryオントロジーに取り込むためにレイクレイヤーからデータを取得しています。 それでは、各取り込みプロセスと消費のパターンについて詳しく説明しましょう。取り込みについては、Lennarおよびサードパーティシステムのすべての取り込みニーズに対応する6つのパターンを構築しました。AWS DMS、SalesforceとSalesforce Marketing Cloud用のAppFlow、API交換用のGlue API、SFTP要件用のAWS Transfer Family、そしてLennarに存在するいくつかのERP用のリアルタイムレプリケーションエンジンであるQlikを使用しています。これら6つのパターンにおいて、データの種類やソースの種類を見ると、今後取り組む新しいソースにも容易にスケールできます。
このすべての統合は、Audit Balance and Controlフレームワークによってサポートされており、データの取り込みポイントから始まるデータ移動のエンドツーエンドのライフサイクルを追跡します。処理の流れを見ると、データがBronzeレイヤーに入ってくると、S3イベントに基づいてイベントベースのトリガーが発生し、リアルタイムでPreStageにデータがロードされます。そこから30分ごとのマイクロバッチサイクルで、特定のDBTモデルを実行してターゲット中心の構造にデータを格納します。
同じパイプラインがSnowflakeにも拡張され、これは別のDBTモデルセットであるディメンションとファクトを生成し、最終的な集計構造もすべて30分サイクルで実行されます。先ほど説明したレイヤーは、スケーラビリティ、スキーマの進化、およびクエリパフォーマンスの最適化を可能にするオープンストレージIcebergフォーマットを採用しています。消費側では、Snowflakeがディメンションとファクトベースの構造を持ち、これがスケーラビリティとセルフサービス分析に重要な役割を果たしています。私たちは、決められたレポートよりもセルフサービスの採用を推進しており、データセット間を簡単に移動し、異なるドメイン間でデータセットを結合できるようにしています。
先ほど説明したように、IcebergはPalantir FoundryやMLabsプラットフォーム、Sagemakerにデータを提供し、これがAI/MLをスケールさせるためのバックボーンとなります。DBTが重要な理由は、SQLのバックグラウンドを持つ人が現代のLakes Snowflakeベースのアーキテクチャーに移行する際、DBTがその移行を非常に容易にするからです。これは依然としてSQLベースのツールであり、DBTとSnowflakeのパフォーマンスは、よりスムーズな移行を実現する上で大きなメリットがあります。
このプラットフォームの機能を見ると、以前は1日2〜3回だった更新頻度が1時間ごとの更新になりました。これらはすべて、CI/CDとDevOpsのためのGit統合によってバックアップされたTerraformモジュールを通じて構築されており、新しい環境やパフォーマンステスト用の環境を数日ではなく数時間で作成できます。RBACを含む適切なアクセス制御を備えた部門横断的なデータアクセスも重要です。データ品質は、特に組織がGenAIのユースケースを検討する際に、私たちが行うすべての基盤となります。データのキュレーションに労力を費やす必要がありますが、適切な品質で信頼できるデータがあれば、ユースケースをより迅速にスケールアップできます。
MLOpsプラットフォームの統合とSageMakerの活用
MLOpsについてはこの後詳しく説明しますが、Medallionアーキテクチャー全体が、MLOpsからSagemakerやPalantirまで、MLとAIをスケールできる方法を提供しています。では、MLOpsとSagemakerについての説明に移りたいと思います。ありがとう、Rohit。Lennarは、モダンなデータプラットフォームの構築から始まり、主要なビジネス課題に対応するためのスケーラブルなMLOpsプラットフォームへと進化させ、データモダナイゼーションの旅で大きな進歩を遂げました。これは、Rohitが言及したように、セキュリティ、データ品質、データガバナンスなどの主要な機能を備えたオープンソースストレージフォーマットを統合した、統一されたMedallionデータとAIレイヤーから始まりました。これにより、データアクセスとデータ品質が確保され、既存のデータサイロが解消され、チーム間のコラボレーションが可能になりました。
チーム間でこのようなコラボレーション機能が整備され、セキュリティ機能とガバナンス機能も備わったことで、機密情報やデータが保護され、業界標準へのコンプライアンスが確保されています。次のステップとして、MLOpsプラットフォームをGoldレイヤーとSnowflakeに統合しました。これにより、MLモデルの開発・デプロイの効率性と能力が向上し、モデルの開発サイクルタイムが短縮されました。
これらの機能により、Lennarは予測分析を活用して、需要予測をより効率的に行い、在庫を管理し、サプライチェーンを最適化できるようになりました。AIモデルは開発サイクルの早い段階で異常や問題を検出することができます。また、MLモデルはより優れた顧客セグメンテーションを提供し、よりパーソナライズされたマーケティング戦略を可能にしています。
プラットフォームの主要な機能についてお話しできることを嬉しく思います。その中核となるのが、集中管理されたFeature Storeです。これにより、データサイエンティストとエンジニアが個別に機能を再構築して重複や不整合を引き起こすことなく、最新かつ高品質な特徴量を使用できるようになりました。このFeature Storeを利用可能にすることで、開発のサイクルタイムが短縮され、すぐに活用できる特徴量を提供できるようになりました。
DevやTestなどの下位環境のワークフローにSageMakerパイプラインを統合することで、データ処理とモデル検証がより効率的に行えるようになりました。モデルが本番環境へのデプロイ準備が整った際も、同じパイプライン内で効率的に処理できます。MLOpsアーキテクチャにより、データサイエンティストとエンジニアは専用の環境でテストを行い、本番環境に移行する前にバグの有無やモデルが期待通りの成果を上げているかを確認することができます。
GitHubへのコミットが必要な場合、自動的に検証チェックがトリガーされ、コードがコミットされてパイプラインにプッシュされる前に、問題を事前に検出します。コミット時のこれらの検証チェックにより、信頼性が高まり、完全にテスト済みのモデルのみを本番環境にプッシュすることが保証されます。最後の機能として、完全にテスト済みのモデルのみを本番環境にプッシュし、それらのモデルがリアルタイム予測とバッチ予測の両方を処理できるようにすることで、本番環境でのインサイトを提供できるようになっています。
MLOpsのアーキテクチャを見ると、ここで重要なポイントは4つの環境による統合を実現していることです。完全に管理された環境でモデルの構築とテストを行う機能があり、これは一種のサンドボックスですが、本番データを使用しています。なぜなら、本番データを使ってモデルを構築し、仮説を検証したいからです。表示されているボックスは全て、テスト、開発、サンドボックス開発、テスト、本番という観点から見ることができ、単なる実験だけでなく、実験を経て本番環境に移行し、スケールさせるための完全なモデル構築ライフサイクルを提供します。AWSプラットフォームで実験する際、本番データを開発環境に取り込むことになりますが、これは理想的ではありません。
これは、モデル管理、モデル移行、そしてエンドツーエンドの機能を可能にする、よく統合された構造です。ありがとう、Rohitさん。素晴らしいプレゼンでした。あの椅子から早く立ちたくて仕方がありませんでした。重心バランスに問題がある人にとって、あの椅子は本当に危険ですね。
Lennarにおけるプラットフォーム導入の価値と今後の展望
Lennarにおける価値実現について話しましょう。その前に、MilanさんとRohitさんが詳細なチャートを素晴らしく説明してくれたことに感謝したいと思います。最後に彼らに質問できる機会があると思いますので、どんどん質問してください。なぜなら、それらは「どのように」を定義する非常に重要な概念だからです。 さて、Lennarにおける価値実現についてですが - アーキテクチャを構築するのは素晴らしいことですが、なぜ私たちはそれを気にする必要があるのでしょうか？このようなプラットフォームで私たちが得られるものは何でしょうか？クラウドに移行する最初の理由はコスト削減です。Lennarには、データを連携された方法で - あるいは他の人が言うかもしれない断片化された方法で - 運用している複数の異なるレガシープラットフォームがありました。私たちが目指したのは、そのコストを一箇所に集約することでした。これは私たちにとって大きな推進力でした。なぜなら、Lennarのデータは収益よりも速く成長していくため、より低コストで運用できることを確実にしたかったからです。
私たちは全てを統合したいと考えました。断片化された5つ、6つ、7つ、8つの異なるデータプラットフォームが同じようなことをしているのは意味がありません。次に、生産性向上のためにクラウドを活用します。生産性における大きなポイントは、マクロ指標を正確に把握することです - 販売した住宅数、引き渡した住宅数、着工した住宅数などです。これらのマクロ指標をできるだけ早く把握する必要があり、このプラットフォームがそれを可能にします。また、よりPersonaベースのプロセスベースの消費に関する利点や、堅牢なデータ管理による恩恵もあります。
ここで少し時間を取りましょう。私たちは常にデータ管理について話しています - 品質やLineageといった言葉をよく耳にしますが、これらの言葉は非常に重要です。なぜなら、これらは全ての結果として生まれる「信頼」という指標のインプットとなるからです。ビジネスユーザー、ITユーザー、そして全ての外部ユースケースから信頼されるプラットフォームを構築したいのです。信頼は重要な指標であり、それこそが私たちが目指すものです。だからこそ、説明があったように、私たちのプラットフォームが実現する堅牢なデータ管理に時間を投資する価値があるのです。
最後に、アーキテクチャを将来に備えたものにする必要があります。私たちを取り巻く世界は急速に進化しているため、アーキテクチャもRAGやVector Databaseを通じたGenerative AIの高度なユースケースに対応できるように進化すべきです。Milanが話したように、Machine Learningの産業化に焦点を当てた現在のAWSプラットフォームの実装 - MLOpsはまさにMachine Learningの産業化に他なりません - によって、それが可能になり、そこに大きな価値の実現があります。 次のスライドに示すように、私たちには何らかの形でアナリティクスを使用している約13,000人のエンドユーザーがいます。プラットフォームの機能を約5,000人のユーザーに展開し、さらに増加中です。年末までには、ユーザーベースの半分が、私たちがパートナーシップで構築しているプラットフォーム機能を使用することになるでしょう。これは私たちにとって大きな成果です。なぜなら、優れたプラットフォームであっても、ユーザーエンゲージメントがないことがあり、エンゲージメントのないプラットフォームは消えてしまうからです。そのため、この指標は非常に重要なのです。
次にお話ししたいのは、データ資産の約90%が現在、この新しいプラットフォームに統合されているということです。これは、本当に重要な社内データをすべて取り込むことができたということを意味します。
これには、財務データ、建設データ、購買データ、ITデータが含まれます。さらに、定期的に使用する外部データも多く取り込むことができました：MLSデータ、ATOMデータ、Zondaなどです。他にも定期的に利用しているデータセットが多くあります。社内データと外部データをプラットフォームに統合することで、会場にいらっしゃる多くの方々が現在取り組んでいるような多くのユースケースを実現することができました。ご参加いただき、ありがとうございます。
また、単にプラットフォームを構築するだけでなく、何らかのビジネス価値を持つ多くのユースケースを展開し始めていることを確認したいと思います。ここにいらっしゃる方々と、私たちは2、3のユースケースについて話し合いましたが、実際にはデータを活用してビジネスの文脈に効果的な密着性を構築するものが、それ以上にあります。そのようなユースケースの1つは、Internet Sales Consultantの生産性を向上させることに関するもので、それを構築したチームが会場にいます。データを素早く統合できるようになったからこそ、彼らはそれを実現できたのです。
最後に、データが1か所に構築・統合されていれば、Generative AIのユースケースがはるかに容易になります。なぜなら、AWS SageMaker Bedrockなどを活用してアプリケーションを迅速にスケールできるからです。Salesforceやその他のサードパーティの機能システムの機能を使用する必要がある場合でも、データが統合されているため、それが可能になります。
この会話から得られる重要なポイントは何でしょうか？まず第一に、なぜこのようなパートナーシップが必要なのでしょうか？このようなパートナーシップが必要な理由は、戦略的計画から実行まで、エンドツーエンドで確実に進められるようにするためです。つまり、年単位で計画を立て、日単位や週単位で実行していくわけですが、このようなパートナーシップがそれを可能にします。第二に、アーキテクチャとデザインが重要です。なぜなら、スケーラブルで、再現性があり、保守可能で、あなたがいなくなった後でもビジネス価値を生み続けるようなものを構築したいからです。そして最後に、より将来性のあるものを構築する方法について確認しておきたいと思います。このパートナーシップによって、外部からの視点と内部からの視点の両方が得られ、共同で未来を築いていくことができるため、それが可能になります。
そのため、マイグレーションの旅を始める際には、効果的なパートナーシップを組んで、迅速にゴールにたどり着くことが重要です。以上で私の説明は終わりですが、BrightさんやBroadlyさん、何か付け加えることはありますか？ここで質疑応答の時間を設けて、アーキテクチャに関する質問などにお答えしたいと思います。ありがとうございました。
※ こちらの記事は Amazon Bedrock を利用することで全て自動で作成しています。
※ 生成AI記事によるインターネット汚染の懸念を踏まえ、本記事ではセッション動画を情報量をほぼ変化させずに文字と画像に変換することで、できるだけオリジナルコンテンツそのものの価値を維持しつつ、多言語でのAccessibilityやGooglabilityを高められればと考えています。
Discussion