Databricksでのサッカーコーチングアプリの構築

トラッキングデータは、今やスポーツにおいて最も豊かなシグナルですが、本当の課題は、そのデータをコーチが実際に活用できる形に変換することにあります。

現代の試合は、19の独立したフィードから毎秒25フレーム（FPS）でキャプチャされます。すべての選手、ボール、そしてすべてのイベントが、1秒間に何度も記録されます。1つのトーナメントだけでも、339試合、5,100万行のトラッキングデータにのぼります。しかし、そのデータのほとんどは、最もそれを必要としている人にとって使える状態にはありません。ベンチにいるコーチが5,100万行のテーブルを読み解くことは不可能です。「Coach's Corner」は、このギャップを完全に単一のプラットフォーム上で解消します。

課題は規模だけでなく、タイミングと認知にもあります。コーチは数分ではなく数秒で意思決定を行います。しかし、従来の分析ワークフローはその逆、つまりバッチ処理、オフラインのダッシュボード、試合後の振り返りを前提としています。インサイトが存在する場合でも、アナリストが解釈して伝える必要があるツールの背後に埋もれてしまっています。これにより、データは豊富でモデルは高度であるにもかかわらず、肝心な瞬間に意思決定者が実質的に何も見えないという、構造的なボトルネックが生じています。

Coach’s Corner「La Pizarra」のご紹介

La Pizarra（「黒板」の意）は、Databricks Appとして動作する代表チーム向けのテクニカルベンチです。コーチは試合を選択し、2Dまたは3Dで再生できます。カメラを中継アングルから俯瞰的なタクティカルビューに切り替えたり、最大8倍速でスクラブ再生したりできます。再生画面には、シュートやxG（ゴール期待値）のマップ、パスネットワーク、ヒートマップ、セットピース、チームの陣形、ピッチコントロール、ボールの軌跡、選手の動線など、重要な分析データが重ねて表示されます。再生機能には、詳細な順位表ビュー、イベント駆動型の分析、あらゆるチームを評価するための独自の「Scout」スタイルシグネチャー、そして次の対戦相手に関するオンデマンドの分析レポートを生成できる「Tactical Agent」など、いくつかの高度なツールが統合されています。

ベンチビューは試合のすべてをコーチの手元に集約し、中継映像と俯瞰的なタクティカルビューをシームレスに切り替えられるようにします。8倍速のスクラブ再生や、パスコースやヒートマップの自動オーバーレイ表示により、ピッチコントロールやチームの陣形といった戦術的要素が、単なる数値データではなく、フィールド上の具体的なパターンとして視覚的に捉えられるようになります。

Coach's Cornerの技術的基盤は、「インターフェースは複雑な分析ツールではなく、コーチの自然な直感の延長として機能しなければならない」という単一の基本原則に基づいて構築されました。これには、操作の手間（オーバーヘッド）を減らし、従来のグラフ表示よりも空間的なコンテキストを優先し、すべての指標をゲームの動的な要素として提示するデザインが必要でした。インサイトをプレイ中のフィールドに直接紐付けることで、手動でデータを解釈する必要性を排除し、最も重要となるタイミングで的確な分析結果を提供します。

単一プラットフォームで、すべてのホップを処理

コアとなるデータエンジニアリングは、バックグラウンドで実行されます。生のトラッキングフィードはNDJSON形式でUnity CatalogのVolumeに保存され、Auto LoaderがLakeflow Connectパターンを使用して増分インジェストします。そこから、Spark Declarative Pipelinesがブロンズ、シルバー、ゴールドの各レイヤーを通じてデータを処理します。これはPhoton上で完全にサーバーレスで動作し、46個の定義済みデータ品質エクスペクテーション（Expectations）が適用されます。5,100万行のフレームテーブルを含む最終的なゴールドテーブルは、リキッドクラスタリング（liquid clustering）を活用し、小規模なウェアハウスで実行されるDBSQLを介して1〜3秒のクエリ応答時間を実現します。すべてのボリューム、テーブル、モデル、インデックスを単一のUnity Catalogに統合することで、このアーキテクチャはベンダー固有のグルーコードや二次的なガバナンスシステムを不要にします。

このアーキテクチャは、特化型のマイクロサービスへの移行を避けることで、意図的に断片化を防止しています。インジェスト、変換、サービング、AIオーケストレーションを、個別にローカル最適化されたサイロ化されたスタックに分割するのではなく、システムを単一のプラットフォーム上に統合したままにしました。すべてをDatabricks内に収めることで、理論上の柔軟性を多少犠牲にする代わりに、単一のガバナンスレイヤー、一貫したリネージ、システム間のインピーダンスミスマッチの解消といった、運用の整合性を獲得しました。これはAIを導入する際に特に重要となります。なぜなら、ガバナンスが効いていないデータや一貫性のないデータによるコストは、急速に膨れ上がるからです。

Spark Declarative Pipelinesは、命令型モデルから宣言型（明示的）モデルへと移行することで、信頼性を再定義します。前提条件が埋め込まれた硬直的なジョブに依存するのではなく、正式なエクスペクテーションを適用することで、データ品質を最優先事項として扱います。この46個のエクスペクテーション群は、パイプラインをリアルタイムで保護すると同時に、再生機能、分析、AIエージェントなどの下流のコンシューマーに対してデータの「正確性」を保証するという、2つの役割を果たします。

以下の図は、ベンチビューを支えるアーキテクチャを示しています。最上部には、コーチが操作するエクスペリエンス（再生、分析、スカウト、順位表、エージェント）があります。中間層では、これらの各エクスペリエンスがガバナンスの効いたレイヤーによって支えられています。データとモデルのためのUnity Catalog、分析およびトランザクションサービングのためのLakehouseとLakebase、そして類似性検索のためのVector Searchです。最下部には、すべての起点となる生のデータ（25 FPSのトラッキングフィード、試合イベント、選手プロフィール、ラインナップ）があり、これらすべてがオープンなレイクに保存されます。

速度とスケールのために最適化されたサービングパス

最高のパフォーマンスを確保するため、このアプリケーションはデータ取得に2つの異なるアーキテクチャパスを使用しています。高速なトラッキング再生はLakebaseによって強化されており、ゴールドテーブルをPostgresに同期することで、ミリ秒レベルのウィンドウ処理されたフレーム読み取りを可能にします。ブラウザのクロックが試合全体をスキャンするのではなく、必要なフレームのみをプルできるようにすることで、システムは滑らかでインタラクティブな体験を維持します。逆に、負荷の高いイベント分析はStatement Execution APIを介してSQLウェアハウスにルーティングされ、計算負荷の高いクエリを応答性の高い3D再生から分離します。

LakebaseとDBSQLを意図的に分岐させることは、単なる処理速度だけでなく、異なるアクセスパターンに対応するためのものです。再生機能は、特定のデータセグメントに対するシーケンシャルでレイテンシに敏感な読み取りを必要とするのに対し、分析ワークロードは探索的であることが多く、広範なデータセットのスキャンを必要とします。これらのパスを分離することで、各ワークロードは理想的な環境で動作し、分析処理の急増によって再生体験が低下したり、不要なオーバープロビジョニングが発生したりするのを防ぎます。

LakebaseとDBSQLの分離は、パフォーマンスだけでなく、アクセスパターンの違いによるものです。再生ワークロードは高度にシーケンシャルでレイテンシに敏感であり、データの狭い範囲に対して予測可能なミリ秒単位の読み取りを必要とします。一方で、分析クエリは突発的かつ探索的であり、データセットのより広い部分をスキャンすることがよくあります。これらを単一のサービングレイヤーに統合しようとすると、再生速度が低下するか、分析用に過剰なプロビジョニングを行うかのどちらかになります。パスを分割することで、妥協することなく、各ワークロードを最適な環境で動作させることができます。

ガバナンスの効いたデータに基づくAIスカウティングレイヤー

インテリジェンスは、ガバナンスの効いたデータと「並行」して存在するのではなく、その「上」に構築されます。Scoutチャットは、コーチの自然言語による質問をガバナンスの効いたSQLに変換する、実際のGenieスペースによって支えられています。Vector Searchは、選手プロフィールインデックスに対する「類似選手」の検索を強化します。対戦相手の分析レポートはエージェントです。Agent BricksのスーパーバイザーがGenie、Vector Search、そしてUnity Catalogに登録されたxGモデルをオーケストレーションし、Unity AI Gatewayを介してModel Serving上のClaudeを呼び出すことで、ガバナンスが効いた観測可能なLLM呼び出しを実現します。すべてのステップはMLflowでトレースされ、エージェントには常に決定論的なスクリプトによるフォールバックが用意されているため、ユーザーの前で処理が途方に暮れることはありません。コーチがボード上で見ているのと同じカタログを読み取るため、回答は常にデータと一致します。

以下のスカウトビューでは、コーチはクエリを書いているのではなく、ロッカールームにいるかのように質問を投げかけています。Genieは「xGとxBAについて質問する」を受け取り、ベンチを支えるのと同じトラッキングデータやイベントデータを使用して、バックグラウンドでガバナンスの効いたSQLに変換します。その回答は一般的なLLMの応答ではなく、Unity Catalogに登録されている正確なテーブルとモデルに基づいているため、スカウトの解説はアナリストが見る数値と完全に一致します。

応用AIにおける最も困難な課題の1つは、回答を生成することではなく、それらが追跡可能であり、根拠が明確であることを保証することです。コーチングの現場においては、誤ったインサイトや検証不可能なインサイトは、インサイトが全くないことよりも悪影響を及ぼします。すべてのAIインタラクションをUnity Catalogに紐付け、すべてのモデル呼び出しをUnity AI Gateway経由でルーティングすることで、すべての応答がガバナンスの効いたデータと観測可能な実行パスに関連付けられます。これにより、コーチやアナリストは出力結果だけでなく、その背景にあるプロセスも信頼できるようになります。

エージェントアーキテクチャも、決定論（確実性）を重視する傾向を反映しています。LLMが要約や解説を提供する一方で、データの取得、指標の計算、類似性検索などの重要なステップは、GenieやVector Searchなどの構造化されたシステムによって処理されます。このハイブリッドなアプローチにより、完全な生成システムにありがちな脆弱性を回避しつつ、柔軟で自然なインタラクションを可能にしています。

これが重要である理由

Coach’s Cornerはスポーツに根ざしていますが、そのアーキテクチャは普遍的な課題、すなわち高頻度データにおける「ユーザビリティのギャップ」に対処しています。多くの組織は膨大なデータ量を保有していますが、生の入力を即座の意思決定に変換するシステムがないため、それらは業務に活かされないまま眠っています。このプロジェクトは、インジェスト、変換、そしてAIを単一のガバナンスフレームワーク内に統合することで、データとアクションの間の摩擦を排除できることを証明しています。

その影響は、単にダッシュボードが高速化されることにとどまらず、意思決定のあり方そのものの変化をもたらします。同一システム内でインサイトを数秒で生成、検証、提供できるようになると、データの役割は過去の分析から、意思決定への積極的な関与へと進化します。これこそが、単に試合を観戦することと、試合に影響を与えることの違いです。

以下のエージェントビューは、そのパターンを完全に表現したものです。トラッキングデータと試合イベントから開始し、スーパーバイザーエージェントがチームのスタイルシグネチャを取得し、類似の試合を検索し、xGモデルを呼び出し、LLMにこれらすべてを要約書に統合するよう指示します。コーチには、こうしたオーケストレーションは一切見えません。彼らに見えるのは、「ブラジルの要約書を生成」と書かれたボタン、必要に応じて確認できる推論トレース、そしてゲームプランの一部となる保存されたレポートだけです。

当初はスポーツに特化したアプリケーションとして構想された「Coach’s Corner」は、ライブエンターテインメント分野における最新のデータおよびAIシステムの決定的な設計図へと進化しました。生データを一度取り込み、信頼性の高いパイプラインを通じて精製することで、システムは各特定のワークロードに最適な経路で情報が提供されるようにします。このプロセスにより、生のインプットが、意思決定のまさにその瞬間に利用可能な、ガバナンスの効いた実用的なインテリジェンスへと変換されます。この取り組みから得られる最大の教訓は明確です。データ管理、サービング、そしてAIが単一のプラットフォーム上に統合されると、インサイトは即座のアクションへと変換されるということです。

このようなものを構築してみたいですか？Databricks Appsのドキュメントを参照して独自のフルスタックデータアプリをデプロイし、Lakebaseがどのようにミリ秒単位のPostgresサービングをレイクハウスにもたらすかを確認し、GenieとAgent BricksがどのようにUnity Catalogの下でデータにガバナンスの効いた自然言語インテリジェンスを追加するかを学びましょう。

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