amBrain
iGamingJan 15, 2026読了7分

ライブベッティングのアーキテクチャ:50ms未満でオッズ更新を処理する

スポーツベッティングエンジンライブディーラーゲームプレイヤー体験カジノプラットフォーム責任あるゲーミングプレイヤー定着率ソフトウェア開発ゲームプロバイダシームレスな統合iGaming業界
画像を読み込めませんでした

多くのオペレーターにとって、インプレイベッティングはスポーツベッティング収益の70%超を占めます。それを支えるアーキテクチャは、毎秒数千件のオッズ変更を、整合性を保証しながら処理しなければなりません。

チャンピオンズリーグ準決勝の89分、ゴールが決まります。3ms以内にカジノプラットフォーム上の該当マーケットがすべて停止し、50ms以内に再計算されたオッズが420万の接続クライアントへ届きます。

この一連の処理に遅れが生じると裁定の余地が生まれ、目の利くベッターに数秒で突かれます。

複数のスポーツデータプロバイダーのフィードを5ms未満で正規化

アーキテクチャの起点は、スポーツデータプロバイダーからのフィードです。プレーごとのイベント、統計の更新、事前計算されたオッズがWebSocket接続で届きます。

複数のゲームプロバイダーのフィードは、同じイベントをそれぞれ異なるレイテンシ、フォーマット、信頼性で配信します。フィードハンドラーに求められるのは次の点です:

  • 3〜5社のプロバイダーからのイベントを、受信後5ms以内に共通フォーマットへ正規化する
  • プロバイダー間で情報が食い違う場合は競合解決を適用します。時間が重要なイベント(得点、レッドカード)は最も速いプロバイダーを、統計データ(ポゼッション、シュート数)は最も正確なプロバイダーを採用します
  • フィード切断をハートビート1間隔、通常1〜2秒以内に検知して復旧します
  • 各イベントにプロバイダーのレイテンシ情報を付与し、下流のシステムが鮮度を適切に重み付けできるようにします

フィードの正規化は、ライブベッティングのパイプラインで最初のボトルネックです。ここでの10msの遅延は、下流のすべてのシステムへ波及します。

画像を読み込めませんでした
ライブベッティングのソフトウェア開発では、すべてのコンポーネントを通じてエンドツーエンドで50ms未満のレイテンシが求められます

事前計算したオッズテーブルとリアルタイム統計モデルを組み合わせる

スポーツベッティングエンジンは、レイテンシ予算の範囲内で数千のマーケットを同時に更新しなければなりません。純粋なリアルタイム計算では間に合いません。

この量をさばくにはハイブリッドな方式を採ります:

  • よくあるシナリオ向けの事前計算済みオッズテーブル:「ホームチームが1点リードしている75分にゴール」といった条件は、計算ではなく参照で解決します
  • 事前計算が現実的でないエッジケースやインプレイのマイクロマーケットには、リアルタイムの統計モデルを用います。推論は10ms未満で完了する必要があります
  • ベイズ更新により、事前計算したベースラインをライブデータで補正し、イベントごとの全面再計算を回避します - これで全マーケット更新の85%をカバーします

残り15%の更新はリアルタイムモデルを通ります。プレイヤー体験は、両方の経路が同じレイテンシの枠内で応答できるかにかかっています。

悪用を防ぐため、マーケットを5ms未満で停止する

ゴールやレッドカードが出た瞬間、影響を受けるすべてのマーケットを即座に停止する必要があります。100msの遅れでも、目の利くベッターが見つけるアービトラージの隙が生まれます。

イベント駆動アーキテクチャは、専用の高優先度チャネルを通じて停止シグナルを伝播させます:

  • 停止メッセージは通常の処理キューを完全に迂回します。スレッドプール、ネットワーク優先度、障害ドメインをいずれも分離します
  • 各メッセージは単調増加するシーケンス番号を持ち、下流のシステムは取りこぼしがないことを検証できます
  • 停止シグナルは更新後のオッズより先にプレイヤー向けの層へ届き、古い価格でのベットを確実に防ぎます
  • 停止したマーケットに対する責任あるゲーミングのチェックも同じ優先チャネルで実行し、不正検知が停止直前の数秒間の異常なベットパターンを検出します

マーケットのサスペンドはレイテンシを一切許容しません。機能ではなく安全機構だからです。

画像を読み込めませんでした
フィールド上の出来事は連鎖的なマーケット更新を引き起こし、接続中の数百万のプレイヤーへ届きます

差分圧縮を用い、WebSocket経由で数百万クライアントにオッズを配信する

更新のたびに数百万の接続クライアントへオッズの全スナップショットを配信すれば、どのようなネットワークも飽和します。差分圧縮により帯域を85-95%削減します。

クライアント側のレンダリングパイプライン:

  • WebSocket接続で差分更新を受け取り、プレイヤー端末のローカルオッズキャッシュに適用します
  • オプティミスティックUIにより、プレイヤーは表示中のオッズでベットでき、公正性と規制順守はサーバー側の検証が担保します
  • 古いデータの検知により、想定間隔内に更新されていないオッズを可視化し、陳腐化した価格でのベットを防ぎます
  • モバイルアプリではネットワーク状況が常に変動します——シーケンスに欠落が生じた場合、クライアントは完全なスナップショットを要求し、可能な場合は取りこぼした差分を再適用します

ライブ試合中の再接続をまたいでセッション状態を保持する

試合中にWebSocketが切断されても、ベットスリップが失われてはなりません。プレイヤー管理システムは、プレイヤーセッションに紐づけてベットスリップの状態をサーバー側で保持します。

チャンピオンズリーグ決勝では、モバイル利用者がWiFiとセルラーを行き来するため再接続率が急増します。セッション層はその負荷を吸収しなければなりません:

  • ミリ秒未満で読み出せるRedisベースのセッションストアは、ベッティングエンジンとは独立してスケールします
  • 再接続フローでは、現在のベットスリップとオッズの全スナップショットを1往復で取得します
  • ロイヤルティプログラムとフリースピンの状態はベットスリップとともに復元され、プレイヤー体験がそのまま再開します
  • セッションの失効は切断ではなく15分の無操作タイマーで判定します。短時間のネットワーク断で状態が消えることはありません

責任あるゲーミングとコンプライアンスのチェックをライブパイプライン内で実行する

入金上限、セッションタイマー、負け追い検知は、ゲーム体験を損なうことなくライブベッティングのパイプライン内で動作します。

ブロッキングチェック(入金上限、自己排除の状態)はインメモリキャッシュから読み取り、2ms未満で完了します。行動スコアリングはイベントストリーム上で非同期に実行し、プレイヤーの嗜好とベットパターンから問題行動の兆候を分析します。

ライブディーラーゲームとオンラインカジノゲームは、同じカジノプラットフォーム上で共通のアーキテクチャパターンを持ちます。リアルタイムのイベント処理、即時の状態伝播、そしてプレイヤー体験に体感できる遅延を加えないコンプライアンスチェックの統合です。

iGaming業界では、ピーク時のイベント中も、責任あるゲーミングの基盤がベッティングエンジンと同じようにスケールすることが求められます。処理が追いつかないコンプライアンス基盤は、性能上の問題ではなく規制上のリスクです。

手元に似た設計はありますか?

現在のアーキテクチャと気になっている障害シナリオをお持ちください。30 分で一緒に確認します。