ステータス：ドラフト（2026-10-13）、ドキュメント・論文基準（独自の実測値なし）。 この記事は公式ドキュメント（2026-10-13閲覧）と論文の数値をもとに執筆しました。私たちの実験では、ビジョン言語モデルを実際に呼び出していません。スロー確認レイヤーは計画段階です。 作成ルール：実測データが基本であり、測定できなかったものは「未実測」と表記します。
目次
1. 魅力的なアイデア
ビジョン言語モデル（VLM）は、映像を入力すると何が起きたのかを文章で答えてくれます。卓球のルールもテキストとして理解しています。それならば、パート1からパート7までのボール検出、卓球台の幾何学、イベントのルール、審判エンジンをすべてスキップして「このラリーはどちらが勝ったの？」と聞けばよいのではないでしょうか。
結論から言うと、現時点では 得点を決める作業には適していません。 モデルが賢くないからではなく、得点を決める瞬間が モデルの入力に含まれない ためです。
2. 理由その1：1秒に1枚
Gemini APIの映像理解ドキュメント（2026-10-09更新）には次のように記載されています。
- 映像入力はデフォルトで 1秒に1フレームを抽出し処理する。
fpsを個別に指定できる。 - 低解像度設定において、1フレームは66トークン、映像1秒は約100トークンである。
- 映像内の特定の時点は
MM:SS形式の時刻で尋ねる。 - そしてドキュメント自身が警告している：「高速な動作は1 FPSのサンプリングのため詳細が失われる可能性がある。」
リアルタイム対話用のLive APIのドキュメントはさらに明確です。映像は静止画として送信し 最大で1秒に1枚であり、音声と映像を一緒に送信するセッションは 2分に制限されます。
卓球に当てはめると次のようになります。
| 私たちが知っている時間 | 値 | 根拠 |
|---|---|---|
| 60fpsの1フレーム | 16.7ms | — |
| サーブの最初の2つのバウンドの間隔 | 0.18–0.55秒、中央値0.40秒 | 実際の試合12本、ラベル付きサーブ275個（実測） |
| ラリー内のバウンド間隔 | 98%が1.5秒以内 | 同上のデータ |
| 同じ側に2回バウンドした疑いを持つべき間隔 | 0.25秒未満 | 5本 |
1秒に1枚を見ると、1つのサーブで発生する2つのバウンドはたいてい同じ1秒の範囲内、 2つのサンプル間を通り過ぎてしまいます。「どちらの側に何回落ちたのか」が得点を決めますが、その瞬間が入力に全く存在しません。モデルができるのは前後のシーンから推測することだけです。
fps を上げればよいのではないでしょうか。ドキュメントには指定方法は記載されているものの、上限が記されておらず、例示ではむしろ0.5となっています。60fpsで送信するとトークンが60倍になり、それでもモデルがフレーム間の短い接触を時刻として正確に捉えられるという根拠は見つかりませんでした。時刻を秒単位で扱うという点も引っかかります。16.7ms単位の順序が重要な判定において、秒単位の時刻はあまりにも粗すぎます。
3. 理由その2：ベンチマークが示す水準
ラケットスポーツの映像でVLMがどの程度機能するかを測定したベンチマークとして、TennisTV（arXiv 2509.15602、2026-04時点のv5）があります。テニス映像1,298本、質問2,527件、タスク8種を用いて17個のVLMを評価しました。
| 対象 | 全体精度（論文） |
|---|---|
| 人間 | 89.2% |
| GPT-4.1 | 45.1% |
| GPT-4o | 44.5% |
| Gemini 2.5 Pro | 43.9% |
| ランダム選択 | 27.9% |
最も難しいタスクは ラリーでのボールの打撃回数を数えることであり、Gemini 2.5 Proは31.5%でした。モデルによってはランダム（25%）よりも低い結果となりました。コストの都合上、商用モデルは1fpsで評価されたことも論文に記載されています。オープンソースモデル（Qwen2.5-VL-7B）でフレーム数を変更して検証したところ、1fpsが38.1、16枚が38.6、32枚が38.8、64枚が38.4と、ほとんど変化しませんでした。 フレームを増やしても自動的に改善されるわけではないことを意味しています。著者らは、タスクごとにサンプリング密度を調整する必要があると結論付けています。
ベンチマークのバージョンごとにタスク数や数値が少しずつ異なるため、引用する際はバージョンを併記する必要があります。卓球を直接扱ったVLM判定ベンチマークは今回の調査では見つかりませんでした。
4. 理由その3：リアルタイム性と責任
- 遅延。 Live APIのドキュメントには遅延の測定値が記載されていません（未確認）。パート1の判定許容時間は1.5秒であり、現在のエンジンの判定遅延の中央値は0.16秒です。
- セッション。 音声＋映像のセッションが2分間であれば、試合を1つ観戦している間ずっとセッションを繋ぎ続ける必要があります。
- 説明できるか。 ルールエンジンは「このバウンドがこの側にこの時刻に発生したため、この選手が失点した」とイベントを1つずつ示すことができます。人間が修正する際、どこが間違っていたのかを把握できます。VLMの文章による回答はもっともらしく見えても、どのシーンを根拠にしたのかを確認するのが困難です。
5. それではどこに配置するのか：スロー確認レイヤー
VLMが苦手とするのは「16.7ms以内の順序」であり、得意とするのは「シーン全体の意味」です。ラリーが終了したか、選手が得点を喜ぶジェスチャーをしているか、ボールを拾いに行っているかといった大まかなイベントは、1秒に1枚でも把握可能です。そのため、パート1の4つのレイヤーのうち一番下である スロー確認レイヤーに配置する計画です。
- スコアボードはルールエンジンの判定をそのまま反映します。VLMの完了を待ちません。
- 「要確認」とマークされたラリーのみ、前後の数秒のクリップを非同期でVLMに送信します。
- VLMの回答が審判と異なる場合は 表示するだけ にします。スコアを変更するのは人間です。
コストは小さく抑えられます。ドキュメントの単価で計算すると、10秒のラリー1本を1fpsで再確認するのに約1,300トークン、最も安価なティアで約0.0004ドルとなります（ドキュメント単価からの算出値、未実測）。ただし、映像を外部サービスに送信することになるため、ユーザーの同意とデータ保持の条件を事前に定める必要があります。まだ実際に呼び出したことはなく、研究実験でも呼び出していません（未実測）。
6. まとめ
| 質問 | ルールエンジン | ビジョン言語モデル |
|---|---|---|
| 入力の時間解像度 | 毎フレーム（16.7ms） | デフォルト1秒に1枚 |
| 時刻の表現 | 秒の小数 | MM:SS |
| 判定の根拠 | イベントのリストとして提示 | 文章 |
| 得意なこと | バウンドの順序、サイド、時刻 | シーンの意味、説明 |
| TT Scoreにおける位置 | 1〜3層（判定） | 第4層（スロー確認、計画中） |
ビジョン言語モデルがより高精度な時間分解能を扱えるようになれば、この表は変わるでしょう。そのときにも同じ質問で再び測定すればよいのです。「得点を決める瞬間が入力に含まれているか。」
ティティの一言。 1秒に1回しか目を開けない審判には、ボールがどこに落ちたかなんて見えませんよ。その代わり、試合が終わった後に「このシーン、おかしくない？」と教えてくれるアシスタントとしては役に立つかもしれません。
参考
- Gemini API 映像理解： https://ai.google.dev/gemini-api/docs/video-understanding （2026-10-09更新、2026-10-13閲覧）
- Gemini Live API ガイド： https://ai.google.dev/gemini-api/docs/live-guide （2026-10-13閲覧）
- TennisTV： https://arxiv.org/abs/2509.15602 （v5）
- バウンド間隔の実測：リポジトリ
ttscore/referee.pyのヘッド、events.pyのEND_AFTER_BOUNCE_Sのコメント