ハートビートが解決する問題
最も見つけにくいチートは、アンチチートのクライアントを静かに無効化してから、誰にも見られずに動くものです。シグネチャチェックはフックできます。NUIの検査はブロックできます。ランタイムの整合性関数はno-opにパッチできます。クライアント層がいったん沈黙すれば、単層のACには何も見えません。ハートビート改ざん検知は、その「沈黙」を高くつくものにするために存在します。ハートビートがないこと自体が検知だからです。
ハートビートのループの仕組み
Ravenのクライアントは、一定の間隔で署名付きのペイロードを送ります（サーバーごとに可変。2026-02-17の更新履歴を参照。以前は1500msで固定でした）。ペイロードには重要なランタイム状態（リソースの整合性、フックテーブルのフィンガープリント、イベントハンドラーのアドレス）の暗号学的ハッシュに加えて、タイムスタンプとセッションごとのnonceが含まれます。サーバーは署名を検証し、ハッシュを期待されるベースラインと比較して、到着間隔を記録します。検出される失敗は3種類です。ハートビートが届かない（沈黙したクライアント）、ハートビートは届くがペイロードが期待値と一致しない（改ざんされたクライアント）、ハートビートの間隔が正しくない（リプレイまたは古いクライアント）。
間隔が重要な理由
固定のハートビート間隔は回避しやすくなります。ハートビートとハートビートの間だけクライアントを無効化するチートは、ループを生かしたまま見られずに動けます。サーバーごとに可変の間隔（最初の24時間の平均tickレイテンシで調整）にすると、その隙間はチート側から予測できなくなり、遅延の大きい経路にいる正規のプレイヤーにも問題を起こしません。2026-03のリリースでデフォルトの間隔を固定1500msから可変800〜1500msの範囲に組み直したところ、EU/AS経路での誤検知が約38%減りました。
ハートビートが失敗したときに起きること
失敗時の対応は、サーバーごとに3段階で設定できます。第1段階（警告）はライブマップ上でそのプレイヤーに印を付け、設定したDiscord Webhookで管理者に通知します。第2段階（KICK）は一般的な切断理由でプレイヤーをサーバーから落とし、完全な証拠（最後の有効なハートビート、現在のタイムスタンプ、ペイロードの差分）とともにイベントを記録します。第3段階（自動BAN）はローカルのサーバーでそのプレイヤーをBANし、管理者のレビュー後にグローバルBANデータベースへ昇格させるキューに入れます。ハートビート層は通常のネットワーク不調でも誤検知を出しうるため、デフォルトの設定は控えめです（まず警告し、繰り返した場合にだけ段階を上げます）。
ハートビートと信頼スコアの関係
ハートビートの異常はそれぞれ、プレイヤーごとの信頼スコアに反映されます（バージョン2026.4.0で導入。/changelogを参照）。1回の遅延はノイズです。同じプレイヤーから複数のセッションにまたがって遅延が続く、特定のゲーム状態に入ったときにだけハートビートが遅れる、リソースパックが更新されたのに同じハッシュを返し続ける。こうしたものはすべて、第3段階のBANが1件出るよりずっと前に、管理者のレビュー用としてそのプレイヤーをライブマップに浮かび上がらせるシグナルです。