Xbox Oneでは「2つのWindows 8」が同時に動く。開発者向けイベントで見えてきたシステムアーキテクチャの実態

　北米時間2014年4月2〜4日，Microsoftは，米国サンフランシスコで，開発者向けイベント「Build 2014」を開催した。本イベントはMicrosoftの幅広いソリューション――大はクラウドシステムから小は組み込み機器向けWindowsまで――を扱うもので，主なテーマは4Gamer読者向けではないのだが，Xbox Oneやゲーム開発に関するセッションもいくつか用意されていた。

セッションを担当したFrank Savage氏（Partner Development Lead，Microsoft）。かつてはあのOrigin Systemsで，「Strike Commander」や「Wing Commander 3」の開発に携わったという経歴の持ち主だ

　今回はそうしたゲーム関連のセッションから，「Understanding the Xbox One game platform built on Windows」と題するものを取り上げたい。
　2週間以上も前に開かれたイベントを今あえて取り上げるのは，このセッションでXbox OneのOS構成に関する興味深い話題が扱われたためだ。国内発売が2014年9月ということもあって，日本での詳細な情報がまだ少ないXbox Oneだが，新世代ゲーム機がどのようなOSの上で動作しているのかは，ゲーム機の仕組みに興味がある人には，なかなか面白い話になるだろう。

Xbox Oneでは3つのOSが同時に動く

　Xbox OneやPlayStation 4といった新世代ゲーム機では，ゲームを動かす「ゲームOS」以外にも，高度な機能を備えた別のOSが同時に動いて，さまざまなサービスをバックグラウンドで処理するのが一般的になっている。
　今回のセッションでは，Xbox One上でどのようなOSが動作しており，それらがどのような関係にあるのかが説明された。

　Xbox Oneでは，「仮想マシン」（Virtual Machine）と呼ばれる技術を使って複数のOSを同時に動かしている。誤解を恐れず簡単に説明すると，仮想マシンは，あるコンピュータの上で動く「疑似的なコンピュータ」のことだ。
　「仮想マシンソフト」という，ソフトウェアが作り出した擬似的な存在なので，たとえば，実際に動作しているコンピュータとはまったく異なるハードウェアであるかのように仮想マシンを振る舞わせたり，1台のコンピュータを複数台のコンピュータであるかのように振る舞わせたりすることも可能だ。
　そのうえ，1台の仮想マシン上で動くOSが暴走状態に陥ったとしても，仮想マシンソフト側でそれを停止させたり，リセットして再起動させたりすることも自由自在。そのため仮想マシンは，とくにサーバー分野で積極的に利用されている技術であるわけだ。

　さて，1台のコンピュータ上で複数の仮想マシンが動いている場合，それぞれの仮想マシン上で動くOSやアプリケーション（ゲームも当然含む）は，ほかの仮想マシンが存在することを気にせずに，あたかもそのコンピュータを自分だけで独占しているかのように動作できる。Xbox Oneでは，仮想マシンが持つこの特性を利用して，ゲームとゲーム以外のソフトウェアを共存させるのに利用しているのだ。

　具体的に説明していこう。Xbox Oneでは，ハードウェアに直接アクセスでき，かつすべての基盤となるOS「Host OS」が動いており，その上で，2つの仮想マシン「Shared partition」と「Exclusive partition」が動くという構造になっている。
　Shared partitionでは，ダッシュボードをはじめとした，ゲーム以外のユーザーインタフェース（以下，UI）やアプリケーションを管理するOS「SharedOS」が動作する。そしてExclusive partitionでは，ゲーム用のOSである「ExclusiveOS」が動く。つまり，Xbox Oneというシステムは，合計で3つのOSが動作するという，なかなか複雑な仕様になっているわけだ。Windowsを直接動作させている今日（こんにち）のPCよりも先進的なマシンだといっていいかもしれない。

Xbox OneのOS構造を示した図。最下段にあるのが基盤となる「Host OS」で，その上にShared partitionとExclusive partitionという2つの仮想マシンが置かれ，それぞれでOSが動作する

　それぞれのOSが持つ役割について順に説明しよう。
　まずHost OSは，Xbox Oneのハードウェアリソースすべてを管理し，仮想マシンソフト「Hyper-V」を動かす役目を担っている。ちなみに，一般的な仮想マシンソフトでは，Host OSのことを「ハイパーバイザ」と呼ぶ。
　Hyper-Vとは，Microsoftが開発したWindows Server向け仮想マシンソフトのこと。今ではWindows 8.x向けにも提供されている。詳細は説明されなかったが，Xbox OneのHost OSでは，サーバー用をそのまま使うのではなく，Xbox One専用に改良されたHyper-Vを用いているようだ。ハイパーバイザとは呼ばずにHost OSという名称を使っているのも，こうした違いを反映したものかもしれない。

　次なるSharedOSは，Windows 8をXbox One用に改良したOSとなっている。
　PC用のWindows 8.xでは，以前のWindowsから継承されたデスクトップ環境を提供するソフトウェアと，Windowsストアアプリ用の環境を提供するソフトウェアが動作している。これら，UIの基礎を提供するソフトウェアのことを「シェル」（shell）というのだが，Shared OSでは，「Xbox shell」と呼ばれる専用シェルが使われており，このXbox shell上で，ダッシュボードや，「Shared apps」と呼ばれる専用アプリが動作しているわけだ。

　さらにSharedOSは，「ゲーム以外のソフトウェアを動かす」だけでなく，より重要な役割も担っている。それはゲームが必要とするシステムサービスを提供するというものだ。
　サーバー用のHyper-Vでは，Shared partitionのことを「ルートパーティション」や「プライマリパーティション」と呼んでいるのだが，ここで動作するWindowsには，ハードウェアを制御するデバイスドライバを動かすという役目がある。そのため，ほかのパーティションで動いているOSがハードウェアにアクセスしようとした場合，そのアクセス要求はHost OSを経由してルートパーティション側のWindowsに送られてから処理されるのだ。

　Xbox Oneも，これとほぼ同じ仕組みを採用している。ExclusiveOS側で動くゲームがハードウェアにアクセスしようとしたときには，その処理はExclusiveOSからHost OSを経由して，SharedOS側のデバイスドライバに送られてから，実際のGPUやネットワークコントローラを動かすわけだ。
　画面の描画やネットワークアクセスといった処理もXbox OneではゲームOS側ではなく，SharedOS側で動いていると聞けば，少し驚く人もいるのではないだろうか。

　さて，実際にゲームを動かしているのは，Exclusive partitionで動いているExclusiveOSなのだが，このOSも実は，「強力にダイエットしたWindows 8」なのだという。少し話がそれるが，その背景を説明しておこう。
　Microsoftは，Windows 7の開発において，OSの中枢部分（カーネル）を大幅に整理し，必要な部品だけで構成された「MinWin」という軽量カーネルを作り上げた。MinWinは最小限の中枢部にファイルシステムやネットワーク処理機能などを含む一方で，グラフィックス機能やサウンド機能，UIといった要素は含まない。そのおかげで，メモリ使用量やストレージ使用量を削減できたと，Microsoftは当時主張していた。そしてこの仕組みは，Windows 8にも受け継がれている。
　こうした背景から推測するに，Xbox OneのExclusiveOSは，MinWinをベースに開発されたXbox One専用のゲームOSなのだろう。ベースがWindows 8とはいえ，その中核だけを取り出して使っているのがExclusiveOSというわけだ。

　ここまで読むと，Xbox Oneはゲーム機としては不釣り合いに見えるほど，複雑なOS構造を採用したように思えるだろう。たしかにこの仕組みは，純粋な性能面だけで見ればオーバーヘッドを生む要因でもある。それにも関わらずMicrosoftがゲームの実行環境を分離した理由は，いくつか考えられる。

　まず1つには，ゲームのプログラムやデータを改変から保護するために，外部からアクセスできない環境を作る必要があったからではないだろうか。SharedOSとExclusiveOSは，異なる仮想マシン上で動作しているので，万が一SharedOS側で不正なプログラムを動作させられたとしても，ExclusiveOS側のゲームを安全なまま保つことができるのだ。
　逆にゲームが暴走するようなことがあっても，SharedOS側に影響はでないので，ExclusiveOS側を安全に停止させることも可能であろう。仮想マシンを分離したことにより，お互いが安全な状態に保たれるのだ。

　また，もう1つの理由として考えられるのは，ゲーム側からハードウェアの挙動や応答速度が予測可能な環境を作るためである。
　例として，Windows上でPCゲームとゲーム以外のアプリケーションを同時に動作させている場合をイメージしてみよう。Windowsでは，ゲームのプレイ中でもほかのアプリケーションやサービスが動作しているのが一般的だ。これらゲーム以外のアプリケーションに，CPUやGPU，ネットワーク機能といったハードウェアリソースを取られてしまうと，ゲームの動作が遅くなったり，最悪止まってしまうこともある。
　汎用コンピュータであるPCならば「仕方ない」で済まされるかもしれないが，ゲーム機であるXbox Oneでそれは許されない。だが，Xbox Oneではゲーム以外の部分も強化されているので，単純に1つのOS上でゲームとゲーム以外を共存させるのは，難しい面もあるだろう。
　そこで，SharedOSとExclusiveOSを異なる仮想マシンで分離したうえで，Host OSがハードウェアリソース割り当てを確実に行うことで，SharedOS側に影響されることを防いでいるわけだ。

　深読みになるかもしれないが，MicrosoftがXbox Oneで仮想マシンを使う構成を採用した理由には，将来のXboxでハードウェアが変更されることがあっても，ゲームの互換性を維持するのが容易になるからといった理由もあるかもしれない。
　先にも述べたように，仮想マシンは擬似的なコンピュータであり，実際に動いてるハードウェアとは異なるものであるかのように振る舞える。だから，将来のXboxでCPUやGPU，チップセットやネットワーク機能などに変更があっても，仮想マシン側でその違いを吸収させることが可能だ。
　つまり，将来のXboxでXbox One用のゲームを動かすときには，Xbox Oneであるかのように振る舞う仮想マシンを作りだし，将来のXbox専用ゲームを動かす場合は，そのように振る舞う仮想マシンを作る。Xbox OneのOS構造なら，そんなことが可能になるのだ。

　もちろん，ゲームが快適に動作するだけの性能を実現しなくてはいけないので，仮想マシンがあるからといってまったく異なるCPUアーキテクチャを採用するのは難しい。だが，同じアーキテクチャの延長線上であれば，より性能や機能で優れたものを選択しやすくなる。そのために必要な技術の土台をXbox Oneで導入しておこうとMicrosoftが考えたとしても，不思議なことではないだろう。

Xbox Oneは5種類の動作状態を使い分ける

　セッション中では，Xbox Oneの動作状態に関する説明も行われた。それによると，Xbox Oneには5つの動作状態があるという。
　ExclusiveOS，つまりゲームが全画面で動作している「通常状態」（Normal）と，ゲーム中に［Xbox］ボタンを押したときの「制限状態」（Constrained），ゲームが中断された「中断状態」（Suspend），そして「SharedOSのみ」が動作している状態とシステム全体がスリープしている「低消費電力状態」（Low power）である。
　ちなみにSharedOSは，低消費電力状態を除いたすべての状態で動作しているとのことだ。デバイスドライバがSharedOS側で動くというHyper-Vの仕組みを考えれば，これは当然だろう。

Xbox Oneには5つの動作状態がある。低消費電力状態以外では，SharedOSが常に動作している点に注目

プレイ中に［Xbox］ボタンを押してダッシュボードを表示した状態が，制限状態である。ゲームは写真中央上側の大きなタイルの中に表示されている

　5つの動作状態の中でも，制限状態と中断状態については，一歩踏み込んだ説明があった。
　Xbox Oneでは，ゲームをプレイ中にXbox One Wireless Controller（以下，ゲームパッド）にある［Xbox］ボタンを押すと，画面がダッシュボードに切り替わり，ゲームは小さな窓のような「タイル」の中で動作する状態になる。これが制限状態だ。
　ゲームが全画面で動く通常状態の場合，ExclusiveOS側は8基あるCPUコアのうち，6基（コア0〜コア5）を使用できるという。ところが制限状態では，ゲーム側が利用できるリソースは制限され，使えるCPUコアは4基（コア0〜コア3）だけとなる。コア4とコア5で動作していた処理は，コア2とコア3に割り当てられるのだそうだ。
　さらに，GPUはリソースの50％しか使えなくなり，ゲームパッドはSharedOS側の操作に使うことから，ゲームの操作も行えなくなる。ただし，このような状態でも，ネットワークの利用に制限はかからない。

制限状態と中断状態の説明スライド。制限状態ではゲームから利用できるCPUやGPUのリソースが制限される

　制限状態でもゲームの動作を止めず，ネットワークも使える状態のままにしておく理由は，オンラインプレイを考慮しているためだ。ユーザーがダッシュボードに表示を切り替えるとゲームは操作できなくなるが，ゲーム自体は動作し続けて，サーバーやほかのプレイヤーとの通信を維持し続けられる。オンラインプレイはそのまま維持されるので，必要となればすぐにゲームに戻れるわけだ。

　なお，SharedOS側で実行されているアプリケーションも，CPUやGPU，メモリなどのリソースを使用できる割合に3段階の制限がある。その基準は，「SharedOS側が画面をどれくらい占有しているか」によって決まるそうだ。たとえば，画面全体にSharedOS側が表示されている場合は，2基のCPUコアを使える。その一方で，Windows 8.xのスナップ機能と似たように，画面の左右に小さくスナップ表示された状態では4分の1基分しか使えず，バックグラウンド状態では15分に1度，2秒間だけの使用に制限されている。

SharedOS側のアプリケーションは，画面をどれくらい占有しているかによってリソース割当量が変わる。メモリ容量やCPUとGPUの処理能力，さらにビデオ再生能力まで変化するという

　さて，制限状態ではゲームが動き続けるのだが，中断状態になると，ゲームはいったん終了される。ゲームが使っていたメモリは破棄されるので，ゲーム側は，再開するときに備えてプレイの状態を保存しておく必要があるという。
　プレイの状態は，「Connected Storage」と呼ばれる容量16MBの専用領域に保存される。何を保存するのかは，ゲーム開発者が任意に決められるそうだ。ただし，ゲームの中断からSharedOS側へのスムーズな切り替えを実現するために，保存は1秒以内に終えることが要求されている。

中断状態になるとき，ゲームは，容量16MBのConnected Storageに状態を保存し，再開するときにまた読み出す。何を保存するかはゲーム開発者が決められる

　ちなみに，Connected Storageの内容は，クラウド側に保存できるとMicrosoftでは謳っている。とはいっても，直接クラウド側に保存するのではなく（※1秒では16MB分のデータを保存できない），メモリやHDDなどに一時的に保存したあとで，SharedOSがクラウド側に転送するのだと思われる。クラウド側に保存するということは，中断前とは別のXbox Oneや，ほかの機器で再開することも理論上は可能だろう。とはいえ，現在のXbox Oneがそこまでサポートしているのかどうかは語られなかった。

　システム全体がスリープする低消費電力状態についても触れておこう。一口に低消費電力状態といっても，実際には2種類の状態があるそうだ。1つは通信を行わない完全なスリープ状態で，この状態が最も消費電力が少ない。もう1つは，ほとんどのデバイスはスリープしているものの，通信は機能している状態で，こちらはOSやアプリケーションの自動アップデートに使えるとのことだ。

Universal Windows Appで，Xbox OneとWindowsで同じアプリケーションが動くように

　以上のように，Xbox Oneで動作している3つのOSのうち2つは，ほぼWindows 8.xベースと述べて差し支えない。ベースとなるOSがほとんど同じで，CPUもPCと同じx86系となれば，「PCとXbox Oneで同じアプリケーションを動かせたりしないの？」と思う人もいえるだろう。

Universal Windows Appによって，Xbox OneやPC，タブレットやスマートフォンの全Windowsプラットフォームで，同じアプリケーションが動くようになるという

　Build 2014では，まさにそのための技術である「Universal Windows App」が発表されている。
　Universal Windows Appは，PC用のWindows 8.x（※タブレット端末用のWindows RTも含む）とXbox One，そしてWindows Phone 8.1といった全Windowsプラットフォーム上で動作することを目指したアプリケーションのこと。Windows 8で導入された新しいアプリケーション実行環境「WinRT」をXbox OneやWindows Phone 8.1に導入し，それによって実現するのだという。
　簡単にいってしまえば，Universal Windows AppであればWindows 8.x用のWindowsストアアプリが，Xbox Oneでも動くようになるというわけだ。PCとWindows RTタブレットしか想定されていない従来型のWindowsストアアプリはともかく，今後登場予定のUniversal Windows Appであれば，3プラットフォームを横断的にサポートして動作するアプリケーションの実現が可能になる，と理解しておけばいいだろう。

　Windowsストアアプリの品揃えがパッとしない現状を知っている人からすれば，「そんなものがXbox Oneで動いたとして，何が嬉しいんだ？」と思うかもしれない。その点は否定できないのだが，ゲームという観点では，WindowsストアアプリがXbox Oneでも動くようになれば，開発者がカジュアルゲームを従来よりも作りやすくなる効果が期待できる。
　ゲーム開発者からすれば，Windowsストアアプリとしてゲームを作れば，それがそのままXbox OneやWindows Phone 8.xで動作することになるのだから，それぞれに作り分ける必要がなくなるのだ。もちろん，タッチパネルで操作できるPCやスマートフォンと，ゲームパッドで操作するXbox Oneという操作性の違いは考慮しなくてはならないが，動作するプラットフォームが広がるというならば，ゲームを作ってみようと考える開発者もいるのではないだろうか。

　今のところ，Windowsストアアプリはよく言っても発展途上。Windows Phone 8.xはスマートフォン用OSとして後発であり，日本では搭載端末の販売すらされていない。だが，Universal Windows Appが発表されたことで，WindowsとXbox One，Windows Phone 8.xの関係が変わる可能性はある。
　同じWindowsから枝別れして独立したプラットフォームとなったXbox OneやWindows Phone 8.xが，Universal Windows Appの登場によって，「同じWindowsを基に作られた，用途別のプラットフォーム」という位置付けに変わっていくように受け取ることも可能だからだ。
　この変化は，ゲーマーにとっても決して悪い話にはならないだろう。

Build 2014での当該セッション情報（英語）