Valveは10月15日付（日本時間16日）のSteam Client Betaで、Linux版Steamクライアントを64bit化し、Steam Runtimeのコンテナ内で動作させる方式へ移行した。3月から実験的な設定として提供してきた機能が、通常のベータ版に組み込まれたことになる。今回の変更は、Linuxディストリビューションによって異なるライブラリ環境への依存を減らし、Steamをより安定して動作させることを目的としている。ただし、クライアント本体が64bit化されても32bitライブラリが不要になるわけではない。今回の変更を正しく理解するには、Steamクライアント本体とゲーム、それぞれの実行に必要なライブラリを区別する必要がある。

AD

3月の実験版から通常ベータへ移行

Valveが公開した今回の更新履歴には、Linux版Steamクライアントの64bit化と、Steam Runtimeコンテナ内での実行への移行が記載されている。併せて、一部のユーザーに更新画面が表示されない問題も修正された。Valveはコンテナへの移行について、すでにゲームで利用しているものと同じ技術を使うことで、異なるLinuxディストリビューション間でも一貫した動作を確保しやすくなると説明している。

ただし、64bit版のLinux用Steamクライアントが今回初めて登場したわけではない。3月19日付のベータ更新では、すでに「SteamRT3」実験版として64bit化とコンテナ内での実行が案内されていた。当時は通常のベータクライアントとは別に提供され、利用するには設定画面で実験版を有効にする必要があった。今回の更新は、その実験的な実装を通常のベータ版へ移したものであり、安定版への正式な導入時期はまだ発表されていない。

Linux版Steamの64bit化を求める声は以前からあった。2014年9月30日には、ValveのGitHubリポジトリに、32bitライブラリを必要としない64bit専用クライアントを求める要望が投稿されている。これに対し、Valveは当時の回答で、Steamクライアントは32bitアプリケーションであるため32bitライブラリが必要であり、現時点では64bit版を開発する計画はないと説明していた。それから約12年を経てクライアント本体の64bit化が進んだものの、32bitライブラリを一切必要としない環境で動かしたいという要望まで実現したわけではない。

コンテナ化でLinuxディストリビューション間の違いを減らす

従来のLinux版Steamクライアントは、「scout」と呼ばれる古いSteam Runtimeの共有ライブラリを、ホストOS側のライブラリと組み合わせて動作していた。ライブラリとは、描画や基本的な処理など、複数のプログラムから共通して利用される機能をまとめたソフトウェア部品のことだ。ValveのSteam Runtimeに関する説明によると、従来方式ではLD_LIBRARY_PATHという環境変数を使い、Steamが用意したライブラリを検索先に追加していた。

この仕組みは幅広いLinux環境への対応に役立つ一方、Steamが利用するライブラリをすべて同じバージョンに統一できるわけではない。Valveの設計比較文書によると、従来方式では基本ライブラリであるglibcやグラフィックスドライバーをホストOSから利用し、ほかのライブラリもホストOSとscoutの間で選択していた。そのため、ホストOS側のライブラリの仕様や動作が変化すると、古いゲームに不具合が生じる可能性がある。Linuxディストリビューションごとに採用するライブラリや更新状況が異なることも、互換性の問題を複雑にしていた。

同じSteamクライアントをインストールしても、利用するOSやその更新状況によって、実際に読み込まれるライブラリの組み合わせが変わる場合がある。その結果、あるLinuxディストリビューションでは正常に動作するゲームが、別の環境では動かないといった問題につながる。Valveにとっても、不具合を再現するためにOSごとの環境差を考慮しなければならず、開発やサポートの負担が増える要因になっていた。

今回採用されたコンテナ方式は、Linuxの「名前空間（namespace）」という仕組みを使い、アプリケーションから見える実行環境をホストOSから分離するものだ。Steam Runtimeが用意する共通のライブラリ環境を利用することで、ディストリビューション固有の構成に左右される部分を減らせる。Valveはすでにゲームの実行環境でこの技術を利用しており、今回の更新ではその仕組みをSteamクライアント本体にも広げた。これにより、異なるLinux環境でも使用するライブラリの組み合わせを管理しやすくなり、動作の一貫性向上が期待できる。

ただし、SteamクライアントがSteamRT3へ移行したからといって、すべてのゲームが同じ世代のSteam Runtimeを使うようになるわけではない。Steam Runtimeには複数の世代があり、ゲームやWindowsゲーム互換レイヤーのProtonが利用する実行環境はそれぞれ異なる。今回変更されたのは主にSteamクライアント本体の実行方式であり、すでに配信されているゲームの実行ファイルが一斉に64bit化されたり、すべてのゲームの実行環境が置き換わったりするものではない。

AD

64bit化しても32bitライブラリが必要な理由

Steamクライアント本体が64bit化された一方、Valveは32bitライブラリのサポートを引き続き求めている。ベータ版の動作要件では、x86_64環境で32bitと64bitのライブラリを併用する「multilib」構成が必要とされており、基本ライブラリだけでなく、グラフィックスドライバーについても両方の版をインストールするよう明記されている。64bit版のライブラリだけで構成されたx86_64環境は、現時点ではサポート対象外だ。

つまり、Steamクライアント本体の64bit化と、32bitゲームを動かすための環境を維持することは、Valveの方針では両立する。今回の更新内容、10月17日時点のベータ版の動作要件、Valve開発者によるGitHubでの説明を基に、それぞれの変更点を整理すると次のようになる。

対象 今回の変更・維持する条件 利用者にとっての意味
Steamクライアント本体 64bitアプリケーションへ移行 クライアント本体の実行形式が変わる
クライアントの共通実行環境 Steam Runtimeのコンテナ内で実行 OSごとのライブラリの違いによる問題を減らす
ホストOSのライブラリと描画ドライバー 必要な32bit版と64bit版を引き続き要求 32bitライブラリをすべて削除できるわけではない
既存の32bitネイティブLinuxゲーム 32bitの描画環境を引き続き必要とする Steam本体の更新によってゲームが64bit化されるわけではない

この表はクライアントの変更点と互換性要件を整理したものであり、性能や必要なパッケージ数を比較したものではない。Steam本体が64bitアプリケーションとして動くことと、ゲームを実行するためにOS側が備えるべき機能は別の問題だ。また、Steam RuntimeのコンテナはグラフィックスドライバーをホストOS側から取り込んで利用するため、GPUに関する依存関係まで完全にコンテナ内で完結するわけではない。

Valveの開発者であるlostgoat氏は、日本時間10月16日のGitHubでの回答で、32bitゲームを正常に動作させるには32bit版のグラフィックスドライバー群が必要だと説明した。さらに、ProtonがWoW64に対応していても、64bit専用のホスト環境では動作しなくなる32bitネイティブLinuxゲームが数多く存在すると指摘している。Steamクライアントの64bit化だけでは、こうしたゲームとの互換性を維持できないということだ。

WoW64は、32bitのWindowsプログラムを64bit環境で実行するための互換機構であり、32bitのネイティブLinuxアプリケーションを64bit化するものではない。Windows版のゲームをProton経由で動かせる場合があっても、既存のLinux版ゲームをそのまま実行できることとは意味が異なる。そのため、WoW64への対応を理由に、Linux向けの32bitライブラリがすべて不要になるわけではない。lostgoat氏も、ホストOS側から32bitライブラリを完全に排除することは今回の目標ではなく、必要なライブラリの種類を減らすことが狙いだと説明している。

2019年のUbuntu騒動から続く32bit互換性の課題

Linuxで32bitライブラリをどこまで維持するかという問題は、Steamクライアントだけで解決できるものではない。2019年には、Ubuntuを開発するCanonicalが32bitパッケージの提供方針を巡って、ゲーム関連のコミュニティから強い反発を受けた。同社が2019年6月24日に発表した声明によると、ゲーマーやUbuntu Studio、WINEコミュニティから寄せられた意見を受け、Ubuntu 19.10と20.04 LTS向けに必要な32bitのi386パッケージを選定し、ビルドする方針へ変更した。

Canonicalは声明の中で、古いソフトウェアを動作させるために必要なパッケージをコミュニティと協力して特定し、不足するものがあればリリース後にも追加できると説明している。同時に、長期的にはコンテナ技術を活用し、新しいUbuntu環境でも古いアプリケーションを実行できるようにする構想を示していた。32bitアプリケーションとの互換性を維持する必要性と、利用が限られる古いライブラリを保守し続ける負担は、当時から課題として認識されていた。

今回のLinux版Steamの変更も、こうした長年の課題に対する取り組みの一つといえる。クライアント本体の64bit化を進める一方で、古いゲームとの互換性は維持し、共通ライブラリの管理をSteam Runtime側へ移していく方針だ。ホストOS側に必要なライブラリを減らせれば、Linuxディストリビューションの開発者にとっても、維持すべき依存関係を絞りやすくなる可能性がある。ただし、今回の変更だけで各ディストリビューションが32bit対応を廃止できるわけではなく、既存ゲームとの互換性を確保しながら段階的に依存関係を整理していく必要がある。

AD

ベータ版を試す前に確認したいOSと描画環境

Valveが公開している新しいベータ版の動作要件では、glibc 2.31以降とLinuxカーネル5.6以降が必要とされている。さらに、特別な権限を使わずにユーザー名前空間とマウント名前空間を作成できることも条件だ。これはSteam Runtimeのコンテナを動作させるために必要な仕組みであり、Linuxカーネルのバージョンが要件を満たしているだけでは十分とは限らない。ディストリビューションのセキュリティ設定によっては、名前空間の作成が制限されている場合もあるためだ。

デスクトップ環境については、D-BusのセッションバスとX11サーバーが必要とされている。X11は通常のX11セッションだけでなく、Wayland環境でX11アプリケーションを動かすXwaylandでもよい。そのため、今回の64bit化は、SteamクライアントがWaylandへ直接対応する変更を意味するものではない。また、音声にはPulseAudioまたはpipewire-pulse、描画にはOpenGLとVulkanのドライバーが必要であり、ライブラリとグラフィックスドライバーの32bit版・64bit版を両方用意する要件も残っている。

今回の更新でValveが強調しているのは、Linuxディストリビューション間での動作の一貫性だ。更新履歴には、Steamクライアントの起動時間やゲームのフレームレートが何％改善するといった性能測定結果は掲載されていない。64bit化やコンテナへの移行によって実行環境の管理は変わるものの、それだけでゲームの動作速度が向上すると判断する根拠はない。

今後の焦点は、新しい実行方式が安定版へいつ導入されるかに加え、既存のゲームとの互換性をどこまで維持できるかにある。ベータ版を試す場合も、Steamクライアントが正常に起動するかだけでなく、手持ちの古い32bitゲームが描画を含めて問題なく動作するかを確認する必要がある。ValveがホストOS側に求めるライブラリを減らしながら、こうした互換性を維持できれば、Linuxユーザーは古いゲームを引き続き楽しみつつ、新しいディストリビューションへ移行しやすくなるだろう。