ゲームラグ白書 › 症状から探す

入力遅延：原因76件と担当

別名：反応が遅い、もっさり、操作が重い、手応えがない

図のあるメインページの症状辞典で開く →

押してから結果が出るまでに時間がかかります。画面そのものは滑らかな場合もあります。

スキルボタンを押すと0.2〜0.5秒後に発動。アイテムを拾う、会話、取引のようにサーバーの確認を待つ操作が遅くなります。

往復時間（Ping）が長いか、どこかでキューが詰まっています。距離、ルーターのキュー、Nagle（小さなパケットをまとめて送るTCPの機能）、サーバーのキューを確認します。Pingが低いのにいつも操作が重いなら、V-Sync・低いFPSのような自分のPC側か、操作のたびにサーバーの確認を待つ設計（同期方式の章）を疑います。

この症状を引き起こす原因

L1 クライアントのゲームプロセス

• 大人数の描画負荷: 攻城戦やワールドボスのように数百人が1つの画面に入ると、描画のコストそのものが処理しきれなくなります。 (ゲーム開発チーム・クライアント開発)
• メインスレッドのパケット処理ボトルネック: 受信したパケットをフレームごとに決まった量しか処理しないと、押し寄せたパケットがどんどん次のフレームへ持ち越されます。 (ゲーム開発チーム・クライアント開発)
• V-Syncとレンダーキュー: GPUが描画したフレームを何枚かキューにためておき、モニターの周期に合わせて出力する間、入力が遅れます。 (ゲーム開発チーム・クライアント開発)

L2 クライアントのOS・端末

• 省電力モード・サーマルスロットリング: ノートPCのバッテリーモード、スマホの省電力モード、端末の発熱によって、CPU・GPUの速度が落ちます。発熱の場合は、最初は問題なく、しばらくしてから重くなるのが特徴です。 (外部・外部)
• 同じ端末の他のアプリによる帯域幅の占有: クラウド同期、大容量のダウンロード、ゲームのアップデートが同じPCで動いていると、ゲームのパケットがキューで待たされます。 (外部・外部)
• ディスプレイ・入力デバイス・フレーム生成による遅延: Pingは正常なのに操作が重いなら、テレビの映像処理やワイヤレスコントローラー、フレーム生成機能が、入力と画面の間に遅延を上乗せしているのかもしれません。 (外部・外部)

L3 家庭内ネットワーク

• Wi-Fiチャンネルの混雑: マンションのようにルーターが数十台ある場所では、同じチャンネルを分け合って使うため、送信の機会を待つことになります。 (外部・外部)
• バッファブロート（ルーターのキュー）: 家族の誰かが動画をアップロードしたり大きなファイルをダウンロードしたりすると、ルーターのキューに数百ms分のパケットがたまり、ゲームのパケットもその後ろで待たされます。 (外部・外部)
• RRC状態遷移の遅延（モバイル無線の省電力）: スマホはしばらく通信がないと無線接続を低電力状態に落とし、次のパケットのときに再び立ち上げるため遅れます。 (ゲーム開発チーム・クライアント開発)

L4 インターネット回線

• 伝搬遅延（物理的な距離）: 光ファイバーの中では、光でさえ1秒に約20万kmしか進みません。遠いサーバーは、どれほど性能が良くても遅れます。 (インフラチーム・サーバーインフラ)
• 衛星インターネット（低軌道・静止軌道）: 衛星インターネットは電波が宇宙を往復するため、静止軌道衛星では往復だけで0.5秒を超えます。Starlinkのような低軌道衛星は普段は速いものの、経路を割り当て直す瞬間に遅延が揺れ、一瞬途切れることもあります。 (外部・外部)
• 迂回ルーティング: 通信事業者どうしの接続契約の都合で、近いサーバーでも遠くを回って届きます。 (インフラチーム・ネットワークインフラ)
• 海底ケーブル・国際回線の障害: 海底ケーブルが切れると、修理されるまでの数週間（長ければ数か月）は遠い迂回経路を回ることになり、残った回線は混雑します。 (外部・外部)
• 通信事業者の速度制限・トラフィック管理: データ使用量の上限を超えた場合や、特定のトラフィックを管理する料金プランでは、パケットが遅らされたり破棄されたりします。 (外部・外部)
• VPN・ラグ軽減ツール経由: VPNやラグ軽減ツールを使うと、パケットはその会社の中継サーバーを経由します。中継サーバーが遠かったり混雑していたりすると、かえって遅くなります。 (外部・外部)

L5 データセンターのネットワーク機器

• DDoS対策の経由・誤検知: 攻撃を防ぐためにトラフィックをスクラビングセンターに回すと経路が長くなり、正常なユーザーを攻撃と誤認してブロックすることもあります。 (インフラチーム・ネットワークインフラ)
• データセンター回線の飽和: アップデートデータの配信・ログ転送・バックアップがゲームと同じ回線を使うと、回線がいっぱいになります。 (インフラチーム・ネットワークインフラ)

L6 サーバーのネットワークカード

• NIC割り込みの単一コア集中: NICがパケット到着の割り込みを1つのCPUコアにだけ送ると、そのコアがボトルネックになります。 (インフラチーム・サーバーインフラ)
• 過剰な割り込みコアレッシング: CPUの負担を減らすために、パケットをまとめてから一度に知らせると、まとめる時間の分だけ遅れます。 (インフラチーム・サーバーインフラ)
• NIC帯域幅の飽和: 1Gbps・10Gbpsのカードを限界まで使うと、送信キューが長くなり、最終的に破棄されます。 (ゲーム開発チーム・サーバー開発)
• GRO/LROの結合待ちによる遅延: 複数のパケットを1つにまとめてCPUの負担を減らす機能です。設定によっては、小さなゲームのパケットが、一緒にまとめる次のパケットを少し待つことがあります。 (インフラチーム・サーバーインフラ)

L7 サーバーOS（カーネル）

• サーバーの電源管理（C-state・周波数制御）による遅延スパイク: 使われていないCPUコアは、電力を節約するために深い省電力状態（C-state）に入り、周波数も下げます。パケットやタイマーが来ると、復帰して周波数を上げるまでに時間がかかるため、小さなパケットの処理に遅延が加わります。 (インフラチーム・サーバーインフラ)
• OS・カーネル・ドライバー・ファームウェアのアップデート後の性能変化: ゲームのコードは変わっていないのに、サーバーのOS・カーネル・ドライバー・ファームウェアをアップデートしてから遅くなるケースです。アップデートによって、デフォルト値、スケジューラー、CPU脆弱性の緩和策（mitigations）、ドライバーの動作が変わることがあります。 (インフラチーム・サーバーインフラ)

L8 ソケットとプロトコル

• Nagleアルゴリズム＋遅延ACK: 小さなパケットをまとめて送るNagleアルゴリズムと、ACKを遅らせて送る遅延ACKがかみ合い、メッセージを分けて書き込むたびに40〜200msずつ遅延します。 (ゲーム開発チーム・サーバー開発)
• アイドル後のスロースタート: TCPはしばらくアイドル状態が続くと輻輳ウィンドウ（一度に送れる量）を再び縮めるため、急に大きなデータを送るときに何回かに分けて送ります。 (インフラチーム・サーバーインフラ)
• 輻輳制御による送信量の急減: TCPはパケットロスを輻輳のシグナルとみなし、送信速度を30〜50%落とします。Wi-Fiでのパケットロスにも同じように反応します。 (インフラチーム・サーバーインフラ)
• ブロッキングI/O構造: 1つのソケットを待っている間、スレッドがほかの処理をできない構造では、人が増えるほど全体が遅くなります。 (ゲーム開発チーム・サーバー開発)

L9 サーバーのゲームプロセス

• ティックバジェット超過: 1ティックの処理がバジェットを超えるとサーバーのティック周期が延び、そのエリア全体がゆっくり進んだりカクついたりします。 (ゲーム開発チーム・サーバー開発)
• ブロードキャストの急増: 1人の動きを、その人が見えている全員に送ると、集まった人数の2乗に比例する数の更新を送ることになります。 (ゲーム開発チーム・サーバー開発)
• シングルスレッドのエリア過負荷（ホットスポット）: エリアごとに1つのスレッドが担当する構造では、1か所に人が集中すると、そのコア1つだけが100%になります。 (ゲーム開発チーム・サーバー開発)
• ロック競合: 複数のスレッドが同じデータを使うために1つのロックを待つと、スレッドを増やしても一度に1つずつしか実行されません。 (ゲーム開発チーム・サーバー開発)
• メッセージキューの滞留: リクエストが処理速度より速く届いてキューにたまると、後ろのリクエストは数秒後にやっと処理されるか、破棄されます。 (ゲーム開発チーム・サーバー開発)
• シリアライズ・圧縮のコスト: 送るデータをバイト列に変換して圧縮するのにもCPUを使い、人が多いとこのコストが急増します。 (ゲーム開発チーム・サーバー開発)
• スレッドプールの枯渇: 処理を担うワーカースレッドがすべて遅い処理に塞がれると、新しいリクエストはいつまでも待たされます。 (ゲーム開発チーム・サーバー開発)
• 1体に集中する戦闘（ワールドボス）: 数百人が1体のボスを同時に攻撃すると、そのボス1体の計算が1か所に集中し、ヒット情報が見ている全員に送信されます。 (ゲーム開発チーム・サーバー開発)
• 密集エリア進入時のスポーン集中: 人でいっぱいの街にテレポートすると、サーバーは新たに見えるようになった数百人の外見・装備・状態を一度に送らなければなりません。 (ゲーム開発チーム・サーバー開発)
• オブジェクトの蓄積（消えずに残るアイテム・召喚物）: 消えるはずの地面のアイテム、召喚物、終わったタイマーが片付けられずにたまると、サーバーを長く稼働させるほど毎ティックの処理が増えます。 (ゲーム開発チーム・サーバー開発)
• アップデートによるトラフィックパターンの変化: 新しいコンテンツ・エフェクト・同期項目がパケットのサイズと頻度を増やすと、問題なく動いていたサーバーがアップデート後からMTU・帯域幅・パケット数の上限に引っかかります。 (ゲーム開発チーム・サーバー開発)

L11 ディスク

• fsyncの集中: データを「確実に」ディスクに書き込むよう要求すると、ディスクによっては1回に0.1ms〜数十msかかり、要求が集中するとキューが長くなります。 (ゲーム開発チーム・サーバー開発)
• クラウドディスクのバーストクレジット枯渇: 一部のクラウドディスクや小さなサーバースペックには、一時的にベースラインより速く使えるバーストクレジットがあります。忙しい時間が長引いてクレジットが底をつくと、速度が急に落ちます。 (インフラチーム・サーバーインフラ)
• IOPS上限・キューの飽和: ディスクが1秒間に処理できる要求数を超えると、キューが長くなって遅延が急増します。 (インフラチーム・サーバーインフラ)
• バックアップ・圧縮・スキャン処理: 深夜のバックアップ、ログの圧縮、セキュリティスキャンがディスクを独占すると、ゲームサーバーの読み書きが詰まります。 (インフラチーム・サーバーインフラ)
• HDDのシーク遅延: HDDはヘッドがプラッタ上を移動する（シーク、seek）必要があるため、散らばったデータの読み書きに1回あたり10ms近くかかります。 (インフラチーム・サーバーインフラ)

L12 データベース

• インデックスのないクエリ: インデックスがないと、条件に合う行を探すためにテーブル全体を読む必要があります（フルスキャン）。 (ゲーム開発チーム・サーバー開発)
• ホットスポットの行ロック競合: 全員が同じ行（ギルド倉庫、オークションの人気アイテム、サーバー全体のカウンター）を更新しようとすると、ロックを取れるのは1人ずつです。 (ゲーム開発チーム・サーバー開発)
• DBのデッドロック: 2つのトランザクション（ひとまとまりで処理されるDB操作）が互いに相手のロックした行を待つと、DBが片方を強制的に取り消します。 (ゲーム開発チーム・サーバー開発)
• コネクションプールの枯渇: DBとの接続数は決まっているため、遅いクエリが接続を占有すると、残りの要求は待たされます。 (ゲーム開発チーム・サーバー開発)
• チェックポイント・ログフラッシュ: DBがメモリ上の変更分を定期的にまとめてディスクに書き込む瞬間、クエリが遅くなります。 (インフラチーム・DBインフラ)
• コールドキャッシュ（再起動直後）: DBを再起動するとメモリ上のキャッシュが空になっているため、しばらくはすべての読み込みがディスクから行われます。 (インフラチーム・DBインフラ)
• ログイン殺到とN+1クエリ: キャラクター1体を読み込むたびに数十回の個別クエリを発行していると、数万人の同時ログインは数百万件のクエリになります。 (ゲーム開発チーム・サーバー開発)
• 大規模なバッチ処理: ランキング集計、郵便の一括送信、古いデータの整理をサービス中に実行すると、ロックとディスクを占有します。 (ゲーム開発チーム・サーバー開発)
• キャッシュスタンピード: 人気データのキャッシュが同時に期限切れになると、数千件の要求が一斉にDBへ殺到します。 (ゲーム開発チーム・サーバー開発)
• 長時間開いたままのトランザクション: 1つのトランザクションが長く開いたままだと、ロックを持ち続けるうえ、DBが古いバージョンのデータを整理（purge）できないため、全体が徐々に遅くなります。 (ゲーム開発チーム・サーバー開発)
• Redisの遅いコマンド: Redisはコマンドを1つずつ順番に処理するため、遅いコマンドが1つあると、その後ろのすべての要求が止まります。 (ゲーム開発チーム・サーバー開発)
• 実行計画の変化によるクエリ遅延: コードは変わっていないのに、DBが同じクエリの処理方法（実行計画）を変えると、昨日2msだったクエリが今日は数百msになります。 (インフラチーム・DBインフラ)
• サービス中のスキーマ変更（DDL）によるロック: サービス中にテーブルへカラムやインデックスを追加すると、一瞬だけ必要なロック1つのために、そのテーブルを使うすべての要求が待たされることがあります。 (インフラチーム・DBインフラ)

L13 サーバー構成と運用

• ゲートウェイ・プロキシ経由: クライアントとゲームサーバーの間に中継サーバーを置くと、経由するたびに処理時間が加わり、そのサーバーが単一障害点になります。 (ゲーム開発チーム・サーバー開発)
• カスケード障害: 1つのサービスが遅くなると、それを呼び出すサーバーが応答待ちで塞がり、関係のない機能まで止まります。 (ゲーム開発チーム・サーバー開発)
• デプロイ・再起動: アップデートのためにサーバーを再起動するとき、接続を移さずに止めると、そのサーバーにいた人は切断され、終了直前の保存と再接続が一気に集中します。 (ゲーム開発チーム・サーバー開発)
• 大量のマクロ・ボット: ボットは人よりはるかに頻繁にリクエストを送り、サーバーのスループットを食いつぶします。 (ゲーム開発チーム・サーバー開発)
• マッチメイキング・リージョン割り当ての誤り: 近いリージョンがあるのに遠いリージョンのサーバーに割り当てられると、回線に問題がなくても、そのユーザーだけPingが常に高くなります。 (ゲーム開発チーム・サーバー開発)

同期設計

• サーバー応答後にだけ演出（リクエスト・レスポンス方式）: ボタンを押しても、サーバーの応答が来るまでアニメーションも音も出ません。Pingがそのまま反応速度になります。 (ゲーム開発チーム・クライアント開発)
• 逐次往復の多いプロトコル（chatty）: 1回の操作でサーバーとの往復が順番に何回も必要になると、Pingがその回数分だけ積み重なります。 (ゲーム開発チーム・サーバー開発)
• スキルの先行入力なし: 前のスキルがサーバーで終わったという確認を受けるまで次のスキルを押せないと、連携のたびに往復時間が挟まります。 (ゲーム開発チーム・クライアント開発)
• Pingに削られる短い判定の受付時間: 回避・パリィ・ガードのように反応すべき時間が短いと、Pingがその時間を削ってしまい、よけられない攻撃が生まれます。 (ゲーム開発チーム・サーバー開発)
• ロックステップでの最も遅いプレイヤー待ち: 全員が同じターンを一緒に計算する構造では、1人の入力が遅れると全員が待たされます。 (ゲーム開発チーム・サーバー開発)
• 二重のティック待ち: リクエストを次のティックまでためてから処理し、結果もその次のティックで送ると、ティック間隔が2回分加わります。 (ゲーム開発チーム・サーバー開発)

一部のユーザーだけに起きる問題

• プレイヤーごとの入力バッファのサイズ: サーバーが人ごとに入力を少しためておき、1ティックに1つずつ取り出して使うと、ほかの人の目にはなめらかですが、本人の行動がサーバーで確定するタイミングはその分遅れます。 (ゲーム開発チーム・サーバー開発)
• 回線が重いパーティメンバー1人とボスのギミック: 全員が決まった瞬間に一緒に反応しなければならないレイドのギミックでは、回線が重い1人の遅れた反応がパーティ全体の失敗になります。 (ゲーム開発チーム・サーバー開発)
• 特定キャラクターのデータ肥大化: アイテム・郵便が数千個たまっていたり、フレンド・ブロックリストやバフが極端に多かったりするキャラクターは、接続時・保存時・周囲への通知で扱う量がほかの人の数倍になります。回線に関係なく、そのキャラクターでだけ重くなります。 (ゲーム開発チーム・サーバー開発)
• 接続ごとの送信バジェット・優先度: サーバーが接続ごとに送る量に上限を設けて近いものから送ると、上限が低く設定された側は、遠くにいるNPCを遅れて受け取るか、受け取れません。 (ゲーム開発チーム・サーバー開発)

TCP再送の根本原因

• 受信サーバーのホストでのパケット破棄: パケットはサーバーまで届いたのに、NICのリングバッファ（到着したパケットを一時的に入れておくバッファ）があふれたり、カーネルで受信処理を担うコアが飽和したりして破棄されます。 (インフラチーム・サーバーインフラ)
• 遅延の急上昇による不要な再送: パケットは消えておらず、一時的にとても遅れて届いただけなのに、その遅延がRTOより長いと、送信側はパケットロスと判断して再送します。 (外部・外部)
• 順序の入れ替わりによる不要な高速再送: 複数の経路や束ねたリンクを通る間にパケットの順序が入れ替わると、受信側が重複ACKで「抜けたパケットがある」と知らせ、送信側は問題のないパケットを送り直します。 (インフラチーム・ネットワークインフラ)
• ACKの遅れ・消失（上り回線の飽和）: データは問題なく届いているのに、「受け取った」というACKが満杯の上りキューで遅れたり消えたりすると、送信側はパケットロスと判断して再送します。 (外部・外部)
• RTOの設定が環境に合っていない: RTOの最小値を下げすぎると少し遅れただけで不要な再送が起き、デフォルト値（200ms）はゲームにとっては長すぎて、1回失うたびに長く止まります。 (インフラチーム・サーバーインフラ)

図のあるメインページの症状辞典を見る