Steam Remote Playに「Pyrowave」追加｜最大500Mbps、1GbEで足りる？低遅延の仕組みを検証
本記事にはアフィリエイト広告（Amazon・楽天市場等）のリンクが含まれています。
最大500Mbps、1GbEで足りる？低遅延の仕組みを検証
出典：Pyrowave公式GitHubリポジトリ ／ 開発者Hans-Kristian Arntzen氏の技術解説ブログ ／ Steam Remote Play公式フォーラム「Pyrowave video codec now in beta!」 ／ Steam Client Beta公式アナウンス(9月21日)にもとづきます(2026年9月22日時点)。
Valveは2026年9月21日、Steam Client BetaのRemote Playに新しい映像コーデック「Pyrowave」を追加しました。公式アナウンスではPyrowaveについて「高帯域・低遅延の映像ストリーミングを可能にする実験的なビデオコーデック」と説明されています。現時点では正式版ではなく、Steam Client Betaで試験提供されている機能です。
注目したいのは、AV1のように「同じ画質をもっと少ない通信量で送る」方向とはほぼ逆を向いていることです。Pyrowaveは家庭内LANで余っている帯域を積極的に使う代わりに、映像の圧縮・展開にかかる時間を極端に短くすることを狙っています。手動設定時には100〜500Mbit/sという非常に高いビットレートを使用でき、HDRやYUV 4:4:4にも対応します。
では、500Mbit/sも使うなら2.5GbE環境が必要なのでしょうか。結論からいえば、現在公表されている500Mbit/sという上限だけを見る限り、正常な1GbE有線LANなら帯域上は収まります。むしろPyrowaveで重要なのは「2.5GbEか1GbEか」だけではありません。従来のH.264・HEVC・AV1と何が違うのか、ネットワーク側で詰まった場合に低遅延というメリットが残るのかまで理解して使う必要があります。
目次
要点まず何が起きたか
手動設定時のビットレート上限は500Mbit/sで、正常な1GbE有線LANなら帯域上は収まります。ただしPyrowave自体を有効にすると自動的に最低250Mbit/sを使う仕様のため、Wi-Fiや不安定な回線ではかえって遅延が増える可能性があります。
仕組みPyrowaveとは？Steam Remote Play向けの低遅延コーデック
PyrowaveはHans-Kristian Arntzen氏が開発している映像コーデックです。公開されているGitHubのREADMEでは、Pyrowaveを「intra-only video codec(実質的には静止画コーデック)」と説明しており、静止画コーデックを高速に連続処理して動画として利用する設計になっています。Vulkan Compute Shaderで実装され、主な用途として「帯域よりも最小遅延を優先する、Ethernet経由のローカルゲームストリーミング」が挙げられています。開発側が想定するビットレートも200Mbit/s以上とかなり高めです。
つまりPyrowaveはYouTubeやNetflixのような動画配信用コーデックを目指しているわけではありません。家庭内に1GbEクラスのLANがすでに存在するなら、数十Mbit/sまで必死に映像を圧縮するより、その帯域を使って圧縮処理そのものを簡単にした方がゲームストリーミングでは有利なのではないか、という発想です。
設計思想なぜH.264・HEVC・AV1より帯域を大量に使うのか
一般的な動画コーデックでは、現在のフレームと前後のフレームには似た部分が多いことを利用してデータ量を削減します。こうした仕組みのおかげでH.264やHEVC、AV1は非常に高い圧縮率を実現できますが、ゲームストリーミングでは入力してから画面に結果が表示されるまでの時間も重要です。開発者は、ゲームストリーミングではコントローラー入力・ゲーム描画・映像エンコード・ネットワーク転送・デコード・ディスプレイ表示という複数の処理が順番に発生し、どこか一つで待ち時間が増えれば、その分だけ最終的な操作遅延も増えると説明しています。
そこでPyrowaveは、フレーム間予測を使わないintra-only方式を採用しました。それぞれのフレームを独立して処理するため圧縮効率は大幅に悪化しますが、前のフレームを参照して複雑な動き予測を行う必要がありません。開発者自身、一般的なゲームストリーミングでは10〜20Mbit/s程度で済む場面に対し、Pyrowaveでは100Mbit/s以上を使うことになると説明しています。帯域を節約する代わりに処理を複雑にするのではなく、帯域を使って処理時間を買うのがPyrowaveの基本思想です。
実装エントロピー符号化まで簡略化してGPUで並列処理する
Pyrowaveが高速な理由はintra-onlyだけではありません。開発者は一般的な画像・動画圧縮で使われるエントロピー符号化について、GPUで大規模に並列化するには扱いにくい処理だと説明しています。そこでPyrowaveでは、この部分も大幅に単純化されています。画像を離散ウェーブレット変換(DWT)で処理し、JPEG 2000でも利用されるCDF 9/7フィルターを使用します。その後の係数の保存方法も、GPUで大量に並列処理できることを強く意識した設計になっています。高い圧縮率を目指せば、普通は「どうすれば1bitでも情報を減らせるか」を考えますが、Pyrowaveは逆です。「家庭内LANなら数百Mbit/s使っても構わないので、できるだけGPUが簡単に処理できる形式にする」という割り切りが、H.264やAV1とはかなり異なる部分です。
性能開発者のテストでは1080pのエンコードが0.13ms
Pyrowaveで最も目を引くのが処理時間です。開発者がRadeon RX 9070 XTとRADVを使って行った1080p・YUV 4:2:0のテストでは、『Clair Obscur: Expedition 33』の映像を約0.13msでエンコードできたとしています。デコードは100マイクロ秒未満で、より一般的なゲーム映像ではエンコードが約80マイクロ秒だった例も示されています。GitHub READMEでも、1080pではエンコード・デコードともおおむね0.1ms未満、4Kでも約0.2ms未満という性能が掲げられています。
この数字はPyrowaveそのもののエンコード・デコード処理について、開発者が特定のGPUやドライバー・映像を使って測定した結果です。実際のRemote Playではゲームの描画時間・映像キャプチャ・ネットワーク転送・クライアント側処理・ディスプレイの表示遅延まで加わります。60fpsでは1フレームが約16.7msあり、エンコードが0.1ms級まで短縮されても、他の工程で遅延が発生していればPyrowaveが消してくれるわけではありません。
耐性パケットロスにも強いのがintra-onlyのメリット
intra-onlyにはもう一つ特徴があります。フレーム同士が強く依存しないことです。一般的な動画圧縮では、あるフレームが前のフレームを参照している場合、参照元の映像が壊れるとその影響が後続フレームまで残る場合がありますが、Pyrowaveでは各フレームを独立して処理します。さらに開発者は、64×64ピクセル単位のブロックについても独立して復号できる設計を採用しており、データが欠落した場合にはその部分をゼロとして処理し、小さなぼけとして復旧できる構造を説明しています。つまりPyrowaveは単に高速なだけでなく、ゲームストリーミングで厄介な「パケットロス後に画面の乱れがしばらく残る」という問題も起こりにくい方向の設計です。もちろん、パケットロスが大量に発生しても問題ないという意味ではなく、500Mbit/s近い通信を不安定なWi-Fiへ流せば、帯域不足や混雑そのものが新しい遅延原因になります。
検証最大500Mbpsなら1GbEで足りる？
ここが今回もっとも気になるポイントです。Steam Client Betaで手動ビットレートを設定する場合、自動ビットレートを無効にすると100〜500Mbit/sの範囲で調整できます。Valveはホストとクライアントを少なくともGigabit Ethernetクラスのネットワークへ接続することを推奨しています。500Mbit/sは、1GbEの公称1,000Mbit/sに対してちょうど半分です。EthernetやIPなどのオーバーヘッドが存在するため1GbEで実際に1,000Mbit/sのデータを運べるわけではありませんが、それを考慮しても500Mbit/sの映像ストリーム1本だけで1GbEを使い切る数字ではありません。したがって、Pyrowaveを使うためだけに2.5GbEが必須とは考えにくいです。現在公表されている500Mbit/sという手動設定上限を基準にするなら、まず1GbEの有線LANで試すのが合理的です。
ただし注意したいのは、Pyrowave自体を有効化すると自動的にビットレート設定を無視し、最低250Mbit/sを使う仕様になっていることです。手動で100Mbit/sに固定していても、Pyrowaveを有効にした時点でそれより高い帯域が使われる可能性があります。2.5GbEが意味を持つのは、Remote Playと同時にNASへ大容量ファイルを転送する場合や、同じアップリンクへ複数の高速通信が集中する場合など、500Mbit/s以外にも帯域を大量に使う環境です。2.5GbEにすればPyrowave自体のエンコード時間が短くなるわけではありません。
留保「4K 120Hzなら2.5GbE必須」ともまだ言えない
高解像度・高リフレッシュレートになると、「4K 120Hzなら500Mbit/sを超えるので2.5GbEが必要なのでは」と考えたくなりますが、現時点では単純にそう断定できません。Steam版で公開されている手動ビットレート範囲は100〜500Mbit/sです。4K・120fpsだから映像データ量を単純に比例させ、「必要帯域は1Gbpsを超える」と計算することはできません。圧縮コーデックなので、解像度やフレームレートが上がった場合には1フレーム当たりに使えるデータ量や画質とのトレードオフが変化します。4K 120HzでどのビットレートをSteamが自動選択するのか、500Mbit/s時にどこまで画質を維持できるのかについては、実機検証を見る必要があります。「Pyrowave対応だから2.5GbEへ交換する」のはまだ早いでしょう。
目安500Mbpsは実際どれくらいのデータ量なのか
| ビットレート | 1秒あたり | 60fps時の1フレーム |
|---|---|---|
| 500Mbit/s | 約62.5MB | 約1.04MB |
| 250Mbit/s | 約31.25MB | 約0.52MB |
| 200Mbit/s | 約25MB | 約0.42MB |
| 100Mbit/s | 約12.5MB | 約0.21MB |
500Mbit/sが1時間続けば約225GB相当のデータがLAN内を流れる計算になりますが、これは同じ家庭内LANでPCから別の端末へストリーミングするだけの話で、SSDへファイルが保存されるわけでも、インターネット回線の通信量として消費されるわけでもありません。一方、Remote Play Anywhereなどでインターネット越しに同等のビットレートを利用するなら話は別です。開発者自身、100Mbit/sを大きく超える帯域を使うため、光回線同士のピアツーピアでもない限り一般的なインターネット越しのストリーミングには向かないと説明しています。Pyrowaveは基本的に家庭内ストリーミング向けと考えた方がよいでしょう。同じ500Mbit/sでも120fpsになると、1フレーム当たりのデータ量は60fps時の半分になります。今後4K・120HzなどでPyrowaveを評価するときは、解像度・fps・YUV形式をそろえた状態で画質を比較する必要があります。
画質YUV 4:4:4対応はゲームより文字表示で効きやすい
PyrowaveではYUV 4:2:0だけでなく4:4:4も実装されています。一般的な映像配信でよく使われる4:2:0では、人間の目が明るさより色の細かい変化に鈍感であることを利用し、色差情報の解像度を減らします。映画やゲームの映像では非常に効率的ですが、小さな文字や細い色付きの線では輪郭がにじんで見える場合があります。4:4:4では色差情報を間引かないため、PCのデスクトップ・ブラウザ・コードエディター・小さなHUDなどをRemote Play経由で表示したときに違いが出やすくなります。Steam版では4:4:4は追加の帯域と処理を必要とするため標準では無効で、必要に応じて有効化する仕様です。HDRは送信側と受信側の双方が対応している場合に自動的に有効になります。ゲーム映像だけなら必ず4:4:4にする必要はありませんが、リモートデスクトップに近い使い方をするなら、Pyrowaveと4:4:4の組み合わせは面白そうです。
留意点画質劣化はブロックノイズより「ぼけ」が出やすい
Pyrowaveはウェーブレット変換を使っているため、画質を落としたときの見え方も一般的な動画圧縮とは少し異なります。開発者によると、高周波成分を強く削った場合、典型的なJPEGのような四角いブロックノイズというより、ぼけやリンギングが発生しやすいとされています。開発者自身、『Expedition 33』の植物やTAAノイズが圧縮しにくかったと説明しており、200Mbit/sを超える60fps映像では並べて拡大しないと圧縮痕を見分けにくかったとしています。ただし、これは開発者による評価です。Steam Remote Playに組み込まれた状態でH.264、HEVC、AV1より常に高画質になると確認されたわけではありません。
注意Pyrowaveだから必ずRemote Playの遅延が減るわけではない
Pyrowaveが高速化しているのは主に映像のエンコードとデコードです。ネットワークそのものが遅ければ、映像データを送る部分の遅延は残ります。特に250〜500Mbit/sという大量の通信をWi-Fiへ流し、アクセスポイント付近が混雑した場合、帯域不足による待ち時間が増えれば本末転倒です。Pyrowaveのエンコードが0.1ms級でも、ネットワークで数十ms待っていればゲームの操作感は良くなりません。「H.264よりPyrowaveの方が低遅延」というコーデック単体の話と、「自分のRemote Play環境で遅延が減る」という話は分けて考える必要があります。現在のWi-Fiは数百Mbit/s以上の実効速度が出る環境も珍しくないため、Pyrowaveがまったく使えないわけではありませんが、有線LANとWi-Fiでは500Mbit/sという数字の意味が違います。Ethernetはスイッチを介してホストとクライアントが安定したリンクを確保しやすい一方、Wi-Fiは同じ無線空間を複数端末が共有します。Wi-Fiで試す場合は最初から高いビットレートへ固定するより、Steamの自動設定や低めのビットレートから比較した方がよさそうです。ルーターやWi-Fi環境そのものを見直したい場合は、無線側の選び方から確認することをおすすめします。
経緯Valveは以前からRemote Playの高帯域化を進めていた
Pyrowaveだけを見ると突然登場した実験機能にも見えますが、Steam Remote Playの最近の更新を追うと流れが見えてきます。Valveは2026年6月23日の安定版更新で、Remote Playの通信速度上限を引き上げ、対応環境ではアダプティブビットレートが最大250Mbit/sまで使えるようになりました。7月には、帯域を無制限にした際にクライアント側の動画デコーダーへ過剰な負荷がかかる問題を修正しています。さらに9月1日の安定版では、それまでベータ限定だったSteam Deck OLEDへのHDR Remote Playと、実験的SteamRT3クライアントでのAV1ストリーミング対応が、全ユーザー向けの安定版へ組み込まれました。
この流れを見ると、Pyrowaveは単発の実験というより、ValveがRemote Playの映像品質・高帯域・低遅延化を段階的に進めてきた延長線上にあると考えられます。特に6月に帯域上限を引き上げたことは、数百Mbit/sを前提とするPyrowaveを後から載せるための土台としても自然です。
検証方法Pyrowaveを試すなら「平均FPS」ではなくRemote Play側を見る
Pyrowaveを比較する場合、ゲーム内FPSだけを測ってもほとんど意味がありません。知りたいのは、映像を別端末へ送るまでにどれだけ時間がかかったかです。同じPC・同じゲーム・同じ解像度・同じフレームレート・同じネットワークを使い、従来コーデックとPyrowaveだけを変更して比較する必要があります。Steam Remote Playにはストリーミングのパフォーマンス情報を確認する機能があり、エンコードやネットワーク、デコードなどを切り分けて確認できます。Pyrowaveについても、単に総遅延が何msになったかだけではなく、どの工程が短くなったのかを見る方が重要です。エンコードが3msから0.2msへ減ったのに総遅延がほとんど変わらなければ、別の部分がボトルネックになっています。反対に、有線LAN＋低遅延モニターという環境でエンコード・デコード時間が大幅に減れば、Pyrowaveのメリットがそのまま出やすくなります。
影響今すぐ何をすればいいか
- ホストPCとクライアントが1GbE以上の有線LANでルーターへ直結されているか
- Steam Client Betaに両方の端末をオプトインしているか
- Wi-Fi経由で使う場合はまず低めのビットレートから試す
- Pyrowaveのためだけの2.5GbEへの買い替え
- 4K・120Hz環境で必要な帯域の断定
- H.264/HEVC/AV1より常に高画質という判断
Q&Aよくある質問
まとめまとめ｜現時点では2.5GbEへ買い替える必要はなさそう
Steam Remote Playへ追加されたPyrowaveは、「もっと高効率に圧縮する」という最近のコーデック競争とは逆方向の発想を持っています。フレーム間予測や複雑な圧縮処理を減らし、家庭内LANの帯域を大量に使うことでエンコード・デコード時間を極限まで短縮しようとしています。
現在公開されている手動ビットレートの上限は500Mbit/sで、この数字であれば正常に動作する1GbE有線LANには十分収まります。「Steam Remote Playのために今すぐネットワーク機器を2.5GbEへ総交換する」という段階ではありません。まず確認したいのは、ホストPCとクライアントが1GbEでリンクしているか、途中のルーターやスイッチが速度を落としていないか、Wi-Fiがボトルネックになっていないかです。そのうえで500Mbit/s近いPyrowaveを使いながらNAS転送なども同時に行うのであれば、2.5GbEへ移行する意味が出てきます。
開発者のテストでは1080pで0.1ms前後という非常に短い処理時間も示されていますが、これはRemote Play全体の入力遅延を意味する数字ではありません。むしろ重要なのは、エンコード時間を削った結果、ネットワーク・デコード・ディスプレイまで含めた最終的なRemote Playの遅延が本当に減るのかです。PyrowaveはまだBetaですが、Valveが6月から帯域上限を引き上げ、その後HDRやAV1を安定版へ組み込んできた流れを考えると、Steamの家庭内ゲームストリーミングが「帯域を節約する時代」から「余ったLAN帯域を低遅延のために使う時代」へ進む可能性を感じさせる機能です。
あわせて読みたい
