姿勢とラケット：RTMPoseのSimCC、MediaPipeの2段階、RacketVisionのラケット5点

ステータス：草稿（2026-10-13）、一部の実測を反映。 姿勢実験（2026-10-11〜12）とコーチング画面の速度は直接測定した値です。RacketVisionはデータのみをカウントし、モデルの実行は行っていません（未実測）。論文の数値は「論文」と表記しています。 作成ルール：実測データを基本とし、測定できなかったものは「未実測」と表記します。

目次

• 1. なぜ人とラケットを見ようとするのか
• 2. RTMPose：座標を2つの1D分類に
  • トップダウン（Top-down）
  • SimCC：2Dヒートマップの代わりに1Dベクトルを2つ使用
  • 数値
• 3. MediaPipe Pose：検出と追跡を分離する
• 4. RacketVision：ラケットを5点で表現する
  • 卓球部分を直接カウントしてみた（2026-10-13）
• 5. 実際に使用した箇所とその結果
  • スコアエンジン：削除するとマイナス、表示するだけならプラス（2026-10-11〜12）
  • 姿勢コーチング：ブラウザはMediaPipe、サーバーはRTMPose
• 6. まとめ：何をどこに使うか
• 参考

1. なぜ人とラケットを見ようとするのか

第5部で詳しく見ていきますが、現在のエンジンが間違える最大の理由は イベント抽出です。その中でも「テーブル上でラケットに当たった球をバウンドと読み間違える」ミスが多くありました。ボールの軌跡だけを見ると、どちらも画面上で「下りてから上がる」V字を描きます。エンジンは「バウンドは水平方向を維持し、打球は方向を反転させる」というルールで大部分を排除しますが、すべてを取り除くことはできません。

人間はこの2つを簡単に区別します。ボールの横にラケットがあり、手首が振られていれば打球です。そのため、姿勢（人間の関節座標）とラケットの位置を補助シグナルとして取り入れようとしています。用途は3つあります。

そして、スコアとは別に、TT Labの 姿勢コーチング 画面が同じモデルを使用しています。

2. RTMPose：座標を2つの1D分類に

トップダウン（Top-down）

RTMPose（arXiv 2303.07399, MMPose, Apache-2.0）は2段階の構成です。まず人検出器（RTMDet）が人物のバウンディングボックスを検出し、そのボックスを切り抜いてキーポイントモデルが17個の関節を検出します。画面の片隅に小さく写っている人物であっても、ボックスを切り抜いて拡大するため、関節がはっきりと捉えられます。練習動画のように腕の動きが速く、人物が小さく写っている動画に強みを発揮します。

SimCC：2Dヒートマップの代わりに1Dベクトルを2つ使用

第2部でのボール検出では2Dヒートマップを描画しました。17個の関節ごとに2Dマップを描画すると計算量が多くなり、マップの解像度がそのまま位置の解像度になります。精度を高めるにはマップを大きくする必要があり、その分コストがかかります。

SimCC（arXiv 2107.03332）はアプローチを変更します。「この関節のx座標はどのビン（セル）か」、「y座標はどのビンか」を それぞれ分類問題として解きます。関節ごとに長さ $W \cdot k$ と $H \cdot k$ の1Dベクトルを2つ出力し、それぞれのベクトルから最も確率の高いビンを選択します。$k$ は1ピクセルをいくつに分割するかを表し（MMPoseの simcc_split_ratio、デフォルトは2.0）、$k = 2$ の場合はサブピクセル解像度が得られます。2Dマップを大きくしなくても、ピクセル単位より高精度な位置が得られる仕組みです。第2部のTTNetがボールの位置をx・yの2つの1Dベクトルとして出力したのと同じ発想です。

デコードは非常にシンプルです。

# open-mmlab/mmpose mmpose/codecs/utils/post_processing.py get_simcc_maximum() 에서(Apache-2.0)
x_locs = np.argmax(simcc_x, axis=1)
y_locs = np.argmax(simcc_y, axis=1)
locs = np.stack((x_locs, y_locs), axis=-1).astype(np.float32)
max_val_x = np.amax(simcc_x, axis=1)
max_val_y = np.amax(simcc_y, axis=1)
mask = max_val_x > max_val_y
max_val_x[mask] = max_val_y[mask]          # 신뢰도 = 두 축 최댓값 중 작은 쪽
vals = max_val_x
locs[vals <= 0.] = -1

その次に keypoints /= simcc_split_ratio でビンの番号をピクセルに戻します。信頼度を2つの軸のうち 小さい方に設定することが注目すべき点です。xは確実だがyが曖昧な場合、その関節は曖昧であると判断されます。

数値

RTMPose-mは1,359万パラメータ、1.93 GFLOPs、COCO AP 74.9です。遅延はデスクトップCPU（ONNX Runtime）で11.06ms、デスクトップ向けGPU（TensorRT FP16）で2.29msです（公式README、256×192入力）。論文抄録の75.8 APは学習データが異なるバージョンの値であるため、どのバージョンを指しているかを確認して引用する必要があります。

3. MediaPipe Pose：検出と追跡を分離する

MediaPipe Pose Landmarker（BlazePose, arXiv 2006.10204, コード Apache-2.0）は、モバイルブラウザでの動作を目標として開発されたモデルです。そのコンセプトは以下の通りです。

1. 検出（detector）：初回、または人物を見失ったときのみ実行されます。顔検出器を人検出の代用として使用し、骨盤の中心と体を囲む円の半径・傾きを同時に予測して人物の位置を特定します。
2. 追跡（tracker）：毎フレーム実行されます。33個の関節と「人物がまだ存在するか」、および 次のフレームで探索する領域を同時に予測します。人物が存在しないと判断された場合は、次のフレームで検出を再度実行します。

重い検出処理を毎フレーム実行しないことが、高速化の秘訣です。画面座標のほかに、 骨盤を原点としたメートル単位の3D座標（world landmarks）も出力されます。

ライセンスに関する注意：コードはApache-2.0ですが、モデルファイルには別途モデルカードが添付されています。そのカードの利用条件については、現時点で確認できていません（未確認）。

4. RacketVision：ラケットを5点で表現する

RacketVision（arXiv 2511.17045, AAAI 2026, コード・データカード MIT）は、卓球・テニス・バドミントンの中継映像におけるボールの位置と ラケットのバウンディングボックス＋5点をアノテーションしたデータセットおよび基準モデルです。5点は、上（top）・下（bottom）・ハンドル（handle）・左（left）・右（right）です。上・下・左・右の4点がラケット面の輪郭を定め、ハンドルが向きを決定します。面が見える角度と向きがわかれば、「ボールがラケット面の近くにあるか」を判定することができます。

卓球部分を直接カウントしてみた（2026-10-13）

ダウンロードした卓球部分のアノテーションファイルを読み取り専用でカウントしました（元データとスクリプトは第7部を参照）。

5点と言われているものの、実際には 4点しか見えないラケットが大部分です。中継の視点では、ラケットの下端が手に隠れたり、面に重なったりするためだと考えられます。論文でも、左・右の点の精度（PCK@0.2 約65〜80%）が、上・下のような構造的な点（92%超）よりも低いと報告されています。1080pにおいてラケットボックスが一辺約43px程度であるため、スマートフォンの側面からの映像ですべての5点を見つけることはさらに難しくなると推測されます。

論文のもう一つの結果が設計において重要です。ボールの次の軌跡を予測する際、ラケットの特徴を 単純に結合すると、ボールのみを使用する場合よりも性能が低下し、クロスアテンションで統合して初めて性能が向上しました（卓球、過去80フレーム → 未来20フレーム、ADE/FDE 113.9/184.3 → 101.3/161.3px、論文）。シグナルを追加したからといって自動的に良くなるわけではないという、以下の我々の実測値と同じ結論です。

5. 実際に使用した箇所とその結果

スコアエンジン：削除するとマイナス、表示するだけならプラス（2026-10-11〜12）

人検出器（RTMDet）のONNXファイルは、グラフ内のNMS演算をOpenCV DNNが読み込めず、実験イメージにONNX Runtimeも含まれていませんでした。そのため、人物のバウンディングボックスの代わりに ボールを中心とした 540×720 のボックスをRTMPose-mに入力し、「ボールの近くに手首があるか」のみを判定させました。CPU（OpenCV DNN）で1ボックスあたり74ms（他の処理と共有しているCPUの中央値）かかったため、エンジンが生成したバウンド候補の2,499フレームに対してのみ実行しました。

まず学習用5試合において、手首でボールを区別できるかを検証しました。バウンド候補1,982個の内訳は、正解バウンド1,481個、打球をバウンドと読み間違えた誤検出27個、その他の誤検出474個でした。「手首スコア0.5以上、手首とボールの距離60px以内」の条件で削除すると、正解10個、打球の誤検出5個、その他の誤検出24個が削除されました。 正解と誤検出をほとんど区別できませんでした。 エンジンがすでに大部分の打球の誤検出を排除しており、残りがわずか27個しかなかったことも原因の一つです。

実際の第12部・275ラリーの結果です。

結論はシンプルに2行です。現在の水準の姿勢シグナルでバウンドを 削除するとマイナスになります。判定を変更せず、 人間に再確認を促す表示のみ を行うと、確認なしの誤判定4件を人間の確認対象に引き上げることができます。その代わり、確認必要の割合が17%p増加します。そのため、エンジンでは「姿勢によってバウンドを削除しない（確認必要とするのみ）」というルールを採用しました。人検出器を適切に組み込んだバージョンは未実測です。

姿勢コーチング：ブラウザはMediaPipe、サーバーはRTMPose

6. まとめ：何をどこに使うか

ボール、姿勢、ラケットを一度に受け取り「誰がいつ打ったか」を出力するモデルは卓球分野でも登場しています（例：ボール・卓球台・上体のキーポイントからラケット接触時刻を出力するEventNet、arXiv:2610.08286、中継データLATTE-MVで±3フレームF1 91.16、論文）。このようなモデルを私たちの側面映像で検証することが次の実験候補です（進行中）。

TTの一言。 手首がボールの横にあるからといって、すぐに「打撃！」と叫んではいけません。そんな時は「一度確認してください」とお願いすることが、スコアを守る道でした。

参考

• RTMPose: https://arxiv.org/abs/2303.07399, https://github.com/open-mmlab/mmpose （Apache-2.0）
• SimCC: https://arxiv.org/abs/2107.03332
• BlazePose: https://arxiv.org/abs/2006.10204、MediaPipe Pose Landmarker https://developers.google.com/edge/mediapipe/solutions/vision/pose_landmarker
• RacketVision: https://arxiv.org/abs/2511.17045, https://github.com/OrcustD/RacketVision （MIT）
• EventNet: https://arxiv.org/abs/2610.08286
• 私たちの測定：リポジトリ docs/tt/PERFORMANCE.md 2.9.5、姿勢コーチング設計ドキュメント第9節、 docs/experiments/2026-10-13-tt-dataset-stats/