> ## Documentation Index
> Fetch the complete documentation index at: https://devdocs.xbox.com/llms.txt
> Use this file to discover all available pages before exploring further.
# コンテンツ更新のベスト プラクティス
> コンテンツ更新のベスト プラクティス
**MSIXVC2 を使用していますか?** このページで説明するアライメントとレイアウトの制約は、従来の MSIXVC 形式に適用されます。MSIXVC2 では、これらの要件を排除するコンテンツ ベースのセグメント化を使用します。MSIXVC2 のコンテンツ更新ガイダンスについては、[MSIXVC2 によるコンテンツ更新](/build/core-features/common/packaging/packaging-updates-msixvc2) を参照してください。
## 概要
リリース後にデータを変更、追加、または削除することによって、コンテンツ パッケージを更新できます。更新を開始するには、更新されたパッケージ全体を Partner Center にアップロードして公開します。以降のコンテンツのデジタル インストールでは、更新されたパッケージが直接ダウンロードされます。システムのコンテンツ更新技術は、既存のインストールを変更して更新されたパッケージを反映します。
Microsoft Game Development Kit (GDK) のコンテンツは、サブファイル粒度で動作する XVC または MSIXVC パッケージにパッケージ化されます。
データはインプレースで上書きできます。また、4 キビバイト (KiB) (4,096 バイト) の倍数でファイルへのデータ挿入または削除も可能です。
データを効率的に移動することはできません。
すでにコンテンツ更新が入っているゲームを元のゲーム ディスクからユーザーがインストールする場合、インストール プロセスはディスクとクラウドの両方からデータを取得します。パッケージの変更されていない部分はディスクからインストールされ、更新されたデータはストリーミング インストールによってクラウドからダウンロードされます。このプロセスは、システム UI とすべてのゲーム内 API に対して、通常のストリーミング インストールと同じ動作をします。
コンソールまたは PC が以前にインストールしたコンテンツを更新すると、プロセスはインストールされている XVC または MSIXVC パッケージ ファイルをインプレースで変更して、新しいデータや削除されたデータに対応し、新しいデータをダウンロードします。更新がインストールを開始してから完了するまでの間、ゲームは実行できません。
## パッケージを効率的に作成する
コンテンツ更新は、ゲーム開発プロセスを妨げないように努めます。ゲーム コンテンツにどのような変更を加えても、パッケージを正しく更新できます。ただし、ダウンロード サイズの効率 (プレイヤーがゲームをプレイできない時間に対応) やハード ドライブ空間の消費の効率が良くない可能性があります。以下のヒントは、最良のユーザー エクスペリエンスを保証するようにゲームをパッケージ化するのに役立ちます。
**シンプル:**
* pack ファイルを使用して複数のアセットを 1 つのファイルに集約する場合、pack ファイル作成者が各アセットの開始を 4-KiB 境界にアライメントしていることを確認してください。このヒントは [シンプルなアライメントの例](#AS) で示されています。
* アセットを圧縮する場合、圧縮が決定論的であり、各アセットが独立して圧縮されていることを確認してください。
* チャンク ID を変更したり、ファイルをチャンク ID 間で移動したりしないでください。
* パッケージ内のチャンク、チャンク内のファイル、またはファイル内のアセットを並べ替えないでください。アセットを名前やその他の安定した識別子で並べることを検討してください。
**高度:**
* pack ファイルを使用して複数のアセットを 1 つのファイルに集約する場合、pack ファイル作成者が各アセットの開始を一貫してアライメントしていることを確認してください。このガイダンスは、常に 4 KiB の開始にアライメントする高度なバージョンです。
例として、以前のパッケージでオフセット `PriorAssetOffset` から始まり、更新でビルドされているパッケージで `AssetOffset` から始まるアセットを考えます。pack ファイル作成者が各アセットの開始を 4-KiB 境界にアライメントしていることを確認するには、`PriorAssetOffset % 4096 == 0` と `AssetOffset % 4096 == 0` を設定します。この条件は常に `PriorAssetOffset % 4096 == AssetOffset % 4096` を満たします。この文が満たされることを確認する他の任意の方法も機能します。この条件により、pack ファイル作成者が使用するパディングを減らすことができます。
このヒントは [ステートフルなアライメントの例](#AAS) で示されています。
* 非決定論的な圧縮を使用しており、圧縮されていないアセットが変更されていない場合、圧縮データも変更されないように、以前のパッケージング時の圧縮データをコピーしてください。
* アセットが予想される実行時ロード順序に一致するように自動的に順序付けられている場合、最初のリリースで自動順序付けを固定することを検討してください。
* pack ファイルに更新で頻繁に変更される多くの小さなアセットがある場合、それらを隣接させることを検討してください。400 KiB を 1 回変更する方が、4 KiB を 100 回変更するよりも効率的です。
## pack ファイル内の良いアライメントと悪いアライメントの例
一部のゲームは、多数のアセットを *pack ファイル* と呼ばれる大きなファイルに結合します。サブファイル コンテンツ更新は、そのようなゲームへの更新のダウンロード サイズとハード ドライブ サイズの効率を大幅に向上させます。この技術を活用するには、ゲームの pack ファイル作成ツールがファイル内のアセットの 4-KiB アライメントを保持することが重要です。このセクションでは、pack ファイル内でアセットをアライメントする良い方法と悪い方法の例を示します。
説明のため、各例は文字が入ったセルの連続として示されます。図を単純化するため、各セルは 1 KiB です。セル間の実線は 4-KiB 境界がある場所を表します。
### データ上書き
以下の図では、更新で 1 つのセルが上書きされます。ダウンロードされるのは、このセルを含む 4-KiB ページのみです。
### 挿入
以下の図では、更新で 1 つのセルが挿入されます。その結果、挿入後のすべてのセルが 1 つずれます。このずれにより、挿入後の 4-KiB ページのどれも新旧パッケージ間で同じでなくなるように、セルが 4-KiB 境界を越えて移動します。挿入後のすべての 4-KiB ページがダウンロードされます。
以下の図では、更新で 1 つのセルが挿入されます。加えて、3 つのパディング セルが挿入されます。この 4 つのセルは事実上 4-KiB の挿入となり、以降のセルが 4-KiB 境界を越えてずれるのを防ぎます。挿入とパディングを含む 8 KiB のみがダウンロードされます。
### 削除
以下の図では、更新で 1 つのセルが削除されます。その結果、削除後のすべてのセルが 1 つずれます。このずれにより、セルが 4-KiB 境界を越えて移動します。削除後のすべての 4-KiB ページがダウンロードされます。
以下の図では、更新で 8 つのセルが削除されます。ダウンロードされるのは 4 KiB のみです。削除の開始と終了の 4-KiB ページ内にあったセルです。
削除が 4 KiB でアライメントされ、その長さが 4 KiB の倍数であれば、データのダウンロードは不要です。
### アライメント: シンプル
以下の図は 6 つのアセットを示しています。各アセットは任意の数のセルに格納されます。すべてのアセットの開始は 4-KiB 境界にあります。その結果、アセットを独立して追加、変更 (サイズの増減を含む)、または削除できます。
このアライメントは、pack ファイル内でアセットをアライメントする最も簡単な方法です。
### アライメント: 高度なステートレス
以下の図は 7 つのアセットを示しています。各アセットは任意の数のセルに格納されます。すべての大きなアセットの開始は 4-KiB 境界にアライメントされますが、小さなアセット (図の Asset 6) は前のアセットにパディングなしで連続してパックされます。このアライメント方法は次の 3 つの利点を提供します。
1. パディングに使用する空間が少なくなります。
2. Asset 5 を変更した場合、Asset 6 のダウンロードは実質的に無料です。
3. Asset 6 を変更した場合、いずれにせよ完全な 4 KiB がダウンロードされます。それがパディングか Asset 5 の終わりであるかは関係ありません。
必要となるパディングにアセットが収まる場合は、パディングなしでパックしてください。
### アライメント: 高度なステートフル
以下の図は 7 つのアセットを示しています。各アセットは任意の数のセルに格納されます。最初のパッケージでは、すべてのアセットの開始がパディングなしでパックされます。新しいパッケージでは、すべてのアセットの開始が、以前のパッケージと同じ 4-KiB ページ内の同じオフセットから始まります。
たとえば、Asset 3 は以前のパッケージでは 4-KiB ページの 1 セル目から始まっていました。新しいパッケージでは、Asset 3 の前にパディングが追加され、4-KiB ページの 1 セル目からも始まるようになりました。
このアプローチは、コンテンツ更新が必要とするアライメントを保持しつつ、パディングの量を最小限に抑えます。このアプローチの欠点は、pack ファイル ツールが以前の pack ファイルのレイアウトを把握してオフセットを一致させる必要があることです。
## 断片化
更新の履歴が長く、時間の経過とともに既存のファイルに多くの変更が加えられているタイトルや、大きなファイルに対して小さな編集が多いパッケージの場合、コンテンツ更新アルゴリズムは最適でない更新サイズを生成することがあります。最適でない更新サイズは 2 つの方法で判定できます。
1.\t`/priorpackage` を指定して実行した `makepkg pack` の出力を確認します。「More than # page-level XTS entries. Page-level update efficiency will be compromised for # pages.」という警告が表示されます。
1.\t`makepkg pack` または `packageutil compare` によって生成された比較レポートを確認します。変更されていないことがわかっているファイルが 100% 再ダウンロードされていることをレポートが示している場合、XVC ファイル形式の暗号化フラグメント データ構造の空き容量が不足している症状である可能性があります。
Microsoft アカウント担当者からの指導のもと、より最適な差分計算を生成するために `makepkg pack` の `/maxencryptionfragments` オプションの使用を検討してください。この値を高く設定しすぎると、ゲームの起動時や DLC のマウント時にメモリ不足エラーが発生するリスクが高まります。
データを挿入するとき、コンテンツ更新は物理ハード ドライブ上のパッケージのデータの断片化を引き起こします。コンテンツ更新は、更新中にパッケージの部分的な最適化を行うことでこの影響を最小限に抑えようとします。ハード ドライブの空き容量に応じて、隣接する任意の 2 つのフラグメントのサイズの合計が少なくとも 100 メビバイト (MiB) であることを保証します。コンテンツ更新は、すべてのフラグメントを少なくとも 100 MiB にしようと試みます。
XBOX One ERA 向けの以前のコンテンツ更新の反復では、断片化解消を行いませんでした。
## ツールの使用方法
* **`makepkg /contentid GUID`:** コンテンツ ID パラメーターは、パッケージ ファミリ名と併せて、バージョン間でパッケージを識別します。パッケージ間の更新をテストするには、同じコンテンツ ID とパッケージ ファミリ名を使用して両方のパッケージを作成します。
* **`packageutil compare`:** このツールは、古いパッケージから新しいパッケージに更新する方法を記述した更新プランを生成します。また、更新を行うためにダウンロードされるファイルとそれらのファイル内の範囲をリストしたレポートも生成します。予期しない変更を特定するには、このレポートを使用します。
* **`xbapp update` (PC: `wdapp update`):** このツールは、以前に開発キットまたは PC にインストールされたパッケージを新しいパッケージに更新します。小売コンソールと同じ方法を使用するため、これを使用してユーザー エクスペリエンスと更新後の IO パフォーマンスをテストできます。
## 詳細
このセクションでは、コンテンツ更新の仕組みに関する実装の詳細について説明します。これらの詳細は変更される可能性があります。すべてを理解し、微調整したい非常に興味のある開発者向けの内容です。
**更新ストリーミング プランとは何か?**
更新ストリーミング プランは XBOX FastStart 技術の進化形です。コンテンツ更新 v3 は、これらのプランを使用して、古いパッケージを新しいパッケージに変換する方法を XBOX コンソールと PC に指示します。このアプローチにより、コンソールや PC がダウンロード中に行える処理よりも、公開時にクラウドでより集中的な分析を行うことができます。
**挿入または削除の許可倍数として 4 KiB が選ばれた理由は?**
4 KiB は、XBOX とサポートされる PC ファイル システム上の NTFS クラスター サイズです。NTFS クラスター サイズとは異なる倍数で挿入または削除を行うと、更新のインストールに多大なディスク IO が必要となります。
コンテンツ パッケージは、4-KiB ブロックで暗号化および整合性保護されます。暗号化ブロック サイズと異なる倍数で挿入または削除を行うと、更新のインストールにデータの再暗号化が必要となります。この要件により、適切なユーザーがサインインしていないためライセンスが利用できない、またはゲーム ディスクが利用できないシナリオでのバックグラウンド更新が妨げられます。
この要件により、更新プロセスの終わりに時間のかかる展開手順を必要とせず、パッケージを効率的に更新できます。
**makepkg/packageutil の実行時と公開時にはそれぞれ何が起こるのか?**
両方で同じ処理が行われます。公開時、パッケージは、クラウドの最適な選択肢である以前のパッケージからのデータ (makepkg /priorpackage に相当) を使用して暗号化されます。次に、多数の古いパッケージからの更新ストリーミング プランが生成されます (packageutil compare に相当)。
**makepkg で指定した /priorpackage は小売パッケージに影響するのか?**
いいえ。クラウド内の公開プロセスは常にこの指定をオーバーライドします。`makepkg` オプションは、公開前のローカル見積もりを有効にするためにのみ提供されています。
**更新されたゲーム データのみがダウンロードされるのか?**
いいえ。パッケージには、すべてのデータ ページの暗号ハッシュ、Game OS (コンソールのみ)、および組み込み NTFS ファイル システムを含む、多くのシステム データが含まれます。これらは必要に応じてダウンロードされます。
加えて、HTTP リクエストのオーバーヘッドを最小限に抑えるために、変更されていないデータの一部が再ダウンロードされることがあります。現時点では、変更されたデータで囲まれた 64 KiB 未満の変更されていないデータは再ダウンロード対象となりますが、この構成は *ダウンロード時間* を最適化するために変更される可能性があります。
packageutil compare によって生成されるレポートには、以前の情報がその見積もりに含まれています。
### 関連項目
[コンテンツ更新の作成、検査、およびテスト](/build/core-features/common/packaging/packaging-testing-updates)
[更新の確認](https://learn.microsoft.com/build/store/commerce/fundamentals/xstore-checking-for-updates)
## Related topics
- [コンテンツ更新の作成、検査、およびテスト](/ja-jp/build/core-features/common/packaging/packaging-testing-updates.md)
- [MSIXVC2 によるコンテンツ更新](/ja-jp/build/core-features/common/packaging/packaging-updates-msixvc2.md)
- [更新プログラムの確認](/ja-jp/publishing/xstore-commerce/xstore-checking-updates.md)
- [タイトル パッケージング、更新、およびストリーミング インストールのテスト](/ja-jp/build/core-features/common/packaging/title-packaging-streaming-install-testing.md)
- [ストリーミング インストールと Intelligent Delivery: 概要](/ja-jp/build/core-features/common/packaging/overviews/streaming_install-intelligent_delivery.md)