はじめに

メジャーリーグの「ロボット審判＝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などに小さくアウトプットしていく習慣

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

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