Source engineサーバーに必要なハードウェアとネットワーク要件

Source engineサーバーに必要なハードウェアとネットワーク要件

Source Engineサーバーのハードウェアおよびネットワーク要件に関する情報。

July 26, 2026約 9 分で読めますJuly 26, 2026 に更新
Source engineサーバーに必要なハードウェアとネットワーク要件

Source engineは、Valveが開発した3Dビデオゲームエンジンです。Source engineは物理演算、AI、グラフィックスの進歩で有名で、当時としてはリアルなゲームを実現しながらも、古く性能の低いハードウェアでもスケーラブルに動作しました。Source engineのサーバーとは、プレイヤーが接続してサーバーのワールド内で一緒にプレイできるホスト型のゲームサービスです。Source engineのサーバーはmodによってカスタマイズでき、接続している全プレイヤーにとって独自の、そしてしばしば楽しいゲームプレイ体験をもたらします。

Source engineで動作するゲームには、Team Fortress 2、Counter-Strike: Source、Garry's Modなど、多数あります!

よく聞かれる質問は、Source engineサーバーを運用するために必要なハードウェアおよびネットワーク要件は何か、またMinecraftやRustといった他のゲームのサーバーとどう比較されるか、というものです。この質問への答えは、本当に場合による、ということです。

Source engineサーバーはMinecraftやRustといった他のゲームに比べてRAM使用量がはるかに軽い一方で、ほとんどシングルスレッドです。つまり、コア数が少なくてもシングルスレッド性能が高いプロセッサの方が、コア数が多くてもシングルスレッド性能が低いプロセッサよりも、Source engineサーバーにおいては良いパフォーマンスを発揮するということです。これは特に、負荷の高いゲームモードをホストする予定がある場合や、サーバーに一度に多くのプレイヤーを接続させたい場合に当てはまります。

とはいえ、ハードウェアとネットワークの要件を決める際に考慮すべき追加の要素を以下に挙げます。

  • サーバーに一度に接続してプレイするプレイヤーのピーク人数。
  • サーバーが実行するゲームモード、modの量、およびマップの種類。
  • サーバーのtickrate。
  • サーバーのパフォーマンス関連のConVar値。

絶対的な最高のパフォーマンスを求めていて、資金に余裕があるなら、個人的にはPassmarkのシングルスレッド性能ベンチマークで高評価を得ているようなCPUを搭載したサーバーを探すことをおすすめします。

同時接続プレイヤー数

サーバーに一度に接続するプレイヤーが多いほど、各クライアント間でやり取りされるネットワークデータが増え、通常はゲームおよびサーバー自体で行われる処理も増えるため、CPU使用率が高くなります。

シングルスレッド性能とプレイヤー数についての一般的なガイドラインや目安は、他にも変数が多すぎるため存在しませんが、サーバーに一度に多くのプレイヤーを接続させる予定がある場合は、シングルスレッド性能の高い、より新しいCPUを入手するようにしてください。

ゲームモード、modの量、マップの種類

これらは、必要なサーバー要件を決める上で非常に重要な要素です。例えば、Counter-Strike: SourceのDeathmatchのように、プレイヤーが絶えず撃ち合い、リスポーンし、走り回るゲームモードを実行しているサーバーは、プレイヤーが死んでも次のラウンドまでリスポーンしないゲームモードを実行しているサーバーよりも、多くのリソースを消費する可能性が高いです。

とはいえ、近接戦闘向けのマップや物理プロップを多用するマップは、より広く開けたマップよりも多くのCPUパワーを消費する可能性が高いです。

サーバーのTickrate

tickrateとは、サーバーがゲームをシミュレートする頻度のことです。デフォルトでは、サーバーのtickrateは66.66...(15msごと)に設定されています。この値は、ゲームやmodがサーバー管理者による変更を許可している場合、サーバーの起動コマンドで-tickrateコマンドライン引数を使用して変更できます。

サーバーのtickrateが高いほど、必要なCPUパワーと帯域幅が増加します。これにより、サーバーがクライアントとの間で送受信する更新データの量も増え、クライアントのレイテンシやヒット判定などが改善されます!

Garry's Modには、一度に128人ものプレイヤーをホストできるサーバーが数多く存在します。これは、33や22といった低いtickrate値で運用しているため実現できており、これはほとんどの場合(もちろんサーバーにもよりますが)CPUが一般的なサーバー負荷を処理するのに十分低い値です。

サーバーのパフォーマンス関連ConVar値

サーバー上で変更できる、パフォーマンスに関連するConVarがいくつかあり、これらはサーバーが消費するCPUと帯域幅の量に影響します。とはいえ、これらの設定はクライアントのレイテンシ、パケットロス数、チョークなどにも影響を与える可能性があります。

以下は、私が最も有益だと感じたパフォーマンス関連のConVarの一覧です。

  • sv_maxrate - サーバー上でクライアントに許可される最大帯域幅レート(受信・送信両方)を「バイト」単位で指定します。0に設定すると無制限を意味し、ネットワークとハードウェアの容量が十分にある場合に推奨されます。
  • sv_minrate - サーバー上でクライアントに許可される最小帯域幅レート(受信・送信両方)を「バイト」単位で指定します。
  • sv_maxupdaterate - サーバーがクライアントに送信できるupdateパケットの最大数(1秒あたり)。通常はサーバーのtickrate値と同じですが、CPU負荷や帯域幅使用量を下げるために低く設定される場合もあります。
  • sv_minupdaterate - サーバーがクライアントに送信するupdateパケットの最小数(1秒あたり)。通常は0からサーバーのtickrate値の半分(例:33)の間で設定されます。
  • sv_maxcmdrate - サーバーがクライアントに送信できるcommandパケットの最大数(1秒あたり)。通常はサーバーのtickrate値と同じですが、CPU負荷や帯域幅使用量を下げるために低く設定される場合もあります。
  • sv_mincmdrate - サーバーがクライアントに送信するcommandパケットの最小数(1秒あたり)。通常は0からサーバーのtickrate値の半分(例:33)の間で設定されます。
  • net_splitpacket_maxrate - サーバーがクライアントに分割パケットを送信できる最大バイト数(1秒あたり)。大量のネットワークデータが一度に送信される状況でchoke(詰まり)が発生する場合、128000のような高い値に設定すると改善が見込めます。
  • net_maxcleartime - サーバーが1回のtick内でネットワークデータの処理と送信に費やす最大時間(秒)。0.001のような低い値に設定すると特定の状況でchokeを減らせますが、その分CPUパワーが必要になります。
  • sv_parallel_sendsnapshot - 1にすると、サーバーが各クライアント用のゲーム状態スナップショットの準備に別スレッドを使用できるようになります。プレイヤー数が多い環境ではサーバーパフォーマンスが大幅に向上する場合があります。

これらの値をどう設定すべきかをより深く理解するために、Source Multiplayer Networkingを読むことをお勧めします。また、NFOservers.comのこのトピックも非常に有益で参考になりました!

専用ホスティングプロバイダーを利用している場合、おそらくこれらのConVar値を高い値/無制限に設定できるだけのネットワーク容量があるはずです。その場合、以下の値がほとんどのケースで機能するはずです。

sv_maxrate 0
sv_minrate 75000
sv_maxupdaterate 66
sv_minupdaterate 20
sv_maxcmdrate 66
sv_mincmdrate 20
net_splitpacket_maxrate 128000
net_maxcleartime 0.001
sv_parallel_sendsnapshot 1

これらのパフォーマンス関連のConVarをどの値に設定すべきかまだよく分からない場合は、このツールのようなものを使って値を計算することをお勧めします。また、SpeedTest.netやCloudFlareなどのツールでネットワークスピードテストを実行し、サーバーのアップロード・ダウンロードのネットワーク速度を確認することも推奨されます。これらのネットワーク速度は、パケットロストなどのネットワーク関連の問題に陥る前に、同時に何人のプレイヤーをサーバーに接続できるかに大きく関わってきます(特にアップロード速度は、インターネット経由で全プレイヤーに一度に送信できる帯域幅の量を示すため重要です)。

サーバーパフォーマンスの監視

Sourceエンジンのゲームでサーバーパフォーマンスを監視するのに最適なゲーム内ツールは、組み込みのNet Graphです。デベロッパーコンソールでnet_graphの値を0から4に変更することでネットグラフを表示できます。

このツールは、接続しているサーバーとの間で送受信している帯域幅の量、サーバーのFPS、あなたとサーバーが送受信しているアップデートの量などを表示します!

Net Graphのより詳しい説明はこちらにあります。

以下は、前述のWikiページからの情報です:

Net Graph Image

エリア1

このエリアは、グラフのペイロード部分で使用されている色の凡例です。ペイロードの一部が届いても、あらかじめ決められたバケットに収まらない場合、最後の色と全パケットサイズを示す小さな白い点(画像のインジケーターaを参照)の間の透明な領域に表示されます。

エリア2

95パーセンタイルに含まれる300バイトより大きいパケットについては、そのパケットサイズがペイロード領域の上部にテキストで表示されます(マーカー2を参照)。なお、Orange Box技術ではパケットに圧縮が使われていますが、net_graphのペイロードで報告されるサイズは、展開後のペイロードサイズに基づいています。

エリア3

ローカル接続のフレームレート(FPS)とサーバーへのラウンドトリップpingがエリア3に表示されます。

エリア4

このエリアは現在の帯域幅使用量を表示します。in/outは、最後に受信・送信したパケットのバイト単位のサイズを示します。k/sは、各方向で最近観測された(移動平均の)キロバイト/秒を示します。

エリア5

このエリアは、クライアントが接続しているサーバーのパフォーマンスを表示します。svタグは、クライアントに配信された最新のネットワーキングアップデート時点でのサーバーのFPSを示します。varは、サーバーが記録した直近50フレームにおけるサーバーのフレームタイム(server fps = 1.0 / frametime)の標準偏差を示します。サーバーのフレームレートが20fps未満の場合、この行は黄色で描画されます。10fps未満の場合は赤色で描画されます。

エリア6

lerpインジケーターは、クライアントが使用している補間のミリ秒数を示します。lerpの値についての補足は以下の通りです。

Area 7

このエリアは、ユーザーの現在の cl_updaterate 設定、サーバーから実際に受信している更新の秒間実数、サーバーへ実際に送信しているパケットの秒間実数、そしてユーザーの cl_cmdrate 設定(ユーザーがサーバーへ送信したいパケット数の希望値)を表示します。

Area 8

net_graphshowlatency が1の場合、このエリアは接続のレイテンシーの履歴表示を示します。高さ(マーカー d で示されている)は net_graphmsecs の時間に対応します(実際には、テキストフィールドが収まるように net_graphmsecs の上に少し余裕があります)。赤い縦線は、サーバーからクライアントへドロップされたパケットを示します。グラフに黄色いマーカーが表示されている場合(マーカー c のような)、これはサーバーがクライアントへ更新を送信する前に、1つ以上のパケットをチョーク(抑制)しなければならなかったことを示しています。

Area 9

net_graphshowinterp が1の場合、このエリアはクライアントの各フレームごとに、どれだけの補間(インターポレーション)が必要だったかを表示します。パケット間に大きなギャップがある場合(パケットロス、サーバーのフレームレートが低すぎる、など)、クライアントは補間に必要なデータが不足し、外挿(エクストラポレーション)を開始します。外挿はオレンジ色のバーとして白い線の上に表示されます(9のマーカーのすぐ左に、外挿が連続している様子が見られます)。さらに、最下部のピクセルは、そのレンダリングフレームで CUserCmd(usercmd)パケットが送信されたか、あるいはユーザーの cl_cmdrate 設定によりクライアント側で保留・集約されたかを示します。

専用ホスティング VS LANサーバー

ホームネットワーク(LAN)上で公開サーバーをホストすることはできますが、推奨されません。代わりに、専用ホスティングプロバイダーからサーバーを購入するべきです。

専用ホスティングにしばしば付随するサブスクリプション制の料金は、大きな欠点と見なされることが多いですが、専用ホスティングを使う理由には以下のようなものがあります。

  • より高いネットワーク容量と、攻撃対策専用に設計された緩和システムのおかげで、(D)DoS攻撃からより良い保護が得られる。
  • より良いクライアントルーティングとレイテンシー。
  • より安定している(例えば、家で停電が発生してもサーバーがオフラインにならない)。

さらに、自宅でサーバーをホストしない方が良い理由もいくつかあります。

  • 一部のISPは、ホームネットワーク上での公開ゲームサーバーのホスティングを禁止しています。
  • 実行しているサーバーの数、サーバーの負荷、サーバーのプロセッサなどによって、自宅の電気代とネットワーク帯域幅のコストが高くなります。

関連項目

https://moddingcommunity.com/blog/how-to-download-run-steamcmd/

まとめ

これでこのガイド/ナレッジベースの記事は終わりです。これで、Source engineサーバーを運営する際に必要となるハードウェアとネットワークについて、より理解が深まったはずです。

このガイドに関する質問やフィードバックがある場合は、こちらのフォーラムトピックに返信してください!このガイドは今後も随時作業・改善が加えられていきます。

私たちのDiscordサーバーに参加しよう!

コメント (0)

コメントするにはログインしてください。

読み込み中…

もっと見つける

投稿

読み込み中…

最近のアクティビティ

読み込み中…
コミュニティへ