権威サーバーと状態レプリケーション

なぜ「サーバーが正本を持つ」ことがすべての出発点なのか

リアルタイムマルチプレイヤーの根本課題は、物理的に離れた複数の機械が、光速の制約による遅延の中で、同一のゲーム世界を矛盾なく共有することです。素朴に「各クライアントが自分の状態を計算して他者に通知する」構成にすると、二つの致命的問題が生じます。第一に、遅延で状態がずれたとき「どちらが正しいか」を決められない（分岐した現実が併存する）。第二に、クライアントが送ってくる値を信じるしかなく、改造クライアントが「自分は当たっていない」「ダメージは0だ」と嘘をつけば防げません。

サーバー権威（authoritative server）モデルは、この両方を一手で解きます。ゲーム状態の正本（source of truth）はサーバーだけが保持し、クライアントはプレイヤーの入力（input）——押されたキー、狙った方向、撃った瞬間——だけを送ります。サーバーはその入力をゲームシミュレーションに適用し、当たり判定・ダメージ・アイテム取得などの結果を確定して、各クライアントへ配り返します。クライアントは受け取った状態を描画するだけの存在に近づきます。矛盾は起きえず（正本は一つ）、クライアントの主張はサーバーが検証するため嘘が通りません。

クライアント予測と再調整：往復遅延を隠しつつ整合性はサーバーに委ねる

サーバー権威を素直に実装すると、自機を動かすたびに入力送信→サーバー処理→結果受信の往復（RTT）を待つことになり、100ms級の操作遅延が体感されます。これは許容できません。そこでクライアント予測（client-side prediction）を導入します。クライアントは自分の入力をサーバーへ送ると同時に、同じシミュレーションをローカルでも即座に実行し、自機を先に動かして見せます。多くの場合サーバーも同じ結果を出すので、遅延は体感上消えます。

問題は、サーバーの確定結果がローカル予測とずれたとき（他プレイヤーとの衝突、外乱、モデル差）です。ここで再調整（server reconciliation）が働きます。クライアントは送った入力すべてに連番（シーケンス番号）を付けて保存しておきます。サーバーは状態を返す際「どの入力番号まで処理済みか」を併せて通知します。クライアントはその確定状態を土台に据え、まだサーバーに確認されていない入力を確定状態の上へ再適用（replay）して現在位置を作り直します。予測が正しければ位置は変わらず、ずれていればこの再適用で滑らかに正しい位置へ寄っていきます。

他プレイヤーの表示は別の扱いになります。自機は予測しますが、他者の入力は手元にないため予測できません。到着済みの複数スナップショットの間を描くエンティティ補間（interpolation）で滑らかに見せ、意図的に約100〜200ms過去を描画します。パケットが途切れて次のスナップショットが未着のときだけ、速度を延長する外挿（extrapolation／dead reckoning）で当座をしのぎますが、外挿は当たると危険な推測なので短時間に限ります。撃った側と撃たれた側の時間軸のずれは、サーバーが撃った瞬間の過去状態へ巻き戻して判定するラグ補償（lag compensation）で吸収します。

状態スナップショットとデルタ圧縮：帯域を桁で削る

横にスクロール

サーバーは全クライアントへ毎ティック状態を送りますが、ゲーム世界の全エンティティを毎回フルで送れば帯域が破綻します。ここで効くのがスナップショット＋デルタ圧縮（delta compression）です。基本発想は「前回そのクライアントが確実に受け取った状態（ベースライン）と、今の状態の差分だけを送る」こと。動いていないオブジェクトや変化のないフィールドは送らず、変わった値だけをビットに載せます。

デルタ圧縮の基本ループ（サーバー側・クライアント別）:

  1. クライアントごとに「確認済みの最新スナップショット番号」を保持
  2. 現在のスナップショット S_now と、その確認済み S_ack を比較
  3. フィールド単位で S_now と S_ack が異なる箇所だけをエンコード
        → 変化ビットマスク + 変化した値のみ送信
  4. パケットに「基準にした S_ack の番号」を明記して送る
  5. クライアントは受信デルタを S_ack へ適用して S_now を復元し、
     受信を確認（次回のベースラインになる）

  ※ UDP前提。デルタは「特定のベースラインからの差」なので、
    どのスナップショットを基準にしたか（番号）が一致しないと復元不能。

デルタと直交して効くのが量子化（quantization）です。座標を32bit浮動小数のまま送る必要はなく、マップの範囲と要求精度から必要ビット数を割り出し、整数に丸めて送ります（例：位置を1cm刻みの固定小数に、回転角を10〜12bitに）。値の範囲が既知なら情報量は激減します。さらに関心領域（Area of Interest／relevancy）によるフィルタで、そのプレイヤーから見えない・遠すぎるエンティティは配信対象から外します。これは帯域削減であると同時に、壁の向こうの敵情報をクライアントへ送らないことでウォールハック（wallhack）系チートの成立余地を断つセキュリティ施策でもあります。

チート対策：権威モデルは前提であって万能ではない

サーバー権威は最強のチート対策基盤ですが、それだけで完結はしません。「クライアントから来る値は一切信用せず、常に検証する」という原則を各所に貫く必要があります。移動なら、クライアントが申告した新座標をそのまま採用せず、前回位置・経過時間・最大速度から到達可能かをサーバーが検算し、逸脱すればスピードハックとして棄却・巻き戻します。射撃なら、ダメージ量はサーバーが武器データから決め、クライアントの申告は使いません。前述の関心領域フィルタで見えない情報を送らないことは、情報系チートへの構造的な防御になります。

クライアント側の対策（アンチチートによるメモリ改ざん・不正プロセス検知）は補助であり、根拠にはできません。理由は明快で、クライアントは攻撃者の完全な支配下にある機械だからです。サーバー側検証を主、クライアント側検知を従とし、さらに統計的な異常検知（人間には不可能なエイム精度・反応速度）でカバーするのが実務の多層防御です。

まとめ

権威サーバーモデルは、ゲーム状態の正本をサーバーだけに持たせ、クライアントを「入力を送り結果を受け取る」存在に限定することで、分岐した現実を排し、クライアントの嘘を無効化します。素直に実装すると操作遅延が問題になるため、自機はクライアント予測で即座に動かし、入力を連番で保存し、サーバー確定状態の上へ未確認入力を再適用する再調整で、遅延を隠しつつ最終的な整合をサーバーへ委ねます。他プレイヤーは過去のスナップショット間を補間で描き、未着時のみ短時間の外挿で補い、撃ち合いの時間差はラグ補償で吸収します。帯域は、ack済みベースラインとの差分だけを送るデルタ圧縮、範囲既知の値を整数に丸める量子化、見えないエンティティを配らない関心領域フィルタの三段で桁単位に削ります。通信はUDPを基盤に信頼性を選択的に自前設計します。そしてチート対策の根幹は「クライアントの申告を一切信用せず、移動・ダメージ・可視性をサーバーで常に検証する」ことにあり、クライアント側アンチチートはあくまで補助です。低遅延・公平性・帯域効率・改ざん耐性という互いに衝突しがちな要求を、これらの技法の組み合わせで同時に満たすのがネットコード設計の核心です。関連する基盤として、UDP/TCPやパケット挙動はネットワークのトピック、改ざん耐性やアンチチートの位置づけはセキュリティのトピック、補間・外挿の描画側の質はグラフィックスのトピックも参照してください。