XBOX services サンドボックスの詳細

XBOX services サンドボックスの概要 も参照してください。 XBOX Live のサンドボックスは、開発のためのプライベート環境全体を提供します。 この記事では、サンドボックスとは何か、なぜ存在するのか、パブリッシャーにどのように適用されるのか、また XBOX の内部チームにどのような影響を与えるのかについて説明します。 この記事の対象読者は、XBOX One (以降) 向けのコンテンツを構築し、サンドボックスを使用するパブリッシャーです。 XBOX Live 開発は、パブリッシャーに対して、本番品質のサービスと本番 MSA 開発者アカウントを使用して本番環境でテストする大きな機会を提供します。 機能と柔軟性の向上には、開発中と一般提供中のタイトルデータを作成し、タイトルへのアクセスを管理するために、Partner Center での構成手順が必要です。 サンドボックスは本番環境でデータをパーティション分割する方法です。 すべてのコンテンツに対して単一の本番環境があるため、サンドボックスは、ある環境で生成されたデータが別の環境に交差しない “仮想環境” として機能します。

​

XBOX Live 上でコンテンツを分離する

XBOX Live には、リリース前 (開発中およびベータ)、認定、および小売のすべてのコンテンツが存在する単一の本番環境しかありません。 コンテンツ分離は、本番環境でパブリッシャーのコンテンツが漏洩しないことを保証する方法です。 その核心において、コンテンツ分離は、リソース (タイトルまたはサービス) にアクセスする権限を要求する任意の主体 (ユーザー、デバイス、またはタイトル) が、そのリソースにアクセスする権限を与えられていることを保証します。 コンテンツ分離では、タイトルまたはサービスのデータが格納されるサンドボックスにパーティションが分割され、認可ポリシーはサンドボックスのスコープ内で定義されます。 サンドボックスは、本番環境のデータをパーティション分割する方法です。

• XBOX 360 時代のサービスでは、PartnerNet と ProductionNet は 2 つの別々の環境です。
• XBOX One (以降) のサービスでは、単一の本番環境に n 個の別々の仮想環境が含まれ、各仮想環境はサンドボックスと呼ばれます。

すべてのコンテンツに対して単一の本番環境があるため、サンドボックスは実際には、ある環境で生成されたデータが別の環境に交差できないユニークな仮想環境です。 次の図は、パブリッシャーがプライベート開発用サンドボックスを作成できる単一の本番環境を示しています。 これらのサンドボックスへのアクセスは、承認された開発アカウントまたは開発キットにのみ許可されています。 図 1. 本番環境のサンドボックス。 PublisherA が開発用サンドボックスを持っているのと同様に、他のパブリッシャーもそれぞれの開発用サンドボックスを持っています。 同じタイトル ID が異なるサンドボックスに存在する場合がありますが、そのタイトル ID に対して生成されるデータはサンドボックス間で異なります。 Microsoft のみが投入できる 2 つのシステムサンドボックス、CERT と RETAIL があります。 名前が示すとおり、CERT サンドボックスはリリース前の認定を受けているタイトル用であり、RETAIL サンドボックスはすべての小売ユーザーおよびデバイスからアクセス可能な、実際の金銭を扱うサンドボックスです。 以前 XBOX Live ではタイトル ID が一意でしたが、現在はタイトル ID とサンドボックス ID の組み合わせが一意になります。 以前は一意として扱われていた製品 ID や他の ID 空間についても同様です。 それらは現在、サンドボックス ID と組み合わせる必要があります。 XBOX Live のすべてのデータは、システム全体を通じてサンドボックス ID によって主にパーティション分割されます。

​

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

タイトルは Partner Center で誕生します。 タイトルにはタイトル ID、製品 ID、サービス構成 ID (SCID) が割り当てられます。 タイトルや製品それ自体は、XBOX Live にとって意味を持ちません。 単一のタイトルを小売と開発の両方で同時に利用できるようにするために、Partner Center は必要な区別を作成し維持するためにタイトルのインスタンス化をサポートしています。 タイトルのインスタンスはサンドボックスに存在し、ここでサンドボックスが登場します。 Partner Center でタイトルを作成するには、パブリッシャーは製品グループを作成し、製品グループのジャンルを指定し、その中に個々の製品を作成します。 図 2. 製品グループ、製品、製品インスタンス、およびサンドボックスの関係。

​

製品インスタンス

製品インスタンスは、特定のサンドボックスにおけるタイトル、製品、および構成データの投影です。 このデータは次の 3 つの領域で説明されます: サービス構成、カタログメタデータ、およびバイナリ。

​

サービス構成

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

​

カタログメタデータ

販売テキスト、アートアセット、可用性/オファー情報、ライセンスデータなど、カタログに存在するメタデータ。

​

バイナリ

バイナリは次の 2 つの方法のいずれかで表現できます:

1. サイドローディングを有効にするためのメタデータのみ。これにはコンテンツ ID、バージョン情報、およびライセンス情報が含まれます。
2. CDN に伝搬され、クライアントにダウンロード可能な完全なバイナリ。

​

アクセス権を正しく取得する

XBOX One (以降) のコンテンツには 2 つの明確なアクセスタイプがあります: デザインタイムアクセス — Partner Center 経由の PC からのアクセス — 製品に取り組む人がコンテンツ、構成、およびメタデータをアップロード、整理、および操作することを許可しますが、製品のインスタンスを実行または再生することは許可しません。 ランタイムアクセス — XBOX コンソールからのアクセス — 開発者、テスター、レビュアー、そして最終的には顧客が製品インスタンスを実行または再生することを許可します。 サンドボックスについて話すときは、通常、XBOX Live 上で実行されるコンテンツへのランタイムアクセスについて話しています。 XBOX Live のサービスにアクセスするには、タイトル ID が必要です。 MicrosoftGame.config にタイトル ID が含まれていると、コンソールはタイトル ID を XBOX Live に送信します。 XBOX Live のセキュリティサービスは、主体 (デバイスまたはユーザー) がタイトルへのアクセス権を与えられていない限り、有効なトークンを返しません。 この検証プロセスがコンテンツ分離の要となります。 非常に高いレベルで見ると:

• 主体グループは XBOX ユーザー ID (XUID)、デバイス ID、タイトル ID、またはサービス ID を含むことができます。
• サンドボックスはタイトル ID、製品 ID、またはサービス構成 ID (SCID) を含むことができます。
• 主体グループにサンドボックスへのアクセスが与えられます。

したがって、ユーザーまたはデバイスがサンドボックス内のリリース前タイトルにアクセスするには、まず Partner Center を通じてアクセスを許可する必要があります。 図 3. Partner Center 経由でアクセスをセットアップするモデル コンテンツ分離の有効性は、あなたの組織が次のプロセスを所有していることに基づいています:

• Partner Center ユーザーアカウント、各ユーザーがランタイムアクセスのためにログオンする開発アカウント、および各ユーザーがメンバーシップを付与されるユーザーグループを作成する。
• 信頼できるコンソールのデバイスグループを作成する。
• 開発用サンドボックスごとに、その中の製品インスタンスにアクセスできるユーザーグループとデバイスグループを正確に指定する。

このセットアップの例を下の図に示します。 図 4. 承認されていないユーザーの資格情報はサンドボックスへのアクセスに失敗し、承認された Partner Center ユーザーアカウントの通常の資格情報も失敗します。 承認された Partner Center ユーザーアカウントが所有する開発アカウントの資格情報のみが、サンドボックスと、現在その中にあるすべての製品インスタンスへのランタイムアクセスを取得することに成功します。

​

開発アカウントのセットアップ

XBOX One (以降) の開発アカウントは、特別なルールが適用された標準の Microsoft account (MSA) にすぎません。 開発アカウントは XBOX Live で開発のために使用されます。 開発アカウント:

• Partner Center で作成する必要があります。
• パブリッシャーにより作成された際、外部開発者ロールが割り当てられます。
• 開発アカウントを作成した Partner Center アカウントに紐付けられます。
• 開発キットにのみログインできます。小売デバイスへの開発アカウントのログインは拒否されます。
• テストのために XBOX Live Developer Gold サブスクリプションまたはその他のサブスクリプションを無料で購入できます。

​

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

主体グループの最初の種類であるユーザーグループは、Partner Center ユーザーの集まりです。 Partner Center ユーザーがユーザーグループに追加されると、これらの Partner Center ユーザーと共にそれらの開発アカウントも流れます。 したがって、ユーザーグループがサンドボックスに割り当てられると、そのユーザーグループ内の Partner Center ユーザーに関連する開発アカウントが適切な主体グループに追加され、主体グループはサンドボックスをバックアップする主要なリソースセットを持つポリシーがセットアップされます。

​

デバイスのセットアップ

デバイスも主体グループに追加されます。 デバイスは、Game Developer Store 経由でエンタイトルメントが購入され、デバイスが開発キットとしてプロビジョニングされている場合にのみ、開発キットとして使用できます。 デバイスが開発キットとしてプロビジョニングされると、そのデバイスはデバイスグループに追加できるデバイスのリストに表示されます。

​

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

主体グループの 2 つ目の種類であるデバイスグループも、サンドボックスへのアクセスを与えることができます。 セットアップは前述のユーザーグループのセットアップと同様です。

​

サンドボックス

​

サンドボックスとは何か?

簡単に言うと、サンドボックスは本番環境でデータをパーティション分割する方法です。

​

なぜサンドボックスが必要か?

ユーザーやデバイスがタイトルにアクセスするのと同様に、タイトルはサービスにアクセスします。 サービスリソースへのアクセスがタイトルのセットに付与される “タイトルグループ” の概念を導入します。 XBOX One (以降) には、リリース前と小売の両方の全コンテンツに対して単一の本番環境があります。 したがって、同一タイトルの複数のインスタンス (リリース前/小売) が同じリソースのインスタンスで動作することを防止する必要があります。

​

サンドボックスには何が入っているか?

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

​

サンドボックス ID とは何か?

サンドボックス ID は、タイトル、製品、またはサービス構成のデータをパーティション分割する単位です。 複数のタイトルが同じサンドボックスに存在することができ、これがサービス構成データを共有するための前提条件です。 サンドボックス ID (大文字と小文字を区別) は、次の形式の文字列です: <PublisherMoniker>.n。 サンドボックス ID の例、XLDP.5 について以下に説明します:

• パブリッシャーモニカはすべてのパブリッシャーにわたって一意です。したがって、“XLPD” はこの特定のパブリッシャーのパブリッシャーモニカです。パブリッシャーモニカは、Partner Center で開発者アカウント マネージャーによってパブリッシャーが “有効化” されたときに作成されます。
• 数字*“n”* はサンドボックスの番号を識別します。この場合、“5” はこのパブリッシャー用に作成された 6 番目のサンドボックスです。

タイトルデータがサービスを通過するときに、XBOX services はサンドボックス ID を使用して、生成されるデータの “環境” を一意に識別します。

​

どのデータがサンドボックス化されるか?

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

​

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

開発者は開発キット上でサンドボックス ID を設定することで、開発キットが動作するサンドボックスを設定します。これはグローバルオーバーライドサンドボックスとしても知られています。 したがって、開発キット内のタイトル (シェルアプリおよび通常のアプリ) から XBOX Live サービス (例: 実績、マッチメイキング、ライセンス、EDS など) へのすべてのリクエストは、そのサンドボックスで行われます。 グローバルオーバーライドサンドボックスはまた、参照時にはグローバルオーバーライドサンドボックスに投入されたコンテンツのみが表示されることを意味します。

​

サンドボックスの種類

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

• パブリッシャーサンドボックス。パブリッシャーは自身の開発中サンドボックスにアクセスできます。これらは XLDP.0、XLDP.1、XLDP.2、XLDP.3 などのようになります。ここにパブリッシャーはタイトルの製品インスタンスを配置します。これらのサンドボックスへのアクセスは、パブリッシャーがアクセスを許可したユーザー/デバイスに制限されます。
• Microsoft サンドボックス。これらは組み込みのサンドボックスです: RETAIL と CERT。これらの保護されたサンドボックスに公開できるのは Microsoft のみです。

​

CERT サンドボックス

タイトルが一般提供の準備ができたら、まず認定を受ける必要があります。 CERT サンドボックスは、認定に関わる個人のみがアクセスできる Microsoft 制御のサンドボックスです。 パブリッシャーは、自身が所有するコンテンツのうち認定を受けているものを確認できます。 認定中に不合格となった製品インスタンスは、開発サンドボックスに戻して、パブリッシャーが Partner Center を使ってデバッグおよび修正することができます。

​

RETAIL サンドボックス

RETAIL サンドボックスは、XBOX One (以降) 向けに作成されたすべてのコンテンツの最終目的地です。 タイトルが認定に合格すると、RETAIL サンドボックスに追加されます。 RETAIL サンドボックスで実行が許可されるのは、グリーン署名されたコンテンツのみです。 これは、パブリッシャー主導のベータも RETAIL サンドボックスで行われるという重要な意味を持ちます。 RETAIL サンドボックスで生成されるデータは実際の顧客本番データを表します。 RETAIL サンドボックス内のコンテンツへのアクセスは、コンテンツ分離により引き続き制御可能です。 例えば、パブリッシャー主導のベータは RETAIL サンドボックスで実行され、パブリッシャーはパブリッシャー定義のベータリソースセットタイトルにアクセスできる主体グループを選択します。 ベータタイトルによって生成されるサービスデータは実際の本番 (プロダクション) データであり、タイトルが一般提供に移行しても引き続き存在します。

​

サンドボックス間のデータ相互作用

定義上、サンドボックスはデータ共有を制限するコンテナです。 したがって、サンドボックス間のデータ相互作用はできません。

​

サンドボックスを整理する

このセクションでは、パブリッシャーがサンドボックスを整理する方法の例を示します。 パブリッシャーはデータを整理するためのサンドボックスの使用方法を理解する必要があります。 以下の例は、コンテンツ分離を伴うランタイムアクセス管理のみを示しています。

​

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

パブリッシャーの基本的な構造は次のようになります:

• パブリッシャーが所有するすべてのユーザーおよびデバイスがデザインタイムとランタイムの両方でアクセスできる 2 つのタイトル。
• タイトルごとに 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 へのアクセスのみを持ちます。 また、財務ユーザー (グループ C) は TitleX へのデザインタイムアクセスを持っています。 財務ユーザーグループは通常、タイトルのランタイムデバッグを行わないため、分離されています。

​

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

この例では、要件が少し変わります:

• 2 つのタイトル。
• 各タイトルへのアクセスは、特定の個人のセットに制限されるべき。
• タイトルごとに 1 つの製品インスタンス。
• タイトルのデザインタイム Partner Center 構成データへのアクセスが必要な管理者ユーザーグループ。このグループの個人はすべてパブリッシャーの管理者であり、カタログに公開されるすべてのデータ (カタログメタデータ、財務、マーケティング、認定申請など) を制御できます。

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

​

シナリオ 4: 自由なスタイル

接続の数と冗長性を避けるために、サンドボックスのランタイム接続のみを示すことを選択しました。 その他のデザインタイムアクセス権限を追加することを妨げるものはありません。 この例では、要件は次のとおりです:

• 特定の人物のみがパブリッシャー内の特定のタイトルにアクセスできる。
• パブリッシャーは異なる会社のベンダーと連携しており、これらのベンダーは短期の場合がある。
• パブリッシャーはタイトルを廃止できるべきであり、そうすることでベンダーや FTE がアクセスしていたデータへのアクセスを防止できるべき。

この要件をモデル化するために、次のような構造を採用できます。 以下のモデルに従います:

• TitleX と TitleY はそれぞれサンドボックス XLDP.1 に 1 つの製品インスタンスのみを持つ。
• TitleZ は 2 つの製品インスタンスを持ち、1 つはサンドボックス XLDP.2、もう 1 つはサンドボックス XLDP.3 にある。
• FTE ユーザーグループ B にはすべてのサンドボックスの製品インスタンスへのアクセスが与えられる。
• ベンダーユーザーグループ A はベンダー専用のユーザーグループで、サンドボックス XLDP.1 へのアクセスが与えられる。
• ベンダーデバイスグループ C はベンダー専用のユーザーグループで、サンドボックス XLDP.3 へのアクセスが与えられる。

​

デバイスがターゲットとしているサンドボックスを判定する

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