オンライン対戦のサーバー費用：無料枠で何人まで同時接続できるか

無料枠を決める二つの軸

サーバー費用を考えるとき、多くの人が「同時接続数」だけを気にします。しかし実際には、もう一つの軸である「月間転送量（帯域）」がボトルネックになるケースが少なくありません。

同時接続数は、ある瞬間にサーバーと通信しているクライアントの数です。対戦ゲームでは1試合に2人以上が常時接続するため、試合数が増えるほど直線的に伸びます。100人が同時にプレイしていれば少なくとも100接続、試合外のロビーも含めればさらに増えます。

月間転送量は、1か月間にサーバーが送受信したデータの合計です。対戦中の座標・入力・状態同期を毎秒送り続けると、1接続あたりのデータ量は小さくても積み上がります。1試合10分・毎秒1kBのメッセージであれば1試合で約600kB、月に1,000試合なら約600MBです。無料枠が月1GBのサービスであれば、この規模でも余裕がありますが、ゲームが人気になって月1万試合になると6GBになり、無料枠を超えます。

判断の出発点として、自分のゲームが「同時接続が先に上限に達するか」「転送量が先に上限に達するか」を粗く見積もっておくことが重要です。

主なサービスの無料枠の構造

WebSocket対応のサーバーを無料で使う選択肢は大きく三つのカテゴリに分かれます。

マネージドなリアルタイム通信サービス

Ably、Pusher、PubNub、Supabase Realtimeなどが代表例です。接続管理・スケーリング・再接続処理をサービス側が担うため、自分でWebSocketサーバーを書く必要がありません。

無料枠は「月間メッセージ数」や「同時接続ピーク数」で制限されます。同時接続の上限は数十から数百の範囲のサービスが多く、小規模なゲームや開発・テスト段階では十分です。ただしメッセージ数の制限は意外と厳しく、頻繁に状態を送るゲームでは月の中盤に上限に達することがあります。

コンテナ・PaaS型のサーバー

Render、Fly.io、Railway、Koyebなどは、Node.jsやGoで書いたWebSocketサーバーをそのままデプロイできます。無料枠はCPU時間・メモリ・転送量で定義されることが多く、接続数の直接制限はありません。

注意点は「スリープ」です。一定時間アクセスがないとインスタンスが停止し、次のリクエストで起動するまでに数秒から数十秒かかります。ゲームのマッチングや接続開始のタイミングでこの遅延が出ると体験が悪くなるため、無料枠のまま常時起動を維持できるかどうかを事前に確認する必要があります。

サーバーレス・エッジ関数

Cloudflare WorkersのDurable Objectsは、エッジで状態を持ちながらWebSocket接続を維持できる比較的新しいアプローチです。無料枠はリクエスト数とDurable Objectのストレージ使用量で管理されます。レイテンシが低い反面、実装の学習コストが高く、長時間の接続維持に関してはコスト計算が複雑になります。

同時接続数の目安と判断基準

「無料枠で何人まで」という問いへの現実的な答えは、「構成によって10人から数百人まで幅がある」です。ただし、次の基準で判断できます。

まず、同時接続が常時50以下の規模であれば、マネージドサービスの無料枠に収まる可能性が高いです。週末のみ公開する小規模ゲームや、クローズドなテスト運用がこの段階に当たります。

次に、同時接続が100〜300程度を想定する場合、マネージドサービスではメッセージ数上限が先に来ることが多く、PaaS型で自前のサーバーを動かす方が制御しやすくなります。この規模では転送量の見積もりが特に重要で、1接続あたりの月間転送量を計算してから無料枠と比べます。

常時300を超える同時接続を目指す場合は、実質的に無料枠の範囲を超えると考えた方が安全です。ただし、試合ルームを適切に分離し、接続が切れた際に再接続する仕組みを作ることで、1サーバーあたりの負荷を下げながらコストを最小化できます。

費用を抑えるための構成の考え方

同時接続数を抑える最も有効な手段は、接続している時間を短くすることです。試合中だけWebSocketを開き、ロビーやメニュー画面ではHTTPのポーリングや軽量なSSE（Server-Sent Events）に切り替えるだけで、同時接続数は大幅に減ります。

次に有効なのが、送信頻度の調整です。毎フレーム（60fps）送信するのではなく、入力変化があったときだけ送る差分送信、または10〜20fps相当に間引くことで、転送量を数分の一に抑えられます。

また、部屋（ルーム）の概念を持たせることで、サーバーが管理する接続の単位を小さくできます。2人対戦なら1ルーム2接続という単位で考え、ルーム数の上限を無料枠から逆算して設定すると、突発的なスパイクが起きても費用が跳ね上がりにくくなります。

開発中はローカルでサーバーを動かし、本番デプロイは本当に人に見せるときだけにするのも有効です。PaaS型サービスのインスタンスをデプロイしたまま放置すると、転送量や起動時間の無料枠を開発中に消費してしまいます。

無料枠を超えたときの対処

無料枠を超えた場合の選択肢は三つです。有料プランへの移行、別サービスへの移行、または機能の制限です。

有料プランへ移行するかどうかの判断基準は、「ゲームの同時接続数がどのくらいの頻度で無料枠を超えているか」です。月の数日だけ上限に達し、それ以外は余裕があるなら、アクセス集中の時間帯を分散させる工夫（例：招待制の先行公開、時間帯を絞ったイベント対戦）で解決できることもあります。

恒常的に上限を超えるようであれば、それはゲームが実際に使われているサインでもあるため、有料プランの最低コストと想定収益・広告収入を比較して判断するのが現実的です。

次の行動

まずは自分のゲームの「1試合の平均時間」と「1秒あたりの想定メッセージ数」を書き出し、月間転送量を粗く計算してみてください。その数値を持って各サービスの無料枠の条件を公式サイトで確認すると、どのサービスが合うかが具体的に絞られます。実装が完成したらアソバースにZIPまたはHTMLファイルとして投稿し、実際のプレイ環境での接続数を確かめてみてください。

参考資料

• Ably 公式ドキュメント（Pricing・Connection limits）
• Pusher Channels 公式ドキュメント（Free plan limits）
• Render 公式ドキュメント（Free tier / Sleep behavior）
• Fly.io 公式ドキュメント（Free allowances）
• Cloudflare Durable Objects 公式ドキュメント（Pricing）
• MDN Web Docs — WebSocket API