フォグゲーミング構想は生きていた!?　クラウドゲーミング的な処理における徹底的な遅延削減の取り組み［CEDEC 2025］

　セガ フェイブはゲーム開発者会議のCEDEC 2025で，「ゲームの入力遅延の計測およびリモートプレイを考慮した場合の入力遅延の変化と遅延対策」という講演を行った。同社がCRIミドルウェアと共同研究開発中の次世代技術を紹介するものだ。

　セガ フェイブは，セガの玩具部門やアーケードゲーム開発部門が分社化された，セガの完全子会社である。CRIミドルウェアは，ゲーム関連ミドルウェアを手広く開発・提供しているゲーム開発関連企業の大手。セガとCRIミドルウェアはともにCSKグループに属していたことがあり，関係は深い。

　筆者は2020年夏頃に，「セガが“フォグ”ゲーミングと呼ばれる，クラウドゲーミングとは異なる独自技術を開発中である」という情報をキャッチし，独自取材記事としていくつかのメディアに寄稿したことがある。さまざまな角度からバズったので，覚えている人もいるかもしれない。

　あのスクープ記事以来，セガからは音沙汰がなかったのだが，2025年7月頭に「CEDEC 2025にて関連発表をするのでよかったら聞きに来ませんか」という打診を受けたため，今回のこのセッションに興味津々で臨んだというわけである。

セガ フェイブ 瀬戸大樹氏。ゲームセンター向けのゲーム基板の設計開発担当

CRI・ミドルウェア 渡邉光輝氏。各種ミドルウェアや，BtoB想定の組み込み向けアプリ開発などを手がけてきた

フォグゲーミングとは何か?

　まず，フォグゲーミングとは何か，について簡単に振り返っておこう。それには，まず，既存キーワードの「クラウドゲーミング」のおさらいから始めたい。

　クラウドゲーミングとは，クラウド上の高性能コンピュータ（サーバー）で動作中のゲームを，低性能なクライアント端末から操作してプレイできるサービスのことだ。GoogleのStadiaが短期間でサービスを閉じた印象が強いが，2025年7月時点で，Xbox Cloud Gaming，Amazon Luna，PlayStation Plus（プレミアムプラン向けサービス）などが稼動中だ。NVIDIAのGeForce Nowは，リモートレンタルPCの意味合いが強いが，クラウドゲームサービスの側面もあるので，これに含められるかもしれない。

　対する「フォグゲーミング」も，概念としてはクラウドゲーミングとほぼ同一だが，両者における最大の相違点は，サーバーの位置となる。

　クラウドゲーミングでは，ゲームが動作するサーバーが，ユーザーから遠い場所にあるデータセンターに集約されている（たまたまその近場に住んでいるという特殊状況を除けば）。そのため，サーバーとユーザー（クライアント）との物理的な距離によって発生する遅延が避けられない。

　対するフォグゲーミングでは，ユーザーから物理的に近い位置にサーバーを置き，距離を可能な限り縮めることをコンセプトとしている。

半導体技術は3nmプロセス以下になると「価格が下がりにくい」「消費電力が下がりにくい」という見通しのため，ゲームプラットフォームのコストと消費電力の上昇が懸念されている。セガは，少なくとも「一定のゲーム分野」にはクラウド的な技術が必要になると分析している

　クラウド（雲）は空の上の「遠い」場所にあるが，フォグ（霧）はユーザーの周りに立ち込めるので「近い」存在ということから「フォグゲーミング」という名称が付けられたとされる。まあ，IT用語的には，ユーザーの近くに配置した演算施設（コンピューティング拠点）は「エッジ」と呼称するので「エッジゲーミング」といった方がIT業界人にはイメージしやすいかもしれない。

　では，ユーザーに近いエッジコンピューター（エッジサーバー）を，セガはどうやって構築するのか……という話になるのだが，以前取材した際，セガ フェイブは「日本全国に存在するゲームセンターの活用」を想定していると述べていた。

　ゲームセンターにあるアーケードゲーム機のコンピュータは，今や普通のPCそのものだ。対戦系筐体に一部例外はあるが，基本的にはゲーム機筐体1台につき，1台のPC相当のコンピュータが搭載されている。

　ハイエンド3Dグラフィックスのものがあれば，一昔前のスマートフォン級のシンプルな映像表現のものもあるといった具合に性能差はあるが，全てにPCが搭載されているのだ。しかし，これらはお客がいないときもずっと稼動しているため，ゲームセンターの電気代は馬鹿にならない。

　であれば，ゲームセンター内にサーバーを設置し，店内のアーケードゲーム機上のゲームを全てクラウドゲーミング（というかリモートゲームプレイ？）的な実装にしたら，演算リソースの最適化，電気消費量の最適化が行えるではないか。ベーシックな映像表現のゲームであれば，1台のサーバーで複数機の筐体分のゲームを同時に動作させることは性能的には可能である。

　そして，一部の体感ゲームのような特殊操作を使わない，汎用コントローラでプレイできるゲームであれば，そのゲームセンター施設の周辺に住む人々が，自宅からリモートプレイに参加できるようにしてもいいかもしれない。これが，セガ フェイブが開発を進めているとされるフォグゲーミング構想になる。

　「ゲームセンターにエッジサーバーを置く？」……たしかに，ゲームセンターはちょっとした規模の街なら1つや2つはあるし，山奥に建造されたデータセンターにアクセスするよりも遅延は小さくできるだろう。しかし「ゲームセンターって，最近数を減らしてませんか？」という疑問が浮かぶ人は少なくないはずだ。

　ただ，セガグループの親会社はセガサミーホールディングスであり，サミーはパチンコ・パチスロ機器メーカーである。ゲームセンター以上に数が多いパチンコ店にエッジサーバーを置くのであれば，フォグゲーミング構想のリアリティは高まって来るように思える。パチンコ筐体に対するネットワーク接続機能の搭載に関しては強い法規制もあるようなので，すぐに全国のパチンコ店がエッジデータセンターになるとは言い切れないが。

講演後の質疑応答にて「これって，あのフォグゲーミング構想の図そのものですよね」という質問に対し，講演者の瀬戸氏は「はい，そう考えてもらってよいです」と述べていた。

ゲーミングPC単体でも遅延は起きている

　研究グループがまず調査したのは，PC単機でゲームを動作させたときに，どの程度の入力遅延があるのか，というテーマだった。

　この調査を行うために，研究グループは独自の入力遅延測定器を開発。その測定のメカニズムは以下のようになったと報告している。

この入力遅延テストはネットワークを介していない。事実上，我々がPCでゲームをプレイしたときに，どの程度の遅延が起きているかを確認するものに相当する

　この図を軽く解説すると，

（1）USB接続のゲームコントローラにてボタンを押すと，独自開発された専用の測定器のタイマーがスタート
（2）ゲームコントローラの入力がUSBケーブルを伝わる
（3）PC上で動作中の測定アプリ（ゲームに相当するアプリ）がコントローラ入力を認識したら，画面左上に四角い白いマスを描画し（ゲーム映像に相当），同時に矩形波の試験音を鳴らす（ゲームサウンドに相当）
（4）前出の測定器で映像と音声を認識したら，それぞれの経過時間を記録する

　といった感じになる。映像（白いマス）は，測定器に接続されたフォトセンサー（輝度センサー）で，音声（試験音）は矩形波の立ち上がりで認識する仕組みだ。

独自開発の測定器。原理的にはNVIDIAのLDATシステムに近い（関連記事）

　まずは映像面の測定結果を示す。

測定対象のグラフィックスAPIは，DirectX 9 / 11 / 12，Vulkan，OpenGLの5種。また，垂直同期はオン，ディスプレイのリフレッシュレートは144Hzとしている

　このグラフは横軸が計測結果の遅延時間（ms）となり，縦軸はその測定結果が何回あったか，というヒストグラムを表している。結果を見ると，多少のばらつきがあるが，それぞれのグラフィックスAPIでの計測結果は，だいたい5msの幅内に収まっているようだ。

　早い測定結果を示したのは，DirectX 11とDirectX 12を用いたときで，共に，入力遅延は20ms〜27msあたりの範囲に収まっているのが分かる。

　測定に用いたディスプレイは，垂直同期オンでリフレッシュレート144Hzが設定されていたので，ゲームループ1回分の処理時間は最短で144分の1秒（≒約6.9ms）となる。つまり，ゲームコントローラの入力が行われてからその入力を反映した映像が出てくるまで，最短でも約6.9msがかかることになる。

　計測値が20ms〜27msという低遅延なDirectX 11 / 12を用いたとしても，PCゲームでは，そこから6.9msを差し引いた，13ms〜20msあたりの遅延が固定値的な遅延として付随してくるということだ。

　この固定値的な遅延の内訳は，ゲームループ以外の要因で起きていると推察される。たとえばUSB接続のゲームコントローラ側の入力系の処理時間，USB情報がPCへ伝達されて，それがゲームプログラムに認識されるまでの所要時間，HDMIケーブルからモニターに入力された映像が表示されるまでのモニター側の遅延時間，遅延計測器側の遅延時間（フォトセンサーが規定輝度を超えるまでの所要時間など）などだ。

　なお，USBのポーリングレートが1msだったとのことなので，ゲームコントローラの信号がPC側に伝達されるまでのワーストケースでは，計測結果にはこの1msの遅延が含まれることもあったと推察される。

　この測定結果で分かるのは，コンピュータゲームには，意外と，ゲームループ起因や，モニター起因以外にも，結構な量の遅延が介在しているということだ。

　そして，この実験で､筆者がとても興味深かったのは，PCゲームでは，サウンドデバイスによって，固定遅延がかなり変わってくると言う事実だ（下のスライド）。

映像に対してサウンドはやや遅れる計測結果が得られた。その遅延量は，サウンドデバイスのPCとの接続バスの種類によっても変わることが判明

　上の計測結果のうち，灰色線は，PCのマザーボード上に実装されていたサウンドデバイスの出力の遅延を表している。このマザーボード上のRealtekオーディオは，ハードウェア的にはUSBバスに接続されたUSBサウンドデバイスだったそうで，おそらくUSBバスに起因した遅延が固定値として上乗せされたようだ。

　テレビやディスプレイをHDMI接続した際，PC側が認識するHDMI経由で伝送される「High Definition Audio」デバイスは，論理サウンドデバイスであり，事実上のソフトウェア的なサウンドデバイスになるが，こちらの方が10ms近く低遅延だということが判明した。

　こうした結果を踏まえて，コアなゲームファンは今後，サウンドデバイスの遅延にも気を配るといいかもしれない。なお，USB接続のサウンドデバイスは遅延が大きい傾向があるようなので，低遅延を意識するならば，今回の実験で分かったように，HDMI経由の論理サウンドデバイスを選択した方がよいかもしれない。また，今回の実験では未計測だった，PCIeバス接続のサウンドデバイスの遅延量も気になるところだ。

徹底した低遅延を実現するための工夫とは

　次に行われた実験は，いわゆるクラウドゲーミング的なシステムにて，この入力遅延を計測するものであった。具体的には，サーバー相当のPC（講演資料ではTxと略記。トランシーバーの意）とクライアント相当のPC（講演資料ではRxと略記。レシーバーの意）をネットワーク接続し，この両者間で生じた遅延を計測するものになる。

クライアント端末（Rx）でゲームコントローラによる入力を行い，ゲームアプリに相当するものはサーバー（Tx）で動作。ゲーム映像に相当するものはTxで描画し，ネットワークを通じてRxへと伝送。その映像表示と音声再生はRxに接続されたディスプレイ / スピーカーで行われる

この実験ケースでは，以下のような処理系を順番に通ることになる。

クラウドゲーミング的な処理系のパイプライン

　筆者の解説を，上スライドの1から8までを対応させる形で行うと，以下のような感じになる。なお，上でも触れたように，セガ フェイブの発表スライドでは，クラウドゲーミングにおけるユーザー端末（クライアント端末）に相当するものは「Rx」，サーバーに相当するものは「Tx」と呼称している。

　まず，ユーザー側のクライアント端末（Rx）でゲームコントローラでの入力が行われ（1），この入力がネットワークを伝達（2）。サーバー（Tx）はこのプレイヤー入力を処理して，映像（白いマス）をGPUで描画（3）する。

　ここで記すべきなのは，Tx側はディスプレイへの映像表示を行わないこと。それはそうだ，プレイヤーはネットワークの先のRxの前にいて，Txの前にはいないからだ。

　そして，TxのGPUで描画された白いマス映像は，内部的にGPUでH.264エンコードされる（4，5）。

　エンコードされたH.264映像ストリームはネットワークを通じてユーザー端末，すなわちRxへと伝送される（6）。RxはこのH.264ストリームをデコードし（7），Rxに接続されたモニターへと表示する（8）。

　現状は，H.264コーデックを活用しているが，ここに深い意味はないようだ。実験の都合上，最も互換性の高い，ベースラインのH.264を活用しただけ……という理解でいいだろう。

　さて，セガ フェイブとCRIミドルウェアでは，この1から8までのプロセスにおいて，徹底した遅延対策を行ったとし，その具体的な試みを，このあと，一要素ずつ紹介していた。

　TxでのGPU描画結果は，そのままGPUメモリー上に居座ったままとし，これを直接，H.264でエンコードしている。余計な遅延となるので，描画結果をメインメモリーなどへはコピーしない。ただし，エンコードされた映像ストリームはシステムメモリーを通じてネットワークから出力されていく。

GPUで描画された映像は，GPUメモリーに描き出される

これを，そのままGPU内のエンコーダに入力させる

　Txからの映像ストリーム出力，サウンドストリーム出力，そしてRxからのコントローラ入力は，ネットワークチャンネル上としては，個別チャンネルで伝送させる，とてもシンプルな構造としている。

映像と音声は，それぞれ個別チャンネルで，そのまま伝送

　サウンドストリームは非圧縮のリニアPCMで出力する実装としており，映像のH.264ストリームとは別チャンネルで伝送される。
　映像はネットワーク帯域の消費量を考えると圧縮が必要不可欠となるが，音声は非圧縮なリニアPCMで伝送したとしても，2CHステレオであれば，伝送帯域はたかだか1Mbps前後。今回の実験では，低遅延の方を重視して非圧縮伝送を採用した。

音声フォーマットは低遅延を優先させて非圧縮リニアPCMを採用

　映像にしろ音声にしろ，圧縮処理を行うには，ある程度のデータ列をバッファリングする必要があり，これが遅延を生むことにつながる。比較的低遅延だとされるAAC-LCでも，理論値にして55msの遅延が発生するという。リニアPCMの採用は，固定値の遅延を徹底的に排除したいという今回の開発コンセプトからすれば，自然な選択といったところか。

　なお，フォグゲーミング構想では，同一施設内，あるいは近距離内でのネットワーク伝送を想定しており，ネットワーク帯域はある程度は贅沢に使える……という想定があるので，このあたりがリニアPCM採用を許容したとも考えられる。ちなみに，マルチCHサラウンド音声だとしても，16bit / 48kHz / 7.1chでたかだか6Mbps程度である。

Rxに伝送されてきた映像ストリームは逐次デコードされて，Rxに直結された画面に表示される

　ユーザー端末のRxでは，Txからネットワーク伝送されてきた音声ストリーム（非圧縮）をそのまま再生することになる。映像はH.264ストリームとなっているので，これをGPU側のデコーダーに直接入力して，GPUメモリー側で映像フレーム化。これをGPUは，そのままHDMIなどを通じて表示する。ここでもメインメモリーへのコピーなどは一切行わない哲学が徹底されている。

　なお，ネットワークやその他の要因により，デコードした映像フレームが表示に間に合っていない場合は，表示をせずに破棄するメカニズムもRx側には搭載されている。遅延したフレームをくそ真面目に表示していては，遅延がどんどん蓄積していってしまうからだ。また，この「フレーム破棄メカニズム」は，後述する特殊な遅延隠蔽にも役立つ重要な機能となる。

映像は十分に低遅延の伝送。しかし課題も残る

　測定は，TxとRxのそれぞれのWindows PCを，Ping 0.7msのローカルネットワークでつないだ状態で実施。なお，ゲームループは60fpsを想定。実際の映像遅延の測定結果は下のスライドのようになったとしている。

Txの測定結果は，前半にあったものと同じで単機PCでの固定遅延のあぶり出しに相当する。青いRxの測定結果は，Windows PCのRxによるもの。そして灰色の測定結果は，Android端末のRxによるもの

　なお，このグラフ中の橙色線のTxの測定値は，Tx単体ローカルで遅延を計測したものになる。いわば，クラウドゲーミング的なことを行わず，ローカルでゲームを動かした場合の遅延を表したものになる。

　つまり，このTx単機の計測スタイルは，前半のDirectX 11 / 12などを計測した遅延と同じ，PCゲーミングにおける固定値ということになる。では，なぜ前半とここでの測定値が異なるかというと，前半の計測は144Hzディスプレイが接続されたPCだったため。つまり，ゲームループが144Hzだったわけだ。ここではゲームループが60Hzの計測だったので，その差が表れている。

　さて，ここのTxの測定結果と，水色線のRxの測定値には24.3msの差異があることが分かるワケだが，これは一体何なのか。答えを先に言ってしまえば，ローカルPC（60Hz）でゲームをプレイしたときと，クラウドゲーミング的な処理系で60Hzゲーミングを楽しんだときの遅延量の違いということになる。

　24.3msというと，60fps（1フレーム≒16.67ms）換算で，約1.5フレーム程度の遅延。60fps換算で1.5フレーム遅延というと，2017年モデルくらいのシャープAQUOS（たとえばLC-50US5）あたりののゲームモードがこのくらいだった（笑）。

　ところで，ここの計測結果には，灰色線のRxの測定結果も示されているが，これは，クライアント，すなわちRxをAndroid端末にした場合の計測結果となる。Android端末のSoC内のH.264デコーダは，搭載SoCの種類によってデコード速度が遅めで，たまたま測定に選出した端末はこの速度だったというだけだ。研究グループでは，優秀なH.264デコーダを搭載したSoCであれば，水色線のWindows PCのRxに近い測定結果になると踏んでいるようだ。

　続いて，音声遅延の測定は以下のようになったと示された。このテストでもゲームループは60Hzになる。

音声の遅延の測定結果。Tx単機の遅延は映像と比べて少ないのに対し，クラウドゲーミング的な処理系では大きくなっている

　この測定結果には，Txの単機テストの結果が2つ示されているが，これは，音声再生をゲームエンジンであるUnityのNAudio APIで再生した測定値と，CRIミドルウェア独自のサウンドミドルウェアADX（のカスタム版API）で再生した測定値の両方を示しているため。再生サウンド自体は，どちらも非圧縮のリニアPCMである。

　音声は垂直同期を待たず随時再生できることもあってか，Txの単機テストにおいて，NAudio経由でもADX経由でも，前出の映像より低遅延となっている。しかし，一方で，クラウドゲーミング的な処理系が付与されたRxにおける遅延は，映像よりも50ms近く遅い。

　この原因について，研究グループに質問してみたところ，理由は2つほどあるという旨の回答を頂いた。

　1つは，Tx側で発生している遅延だ。これを改善するために，研究グループは，ADXをカスタムし，Txにて，WindowsのサウンドサブシステムであるAPO（Audio Processing Object）をバイパスしてネットワーク出力するようにして遅延を改善したという。

　その結果，Rxまでの音声遅延は，ADX経由の方がNAudio経由よりも低遅延化できたとしている。水色（Rx応答:ADX経由）の方が，橙色（Rx応答:NAudio経由）よりも，低遅延になっていることが，たしかに測定結果からも読み取れる。

　なお，このAPOとは，残響効果をはじめとした追加のオーディオ処理をするためのサブシステムで，Windowsでサウンドを再生する際には基本的にここを通ることになる。クラウドゲーミング的な処理系においては，サーバーに相当するTxにおいては音声を実際に再生する必要がないため，APOを通す必然性がない。ADXは，今回の実験システムの開発に参加したCRIミドルウェア自社製のオーディオミドルウェアなので，当然，勝手知ったるもの。そこで，APOに流さず，直接ネットワークへ出力できるように特別にカスタムしたら，NAudio経由よりも速くなった……という寸法である。

　しかし，音声の伝送自体はより低遅延になったとはいえ，そもそも無圧縮の音声が，映像よりも遅延が大きいというのは不可解なままである。これについて研究グループに質問してみたところ，Rx側の音声再生には，ある程度のバッファサイズを設け，そこにPCMデータが埋まってからでないと，うまく再生できなかったため……という回答だった。

　なるほど。たしかに非圧縮のリニアPCMならば音声のエンコード処理やデコード処理は不要だが，伝送されてきた生の音声PCMデータを，1要素ずつ（16ビット=2バイト）ずつ再生するわけにもいかない。再生ジッターが発生し，再生音にブチブチとしたノイズが混じりそうだ。これを低減するためには，ある程度バッファリングしてオーディオデバイスに手渡すのが改善案としては手っ取り早い。そう，この部分で（つまりRx側で）再生遅延が発生しているということのようだ。

60fps換算時の遅延を0.5フレーム未満にする手法は見えている

　遅延を徹底的に低減させることに取り組んだ，今回のセガ フェイブの研究グループの講演は大変興味深いものであった。

クラウドゲーミング的な処理系における遅延は，アイデアと技術次第で短縮できる可能性が見え始めた

　筆者的に特に興味深かったのは，ゲームの処理系が「コントローラ入力→シミュレーション→描画→表示」という逐次処理のループ構造である以上，クラウドゲーミングではない単機PCでも，それなりに大きい固定量の遅延があるという事実だ。よく考えて見れば当たり前のことなのだが，多くのゲームファンも，この固定遅延量については意識してこなかった人は多そうだ。

　そして映像は，GPUによる描画時間を無視すれば，エンコード処理系とデコード処理系を挟んでも，60Hz系のゲームループで約1.5フレームの遅延に抑えられることが分かったことについても，「意外に低遅延にできるものなんだね」と驚く人は多いだろう。

　なお，研究グループには，この遅延を限りなくゼロに近づける方策も見えているようだ。そのヒントが，今回の講演の冒頭の144HzゲームループのでのTx単機の結果に現れている。その遅延が，本講演後半の60HzゲームループのTx単機テストよりも圧倒的に小さいことに気が付いた人は多いだろう。

　そう。サーバー側（Rx側）のゲームループを，たとえば4倍の240Hzなどにすれば，理屈上は，クラウドゲーミング的な処理を通しても，240分の1秒の1.5倍，すなわち，遅延を約6.25ms程度にまで削減できるということだ。これは，60fps換算で0.375フレーム遅延に相当する。

　ちなみに，このシステムにおいて，クライアント側（Rx側）は，60Hz固定で動作でもOK。たとえTx側から240fpsの映像が送られてきても，60Hz固定のクライアントでは，伝送されてきた最新フレームだけを表示し，その間に届くフレームは表示せずに破棄すればいい。これだけで遅延は隠蔽される。60fpsのゲームを高リフレッシュレートのモニターでプレイすると遅延が減退する，あの現象と理屈は同じだ。これが後述すると書いた遅延隠蔽のメカニズムだ。

　なお，サーバー側のゲームループのサイクル速度を上げることで，クラウドゲーミング上の遅延を隠蔽するテクニックは，実はNVIDIAのGeForce Nowですでに実装されている。
　クラウドゲーミング的な処理系において，遅延を60fps換算で1フレーム未満の遅延に短縮できれば，格闘ゲームなどのeスポーツ系ゲームであっても，クラウドゲーミング的なシステムでそれなりにプレイできるはずだ。

　そして，課題として残されている音声の遅延について，研究グループによれば，Rx側の音声再生バッファの最適化や，その他の工夫（映像ストリームよりも先駆けて音声ストリームの伝送を先行させるなど）でさらなる低減を目指したいとのことであった。

　余談になるが，今回の研究グループの調査によれば，現在，他社が提供しているクラウドゲームサービスやリモートプレイシステムにおいても，音声の遅延は映像の遅延よりも大きいそうで，このテーマに取り組む研究者にとって，未だ手強い課題点となっているようだ。

　まあ，もともと人間は自然界において，音声は多少遅れても違和感を感じないことが精神物理学の世界ではよく知られているので，多くの状況では許容されるかもしれない。とはいえ，リズムゲームなどでは，そうした言い訳も通りにくいので，根本的な改善が必要なのは間違いないだろう。

　フォグゲーミング構想の今後の展開に期待したい。

「CEDEC 2025」公式サイト

4Gamer「CEDEC 2025」関連記事一覧