※本記事は、AWSチャンネルにて公開されている「How Arccos Golf is using AWS and generative AI to transform the game (SPT211)」の内容を基に作成されています。動画の詳細情報はhttps://www.youtube.com/watch?v=qt7SwZy434I でご覧いただけます。本記事では、プレゼンテーションの内容を要約・構造化しております。

なお、本記事の内容は原著作者の見解を正確に反映するよう努めていますが、要約や解釈による誤りがある可能性もありますので、正確な情報や文脈については、オリジナルの動画をご視聴いただくことをお勧めいたします。

本プレゼンテーションはAWS re:Invent 2024のライトニングトークとして行われ、Arccos GolfのVP of Software EngineeringであるRyan Johnson氏によって発表されました。AWSは、エンタープライズアプリケーション、ビッグデータプロジェクト、ソーシャルゲーム、モバイルアプリなど、あらゆるものをクラウドで実行できるインフラストラクチャとアプリケーションサービスを提供しています。

より詳しい情報については、AWSの公式サイト（https://go.aws/more ）をご参照ください。

1. はじめに

1.1 Arccos Golfの概要

Ryan Johnson：私はRyan Johnsonと申します。Arccos GolfのVP of Software Engineeringを務めております。本日は、ゴルフアナリティクスの分野でジェネレーティブAIをどのように活用し、ゴルフをより身近なスポーツにし、プレイヤーの上達を支援しているかについてお話しさせていただきます。

Arccos Golfは、ゴルフのトラッキングアプリを提供しています。我々のサービスは、お客様がクラブにセンサーを取り付け、スマートフォンとペアリングすることで機能します。プレーヤーがゴルフラウンドをプレーする際、我々のシステムはコース上でのすべてのパフォーマンス、ショット、そして関連するメタデータを追跡します。このデータを基に、プレーヤーの優れている点と改善が必要な点を分析し、フィードバックを提供しています。

我々は7-9年間このサービスを提供してきており、10億ショット以上のデータを蓄積しています。これは少なくともアマチュアゴルフのデータとしては最大規模のものです。このデータを活用した分析により、実際のパフォーマンス改善に結びついています。具体的には、我々のサービスを利用する顧客は、初年度で平均5ストロークのスコア改善を達成しています。

ゴルファーの皆様はご存知の通り、これは非常に大きな改善です。ハイハンディキャップのゴルファーであれば5ストローク程度の改善は可能ですが、ローハンディキャップのゴルファーでも、その技術レベルに応じた大きな割合での改善を実現しています。このように、我々のデータ分析は実際のゲーム改善に貢献しており、今後はジェネレーティブAIによってさらなる変革が可能になると考えています。

1.2 発表の主要テーマと目的

本日の発表では、私たちのデータエンジニアやアナリストとしての役割の本質から説明させていただきます。私たちの仕事は、保有するデータを活用して実際のインパクトを生み出し、変化を促すことです。

Arccos Golfにおいて、それはゴルファーの上達支援を意味します。ビジネスによって目的は異なり、よりよいビジネス判断を導くことかもしれませんし、製品の改善かもしれません。しかし、もしデータを単にS3に保存し、分析を行っても、誰もそれを理解できなければ意味がありません。そこで、私たちは原点に立ち返り、いかにインパクトと変化を生み出すかを考える必要があります。

本日は以下の内容についてご説明させていただきます。まず、アナリティクスの一般的な課題について、特にゴルフやスポーツアナリティクスの文脈でお話しします。次に、Amazon Bedrockを活用してユーザーの理解を助けるために開発した製品についてご紹介します。そして、その過程で得られた教訓について、皆様のビジネスにも適用可能な形でお伝えします。最後に、私が特に期待している分野として、データ収集、データ分析、そしてデータに基づくアドバイスという一連のサイクルにおいて、LLMをどのように活用できるかについてお話しします。これはLLMの活用において、まだ十分に注目されていない領域だと考えています。

特に本日は、このように技術的な観点からお話をさせていただきますが、これらの教訓は、ゴルフに限らず、スポーツ全般、そしてビジネス全般にも応用可能なものです。なぜなら、データを持っているだけでは不十分で、そこから実際のインパクトを生み出すというチャレンジは、どの分野でも共通だからです。

2. ゴルフアナリティクスの課題

2.1 数学的分析に対するユーザーの抵抗感

私の母がよく言っていたように、「人は4文字の言葉のようなもの」です。このケースでは、その4文字の言葉とは「数学」です。人々は数学を好みません。これは、我々のHead of Data Analyticsであるルー・スタグナーへのツイートに如実に表れています。

「あなたは数学だけが重要だと考えているようですね。でも数学はしばしば間違っているし、ゴルフボールは計算機で打つわけじゃない。」

このツイートは、数学に対する人々の嫌悪感を完璧に表現しています。確かに、実際のゴルフボールを打つのに計算機を使うわけではありませんが、数学は信じられないほど有用なツールです。

これは、ゴルフアナリティクスに限らず、ビジネスアナリティクスであっても直面する全般的な課題です。人々はアナリティクスと数字に対して本能的な抵抗感を持っています。この抵抗感は、データを活用してゴルファーの上達を支援しようとする我々にとって、最も基本的な課題の一つとなっています。

データ分析に対する一般的な抵抗感の背景には、分析結果の解釈の難しさや、実践との結びつきが見えにくいという問題があります。しかし、この抵抗感を克服し、データ分析の価値を実際の成果に結びつけることが、我々の重要な使命となっています。

2.2 一次元的な分析と多次元的な分析の比較

この課題の本質は、一次元的なアナリティクスと多次元的なアナリティクスの対比にあります。人々は一次元的なアナリティクスなら理解できます。なぜなら、アナリストや専門家のように深く掘り下げる時間や情熱がなくても、基本的な指標は理解できるからです。しかし、問題はこれらの基本的な指標が実は価値が低いということです。

ゴルフの世界では、フェアウェイ到達率やパット数などが典型的な一次元的指標です。しかし、これらは古い、陳腐化した分析指標であり、実際の価値は限定的です。例えば、パット数を見てみましょう。パット数は実際には、どれだけ上手くパットができたかを示す指標というよりも、アプローチショットやショートゲームの精度を反映している可能性が高いのです。つまり、ピンまでの距離が遠ければパット数は必然的に多くなります。しかし、人々はシンプルに「このラウンドは35パットだった」（私の場合は75パットですが）というような数字を理解できます。

一方で、我々がアナリティクスの分野で目指すべき方向性は、多次元的な分析です。これは非常に洞察力に富んでいますが、理解が難しい。典型的な例が「ストロークスゲイン」です。この概念をご存知の方はどれくらいいらっしゃいますか？（会場で挙手を求めたところ）3名ですね。ゴルファーが大多数いる中でたった3名というのが、まさに私の指摘したい点です。

ストロークスゲインは、実はゴルフゲームを分析する最良の方法です。しかし、それは非常に複雑で理解が難しい概念です。単純化して説明すると、ストロークスゲインはショットごとに、ベンチマーク（例えばツアープロやスクラッチゴルファーなど）と比較してどれだけ良いパフォーマンスを出せたかを測定するものです。しかし、それ以上に複雑な要素があります。

さらに、理解を難しくしている要因として、その尺度の直感的でない点があります。例えば、+0.2というストロークスゲインは実際にはとても良い数値です。ベンチマークと比較して2/10ストローク良かったということですが、ホールでスコア+2（ダブルボギー）というのは良くないスコアです。つまり、ストロークスゲインのスケール自体が、平均的なゴルファーにとって直感に反するものになっているのです。

2.3 従来の解決策とその限界

もちろん、LLMやジェネレーティブAIを使わずにこの課題を解決する方法は存在します。その代表的な例が、人間によるデータ処理とコミュニケーションです。私たちはEdoardo Molinariと協力関係を築いていますが、彼は素晴らしいゴルファーであると同時に、素晴らしい人物です。

Edoardoは欧州ツアーで活躍していますが、実は訓練を受けたエンジニアでもあります。現在、世界トップ10に入るゴルファーの多くのスポーツアナリティクスを担当しています。彼のアプローチは非常にうまく機能しています。Edoardoと彼のチームは、複雑なデータを理解可能な洞察に変換するという課題を見事に解決しているのです。

しかし、この解決策には大きな限界があります。それは、非常に手間がかかり、コストも高いということです。確かに素晴らしい成果は出せますが、このアプローチはスケールしません。Edoardoは私たちの全顧客からの分析リクエストに応えることはできません。

これこそが、LLMが明らかな解決策として浮かび上がってくる理由です。しかし、単にジェネレーティブAIをジェネレーティブAIのために導入するのではいけません。実際、私たちが敬愛する他社のアプリでは、同様のコンセプトで先行して導入を試みましたが、「明らかに当たり前のことを生成しただけで、誰の役にも立たない」「ジェネレーティブAIは少しでも不正確であってはいけない」といったフィードバックを受けていました。これらの教訓は、私たちが製品開発を進める上で重要な指針となりました。

3. Arccos Driverレポートの開発

3.1 製品開発の目的と制約条件

私たちはArccos Driverレポートの開発にあたり、ドライバーがゴルフゲームにおいて果たす重要な役割に注目しました。ゴルファーの皆さんはご存知の通り、ティーショットは非常に重要です。おそらく皆さんが最もお金をかけているクラブでもあり、私のように1-2年おきに新しいドライバーを購入する方も多いでしょう。また、最も楽しい要素でもあります。誰もがドライバーショットを楽しみます。

より分析的な観点から見ても、ドライバーショットは非常に重要です。最初のティーショットが悪ければ、そのホールの残りのプレーで苦労することになります。そのため、ゴルファーのドライビング能力を向上させ、何がうまくいっているかを効果的に伝えることができれば、大きな影響を与えることができます。

しかし、この開発には明確な制約条件がありました。私たちはスタートアップ企業であり、大規模な組織ではありません。そのため、迅速かつ効率的に開発を行い、できるだけ早くお客様に提供することを目指しました。

また、数値データから適切な文脈を理解することも重要な課題でした。LLMは計算機ではなく、ゴルフボールを打つものでもありません。LLMはトークンで考え、数値で考えるわけではありません。この違いを理解し、適切に対処することが必要でした。

そのため、私たちは意図的にファインチューニングなどの高度な手法は避け、素早くプルーフオブコンセプトを作ることに注力しました。これにより、迅速な開発サイクルを維持しながら、製品の価値を検証することができました。このアプローチは、限られたリソースの中で最大の効果を得るための戦略的な選択でした。

3.2 設計上の主要な考慮事項

私たちがドライバーレポートの設計を進める上で、いくつかの重要な考慮事項を設定しました。まず、単純なジェネレーティブAIの実装ではなく、ユーザー一人一人に合わせたパーソナライゼーションの実現を目指しました。

また、私たちが敬愛する他社のアプリケーションからの教訓として、単純に統計データを羅列するような出力は避けることにしました。以前、他社のアプリでは「明らかに当たり前のことを生成しただけで、誰の役にも立たない」という評価を受けていました。これは、LLMが単に統計を繰り返すだけで、実質的な価値を提供できていないことを示唆しています。

そこで私たちは、ユーザーの注意を適切な箇所に焦点化することを重視しました。ドライバーに関する様々なデータがありますが、それらすべてを提示するのではなく、LLMを活用してデータを要約し、ユーザーの注意を最も重要な点に向けることを目指しました。これにより、ユーザーは自分のゲームの改善に最も効果的な情報に集中することができます。

私たちはこれらの考慮事項に基づいて開発を進め、実際に機能することを確認しました。しかし、これで発表を終えるわけにはいきません。むしろ、この過程で直面した課題と、それをどのように解決したかについてお話しすることで、皆様のアプリケーション開発にも役立つ知見を共有できると考えています。

4. 技術的な発見と教訓

4.1 オーケストレーション層での予想外の工数

開発を進める中で、私たちが最も驚いた点の一つは、オーケストレーション層に予想以上の工数がかかったことです。LLMを使用しない従来の方法であれば、おそらく一つのスクリプトですべてを実行し、最後にPDFを出力するような単純な構成で済んだかもしれません。

しかし、よく考えてみると、LLMが出力を生成するためには、レポート内の他のすべてのデータが必要になります。私たちは意図的にRAG（Retrieval Augmented Generation）を使用しませんでした。なぜなら、LLMにユーザーが見るものと同じ情報を見せ、そのプレゼンテーションの適切な部分に注意を向けさせたかったからです。

つまり、LLMを実行する前に、レポート全体を生成する必要がありました。私たちはこれをAWS Step Functionsを使用して実装しました。まず数値を計算し、他のデータ要素を生成します。技術的にはこれを実装する方法は50通りほどあると思いますが、これが私たちが選択したアプローチです。

Step Functionsは私たちのケースでは非常にうまく機能しました。このプロセスは、数値の計算、データの生成、そのデータのLLMへの供給、テキストの生成、そして最終的にすべてを再びレポートにまとめる、という流れで進みます。当初の想定よりもこの部分に時間を費やすことになりましたが、結果として堅牢なシステムを構築することができました。

4.2 データフォーマットの影響

私たちはデータの性能を向上させるために、いくつかの技術的な工夫を実装しました。特に驚いたのは、データフォーマットが予想以上に大きな影響を与えたことです。私たちはXML、YAML、JSONの3つのフォーマットでテストを実施しました。

特に期間比較のコンテキストにおいて、XMLが最も優れたパフォーマンスを示すことを発見しました。例えば、先月と今月のパフォーマンスを比較する際、XMLフォーマットで過去のデータと現在のデータをブロックとして構造化することで、LLMの理解度が大幅に向上しました。興味深いことに、XMLで前月のデータブロックと当月のデータブロックを明確に区分けすることで、LLMはより正確な比較分析を行うことができました。

もう一つ私たちを驚かせた発見は、チャートやグラフの視覚データを含めることの効果です。LLMはすでにそれらのチャートを生成するための数値データを持っていたにもかかわらず、実際のチャートを入力として含めることで、出力の品質が大きく改善されました。これは当初は予想していなかった結果でした。

また、数学的な比較を支援するために、「3マイナス2イコール1」のような形で変化量を事前に計算して提供することも試みましたが、これは予想に反して効果がありませんでした。むしろ、XMLでデータを構造化することの方が、はるかに大きな改善をもたらしました。これらの発見は、LLMがどのようにデータを理解し処理するかについての私たちの認識を大きく変えることになりました。

4.3 モデル選択と最適化の過程

モデル選択とプロンプトの最適化には予想以上に時間を費やしました。これはLLMとジェネレーティブAIを使用する際の基本的な要件ですが、私たちの経験からいくつかの重要な教訓が得られました。

Amazon Bedrockを使用することで、私たちは様々なモデルを試し、出力の品質とコストのバランスを取ることができました。大きなモデルが必要なのか、小さなモデルで十分なのか。これらを検証する際、Bedrockの大きな利点は、モデルの切り替えが会話の中の1行の文字列を変更するだけで済むことでした。

当初は、人間がテキストを読んで「これは良い」「これは悪い」と評価していました。しかし、これはスケーラブルな方法ではありませんでした。そこで私たちは、異なるモデルの出力を別のモデルに供給し、0から100のスコアを付けさせることで、モデル選択のプロセスを自動化しました。

最終的に、私たちは最新のClaudeバージョンを採用することを決定しました。これもBedrockの利点の一つで、最新モデルへの移行が非常にスムーズでした。すべてが完璧に機能し、素晴らしい体験でした。

また、プロンプトの生成においては、Anthropicのプロンプト生成ツールを活用しました。プロンプトエンジニアリングは科学と芸術の両面を持っていますが、専任のプロンプトエンジニアではなくジェネラリストとして作業する場合、LLMを活用してプロンプトの改善を支援してもらうことで、パフォーマンスを大幅に向上させることができました。

これらの取り組みを通じて、私たちは品質とコストのバランスを取りながら、最適なモデルとプロンプトの組み合わせを見つけることができました。

4.4 分析と要約の分離手法

私たちは、データの分析と要約を分離する2段階アプローチを採用しました。具体的には、データから最終的な出力テキストを生成する方法として、2つの異なるアプローチを検討しました。

1つ目のアプローチは、単純にデータをLLMに入力し、約150ワードの要約を直接生成する方法です。2つ目のアプローチは、まずLLMにデータを提供してデータの分析を制約なく行わせ、その後で別のステップとして、その分析に基づいて素晴らしい150ワードの要約を生成し、それをブランドに合わせて調整し、ゴルファーのモチベーションを高めるような内容にする方法です。

私たちの実験では、AからBへの直接的なアプローチよりも、この2段階のアプローチの方がはるかに成功しました。この方法により、まず深い分析を行い、その後でユーザーにとって最も重要な洞察を適切な形で伝えることができました。さらに、この分離によって、各段階での品質管理が容易になり、ブランドの一貫性を維持しながら、個々のゴルファーに合わせた適切なトーンでメッセージを伝えることが可能になりました。

この2段階アプローチは、他社のアプリケーションで見られた「明らかに当たり前のことを生成しただけ」という課題を克服する上でも効果的でした。分析と要約を分離することで、より深い洞察と、それを効果的に伝えるための適切な表現方法の両方を実現することができました。

5. 精度向上への取り組み

5.1 比較データ処理の課題

ユーザーに不正確なデータを提供することは、皆様を驚かせないかもしれませんが、ユーザーにとって全く価値がありません。LLMは適切なコントロールがない場合、特に不正確な結果を生成しやすい傾向にあります。私たちの場合、特に期間比較のデータ処理において、この問題が顕著でした。

実際、この精度の問題は当初、プロジェクト全体を中止するかどうかを検討するほど深刻でした。データの出力の正確性が一貫していなかったのです。これは丁寧に言い換えているのですが、実際にはかなり深刻な状況でした。特に、期間比較におけるLLMの処理は大きな課題でした。

この問題は、特に月次の比較データを扱う際に顕著でした。例えば、先月と今月のパフォーマンスを比較する際に、LLMは時として不正確な解釈や計算を行うことがありました。これは単なる表示の問題ではなく、ユーザーの信頼を損なう可能性のある重大なリスクでした。

私たちはこの課題に対して、データの検証とエラーチェックの強化、入力データのフォーマット改善、そして最終的にはLLMジャッジモデルの導入という段階的なアプローチで取り組みました。これらの取り組みは、次のセクションで詳しくご説明する予定の解決策へとつながっていきました。

5.2 LLMジャッジモデルの導入と効果

私たちはこの問題を、同じモデルを使用しながらも異なるプロンプトで別の会話を行うという方法で解決しました。具体的には、あるプロンプトで生成したテキストを評価するよう、同じモデルに依頼するアプローチを採用しました。このプロセスでは、最初のモデルと同じデータを提供し、「このテキストは正確ですか？」というような問いかけを行い、JSONフォーマットで出力を得ます。

このLLMジャッジモデルは、テキストが不正確な場合に修正を行い、新しいテキストを提供することもできます。この導入により、プロジェクトの存続が危ぶまれるような状況から、データの正確性に関する懸念がほぼ完全に解消されるまでに改善することができました。

このアプローチは、他のプレゼンテーションでも「LLMジャッジ」というコンセプトとして紹介されているのを見かけることがありますが、私たちの経験では、このコンセプトは確かに効果的でした。正確性の確保が重要な課題となっていた私たちのプロジェクトにおいて、このLLMジャッジモデルの導入は決定的な転換点となりました。

特に注目すべきは、このアプローチが追加のモデルトレーニングや複雑なシステム構築を必要とせず、既存のモデルと異なるプロンプトの組み合わせだけで実現できた点です。これは、スタートアップとして限られたリソースで効率的な解決策を見出す必要があった私たちにとって、非常に重要な発見でした。

6. ゴルフコースデータの課題と解決策

6.1 グローバルなゴルフコースの複雑性

ゴルフは皆様ご存知の通り、無限の複雑性を持つスポーツです。全世界に38,000以上のゴルフコースが存在し、それぞれが独自のレイアウトを持つ、まさに雪の結晶のように一つ一つが異なります。これらのコースは206カ国に分布しており、少なくとも544,000のホールが存在します。

さらに、各ホールには複数のティーボックスがあり、ラフな計算ですが、約160万のティーボックスが存在することになります。そして、87百万人のゴルファーが、それぞれ異なるスキルレベルでプレーしています。

これは規模の課題であると同時に、多様性の課題でもあります。例えば、セントヘレナ島のゴルフコース（私も調べるまで場所を知りませんでしたが、大洋の真ん中にあります）であっても、アプリとしては完璧に機能させる必要があります。つまり、どんなに遠隔地や特殊なコースであっても、そこでプレーする可能性があるため、例外なく対応しなければならないのです。

これは私たちがアプリの開始時から取り組んできた課題であり、今後LLMを活用することでさらなる改善が期待できる分野です。特に、これだけの規模と多様性を持つデータを効率的に処理し、個々のゴルファーに適切なフィードバックを提供するという点で、新しい可能性が開けてきています。

6.2 ピンシート解析へのLLM適用

ゴルフの基本的な目的は、できるだけ少ないストロークでボールをホールに入れることです。しかし、ゴルフアナリティクスを行う上での課題は、そのホールが実際にどこにあるのかを知ることです。ピンの位置は一部のコースでは毎日、その他のコースでも定期的に変更されています。つまり、アナリティクスの精度を高めるためには、常に移動する目標を追跡する必要があるのです。

残念ながら、ピンの位置に関する単一の信頼できるデータソースは存在しません。ピン位置を集約する企業も存在しないのが現状です。しかし、多くのゴルフコースでは、ファーストティーやクラブハウスでピンシートを配布しています。これらのピンシートは標準化されておらず、様々なベンダーが異なるフォーマットで作成しています。

私たちはこの課題に対して、基本的なファンデーションモデルとシンプルなプロンプトを使用するLLMベースのアプローチを採用しました。LLMに対して「これはピンシートの画像です。このホールについて、下端からの距離、左端からの距離、グリーンの深さのデータを提供してください」というような指示を与えることで、ユーザーのために正確なピン位置を設定することができました。

この技術は驚くべき効果を発揮しました。実は、このような課題はLLMがなければ解決が極めて困難だったでしょう。もちろん、数十万ドルを投じてコンピュータビジョンのアルゴリズムを開発し、データセットを構築することも理論的には可能でしたが、実際には非現実的でした。しかし、LLMを活用することで、トレーニングなしで、単にピンシートの写真を撮り、プロンプトを調整するだけで、必要なデータを取得することができました。このアプローチにより、ティーオフ直前のゴルファーでも、写真を撮ってからデータ入力までの待ち時間を最小限に抑えることができるようになりました。

6.3 従来手法との比較とLLMの利点

私たちがLLMを採用した理由の一つは、従来のコンピュータビジョン手法と比較して大きな利点があったからです。もし従来のアプローチを取った場合、数十万ドルを投資してコンピュータビジョンアルゴリズムを開発し、独自のデータセットを構築する必要があったでしょう。これは膨大なコストと時間を必要とする取り組みになっていたはずです。

しかし、LLMを活用することで、このプロセスは劇的に簡略化されました。追加のトレーニングを必要とせず、単にピンシートの写真を撮り、適切なプロンプトを設定するだけで、必要なデータを取得することができました。この方法は、特にユーザーがティーオフ直前にピン位置をアプリケーションに入力する必要がある場合など、リアルタイムでの処理が求められる場面で非常に効果的でした。

LLMの導入により、従来のコンピュータビジョンアプローチで必要とされていた時間とリソースを大幅に削減することができました。同時に、高い精度と信頼性も維持することができています。これは私たちのような規模のスタートアップにとって、特に重要な利点でした。

このように、LLMを活用することで、データの収集、分析、そしてユーザーへのアドバイスという一連のサイクルの中で、より効率的かつ効果的な解決策を実現することができました。私は今後、このような活用方法がさらに広がっていくことに期待を寄せています。