2
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

MLBロボット審判をAWSで再現するとしたら?

2
Last updated at Posted at 2025-12-02

はじめに

メジャーリーグの「ロボット審判=ABS(Automated Ball-Strike System)」を題材に、できるだけシンプルで、口頭でも説明できるAWS構成を考えてみます。

ここでの基本方針は「複雑にしすぎず、確実に動く構成を」を軸に、あくまで"ざっくり技術イメージ"として整理します。

1. ABS は中で何をしているのか?

公式の仕組みを大まかに言葉にすると、流れはこうです。

カメラでボールを捉える

球場の屋根やバックネット裏などに高性能カメラを1球場に約12台設置し、1球ごとの軌道を撮影します。

コンピュータビジョンで軌道を計測する

複数カメラの映像から三角測量を行い、フレームごとにボールの3D位置を算出します。

連続フレームから軌道を推定し、ホームプレート上を通過する瞬間の位置(高さ・左右)を求めます。

ストライクゾーンのモデルを作る

ルールに基づき、打者の身長などからゾーン上端・下端をパーセンテージで定義します。
横幅はホームベースと同じ17インチ(約43㎝)

判定ロジック

ボールが、プレート通過時点でこのゾーンに入っていれば「ストライク」、外れていれば「ボール」と判定します。

通信基盤

カメラからのデータは、専用の高速ネットワーク(MLB ではT-Mobileのプライベート 5G)が使われています。

ざっくりまとめると

「カメラ → 軌道推定 → ゾーンとの位置関係 → 判定」

というパイプラインです。

※参考資料

2. これをAWSで再現するとどうなるか?

3 レイヤで割り切ります。

2-1. 入力レイヤ

Direct Connect

  • 球場とAWSを専用線で直結し、映像データを安定して送ります。

Kinesis Video Streams

  • 判定用カメラの映像を受け取ります。
  • 後ろの処理が「この投球の映像だけ欲しい」と取り出せる形で保存・配信する役割です。

2-2. AI 判定レイヤ

Kinesis Data Streams

  • 映像データを「1投球単位」のイベントとして後ろの Lambda / SageMaker に順番よくデータを流し、大量のイベント(投球)を捌きながら順序とスループットを管理する役割です。

AWS Lambda

  • イベントを受け取り、必要な情報だけ抜き出して整形します。

Amazon SageMaker

  • AWS上のロボット審判本体。機械学習済みモデルをリアルタイムエンドポイントとしてデプロイし、軌道とストライクゾーンから strike / ball を返します。

Amazon DynamoDB

  • pitch_id, 判定結果, 信頼度, 時刻などをミリ秒単位で保存・参照するための NoSQL DBです。

2-3. 表示・配信レイヤ

AWS Elemental MediaLive

  • 中継映像を受け取り、HLS など配信用フォーマットにリアルタイム変換します。

Amazon CloudFront

  • 世界中のエッジロケーションから配信するCDN(コンテンツ配信網)。視聴者に近いサーバーから配信し遅延を減らし負荷分散します。

Amazon API Gateway(WebSocket)

  • APIを公開・管理するためのフロントドア。 この構成では HTTP API / WebSocket API を立てておき スコアボード用アプリからの 「この投球の判定を教えて」というリクエストを受ります。

Amazon Cognito

  • 有料配信や運営用コンソールのユーザー認証・トークン発行を担います。

Lambda@Edge

  • CloudFront のエッジでトークン検証などの軽い処理を行い、不正アクセスを弾きつつ正規ユーザーにはすぐ配信します。

全体フロー

ここまでをまとめると、

カメラとセンサーから Direct Connect で AWS に送り、Kinesis → Lambda → SageMaker → DynamoDB で判定を出し、MediaLive → CloudFront で映像を配信しつつ、API Gateway / WebSocket で判定結果を UI に載せる

という流れになります。

3. 「複雑にしすぎず、確実に動く構成」にしているポイント

配信パイプラインは 1 本に絞る

映像は Direct Connect → MediaLive → CloudFront に寄せて、ロボット審判は別にしています。

AI が落ちても配信は継続

判定レイヤは配信と疎結合にし、最悪ストライクゾーンのオーバーレイが消えるだけで試合は見られる設計。

サービス数を増やしすぎない

"説明できる範囲"に収めるために、3レイヤ × 数サービスに抑え、口頭試問でも図なしで話せる粒度にしています。

おわりに

ABSの詳細な実装はもっと複雑ですが、「3レイヤ構成でざっくり、 AWSで再現してみる」というだけでも、

  • 自分でテーマを決めて考える力
  • 抽象的な言葉(AWS / AI / 配信)の裏側を説明する力
  • Qiitaなどに小さくアウトプットしていく習慣

の良い頭の筋トレになると感じています。

完璧な構成図を目指すより、まずはこのぐらいの粗さで言語化しておき、あとから少しずつ精度を上げていく前提のメモとして書きました。

2
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
2
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?