ホワイトペーパー · v1.0 · 2026年8月

サーバー認定リズムパフォーマンススコアリング

時計が嘘をつく市販デバイスの上で、OneDrum はどうやって人間のタイミングを認定するのか——可聴クロック、較正ステップのない較正、ドリフト追跡、較正に盲目にされないアンチスプーフ、そして誰でも検証できるスコア。これが全メカニズムの公開です。ここに書かれたすべては onedrum.io の本番環境で稼働しており、掲載の実データに裏付けられています。

1. 問題

物理的なタップとソフトウェアが見るタイムスタンプの間には、デバイス依存の遅延が積み重なります。タッチ入力遅延(30〜100ms)、音声出力遅延(有線で約30ms、Bluetooth では150〜300ms)、メインスレッドのディスパッチ遅延(実測:中央値0.6ms、最悪10.6ms)。聞こえている音に完璧に合わせて叩いたプレイヤーが、その合計だけ「遅れて」記録される——多くの場合、まっとうな判定窓の幅を超えて。

そしてスコアが娯楽を超えた意味を持つとき、第二の問題が現れます。判定は、不正なクライアントがスクリプトで偽造しうる入力からサーバーが計算しなければならず、しかも遅延補正の仕組み自体が、ボットのメトロノーム的な入力を「人間らしいタイミング」に中心化してしまう資金洗浄経路になってはならない。リズムゲームは第一の問題を明示的な較正画面で解き、第二の問題を無視してきました。OneDrum の設計制約は、両方を、儀式ゼロで解くことでした。

2. アーキテクチャ:クライアントは描画し、サーバーが決定する

すべてのタイムスタンプ——キュー、タップ、リプレイされるプレイヤー——はメディアタイムライン(リファレンスクリップ自身の再生時刻)上にあります。デバイス間の実時間同期は一切不要です。クライアントはタップのタイムスタンプだけを送信し、セッションごとに隔離されたサーバー権限が、純粋関数でユニットテスト済みのスコアリングカーネルで較正・判定・妥当性を計算し、そのランに適用された判定窓を記録した署名付きペイロードとして結果を発行します(検証方法:認定スコア仕様(英語))。

3. 可聴クロック

AudioContext.currentTime はスケジューリングの時計です——サンプルが音声システムに渡された時刻であって、スピーカーから出た時刻ではない。その差は baseLatency + outputLatency:Bluetooth では判定窓を丸ごと超えるほどです。OneDrum は可聴時刻——音声サブシステム自身が報告する「発音済みサンプルと高精度タイムスタンプの対応」から導いた時刻——に対してスコアします:

audibleTime(perfMs) = contextTime + (perfMs − performanceTime) / 1000

これでキューの時刻とタップの時刻が、出力遅延に関係なく同じ基準系を共有します。タップはハンドラが実行された時刻ではなく、入力イベント自身のタイムスタンプ(event.timeStamp)で記録され、最大10msの「偽の遅れ」を除去します。

4. 較正ステップのない較正

較正画面もカウントインもありません。音楽が始まり、最初の1小節がウォームアップに指定されています——他の小節とまったく同じ見た目で。プレイヤーは普通にそれに応え、その応答の生のずれ(delta)がデバイスオフセットになり、以後のすべての採点タップから差し引かれます。ウォームアップはスコアに入りません。1回の応答で足りるのは、判定窓(±120ms)が人間のタップ間ジッター(約25ms)より広いから——1サンプルの不正確さは窓の余白に吸収されます。較正は、プレイの副作用なのです。

ウォームアップで手が滑ったプレイヤーは適応フォールバックが救います。未較正の間、±200ms 以内のニアミスを収集し、5個以上が(収集した全サンプルで σ ≤ 75ms と)緊密に一致し、かつ中央値がデバイスとして妥当(≤180ms)なら、その中央値を採用して現在のタップを再判定——較正を完成させたタップ自身が認定されうる。ガードが構造を支えています:大きさの上限は音楽的な音価より下にあるので、一貫した半拍ズレは「音楽的ミス」であって、決して「補正」されて合格にはならない。分散ゲートにより、散らばったタイミングがオフセットを固定することもありません。

5. ドリフト:較正され続ける較正

本番データ(§7)は、少なくとも一つの主要プラットフォームで、報告される音声遅延がセッション中にドリフトすることを示しました——ウォームアップ小節で正しかったオフセットが、数小節後には古くなっている。設計上の答えがドリフト再センタリングです。較正後、サーバーは直近のずれのスライディングウィンドウを監視し、分散が緊密なまま中央値だけがゼロから歩き去ったとき——時計のドリフトの署名であって、演奏の変化ではない——同じガードの下でオフセットを中央値の方向へ調整します。アンチスプーフのゲート(§6)はこの補正に不変な値で計算されるため、ドリフト追跡が防御を弱めることはありません。

6. 較正に盲目にされないアンチスプーフ

人間のジッターではありえない精度のラン(8タップ以上で σ < 3ms)は too_perfect としてフラグされ、シェアカードもクラウドへのリプレイも拒否され、認定ペイロードに trusted: false として報告されます——隠されるのではなく、報告される。要点はこのテストをどこで走らせるかです。適応較正は一定オフセットの入力列を中心化します——つまり較正後の値で計算した妥当性テストは、一定オフセットのリプレイボットを見逃してしまう。だから妥当性は生のタップ−キュー値——どんな一定オフセットにも不変で、採点用のずれとは別に保存される——で計算します。固定オフセットでタップを再生する機械は、較正がそのスコアを丁寧に中心化した後でも、フラグされたままです。

7. 勘ではなく、フィールドが調整する

判定窓は ±90ms で始まり、仕様書には約束が書かれていました:記録されたずれで調整する。本番の実応答1,234回の後、データが語りました——デスクトップと iPhone は中央値がゼロから7ms以内。Android は51ms早く、ミスは早すぎ119対遅すぎ6——§5を動機づけたドリフトの署名です。窓は現在 ±120ms(120BPM の16分音符ちょうど)で、すべての認定ペイロードが「どの窓で判定されたか」を記録するため、調整が過去のスコアの意味を曖昧にすることはありません。全分析:フィールドノート(英語)、日本語の解説はnote の記事へ。

8. 円陣:検証でゲートされた群衆

採点キューの半分以上を認定され、かつ妥当性ゲートを通過した完走ランは保存され、メディアタイムライン上で——だから位置合わせは完璧に——後のセッションへリプレイされます。ひとりで訪れたプレイヤーも即座に円陣の中で叩くことになり、その円陣はキュレーションされた集団です:リプレイされる全員が、認定済みで、人間として妥当と判定された演奏。誠実なラベリングもメカニズムの一部です:録画されたプレイヤーは「リプレイ」と明示され、ライブと偽らない。運営が播種した合成ストリームは合成マーカー付きで保存され、別ラベルで表示され、実ランより下位にランクされます。将来の同期スタートは、時計の比較を一切せず、単一の相対カウントダウンだけで円陣を複数デバイスへ広げます——認定はメディア相対のまま、時計同期フリーで。

9. ビートの先へ:カーネルの一般化

認定カーネルはゲームに依存しません。以下は出願とロードマップに開示された方向性です。トレーディングフォース:不変テンポでの交互の4小節コール&レスポンス——AIリードでも対人でも——各交換をサーバーが認定。テンポは決して合わせてくれないので、「時間を守ること」自体が課題になります。精密タイマー:サーバーが署名付きで発行するターゲット(オフラインの引き直し不可)、プレイヤー自身の2入力間の間隔として測るスコア(デバイス遅延が相殺されるので較正不要)、試行履歴全体で統計的に判定する人間らしさ。アコースティック演奏評価:マイクで拾った本物のドラム演奏、オンセットは同じタイミング認定へ、機械学習モデルがタイミング以外の技術次元を採点——同じ署名付き結果に合成されます。

付録:実装パラメータ

すべてのパラメータは一点構成の定数で、実デバイスの記録データから調整されます。上記は現行の作業値であり、最適値の主張ではありません。

OneDrum はエンジンと API の名前、Viking Row はその上の最初の体験です。 オペレーターの方からのご質問を歓迎します。 · English version · Field notes · Viking Row を遊ぶ