re:Invent 2025: プレミアリーグとブンデスリーガにおけるGenAIを活用したデータドリブンなフットボール分析事例
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
re:Invent 2025 の書き起こし記事については、こちらの Spreadsheet に情報をまとめています。合わせてご確認ください
📖 re:Invent 2025: AWS re:Invent 2025 - GenAI in the Beautiful Game: Data-Driven Success in Football (SPF302)
このビデオでは、Amazon Web ServicesのSteve Drewが、生成AIとフットボールの融合について解説しています。Premier LeagueやBundesligaのクラブにおける具体的な活用事例を紹介し、6,800のデータポイントからKPIを抽出する分析手法、Holstein KielによるAmazon Bedrockを用いた自然言語クエリシステム、Darmstadtの機械学習を活用したペナルティキック分析などが取り上げられています。手書きスカウトレポートのOCR処理、Amazon RedshiftやQuickSightを使用したデータプラットフォーム構築、さらにはAgentic AIによるマルチエージェントアプローチまで、段階的な技術進化が示されています。West Ham Unitedの10万人規模の選手データベースを活用したGenAIスカウティングプラットフォームの事例では、レポート作成時間の大幅削減と選手カバレッジの拡大が実現されています。データ基盤の重要性と人間の専門知識を補完する技術活用の在り方が強調されています。
※ こちらは既存の講演の内容を最大限維持しつつ自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますのでご留意下さい。
本編
生成AIとフットボール：データが切り拓く美しいゲームの未来
皆さん、こんにちは。お疲れ様です。私の名前は Steve Drew で、Amazon Web Services のシニアエンタープライズアーキテクトをしています。戦略的なパートナーや顧客の皆さんが AWS のテクノロジーを使ってソリューションを構築するのをサポートしています。今日は、生成 AI とフットボール、つまり美しいゲームについてお話ししたいと思います。これは私が非常に情熱を持っているテーマです。私はフットボールファンとして 40 年以上の経歴があり、データの分野でも長く働いてきました。ロンドンオリンピックのデータ API を構築しましたし、本当に嬉しいのは、生成されるデータの爆発的な増加と、それがどのように活用でき、どのような洞察が得られるかということです。
これを紹介したいと思います。Brian Clough はイングランドの最高のマネージャーの一人で、彼はこう言いました。「もし神がフットボールを雲の中でプレーしてほしかったなら、草を空に置いたはずだ」と。Brian Clough は議論の余地のない人物で、私も彼に異論を唱えるつもりはありません。私が示したいのは、AWS のサービスがフットボールのプレー方法にどのような影響を与えているかということです。今日は、スポーツデータプラットフォームについて少し、そして何が起こっているかの基礎について、そして生成 AI と AI サービスが処理できる情報についてお話ししたいと思います。
イングランド Premier League とドイツの Bundesliga のクラブからの使用事例をいくつか紹介し、その後、agentic AI への進化についても少し触れたいと思います。フットボールは世界中で最も人気のあるゲームの一つで、公園でプレーする人から 10 万人までの観客がいるスタジアム、そして World Cup の決勝戦を見ている数十億人まで、様々なレベルでプレーされています。しかし重要なポイントの一つは、単に 11 人対 11 人のゲームではないということです。
現代のフットボールクラブは非常に洗練された組織です。 プレーヤーのパフォーマンスを向上させるためにサポートしている様々な役割を持つ多くの異なる部門があります。これは、結果がピッチにいる 11 人のプレーヤーだけでは決まらないことを示しています。チームが最高レベルで競争している場合、非常に微妙なマージンが関わっており、潜在的なエッジを見つけたり、優位性を得たりすることがますます重要になっています。
基本的に、私たちがしようとしていることはより多くのゲームに勝つことです。これはルールに従ってやらなければならず、もう無制限にお金を投資することはできません。しかし、より重要なのは、フットボールの周りに関わっている膨大なコミュニティがあるため、私たちはファンに成功を祝ってもらいたいのです。私たちはクラブを持続可能な方法で成長させたいと考えており、そのコミュニティの構築はその大きな要素です。
では、フットボールクラブによるテクノロジーの活用について考えると、これをどのようにメインコンポーネントに分解するかということですね。まず、解決したいユースケース、つまり何の問題を解決しようとしているのか、どこで優位性を得たいのかがあります。これは、従来の analytics と AI、machine learning、generative AI テクノロジーの組み合わせによってサポートされており、それが最終的には insights を得たり、価値を得たり、より良い競争優位性を得ることにつながるはずです。
フットボールクラブにおけるデータプラットフォームの構築：ユースケースから生成AI活用まで
これは、プロフットボールクラブがテクノロジーを活用している use cases の一部のサンプルに過ぎないと思います。トレーニングスケジュールがどのようなものであるべきかといった preparation 要素に関するものであれ、特定のチームやピッチにいるプレイヤーのグループがどのようにパフォーマンスしており、どのようなトレンドを示しているかといった performance analysis の観点からのものであれ、です。そして、もう一つの大きなグループは scouting に関するもので、自分たちのプレイヤーを育成することと、より多くの成功をもたらすために連れてくる可能性のある将来のターゲットを特定することの両方です。
このスライドを以前見たことがある人も多いと思いますが、data が基盤となります。これにより、AI と generative AI サービスを使用して insight を導き出し、優位性を得ようとすることができます。これをフットボールのコンテキストで考えると、外部のデータソースと自分たちのチームの内部データソースの両方があります。
ビデオは増加する頻度で記録され、ゲームの特定の部分のハイライトをキャプチャしています。coach reports や scouting reports に関するテキストデータが入ってきます。膨大な量の tabular data が流れてきています。プレイヤーが passing KPIs でどのようにパフォーマンスしたかに関する数千のデータポイントとデータフィールドを考えると、GPS tracking があります。データの量は増え続けており、数千、数万のデータフィールドと数百万のデータポイントがあります。
以前と同様に、generative AI を使用して use cases に関する質問に答え始めることができます。結局のところ、私たちはまだアプリケーションを構築しているので、LLM を呼び出す以外のユーザーエクスペリエンスのためにデータベースが必要です。私たちは、data ingestion を含む相当に標準的な data pipeline architecture を持っており、batch または real-time で structured および unstructured data を取り込んでいます。これらを処理し、変換し、いくつかの初期 insight を得るためのパイプラインを設定しています。data governance 要素に関する考慮事項があります。プレイヤーの医療履歴や他の機密情報が含まれる可能性がある、そのデータのプライバシーとセキュリティを確保する必要があります。PII data と private data がそこに含まれています。
まず一般的なレベルに進む前に、私たちはまだ従来のデータ処理を行う必要があります。クラブで取り組んできたデータ、AI、ML、そして生成AIの組み合わせから、AIとMLはまだそこにあり、本当に常に存在していて、実は3つの部分から来ています。1つは、私たちを通じて来ている膨大な量のデータの統計分析に関するものです。私たちはトレンドとパターン検出、そして特徴識別を見ています。私たちが持っているこのデータの大量の中で、重要なデータフィールドになるものが何かを見ようとしています。AIとMLの大きな使用量をまだ見ています。これはデータの別のレイヤーの処理として機能し、その後、生成AIのトピックで使用できます。
これは詳細に入る前のちょっとした要約ですが、クラブで生成AIの使用を見ている場所は、データ抽出部分とインテリジェント文書処理の周りにあります。スカウティングレポートと手書きレポートをどのように処理するかを見ています。その非構造化データから出てくる可能性のある特定のデータ属性を抽出しています。私たちはこれをインサイトの観点から見ています。今、私たちのデータレイクがデータで満たされているので、そこの他の部分からレポートと情報をどのように集約できるかを見ています。私たちは最後の部分に移動します。これはデータの民主化に関するもので、スカウト、コーチ、そして他のペルソナがこのデータを簡単にクエリできるように、データプールを簡単に見られるようにする方法を考えています。
Bundesligaクラブの実践例：6,800のデータポイントから選手パフォーマンスを可視化
かなり一般的なユースケースで、かなりの数のクラブで見ているのは、チームまたは選手のパフォーマンスをどのように分析するかを見ています。これは存在する数千のデータフィールドを取り、競争上の優位性を得ることができる場所を見つけようとしています。その一般的なアプローチは本当にそのデータプラットフォーム、いくつかの分析、ビジュアライゼーション、そしておそらく生成AIの小さな要素から始まります。私たちはここに持ってきています。ですから、この例から、ドイツの Bundesliga のクラブの1つです。
ドイツの Bundesliga は素晴らしい例を提供しています。彼らは、特定の選手のために分析および処理できる主要業績評価指標のグループを構築したいと考えていました。これは私たちのデータパイプラインの一部になりました。私たちは6,800の異なるデータポイントから始めて、ポゼッションKPI、タックリングKPI、または他のカテゴリーであるかどうかにかかわらず、データ機能のグループを抽出します。KPIの各グループは、多数の個別のKPIで構成できます。私たちはデータの準備と前処理の段階でそれを処理します。それを完了したら、ユーザーがクエリを入力したり、ダッシュボードを構築したりすると、単一の選手、複数の選手、またはシーズン全体の選手比較のための長期的なデータ処理を行うことができます。これはビジュアライゼーションの基礎になります。
私たちがクラブの開発をサポートしてきた多くのアーキテクチャがあります。ここでより単純なものの1つを選んでみましたが、コンポーネントは本当に同じです。右上に多くのサードパーティデータAPIがあります。そのデータを取り込み、ETLを行い、Amazon Redshift を例として、好みのデータストアに保存するプロセスがあります。その後、カスタムビルトのUIまたは Amazon QuickSight のようなもので、それを前面に出して、通過するデータの簡単なビジュアライゼーションを提供します。
このクラブの例を見てみると、非常にシンプルなダッシュボードなんですが、ここで私はプレイヤーをこれらの KPI グループに対してクエリして比較し、この 2 人のプレイヤーがどのように比較されるかを見ることができます。では、物事がどのように進化しているかについて説明していきます。
Holstein Kielのデジタルトランスフォーメーション：推論モデルとData Value Generate Flywheel
私たちは、ドイツの Bundesliga にある Holschenkiel と協力してきました。ここで強調したい重要なメッセージは、データが短時間で重要な客観的情報を生成するのに役立つということです。フットボールクラブは膨大な量のデータを生成していますが、それを競争上の優位性に変えるのに苦労することが多いです。Holschenkiel が最初に取った方法は、データアーキテクチャの観点から考えることでした。データソースは孤立して見るべきではなく、多くのリンクされたデータタイプがあるため、彼らは所有するすべてのプレイヤーに対してプライマリ ID を作成することから始めました。これにより、プレイヤーがフィールドとトレーニングの両方でどのようにパフォーマンスしているか、そして異なるクラブを通じてどのように進歩しているかの長期的な進行状況を追跡することができました。
彼らは、チームマネジメント、ワークロード管理、またはスカウティングであるかどうかにかかわらず、見ていきたい 6 つの重要な領域を特定していました。これらは、彼らが洞察を得るために価値があると判断したフットボールドメインになりました。そのデータモデルから、私たちはインテリジェントなプレイヤー分析に焦点を当てたデータ処理環境をセットアップしました。スケーラビリティと安全なデータ基盤を中心に、5 つの重要な技術原則が導入されました。また、モジュラーアーキテクチャとして構築することで、将来的に拡張できるようにしました。重要な部分としては、イベント駆動型のアプローチと、論理的に分離されたビューの両方から考えることでした。
なぜこれが重要だったのでしょうか？それは、将来必要とされる技術開発またはメンテナンスを削減するからです。結局のところ、Holschenkiel のようなクラブの焦点はフットボールにあります。彼らはテクノロジープロバイダーではなく、それは彼らのコアビジネスではないからです。この例は、特定のプレイヤーについて、彼らの攻撃パフォーマンスが過去の期間にどのように変わったかを示そうとしています。
このデータプラットフォームから構築して、 Hosecure は Bedrock または OpenAI on Bedrock をどのように使用して、さらなる競争上の優位性を得ることができるかを検討してきました。これらの前向きなテクノロジーを見ようとしています。あなたが以前に見たかもしれない 3 つの領域は、OpenAI のような推論モデルを使用して、自然言語を通じて質問をし、LLM に利用可能なすべてのデータポイントを考慮させようとしています。これは、かなり静的なダッシュボードから移行しようとしています。
最初の部分から、既存のデータプラットフォームに自然言語検索をどのように組み込むことができるかを可視化しようとしているんだと思います。私たちは、これが比較的簡単に始められる部分であるというケースをいくつか見てきました。ですから、最初のアプリケーションポイントでは、ユーザーが「Harry Kane の得点率がここ6ヶ月でどのように変わったか」というような自然言語クエリを質問することができます。このクエリは AWS Amplify 上で動作するカスタム AI を通じて取り込まれます。その後、ユーザーのクエリは Amazon Bedrock Knowledge Base に渡されます。ここでは、データ検索とデータ処理の両方を行うことができます。
Knowledge Base はユーザーのリクエストを SQL クエリに変換し、それを既存のクエリエンジンである Redshift に送ることで、データを抽出することができます。私たちのデータを Redshift のフィールドレベルでラベル付けするか、AWS Glue テーブルを使用してそれを充実させるかのいくつかの場所があります。データが処理され、SQL クエリが実行されると、データが返されてきて、それを LLM で処理してユーザーに返すことができます。これにより、対話的に進めることができ、さらなる質問について考え、分析を洗練させることができます。
このことについて、より複雑なリファレンスアーキテクチャもいくつかあります。一般的なアプローチとしては、ここに RAG タイプのデータストアを追加することになります。そうすることで、データアナリストが定義した事前に入力されたクエリや事前に使用されたクエリを持つことができます。しかし、本当のところは、私たちのデータをどのように民主化し、コーチなどの非技術系スタッフが持っているものをどのようにより良い使用方法に導くことができるかという使用ケースに帰着します。
OpenAI または Bedrock の選択に関して、Hodgson Kiel が考慮した4つの考慮事項の1つは、提供される推論能力を探していたということだと思います。ですから、「ストライカーのゴール貢献度が40%低下したのはなぜか」というような質問の場合、システムプロンプティングなしで LLM から返ってくる可能性のある結果の多くは、非常に1ステップの答えです。複数のタスクに分解でき、マルチステップの計画に進むことができる推論 LLM を使用することで、私たちが収集した複数のデータソースを調べて調査することができます。
計画を反復処理する際に矛盾した情報が見つかった場合、LLM はその将来の計画を修正して、SQL クエリを通じたツールの使用や、コードの実行などのツールを使用して、より正確な答えを提供することができます。推論モデルの使用を計画している場合、ここに検証ステップを含めることが非常に重要になると思います。
このバリデーションステップは、データを使ってトレーニング方法をどのように変えていくかを計画している場合に特に重要になります。 Hush と Kiel が経験した例の一つは、彼らのデジタルトランスフォーメーションに関わるものでした。彼らは自分たちのコンパスが何であるべきか、つまり North Star と呼ぶかもしれないものを見つけ出そうとしていました。単に新しいテクノロジーを導入するのではなく、異なるチームや部門が将来どのように一緒に働くのかといった重要な質問に答えようとすることが大切です。最も重要なのは、私たちが持っている人間の知識をどのように豊かにできるかということです。数十年の経験を持つスタッフメンバーがいますが、問題は彼らのスキルを最新のテクノロジーでどのように充実させることができるかということです。そして、新しいアプローチの成功をどのように測定するのかということです。
彼らは Data Value Generate Flywheel と呼ぶものを組み立てました。ここでの高レベルの考え方は、彼らが保存して利用可能なデータを見ることから始めて、潜在的なユースケースが何であるかを考え抜くというものです。その点に戻ると、ユースケースから作業することが重要です。彼らが組み立てた技術インフラストラクチャを使って、次のステップはユースケースを取り、素早く概念実証を作成し、それを反復して、実際に彼らがやろうとしていることから価値が出ているかどうかを確認することです。その後、そのユースケースが成功した場合、完全な機能ソリューションに進めます。
ポジティブな結果が得られた場合、その後はより広く使い始めることができ、より多くの人の時間をそれに費やしたり、より多くの財政的インセンティブを与えたりすることができます。しかし、それは彼らが組み立てた全体的なデータプラットフォームと AI プラットフォームの価値に貢献し戻ってきます。なぜなら、新しい機能が追加されるたびに反復するごとに、より良い全体的なインサイトが得られるからです。 もう一つ重要な引用を取り上げたいのは、オペレーショナルの改善と人間の専門知識をより具体的にデプロイすることについてです。これが重要な部分です。なぜなら、私たちが使用または組み立てているすべてのテクノロジーは、クラブのスタッフを増強するためのものだからです。
Darmstadtの機械学習活用：ペナルティキック成功率向上への挑戦
別のクラブに移りますが、このクラブは generative AI よりも機械学習にもう少し焦点を当てているかもしれません。イングランドのファンとして、ペナルティのトピックを持ち出すのはいつも辛いのですが、Bundesliga では Darmstadt は非常にデータドリブンなフットボールクラブです。彼らは自分たちが今後行うすべての決定にデータを組み込もうとしています。彼らのデータサイエンティストの一人と話していた時、彼らがこれらのテクノロジーをどこで使用しているかの例を引き出しました。フットボールゲームでのペナルティのようなものは非常に頻繁には起こりません。彼らはかなり良いコンバージョンレート、78 から 79 パーセントを持っています。そこで彼らは、ここで小さなアドバンテージを得ることができるかどうかを見るために実験を行いました。これは潜在的にピッチ上で何か非常に大きなもの、つまりゴールイベントを変更します。
外部データプロバイダーがいるところで、ペナルティキックの観点から、コーチがビデオを手動で見ていくことができます。サードパーティのフィードが利用可能なので、各プレイヤーがボールをどの座標に置いて、どのようにレイアップにアプローチするかを見ることができます。私たちはそれをデータストレージシステムに保存しています。Fabian の見方は、フォーカスは本当にインフラストラクチャを実行して設定しようとするのではなく、エッジを得ようとすることです。そこで彼が選んだのは Amazon SageMaker Studio Lab を使用して簡単に環境をセットアップし、その後 Amazon SageMaker を使用してモデルをトレーニングすることでした。
スケールが役に立つ一つのことは、このようなスケール・ツー・ゼロのアプローチで、実行コストが比較的低いというものです。彼らがモデルを構築していく中で、テストはまだ進行中で、今のところ共有する意思はないということですが、このテクノロジーの使用方法は、ゴールキーピングコーチとゴールキーパーによって使用され、そのリストを持つというアイデアでした。ご存知のように、そのリストはまだゴールの後ろに置かれた水のボトルに貼り付いているのですが、彼らは分析を行って、実際のところ、相手のストライカーからすると、彼はどこに行く可能性が高いのかを見てきました。これを使って、実用的に考えようとしているんです。最も複雑なアーキテクチャを提供する必要はなく、質問に答えたり、洞察を得たりするために使用する必要もありません。
ここの上部にある私のお気に入りの引用の一つは、「感情がフットボールを動かすが、データが進歩を推進する」というものです。これはクラブが言っていることとして本当に強力だと思います。そして、これが Darmstadt がデータをあらゆるステップで使用している場所です。以前、あなたは多くの統計とデータ分析がそのような部分から来ていることについて話してきました。しかし、洞察を得たい他のデータセットがあります。私たちが持っているタビュラーデータを拡張したいのです。
インテリジェント文書処理からAgentic AIへ：手書きレポートの自動化と自律的データ分析
フットボールクラブ内では、ご存知のように、多くのコーチ、スカウト、その他の部分が関わっています。まだ手書きされているレポートの一部、手書きのもの、タブレットなどの他の方法のもの、そしてこのデータをどのように取り込んで、既存のタビュラーデータと一緒にクエリできるようにするかを見ていきたいのです。繰り返しになりますが、以前のデータプラットフォームから、インジェスション、トランスフォーメーション、ここにはいくつかの処理も含まれています。
ここで取られたアプローチは、手書きレポートの写真をポータルにアップロードしてから、インジェストして S3 に保存することでした。その後、Step Functions を通じてそれを取り込んで、処理を開始します。実験とある程度の比較を通じて、LLM の使用が OCR とインテリジェントドキュメント処理の両方を行うために導入され、その後、その情報から主要な洞察と主要なエンティティを抽出します。そのプロセスの一部として、プレイヤー名やその他の部分など、既知の固定変数のようなものに対して検証を行います。その情報は、その後、作成されていた既存のダッシュボードと一緒に視覚化できるように、データストアに書き込まれました。
ドキュメントインジェスションとドキュメント処理がありました。利用可能なデータのタイプを構築して増やし始めると、アプリケーションの次のイテレーションを見始めます。複数の多様なデータタイプとデータストア全体でどのように検索を開始できるでしょうか。データを特定の場所に保存することは、常にパフォーマンスのために正しいタイプのデータに最適なデータストアを選択しようとしているためです。次のイテレーションは、QuickSight をダッシュボードに使用するのではなく、Amplify に書き込まれてホストされているカスタムアプリがあります。その後、ユーザーから来るクエリを取得するために Bedrock Agents をどのように使用できるかを見ています。例えば、Harry Kane の過去 6 ヶ月間のコンバージョンレートはどのくらいですか？
それでは、私たちのエージェントが構造化データストアまたは非構造化データストアに接続して、関連情報を抽出し、それを組み合わせて、ユーザーに提示し直します。 その後、まだ実験段階にあるトピックに移ります。少なくとも私が見ている限りでは、完全な本番環境への展開にはなっていません。Agentic AI はこの分野でホットなトピックです。私たちは 3 つの重要なインプット、つまり以前に行われたことの記憶、利用可能なツール、そしてユーザーが達成しようとしている目標を活用して、データをクエリするアクション、観察を行い、反復処理を行おうとしています。
その単一エージェントアプローチがどのように機能するかを説明したいと思います。議論されたタスクの 1 つに戻ってきます。では、タスクは何になるのでしょうか？マッチ分析を見ています。前のゲームを見て、今日のプレッシングプレーがどのように機能したかを考えたいと思います。その後、そのリクエストをエージェントに渡します。エージェントはユーザーのクエリに基づいて計画の観点からそれを見ます。このタスクを何に分解する必要があるのか？これには、ユーザーの質問の評価、レスポンスの評価、データの分析が含まれます。計画ステップは必要に応じて修正および反復できます。
その後、ツールまたはアクションを呼び出します。これには通常、データストアをクエリして過去の攻撃パフォーマンスがどのようなものかを確認することが含まれます。プレイヤーレベルの分析またはチームレベルの分析が必要です。エージェントはその後、計画を反復処理し、ポイントをチェックオフし、おそらく新しいポイントを追加します。ここでの考え方は、より柔軟で自律的なアプローチを持つようになるということです。新しいツールと情報が発見されるにつれて、固定コーディングまたは固定プロンプトから離れていきます。アーキテクチャの観点から、多くの人々が現在 AgentCore についてエージェントをホストするために話しています。
左側で AgentCore Runtime 内にホストされているユーザーフロントエンドから、エージェントをデプロイしたいと考えています。その中には、エージェントに実行させたいことの指示があります。フットボールデータ分析の観点からそれを考えると、どのようなものであるべきかについてのルールとガイダンスがあります。プレイヤーレポート、チーム分析、またはプレイヤースタッツなど、利用可能だった過去のレポートのいくつかを構築して、エージェントのローカルツールとして利用可能にすることができます。これらは、異なるデータストアに情報を提供し、クエリできるアクションです。
反復処理を進めるにつれて、Amazon Bedrock と選択した大規模言語モデルへの呼び出しを行うことができます。何をするべきかを理解し、情報を処理し、ユーザーが促したゴールに向かって進みたいと考えています。 これを議論された 6 つのドメインに戻したいと思います。システムが進化し、より多くのインサイトを生成したい、または情報への可視性をさらに高めたいと考えるにつれて、マルチエージェントアプローチから、特定の領域に焦点を当てた、より専門化されたエージェントを考えることでアプローチできます。
これにより、モジュール化されたエージェントが登場します。例えば、マッチ分析に特化したものもあります。このアプローチにより、ワークフローの観点から、エージェントと機能を素早く追加または削除できる柔軟性が得られます。フロントに orchestrating agent を配置して、ユーザーのリクエストを満たすために適切なツールやエージェントを選択できるようにしています。
時には単一のエージェントだけを呼び出す必要があります。例えば、プレイヤーのパフォーマンスを確認する場合などです。しかし、4つか5つのドメインに対してリクエストを行い、結果を集約して包括的な回答を返す必要があるクエリもあります。これにより必要な柔軟性が得られます。以前のような厳密に定義されたルールではなく、今は膨大な量のデータと膨大な量のツールを提示し、実行されるアクションは LLM によってユーザーのリクエストに基づいて、または新しい情報が発見されるにつれて自動的にカスタマイズまたは計画されます。
例えば、medical insights から injury history について何かが返ってきて、Harry Kane のコンバージョン率が8週間前に左足を負傷したために低下したことがわかった場合、それはさらなる分析を変更し、エンドユーザーに提示されるレポートを変更する可能性があります。複数のエージェントをデプロイし始めても、それほど複雑にはなりません。個々のエージェントをデプロイするために AgentCore Runtime を使用し続けています。見られるパターンは、共通のツーリングと共通の機能を、AgentCore Gateway 経由で MCP server として公開することです。
考え方としては、共通の関数と共通のレポートを AgentCore Gateway でホストして、そこで実行されているすべてのエージェントに公開できるということです。これにより、既存の API エンドポイントまたは既存の Lambda 関数を取得し、AgentCore Gateway とインターフェースして、実行されているいずれかのエージェントで使用できるようにします。データ、AI、機械学習、生成 AI についても説明してきました。ここからは agentic AI についてですが、すべてが agentic AI である必要はありません。ユースケースに基づいて何が理にかなっているかを本当に考える必要があります。
ドキュメントからの情報抽出やレポートの要約、レポートの相関関係と要約に生成 AI を使用できる組み合わせを使用することができます。スポーツデータのトレンドを見ている予測 AI と組み合わせることができます。その後、計画を検討する場合は agentic AI の使用を検討するかもしれませんが、最も重要なのは発見したことに基づいてアクションを取ることです。ワークロードの一部のコンポーネントは、従来のコードとして実行するだけで理にかなっているものが常にあります。それについて問題はありません。
AWS GenAI Innovation CentreとAPNパートナーによる実装支援
ユースケースの観点から見ると、皆さんのジャーニーをサポートするために、私が強調したい2つのガイダンスとチームがあります。1つ目は AWS GenAI Innovation Centre で構築できるというもので、2つ目は APN AI Competency Partner と一緒に構築するというものです。どちらのグループも、今日お話しした全てのテクノロジーに関して豊富な経験を持っており、プロジェクトをより早く実現するのをお手伝いできます。また、パートナーネットワークの中には、特定の業界に深い専門知識を持つパートナーもいますので、そういったパートナーについても何社かご紹介したいと思います。
West Ham Unitedのスカウティング革命：生成AIで実現する10万人規模の選手評価プラットフォーム
では、本日最後のユースケースについてご説明します。プレミアリーグの West Ham United は、Academy of Football として知られる長年の才能育成の伝統を持っており、才能の発掘、育成、そして人材育成に関して強い背景を持っています。West Ham の技術採用チームは、エンドツーエンドの GenAI スカウティングプラットフォームの構築を検討しています。彼らはプレミアリーグの中で初めて GenAI をエンドツーエンドで活用しようとしているクラブです。West Ham は AWS と APN パートナーの Crayon と提携して、彼らの特定のユースケースに最適なテクノロジーを活用していることを確認しています。
GenAI を使用したエンドツーエンドプラットフォームというのは、プレミアリーグのクラブのスカウティングプロセスがどのように見えるかについてご説明します。まず、180カ国にわたって、プロとしてフットボールをしている、または youth teams を通じて活躍している利用可能な選手の世界規模のデータベースである100,000人の選手から始まります。初期のデータ分析を使用して、統計情報、新聞記事、その他のデータソースに基づいて、これらの候補者の一部をショートリストアップしようとします。これにより、さらに詳しく調査する必要がある選手の最初のウォッチリストに絞り込まれます。
そのウォッチリストから、スカウトは動画を見て、選手のパフォーマンス、トレンド、その他の要素についてさらに詳しく分析します。スカウトはその後、その選手に関するテキストと視覚的なレポートを作成します。これはかなり時間がかかる可能性があります。このショートリストに基づいて、レポートが作成され、さらに優先度リストが特定されます。しかし、スカウトはその後、統計情報とビデオクリップではすべてを捉えることができないため、実際にこれらの選手を見に出かけます。選手がスカウトされた後、通常20～30ページの非常に長いレポートが作成されます。クラブが進めるべきか、もっと時間をかけるべきか、あるいはこの選手にお金を使うべきかを検討し始めるときです。
こうした統計やデータ分析を通じて進められていますが、レポート作成には人間的な要素が大きく関わっています。ここが generative LLM と AI が非常に強力になる部分で、レポートをより速く作成するのを支援し、また同時にレポートを要約するのにも役立ちます。例えば、優先順位をつける必要のある選手が30人いたり、100人いたりする場合、これらのツールを使って最も関連性の高い情報を引き出すことができます。レポートを書く時間、レポートを分析する時間、そしてデータを集める時間を大幅に削減することができます。
これが West Ham が generative AI の使用で目指しているところです。つまり、この技術を使ってスカウトと選手獲得を支援することです。 目標は既存のスカウティング方法を補完し、このプロセスを高速化し、評価できる選手の数全体についてより良い可視性を得ることです。適切なテクノロジーを使用することで、選手カバレッジの範囲をより広げることができます。
ここが generative AI を使用できる場所であり、クラブが使用している場所だと思います。生産性の向上、スケールの拡大、そしてさらなる詳細とインサイトをもたらすためです。 West Ham のタレント識別プラットフォームの現状をまとめると、彼らが目指しているところをカバーしてきました。つまり、利用可能なスカウトとコーチの時間と労力を削減し、利用可能な分析のレベルを高め、選手カバレッジを拡大することです。
私たちの環境に入る考慮事項とデータ入力には、人間が作成したスカウトレポート、マッチレポート、そして評価が含まれます。私たちは他のモードのデータの組み合わせを持っています。イベントレベルのデータ、トラッキングデータ、そして物理的なデータです。さらなる決定を支援するために考慮したい大量の情報があります。 generative AI コンポーネントはここで、異なるモードと異なるタイプのデータを処理するために機能します。 それは推論能力を提供し、新しいデータ、新しい変数、そして新しいインサイトが抽出されるときに何が求められているのかを考え抜くのに役立ち、レポートのカバレッジとレポートの詳細レベルを増やすのに役立ちます。
この最後の部分に来ると、既存の実践を補強するための証拠に基づいた決定があります。 テクノロジーはツールとしてそこにあり、より多くの詳細、より高いレベルの分析、または他の場所でより良く使用できる時間を節約するために提供されます。私たちは自動化された due diligence レポートの作成に到達しており、それはスカウティングまたは transfer コンテキストで使用できます。
このことについて強調したいのは、私たちのクラブに適切な選手を見つけるために、多くの側面が関わっているということです。技術的な側面もあれば、財務的な側面もあり、人間的な側面もあります。重要なのは、データと生成AIサービスを活用できる場面では、作成されるレポートの質を向上させることで、より良いデータドリブンな意思決定ができるようになるということです。大規模言語モデルと同じように、私の要約は毎回少し異なるかもしれませんが、4つのポイントを挙げたいと思います。多くのクラブで見てきたのは、堅牢なデータ基盤が本当に重要だということです。適切なタイプのデータを適切なテクノロジーで保存し、それを単一のインターフェースに流し込んで、私たちのニーズに応じてクエリできるようにする必要があります。
クラブによるGenAIの使用は、ユーザーの経験を置き換えるのではなく、向上させるためのものです。フットボールにはゲームがあり、その中には依然として人間的な要素が大きくあります。数十年の経験は、補完的な知識のセットとして機能します。
より多くの多様なタイプのデータを収集することで、分析を行う際や目指す場所を決める際に、より良いターゲット化された意思決定ができます。重要なポイントの1つは、データフィールドの数が増え始めて大きくなるにつれて、LLMの使用は、どのデータを見るべきか、または考慮すべき正しいデータが何かを特定するのに役立つということです。エージェントの使用でこれを見ると、データを処理し、使用する正しい情報を絞り込む際に、新しいデータを発見した場合や、正しく見えない、またはさらなる調査が必要な回答を得た場合に、是正措置を取ることができます。
本日は以上です。ご質問やお話しになりたいトピックがあれば、お気軽に側まで来ていただくか、今ご質問ください。どのような方法でも構いません。ありがとうございました。本当に興味深いお話ですね。自分の声が返ってくるのを聞くのは本当に変な感じです。レフェリーに関して何か見かけたことはありますか？
特に見かけたことはありません。FAレベルというより、クラブとの関係が中心でした。あなたの関心分野としては、イエローカードが出る場所の過去のパフォーマンス閾値を分析することかもしれません。ええ、プレーが前に進むにつれて、彼らはみんな耳にモニターを持っていて、リアルタイムデータが耳に入ってきています。選手がボックスに入る際に90%のダイビング確率があるようなもの、またはそのリアルタイムデータが流れ込むようなものかどうかはわかりませんが、それが彼らを助けるのか、何か役に立つのかはわかりません。
リアルタイム分析ソリューションは実際に存在していますが、今日は公開できないものもあります。ただ、そのリアルタイムデータを調整するという考え方から、データソースについて説明していた時のように、一部は過去を遡るデータで、一部はリアルタイムスクリーニングベースのデータです。GPS データが入ってくるので、選手を分析することができます。例えば Harry Kane をまた取り上げてしまいますが、適切なコンタクトがなかった場合に彼がダウンする確率は 60% で、その情報をフィードバックします。レイテンシーの観点からすると、構築して組み合わせることができるサービスが存在します。なぜなら、サブセコンドではなく、数秒以内の処理について話しているからです。イベントをキャプチャしてから、それを既存の統計と相関させるために利用可能にするまでを想像してみてください。
これはスポーツ放送局の例として、非常に興味深い付加価値になる可能性があります。ですが、はい、興味深い質問ですね。その点についてはもう少し考えてみます。ウェアラブルについてはどう見ていますか？多くのチームが Catapult や Whoop などを使用しています。今日の市場でクラブがウェアラブルに関連するデータを要求したり、求めたりし始めているのを見かけていますか？
はい、今日言及した 2 つのクラブから、ピッチ上のトラッキング位置の観点からのウェアラブルデータが取り込まれ、摂取され、走行距離などのメトリクスのパフォーマンス統計などの分析に使用されています。
彼らが調べたユースケースの 1 つは、ゲーム中にクラブのディフェンスがどのようにリンクしていたかを見て、選手がポジションから外れていないかを確認することでした。その分析は、個々の関節の動きのデータというより、GPS と選手トラッキングデータからより多く来ています。ただし、構築されたデータレイクに含まれています。この時点では、生成 AI というより AI/ML タイプの分析からより多く出てきていますが、検討されているものです。
AI とフットボールについて戻りたいのですが、リアルタイムに向かっていく中で、イベント時の決定に使用されるのではなく、より先を見据えたものになるか、以前のレビューのためになります。これはコーチとアシスタントコーチとの直接的なコミュニケーションを伴います。ビデオモニターが利用可能なフットボールグラウンドでは、スカウトが手書きのメモを出す代わりに、あなたが見ているものを示すリアルタイム分析があり、それはあなたが採用している戦術を変える可能性があります。
このようなものに対する需要はあると思いますが、現在のところ準備段階に多くの焦点が当たっています。クラブは映像セッション中に過去のデータを使用して次の試合に向けて異なるセットアップをしたり、スカウティングの履歴データに基づいてプレイヤーのスケジュールを変更したりしています。他の業界で見られているように、より リアルタイムの情報へと移行していくでしょう。一部のクラブはトレーニング中にこれを実施しており、まだ話していないクラブの中にはライブで実施しているところもあるかもしれません。
コーチたちはそれに対してオープンですか？ほとんどのコーチは、いわゆるレガシー世代に属しています。人間的な要素がまだ非常に大きく関わっています。50年以上ゲームに携わっているマネージャーの中には、それに対してあまり前向きでない人もいるかもしれません。しかし、データフライホイールの概念を見てみると、このプロセスが優位性をもたらすことを投資対効果で示し、証明できれば、より多くの受け入れが得られるという考え方です。マネージャーは依然として非常に強い意見を持つ可能性が高いですが、より開放的になる可能性があります。
ありがとうございました。皆さん、ありがとうございます。さらにご質問がある場合は、後ほど私たちのところにお越しください。West Ham や Bundesliga のいくつかのクラブと協力してきた Crayon のチームメンバーが何人かここにいます。Reinvent の残りの時間をお楽しみください。
※ こちらの記事は Amazon Bedrock を利用し、元動画の情報をできる限り維持しつつ自動で作成しています。
Discussion