モデルの原理と論文：ボール、卓球台、そして私たちが独自に学習した3つのモデル

状態：ドラフト（2026-10-26）、実測反映済み。 「論文」と記載した数値は、元の論文・公式リポジトリを開いて確認した値であり、それ以外の数値は私たちが公開映像と合成画像を用いて独自に測定した値です。スマートフォンによる現場映像の精度は未実測です。論文の書誌のうち、原文を最後まで確認できなかったものについては参考文献にその旨を記載しています。 作成ルール：実測データが基本であり、測定できなかったものは「未実測」と表示します。

目次

• 1. マップ：どのモデルがどこで動作するか
• 2. ボール：座標を当てるのではなくマップを描く
  • なぜ難しいのか
  • 系譜：TrackNet → WASB → BlurBall
  • 私たちの利用方法
  • 実測
  • ファインチューニングを試みた版：無効化した理由
• 3. 卓球台：検出、確認、追跡
  • 検出チェーン
  • 検出した四角形の再確認
  • 追跡：ピラミッドLucas–KanadeとRANSAC
  • 4つの頂点から卓球台の平面へ：ホモグラフィ
• 4. 私たちが学習した3つ
  • ① 偽のバウンドの排除：1万8千パラメータの1D CNN
  • ② 「確認が必要」の補正：19特徴のロジスティック回帰
  • ③ 卓球台の頂点モデル：凍結したエンコーダーと小さなヒートマップヘッド
• 5. 姿勢と音声：入力しなかったシグナル
  • 姿勢（RTMPose）：コーチングのみ
  • 音声：エンジンに入力しない
• 6. まとめ
• 参考文献
• あわせて読みたい

1. マップ：どのモデルがどこで動作するか

自動判定の認識部分は、いくつかのモデルといくつかの古典アルゴリズムの組み合わせです。

この記事では上から順に原理を解説し、論文の考え方と私たちの利用方法を並べて記載します。ボール・卓球台モデルの系譜は前回のシリーズの パート2·パート3により詳しく載せているため、ここでは要点を改めて記載し、 その後に変更された点と 私たちが学習した内容に重点を置きます。

2. ボール：座標を当てるのではなくマップを描く

なぜ難しいのか

卓球のボールは直径40mmです。512×288に縮小した画面ではわずか数ピクセルであり、高速なボールは1フレームの露光時間中に長くブレてぼやけた縞模様になります。ラケットや身体に頻繁に遮られ、白いボールは白い衣服・照明・壁の模様と混同されやすくなります。

系譜：TrackNet → WASB → BlurBall

TrackNet（2019）[3]は2つのアイデアを示しました。1つ目は、ボールの(x, y)を2つの数値で直接予測するのではなく、ボールが存在する可能性の高い場所に丘が盛り上がった ヒートマップ（heatmap）を描かせることです。畳み込みニューラルネットワークは位置ごとに同じ判断を行う構造であるため、空間マップを出力することが構造に適合しており、滑らかな正解データのおかげで学習が安定します。2つ目は、 連続する3フレームをまとめて 入力することです。1枚の画像では白い点がボールなのかゴミなのかわかりませんが、3枚の画像を見れば動いているものがボールであると分かります。

WASB（2023）[2]は、様々な競技に通用する基準線を目標として3つの要素を組み合わせました。解像度を最後まで維持する小型のHRNet系バックボーン[16]、距離に応じて小さくなる実数ヒートマップとquality focal loss、そして等加速度運動モデルによって次の位置を予測し、遠くの候補を排除する推論です。

BlurBall（2025–2026）[1]は私たちのボールモデルです。核心はラベル付けを行う箇所です。従来のデータセットでは、ブレたボールの 前端をボールの位置として記録していましたが、論文ではこれが非対称であり、ブレに含まれる速度情報を捨てていると指摘しています。そのため、ボールの位置を ブレの中心に記録し、ブレの方向（θ）と半分の長さ（l）をラベルとして一緒に付与します。正解ヒートマップも1点ではなく、ブレの両端を結ぶ縞模様全体を覆います。構造はWASBのHRNetバックボーンにチャンネル注意機構（Squeeze-and-Excitation）を追加したものです。

出力されたヒートマップをしきい値（論文では0.7）で切り出して塊（Blob）を作成し、それらのピクセルに対して主成分分析（PCA）を行うと、主軸の方向がブレの角度になり、主軸上の投影範囲の半分がブレの長さになります。信頼度は、塊の値の 平均です。総和を使用すると長いブレが有利になってしまうためです（論文）。ブレベクトルは露出時間中の速度の手がかりであるため、論文では最初の3フレームに2次多項式をフィッティングする際にこれを一緒に加えることで、軌跡予測の平均誤差を84.4pxから53.0pxに減少させたと報告しています（論文）。私たちはまだブレの方向を判定に使用していません。ブレを速度に変換するにはカメラの露出時間を知る必要があるのですが、スマートフォンでは露出がフレームごとに変わる可能性があるためです。

私たちの利用方法

• 重みは5.8MB、入力は512×288フレーム3枚のウィンドウです。リアルタイムの経路では、ウィンドウの 最後 のフレームのヒートマップのみを使用します（未来のフレームを待ち受けるのを避けるため）。
• 著者の重みを ファインチューニングなしで そのまま使用します。読み込む際にsha256を照合し、 weights_only=True としてのみ読み込みます（パート1）。
• 候補が複数ある場合、直前のボール位置から512の画面基準で80px以内の候補の中からスコアが最も高いものを選びます。WASBの「予測から遠い候補の排除」を非常にシンプルに短縮したものです。
• ボール検出の直前に、フレームごとに明るさの0.5%および99.5%の分位点を0〜255に引き伸ばします（TTSCORE_BRIGHTEN、学習なし）。合成された「暗い」条件（明るさ×0.25 + ノイズ）におけるリアルタイム経路そのままのテストでは、7試合中の正解数が34から51に向上し（McNemar p=0.0001）、クリアな映像では53対54で損失は有意ではありませんでした（2026-10-14、園長 E18）。計算時間はノートPCのCPUで中央値1.6msです。実際の暗い卓球場のスマホ映像におけるメリットは未実測です。

実測

公開テストの試合でほぼ完璧である理由の一つは、注意深く読み取る必要があります。BlurBallの学習映像リストが公開されていないため、私たちがテストに使用する公開試合と重複しているかどうかわかりません。そのため、この数値を汎化性能として捉えず、他の研究室や中継映像の数値をあわせて記載しています。

ファインチューニングを試みた版：無効化した理由

複雑な背景や暗い条件に対して頑健にするため、本番の重みを教師とした自己蒸留ファインチューニング版（clutter-v1）を作成しました（園長 E31）。きれいな映像20%、複雑な背景40%、暗さ・低解像度・ブレ・JPEG・手ブレ・30fpsを混ぜ合わせ、ノートPC用GPU（8GB級）の使い捨てポッドで69分間、8,934ステップ学習させました。合成劣化環境におけるボールの再現率は、強い劣化時が0.752 → 0.949、暗い環境が0.685 → 0.924へと向上しました。しかし、実際の経路テストにおいて有効化の条件の一つ（「見逃した誤答が運用版より多くないこと」、10対8）を満たせなかったため、 無効化しました。

3. 卓球台：検出、確認、追跡

ボールが「どちら側に落ちたのか」を知るには、卓球台の4つの頂点が必要です。卓球台に関する処理は3つの段階に分かれます。試合開始前に 一度検出し、検出した四角形が本当に卓球台であるかを 確認し、その後は毎フレーム 追跡します。

検出チェーン

検出は複数のモデルを順番に試行し、失敗した場合は次へ移行するチェーン構造になっています（live/tablemodels.py）。リアルタイムのワーカー設定は sam3 → efficienttam → color ですが、先頭にあるSAM 3は以下の理由により実際には呼び出されないため、 EfficientTAM S → 色ベース として動作します（2026-10-25の運用ワーカーの状態確認、園長 E44）。録画版のワーカーは efficienttam → sam2 → color です。

SAM 2[4]は、映像を1フレームずつ流しながらセグメンテーションを行うモデルです。フレームごとに画像エンコーダーが1回動作し、現在のフレームの特徴が メモリバンク（直近のフレームや、ユーザーが点・ボックスを与えたフレームの特徴）に対してクロスアテンションをかけ、過去にセグメンテーションした物体を記憶しながら現在のフレームを認識します。物体がこのフレームに映っているかどうかを個別に予測するオクルージョンヘッドもあります。私たちの利用法では、「卓球台の位置にいくつか点を打つと、その物体のマスクが出力される」というプロンプトセグメンテーションが核心です。

EfficientTAM[5]はSAM 2を軽量化したモデルです。論文では、SAM 2が重い理由を階層型画像エンコーダーとメモリ モジュールにあると分析し、エンコーダーを階層のない通常のViT（Tiny/Small）に変更し、メモリ内の空間トークンが近隣同士でほぼ同一である性質を利用してキーとバリューを2×2で平均プーリングし、トークン数を1/4に削減しています。論文では、SAM 2（HieraB+）と同等の精度でありながら、A100上で約2倍高速であり、パラメータが約2.4倍少ないと報告しています（論文）。サイズはTiが1,800万、Sが3,400万です。スマートフォンの速度については、論文のアブストラクトと本文の表の数値が一致していないため、ここでは転記しません。

SAM 3[6]は、「table tennis table」のような 短いテキストログの概念に該当する物体をすべて見つけます。「その概念はこの画像にあるか」を個別に判断するpresence tokenにより、「あるか？」と「どこに？」を切り離しているのが特徴です。人間が点を打つ必要がないため、最初のフレームの自動初期化に最も適した原理です。しかし、 私たちはまだ使えません。

• 重みがアクセス承認を受けなければ取得できない方式（ゲート）であり、承認前には取得できません。
• ワーカーのイメージがPython 3.11であるのに対し、SAM 3は3.12以上を要求するため、ロードの段階で失敗して次の行へ進みます。パート1の「イメージをビルドせずにコードを載せる」デプロイ方式が支払う代償です。
• 8億4,800万パラメータと重いです。リアルタイムのループよりも、初期化やラベリングの補助に向いています。
• ライセンス（SAM License）は条文上、商用利用を妨げませんが、ApacheやMITとは異なり、規約の一方的な変更、訴訟時の終了、リバースエンジニアリングの禁止、輸出管理の条件が付いています。商用サービスで使うには法的検討が先決です。

色ベースはGPUがない場合の代替経路です。卓球台の上面の色と白い線で四角形を探します。サーバー側は ttscore/tablefind.py、ブラウザ側にも同じ考え方のコピーがあります。

条件：公開バンドルの検索条件7×103枚＝721枚、同じ後処理、2026-10-13(docs/tt/PERFORMANCE.md 2.12)。そのため、運用の最初の行はEfficientTAM Sです。

見つけた四角形の再確認

分割モデルが「何か」を見つけたからといって、それが卓球台である保証はありません。見つけた四角形を7つの検査で再確認します(ttscore/tablecheck.py、検査名 color・facing・tall·flat・uneven・spill・noline)。上面の色は卓球台らしいか、四角形の向きと高さ・平らさは卓球台らしいか、辺の長さは揃っているか、卓球台からはみ出ていないか、白い線は見えているか、といった項目です。1つでも引っかかると、信頼度を「確実」の閾値0.55未満に下げ、画面はユーザーに「タップしてください」（卓球台を一度タップ）または「直接指定してください」（4つの頂点を直接）を求めます。

追跡：ピラミッドLucas–KanadeとRANSAC

検索は1〜2秒かかる重い処理であるため、毎フレーム実行することはできません。スマホが揺れたり中継カメラが動いたりしても頂点を逃さないように、見つけた後は オプティカルフローで追跡します(live/tablecv.py).

• Lucas–Kanade[9]：「小さな窓の中の明るさは動いてもそのまま」と仮定し、映像の空間勾配から2つの映像のズレを反復して求めます。窓1つに対する小さな最小二乗問題であるため高速です。
• ピラミッド[10]：大きな動きは小さな窓では捉えられないため、映像を複数の段階に縮小したピラミッドの一番上で大まかな移動を求め、下の段階に渡しながら洗練させます。私たちの設定は窓21×21、ピラミッドは元の映像の上に3層までです。
• 良い特徴点[11]：勾配行列の小さな固有値が大きい点（コーナー）が追跡しやすくなります。卓球台の四角形を12%広げた場所（白い線・ネット・コーナー・脚）でまず選び、模様のない上面で点が足りない場合は画面全体から埋めます。手ブレは画面全体が一緒に動くためです。
• 前後往復検査とRANSAC[14]：選手やボールのように別々に動く点は捨てなければなりません。基準→現在に移した点を再び現在→基準に移して1.5pxを超えてズレていれば捨て、残った点でRANSACホモグラフィ（3pxの閾値）を求めます。
• 累積誤差の防止：フレーム同士をつなぎ合わせると誤差が蓄積するため、常に 基準画面から直接 現在のフレームに移します。直前のフレームの結果は初期推定としてのみ与えます。
• カットと再検出：64×36に縮小した画面の差分で画面転換（カット）を検知し、カット後に同じカメラ画面に戻った場合、保存しておいた基準画面（最大4枚）のORB特徴によってモデルなしで即座に合わせます。

密なオプティカルフローであるFarnebäck[12]は画面全体の動きの量を測定する実験にのみ使用し、卓球台の追跡にはスパースなLucas–Kanadeが適切でした。動くのは四角形一つだけであり、毎フレーム処理する必要があるためです。

なぜ追跡がこれほど重要なのかは合成実験が示しています（2026-10-13、台帳E12）。ボールの座標を画面のまま使用すると、カメラがパン・ズームする映像で正解判定が50から24〜40に崩壊し、正解ホモグラフィで平面に戻すと完全に回復しました。さらに興味深い発見は、 正確度よりもブレが判定を台無しにするという点です。フレームごとに個別に推定したホモグラフィはわずか2pxのブレで5〜10ラリーを失いましたが、誤差が時間的に連続する（伝播型）推定は5pxの誤差でも上限と同じでした。バウンド判定は画面yのV字型を見るため、フレーム間のブレが偽のV字を作ってしまうからです。そのため、運用では毎フレームのオプティカルフロー（60Hz）で滑らかに追跡します。

4つの頂点から卓球台の平面へ：ホモグラフィ

平面上の点はカメラ映像から3×3行列Hの1つで変換されます[13]。Hは倍率を除くと8自由度であり、対応点のペアが2つの方程式を与えるため、 4ペアであれば確定します（4つのうち3つが同一線上にあってはならない）。画面の4つの頂点 ↔ 実際の卓球台の4つの頂点（2.74m × 1.525m）でHを作成すると、バウンド瞬間のボールをメートル単位の卓球台座標に変換できます（ttscore/table.py).

2つの落とし穴があります。

• 平面上の点にのみ適合します。 空中のボールは平面上にないため、ボールが卓球台に触れる瞬間のみ使用します。バウンド瞬間、ボールの中心も接触点より半径20mm上にあるため、その分を補正します。
• 4点だけではどちらの辺が長い辺かわかりません。 どのような四角形でも2通りの方法で長方形に変換できます。コードは、人間やデータが端の辺を教えてくれた場合はそれを、そうでない場合は卓球台の2つの半分に1つずつ打った点を、それもない場合は2つの消失点の直交条件から焦点距離を求めて実際の長さの比を計算して決定します。

4. 私たちが学習させた3つ

ここからは著者の重みではなく、私たちが直接学習させたモデルです。3つとも小さく、3つとも「ルールや大きなモデルがすでに行った処理をフィルタリングしたり確認したりする」位置にあります。

① 偽のバウンドのフィルタリング：1.8万パラメータの1D CNN

問題。 パート3の審判は、バウンドが1つ間違えると順番が丸ごと狂ってしまいます。ルールが出したバウンドには、打球をバウンドと読み取ったもの、ネットを越えるボールが揺れたことによる偽物が混ざっています。

モデル。 ボール軌道の短い窓を見る小さな1D畳み込みニューラルネットワークです（ttscore/bounceveto.py）。入力は判定フレームとその前の16フレームの特徴9つ（ボールが見えているか、検出信頼度、ネット基準のx・y、速度、卓球台の上面にあるか、ネット帯の中にあるか、端の外にあるか）であり、3つの畳み込み層の後に小さなMLPがバウンド・打球・ネット通過の確率を出力します。パラメータは18,179個です。

使い方：フィルタリングのみ。 このモデルでバウンドを 新しく作成せず、ルールが出したバウンドのうち±2フレームの確率がすべて0.3未満のものだけを捨てます。この決定は実験から導き出されました。モデル単体でバウンドを検出させると、先読みなし（未来フレーム0）で使う場合に崩壊し（バウンド直後が見えず確率が前方に広がる）、フィルタリングについてはルールがすでに位置を捉えているため先読み0で十分でした（台帳E01）。そのため遅延の追加は0であり、計算はノートPCのCPUで1フレームあたり約0.1msです。

学習。 ボール軌道とバウンド・ネット・打球のマーカーを使用し、60fpsの偶数フレーム＋30fpsのコピー＋座標を15%・30%隠したコピーを混ぜて学習させました。ノートPCのCPUで学習を行いました（2026-10-13、台帳E01・E05）。30fpsのコピーを混ぜた理由は、最初のバージョンが30fpsの入力に対してむしろ6〜11%p崩壊したためです（分布外）。混ぜたバージョンでは30fpsでの損失がなくなりました。以降、学習型モジュールは常に30fpsのコピーを混ぜるというルール（台帳 Ruling R2）がここから生まれました。

実測（リアルタイム経路のまま、公開テスト7試合×劣化11条件、ラリー×条件627、2026-10-13、台帳E08）：

ペア比較で＋4.9%pでした（同じ57ラリーを11条件で再カウントするため独立ではなく、区間は楽観的）。対照群が重要です。クリーンな開発試合では「検出信頼度の低いバウンドを捨てる」が学習フィルタリングと同等のスコアを出しましたが、実際の劣化条件では真逆の結果となり崩壊しました。検出信頼度は暗くなると本物のバウンドでも一緒に低下するためです。 学習フィルタリングの利点は、「信頼度の低いバウンドを捨てること」ではなく、軌道の形状を見ることに由来します。

1つの限界も見つかりました。バウンド付近が隠れてV字が消えると、補間によって埋められた軌道で確率が低く算出され、本物のバウンドが捨てられてしまいました（台帳E11の隠蔽サブセット41 → 38）。そのため、バウンド付近にボールが見えないサンプルがある場合はフィルタリングを休止するようにしました（台帳E17）。

② 「要確認」の補正：19特徴量のロジスティック回帰

パート3で見たように、「信頼度 < 0.6」は不正解を判別できませんでした（AUC 0.51）。判定の瞬間にエンジンがすでに把握している19個の値を用いて 判定が間違っていた確率を出力するロジスティック回帰を学習させました（ttscore/reviewcal.py).

ロジスティック回帰の良い点は2つあります。学習データ（多様な劣化条件で実行した判定）が大きくなくてもよく、結果を人間に説明できる点です。線形モデルは各特徴が「不正解の方向にどれだけ押し出したか」をそのまま読み取ることができるため、チップの理由（「ボールを見失いました」、「長いラリーです」）をその寄与度から直接作成できます。計算は判定ごとに内積が1回です。

学習データは、リアルタイム経路のまま実行した判定と、そのラリーの勝者の正解です。v2では同じ特徴に ラベル修正を加えました。正解ラベルが複数のラリーを1つにまとめている場所で、エンジンの正しい判定が「不正解」として学習されていたためです（台帳R7・R8、E25）。閾値は学習試合単位の5分割交差検証で選定し、v2の閾値は0.0442です。結果はパート3の第5節の表にあります。確認なしの不正解（幽霊を含む）が20から8に減り、要確認が450から497に増えました。

注意すべき点が1つ。補正は ボールモデルが出力した判定分布で学習したものであるため、ボールモデルを変更すれば補正も変更する必要があります。微調整されたボールの重みの上にv2をそのまま残したところ、確認なしの不正解が14から28に増加しました（台帳E31）。そのため、そのペアとしてv3を別途学習させました。

③ 卓球台の頂点モデル：凍結されたエンコーダーと小さなヒートマップヘッド

問題。 2026年10月25日、本番での検出チェーンがどこで失敗するのかを新しい画像35枚（リーグ中継26枚、4Kサークル側面4枚、1934年の古いフィルム2枚、実験室の斜め3枚、すべて商用利用可能な公開映像）で測定したところ、 タップなしで確実＆正解 0/35 でした（台帳E42）。原因を切り分けると、側面・斜めではネットが上面を分断し、分割マスクがほぼ常に 半分になっており、選択スコアが大きい床・壁のマスクが上に押し上げられていました。後処理の調整7つ（グリッドプロンプト、拡張下限、白線閾値、半分の結合、半分チェックなど）をすべて試しましたが、どれも「どこでも悪化せず新しいバッチで改善する」を満たせませんでした。マスク内で四角形をパズル合わせする方式の限界でした。

考察。 マスクを経由せず 頂点を直接 出力させよう。人間の姿勢推定が関節ごとにヒートマップを描くように[15][16][17][18]、卓球台の4つの頂点とネットの2つの端点をヒートマップとして出力させます。

構造。 本番の検出チェーンですでに使用しているEfficientTAM Sの画像エンコーダー（同じ重み、Apache-2.0）を 凍結し、その64×64×256の特徴量の上に畳み込み数層の小さなヘッド（約64万パラメータ）を載せて、128×128のヒートマップを2枚出力させます。1枚は4つの頂点用、もう1枚はネットの2つの端点用です。卓球台は対称であるため、頂点に名前（左上など）を付けず、4つのピークを周囲の順序で読み取ります。損失はσ=4pxのガウス正解に対する重み付きMSEです。

なぜ凍結したのか。 実際の学習画像が12枚しかなかったからです。事前学習済みの特徴量が優れており、学習条件と使用条件が異なる場合、ヘッドがデタラメな初期段階においてバックボーンまで一緒に学習させると事前学習済みの特徴量が歪み、分布外（OOD）性能が低下する可能性があるという分析があります[19]。その論文は主に分類タスクの線形ヘッドを扱うため、我々は原理レベルの根拠としてのみ使用します。実用的な理由もありました。本番環境ですでに同じエンコーダーの重みを持っており、新しく受け取る重みやパッケージがなかったからです。エンコーダーを微チューニングする実験はまだ行っていません。

学習データ：合成80%、実写20%。 商用利用可能なデータのみを使用しました。

• 合成：我々のコードで描画した卓球台（規格2.74×1.525×0.76m、ネット15.25cm）を、ランダムなカメラ（距離2.4〜15m、画角35〜100°、高さ・傾き）、照明、ぼかし、ノイズ、JPEG、モノクロ、床、背景の壁、隣の卓球台、人物ボードとともに描画しました。外部の画像は使用していません。レンダラーが頂点座標を正確に把握しているため、手動でラベルを打つ必要はありません。ネット端のラベルは、ネットが長辺と交わる 卓球台の高さの点（長辺の中央）として定義しました。
• 実写：2015年のスロベニアリーグ中継（Wikimedia Commons, CC BY 3.0）から、 テスト区間と重ならない 12枚。拡大・移動・回転・色変換・左右反転で水増ししました。
• 除外したもの：テストで使用するサークル映像と同じ体育館の別の映像、テストの実験室映像と同じ実験室・カメラの別の映像。ラベルまで作成しましたが、学習には投入しませんでした。投入するとテストが楽観的になってしまいます。非商用データセットはテストにのみ使用しました。

この設計はドメインランダム化[20][21]の考え方に従っています。レンダリングをあえて非現実的なくらい激しく変化させて学習させれば、実際の映像はモデルがみた無数のバリエーションのなかの「ひとつのバリエーション」になるという考え方です。合成のみで学習した後に少量の現実データを足すという流れも[21]が示した方向性です。卓球においては、ボールや卓球台の2D検出は実際のラベルで、2D→3D軌跡は物理的に正しい合成でのみ学習した研究があります[22]。

学習は2,500イテレーション×バッチ12（＝3万枚）、AdamW、シードセットであり、ノートPCのGPU（8GBクラス）で使い捨てのポッドごとに約20分かかりました（5本）。選択なしで最後の重みを使用しました。

デコード：ピークの大きさを信じるな、幾何学を信じよ。 最初のデコード（事前登録：4つの頂点ピークの最小値≧0.5であれば確実）は却下されました。合成で学習したピークの大きさは、実際の画像ではほぼ常に0.5を超えていました。 過信です。頂点のうち3つは合っているが1つがスコアボードやネットの支柱に張り付いている事例が多発しました。

そこで2つ目のデコード（d2）を作成しました（ttscore/tablekp.py）。頂点ヒートマップのピーク上位6つから4つを選んで凸四角形を作り、その四角形だけで ネットの端点が存在すべき場所を計算し、ネットヒートマップのピークと突き合わせます。

1. 四角形の2つの対角線が交わる点は、遠近法においても実際の卓球台の 中心です（射影中心）。
2. 2つの端辺を延長して交わる消失点とその中心を結ぶ線は、遠近法における「ネットが置かれた線」です。
3. その線が2つの長辺と交わる点が、ネットの端点が存在すべき場所です。

ネットと頂点は 別々に出力されたヒートマップであるため、両者が幾何学的に一致するということはピークの大きさとは独立した根拠となります。確実の条件は「ピークの最小値≧0.5、かつネット端の距離≦12px」です。12pxはテストではなく 検証バッチ（合成300枚＋学習から除外した実写4枚）において8・12・16・24の中から選びました。検証用合成での確実＆不正解が54〜68から5〜9に減少しました。

この計算は卓球台平面上の点のみを使用します。ネットの頂点は平面から15.25cm上にあるためホモグラフィに含めてはいけませんが、我々のネット端ラベルは卓球台の高さの点であり、しかも ホモグラフィの計算には含めず、検証と「どの辺が端辺であるか」を決定するためだけに 使用します。ホモグラフィは4つの頂点のみで計算します。

統合：ポリシーD。 頂点モデルは従来の検出を置き換えるのではなく、併用します。

採用条件は結果を見る前に決定し、台帳に記載しました（事前登録）。新しい35枚で確実＆正解が増え、いかなるバッチでも確実＆不正解が増えないこと（シードセットの中央値）。

実測：研究テスト（テスト204枚、確実＆正解 / 確実＆不正解、2026-10-25、台帳E43、 docs/tt/PERFORMANCE.md 2.19):

合成のみで学習したバージョン（同じデコード）は公開バッチでの確実＆正解が多かったものの（+24）、確実＆不正解も増加したため条件を満たせませんでした。実写12枚が過信を抑え込んだ形です。本番コードのまま再実行した結果（シード2の重み、ヘッドのみ2.5MB）は89 / 22であり、1回の検出あたりノートPCのGPUで40ms余分にかかりました。

正直に記載すべき限界が3つあります。

• テストを2回行いました。 d2デコードは最初のテスト結果を見た後に設計しました。閾値は検証で選びましたが、設計自体がテストの影響を受けています。
• メリットが片方に偏っています。 新しい35枚のメリット4件はすべて学習区間と同じ中継の別の区間であり、公開バッチのメリットは側面映像で発生しました。4Kサークル・古いフィルム・実験室の斜めは0のままです。 別の体育館・別の中継への汎化はこのデータでは示されませんでした。
• ラベルが人間の手によるものではありません。 実際の学習12枚と新しいテスト35枚の頂点は、AI作業者が2倍拡大グリッドで読み取り、隠れた遠くの頂点は消失点として計算して打点しました（おおむね±5px）。

実測：本番での有効化後（2026-10-25夜〜10-26未明、台帳E44）。2026-10-25に本番のリアルタイムワーカーで頂点モデルを有効化しました。有効化後、本番ワーカーにテスト画像212枚をカメラのスコアボードと同じJPEG品質70で送信し、212件すべての応答に頂点モデルが稼働したという記録がありました。画面のフロー（タップなしで確実なら終了、そうでなければ1回タップ、それでもダメなら手動で4つの頂点）をそのまま模倣し、正解のある3のバッチ204枚で集計しました。ペアのベースライン（頂点モデルOFF）は本番をオフにできないため、同じコードをノートPCのGPUの使い捨てポッドで同じJPEGを使用して実行しました。

メリットばかりではありませんでした。頂点モデルが新しく作り出した誤った確実が5件あり（最大114px —— 学習区間と同じ中継の別の区間）、解消したものが8件であったため、合計は26から23になりました。撮影条件別27クリップバッチだけに注目すると、確実＆不正解が3から4に1つ増えました。オフにする条件（確実＆不正解がベースラインより増加、またはエラー）には該当しなかったため、 ONのまま維持することにしました。

この比較にはブレが混ざっています。ベースラインは別のGPUで実行したため、従来の検出の確信度が204枚中14枚で本番と異なっていました（GPUの違い）。また、JPEG 70では従来の検出がロスレス画像よりも劣化しており（71/22 → 61/26）、研究テストの数値と直接比較することはできません。実際のブラウザで画面を最後まで操作するテストは実施しておらず、上記の表は画面フローのルールを模倣したものです。

5. 姿勢と音声：取り入れなかったシグナル

姿勢（RTMPose）：コーチングのみ

RTMPose[7]は人物のバウンディングボックスを最初に検出し（RTMDet）、人物ごとに切り抜いて姿勢を推定するトップダウン方式です。ヘッドにはSimCC[8]を使用し、キーポイントの位置をヒートマップではなく x座標分類とy座標分類 の2つの問題に置き換えます。1つの画素を複数のセルに分割することで、低解像度でもサブピクセル精度を得るという考え方です。

TT Labはこのモデルを コーチング画面の精密分析(ttcoach/pose.py）にのみ使用します。スコアエンジンに組み込む実験は2回行い、2回とも却下されました。

• 姿勢でバウンドを除外すると、公開試合12試合のラリー勝者が93.1%から87.6〜92.0%に低下しました（PERFORMANCE 2.9.5）。
• 姿勢を偽のバウンド除外に組み合わせるとオクルージョン区間ではやや改善しましたが、ルールのみを使用した場合を超えることはできず、何よりも姿勢推定にGPUでフレームあたり24.6〜25.0msかかり、新しいモジュールの予算である5msを超過しました（台帳E11）。「リアルタイム不可能」です。

音声：エンジンに不採用

ボールが面に当たる時間は1.3–1.8msと非常に短いため、音声は「いつ」を映像フレームの間隔（30fpsなら33ms）よりもはるかに高精度に伝えてくれます[23]。クリーンな音声データセットでは、私たちの分類器も卓球台やラケットの音を99.3%の精度で判別しました。しかし、実際の練習場の録音ではスコアに対する効果を確認できませんでした（PERFORMANCE 2.7・2.9.6、前回のシリーズ 第6話）。クリーンな音声でのパフォーマンスが、雑音や隣の卓球台の音の前に大きく低下してしまったのです。

そのため、リアルタイムの処理パイプラインでは 音声を受け取りません。 カメラのスコアボードはカメラ起動時にオーディオを要求せず（getUserMedia({audio:false})）、録画データの分析では音声を破棄します。映像・音声・姿勢を統合した卓球の得点判定に関する論文は、今回の調査範囲では見つかりませんでした（検索範囲が狭かったという留保をつけておきます）[24][25]。

6. まとめ

• ボールは「ヒートマップ ＋ 複数フレーム ＋ ブラーの中心」という系譜の終着点である BlurBall を著者の重みそのままに使用しています。学習データが公開されていないため、公開テストの数値をそのまま汎化性能として読み取ることはできません。
• 卓球台はセグメンテーションモデルで一度検出し、7つの方法で再確認し、ピラミッド Lucas–Kanade と RANSAC を用いて毎フレーム追跡します。判定を狂わせるのは頂点誤差よりも フレーム間の揺れでした。
• 私たちが学習させたモデルはどれも小さく、ルールや大規模モデルの結果を フィルタリングしたり確認したりする 位置づけにあります。1.8万パラメータのフィルタ、19特徴量の回帰、64万パラメータのヘッドです。
• 頂点モデルの運用により「ここを指してください」という手間を17%削減できましたが、他の体育館への汎化はまだ確認できていません。他所での商用利用を見据えた実データの検証が次の課題です。

T-Note（一言）。 頂点モデルは最初は自分がすべて正しいと言い張っていました。そこで「ネットの端があるべき場所に本当にネットの端があるか」ともう一度問いかけるようにしたところ、はるかに謙虚になりました。

参考文献

1. T. Gossard, F. Radovic, A. Ziegler, A. Zell. "BlurBall: Joint Ball and Motion Blur Estimation for Table Tennis Ball Tracking." CVPR Workshops (CVsports), 2026. arXiv:2509.18387. コード: MIT.
2. S. Tarashima, M. A. Haq, Y. Wang, N. Tagawa. "Widely Applicable Strong Baseline for Sports Ball Detection and Tracking." BMVC, 2023. arXiv:2311.05237.
3. Y.-C. Huang, I.-N. Liao, C.-H. Chen, T.-U. İk, W.-C. Peng. "TrackNet: A Deep Learning Network for Tracking High-speed and Tiny Objects in Sports Applications." arXiv:1907.03698, 2019.
4. N. Ravi 他. "SAM 2: Segment Anything in Images and Videos." ICLR, 2025. arXiv:2408.00714. コード・チェックポイント: Apache-2.0.
5. Y. Xiong 他. "Efficient Track Anything." ICCV, 2025. arXiv:2411.18933. コード・チェックポイント: Apache-2.0.（学会採択は他論文の参考文献表記で確認、学会の原著ページは未確認）
6. N. Carion, L. Gustafson, Y.-T. Hu 他. "SAM 3: Segment Anything with Concepts." ICLR, 2026. arXiv:2511.16719. SAM License (2025-11-19).
7. T. Jiang, P. Lu, L. Zhang, N. Ma, R. Han, C. Lyu, Y. Li, K. Chen. "RTMPose: Real-Time Multi-Person Pose Estimation based on MMPose." arXiv:2303.07399, 2023.
8. Y. Li, S. Yang, P. Liu, S. Zhang, Y. Wang, Z. Wang, W. Yang, S.-T. Xia. "SimCC: A Simple Coordinate Classification Perspective for Human Pose Estimation." ECCV, 2022. arXiv:2107.03332.
9. B. D. Lucas, T. Kanade. "An Iterative Image Registration Technique with an Application to Stereo Vision." IJCAI, 1981, pp. 674–679.
10. J.-Y. Bouguet. "Pyramidal Implementation of the Lucas Kanade Feature Tracker: Description of the Algorithm." Intel Corporation, Microprocessor Research Labs, 2000.（本文は閲覧できず、書誌情報と OpenCV の引用までを確認）
11. J. Shi, C. Tomasi. "Good Features to Track." CVPR, 1994, pp. 593–600.
12. G. Farnebäck. "Two-Frame Motion Estimation Based on Polynomial Expansion." SCIA, 2003, LNCS 2749, pp. 363–370.
13. R. Hartley, A. Zisserman. Multiple View Geometry in Computer Vision, 2nd ed. Cambridge University Press, 2004. 第2章・第4章。
14. M. A. Fischler, R. C. Bolles. "Random Sample Consensus: A Paradigm for Model Fitting with Applications to Image Analysis and Automated Cartography." Communications of the ACM 24(6):381–395, 1981.
15. A. Newell, K. Yang, J. Deng. "Stacked Hourglass Networks for Human Pose Estimation." ECCV, 2016. arXiv:1603.06937.
16. K. Sun, B. Xiao, D. Liu, J. Wang. "Deep High-Resolution Representation Learning for Human Pose Estimation." CVPR, 2019. arXiv:1902.09212.
17. X. Zhou, D. Wang, P. Krähenbühl. "Objects as Points." arXiv:1904.07850, 2019.
18. J. Tompson, A. Jain, Y. LeCun, C. Bregler. "Joint Training of a Convolutional Network and a Graphical Model for Human Pose Estimation." arXiv:1406.2984, 2014.
19. A. Kumar, A. Raghunathan, R. Jones, T. Ma, P. Liang. "Fine-Tuning can Distort Pretrained Features and Underperform Out-of-Distribution." ICLR, 2022. arXiv:2202.10054. 原理レベルでのみ引用。
20. J. Tobin, R. Fong, A. Ray, J. Schneider, W. Zaremba, P. Abbeel. "Domain Randomization for Transferring Deep Neural Networks from Simulation to the Real World." IROS, 2017. arXiv:1703.06907.
21. J. Tremblay 他。「Training Deep Networks with Synthetic Data: Bridging the Reality Gap by Domain Randomization」CVPR Workshops, 2018. arXiv:1804.06516.
22. D. Kienzle, K. Ludwig, J. Lorenz, S. Satoh, R. Lienhart. "Uplifting Table Tennis: A Robust, Real-World Application for 3D Trajectory and Spin Estimation." arXiv:2511.20250, 2025.
23. T. Gossard, J. Schmalzl, A. Ziegler, A. Zell. "Sound-Based Spin Estimation in Table Tennis: Dataset and Real-Time Classification Pipeline." IEEE STAR, 2025. arXiv:2409.11760.
24. S. Tsuji 他。「Audio-Visual Self-Supervision for Frame-Level Player-wise Offensive Shot Detection in Table Tennis Matches」MMSports '24, 2024. doi:10.1145/3689061.3689064. （書誌は検索要約でのみ確認）
25. X. Zhou, Q. Huang, L. Xie, S. Cox. "Detection of Ball Hits in a Tennis Game using Audio and Visual Information." APSIPA ASC, 2012.
26. 我々の測定：リポジトリ docs/tt/PERFORMANCE.md 2.1・2.8・2.12・2.19、研究台帳 E01・E05・E08・E11・E12・E17・E18・E25・E31・E42・E43・E44。コード live/blurball.py·tablecv.py·tablemodels.py, ttscore/table.py·tablekp.py·bounceveto.py·reviewcal.py.

あわせて読みたい

• 前シリーズ TT Scoreモデル解剖 第2部：ボールの検出, 第3部：卓球台の検出.
• ビジョンモデルを読む 第1部・第3部：U-Net と HRNet, 第10部：SAM 2 と EfficientTAM, 第11部：SAM 3.
• ビジョンモデルを読む 第2部・第5部：オプティカルフロー, 第7部：ポーズヒートマップ, 第9部：ボール追跡.
• 本シリーズ 第5部：データ・ライセンス・学習プロセス：学習がどこでどのように動くのか、商用サービスに合わせた学習データの原則。