ゲームの世界では、キャラクターが壁にめり込んだり、弾丸が敵をすり抜けたりする「衝突判定バグ」は、長年にわたり開発者を悩ませてきた。だが、その原因は単なるプログラムのミスではない。それは、離散化された時間と有限精度の数学が生み出す、デジタル空間特有の“物理的ゆらぎ”である。

本稿は、AABBやOBBといった幾何モデルから、浮動小数点誤差、連続衝突判定（CCD）、そしてAIによる誤差補正の最前線まで、「当たり判定」がなぜ外れるのかを、数学と哲学の両面から読み解く技術的・理論的分析である。

衝突判定の根幹を理解すれば、バグは偶然ではなく、再現できる“数理現象”として見えてくる。
これは、ゲーム物理を哲学的に観察するための、ひとつの「科学的バグ読解書」である。

目次 [ close ]
  1. 第1章　衝突判定の基礎構造
    1. 1-1. 衝突判定とは何か
    2. 1-2. 判定の流れ：離散時間と空間のサンプリング
  2. 第2章　数学的誤差が作る“当たり判定のすき間”
    1. 2-1. 浮動小数点演算の限界
    2. 2-2. 境界条件と丸め誤差の罠
    3. 2-3. 数学モデルの不一致 ― 理論と実装のずれ
  3. 第3章　離散時間シミュレーションと“すり抜け”現象
    1. 3-1. 離散時間シミュレーションの本質
    2. 3-2. 連続衝突判定（Continuous Collision Detection, CCD）の原理
    3. 3-3. 離散 vs 連続 ― 計算資源のトレードオフ
  4. 第4章　再現実験：理論が示す“すり抜け”の再構成
    1. 4-1. シンプルな1次元モデルのシミュレーション
    2. 4-2. 数値精度による境界非検出の再現
    3. 4-3. 複合条件バグの連鎖
    4. 4-4. 検証的まとめ ― バグを“再現できる理解”へ
  5. 第5章　結論：数学を理解すれば、バグは再現できる
    1. 5-1. 本稿の要約
    2. 5-2. 衝突バグを防ぐための実践的提言
    3. 5-3. 今後の展望：AIとGPUによる“自律的誤差補正”
    4. 5-4. 結語：バグは理解できる「数理現象」である

第1章　衝突判定の基礎構造

1-1. 衝突判定とは何か

ゲームにおける「衝突判定（Collision Detection）」とは、複数のオブジェクトが空間上で交差・接触したかどうかを検出する計算処理を指す。
この処理は単に「当たった・当たらなかった」を決めるだけではなく、物理演算・アニメーション・AIの行動決定など、ゲーム全体の挙動を律する中枢的機能でもある。

たとえば、アクションゲームでキャラクターが壁にぶつかって止まる、弾丸が敵に当たってダメージを与える――これらのすべてに衝突判定が関与している。
したがって、衝突判定が正確に動作しなければ、「壁をすり抜ける」「敵に当たらない」「床を貫通して落下する」といったバグが発生する。

衝突判定の方式は、主に次のような幾何的モデルで分類できる。

判定モデル概要特徴
AABB（Axis-Aligned Bounding Box）軸に平行な直方体でオブジェクトを近似し、各軸方向の範囲が重なるかを確認。計算コストが低く、2D・3D問わず広く用いられる。
OBB（Oriented Bounding Box）任意の角度に回転した直方体を使用し、より実際の形状に近い判定を可能にする。精度は高いがやや計算が重い。
Sphere / Capsule 判定球体またはカプセル状の境界で当たり範囲を定義。キャラクターなど回転を多用する対象に適する。
Mesh-based detectionポリゴン（メッシュ）の形状そのものを用いた厳密な判定。精密だが計算負荷が非常に高い。

これらのモデルは目的とコストのトレードオフによって選択される。
たとえば多くの格闘ゲームでは“ヒットボックス”や“ハートボックス（hurtbox）”と呼ばれる単純形状を用い、意図的に単純化することで公平性と処理速度を両立している。
一方で、物理演算主体のシミュレーションゲームやVR空間など、より正確な形状が求められる場面では、GJK法（Gilbert–Johnson–Keerthi） や SAT法（Separating Axis Theorem） といった高精度アルゴリズムが使用される【1】【2】。
これらは特に凸形状間の最短距離・交差判定を高速に求めるための実用的手法として、現在も主要な物理エンジン（Bullet Physics, Unity, Unreal Engineなど）で利用されている【3】。

1-2. 判定の流れ：離散時間と空間のサンプリング

衝突判定のもう一つの重要な側面は、時間と空間が離散的に扱われているという点である。
現実世界では運動や衝突は連続的に発生するが、コンピュータ上では「フレーム（frame）」単位――すなわち一定の時間間隔 Δt ごとに物体の位置を更新している。
このため、プログラム上では「連続的な動き」を離散的なサンプリング点の列として近似的に扱うことになる。

例：

フレーム1：キャラクター位置 = x = 0.0
フレーム2：キャラクター位置 = x = 10.0
壁の位置 = x = 5.0

この場合、1フレームの間にキャラクターが壁を“飛び越えて”しまっても、途中の状態（x ≈ 5.0付近）を検知できない。
結果として、ゲーム上ではキャラクターが壁を「すり抜けた」ように見える。
この現象は物理的には存在しないが、離散的時間ステップに起因する観測の抜け落ちであり、実装上はバグとして認識される。

離散化の影響が顕著な二つの要因

① フレームレート依存の精度差
Δt が大きい（低フレームレート）の場合、物体が1ステップで大きく移動し、衝突を見逃す確率が上がる。
Δt が小さい（高フレームレート）の場合、より細かくサンプリングされ、衝突を検出しやすい。
結果として、フレームレートによって衝突の成否が変わるという現象が起こり得る【4】。

ただし、実際の物理エンジン（Unity, Unreal Engineなど）では、固定物理ステップ（Fixed Timestep） や サブステップ更新 によってこの問題を部分的に緩和している【5】。
それでも極端なフレームレート変動があると、挙動の再現性に影響が残る。

② 数値積分誤差の累積
オブジェクトの位置更新には速度と加速度を用いた数値積分（オイラー法など）が使われる。
これは近似的手法であり、誤差が蓄積することでオブジェクトが「少しずつ沈む・浮く・抜ける」といった現象を引き起こす【6】。
この誤差は積分法の選択（オイラー法・セミインプリシット法・Verlet法など）や Δt の大きさに依存する。

このように、衝突判定は単なる幾何演算ではなく、離散化された時空間上での近似演算として成立している。
したがって、衝突バグの多くは「コードの書き間違い」ではなく、離散サンプリングという計算構造上の限界から生じる。

小結：衝突判定は「幾何 × 時間離散」

第1章で見たように、衝突判定とは「幾何学的モデル × 離散的時間処理」の組み合わせであり、
どちらの側にも誤差や不整合が潜んでいる。
次章では、この離散世界における数学的誤差（浮動小数点演算の限界）が、どのように“当たり判定のすき間”を生むのかを分析していく。

第2章　数学的誤差が作る“当たり判定のすき間”

2-1. 浮動小数点演算の限界

衝突判定バグの多くは、単なるアルゴリズムの誤りではなく、数値計算の根底にある精度誤差によって生じる。
コンピュータが扱う実数値は「浮動小数点数（floating-point number）」として IEEE 754 規格（最新版：IEEE 754-2019 / ISO 60559:2020）に基づいて表現される【7】。
しかし、これは有限ビットによる近似であり、連続的な実数演算を完全に表現することは不可能である。

たとえば十進法では単純な数値 0.1 も二進法では正確に表せず、次のような現象が起こる。

0.1 + 0.2 = 0.30000000000000004

この微小な誤差は日常のアプリケーションでは無視できるが、
「境界で衝突するか否か」を判定するゲーム物理では致命的となることがある。

たとえば、壁の境界が x = 5.0 で、キャラクター座標が x = 5.0000001 だった場合、
理論上は接触していてもプログラム上では「まだ壁の手前」と判断される。
逆に x = 4.9999999 のような丸め誤差によって「当たっていないのに当たった」と誤認することもある。

こうした誤差は、演算順序・コンパイラ最適化・CPU命令セット（x86, ARMなど）によって再現性が変化する。
そのため「ある条件でしか発生しない」「デバッグビルドでは起きない」といったバグが生まれる。
これは単なる不安定性ではなく、有限精度演算という計算空間の非連続性に起因する構造的誤差である。

2-2. 境界条件と丸め誤差の罠

衝突判定では「物体 A と B が重なったか」を判定するために、よく次のような条件式を使う。

if (xA <= xB + widthB) // 衝突とみなす

しかし、この単純な比較がわずかな丸め誤差で反転することがある。
特に、浮動小数点比較における境界上の扱い（inclusive / exclusive）は実装上の重要な判断点である。

比較式意味結果の差
<= を採用境界上でも「衝突」と判定オブジェクトが“めり込む”傾向
< を採用境界上は「非衝突」と判定オブジェクトが“弾かれる”傾向

この違いだけで、物体が「めり込む」「弾かれる」「すり抜ける」といった挙動差が生じる。
実際、Unity や Unreal Engine など主要エンジンでも Contact Offset（接触オフセット）や内部閾値（epsilon値）の扱いが異なるため、
同じ座標でも挙動が完全には一致しない【4】【5】。

そのため、多くの開発者は「ε（イプシロン）判定」と呼ばれる近似比較を導入する。

if (fabs(xA - xB) < EPSILON)

ここで EPSILON は 1e-5 ～ 1e-7 程度の小さな値とし、誤差の許容幅を設定する。
ただし閾値を大きくしすぎれば誤検出が増え、小さすぎれば不検出が起こる。
このため ε設計は精度と安定性のトレードオフの象徴である。
（Unity では Physics.defaultContactOffset、Unreal Engine では Contact Offset Multiplier がこれに相当する【4】【5】。）

2-3. 数学モデルの不一致 ― 理論と実装のずれ

浮動小数点誤差の本質は、理論モデル（実数空間）と実装モデル（有限精度空間）の不一致にある。
理論上、オブジェクトの座標は連続値であり、接触の瞬間を厳密に定義できる。
しかし実装上では、すべての座標が有限ビットの離散点に丸められており、
「接触しているはずの点」がその格子上に存在しないことがある。

例として、2D 空間で「線分と点の衝突」を考えよう。
ベクトル計算では、点 P が線分 AB 上にあるかを内積・外積で判定するが、
丸め誤差により外積が 1e-8 程度の非ゼロ値になることがある。
結果、実際には線上にあるのに「わずかに外れている」と判定される。

さらに3D 空間では座標値が大きくなるほど有効桁数（float で約7〜8桁）が不足し、
「遠方のオブジェクトほど衝突精度が落ちる」という現象が生じる【8】【9】。
この問題は Unity でも Floating Origin 技法（原点再配置）として知られており、
実務では原点付近に再マップして精度を確保する方法が一般的である。
一方 Unreal Engine 5 では Large World Coordinates / World Origin Rebasing により、広大なワールドにおける座標精度低下を軽減している【9】。

小結：数値の世界の“ひずみ”が生む錯覚

衝突判定の精度は、物理エンジンの設計だけでなく、数値表現そのものの限界にも束縛されている。
「数学的に接触しているのに、デジタル的には存在しない」という状況は、
まるで顕微鏡で見ると滑らかな線が無数の点で構成されているようなものだ。

すなわち、ゲーム空間とは連続世界を有限の点群で近似した仮想格子空間であり、
その“目の粗さ”の中で物体はすり抜けたり、跳ね返ったりしているのである。

第3章　離散時間シミュレーションと“すり抜け”現象

3-1. 離散時間シミュレーションの本質

ゲームにおける物理シミュレーションは、ニュートン力学に基づく運動方程式を数値的に近似して解く仕組みで動作している。
理論的には「連続的な時間 $t$」の中で、位置 $x(t)$ や速度 $v(t)$ が滑らかに変化するが、実際のゲームではコンピュータが一定の時間刻み $\Delta t$ ごとにしか状態を更新できない。
この「$\Delta t$ ごとの更新」が、離散的な世界を生み出す。

最も単純な方法がオイラー法（Euler Integration）である。
時間ステップごとに次のように位置と速度を更新する。

$x_{t+Δt} = x_t + v_t × Δt$

この方法は高速かつ実装が容易であるため、Unity や Box2D など多くのゲームエンジンで基本形として用いられている【10】【11】。
しかし、オイラー法は $\Delta t$ が大きい場合に誤差が急増するという弱点を持つ。

高速移動するオブジェクトほど、1ステップで大きく座標が変化し、
「壁の前 → 壁の後」へ一気に飛んでしまうため、途中の“接触点”を検出できない。
これが、プレイヤーがよく遭遇する「壁抜け」「すり抜け」現象の数学的理由である。

つまり、シミュレーションが「連続的な運動」を「$\Delta t$ ごとの点列」としてしか観測できない以上、
**サンプリング定理（Nyquist限界）**のように、時間分解能を超える速さの動きは観測不能になる。
（※ここでの比喩は信号処理上のナイキスト条件を直喩的に用いたもので、厳密な定理適用ではない。）

この比喩は、離散ステップが粗いと高速運動を見落とすという意味で極めて適切である。
衝突判定バグとは、実は「時間のサンプリング精度を超えた運動」に対する観測の失敗なのである【10】【11】。

3-2. 連続衝突判定（Continuous Collision Detection, CCD）の原理

この根本問題に対する物理エンジンの代表的な解決策が、
連続衝突判定（Continuous Collision Detection：CCD）である。

CCD は、離散的なフレーム間における物体の移動経路を解析し、
その経路上で衝突が起きたかを連続時間的に判定する手法である。

● Swept Volume（掃引体）アプローチ

物体が1フレームの間に移動する経路を「空間上で掃引した体積」として扱う。
たとえば球体なら、移動前と移動後の位置を結ぶ線分を中心軸にした「カプセル状の体積」として表現する。
この掃引体と壁オブジェクトとの交差を判定すれば、「途中で接触した瞬間」を検出できる。
これにより、フレーム間の見逃し（tunneling）を防ぐことが可能になる【12】。

● Time of Impact（衝突時刻）の解析

もう一つの方法は、連続的な時間パラメータ $t \in [0,1]$ の中で、
物体AとBの距離関数 $d(t)$ がゼロになる瞬間を解く手法である。
数式的には「$d(t)=0$ を満たす最小の $t$」を求める問題であり、
Newton–Raphson 法などの数値解法で近似的に算出される。
Bullet Physics や Havok などの物理エンジンではこの方式が採用されている【12】。

CCD は非常に強力だが、常に適用すると計算コストが大きくなるため、
多くのゲームエンジンでは「高速移動オブジェクトのみ CCD を有効化」する設計を採用している。
つまり、物体の速度ベクトルに応じて判定方式を動的に切り替えるのが現実的な運用方針である。

なお、Unity の CCD モードには Discrete / Continuous / ContinuousDynamic / ContinuousSpeculative の4種があり、
そのうち Continuous および ContinuousDynamic は掃引体方式、ContinuousSpeculative は推測型（予測ベース）である。
また、MeshCollider には適用制限があり、完全なCCDには非対応である【13】【14】。

3-3. 離散 vs 連続 ― 計算資源のトレードオフ

CCDを導入すればすべてのすり抜けが防げるわけではない。
なぜなら、CCD は理論的には連続判定だが、実装上は依然として近似解法に依存しており、
計算コストと精度のトレードオフが存在するからである。

多くの物理エンジンは、**Substep（サブステップ）**という仕組みで折衷を図っている。
これは、1フレーム内で複数回（例：4〜8回）シミュレーションを行い、$\Delta t$ を分割して精度を上げる方法である【10】【11】【12】。
サブステップを増やせば精度は向上するが、CPU負荷が直線的に上昇する傾向があるため、
フレームレート低下やラグの原因となる。

したがって、開発者はどの程度の精度を“現実的”とみなすかを、ゲームデザインと並行して決める必要がある。
また、近年の GPU 物理シミュレーションでは、並列計算によって CCD を部分的に分散化し、
「重要な衝突だけを高精度に処理する」動的最適化も行われている。
これは、いわば “衝突の優先順位付け” であり、
プレイヤーの視界やカメラ近傍の衝突を優先的に計算する手法などが提案されている。

小結：時間の“粗さ”が作る錯覚世界

第3章で見たように、「すり抜け」バグの正体は、時間が連続ではなくサンプリングされた離散点の列であることに起因する。
高速オブジェクトは、その時間の隙間を“すり抜ける”ことで現実離れした挙動を示す。

この構造は、映像のコマ落ちが人間の目には「瞬間移動」に見える現象にも似ている。
ゲームの衝突判定とは、まさに時間と空間をどの精度で区切るかという選択の上に成り立っているのだ。

次章では、この理論を再現的に確認するために、
実際の1次元モデルを用いた衝突バグのシミュレーション実験を行い、
「$\Delta t$」「精度」「境界条件」がどのように結果を左右するかを具体的に示す。

第4章　再現実験：理論が示す“すり抜け”の再構成

4-1. シンプルな1次元モデルのシミュレーション

衝突判定の理論的背景を理解したところで、
次に「すり抜けバグはどのような条件で起こるのか」を、1次元モデルを用いて再現してみよう。

ここでは、単純化した以下の仮想シナリオを考える。

  • 空間：1次元（x軸上のみ）
  • 壁：固定位置 $x = 5.0$ に存在
  • オブジェクト：初期位置 $x = 0.0$、速度 $v = 12.0$ [m/s]
  • シミュレーション時間刻み：$\Delta t = 0.5$ [s]

オイラー法による位置更新式は次の通り：

$x_{t+Δt} = x_t + v × Δt$

この設定でステップごとの位置を計算すると：

時刻 (s)位置 x
0.00.0
0.56.0
1.012.0

この結果、オブジェクトは 0.5 秒の時点で「x = 6.0」にジャンプしており、
「x = 5.0」の壁を検出する機会を完全に失っている。
フレーム間で壁を“通過”したが、途中を観測していないため、プログラム的には衝突なしと判断される。
この現象が、実際のゲームで頻発する「すり抜け」バグの数理的再現である。

もしここで $\Delta t$ を 0.1 秒に減らすと：

時刻 (s)位置 x
0.00.0
0.11.2
0.22.4
0.33.6
0.44.8
0.56.0

この場合、「x = 4.8 → 6.0」の間に壁を通過していることを検知でき、
連続衝突判定（CCD）などを併用すれば、壁直前での接触を正しく検出できる。

つまり、$\Delta t$ の離散化誤差こそがバグの主原因であり、
シミュレーション精度と演算負荷のバランス設計が鍵となる。

4-2. 数値精度による境界非検出の再現

次に、浮動小数点精度（float / double）の違いによる誤差を観察する。
同じく「壁 = 5.0」の条件で、オブジェクトがちょうど $x = 5.0$ に到達した場合を想定する。

$float x_f = 4.9999995f;$
$double x_d = 4.9999999999995;$

単精度（float）は約7〜8桁、倍精度（double）は約15〜17桁の有効桁数を持つ。
この場合、$x_f$ は丸め誤差で実際には「4.999999」程度に格納され、
条件式 if (x >= 5.0) は偽になる。つまり、衝突しているのに検出されない。

一方、double 精度では誤差が小さく、同条件で真と判定される。
この実験は、衝突判定が数値表現そのものに依存していることを端的に示す。

開発者によっては float の高速性を優先して採用するが、
大規模ワールド（大座標系）では有効桁が不足し、距離誤差が累積して
「遠くの壁に当たらない」「床に沈む」といったバグを誘発する。

Unity や Unreal Engine でも、ワールド原点からの距離に応じて精度誤差が顕著になる現象が報告されており、
このため Floating Origin（Unity）や Large World Coordinates / World Origin Rebasing（UE5）による補正が一般的となっている【15】【16】。

4-3. 複合条件バグの連鎖

実際のゲームでは、衝突判定は単一条件ではなく、
「浮動小数点誤差 × $\Delta t$離散化 × 判定順序」といった複数要素が重なってバグを生む。

この相互作用を整理すると、以下のような連鎖構造になる。

  • $\Delta t$ が大きい → フレーム間の移動量が増加
  • 移動経路上で衝突を見逃す → CCDで補正されない
  • 境界判定に丸め誤差が発生 → 衝突の有無が反転
  • 衝突後の反応処理（反射・停止）が未実行 → オブジェクトが貫通
  • 次フレームで位置が壁の裏側に確定 → 再検出不能

このように、一見「1ドットのズレ」に見えるバグでも、
実際には数値的・論理的な要素が複合的に作用して発生している。

開発者が「再現性が低い」と感じるのは、
そのバグが確率的な数値状態の組み合わせによってのみ顕在化するためである。

4-4. 検証的まとめ ― バグを“再現できる理解”へ

上記の再現実験が示すのは、衝突判定バグが「プログラムの不備」ではなく、
離散的時間・有限精度の数理構造に内在する現象だという事実である。

したがって、真のバグ修正とは「偶然を直す」ことではなく、
条件を制御して再現できる理解を持つことに他ならない。

この理解に基づけば、開発者は次のような実践的アプローチを取ることができる。

  • $\Delta t$ を制御し、サブステップを導入して検証する
  • float と double の切り替えで精度感度を評価する
  • 衝突閾値（ε値／Contact Offset）を可視化して境界条件を観測する
  • シミュレーションログを時間順にプロットし、すり抜け発生時刻を特定する

これらの再現的手法は、もはや単なるデバッグではなく、
**「ゲーム空間における数理実験」**としての性格を帯びている。
そして、こうした観察的アプローチこそが、E-E-A-T における Empirical Observation（検証的知見）に相当する。

小結：数理の理解が“再現不能バグ”を再現可能にする

衝突判定のバグを避ける最良の方法は、「完全に防ぐ」ことではなく、
なぜ起こるかを理屈として理解し、条件を制御することである。

離散化された時間と有限精度の数値空間という“制約下の世界”を理解すれば、
すり抜けやめり込みといった現象も、再現可能な理論的挙動として説明できる。

この理解が、衝突判定を単なるプログラミング技術から、
**「デジタル物理の哲学的対象」**へと引き上げる第一歩である。

第5章　結論：数学を理解すれば、バグは再現できる

5-1. 本稿の要約

本記事では、ゲーム開発における衝突判定バグ――すなわち「すり抜け」「めり込み」「非反応」といった現象――を、
単なる実装上の不具合ではなく、数学的・数値計算的な構造的問題として位置づけて分析した。

第1章では、衝突判定が「幾何学的モデル（AABB, OBB, Sphere）」と「離散時間処理（Δt）」の組み合わせで動作していることを確認した。
この段階で、衝突検出が「連続的現象を離散的サンプリングで捉える試み」であることが明らかとなった。

第2章では、浮動小数点演算の限界――特に丸め誤差と境界条件の不確定性――が衝突検出の不安定性を生むことを示した。
理論上の接触が、実装上は「ほんの $1\times10^{-7}$ の差」で消滅する。
この“数値のひずみ”こそが「当たっているのに当たらない」という錯覚を生み出していた。

第3章では、離散時間シミュレーションの仕組みを分析し、
時間刻み（$Δt$）が大きいほど衝突を見逃すトンネリング（tunneling）現象が起こる理由を説明した。
さらに、連続衝突判定（Continuous Collision Detection, CCD）の導入によって、
フレーム間の「見えない衝突」を補足する原理を整理した。

第4章では、これらの理論を1次元モデルによって再現し、
$Δt$・浮動小数点精度・境界条件の違いがどのように結果を左右するかを実証的に確認した。
その結果、衝突判定バグは「誤ったロジック」ではなく、有限計算世界の宿命的な誤差であることが確かめられた。

5-2. 衝突バグを防ぐための実践的提言

衝突判定における数学的限界を踏まえると、
開発者が取るべき実践的アプローチは「精度・コスト・再現性の三要素をどう調和させるか」に尽きる。
以下は、理論を実務に還元するための提言である。

① ε（イプシロン）を用いた安全な境界設計

浮動小数点誤差を吸収するために、「誤差許容幅（ε）」を明示的に設計する。
εは固定値ではなく、オブジェクトのスケール依存型に設定することが望ましい。

const float epsilon = objectSize * 0.001f;
if (fabs(xA - xB) < epsilon) {
    // 衝突とみなす
}

この方法により、スケールが大きいオブジェクトでの過検出や、微小オブジェクトでの見逃しを減らせる。
（ただしこれは一般的な実務慣行であり、ゲームジャンルや解像度によって調整が必要である。）

加えて、Unity では Physics.defaultContactOffset、Unreal Engine では Contact Offset Multiplier など、
内部的に「接触オフセット」を導入しており、これは ε と同等の機能を果たす。
外部で独自εを定義する場合は、これらのパラメータと整合性を取ることが重要である【17】【18】。

② 高速オブジェクトへの選択的CCD適用

すべてのオブジェクトに連続衝突判定を適用するのは非現実的である。
代わりに、速度ベクトルの大きさが一定閾値を超える場合のみCCDを有効化する。

たとえば、Bullet Physics や PhysX でも以下のような戦略が採用されている【19】：

オブジェクトの速度推奨モード
Slow-moving objects離散判定（Discrete）
Fast-moving objectsCCD（Time of Impact ベース）

このように動的に判定方式を切り替えることで、処理負荷を最小限に抑えつつ精度を確保できる。

また、Unity の Rigidbody.collisionDetectionMode には
Discrete / Continuous / ContinuousDynamic / ContinuousSpeculative があり、
速度や重要度に応じた設定が可能である【17】。
実務的には、弾丸や車両などの高速体のみ CCD を有効にするのが一般的である。

③ Δt（時間刻み）の動的制御

シミュレーションを安定させるために、フレームレートに依存しない固定物理ステップ（Fixed Timestep）を維持する。
これは Unity 公式の Time 設定でも明記されており、フレーム変動による判定抜けを防ぐ最も確実な方法である【20】。

“A smaller fixed timestep will increase accuracy of the simulation but require more processing power per frame.”
— Unity Manual: Time Settings

必要に応じて Substep（サブステップ）を導入し、
1フレーム内で複数回物理更新を行うことで高速オブジェクトの動きをより正確に追跡できる。
ただしサブステップを増やしすぎるとCPU負荷が増大するため、
開発段階ではログやプロファイラで最適値を計測するのが望ましい。

また、Bullet や Havok などでも同様にサブステップ方式を採用しており、
時間刻み精度と処理コストのバランスが重視されている【19】【21】。

④ 数値精度テストの自動化

テスト段階で float と double の両方を切り替えて挙動を比較し、
判定の閾値がどの程度精度に依存しているかを評価する。
これにより、衝突判定の閾値感度（sensitivity）を可視化でき、
将来的なハードウェア差異（GPU・CPU間の浮動小数点演算仕様差）にも耐性を持たせられる。

この手法は、数値的不安定性の早期発見に特に有効である。
とくにマルチプラットフォーム開発では、x86 と ARM の丸め処理差がバグ再現性に影響するため、
自動テストにおける比較検証は **E-E-A-T 観点からも「実証的知見」**として価値が高い。

5-3. 今後の展望：AIとGPUによる“自律的誤差補正”

近年では、GPUベースの並列物理演算や AI補助物理（Physics ML）によって、
リアルタイムで誤差推定と補正を行う研究が進んでいる。
これにより、衝突判定の誤差を確率的に評価し、動的に補正するシステムが実装可能になりつつある。

たとえば、学習ベースの衝突モデル Neural Collision Fields では、
物理エンジンが“すり抜け”挙動を検知した瞬間に補正ベクトルを推定し、
実時間で位置補正を行う実験的フレームワークが報告されている【22】。

将来的には、AIがプレイヤーの挙動を観測して「あり得ないすり抜け」を自動検出し、
その条件下で物理パラメータを一時的に補正する――
そんな “自律デバッグ”の時代 が来る可能性もある。

この方向性は、単なるエラー防止ではなく、
現実に近い物理世界の再構成という哲学的課題に接続している。
すなわち、**有限計算世界における「再現可能な現実の生成」**である。
（なお、この技術はまだ研究段階にあり、商用ゲームエンジンでの一般実装は未到達である。）

5-4. 結語：バグは理解できる「数理現象」である

衝突判定のバグは、不可解なプログラム上の事故ではない。
それは、有限なデジタル世界が連続的な現実を模倣する際に生じる、**必然的な“境界の揺らぎ”**である。

したがって、真にバグを克服するとは、
単に修正コードを書くことではなく、
なぜその誤差が発生しうるのかを理屈で説明できることである。

この理解があれば、開発者は未知のバグにも動じず、
「この現象はΔtと浮動小数点の干渉で説明できる」と自信を持って再現条件を特定できる。

数学を理解することは、“再現不能なバグ”を“再現可能な理論”に変える力を得ることである。

なお、本稿で扱った「観測できない現象」を、フィクションとして再構成した報告書に
『反復横跳びをしていた友達が段々速くなって消えた』
がある。
そこでは、単純な身体運動が観測限界を越える瞬間に、存在そのものが希薄化していく過程が描かれている。
数理的バグの哲学的帰結として、あわせて参照されたい。

【参考文献】

【1】 Christer Ericson, Real-Time Collision Detection, Morgan Kaufmann, 2005.
【2】 dyn4j Blog: Separating Axis Theorem（SAT） 解説.
【3】 Bullet Physics SDK Manual: Continuous Collision Detection and Time of Impact.
【4】 Unity Manual / API: Rigidbody.collisionDetectionMode, Continuous/ContinuousDynamic/ContinuousSpeculative.
【5】 Unity Manual: Time Settings and Fixed Timestep Configuration.
【6】 Erin Catto, Game Physics: Integration Basics, GDC Lecture, 2013.
【7】 IEEE Standard for Floating-Point Arithmetic (IEEE 754-2019 / ISO 60559:2020).
【8】 Unity Manual: Floating Origin Implementation.
【9】 Unreal Engine 5 Documentation: Large World Coordinates / World Origin Rebasing.
【10】 Erin Catto, Game Physics: Integration Basics, GDC Lecture, 2013.
【11】 Unity Manual: Fixed timestep configuration for physics accuracy（Time Manager）.
【12】 Bullet Physics SDK Manual: Continuous Collision Detection and Time of Impact.
【13】 Unity Manual / API: Rigidbody.collisionDetectionMode（CCDモード一覧）.
【14】 Unity Manual: MeshCollider limitations with CCD（Continuousは静的メッシュに限定）.
【15】 Unity Forums / Discussions: Floating Origin Implementation and Precision Stability.
【16】 Unreal Engine Documentation: Large World Coordinates（World Origin Rebasing / double precision 対応）.
【17】 Unity Manual / API Docs: Physics.defaultContactOffset, Rigidbody.collisionDetectionMode, CCD Modes.
【18】 Unreal Engine Documentation: Physics Settings (Contact Offset Multiplier), Collision Overview.
【19】 Bullet Physics SDK Manual: Continuous Collision Detection and Time of Impact.
【20】 Unity Manual: Time Settings and Fixed Timestep Configuration.
【21】 Erin Catto, Game Physics: Integration Basics, GDC Lecture, 2013.
【22】 Ryan S. Zesch, Vismay Modi, Shinjiro Sueda, David I.W. Levin, “Neural Collision Fields for Triangle Primitives,” ACM SIGGRAPH Asia 2023, DOI: 10.1145/3610548.3618225.

免責事項

本記事は一般的な情報提供を目的としたものであり、記載された数値・事例・効果等は一部想定例を含みます。内容の正確性・完全性を保証するものではありません。詳細は利用規約をご確認ください。