ステータス:ドラフト(2026-10-26)、実測値を反映。 データ規模は我々が直接数えた数値であり、ライセンスは各データ・リポジトリの公式ページおよびLICENSEファイルに記載されている文言のみを確認しています。 この記事は法的判断ではありません。 「商用利用可能」は記載された文言に基づくものであり、商用サービスにおける最終的な判断には法的レビューが必要です。 作成ルール:実測データを基本とし、測定できなかったものは「未測定」、根拠を見つけられなかったものは「確認できず」と表示します。
データ・ライセンス・学習プロセス
目次
- 1. なぜこの記事が個別にあるのか
- 2. データセット一覧表
- 3. 学習は実際にどこでどのように回っているのか
- 4. 実験ルール:数値を信用できるようにするため
- 5. 現在の実測数値を一目で
- 6. 商用サービスへの道のり:方針と原則
- 7. まとめ
- 参考文献
- あわせて読みたい
1. なぜこの記事が個別にあるのか
モデルの話は通常、構造と精度で終わります。しかし実際のサービスでは、常に2つの疑問がついて回ります。
- この数値は何で測定したのか? 同じモデルであっても、どのようなデータで、どのようなルールで測定したかによって数値は大きく異なります。
- このモデルを使ってもよいのか? 学習に使用したデータのライセンスがモデルにそのまま引き継がれます。
TT Labは2026年10月18日に商用サービスへと舵を切り、それ以降、2つ目の疑問がすべてのモデルにおける最初の疑問となりました。この記事の最後のセクションでは、その方針と原則、計画について説明します。
2. データセット一覧表
| データ | 出典 | ライセンス | 商用利用 | 我々の用途 | 規模(直接カウント) |
|---|---|---|---|---|---|
| OpenTTGames | 公開卓球データセット(TTNet論文[1]とともに公開) | CC BY-NC-SA 4.0 | 不可 | 研究・評価の土台(固定分割) | 12本、644,199フレーム、89.5分、1920×1080・120fps、音声なし。ボールマーカー52,987フレーム(8.2%)、イベント4,271個 |
| Extended OpenTTGames | 上記データの拡張ラベル(arXiv:2512.19327) | CC BY-NC-SA 4.0 | 不可 | ラリー勝者・原因の正解、打球ラベル(研究・評価) | ラリー終了281(サーバーが分かる275個を使用)、打球1,456 |
| T3Set | 公開トレーニング映像データセット(KDD 2025) | CC BY-NC-SA 4.0 | 不可 | 他条件への汎化評価(ボールの正解なし、目視検査)、音声実験、コーチング基準値 | 選手32名、ラウンド387、映像734本、26.9GB、1080p 60fps、音声あり |
| TT Sounds | 卓球の衝突音データセット[2] | CC BY-NC 4.0 | 不可 | 音声分類実験のみ。エンジンには不使用 | 15msの断片6,037個、ラベル5,702(ラケット3,396・卓球台777・床290・その他1,239)、元録音149件 |
| 実験室卓球映像(OpenNeuro ds004505) | 公開神経科学実験データ | CC0 1.0 | 可能 | デモ1本、卓球台検出テスト(実験室の対角3枚)。テストと同じ実験室のため頂点学習から除外 | 確認できず |
| 2015スロベニアリーグ中継 | Wikimedia Commons | CC BY 3.0 | 可能(出典表記) | 頂点モデル 学習 12枚(テストと重複しない区間)、卓球台検出テスト26枚、最初の画面デモ | 1080p 25fps、24.7分 |
| 4K同好会試合 | Wikimedia Commons | CC BY 3.0 | 可能(出典表記) | 同好会デモ、卓球台検出テスト(側面4枚)。同じ体育館の映像は頂点学習から除外 | 確認できず |
| 1934年卓球ニュースフィルム | Wikimedia Commons | パブリックドメイン | 可能 | 古いフィルムのデモ、卓球台検出テスト2枚 | 確認できず |
| スマホの縦長試合映像 | Wikimedia Commons | CC BY-SA 4.0 | 可能(同一ライセンスで) | 縦長スマホのデモ、条件別テストの1クリップ | 1080×1920、26.08fps |
| 合成卓球台の画像 | 自社コード(外部画像なし) | 自社 | 可能 | 頂点モデル学習の80% | ランダムカメラ・照明・床・背景・隣の卓球台・人物、2500回繰り返し × バッチ12 = 3万枚 |
合成ラリー(ttscore/sim/) |
自社コード | 自社 | 可能 | エンジン合成テスト(正解は別途記述したコードで生成) | 物理1ms積分、ラリー7タイプ、カメラ12プリセット |
| 研究室の3試合(TT3D) | 研究公開データ | 確認できず | 確認できず | 汎化評価のみ | 正解フレーム49,516 |
| 国際中継の自動追跡(LATTE-MV) | 研究公開データ | カードはApache-2.0、元の中継映像の権利は不明 | 不明 | 汎化評価のみ(正解が人のラベルではない) | 812試合、23,781クリップ、640×360・30fps |
| ラケットキーポイント(RacketVision卓球部分) | 研究公開データ | 注釈はMIT、映像の権利は不明 → 内部専用 | 不明 | スコアグラフィック読み取り実験(内部) | 780クリップ、170,027フレーム |
一部の事項は表だけでは分かりません。
- 非商用データが評価の土台となっています。 ボール位置・バウンド・ラリー勝者のラベルが揃った公開卓球データはそのほとんどが非商用ライセンスであり、これまでのほぼ全ての精度数値はその上で測定された評価です。
- 商用利用可能な実際の学習データはまだ少ない状況です。 現在は2015年のリーグ中継の1つから、テストと重複しない12枚を頂点の学習に使用しました。第4部で見た「別体育館への汎化が確認できなかった」という限界はここに起因します。
- 同じ場所の映像は学習から除外しました。 テスト画像と同じ体育館・同じ実験室の別の映像は、ラベルまで作成したものの学習には投入しませんでした。投入するとテスト結果が楽観的になってしまうためです。
- データセットごとの落とし穴(イベント付近にしかラベルがない、複数のラリーが1つにまとめられたラベルなど)については、前シリーズの 第7部に詳しく記載されています。
保管
オリジナルは受け取ったままNASに保存し、変更を加えないようにしています。作業用コピーはGPUサーバーのボリュームに15個の束、約89GB分が存在します(OpenTTGames 33GB、T3Set 26GB、国際中継20.7GBなど)。ノートPCのGPU側には個別のボリュームを置かず、NASを読み込み専用でマウントして読み取ります。研究の成果物(推論結果、ヒートマップ、学習済み重み)もNAS上の専用フォルダに保管しています。ダウンロード記録には同じ場所のサイズが132GBと記載されており、数値が一致していません(どちらが現在の数値であるかは確認できず)。
3. 学習は実際にどこでどのように回っているのか
「学習」というと大規模なGPUクラスターを連想しがちですが、スコアエンジンの学習の大部分は非常に小規模なものです。
| モデル | 学習した場所 | 所要時間・規模 | 運用 |
|---|---|---|---|
| 偽バウンドのフィルタリング(1D CNN、1.8万) | ノートPCのCPU | 20エポック、バッチ2048、シード5個 | オン |
| 「確認必要」補正(ロジスティック回帰、19特徴量) | ノートPCのCPU | 学習試合5本 × 劣化条件での判定、試合単位の5分割交差検証 | オン(v2) |
| 学習型「ラリー終了」(遅延削減) | ノートPCのCPU | — | 棄却(原則 E10) |
| ファインチューニング済みボールモデル(clutter-v1) | ノートPCのGPU(8GBクラス)、使い捨てPod | 8,934ステップ、69分 | オフ |
| 卓球台頂点モデル(ヘッド64万) | ノートPCのGPU(8GBクラス)、使い捨てPodのセット | 各2,500回繰り返し × バッチ12、約20分 | オン(2026-10-25) |
抽出と推論(公開映像全体に対するボールモデルの実行、ポーズ抽出など)は、GPUサーバーまたはノートPCのGPUにあるCPU・GPU Pod上で実行しました。
使い捨てPodという方式
ノートPCのGPU上での学習は、Kubernetes上の 使い捨てPodで実行します。学習コードと入力を格納したPodをそのノードに固定して立ち上げ、終了したら削除します(--rm)。このようにしている理由は、実際に経験したトラブルにあります。
- ノードを固定しないと思わぬところで実行される。 重いビルド作業が固定なしでメモリの小さいノードに割り振られ、同じノード上の他のサービスまでダウンさせてしまったことがありました。そのため、学習Podは常にノードを固定し、立ち上げる前にそのノードの空きメモリとGPU割り当てを確認した上で、メモリリクエスト・制限を記述しています(頂点学習の場合はリクエスト3Gi・制限5Gi、起動前の空き容量6–8GiBを確認)。
- 終了後に残さない。 PodがGPUを掴んだまま残ると、運用担当者がGPUを使用できなくなります。学習が終了したら「残存Pod数0」を確認します。
- 権限を与えない。 使い捨てPodであっても、サービスアカウントトークンなしで、NASは読み込み専用でマウントします。
GPUドライバー側の問題でGPU Podが完全に起動しなかった日もありました。小規模な実験室レベルのGPUを使用する際は、学習コードよりも 環境が正常であるかをまず確認する習慣が必要です。
Kubeflowはインストールされているが、スコアエンジンにはまだ
2026年10月18日にKubeflow Trainer(v2.3.0、JobSet v0.12.0)をGitOpsでインストールし、正常な同期を確認しました。学習専用のゾーンも作成しました。そのゾーンの制限は以下の通りです。
- Podは非root、すべてのcapabilitiesを除外、特権昇格の禁止(Pod Security
restricted). - GPUを確保する場合はノートPCのGPUノードのみ、イメージは内部レジストリのみ、サービスアカウントトークンなし。
- GPU 1枚、メモリ制限の合計6Gi、Podは最大4つまで。
- インバウンドおよびアウトバウンドのネットワークなし(pipもインターネットにアクセス不可)。必要なものは共有ボリューム(NAS、200Gi)に事前に配置します。
しかし、このTrainJobで実行した学習は、これまでに 卓球ロボットアームの強化学習と演技テストのみです。 スコアエンジンモデル(ボール・フィルタリング・補正・頂点)をTrainJobで学習した実績はありません。 その理由は運用ドキュメントに記載されています。ボールモデルのファインチューニングに必要なデータと大規模なGPUはGPUサーバーに存在しますが、学習ゾーンのGPUはノートPCのGPUノードに固定されているため、ルールが一致しません。データを移行するかルールを変更する決定が先決です。パイプライン(KFP 2.16.1)やハイパーパラメータ探索(Katib v0.19.0)もインストールファイルは存在しますが、インストール直後の同期エラーに対処した記録以降の現在の状態は確認できず、卓球モデルに使用した実績は見つかりませんでした。
正直に言うと、現在の規模ではこれが大きな問題ではありません。フィルタリングと補正はノートPCのCPUで数分で終わり、頂点モデルも20分です。学習プラットフォームが必要になるのは、ボールモデルを最初からもう一度学習し直さなければならない時(第6節)です。
4. 実験のルール:数字を信頼できるようにする
学習よりも時間がかかるのは 公平に測定することです。研究ノートの冒頭に、すべての実験に適用するルールを書き留めておきました(2026-10-13)。
固定分割
| 名前 | 試合 | サーバーがわかるラリー | 用途 |
|---|---|---|---|
| dev_train | 公開学習試合3本 | 140 | 研究用の学習型候補の作成 |
| dev_val | 公開学習試合2本 | 78 | ハイパーパラメータ・しきい値・組み合わせの選択はここでだけ行う |
| test | 公開テスト試合7本 | 57 | 実験ごとに 最後に1回だけ使用する。劣化条件の表もここにある |
| all12 | 上記すべて | 275 | 過去の記録と比較する場合のみ |
この分割は研究用です。商用サービスの学習データは第6節の原則に従います。
データ漏洩(リーク)の警告を記載する
ルールエンジンは2026-10-11〜12に公開試合12本すべて(テスト7試合を含む)を確認しながらブラッシュアップされました。そのため、 ルールベースラインのテストスコアは標本内(in-sample)であり、楽観的です。新しい学習型の手法はテスト試合を見たことがないため、比較は新しい手法にとって不利に傾きます。この警告をノートの冒頭に記載し、比較を行うつたびに併記します。また、ボールモデルの学習動画リストが公開されていないため、テスト試合と重複しているかどうかわかりません。そのため、ボール検出の品質を汎用性能として読み取りません。
主要指標は1つ、ペアワイズ比較、シードの中央値
- 主要指標はラリー勝者正解率の1つに固定しました。補助指標(確認なしで不正解、確認必要、判定なし、バウンスF1、フレームあたりのms、判定遅延)は併記しますが、主要指標を変更することはありません。複数の指標の中から良さそうなものを選ぶという事態を防ぐためです。
- 同じラリーの ペアワイズ比較として確認します。McNemarの正確検定とペアワイズ・ブートストラップ95%区間(1万回)を用います。同じラリーを複数の劣化条件で再カウントすると独立ではないため、その場合の区間は楽観的であると記載します。
- 学習型モデルは シード3〜5個の中央値と範囲を記載します。頂点モデルで見てきたように、1つのシードでは1つのバンドル内で「確信&正解」が1〜2増えることもありました。
結果を見る前に判定ルールを記載する
いくつかの実験(要確認補正v3、エンドライン帯、カメラのスコアボード最初から最後まで、頂点モデル)は、 結果を見る前に 採用条件をノートに記載しました(事前登録)。例えば頂点モデルは「新しい35枚の画像において確信&正解が増え、どのバンドルでも確信&不正解が増えないこと、3つのシードの中央値で」というものでした。それでも守れなかった項目があれば隠さずに記載します。頂点モデルは1回目のデコードのテスト結果を見た後に2回目のデコードを設計してテストを2回行い、ノートと第4報にそのまま記載しました。
リアルタイムの予算
- 因果処理:判断時点より後ろのフレームは短い未来予測(デフォルトで200ms以下)までしか見ません。ラリー全体を見た後に判断する方法は「録画トラック」として別途記載し、混ぜ合わせません。
- フレーム予算:60fpsの場合は1フレームあたり16.7ms。新しいモジュールの合計は1フレームあたり5ms以下。
- 判定遅延:ラリー終了 → スコア表示まで1.5秒以下。
- 予算を超える手法は、精度が高くても「リアルタイム不可」に分類します。姿勢結合(1フレームあたり約25ms)はそのようにして却下されました。
失敗から生まれたルール(Ruling)
- R1. 座標レベルの合成オクルージョンは実際のオクルージョンの代わりにはならない。 ボール座標の点を消去するやり方でオクルージョンを模倣した開発実験のメリットは、実際の映像の劣化(映像にオクルージョン用の楕円を描画する)には引き継がれませんでした。実際のオクルージョンでは検出が消えるというよりも、おかしな場所に飛んでしまうためです。
- R2. 学習型モジュールは30fpsのコピーを混ぜて学習する。 60fpsだけで学習したフィルタリングが30fpsで破綻したためです(第4報)。
- R7・R8. ラベルの修正。 データセットのラベルが複数のラリーを1つにまとめていた箇所を見つけて分割し、その修正が補正v2のベースとなりました。
コードライセンスの原則
GPL、AGPL、MPLのコードは持ち込まず、手法のみを新しく実装します。モデルごとに学習データを重みメタデータ(nc_sources)とノートに記載します。この記録が、商用移行の際に何を再学習すべきかを切り分ける基礎となります(第6節)。
5. 現在の実測値一覧
| 項目 | 条件 | 値 | 根拠 |
|---|---|---|---|
| ボールの適合率 / 再現率 | 公開テスト7試合、60fps、512×288 半径5px、2026-10-11 | 0.9817 / 0.9785 | PERFORMANCE 2.1 |
| ラリー勝者(オフライン、ラリー単位) | 公開12本 275ラリー、分割モデル頂点 | 93.8% (258) | PERFORMANCE 2.10 |
| ラリー勝者(デプロイ実時間パス) | 同じ275ラリー、データセットマスク頂点、2026-10-13 | 90.2% (248) | ノート E00 |
| 運用フロー固定基準表 | テスト7試合×劣化11条件、ラベル638、2026-10-16 | 正解508、確認なし不正解8、要確認497、ゴースト51 | ノート E25・E27 |
| 劣化12条件ラリー単位 | 運用ボールモデル + 補正v2 | 587/696 (84%) | ノート E33 |
| 同条件、微調整済みボールモデル | clutter-v1 + 補正v3(オフ) | 610/696 (88%) | ノート E33 |
| カメラのスコアボード最初から最後まで | テスト7試合851秒、偽カメラ30fps、ラベル58、2026-10-17 | 正解47、確認なし不正解0、要確認53/65 | ノート E35 |
| 卓球台の検出(運用、頂点オン) | テスト204枚 JPEG 70、2026-10-25〜26 | クロップなし確信&正解84、確信&不正解23 | ノート E44 |
| 判定遅延 | テスト7試合クリア | p90 1.31秒 | ノート E00・E07 |
| スマホで撮影した実際の卓球場 | — | 未実測(ラベル付きスマホ動画0本) | — |
最後の行が最も重要です。ここまでの数値はすべて 公開映像から得られたものです。固定カメラで綺麗に撮影された研究用映像、中継映像、合成された劣化データです。ユーザーが実際に使用する「地元の卓球場で三脚に固定したスマホ」での数値はまだありません。その数値を得るためにはラベル付けされた自社撮影の映像が必要であり、それが次の節の課題にもつながります。
6. 商用サービスへの道のり:方向性と原則
TT Labは2026-10-18に商用サービスへの方向性を定め、それに合わせて 学習データと重みを商用利用が許可されたものに置き換えています。 ここではその方向性と原則、計画のみを記載します。すべての判断はデータとリポジトリに記載されている文言を基準としており、法律の専門家によるレビューの代わりになるものではありません。
原則
- 運用モデルは商用利用が許可されたデータで学習する。 使用できる素材は4つです。自社撮影・自社ラベリング映像、自社コードで作成した合成データ(卓球台の描画、合成ラリー軌跡)、CC BY・CC0・パブリックドメインのような商用利用を許可する公開映像、および学習利用に同意したユーザーが修正した判定(第6報)です。
- 非商用(NC)データセットは内部の研究・評価にのみ使用する。 上記データセット表の非商用データはエンジンの研究と測定にのみ使用し、商用サービスの学習データとしては使用しません。評価における用途についても法的レビューの対象とします(下記)。
- 公開物は商用利用可能な原典から作成する。 サイトのデモ映像は、商用移行に合わせて商用利用可能な原典から新しく作成しました(2026-10-24〜25)。カメラのスコアボードデモはCC BYのリーグ中継映像を使用して新しく撮影し、原典ごとに作者・ライセンス・変更内容を画面に記載します。
- モデルごとに学習データを記録しておく。 重みメタデータ(
nc_sources)と研究ノートにデータを残し、どのモデルをどのようなデータで再学習すべきかをいつでも切り分けられるようにします。 - GPL・AGPL・MPLのコードは持ち込まない。 手法のみを新しく実装します(第4節)。
この原則に基づいて作成した最初の事例
第4報の卓球台頂点モデルが、この原則に基づいてゼロから作成された最初のモデルです。Apache-2.0エンコーダ、自社合成画像80%、CC BY 3.0の中継映像12枚(20%)で学習を行い、非商用データセットはテストにのみ使用しました(メタデータ nc_sources=[])。CC BYのクレジット表記を学習済みの重みにおいてどのように遵守すべきかは、法的レビューによって決定します。
計画
- 学習型のフィルタリングと補正。 第4報のバウンスフィルタリングと「要確認」の補正は、入力がボールの軌跡と判定の特徴量のみであるため、映像なしで再学習が可能です。合成ラリーコードで軌跡を生成して学習させ、少量の自社ラベリング試合で確認するのが最も早い方法です。修正の記録が蓄積されたら、補正のデータとしても活用します。
- ボールモデル。 ボールモデルについても、自社撮影・自社ラベリングデータで学習する道筋を準備します。これにはラベル付き動画と大規模なGPUが必要であり、第3節で述べた学習プラットフォームが実際に必要となるポイントです。
- ルールエンジンのしきい値。 公開試合を見ながら手動で決定した定数を、自社テストセットを用いて再検証・調整します。
- 自社撮影のテストセット。 以下の評価に関する話題と「スマホでの現場精度の未実測」を同時に解決する課題であるため、最優先事項に位置づけています。
評価データはどうなるのか
評価には非商用データを使用しています。公開試合のテスト7試合が、この記事のほぼすべての数値の基礎となっています。商用企業が内部評価に非商用データを使用することが許可されているかどうかは、データライセンスにおける「非商用」の解釈に関わる法律上の問題であるため、ここでは結論を出しません。技術的に確実な道は1つだけです。 ラベル付きの自社撮影テストセットを作成することです。それは同時に「スマホでの現場精度の未実測」という最大の空白を埋める作業でもあります。
7. まとめ
- これまでの精度は大部分が非商用公開データ上で測定された評価であり、商用利用可能な実際の学習データはまだ少ない状況です。
- 学習規模は小さく済みます。ノートPCのCPUであれば数分、ノートPCのGPUの使い捨てポッドであれば20〜70分です。Kubeflowはインストールされていますが、スコアエンジンの学習にはまだ使用していません。
- 数字を信頼できるようにするため、固定分割、主要指標は1つ、ペアワイズ比較、シードの中央値、事前登録、リアルタイム予算を遵守し、遵守できなかった項目については記載しています。
- 商用サービスに合わせて学習データと重みを商用利用可能なものに置き換えています。非商用データは内部の研究・評価にのみ使用し、再学習は 自社撮影・自社ラベリング・合成データから開始します。
TTの一言: モデルが正しく当てられることと同じくらい、「誰のデータで学習したか」も重要です。だからこそ、これからは自分たちで撮影し、自分たちで作成したノートで勉強していこうと思います。
参考文献
- R. Voeikov, N. Falaleev, R. Baikulov. "TTNet: Real-time Temporal and Spatial Video Analysis of Table Tennis." CVPR Workshops, 2020. arXiv:2004.09927. OpenTTGamesデータ CC BY-NC-SA 4.0(データ公開ページの文言に基づく)。
- 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. データ CC BY-NC 4.0(リポジトリ README).
- 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.
- N. Ravi 他. "SAM 2: Segment Anything in Images and Videos." ICLR, 2025. コード・チェックポイント Apache-2.0.
- Y. Xiong 他. "Efficient Track Anything." ICCV, 2025. コード・チェックポイント Apache-2.0.
- Extended OpenTTGames(ラリー終了の原因・勝者、打球ラベル). arXiv:2512.19327. CC BY-NC-SA 4.0.
- 私たちの計測と記録: リポジトリ
docs/tt/PERFORMANCE.md2.1·2.10·2.19,docs/study/tt-score-models/07-datasets.md(データセットのカウント)、研究元帳第0節(実験ルール)・Ruling・E00・E25・E27・E33・E35・E44、deploy/下記の学習タスク案内ドキュメント、backend/app/tt_score_demos.pyはじめに(デモ原本).
あわせて読m
- 本シリーズ 第4回: モデルの原理と論文: ここで取り上げた3つの学習モデルの構造と実測。
- 本シリーズ 第6回: 試合の記録と個人情報: 人が修正した判定が再び学習の材料となり得る条件。
- 前シリーズ TT Score モデル解剖 第7回: 卓球データセットを自分で数えてみる.