Databricksがデータ＆AIを活用して野球チームを優位に導く方法

野球は、1つの投球、1つの対戦、1つの決断といった小さな瞬間によって定義され、急速に進歩します。この記事では、最新のクラブハウスがDatabricksを使用して、高忠実度の投球データを、試合に勝つための意思決定にどのように活用しているかを紹介します。

試合当日 午後2時

GenieとUnity Catalogによる打者ミーティング

打者たちがビデオルームに入ってきます。コーチは30ページにも及ぶ印刷物を求めているのではなく、今日の先発投手に対する的確なプランを求めています。

その日の午前中、アナリストはラップトップに向かい、Statcastやチーム固有のテーブルが一貫したスキーマ、権限、リネージとともに格納されているUnity Catalog上のGenieを開きました。アナリストは次のように尋ねました。

「今日の先発投手について、過去2シーズンにおける右打者と左打者に対する初球の配球とコースを示してください。ランナーがいる状況での傾向を強調してください。」

Genieは、Unity Catalog内の管理されたDeltaテーブルから回答をコンパイルしました。その作業の一環として、アナリストは、カウント、打者の左右、ランナーの状況別の傾向など、主要なクエリをカプセル化するUnity Catalog SQL関数のセットを登録しました。これにより、将来の計画や自動化されたエージェントで再利用できるようになります。

アナリストは結果を、スタッフが印刷したり、打者のバインダーに含めたりできるシンプルな1ページ資料にエクスポートしました。主なポイントは次のとおりです。

• 右打者：特にランナーがいない状況では、序盤に高いカットボールとフォーシームが多い。
• 左打者：二塁にランナーがいる場合は、チェンジアップとシンカーの割合が増える。
• 2ストライク：ほとんどの重要な三振では、スライダーがアウトコース低めに決まっている。

打撃コーチは3つの明確な話題を持ってミーティングに臨みます。選手たちが打撃練習に向かう頃には、最初の2回の打席は推測ではなく、今日の先発投手が実際にどのように投げるかという共通認識に基づいたものになっています。

シリーズ前のブルペン準備

Agent FrameworkとModel Servingによる継投策のスクリプティング

ほとんどの試合で、先発投手が100球に近づき、打順の中軸が回ってくる場面があることをスタッフは知っています。シンカーボーラーとスライダー主体の右腕のどちらを選ぶかは、その場では直感的な判断のように感じられるかもしれませんが、作業はもっと早くから行われています。

シリーズ前のクラブハウスで、アナリストはAgent Bricksで構築され、Model ServingにデプロイされたMulti-Agent Supervisorを使用して、スタッフが重視する状況をシミュレートします。具体的には、6回裏の打順中軸、7回裏の下位打線、終盤の左打者中心の打席などです。

各意思決定について、エージェントは次のことを行います。

1. Unity Catalogのルックアップ関数を使用して、関連する打者の名前をIDに解決します。
2. カウント、打者の左右、ランナーの状況別の球種とコースの結果を計算するUC SQL関数を呼び出します。
3. 各リリーバーの持ち球を、その打席の打者群と比較し、どのプロフィールが最も効果的で、なぜそうなのかを、分かりやすい野球用語で説明します。

アナリストはこれを短いブルペンカードにまとめます。例えば次のような内容です。

• 「もしこの3人の打者が回ってきて、先発投手が疲れているなら、スライダー主体の右腕が有利です。彼の持ち球がこのような状況でどのように機能したかを示します。」
• 「下位打線が回ってくるなら、シンカーボーラーのゴロを打たせる投球がより多く勝つでしょう。その証拠がここにあります。」

スタッフはそのカードを印刷し、一緒にレビューします。試合中に実際の6回裏の状況が現れたとき、誰もDatabricksにログインしていません。投手コーチは、数時間前にエージェントとプレッシャーテスト済みの意思決定ツリーに従っています。

終盤の攻撃

同じエージェントとツールによる代打策の計画

8回裏の代打の選択も同様の方法で練習されます。

試合前の準備の一環として、アナリストはDatabricksエージェントに次のように尋ねます。

「このシリーズで対戦する可能性のある終盤のリリーバーについて、期待される結果でベンチの打者をランク付けし、それぞれがより良い選択肢となる状況を説明してください。」

エージェントは、同じUC関数とUnity CatalogのDeltaテーブルを呼び出して、次のことを行います。

• 各リリーバーの使用パターンと、各代打の球種、コース、カウント別の結果を組み合わせます。
• ランナー一、二塁、1アウト、カッターを多投する右腕リリーバーに直面する、といった典型的な終盤のシナリオをシミュレートします。
• 「リリーバーXに対しては、ランナーがいる状況では打者Aの方が適していますが、ランナーがいない状況で彼がシンカーを多投する場合は打者Bの方が適しています。」といった、分かりやすいガイダンスを生成します。

アナリストはこれらの推奨事項を、監督のゲームカードや、事前にレビューできる小さな1ページの「代打グリッド」に落とし込みます。試合が始まると、そのカードが参照点となります。監督は、すでに検討済みの選択肢の中から選ぶことになります。データは、ダグアウトでのデバイスに関するリーグ規則を遵守した形式に要約されています。

移動日

Vector SearchとUnity Catalogによるスカウティング準備

シリーズ間のオフ日、アナリストは単一試合の戦術から次の対戦相手に目を向けます。次の2人の先発投手は、打線との直接対戦の履歴が限られています。

Genieに戻り、アナリストは次のように尋ねます。

「次の先発投手と最も似た持ち球と球威の投手を見つけ、その比較対象の投手に対して、我々の打線がどのように対戦してきたかを示してください。」

ここで、Genieは作業の一部をDatabricks Vector Searchに引き渡します。以前の処理からUnity Catalogに保存された投手と打者の埋め込みがインデックス化されているため、システムは目視で推測することなく「似た投手」を見つけることができます。

ワークフローは次のとおりです。

1. Genieは、Unity Catalogテーブルから新しい先発投手の球種と球威を分析します。
2. Vector Searchは、似た球種プロファイルの投手を見つけます。
3. UC SQL関数は、それらの比較可能な投手に対する打線の結果を計算します。
4. Genieは、打撃コーチが使用できるスカウティングレポートにパターンを要約します。

直接対戦のStatcastの履歴が少ない場合、Vector SearchとGenieの組み合わせにより、スタッフは「このような投手に対して、我々はどのように打ってきたか」と言い、それをシリーズ計画に組み込むことができます。これらの洞察は、次のアウェーゲームのミーティングに向けて、アドバンスレポートにエクスポートされます。

フロントオフィスデー

GMとアナリストによるGenie、Lakehouse、Lakebaseの活用

勝利シーズンは、1試合以上の積み重ねで築かれます。GMとアナリストは、価値、フィット感、リスクに関する判断を下すために、同じプラットフォームを使用します。

Genieで、彼らは次のような質問を探求します。

「3番手の先発投手のプロフィールが、カウントと打者の左右別に、我々のディビジョンの上位打線とどのように対戦するかを示してください。彼の価値はどこにあり、どこに弱点がありますか？」

「リーグ内の左打者について、我々のディビジョンで終盤に投げられる投球パターンと合致する強みを持つ選手を特定してください。」

これらの質問は、Unity Catalog内のレイクハウスから直接回答されます。投球レベルのデータ、埋め込み、派生特徴量はすべて1か所で管理されています。Genieはそれらを自然言語の回答に変換しますが、内部的にはロジックは再利用可能なUC SQL関数です。

一方、コーチ、スカウト、フロントオフィスが使用する野球運営アプリは、Lakebase Postgresによって支えられています。そのアプリでは次のことが行われます。

• スカウトが潜在的なトレード候補に関するレポートを入力します。
• コーチが、試合後に「6回裏、打順中軸に対しスライダーから入った」といった、より高レベルの決定にタグを付けます。
• GMがトレード、契約延長、ロスター変更に関する最終決定を記録します。

Lakebase PostgresはDatabricksプラットフォームの一部であるため、アプリの状態はソースデータに近い場所に保持されます。

• アプリへの書き込み（レポート、タグ、決定）はLakebase Postgresに格納され、アクセス権を持つアナリストやエージェントがすぐに利用できます。
• スケジュールされたジョブまたはパイプラインが、Unity CatalogテーブルのキュレーションされたスライスをLakebase Postgresに公開するため、アプリのUIは手動のCSVエクスポートなしで常に最新の統計と特徴量を利用できます。

その結果、共有された記憶が生まれます。何が起こったのか、なぜ起こったのか、そしてどのように正当化されたのかが、タイムスタンプとユーザーIDとともに1か所に保存されます。

これが試合に勝つ理由

• より賢明なロスターの賭け：選手の動きは、特にディビジョン内やポストシーズンで、リーグの投球パターンと一致します。
• 質の高い打席：打者は、一般的な投球ではなく、その瞬間に投手が実際に投げるものに基づいて打席に臨みます。
• よりクリーンなブルペンマッチアップ：各リリーバーの最適な状況が数秒で明らかになり、時間的プレッシャー下での推測が減少します。
• 有利な状況での無駄な投球の減少：打者とカウントごとに決め球を知ることで、深いカウントとフォアボールが減少します。
• より良い初球の結果：期待される選択肢を覆す攻撃計画は、チームの terms で早期のコンタクトを生み出します。

これらすべてが意味を持つのは、数字が正しい場合のみです。散在する個別のツールではなく、単一の管理されたレイクハウス上でこれらのエージェントとアプリを実行することで、クラブはロジックが既に行っている作業と一致していることを確認し、重要な場面でそれを活用できます。データが特定の対戦や動きを指している場合、それはゲームプランの延長のように感じられ、ブラックボックスのようには感じられません。

Databricks Sportsの詳細をご覧になるか、デモをリクエストして、貴社が競争上のインサイトをどのように推進できるかをご確認ください。

(このブログ記事はAI翻訳ツールを使用して翻訳されています) 原文記事