高度な Xbox サービス サンドボックス

「Xbox サービス サンドボックスの概要」も参照してください。

Xbox Live のサンドボックスは、開発用の完全にプライベートな環境を提供します。 この記事では、サンドボックスとは何か、サンドボックスが存在する理由、サンドボックスがパブリッシャーに適用されるしくみ、および、サンドボックスが内部の Xbox チームにどのような影響を及ぼすかについて説明します。 この記事の対象ユーザーは、Xbox One (またはそれ以降) のコンテンツを作成し、サンドボックスを使用するパブリッシャーです。

Xbox Live 開発では、実稼働品質のサービスと MSA デベロッパー アカウントを使用して実稼働環境でテストを行うための、これ以上ない機会がパブリッシャーに提供されます。 機能と柔軟性の向上に伴い、開発中および一般提供後、タイトル データを作成したり、タイトルへのアクセスを管理したりするための構成手順がパートナー センターで必要になっています。

サンドボックスは運用環境のデータをパーティション分割するための方法です。 すべてのコンテンツ向けの単一の実稼働環境が存在するので、サンドボックスは、ある環境で生成されたデータが別の環境に移動できない一意の仮想環境として機能します。

Xbox Live でコンテンツを分離する

Xbox Live では、単一の実稼働環境のみが存在し、すべてのプレリリース (開発中およびベータ) コンテンツ、サーティフィケーション コンテンツ、およびリテール コンテンツがその環境に存在します。

コンテンツの分離は、運用環境で公開元のコンテンツの漏洩がないことを保証するための手段です。 その中心的な機能として、コンテンツの分離は、リソース (タイトルまたはサービス) にアクセスするための権限を要求するプリンシパル ユーザー、デバイス、またはタイトルが、リソースへのアクセスを承認されていることを保証します。 コンテンツの分離により、パーティションはサンドボックスに分割され、タイトルまたはサービスのデータはサンドボックスに格納されます。つまり、承認ポリシーはサンドボックスのスコープの内部で定義されます。

サンドボックスは、実稼働環境内のデータをパーティション分割するための手段です。

• Xbox 360 の ERA サービスでは、PartnerNet と ProductionNet は 2 つの異なる環境です。

• Xbox One (またはそれ以降) のサービスでは、1つの実稼働環境に、固有の仮想環境 n 個含まれています。各仮想環境はサンドボックスと呼ばれます。

すべてのコンテンツ向けの単一の実稼働環境が存在するので、サンドボックスは実際には、ある環境で生成されたデータが別の環境に移動できない一意の仮想環境です。

次の図は単一の実稼働環境を示しており、パブリッシャーはこの環境に、自社用の非公開の開発サンドボックスを作成できます。 承認された開発者アカウントまたは開発キットのみが、これらのサンドボックスへのアクセスを許可されます。

図 1. 実稼働環境内のサンドボックス

PublisherA が自社用の開発サンドボックスを持っているのと同じように、他のパブリッシャーも自社専用の開発サンドボックスを持っています。 同じタイトル ID が複数の異なるサンドボックスに存在することもできますが、そのタイトル ID に対して生成されるデータは、サンドボックス間では別個のデータとなります。

CERT と RETAIL の 2 つのシステム サンドボックスは Microsoft のみが設定できます。 名前が示すように、CERT サンドボックスはリリース前の認定を受けているタイトル用のサンドボックスであり、RETAIL サンドボックスはすべての製品ユーザーおよび製品デバイスがアクセスできる実際の製品を表しているサンドボックスです。

タイトル ID は従来、Xbox Live 内で一意でしたが、現在ではタイトル ID にサンドボックス ID を加えたものが一意な ID となります。 以前は一意の ID として扱われていた製品 ID やその他の ID 空間にも、同じことが当てはまります。 これらはサンドボックス ID とペアにすることが必要になりました。 Xbox Live のすべてのデータは主に、システム全体を通じてサンドボックス ID によってパーティション分割されることになります。

タイトル用の初期セットアップ

タイトルはパートナー センターで誕生します。 タイトルには、タイトル ID、製品 ID、サービス コンフィグ (Service Configuration) ID (SCID) が割り当てられます。

それ専用のタイトルや製品は、Xbox Live では意味を持ちません。 1 つのタイトルを製品版や開発用に同時に使用できるようにするため、パートナー センターでは、タイトルのインスタンス化がサポートされます。これにより、タイトルを必要に応じて区別して維持することができます。 タイトルのインスタンスはサンドボックスに存在し、これがサンドボックスの役割です。

パートナー センターでタイトルを作成する場合、パブリッシャーは製品グループを作成し、製品グループのジャンルを指定してから、その中に個別の製品を作成します

図 2: 製品グループ、製品、製品インスタンス、およびサンドボックス間の関係

製品インスタンス

製品インスタンスは、特定のサンドボックス内のタイトル、製品、および構成データを投影したものです。 このデータについて、サービス構成、カタログ メタデータ、およびバイナリの 3 つの領域に分けて説明します。

サービス構成

サービス構成の定義 (イベント、統計、実績など)。 サービス構成は製品インスタンスのレベルで定義されます。

カタログ メタデータ

カタログに含まれるメタデータであり、販促テキスト、アート アセット、提供/オファー情報、ライセンス データなどが含まれます。

バイナリ

バイナリは 2 つの形態のいずれかで表される可能性があります。

1. メタデータのみ。サイドローディングを可能にします。 これにはコンテンツ ID、バージョン情報、およびライセンス情報が含まれます。

2. CDN に伝達されてクライアントがダウンロードできるようになる完全なバイナリ。

アクセス権の取得

Xbox One (またはそれ以降) にあるコンテンツには、2 種類のアクセス権があります。

設計時アクセス - PC からのパートナー センターを介したアクセスであり、製品に携わる要員がコンテンツ、構成、メタデータをアップロード、整理、および操作することを許可しますが、製品のインスタンスを実行またはプレイすることは許可しません。

実行時アクセス - Xbox 本体からのアクセスであり、開発者、テスト担当者、レビュー担当者、そして最終的にはユーザーがプロダクト インスタンスを実行および再生することを許可します。

サンドボックスについて説明するとき、通常は、Xbox Live 上で実行されるコンテンツへの実行時アクセスに関する説明をしています。 Xbox Live 内のサービスにアクセスするためには、タイトル ID が必要です。 MicrosoftGame.config のタイトル ID が含まれている場合、本体は Xbox Live にタイトル ID を送信します。 プリンシパル (デバイスまたはユーザー) がタイトルへのアクセスを許可されていない場合、Xbox Live セキュリティ サービスは有効なトークンを返しません。

この検証プロセスは、コンテンツ分離の最も重要な機能です。 このプロセスの概要を次に説明します。

• プリンシパル グループには、Xbox ユーザー ID (XUID)、デバイス ID、タイトル ID、またはサービス ID を含めることができます。

• サンドボックスには、タイトル ID、製品 ID、またはサービス構成 ID (SCID) を含めることができます。

• プリンシパル グループにはサンドボックスへのアクセス権が与えられます。

したがって、ユーザーやデバイスがサンドボックス内のプレリリース タイトルにアクセスするには、まずパートナー センターを通じてアクセス権が与えられる必要があります。

図 3: パートナー センターを通じてアクセスをセットアップする場合のモデル

コンテンツの分離の有効性は、組織で以下のプロセスが実施されているという事実に基づきます。

• パートナー センター ユーザー アカウント、各ユーザーが実行時アクセスのためのログオンに使用するデベロッパー アカウント、およびユーザー グループを作成している (ユーザー グループ内で各ユーザーはメンバーシップを付与されます)。

• 信頼された本体のデバイス グループを作成している。

• どのユーザー グループおよびデバイス グループがサンドボックス内の製品インスタンスにアクセスできるかを、開発サンドボックスごとに正確に指定している。

このセットアップに関する例を、次の図で示します。

図 4. 承認されていないユーザーの資格情報ではサンドボックスへのアクセスに失敗します。承認されたパートナー センター ユーザー アカウントの通常の資格情報でも同様です。 承認されたパートナー センター ユーザー アカウントによって所有されるデベロッパー アカウントの資格情報のみが、サンドボックスと、現在そのサンドボックス内にあるすべてのプロダクト インスタンスへの実行時アクセスに成功します。

デベロッパー アカウントのセットアップ

Xbox One (またはそれ以降) の開発アカウントは、特別なルールが適用された標準的な Microsoft アカウント (MSA) です。 デベロッパー アカウントは開発のために Xbox Live で使用されます。

デベロッパー アカウントの特性は以下のとおりです。

• パートナー センターで作成される必要があります。

• パブリッシャーによって作成されるときに、外部開発者のロールを割り当てられます。

• 開発アカウントを作成したパートナー センター アカウントまたはパートナー センター アカウントと結び付けられます。

• 開発キットにしかログインできません。 製品デバイス上では開発者アカウントへのログインは拒否されます。

• テストを目的とした場合は、Xbox Live 開発者向けのゴールド サブスクリプションまたは他のサブスクリプションを無料で購入できます。

ユーザー グループのセットアップ

第 1 の種類のプリンシパル グループであるユーザー グループはパートナー センター ユーザーのコレクションです。 パートナー センター ユーザーがユーザー グループに追加されると、そのグループのデベロッパー アカウントが、これらのパートナー センター ユーザーに適用されます。

したがって、ユーザー グループがサンドボックスに割り当てられるとき、そのユーザー グループ内のパートナー センター ユーザーに関連付けられたデベロッパー アカウントが適切なプリンシパル グループに追加され、プリンシパル グループは、サンドボックスの背景にあるプライマリー リソース セットによってポリシーをセットアップします。

デバイスのセットアップ

デバイスもプリンシパル グループに追加されます。 Game Developer Store を通じて資格を購入し、デバイスを開発キットとしてプロビジョニングする場合、デバイスは開発キットとしてのみ使用できます。

デバイスが開発キットとしてプロビジョニングされると、デバイス グループに追加できるデバイスの一覧にそのデバイスが表示されます。

デバイス グループのセットアップ

第 2 の種類のプリンシパル グループであるデバイス グループにもサンドボックスへのアクセス権を付与できます。 セットアップは、前に詳しく説明したユーザー グループのセットアップと同様です。

サンドボックス

サンドボックスとは

簡潔に言えば、サンドボックスは運用環境のデータをパーティション分割するための方法です。

サンドボックスが必要な理由

ユーザーやデバイスがタイトルにアクセスするのと同じように、タイトルはサービスにアクセスします。 "タイトルグループ" という概念について説明します。これにより、一連のタイトルがサービス リソースにアクセスできるようになります。

プレリリース版とリテール版の両方のすべてのコンテンツを対象として、Xbox One (またはそれ以降) には 1 つの実稼働環境があります。 したがって、1 つのタイトルの複数のインスタンス (プレリリース版とリテール版) を、同じリソースのインスタンスで動作させることはできません。

サンドボックスとは ?

サンドボックスには、サンドボックスに追加されるすべてのタイトルの製品インスタンスが含まれます。

サンドボックス ID とは

サンドボックス ID は、タイトル、製品、サービス構成に関するデータのパーティション分割単位を表します。複数のタイトルが同じサンドボックス内に共存することができます。これは、それらのタイトルがサービス構成データを共有するための前提条件となります。

大文字と小文字が区別されるサンドボックス ID は、<PublisherMoniker>.n という形式の文字列です。

XLDP.5 というサンドボックス ID の例の説明は次のようになります。

• 発行元リンク パスは、すべての発行元に固有です。 "XLPD" は、この特定の発行元の発行元リンク パスです。 開発者のリンク パスは、開発者が開発者アカウント マネージャーによってパートナー センターで "アクティベーション"されるときに作成されます。

• 数字 "n" は、サンドボックスの番号を示します。 この場合、"5" はこの発行者の6つめのサンドボックスです。

タイトルデータがサービスを経由する場合、Xbox サービスはサンドボックス ID を使用して、生成されたデータの "環境" を一意に識別します。

どのようなデータがサンドボックス対象ですか?

次の図では、どのようなユーザー データやタイトル データがサンドボックス化されるかを示しています。

グローバル オーバーライド サンドボックス

開発者は、開発キット上でサンドボックス ID を設定することによって、開発キットが動作するサンドボックスを設定します。これはグローバル オーバーライド サンドボックスとも呼ばれます。 したがって、開発キットで Xbox Live サービス (実績、マッチメイキング、ライセンス、EDS など) に対してタイトル (シェル アプリおよび通常のアプリ) から実行されるすべての要求はそのサンドボックスで実行されます。

グローバル オーバーライド サンドボックスでは、このサンドボックスに取り込まれたコンテンツのみが参照時に表示されます。

サンドボックスの種類

サンドボックスには 2 つの異なるカテゴリーがあります。 これらのカテゴリーは以下のように定義されます。

• パブリッシャー サンドボックス。 公開元はそれぞれの開発中サンドボックスにアクセスできます。 これらのサンドボックスは、XLDP.0、XLDP.1、XLDP.2、XLDP.3 のような名前になります。これは、公開元が自社タイトルの製品インスタンスを配置する場所です。 これらのサンドボックスへのアクセスは、公開元がアクセスを許可するユーザー/デバイスに限定されます。

• Microsoft サンドボックス。 これらは組み込みのサンドボックスである RETAIL および CERT です。Microsoft のみが、これらの保護されたサンドボックスに公開することを許可されています。

CERT サンドボックス

一般提供の準備ができたタイトルは、まず認定に合格する必要があります。 CERT サンドボックスは Microsoft が管理するサンドボックスであり、認定の担当者のみがアクセスできます。 公開元は、自社が保有するどのコンテンツが認定に合格しているかを確認できます。

サーティフィケーション中に不合格となったプロダクト インスタンスは、パブリッシャーがパートナー センターを使用してデバッグと修正を行えるよう、開発サンドボックスに戻すことができます。

リテールサンドボックス

リテールサンドボックスは、Xbox One (またはそれ以降) 用に作成されたすべてのコンテンツの最終的な場所です。

タイトルが認証されると、それが小売サンドボックスに追加されます。 署名済みコンテンツのみが RETAIL サンドボックスでの実行を許可されます。 これには、発行元が運用できるベータ版も RETAIL サンドボックスで実行されるという重要な意味があります。 RETAIL サンドボックスで生成されるデータは実際の顧客の実稼働データを表します。

RETAIL サンドボックス内のコンテンツへのアクセスは、引き続き、コンテンツの分離を通じて制御可能です。 たとえば、発行元が運用できるベータ版は RETAIL サンドボックスで実行され、この場合、発行元が定義するベータ リソース セットのタイトルにどのプリンシパル グループがアクセスできるかを、発行元が選択します。 ベータ タイトルによって生成されるサービス データは実際の実稼働データであり、タイトルが一般提供に移行した後も存続します。

サンドボックス間のデータのやり取り

定義によれば、サンドボックスはデータの共有を制限するコンテナーです。 したがって、サンドボックス間のデータのやり取りは不可能です。

サンドボックスの整理

このセクションでは、公開元が実行できるサンドボックスの整理方法の例を示します。 パブリッシャーは、サンドボックスを使用してデータを整理する方法を理解する必要があります。

以下の例では、コンテンツの分離による実行時アクセス管理のみを示します。

シナリオ 1: 2 つのタイトル、1 つのサンドボックス

公開元にとっての基本的な構造として次のようなものが考えられます。

• 設計時と実行時のどちらの場合も、公開元が所有するすべてのユーザーとすべてのデバイスがアクセスできる 2 つのタイトル。

• タイトルごとに 1 つのプロダクト インスタンス。

この場合、公開元に必要なのは、すべてのプレリリース コンテンツ用の 1 つのサンドボックスだけです。

次の図にユーザー グループを示します。 公開元は、必要に応じてユーザー グループの代わりにデバイス グループを使用することもできます (デバイス グループの方が簡単である場合など)。 また、このユーザー グループは、サンドボックス XLDP.1 とこのサンドボックス内のタイトルに、実行時および設計時にアクセスできます。

シナリオ 2: 1 つのタイトル、異なるチーム

このモデルでの要件は以下のとおりです。

• 1 つのタイトル。

• 開発チームは日単位のビルドを使用して作業する。

• QA チームは週単位の LKG を使用して作業する。

• バグがあった場合、開発チームは週単位の LKG をデバッグする必要がある。

• ファイナンス チームは、タイトルのカタログ リリースに関連する価格カードやその他のメタデータにアクセスする必要がある。

次の図は、TitleX に 2 つの製品インスタンス PI-1 と PI-2 があることを示しています。 製品インスタンスはサンドボックス内に存在する必要がありますが、同じタイトルの 2 つの製品インスタンスが同じサンドボックス内に存在することはできません。 そのため、TitleX-PI-1 はサンドボックス XLDP.1 内にあり、TitleX-PI-2 はサンドボックス XLDP.2 内にあります。

開発ユーザー グループは両方のサンドボックスにアクセスできますが、QA ユーザー グループはサンドボックス XLDP.2 にしかアクセスできません。

また、ファイナンス ユーザー (Group C) は TitleX への設計時アクセスが可能です。 ファイナンス ユーザー グループは通常、タイトルの実行時デバッグにはかかわらないため、分離されています。

シナリオ 3: 2 つのタイトル、完全に分離

この例では、要件が少し異なります。

• 2 つのタイトル。

• 各タイトルへのアクセスを特定の個人の集合に制限する必要がある。

• タイトルごとに 1 つのプロダクト インスタンス。

• タイトルの設計時パートナー センター構成データにアクセスする必要がある管理ユーザー グループ。 このグループ内の個人は全員が公開元の管理者であり、カタログに公開されるすべてのデータ (カタログ メタデータ、ファイナンス、マーケティング、認定の申請などに関するデータ) を制御できます。

このモデルでは、公開元は両方のタイトルを完全に分離しておくことを選択し、これら 2 つのタイトルを 2 つの異なるサンドボックスに割り当てました。 またパブリッシャーは、別個の管理ユーザー グループを作成することを選択し、2 つの製品へのアクセスを割り当てました。

シナリオ 4: 自由自在に

以下の例では、接続の数を少なくして説明を短くするために、サンドボックスの実行時接続のみを示しました。 設計時のその他のアクセス許可も自由に追加することができます。

この例では、要件は以下のとおりです。

• 公開元内部の特定の要員のみが特定のタイトルにアクセスできる。

• 公開元はさまざまな企業のベンダーと協業し、これらのベンダーは短期契約である場合がある。

• 公開元は、タイトルを使用停止にすることによって、ベンダーまたは FTE がアクセスしていたデータへのアクセスを遮断できる必要がある。

この要件をモデル化するために、次のような構造を採用することができます。

使用したモデルは次のとおりです。

• TitleX と TitleY の製品インスタンスが、サンドボックス XLDP.1 にそれぞれ 1 つだけある。

• TitleZ には 2 つの製品インスタンスがあり、1 つはサンドボックス XLDP.2 に、もう 1 つはサンドボックス XLDP.3 にある。

• FTE User Group B は、すべてのサンドボックス内の製品インスタンスへのアクセスが許可される。

• Vendor User Group A はベンダーのみのユーザー グループであり、サンドボックス XLDP.1 へのアクセスが許可される。

• Vendor Device Group C はベンダーのみのユーザー グループであり、サンドボックス XLDP.3 へのアクセスを付与される。

デバイスが対象とするサンドボックスの決定

Xbox サービス API にはアプリ構成シングルトンが含まれており、実行時にタイトルが対象とするサンドボックスを確認できます。 これは、GDK を使用している場合に XSystemGetXboxLiveSandboxId によって行われます。