re:Invent 2025: NFL、Bundesliga、PGA TourのデータとAIによるファンエンゲージメント事例
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
re:Invent 2025 の書き起こし記事については、こちらの Spreadsheet に情報をまとめています。合わせてご確認ください
📖 re:Invent 2025: AWS re:Invent 2025 - Driving Fan Engagement with Data, Analytics, & AI (SPF308)
この動画では、AWS のスポーツソリューションチームが、データ、分析、AI を活用してファンエンゲージメントを推進する方法を解説しています。NFL は AWS 上で 90 億行以上のデータを処理し、700 万以上のファンプロファイルを管理することで、ファン理解を 4 倍向上させました。Bundesliga は Amazon Personalize を使用してアプリ内滞在時間を 17% 増加させ、PGA Tour は Amazon Bedrock で AI コメンテーションシステム Tourcast を構築し、全ショットを 10 秒以内にカバーしています。技術面では、AWS Glue、Amazon Kinesis、Amazon Redshift などを使用したファンデータプラットフォームの構築方法、AWS Entity Resolution による identity resolution、レイクハウスとデータウェアハウスのハイブリッドアプローチが紹介されています。さらに Amazon Bedrock Agent Core を活用した agentic AI ソリューションにより、コンテンツ生成やパーソナライゼーションなど、新しいファン体験の創出が可能になることが示されています。
※ こちらは既存の講演の内容を最大限維持しつつ自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますのでご留意下さい。
本編
スポーツ業界におけるファンエンゲージメントの重要性とデータ活用の必要性
皆さん、こんにちは。スポーツフォーラムにお越しいただきありがとうございます。皆さんの re:Invent の体験をこのセッションで、そしてスポーツフォーラムでのスポーツパートナーシップによる素晴らしいアクティベーションで、キックオフできることを本当に楽しみにしています。私は Jake Lee で、AWS のスポーツソリューションマネージャーです。同僚の Ashwini Rudra と一緒にいます。私たちの二人は、AWS の多くのスポーツ顧客をサポートしているチームにいます。
さて、皆さんがスポーツフォーラムとこのセッションに来た理由は、おそらくスポーツやエンターテインメントへの関心だと思います。今日の観客の中でスポーツファンの皆さんに、私は本当に皆さんのファン体験が私のものより良いことを願っています。なぜなら、私のものは感情のジェットコースターと心が砕けるような敗北の連続だったからです。しかし、私のスポーツチームとのそのジェットコースターのような感情を経験してきたにもかかわらず、私は依然としてそれらのチームに戻ってきて、彼らのプロモーションを見たときにマーチャンダイズを購入し、ゲームのチケットを買い、コンテンツを見て、オンラインでデジタルコンテンツと相互作用しています。
これらは、スポーツ、メディア、エンターテインメント、ゲームの組織がどのようにデータ、分析、AI を使用してファンエンゲージメントを推進できるかの例です。今日、消費者が利用できるコンテンツがこれほど豊富にある中で、スポーツ、エンターテインメント、ゲームの組織は、消費者の時間を競い合う方法を見つける必要があります。 1日の時間は限られていますが、ファンが相互作用できるオプションはたくさんあります。 スポーツはライブ放送を支配しています。 ファンが見るエキサイティングなゲームがなく、フィールドで起きていることに飽きたら、彼らは好きなプログラミングを見ることができるテレビチャンネルとストリーミングプラットフォームを持っています。 それに飽きて、他の何かを見たい、または他の何かをしたいと思ったら、彼らはモバイルデバイス、タブレット、コンピュータ、コンソールで簡単にアクセスできるゲームを持っています。
エンターテインメント提供への頻繁な復帰の意図は、ポジティブな消費者体験から始まります。組織は、デジタル消費者を保持する方法を見つけるために非常に多くの時間を費やす必要があります。今日はスポーツフォーラムにいるので、スポーツとファン体験のレンズを通してこれを分析します。 ファン体験の中で、顧客とファンは、見ることができるブロードキャストとテレビで放映されるエキサイティングなコンテンツを期待しています。彼らは彼らの体験が価値があり、非常にエンターテイニングであることを望んでいます。彼らはこれらのゲームがスリリングでエキサイティングであることを望んでいます。
スポーツリーグとスポーツ組織からのコンテンツと相互作用するとき、彼らはこれらの体験が合理化され、非常に明確であることを望んでいます。彼らはそれらが簡単にアクセスできることを望んでいます。彼らは自分たちにとって重要な情報、メディア、コンテンツを非常に素早く見つけたいと思っており、これらの体験をシームレスにナビゲートできることを望んでいます。 彼らはまたインタラクティブなコンテンツを望んでいます。ファンと消費者は、同じものを見ている他の人と相互作用できる方法を見つけたいと思っています。しかし、彼らは実際にスクリーンに表示されているものに貢献できるとき、多くの価値を見出しています。
最後に、パーソナライゼーションは非常に重要です。なぜなら、ゲーム からライブスポーツまで、毎日非常に多くのメディアとコンテンツが作成されている中で、ファンは自分たちが気になるコンテンツを見つけることができたいからです。ファンはデジタルプラットフォームとメディアで簡単にアクセスできるコンテンツを見つけたいと考えており、彼ら専用に設計されたキュレーションされたレコメンデーションを通じてパーソナライズされた体験を求めています。これらのプラットフォーム上での体験は、個々の消費者に関するデータを生成しており、これらのデータポイントは彼らが相互作用しているすべてのチャネルにわたって取得されています。
ファンデータプロフィールの構築とAI・機械学習による体験の進化
チケットを購入したり、アカウントにサインアップしたりするファンは、プロフィールを作成し、組織がファンプロフィールを取得するための基盤を確立します。これには地理的データと人口統計データが含まれており、そのプロフィールの基盤となります。 ジャージやマーチャンダイズなど、彼らが購入しているものに基づいて、これらのファンの好みが把握されます。
デジタル面では、ユーザーの行動とアプリケーションおよびオンラインサイトとのインタラクションもリアルタイムで取得されています。これには、ユーザーがインタラクションするビデオと記事の数、視聴時間、そしてそのすべての情報が含まれており、これらのユーザー向けのコンテンツを設計し、彼らのデータプロフィールを強化するために取得されています。さらに、異なるファン間の関連性も作られています。 あるチームやリーグを応援しているファンで、密接に関連し結びついている他のファンは、同じ興味を共有し、同じ組織を応援しているかもしれません。これらは、異なるドメイン全体でデータがどのように取得され、ファンデータプロフィールを構築しているかの例のほんの一部です。
ファンに関するデータとプロフィールを使用するという概念は新しいものではありません。スポーツでこれらの機能を使用する初期段階では、ファンデータプロフィールを作成し、パーソナライゼーションとセグメンテーションを実現するためにデータと分析が使用されていました。 Machine learning モデルも、スポーツの高度な統計を作成するために使用されており、テレビで放映されているゲームを視聴する視聴者が、放映されているゲームをより理解し、より精通するのに役立っていました。 これらの統計は初期段階では、スポーツの最大のプレーを説明するために使用され、非常にロジックベースであり、選手がどのくらいの速度で走っているか、またはボールがどのくらい遠くまで移動しているかなど、そのようなことだけを説明していました。
分析、データ、AI の機能がより高度になるにつれて、組織はより新しい体験を作成することができるようになりました。 高度な統計はより診断的で予測的な性質を持つようになり、選手、チーム、そして彼らが対戦した異なるフォーメーションに適用することができるようになりました。Generative AI の出現により、メディアとコンテンツはより高速で、より利用しやすくなりました。スポーツ、メディア、エンターテインメント業界の組織は、コンテンツを見つけるプロセスを加速し、それをオンラインに置き、ファンと消費者の前に配置するのに役立つソリューションを作成する方法を見つけています。情報検索はさらに高速になり、低レベルの問題を解決するプロセスもはるかに高速になりました。
組織がAI機能の活用にますます慣れてくるにつれて、ファンエクスペリエンスを向上させ、ファンが楽しめる新しい体験やコンテンツを作り出そうとしています。先ほど説明したパーソナライゼーションは、ハイパーパーソナライゼーションへと進化し、機械学習の手法を取り入れることで精度を高め、ファンに対してより優れた推奨を提供するようになっています。AIを活用した機能を備えた新しい体験や新しいデジタル製品がますます一般的になってきています。組織は自分たちのチームだけでなく、エンターテインメントエコシステム内のパートナーや他の組織向けのソリューションも作り出し、ファンエクスペリエンスを向上させる方法を見つけています。
NFLとPGA Tourに見るファンデータプラットフォームとAI活用の成功事例
本日は、主に2つの領域に焦点を当てたいと思います。すべてのデータプロフィールを管理するファンデータプラットフォームと、AIを活用した機能を使用して新しい体験やデジタル製品を作成することです。スポーツ、エンターテインメント、メディア、ゲーム企業全体でこれをどのように実現できるかについてのインスピレーションを得るために、同様のソリューションを構築したスポーツパートナーシップの例を参考にしています。National Football League、つまりNFLは、AWSサービスとパートナーソリューションで構築されたAWSプラットフォームを使用して、すべてのファンの統一されたビューを作成しました。このファンプラットフォームは、90億行以上のデータを250以上のディメンションで処理しています。これらのレコードはすべて、Amazon Redshift内に保存・管理される700万以上のファンデータプロフィールに精製、解決、エンリッチ、標準化されています。毎日、1,000以上のデータフィードがAmazon GlueとAmazon Kinesis data streamsを使用して処理・標準化されています。
このデータプラットフォームを構築した結果、ファンに対する理解と認識が少なくとも4倍向上しました。これにより、ファンと消費者がメールやプロモーションにオプトインする率が2～3倍増加しました。
プリファレンスがパーソナライゼーションをどのように推進するかを見ると、Bundesligaの例を検証できます。彼らはアプリエンゲージメントをパーソナライズしています。サッカーは非常にパーソナルなスポーツであり、Bundesligaとブンデスリーガ2の間には36の異なるチームがあります。これらのチーム間で、Bundesligaは平均してファンが約4つの異なる組織とチームをサポートしていることを特定しました。これは約140万の異なるファンプリファレンスの組み合わせです。デモグラフィクス、プリファレンス、インタラクション、行動などの要因を組み込むと、さらに複雑になります。
Bundesligaは、Amazon Personalizeを使用してこれらの異なる組み合わせをより適切に分析・処理し、Bundesligaアプリ上の記事に対してより優れた推奨を作成できるようにしています。この機能と拡張をBundesligaアプリにリリースした後、アプリ内での滞在時間が17%増加しました。アプリ内でより多くの時間を費やしたユーザーは、このパーソナライズされた推奨システムにより、開かれた記事の数が67%増加しました。ユーザーが実施したすべての異なるセッションのうち、ユーザーが実際に異なる記事を開いたセッションが32%増加しました。
組織がどのようにして AI プロダクトを作成して新しいファン体験を生み出すことができるかを見てみましょう。PGA Tour は Tourcast という AI コメンテーションシステムを作成しました。従来のブロードキャストでは、PGA Tour はトーナメント中のすべての選手のスイングの約 25% しかカバーすることができず、それらはすべてそのブロードキャストに限定されていました。 PGA Tour は毎週末のトーナメントで 5,300 万個の異なるデータポイントを処理・管理することができており、これらはすべて DynamoDB 内で管理・保存されています。これらのすべてのデータポイントを使用して、Amazon Bedrock は PGA Tour トーナメント全体で行われるすべてのショットに対して AI 生成コメンテーションを作成するために使用されています。
このコメンテーションはデータポイントに基づいてショットを説明するだけでなく、コース上で何が起こっているのか、そしてそのショットがその特定のトーナメントの文脈において選手にとって何を意味するのかについてのコンテキストも提供しています。その結果、PGA Tour はトーナメント全体のすべての選手のスイングの 100% をカバーすることができるようになりました。非常に印象的なのは、選手がコース上でストロークを行ってから 10 秒以内に、その AI 生成コメンテーションとコンテキストが作成され、Tourcast の AI コメンテーションシステム内に表示されるということです。
データ分析と AI をどのように活用できるかについて、さまざまなスポーツ組織やこれらのイノベーションを作成した顧客を見てきました。ここで Ashwini に、AWS のデータおよび分析サービスを使用してこれらを作成する方法についてお話しいただくようにお招きします。
Fan 360プラットフォームの構築：データインジェストから変換処理まで
皆さん、こんにちは。私は Ashwini Rudra で、AWS の Principal Solutions Architect です。ここでもう 8 年 4 ヶ月 13 日を過ごしています。データを提供しているのは、データはアーキテクチャを構築する際に非常に重要なポイントであり、取りたい情報に基づいた決定にはデータが必要だからです。データプラットフォームを構築する際に信頼をもたらします。どのようにしてそれを行うことができるかについてのガイダンスを提供したいのですが、データエンジニアリング、ETL、またはデータ分析の背景を持っている人がどのくらいいるか知りたいです。
私が行おうとしていることは多くの AWS サービスを使用することですが、それぞれに深く掘り下げる時間がないかもしれません。しかし、fan 360、ファンデータプラットフォーム、またはファンゲノムプラットフォームを構築するための非常に一般的なパターンについて学びます。何と名付けてもかまいません。
ご覧いただけるように、あらゆるデータプラットフォームと Fan 360 プラットフォームはレイヤーに分かれています。非常に一般的なレイヤーはデータソースレイヤーで、ここではファンについてどのようなデータソースや異なるデータソースを収集するかを決定します。次に、インジェスションレイヤーが見えてきます。ここではそのデータをどのようにインジェストするかを決定します。60個または70個のソースがあるかもしれませんし、それぞれが3つの異なる特性を持つかもしれません。ボリューム、バラエティ、そしてベロシティです。その後、データパイプラインに従ってデータを処理する必要があります。データプラットフォーム全体に複数のパイプラインが存在する可能性があります。データエンジニアリングチーム用のパイプライン、アナリティクスチーム用のパイプライン、そしてファンや第三者ベンダーまたはパートナーに直接行くパイプラインです。
その後、ニーズに応じてデータを保存する必要があります。機械学習モデルはアナリティクスチームのツールとは異なるフォーマットでデータを理解するため、データをマッサージして異なるフォーマットで保存し、システム内、ファンへ、または消費者に情報を共有できるようにする必要があります。1つにマージできる、または別々のレイヤーとして持つことができる2つのレイヤーがさらにあります。それはあなた次第です。これらはすべて論理的なレイヤーだからです。1つはインテリジェンスレイヤーで、ここではデータを準備し、データエンジニアリングまたはデータサイエンティストチームと共有して、彼らがデータを試験し、どのような追加価値を得られるかを教えてもらうことができます。もう1つはアクティベーションレイヤーで、これはメトリクスについてです。KPIが何であるか、メトリクスが何であるか、ダッシュボードが何を表示しているか、そして彼らが何を達成したいのかを正確に共有します。ですから、現在これを行う方法は正確に2つあります。1つは既知のもの、つまりあなたがすでに知っていることで、もう1つは未知のもの、つまりどのようなことが可能かについてまったく考えがない場合です。
ここでもう1つのダイアグラムを表示しています。 これらはデータソースを再度見ることができます。そしてそれらは顧客から顧客へ、チームからチームへ、そしてリーグからリーグへと異なります。非常に一般的なソースには、リーグ独自のソース、チームまたはクラブから取得しているデータ、ファンの場合はチケッティングデータ、異なるチャネルまたはサブスクリプションメカニズムにサブスクライブしている場合はサブスクリプション情報、そしてマーチャンダイズ情報が含まれます。ファンとして、あなたはTシャツを買いに行くかもしれません。そしてその情報はその特定の企業によって保持されています。リーグまたはチームとして、あなたはそのすべてのデータをインジェストし、どこかに保存し、異なるツールを使用して統合したいと考えています。次の数分間で、これらの一般的なパターンのそれぞれについて詳しく説明します。その後、データを異なる目的別に構築されたデータベースに保存します。Amazon Redshift のようなデータウェアハウスである可能性があります。または、画像またはテキストベースのデータのいずれかを、データレイク内に直接保存することができます。または、Amazon EMR を使用するか、AWS Glue を直接使用して、ボリューム、サイズ、またはバラエティに基づいてデータを変換したい場合があります。その後、そのデータをアクティベーションレイヤーで利用可能にし、誰もがアクセスできます。
1つお伝えしたいことは、データカタログとガバナンスレイヤーがあることが見えるということです。顧客は一般的に AWS Lake Formation または AWS DataZone サービスでこれを使用して、そのデータを管理し、データ系統とデータがどのように変化しているかが追跡可能であることを確認します。 ここで異なる AWS ダイアグラムとサービスで同じコンセプトを共有しています。 これらのパターンについてはすべてもっと詳しく説明します。ここに1つの例があります。データインジェスションパターンがあり、データをインジェストする方法を知りたいとします。60個または70個のソースがある可能性があります。聞いたことがあるかもしれない1つの一般的なアプローチは AWS Glue Crawler です。60以上の接続があり、これらのソースに直接接続し、データベースをクロールし、データカタログを作成できます。別のアプローチは、顧客またはパートナーが API でデータベースを公開する場合です。
3つまたは4つのオプションがあります。Kubernetes を使用したコンテナを使用して、これらの API に接続し、データをマッサージし、情報を取得し、S3 バケットに入れることができます。これを raw zone または bronze zone と呼びます。複数の命名法が存在します。10 MB 未満の小さなペイロードサイズの場合、AWS Lambda が活躍します。AWS Lambda でサーバーレスアプローチを直接使用して、API を呼び出し、ペイロードを取得し、AWS サービスに保存できます。API がバッチ処理をサポートしている場合、AWS Batch を使用できます。ECS も別のオプションです。そこで言及していませんが、繰り返しになりますが、データがどのように公開されているかによって異なります。
リアルタイムストリーミングについて、 Kinesis、Kafka、Flink のどれを使うべきかについて、多くの人が混乱しているのを見かけます。繰り返しになりますが、ペイロードサイズ、データをどのくらい素早く保存したいか、処理中にデータを変換したいのか、それとも後で変換したいのかによって異なります。ペイロードサイズが小さく、多様性と速度が低いデータの場合は、Kinesis Data Streams を使用してください。リアルタイム変換と分析が必要な場合は、Kinesis Data Firehose を使用してください。Flink または MSK の場合は、より大きなペイロードサイズを考慮してください。MSK または RabbitMQ は、データの速度、多様性、スピードに応じてうまく機能します。
推奨事項は、データを S3 に保存することです。これはあなたの raw zone です。 顧客またはパートナーがファイルアップロードを使用してデータを保存し、単にそれをレプリケートしたい場合、AWS Transfer Family が利用可能です。これは FTP、FTPS、または SFTP プロトコルを理解しています。直接アップロードでき、S3 に接続されるため、データは landing zone に入ります。バッチ処理については、 サイズに基づいて、AWS Batch、EMR、または AWS Glue などのオプションがあります。AWS Glue には変換機能があります。AWS Glue について聞いたことがあるかもしれませんが、250 以上の変換機能があり、データ検証、null 値のチェック、要件に応じたデータの補充、日付形式の変更、または Parquet 形式への変更を行うことができます。これにより、適切なデータ形式を選択できます。
完全なアップロードを実行したが、1 時間ごと、または 1 日ごとに増分変更がある change data capture の要件がある場合、AWS DMS というオプションがあります。これはデータマイグレーションサービスです。データをレプリケートし、change data capture を使用して、どのくらいのデータが変更されたかを特定できるため、変更されたデータのみを data zone にレプリケートしています。また、AWS AppFlow もあります。これは SharePoint、他のファイルストレージ、または Salesforce などの他のソースに接続します。AppFlow には 50 以上のコネクタがあり、異なる SaaS アプリケーションに接続して、その情報とデータを取得し、そのデータを landing zone、bronze zone、または raw zone に配置できます。
これでデータが landing zone にあり、利用可能になりました。 一般的に、人々がすることは複数のデータパイプラインを作成することです。私は 1 つの例を示していますが、推奨事項は 2 つの方法で逆向きに作業することです。1 つは、パートナー、顧客、チーム、マーケティング、または営業チームがメトリクスの観点から何を望んでいるかを正確に知っている逆向きの作業です。ダッシュボードがどのように見えるか、データをどこに保存するか、正確にどの KPI が必要かを知っています。その後、どのような形式、どのようなデータ形式、どのようなクリーニングが必要か、機械学習ベースの場合はどのような特徴エンジニアリングが必要かを決定することで、それに応じてパイプライン全体を構築します。その後、そのデータをエクスポートします。
もう 1 つのアプローチは、変換準備完了の enrichment データです。これをデータサイエンティストに公開します。これは未知の情報のようなものです。experimentation チームに提供して、何ができるのか、可能性の芸術は何かを言います。その後、そのようにデータを公開します。スライドで 2 つのゾーンが見えます。1 つは business transformation ready で、もう 1 つは analytics ready です。私たちはそのアプローチを通じてこれを達成しました。私が見た最も一般的な変換、そして AWS Glue について話しましたが、これは変換を行いますが、パイプラインでは非常に一般的な identity resolution を見てきました。これについては後で話したいと思います。
Identity resolution というのは、複数のソースからデータを取得することを意味します。マーチャンダイズチームから来たデータもあれば、チケッティング情報から来たデータもあり、チームやリーグから来たデータもあります。それらがファンに関してどのようにつながっているのか、それらのファンが同じファンなのか異なるファンなのか、どのようにしてそれを実現するのか。その後、インクリメンタル処理を行います。品質チェック、QA チェックを行い、null データを要件に応じて変換し、Parquet フォーマットに変換します。これらすべての変換を行い、fan loyalty scoring が 1 つ、fan segmentation がもう 1 つです。
これらは統計的および数学的な変更です。これらの数学モデルの実行には AWS SageMaker を使用し、その後 curated zone に移動します。 その後、データはさらなる処理に利用可能になります。
Identity Resolutionとデータアーキテクチャ：レイクハウスとデータウェアハウスの選択
データは利用可能な API、ファン、またはアプリケーションを通じてさらに処理することができます。または BI チームに送信することができます。 では、最初の重要な側面について説明しましょう。それは identity resolution です。これは、これらのファンが同じ人であることをどのように実現するかについてです。 ここに実際の例があります。私がファンだとして、チケットを購入してゲームを見ます。その後、別のベンダーに行って、私のお気に入りの T シャツの 1 つを購入します。その後、別のアプリに行ってビデオと記事を探します。チームやリーグとして、あなたはこの情報を収集しますが、これら 3 つのインタラクションが同じファンまたは同じ人からのものであることをどのように実現しますか？
また、同じ人かもしれませんが、同じ家族または友人グループからの別の人かもしれないシナリオもあります。つまり、彼らは同じファングループに関連しています。 Identity resolution は通常、名前と住所が一致するかどうかを確認して同じファンであるかどうかを判断するなど、標準的なマッチングを通じて行われます。 しかし、数百万のレコードを取得しているとします。通常の処理を通じて情報マッチングを実行するには時間がかかります。 その場合、2 つのオプションがあります。1 つは fuzzy logic を使用して決定とマッチングを行うことで、もう 1 つは機械学習モデルを使用することです。
ファンと顧客の関係を見つけ、これらが同じ人または同じファンであるかどうかを確信を持って判断するために、fan profiling を行う必要があります。これにより、マーケティングチームまたはセールスチームがオファー、チケット、ロイヤルティスコアについてファンに情報を提供する際により良い仕事ができます。プロセスには、データの取り込みと正規化、ファンプロファイルの作成、そしてマッチングが含まれます。これにより、fan identity register service が得られます。 Identity resolution は 2 つの方法で実現できます。1 つは AWS Entity Resolution service を使用することです。これはインフラストラクチャを管理する必要がない管理サービスです。もう 1 つは EMR を通じて処理することです。ここでもアルゴリズムが利用可能です。
推奨事項としては、まずファジィロジックのようなマッチングルールに基づいた決定論的な方法を行うことです。その後で機械学習アルゴリズムを実行します。理由としては、情報が不足している場合があるので、これらのファンが同じグループからのものであるか、あるいはこの2人のファンが同じ人物であるかという確率が得られます。そのデータを情報として与えて、信頼度が高い場合は、あなたが持っている情報に基づいてこれらが同じ人物であるという信頼度とともにそれらのファンをマージします。これにより、データを確実な方法で構造化できるので、そのデータに対して何をすべきかについて、情報に基づいた決定を下すことができます。
その後、あなたのデータは curated zone に準備ができます。さらなる分析のためにそれをどのように公開するかが重要です。みんな機械学習と AI について話していますが、そこには2つのオプションがあります。1つは SageMaker で、もう1つは Bedrock です。通常の機械学習機能の場合、セグメンテーションやはい、いいえと言うバイナリ分類を行いたいとしましょう。Amazon SageMaker に行きます。これは S3 とよく統合されています。あなたのデータはすでにそのアルゴリズム対応データフォーマットに従って準備ができています。接続して、アルゴリズムを実行して、データを取得して、それを S3 に保存します。これがあなたの curated zone です。あなたのデータは準備ができていて、複数のパイプラインがあるかもしれません。
もう1つのオプションは、このファンは過去7年間のロイヤルファンであり、このくらいのポイントを集めたブロンズメダルを持っているというようなファンの概要を取得したい場合です。Amazon Bedrock を使用して概要結果を取得し、必要に応じてデータを保存して、アプリケーションまたはサードパーティのメンバーに公開できます。生成 AI の場合、ベクトルデータベースが必要になる場合があります。複数のオプションがあります。OpenSearch を共有していますが、PostgreSQL でもこれを実現できます。ファン間の関係を計算したいとしましょう。グラフデータベースが必要になる場合があります。その場合、Amazon Neptune は別の選択肢です。
後で話したいもう1つのオプションがありますが、ここで Redshift について言及しました。これはデータウェアハウスソリューションです。ほとんどの場合、顧客がデータレイク、レイクハウス、またはデータウェアハウスのどちらに行くべきか、それらの違いは何か、どのパターンを選択すべきかについて混乱しているのを見ています。BI レポートとクリーンルームにそれをどのように公開するかが重要です。あなたのデータが準備ができたら、後で話しますが、BI オプションの場合、S3 に接続する任意の BI ツールを使用できます。QuickSight があります。これは最近 AI 対応になっています。
アドホッククエリの場合、Amazon Athena を使用できます。ここで SQL ベースのクエリを実行して結果を取得できます。人々は AWS Cleanroom を使用してパートナーと共有しています。非常に重要なアーキテクチャの決定の1つについて話しましょう。レイクハウスかデータウェアハウスか。何をすべきか。これは非常に基本的で高レベルの情報です。データエンジニアリングチームが強く、オープンソースモデルを理解するデータサイエンティストがいて、基本的な分析機能を持っていて、あなたのデータで実験したい場合は、データレイクハウスアプローチに進みます。
既に知られたメトリクスやダッシュボード、実行したい特定のクエリ集約クエリについて理解している場合は、データウェアハウスのアプローチを選択してください。チームが従来の SQL BI スキルを持っている場合、データレイクは一般的に Amazon EMR と Apache Iceberg または Hoodie のいずれかを使用します。問題は、データレイク上でトランザクションと ACID プロパティをどのように実現するかということです。Apache Iceberg と Hoodie を使用して ACID プロパティを実現し、トランザクショナルなアプローチを提供します。データウェアハウスの場合、これらの機能はその目標を達成するために既に組み込まれています。
しかし、最近では生データを実験・共有しながら、BI ツールに直接接続できるデータウェアハウス機能も実現したいとしましょう。AWS の素晴らしいところは、ハイブリッドアプローチを使用できることです。レイクハウスアプローチとデータウェアハウスアプローチのどちらかを選択する必要はありません。Amazon Redshift は 3 つのモードで動作するからです。 Redshift には Spectrum モードがあり、アドホックなニーズに基づいて、インフラストラクチャを作成し、データをプルし、クエリを実行して結果を取得したり、他の監視モードを使用したりできます。
レイクハウスとウェアハウスのアプローチが一緒に機能する 3 つの例があります。 Iceberg と Hoodie を使用してデータウェアハウスを作成し、結果を取得しています。インフラストラクチャには複数のパイプラインがありますが、3 つの例が目立ちます。 リアルタイム分析とエンゲージメントを行っている場合、レイクハウスでクエリを実行します。非常に構造化された履歴データがある場合、ウェアハウスアプローチの方が優れています。複数のチャネルのジャーニー分析がある場合、データソースが異なり、複数の種類と構造を持っている場合、再びレイクハウスアプローチの方が優れています。
画像やビデオなどの非構造化データがある場合、もちろんレイクハウスの方が優れています。すべてが機能しますが、これらはより優れたアプローチであり、だからこそハイブリッドアプローチが常に最良のアプローチだと言うのです。既知と未知について話しました。既知は簡単です。やりたいことを知っていてパターンがあるからです。未知は、データエンジニアリングチームやマシンラーニングスペシャリストに公開されているこのデータがどのように使用でき、どのような可能性が存在するかのようなものです。
Generative AIとAgentic AIによる新しいファン体験の創造
Jake がここで何か洞察を共有します。Jake、お願いします。Sharini は、AWS を使用してデータプラットフォームを作成する方法のいくつかの例を説明し、その柔軟性を強調しました。ここで説明することは、AWS と AWS AI スイートの柔軟性を使用して、AI を活用した機能でファンのための新しい製品とエクスペリエンスを作成する方法です。 AI は、ファンをこれまで以上に喜ばせるための新しいエクスペリエンスを提供する可能性をさらに広げています。組織は、ファンをスポーツ、コンテンツ、そして彼らが本当に楽しんでいるすべてのデータにさらに近づける新しいデジタル製品を作成できます。
20代半ばから30代半ばの年代層からは、放送でのスタット統合に関する需要がより高まっており、高度なアナリティクスはこの年代層の多くのファンにとって大きな成功を収めています。これらのAI機能は放送やデジタルインターフェース、アプリケーション上のスタット統合のように見えるだけでなく、これらのAI機能はダイレクト・ツー・コンシューマーアプリ内でも実行することができます。間接的には、組織はパートナーと協力して、エンターテインメントエコシステム全体を高める新しい製品、ソリューション、ツールを作成することができます。例えばスポーツの場合、パートナーはブロードキャスターであり、ほとんどのファンがスポーツを体験する相互作用のポイントはテレビを通じたものです。
ブロードキャスターは相互作用の最初のポイントであり、何が起こっているのかを説明する役割を担っています。彼らが何が起こっているのかを説明し、AI駆動のスタットについてより良く話すのを支援するツールとソリューションを提供することで、私たちはスタット統合を強く求めるこの年代層に直接対応しているのです。Generative AIとAgentic AIを使えば、現在のデジタルアプリケーション上の機能と機能を改善し、新しい機能を作成する可能性があります。
メディア、エンターテインメント、スポーツの顧客は、新しいAgentic workflowとGenerative AIソリューションを今日提供しているソリューションとオファリングに組み込むことができます。AI駆動ソリューションが現在提供しているものにどのような新しい機能を作成できるかの例を掘り下げてみると、まずコンテンツプラットフォームを見てみます。組織と顧客は、semantic searchとビデオ理解機能を通じてAI駆動の検索機能を作成することで、ファンとデジタルコンシューマーがメディアアーカイブとコンテンツを探索する方法を作成することができます。これにより、大規模なメディアアーカイブを持つ組織にとって、古いコンテンツに新しい命を吹き込み、デジタルシェルフに置かれたまま消費されないコンテンツを活用する新しい可能性と選択肢が開かれます。
スポーツが世界中に拡大し、より国際化するにつれて、コンテンツのローカライゼーションと翻訳がこれまで以上に重要になっています。ファンが理解できる言語にコンテンツをローカライズし、翻訳することは、世界中でのチームと組織の拡大にとって最も重要です。多くのコンテンツが生成されている中で、録画やビデオオンデマンドであれ、ファンは自分たちが最も気にするコンテンツを見つけることができたいと考えています。より長い形式のビデオから自動的にハイライトを作成し、そのハイライトをクリップすることで、ファンが非常に素早くハイライトを見つけることができるショートフォーム体験が生まれます。
リーグやスポーツチームのアプリケーション、またはオンラインサイトやサブスクリプションなどのデジタル製品を見てみると、パーソナライゼーションとハイパーパーソナライゼーションについて話してきました。アプリ内でハイパーパーソナライゼーションのための機械学習手法を組み込み、より優れたレコメンデーションを促進することが、顧客が目指していることです。Chatbotやバーチャルアシスタントなどのセマンティックレイヤーは、顧客とそのファンに、これまで以上に速く情報を見つける方法を提供しています。ファンはもはやインターフェースをナビゲートするのに多くの時間を費やす必要がなく、参加したいイベントなど、探しているものについて素早く質問することができます。
ファンのためのインタラクティブな体験をどのように作成できるか、ファンがコンテンツを提供し、ほとんどのファンがテレビで視聴する体験に貢献する方法を見ていきます。これはファンエンゲージメントを高める素晴らしい方法です。ファンは生成されたデザインを提供したり、コンテストやその他の参加機能の形で貢献したいと考えています。パートナーソリューションとツールについて多く話してきました。パートナーとともにエンターテインメントエコシステムをどのように高めることができるか見ていきます。ブロードキャスターがゲーム内および試合前の分析をどのように準備できるか、高度な統計情報やその他の話題を見ていきます。これらはファンの視聴体験全体を通じてハイライトするためのものです。
AI エージェントの台頭により、組織はデータ、API、およびその他のソリューションにさらに迅速にアクセスする方法を見つけています。では、メディア、エンターテインメント、スポーツの組織と顧客はどのようにしてこれらのタイプのソリューションを作成できるでしょうか。AWS AI スタックを使用して、これを顧客が独自のソリューションを構築するためのツールキットと見ています。これはインフラストラクチャ、コンピュート、および管理されたサービスを提供する方法と見ています。これらは新しいオファリングを作成するのに役立ちます。
AWS はさまざまなチップを通じてインフラストラクチャをコンピュートに提供し、Amazon SageMaker AI を通じて独自の機械学習モデルをトレーニングする機能と柔軟性も提供しています。組織は独自の AI および ML モデルを構築、トレーニング、デプロイできます。Amazon Bedrock を見ると、顧客は Foundation Models と Amazon Nova や主要なサードパーティモデルなどの独自の大規模言語モデルにアクセスできます。Amazon Bedrock 内には Amazon Bedrock Agent Core があり、顧客は独自の AI エージェントを作成するための機能スイート全体にアクセスして、異なるソリューションと体験に組み込むことができます。新しいソリューションの作成に時間をかけたくない顧客向けには、Amazon QuickSuite などの管理されたソリューションもあります。これは顧客が情報とインサイトをより迅速に見つけ、複数のワークフローを自動化するのに役立ちます。
Amazon Bedrock Agent Coreを活用したマルチエージェントアーキテクチャの実装
AWS スタック上のこれらの AI サービスの一部を使用して、ファン体験のための agentic AI ソリューションをどのように作成できるか見ていきましょう。スポーツ内で発生するゲームに基づいてコンテンツを作成および生成するための agentic ソリューションを作成する例を説明します。ユーザーとファンは電話またはデバイス上のアプリを通じてこれらにアクセスします。Amazon Bedrock Agent Core を使用して、顧客と組織はマルチエージェントアーキテクチャを使用してこれらのソリューションを作成できます。
Agent Core runtime は、これらすべての異なるエージェントのさまざまなワークフローをオーケストレーションおよび促進するために使用されます。この例では、ゲームのデータ分析を実行するエージェント、メディアライブラリ内の画像検索を実行するエージェント、およびコンテンツを生成してすべてをまとめるエージェントがあります。Agent Core runtime は、顧客が Anthropic の Claude、LangChain、LangGraph などのあらゆるフレームワークでこれらのエージェントをデプロイおよびオーケストレーションするのに役立ちます。これらのエージェントが連携するための指示とコンテキストを提供します。
これらのエージェントは、メモリ管理、ゲートウェイ認証、ランタイム管理のためのインフラストラクチャとコンポーネントを共有しています。これらは直接呼び出すことも、エージェント間プロトコルを介して相互に通信することもできます。これらのエージェントが他のツールやデータソースをどのように使用できるかを見ると、Agent Core Gateway があります。これはエージェントが API などのツール、ファーストパーティまたはサードパーティのデータソース、あるいは独自のローカルデータウェアハウスとストレージソリューションにアクセスして、これらのエージェントが実際に利用できるツールを作成することを可能にする機能です。
ここでは、皆さんと皆さんの組織がファンエクスペリエンスに組み込み始めたいいくつかの重要なポイントがあります。全体的には、ファンエクスペリエンスを向上させることです。組織は、ハイパーパーソナライゼーション技術と AI を活用した機能を組み込むことで、エンドコンシューマーのための新しいエクスペリエンスを作成することでこれを実現できます。
ファンとコンシューマーをより良く理解し、相互作用するために、AWS サービスの最新スイートを使用して堅牢なデータプロファイルを構築し、新しい最新化されたデータプラットフォームを作成することができます。アイデンティティ解決やその他の ML 手法などの AI と ML 手法を使用して、従来のデータパイプラインとプラットフォームを強化することができます。
最後に、AWS AI stack やその他の最新化されたサービスなどの AWS スタックを活用して、視聴者とファンが楽しめるまったく新しい製品、エクスペリエンス、プラットフォームを構築することができます。
全体的に、皆さんと皆さんの組織がファンとコンシューマーを惹きつけ、興奮させるものを構築することに対して、私たちは非常に期待しています。本日はご参加いただきありがとうございました。それでは質問をお受けします。マイクは後ろにありますし、本日のスポーツフォーラムでも周辺にいますので、よろしくお願いします。
※ こちらの記事は Amazon Bedrock を利用し、元動画の情報をできる限り維持しつつ自動で作成しています。
Discussion