デジタルツインとAI卓球審判：実際のバウンドで物理を合わせ、正解を知る試験場で審判を試す

ステータス：ドラフト（2026-10-18）、実測。試験場の精度はシミュレータ内の相対比較値です。 計算はすべてMac 1台（Apple M1 Max 10コア、Python 3.9.6、numpy 2.0.2）のCPUで行い、GPUやクラスターは使用していません。新しいパッケージ・画像・データのダウンロードは行っていません。調整と試験場はシードを固定した決定論的実行であるため各1回実行し（同一コマンドで同一結果）、処理時間のみ5回実行の中央値です。処理時間はMacで他のプロセスが動作し負荷平均が47〜76の状態で測定した値です。実際の映像は公開データセットOpenTTGames（120 fps、人物が捉えたボール座標とバウンドマーカー）およびその拡張ラベルを使用し、両方ともCC BY-NC-SA 4.0です。このデータで調整した物理パラメータおよびその値で描画したグラフ（反発係数グラフ）も同一条件に従います。元データ（調整結果、試験場判定24,300行ずつ、実際の基準表結果）は作業ディレクトリ measure/tt-twin/ にあります。

目次

• 1. 直感：正解を知る練習試合場
• 2. 実物合わせ：実バウンド1,777片
  • 2.1 方法
  • 2.2 結果
  • 2.3 しかし予測はほとんど改善しなかった
  • 2.4 誤差の大部分は単眼カメラの深さから生じる
• 3. 正解を知る審判試験場：24,300判定
  • 3.1 作成した理由
  • 3.2 3つの弱点
• 4. 改善サイクルの1周：軌道補間
  • 4.1 変更点
  • 4.2 シミュレータにおける結果
  • 4.3 実際の映像における結果（採用有無を決定した表）
• 5. AI審判の拡張：重力子とルール別判定表
  • 5.1 重力子
  • 5.2 ルール別判定表
• 6. 制限事項
• 7. 次のサイクル
• 参考文献

1. 直感：正解を知る練習試合場

カメラ型スコアボードの審判機能を向上させるには、「誤った判定」を大量に収集する必要があります。実際の競技映像には正解ラベルが少なく、エッジボールやオブストラクションのような稀なシーンはほとんどありません。シミュレータ内であれば、物理エンジンがボールの接触位置を把握しているため、必要なシーンを必要なだけ生成して審判に提示できます。これが 正解を知る試験場です。

ただし、試験場のボールの挙動が実際のボールと異なる場合、試験は的外れな弱点を検出してしまいます。そのため、手順を3つに分けました。

1. 実物合わせ（real2sim）： 実際のバウンドを用いてシミュレータの物理パラメータを調整します。
2. 試験場： 調整した物理パラメータでシーンを生成し、運用判定コードに入力して弱点を検出します。
3. 改善サイクル： 最大の弱点を1つ修正し、シミュレータと実際の映像の 両方で改善が見られた場合のみ採用します。

2. 実物合わせ：実バウンド1,777片

2.1 方法

• カメラのセットアップ。 卓球台の4つの角を使用して、試合ごとにカメラの姿勢を算出した。4つの角は同一平面上にあるため焦点距離を決定できず、1,400 px（水平画角約69°）に固定し、±20%の感度を個別に測定した。コーナの再投影誤差は1.0〜4.0 pxであった。
• バウンド片の調整。 バウンドごとに、接触時刻、接触点、入射および出射の速度、トップスピンなど11個の未知数を調整した。接触点が卓球台の平面に拘束され、飛行が重力・抗力・マグナス効果に従うという制約により、単眼カメラでは見えない奥行きが決定される。
• 分割。 調整は訓練用5試合の1,537片、評価はテスト用7試合の240片に試合単位で分割した。
• 物理モデル。 運用中の合成装置と同じ数式（反発係数 e = e0 + e1·v_z、滑り・転がりの境界 2/5、速度・回転に応じた抗力・マグナス係数）を使用し、反発・摩擦・抗力倍率・マグナス倍率のみをパラメータとして最適化した。

最初は「バウンド後50 msのみを観測して次のバウンドを予測する」誤差を最小化する方式で調整したが、測定ノイズが大きく反発係数が実測とかけ離れた値（e0 1.09）になった。そのためこの方式を破棄し、抗力・マグナス倍率をグリッドサーチで選択した上で、バウンドごとに測定した反発係数を直接回帰する手順に変更した。失敗した方法も記録として残す。

2.2 結果

実測の反発係数は、運用合成装置の値よりも0.04〜0.07低かった。ITTF規則（2.1.3）では、30 cmの高さから落としたボールは約23 cm弾まなければならないと規定されており、映像から調整した値はその基準（22.9 cm）の方向に移動した。第2部で見たMuJoCoのDeepMind卓球台の値（26.4 cm）および運用のデフォルト値（26.0 cm）がいずれも規定よりも弾力性高めであったのと同方向である。

2.3 しかし予測はほとんど改善しなかった

サーブの最初のバウンド前の断片とバウンド後150 msを観測して残りの飛行を予測し、相手側のバウンド（B2）と比較した。

（予測がネットに当たりB2を生成できなかったサーブは誤差計算から除外される。訓練55〜59件、テスト7〜8件である。）

• テスト7試合における改善は有意ではない。 サーブが23件しかなく、中央値の95%信頼区間（ブートストラップ2,000回）は、位置が11.3〜30.9 cm対12.7〜29.4 cm、時刻が6.6〜32.9 ms対8.9〜38.3 msで重複している。
• 調整によって減少したのは 偏り（訓練試合の時刻 +9.7 → +3.1 ms）であり、ばらつきはそのままだった。

2.4 誤差の大部分は単眼カメラの深さから生じる

正解が既知の再サンプリングにより単眼カメラの限界を測定した。実際のバウンド調整600件を正解とし、調整された物理モデルで再描画してカメラに投影し、ノイズを付加した上で同じ方法で復元した（物理モデルが正確であると仮定した場合の下限）。

• バウンドの位置は単眼カメラでも正確に特定できる。 60 fpsのスマートフォンで1〜3 cmである。
• 奥行き方向の速度は水平方向よりも7〜10倍不正確である。 0.3秒の飛行では奥行き位置が10〜50 cmずれ、セクション2.3の表のばらつきはまさにこの大きさに起因する。
• 回転は測定できない。 誤差は実際の回転の大きさ（DeepMindデータの中心値54 rad/s）と同等かそれ以上である。
• 30 fpsは前後3フレームしかないため、600件中157件しか調整できなかった。
• 仮定した焦点距離を1,150 / 1,400 / 1,700 pxに変更すると、実測のe（2.5〜3.5 m/sのセル）は0.847 / 0.831 / 0.802に変化した。焦点距離の仮定により、反発係数に±0.03程度の不確実性が加わる。

現在は奥行き誤差が物理パラメータの差を覆い隠している。マグナス倍率と奥行きを同時に決定するには、2台目のカメラか、ボールの模様が視認できるハイスピード映像が必要である。

3. 正解を知る審判試験場：24,300判定

3.1 作成した理由

• 物理モデル。 第2部で調整した値に卓球台の端と側面を追加した。板厚25 mmのボックスとして扱い（推定）、上面の縁に上から接触した場合をエッジ（ITTF 2.1.2に基づくプレイングサーフェス、得点成立）と判定した。
• シーン9種。 エンドライン・サイドライン周辺（エッジ、イン、アウト）、ネットインしてオーバー、サーブレット、ダブルバウンド、高速スマッシュ、高いロビング、ボレー（レシーバーがバウンドする前に打球。プレイングサーフェス上方でのオブストラクション）、基準ラリーである。正解は意図ではなく物理演算による接触順序で決定した。
• 劣化9条件。 理想（ノイズなし）、現実（実測検出ノイズ）、30 fps、120 fps、ノイズ2倍、ぼやけ、オクルージョン、見落とし、スマートフォン（30 fps + ノイズ2倍 + ぼやけ + オクルージョン）である。検出信頼度は実検出器の71,617フレームの分布からサンプリングした。
• 判定エンジン。 運用判定コードのコピーを運用環境と同じスイッチでそのまま実行した。シーンごとに300件、9条件、合計24,300判定の実行にMacで25分を要した。

レンダリングを行わず投影座標を使用した理由。 判定エンジンの入力はボールの画面上の座標であり、目的はエンジンの弱点を発見することである。座標レベルであれば、条件だけを変更して同じシーンを何万回も実行できる。代償として 見た目の違いが失われるということです。ボールが背景・衣類・照明に埋もれること、ラケットや手をボールと誤認すること、実際のブレの痕跡の形状は、検出器のエラーの確率モデルでのみ模倣しました。 実際にテスト環境の基準ラリー（実条件）の精度82%は、同じ運用パイプラインで測定した実際のテスト7試合のクリアな映像における93%（54/58）よりも低いです。そのため 以下の表は、シーンと条件間の相対的な比較としてのみ読み取る必要があります。 絶対値を実際の精度として読み取ってはいけません。

3.2 3つの弱点

1. オブストラクション 16%（すべての条件で12–24%）。エンジンには「相手のボールをこちらのコートに弾ませる前に競技面上から打った」という概念がなく、大部分をツーバウンドと読み取って対戦相手にポイントを与えます。 同じエンジンがエンドラインを超えたボールを打ったボレーを86%的中させますが、ルールを理解しているからではなく偶然です。
2. エッジボール 53%、確認なしでの誤判定 21%。 エッジに当たったボールは、画面上でV字型のバウンドを描きません。エンジンはバウンドを確認できず、アウトとして処理します。間違っていながらも人間の確認に回さない割合が最も高く、最も危険な項目です。
3. サーブレット 60%（オクルージョン 41%、スマホ 44%）。ネットにかすったサーブの速度低下を検知できない、ネットで方向が変わったボールをバウンドと読み取る、またはレシーバー側のバウンドを見逃します。

その次は高いロブ（イン）60%でした。ボールが画面の外に出たり1.5秒以上飛行したりすることで、「ラリー終了」が先に発生します。シーンを問わない失敗原因の第1位は ボール検出が空き位置でのバウンドを見逃すことでした。

120 fpsは60 fpsよりも悪くなりました（77%対80%）。フレーム数が多い方が良くなりそうですが、エンジンの画素の閾値やバウンド拒否ルールが60・30 fpsに合わせて調整されているためだと考えられます。原因を個別に切り分けて再測定はしていません（未計測）。 実際の120 fps映像の推論で確認することが次の作業です。

4. 改善サイクルの1周：軌道の補間

4.1 変更点

テスト環境での失敗原因の第1位である「ボール検出が4サンプル（60 fpsで約0.07秒）を超えて空き位置のバウンドを見逃すこと」を選択しました。実際の試合でも見逃されたバウンドの多くがこのパターンであったという事前の記録があります。

空き位置の前後の軌跡の断片に 曲率を重力で固定した放物線をフィッティングします（曲率 ＝ その位置の画面スケール × 9.81、傾きと切片のみ調整）。以下のすべてを満たす場合にのみ、前後の曲線で空き位置を補間します。

• 前は下降し、後ろは上昇する。2つの曲線が空き位置の内部で交差する。
• 交点の水平位置が前後で卓球台の長さの4%以内に収まり、水平方向が維持されている（反転した場合は打球）。
• 交点が卓球台上面の帯の内部である。空き位置は0.3秒以下、前後の断片はそれぞれ3サンプル以上、放物線の残差は2 px以下である。

補間された点は信頼度を両側の半分とし、そのバウンドは人間の確認側に回ります。閾値は物理法則から事前に決定し、テスト結果を見て選定したものではありません。

（図は原理を示すために作成した合成軌跡です。実際の判定結果ではありません。）

4.2 シミュレータ上での結果

確認なしで間違った判定は1,215件から996件に減少しました。ただし、 エッジ（53.1 → 49.9%）とオブストラクション（16.3 → 14.6%）は低下しました。 これは今回の変更の目標ではなく、次回のサイクルの課題です。

4.3 実際の映像における結果（採用の有無を決定した表）

シミュレータでのみ改善されたものは採用しません。テスト環境は現実の見た目が省略された近似であるため、そこで改善された変更が実際の映像では悪化する可能性があるためです。 そのため、運用時のリアルタイムパイプラインのまま、実際の映像の固定基準表を再度実行しました。

• テストの12条件において悪化した条件はありませんでした（暗い条件での「−1」は、同一条件での「+3」と同時に発生しました）。
• 難問であったロブラリーが正しく修正されました。 テスト第1試合の24.4秒の高いロブは、ボールが落下する瞬間に検出が抜け、バウンドを見逃していたラリーです。クリア、ブレ、手ブレ、スマホ画質の各条件で正しく修正されました。
• 開発用においてラリー単位で悪化した条件が5つありました。クリアな映像の2つのラリーは、得点が終了した後にカメラの前に落ちてきたボールが画面上で卓球台の上に見え、バウンドが補間されたケースでした。単眼の奥行きの曖昧さがそのまま残っており、どちらの判定も信頼度が0.44であるため人間の確認に回ります。
• 処理コストはサンプルあたりp95が0.445 → 0.545 ms（学習3試合クリア）となり、増加分は0.1 ms前後です。リアルタイムの許容量である5 msの範囲内です。

判定：採用。 ただし、運用時には スイッチをオフにした状態 で導入します。オフの場合は従来と同じ計算となるため判定は変わりません。 有効化する前に、カメラのスコアボードのE2Eログ（テスト7試合を仮想カメラ30 fpsで記録して再現）により「運用時より悪化していないこと」をリアルタイムパイプラインで再度確認し、上記の「カメラの前に落ちてきたボール」のグループを合わせて確認します。

5. AI審判の拡張：重力定規とルール別判定表

5.1 重力定規

サーブトスは手を離れた後16 cm以上上がる必要があります（ITTF 2.6.2）。しかし、カメラ1台ではボールまでの距離が分からないため、画面上の画素をセンチメートルに変換するスケールがありません。 ここで重力が定規の役割を果たします。手を離れたボールの画面上の高さを、時間に関する放物線 y = a·t² + b·t + c にフィッティングすると a = g·s/2 となり、s はそのボールの奥行きにおいて1 mが何画素であるかを示します。 これにより、高さ ＝ 画素差 ÷ s として測定でき、奥行き（焦点距離 ÷ s）からボールの3次元位置も算出されます。

• 実測。 実際の試合映像のサーブトス80回において、このように測定したスケールの中央値は 330 px/m であり、カメラの幾何学から求めたネット位置のスケールは4試合で 303–335 px/m でした。重力定規は実際の映像でも有効です。
• 制限。 ルールの「16 cm」は手を離れた瞬間から適用されます。合成テストにおいて、手がボールを3–15 cm持ち上げた後に離す動作（推定）を組み込むと、16 cm判定の精度は0.70–0.86に低下し、境界の±4 cm以内では0.59–0.66に低下しました。 手を持ち上げない理想的な条件では0.99でした。ボールの軌跡だけでは「離れた瞬間」を正確に捉えることが困難です。
• 実際の映像（60 fps、サーブ275本）において高さを測定できたサーブは80本（29%）でした。正解の高さが存在しないため、精度は測定できていません。

5.2 ルール別判定表

シグナルごとに信頼度を設定し、シグナルが食い違う場合や確信度が低い場合は人間の確認に回すという原則です。「測定済み」は今回の実測、「未測定」は未計測を表します。

6. 制限事項

• テスト環境の精度は現実の見た目が省略された近似であるため、現実よりも厳しくなっています（基準ラリー 82%対実際 93%）。表の値は相対的な比較としてのみ使用します。
• 卓球台の板の厚さ 25 mm、角が丸まっていないという仮定、ブレの見逃しモデル、ノイズ強度 2、手の上昇 3–15 cmは推定です。卓球台の側面（サイド）への接触は、シーン生成において一度も発生していません。
• カメラの焦点距離は 1,400 px と仮定しており（±20%で e ±0.03）、回転は単眼では決定できません。
• サーブ予測の適合前後の差はテストサンプルが23個のため統計的有意ではありません。
• 実際の基準表における「確認なしでの誤判定」は、運用の補正ではなく信頼度 0.6 未満のルールでカウントした代理の値です。処理コストはMacの負荷が高い状態で測定した値であるため、アイドル時にもう一度測定する必要があります。

7. 次のサイクル

1. 軌道補間スイッチをオンにする前のE2E確認。
2. エッジ候補 → 人間の確認。 エンドラインの帯の内部で「V字なしで方向が急激に変化すること」をエッジ候補として表示します。テスト環境において確認なしでの誤判定が減少し、通常のアウト判定が悪化しないかを事前に測定します。
3. オブストラクションルール。 横から見れば長さ方向はよく確認できるため（セクション2.4）、方向が反転した位置の長さ方向の座標で判定します。
4. テスト環境の忠実度。 実際の検出器のエラーを速度・位置ごとに再測定してノイズモデルを調整し、120 fpsが60 fpsよりも悪くなった結果を実際の120 fps推論で確認します。

一言まとめ。 正解が分かっている練習環境で審判を2万4千回テストしました。そこで見つかった弱点を修正し、実際の試合映像でも改善された場合のみ採用しました。練習環境だけで優秀な審判は役に立ちませんからね！

参考資料

すべてのリンクは2026年10月18日にアクセス可能であることを確認しました。

• ITTF卓球規則 2026–27（公開コピー）： https://www.tabletennisengland.co.uk/content/uploads/2026/07/Laws-of-Table-Tennis-2026-27.pdf
• DeepMindの公開ボール状態（スピン量の比較に使用）： https://github.com/google-deepmind/competitive_robot_table_tennis（© 2025 Google LLC, CC BY 4.0）
• 実際の映像データ：OpenTTGamesデータセットとその拡張ラベル（CC BY-NC-SA 4.0）。本記事の適合物理値および反発係数の図は同一条件（CC BY-NC-SA 4.0）に従います。
• 前回の記事： 第2部：MuJoCoで卓球の物理を再現する, 第6部：DeepMindの卓球ロボットの改善方向