Steamのビルドに関する専門用語と全体の構成について
本記事は私がSteamでゲームの体験版をビルドした際に理解した、Steamのビルドにおける各専門用語と全体的な構成について解説するものです。
ちなみに筆者がSteamに登録を申請したゲームは以下のものです。興味があれば覗いてみてください。
Steamにおける「ビルド」の意味について
Steamにおける「ビルド」というのは広義の意味と狭義の意味の2つが存在していると私は認識しています。
「広義的なビルド」という言葉の意味は、「Steamでゲームを遊べる状態」にするための一連の作業全般のことを指しており、「ゲームビルド」や「体験版ビルド」といった言葉で呼ばれることもあります。
「狭義的なビルド」という言葉の意味は、以下でも解説する「Steamworksのバージョン管理機能（ビルドIDによる管理）」のことを指しており、単に「ビルド」と呼んだ場合は基本的にこちらのことだと思われます。
なので、本来的には分けて使うべき言葉だとは思うのですが、大半の人は両方ともに「ビルド」と呼んでいるっぽい気もするので、そこまで気にする必要は無いかもしれません。
ビルドに関する専門用語
Steamのビルドに関連する一連の作業で登場する専門用語として、具体的なものをあげると以下のようなものがあります。
・アプリ（App）
・デポ（Depot）
・ビルド（Build）
・ブランチ（Branch）
・パッケージ（Package）
・バンドル（Bundle）
これらがどういったものなのかについて、簡単に解説していきたいと思います。
ちなみに今回説明する専門用語については、Steamworksの公式ドキュメントにも記載がありますので、時間があれば見ておいて貰うほうが良いかと思います。
アプリ（App）とは
アプリについては説明が要らないかもしれませんが、念の為に説明しておきます。
Steamにおける「アプリ」とは、正式名称を「アプリケーション」と良い、これは貴方が開発しているゲーム（もしくはアプリ）本体のことを指しています。
アプリは「App ID」と呼ばれる固有のIDで管理されており、このApp IDはストアページのURLやSteamworks内のアプリ関連ページで頻繁に表示されています。
ここまでは大丈夫だと思いますが、少し複雑になってくるのが、体験版やDLC等の本体のアプリに付属するモノの扱いです。
昔は体験版やDLCは本体アプリの中のデポとして管理していたみたいですが、現在では体験版もDLCも本体のアプリとは別のApp IDを付与して、別アプリとして管理するのが基本となっています。
この製品版と体験版とは別アプリ（App IDも別）であるという概念を先に理解しておかないと、ビルド関連の作業が良く理解出来なくなってしまうため、先に解説しました。
尚、体験版は別アプリではありますが、製品版に対する関連アプリ（子アプリ）という扱いであり、製品版のストアページから体験版アプリをダウンロードする機能等もデフォルトで提供されているため、ユーザーから見ると同じアプリのように感じられるようになっています。
デポ（Depot）とは
恐らくゲームビルドをしている時に一番何なのかが良く分からなくなるのが、「デポ（Depot）」という概念です（私も途中まで良く分かりませんでした）。
「Depot」という英語を直訳すると「格納庫」や「倉庫」といった意味となり、これは良くPCやゲームなどで登場する「ストレージ（Storage）」に近い言葉です。
デポのSteam内における役割もストレージに近く、ゲームの実体（exeファイルなど）を格納しておく入れ物と思ってもらうのが一番理解しやすいかなと思います。
デポもアプリと同じように「Depot ID」という固有のID管理で管理されており、ストアページなどでは見れませんが、Steam DBなどには公開されている情報となっています。
ちなみに、ユーザーがアプリ（ゲーム）を購入するときも、実際にユーザーのローカル環境に配信されるのはデポの内容となっています。
デポは複数作成することができ、Windows用とMac用などでデポの中身を変えて登録しておくことで、ユーザーのOSに合わせて対象のデポの中身をダウンロードさせるといった使い方も可能となっています。
ビルド（Build）とは
ゲームビルドにおける理解し難い概念の２つ目はこの「ビルド」と思われますが、この「ビルド」という言葉はSteamではバージョン管理のための概念となっています。
エンジニア出身の人は「ビルド」と聞くと、Java等の高級言語で書かれたプログラムをPC等で実行できる形式にコンパイルする作業などをイメージしたり、アプリとしてデプロイするまでの一連の流れと誤解してしまうかもしれません。
しかし、Steamではゲームファイルをアップロードした時に、そのファイルの内容がデポとして登録され、その時のデポの中身を一つのビルド（バージョン）として管理している形となっています。
以下のビルド履歴を見ると分かりやすいですが、この一回一回のゲーム用のファイルをアップロードした結果がそれぞれ一つのビルドとして管理されています。
ビルドも「ビルドID」という固有のIDで管理されていますが、このビルドIDは基本的にバージョン情報でしかないため、ビルドIDに紐づくデポの中身が重要となっています。
実際にアプリを購入したユーザーに配信されるデポの中身（ファイル）は、その時に設定されているビルドIDのバージョンのデポの内容が配信されるという形となっています。
ブランチ（Branch）とは
GitやSVN等でバージョン管理をした経験がある人もいるかも知れませんが、Steamにおけるブランチの概念も比較的近い意味となっています。
「ブランチ（Branch）」という言葉を直訳すると、「木の枝」という意味となるのですが、これは文字通り「木の枝」のようにビルドを分岐させられるから名付けられているのだと思います（Git等もそうですので）。
先程のビルドの画像を見てもらうと、一番左側に「カレント」という列と「default」という文章が表示されていると思います。この「default」というのがブランチ名であり、一番上のビルドIDに設定されていることがこの一覧から分かります。
ブランチがSteamでどういう役割を持つかという話ですが、簡単に言うと開発者側で指定したビルドIDのバージョンでSteamに公開する内容を制御するための機能となります。
今回の画像のケースで言うと、「default」ブランチが一番最新のビルドIDに設定されています。そのため、ユーザーがアプリをダウンロードすると、最新のビルドIDに紐づくデポの内容が配信されます。
しかし、「default」ブランチを開発者が一つ前のビルドIDに設定すると、ユーザーがダウンロードするアプリは一つ前のビルドIDに紐づくデポの内容となります。
個人で開発している場合は、常に最新のビルドIDに紐づく内容でユーザーに配信したいというケースがほとんどなので、ブランチについてはビルドするたびに最新のものに紐づける作業くらいに考えている人が多いと思います。
ですが、複数人で開発している場合はユーザーに配信したい最新バージョンだけでなく、内部の開発用に「beta」ブランチを設定して管理したり、初回リリースや前回リリース等の特定のバージョンを残しておくために「legacy」などのブランチを設定しておくといった事も出来ます。
他にも修正した結果、致命的なバグが出てしまい修正に時間が少し掛かりそうという場合は、ブランチを以前リリースしたビルドIDに切り替えることで、一時的にバグを回避するみたいな使い方も可能です。
このようにブランチによるビルドの切り替え機能は非常に便利であり、もしもブランチ機能が無いと常に最新のビルドをユーザーに提供するしかないといった状況となる可能性があるので、機能的には必要で間違いないでしょう。
パッケージ（Package）とは
「パッケージ（Package）」はゲームビルドに直接関連する言葉ではありませんが、アプリに深く関連する用語のため説明しておきます。
とは言っても、パッケージという言葉はSteamにおける商品を意味するものとなっており、アプリを販売する時にはこのパッケージに含めるという形で公開することになります。
イメージし難いかもしれませんが、Steamにおいてユーザーがアプリを購入したり、体験版をダウンロードしたりする行為は厳密にはパッケージを購入し、パッケージ内に含まれるアプリに対して実行権（ダウンロードやゲームプレイ機能へのアクセス権）の付与という仕様で実現されているようです。
つまり、Steamで「アプリを買う」という行為は「パッケージを買う」という意味であり、仮に体験版であったとしても、体験版が含まれたパッケージを無料で買うという操作をしていることになります。
ユーザーからすればあまり意識する必要のない概念ですが、開発者はパッケージの概念を理解しておかないと、実際の販売時に困ることがあるかもしれません。
バンドル（Bundle）とは
「バンドル（Bundle）」もゲームビルドには直接関係ありませんが、合わせて説明しておきます。
Steamのストアページを見たことがある人なら、バンドルという形で複数の商品が一つにまとめられたパックとして、紹介されているのも見かけたことがあると思います。
これは見た時の印象そのままの意味で、バンドルというのは複数のパッケージを合わせて販売するというSteamでの販売機能ですね。
バンドルは開発者側で設定することが出来るため、一応意識しておく必要はあるのですが、意識し始めるのは2作目以降をSteamで販売した後になるでしょうね・・・。
パッケージとバンドルはどちらかというと製品版のリリースの時に意識すべき概念なので、後でそちらの記事が出来たらこの説明はそちらに移動させるかもしれません。
Steamアプリの全体イメージ
地味に長くなってしまいましたが、それぞれの専門用語について簡単にまとめると以下のようなイメージで覚えて貰えば良いかと思います。
アプリ：ゲーム本体のことで親アプリと関連アプリ（子アプリ）の概念がある
デポ：アップロードされた実ファイルの格納場所
ビルド：デポのバージョン管理を行うための機能
ブランチ：ビルドを用途ごとに切り替える機能
パッケージ：一つ以上のアプリを含めたSteamの商品
バンドル：複数のパッケージを含めたSteamの販売パック
言葉だけだと分かりづらいと思うので、私が雑なポンチ絵を作ってみました。多分こんな感じだと思いますが、間違っていたら誰か教えて下さい。
簡単に図の流れを解説すると以下のようになります。
①開発者がアプリAとアプリBを作成
②開発者がアプリA用にビルドA（デポAと紐づく）とビルドBを作成（デポA'と紐づく）
③開発者がアプリAのdefaultブランチとしてビルドAを設定
④開発者がアプリB用にビルドC（デポBと紐づく）を作成し、defaultブランチも設定
⑤開発者がパッケージ①としてアプリA、パッケージ②としてアプリBを販売
⑥開発者がバンドルとしてパッケージ①とパッケージ②を設定
⑦ユーザーがパッケージ①だけ購入
⑧ユーザーがパッケージ①をダウンロードすると、アプリAのdefaultブランチに設定されているビルドAに紐づくデポAがダウンロードされる（ビルドBとデポA'はdefaultブランチに設定されていないのでユーザーは意識しないものとなる）
なんか逆に分かりづらくなった気がするな。。。
ちなみにデポだけ、「デポA」と「デポA'」にしている理由は、デポID自体は同じで中身だけ違うためです。他のアプリやビルドはIDが変わるため、BやCとしています。
尚、デポは厳密には同一のファイル置き場でビルドIDに紐づくマニフェストファイル（Manifest）によって、どの資材を使うのか制御しているみたいなので、「デポA」と「デポA'」のように物理的に別れているわけでは無いっぽいのですが、開発者が意識すべき部分じゃないので図は理解しやすいように分けています。
とりあえず私のビルドに関する認識はこんな感じの流れなので、いやそうじゃないよという意見があれば、修正するので教えて下さい。
まとめ
今回はSteamのビルドに関する専門用語と全体的な構成イメージについて解説しました。
恐らくSteamでゲームを販売している人は今回解説したような概念を何となく理解は出来ていると思いますが、体系立てて理解している人は少数な気がします（ネットの記事などを見てもそう感じる）。
そのため、せっかくなのでそれぞれの言葉の意味やSteamにおけるビルドの概念を私の理解できた範疇で解説したのですが、逆に分かりづらくなったという人も多いかもしれません。。。
単純な話をすれば、ゲームファイルのアップロード方法とブランチの切り替え、公開のタイミングさえ理解しておけば、Steamでのゲーム販売はそこまで問題ないでしょう。
ただ、こういった概念レベルで物事を把握しておくと、記事に無い状況に遭遇したときの対応力が全く違ったものになると思います。
まぁ、そんな状況が来るかどうかは知りませんが、知っておいて損は無いかと思いますので、この記事を見て少しでもビルドへの理解が深まったのであれば幸いです。
それでは、本記事はこれで終わりにしたいと思います。Steam関連の他の記事を確認したい場合は以下の大本の記事からご確認いただければと思います。
