Elemental InferenceのEvent Clippingでスポーツハイライトの自動検出ができるのか検証してみた
AWS Elemental Inference
AWS Elemental Inferenceは、2026年2月下旬に提供開始されたサービスです。
これまでこのブログでは、縦型変換(スマートクロッピング)を中心に試してきました。
- AWS Elemental Inferenceをローンチ当日に早速使ってみた
- Elemental Inferenceを使って横動画mp4をAI処理で縦動画に自動変換してみた
- Elemental Inferenceを使ってMediaConvertで縦動画を自動で作ってみた
2本目の記事の最後に「次はEvent Clippingに挑戦してみたいです!」と書いてから、気づけば半年。
今回はいよいよEvent Clipping、スポーツのハイライト自動検出に着手してみました。
Event Clippingとは
Event Clippingは、ライブ映像の中から「ゴール」や「シュート」のような注目シーンを見つけて、その開始・終了時刻をメタデータとして教えてくれます。
ここで勘違いしやすいのが、クリップ動画そのものは作ってくれないという点です。
いい部分だけ切り取ってくれるのではなく、メタデータとして教えてくれる仕組みになっています。
流れとしては以下となります。
- MediaLiveがソースの映像をElemental Inferenceに渡す
- Elemental Inferenceが映像を解析し、注目シーンの開始・終了を検出
- 検出結果がAmazon EventBridgeにイベントとして届く
- そのイベントを受けて、実際に映像を切り出すのは自分で作る
公式ドキュメントでは、現在対応している競技はサッカーとバスケットボールとされています。
また、Event Clippingはライブ入力のみ対応で、MP4ファイル入力は使えません。
アーキテクチャ
今回は「どんなイベントが、どんなタイミングで届くのか」を確認するのが目的なので、
届いたイベントをそのままCloudWatch Logsに溜めるだけの構成にしました。
リージョンはすべてバージニア北部(us-east-1)で行いました。
環境構築
1. フィードの作成
まずElemental Inferenceのコンソールで「フィード」を作ります。
フィードは、どのAI機能を使うかをまとめた設定の単位です。
AI featuresはEvent Clippingのみを選択します。
Callback metadataは、EventBridgeに届くイベントに毎回付けてくれる文字列です。
今回はsports-testとしました。
その他は特に何も変えずに登録します。
2. EventBridgeルールとCloudWatch Logs
次に、MediaLiveのチャネルを起動する前に、届いたイベントを受け止める先を用意しておきます。今回はEventBridgeのルールで、Elemental InferenceからのイベントをすべてCloudWatch Logsに流すようにしました。
イベントパターンはsourceだけを指定しました。
{
"source": ["aws.elemental-inference"]
}
Elemental Inferenceからどういうイベントが届くのか全て見てみたかったこともあるので、Elemental Inferenceから来るものを全部拾うようにしました。
3. MediaLiveチャネル
あとは通常どおりMediaLiveのチャネルを作り、「AWS Elemental Inferenceの設定」で先ほどのフィードを選ぶだけです。
先ほど作ったフィードを選ぶと、イベントクリッピングの欄でクリッピング出力が含まれていることが書かれていました。
チャネルを開始すると、フィード側にMediaLiveとの関連付けが表示されました。
実際に流してみた
サッカーの映像を流してしばらくすると、CloudWatch Logsにこんなイベントが届きました。
{
"version": "0",
"detail-type": "Clip Metadata Generated",
"source": "aws.elemental-inference",
"time": "2026-10-05T11:45:42Z",
"region": "us-east-1",
"resources": ["arn:aws:elemental-inference:us-east-1:XXXXXXXXXXXX:feed/xxxxxxxxxxxxxxxxxxx"],
"detail": {
"timescale": 90000,
"startPts": 161208065097000,
"endPts": 161208066177000,
"description": "",
"tags": ["goal"],
"callbackMetadata": "sports-test"
}
}
フィードで設定したCallback metadataはcallbackMetadataという専用のフィールドに入っていました。
startPtsとendPtsは、timescale(90000)で割るとUNIX時刻になります。
上のイベントを計算すると、日本時間の20:45:23.3〜20:45:35.3となりました。
ちょうど12秒間のクリップです。このとき、ソース側でゴールが決まったのが20:45:11、MediaLiveの出力で確認できたのが20:45:26頃でした。
つまりこの時刻はソース側の時刻ではなく、MediaLive側の時刻です。
クリップはゴールの約3秒前から約9秒後まで、ゴール前の流れと喜ぶ場面を含んだ範囲になっていました。
Elemental Inferenceの解析にかかる時間は、PTSではなくイベントのtimeのほうに表れます。
timeは20:45:42なので、クリップ終了の約7秒後に通知が来た計算です。
サッカーで出たタグ
約50分間サッカーを流して、出たタグはgoal、shot、saveの3種類でした。
気になったのは、シュートからゴールまでは、別々のイベントとして隙間なく連続して届いていました。
また、saveは5件すべてが同じ時間帯のshotとペアで届きました。
tagsは配列ですが中身は常に1つで、1つの場面に複数のタグがつく場合はタグごとに別のイベントになるようです。
また、上のゴールの直後、20:45:39〜20:45:47にもう1件goalが届きました。
この時間、実際にはゴールは入っておらず、流れていたのは中継のリプレイ映像でした。
映像としてゴールに見えれば、生のプレーでもリプレイでもgoalとして検出されるということがわかりました。
ハイライトを自動で作る場合、リプレイを弾くか、逆に「ゴール+リプレイ」をまとめて1本にするか、後段で判断する必要がありそうです。
他の競技も流してみた
せっかくなので、フィードの設定は一切変えずに、途中で映像だけ別の競技に切り替えてみました。
バスケットボール
映像をバスケに切り替えた途端、twopointerとthreepointerが出始めました。
競技を指定する設定はどこにもないので、競技は映像から自動で判別しているようです。
ドキュメントにはdunkもあるみたいなのですが、今回検証した動画は高校生の試合でそもそもダンクがありませんでした…。
ラグビーと野球
現時点で非対応の競技は、すべてotherになりました。
トライやホームランが特別扱いされることはありませんでした。
MBSで中継の多い野球やラグビーで使えないのは、正直少し残念です。
今後の対応競技の拡大に期待したいと思います。
細かい挙動
4つのスポーツで検証してみて、検出された127個のイベントを並べてみました。生成AIに何か気づくことがないか聞いてみたところ、ほかにもいくつか決まった傾向が見られました。
- クリップの長さは8秒か12秒の2種類だけ:127件すべてがこのどちらかでした
- 境界は4秒刻み:開始時刻の秒数がすべて03、07、11…と4秒ごとに揃っていました。解析が4秒単位で動いているようで、切り出すときは前後に少し余白を足したほうが安全そう…?
- 通知はクリップ終了の約6〜7秒後:どのイベントもほぼ一定でした
- 区間は重なることもある:shotとgoalが隙間なく続く場合だけでなく、4秒ほど重なって届くケースもありました
このあたりは、実際にクリップを切り出す仕組みを作るときの設計に直接効いてきそうです。
最後に
Event Clippingは、設定自体はフィードを作ってMediaLiveで選ぶだけと、とても簡単でした。
一方で、届くのはあくまで「いつ、何が起きたか」のメタデータで、クリップ動画を作るのは自分の仕事です。
Elemental Inferenceが登場したタイミングからこのEvent Clippingは知っていたものの、ドキュメントを読むだけでは分からないことも多く、やはり手を動かしてみるのが一番だと改めて感じました。
今後、対応するスポーツが増えてきて、実際にMBSでのスポーツ中継などで活かせるタイミングが来たときは、この機能を使って自動ハイライトクリップ生成にチャレンジしてみようと思いました。




