マスターアップとは｜AIゲーム開発で完成品を確定して提出する最終工程

2026年10月4日

「マスターアップ」は、ゲームを製品版として確定し、量産や配信に回せる状態にすることを指す言葉です。βROM で不具合を潰し、リリース候補（そのまま製品になれる版）を確かめ、「これで出す」と決めた時点がマスターアップです。開発の最後の節目で、この後はストアの審査や発売の準備に移ります。この連載では、βROM からマスターアップまでの発売前の仕上げを「ポストプロダクション（仕上げ）」と呼びます（資料によっては、発売後の運営を指すこともあります）。この工程が全体のどこにあるかは「ゲーム開発の全工程マップ」で確認できます。

本記事では、マスターアップの定義と英語の呼び方（リリース候補・ゴールドマスター）、マスターアップの条件、提出（コンソールの認証と Steam のビルドの審査）、版番号の付け方、ビルドと素材の保管、デイワンパッチ、パッケージ版とダウンロード版の違いまでを解説します。α・β・マスターの基準は、会社やパブリッシャーとの契約によって違います。この記事では代表的な考え方と、個人・少人数で使える基準の例を示します。例には「αROM（アルファ版）とは」「βROM（ベータ版）とは」と同じ、2Dアクション（全5ステージ）とノベルゲーム（全6章）を使います。Steam の規則は2026年10月時点の公式ドキュメントで確認したもので、変わることがあります。

夕宮たいだ

ふぁ……みんな〜、今日は「マスターアップ」の話だよぉ。「完成した！」って言える日なんだけど、その一歩手前が、けっこう長いんだぁ。

マスターアップとは

ひとことで：製品版として確定し、量産や配信に回せる状態にすることと、その時点を指す言葉です。

ゲーム開発の節目のうち、アルファ（α版）は主な機能がそろい、最初から最後まで通して遊べる段階、ベータ（β版）は機能と素材がそろい、不具合の修正と調整が中心になる段階、マスターアップ（ゴールド）は製品版として確定し、量産や配信に回せる段階を指すことが多い言葉です。ただし、基準は会社やパブリッシャーとの契約で違います。

日本語版 Wikipedia の「マスターアップ」の項目では、狭い意味ではゲームが完成した瞬間を、広い意味ではそこを目指す作業（素材の最終的な組み込み・テストプレイ・デバッグ）を指す、と説明されています（出典は雑誌『PUSH!!』2010年4月号）。実際の使われ方の例として、Pearl Abyss は2026年1月、『紅の砂漠』の製品版のパッケージのマスター制作が完了したことを、「通称：ゴーン・ゴールド/マスターアップ」と添えて発表しました（PR TIMES 配信の発表文、アニメ！アニメ！掲載）。

英語では、量産のマスターに使う最終ビルドを「ゴールドマスター」と呼び、そこに達することを「ゴールドになる（going gold）」と言います。ソフトウェア一般では、量産へ回すことを RTM（release to manufacturing）とも呼びます。日本の現場での呼び方との対応は、おおむね次のとおりです。意味は代表的な定義の例で、会社ごとの基準とは一致しないことがあります。

英語	日本の現場での呼び方	代表的な意味	出典の例
Alpha	α版／αROM	主な機能がそろい、最初から最後まで通して遊べる。素材は仮が残る	Chandler・Bethke の教科書（英語版 Wikipedia の引用）、デジタルハリウッドの解説
Beta	β版／βROM	機能と素材がそろい、不具合の修正と調整が中心になる	同上
Release Candidate（RC）	決まった和名はない（この連載では「リリース候補」）	重大な不具合が出なければ、そのまま製品になれる版	英語版 Wikipedia「Software release life cycle」
Gold master	マスターアップ／マスター	製品版として確定し、量産や配信に回せる	Bethke の教科書（英語版 Wikipedia の引用）、デジタルハリウッドの解説

出典：Wikipedia「Video game development」、Wikipedia「Software release life cycle」、デジタルハリウッド「ゲーム制作の流れ」。α版・β版の段階で提出・確認用に作るビルドを、日本の現場では「αROM」「βROM」と呼ぶことがあります（ROM という呼び方は、カートリッジの時代の名残といわれます）。

リリース候補（RC）からマスターへ

マスターは、いきなり作るものではありません。β の終わりに「このまま製品になれる」と考えたビルドを、リリース候補（RC）として作ります。英語版 Wikipedia は、リリース候補を「重大な不具合が出なければ、そのまま製品になれるベータ版」と説明しています。リリース候補を決めた手順で確かめ、重大な不具合が出たら直して次の候補（候補2、候補3…）を作り、何も出なければ、その候補がマスターになります。英語の教科書（Chandler）の2年の開発の例では、最初のリリース候補は、コードリリース（出荷やコンソールメーカーの審査に出せる版）の3〜4週間前にそろうことが多い、とされています。

例の2Dアクションなら、候補1の通しの確認で「4面のボス戦の途中でポーズして再開すると、操作を受け付けなくなる」（進行不能）ことが見つかり、直して候補2を作り、候補2で重大な不具合が出なかったので候補2をマスターとする、という流れです。ノベルゲームなら、候補1で「英語に切り替えると、5章の選択肢で強制終了する」ことが見つかれば、直して候補2へ進みます。

リリース候補からマスターアップ、提出までの流れ。重大な不具合があれば直して次の候補で確かめ直し、なければマスターを確定して提出し、Steam の審査かコンソールの認証を経て発売する — 図1：重大な不具合が出なくなったリリース候補が、マスターになる

マスターアップの条件

ひとことで：重大な不具合がゼロ、提出物がそろう、プラットフォームの要件を満たす、の3つがそろったビルドをマスターとします。

マスターの条件も会社や契約で違いますが、この連載では次の3つで置きます。

重大な不具合がゼロ

「重大」の線は、先に決めておきます。公開されている例として、マイクロソフトの Xbox の要件（XR-003）は、提出するゲームに、強制終了・フリーズ・遊べないほど低いフレームレート・進行を大きく妨げる不具合・表示の崩れがないことを求めています。また、内容を更新した後もセーブデータと進行が使えることも求めています（Microsoft Learn「XBOX Requirements for XBOX Games」、Version 16.4）。個人で Steam に出す場合も、この一覧は「重大」の線を決める参考になります。

重大でない既知の不具合は、ゼロでなくてもかまいません。残して出すかを判断し、既知の不具合として記録します（判断のしかたは「βROM（ベータ版）とは」で解説しています）。

提出物がそろう

マスターとして渡すのは、ビルドだけではありません。

提出先	主な提出物の例
Steam（自主販売）	審査に出すビルド、承認されたストアページ、内容の申告（Content Survey）、実績やクラウド保存などの設定
コンソール	認証に出すパッケージと、プラットフォームが求める書類
パブリッシャー	契約で決めたマスターのビルドと付属物（クレジット、説明の資料など）

どの場合も、ストアやパッケージに書いた内容と、ビルドの中身が一致していることが前提です。Steam のビルドの審査でも、ストアに書いた機能が入っているかが確かめられます。

プラットフォームの要件を満たす

コンソールでは、発売前にプラットフォーム側の認証を通します（任天堂＝ロットチェック、ソニー＝TRC、マイクロソフト＝XR に基づく認証）。任天堂とソニーの細かい要件は、開発者向けの非公開資料にあります。任天堂は採用サイトで、ロットチェックを、任天堂のゲーム機で販売するゲームが全モデル・全バージョンで正常に動作すること、ガイドラインに適合していることを確かめる検査工程と説明しています（任天堂採用サイト）。

マイクロソフトの XR は公開されているので、どんなことが確かめられるかの具体例として読めます（Version 16.4、2026年9月8日）。認証で試験される XR には印（*）が付いています。

XR	内容（要約）
XR-001 タイトルの安定性	すぐに起動し、動き続け、入力に反応し、正常に終了する。予期せず閉じない
XR-003 提出時の品質	提出時に機能が完成していて、テストできる。重大な不具合がない。更新後もセーブが使える
XR-055 実績とゲーマースコア	発売時に実績を10〜100個、ゲーマースコアの合計を1000にする
XR-115 遊んでいる最中のコントローラーの抜き差し	操作中のコントローラーが外れたら、つなぎ直して続けられるようにする

Steam は「認証」ではなく「審査」です。ストアページとビルドの両方を審査に出し、両方の承認が発売の条件になります。2026年10月時点の公式ドキュメント（Review Process）では、審査は通常3〜5営業日で、公式は7営業日前の申請を勧めています。ビルドの審査では、ストアに載せたすべての OS で起動するか、ストアに書いた機能が入っているか、ゲーム内課金が Steam ウォレットを使うかが確かめられます。ビルドの審査は、ストアページを審査に出した後でないと申請できません。

承認された後も、ビルドは再審査なしで差し替えられます。便利な一方で、マスターを決めた後に変更が入るのを止める仕組みが、Steam 側には無いということでもあります（後述の「ついでの修正」）。

夕宮たいだ

ほよ？ Steamって、承認されたあとも差し替えられるんだぁ。……止めてくれる人は、自分しかいないってことだねぇ。

提出までの進め方

ひとことで：最後の変更を締め切り、リリース候補を決めた手順で確かめ、通ったビルドをマスターとして固定してから提出します。

① 変更を締め切る：コードフリーズに入り、承認した不具合の修正だけを入れる
② リリース候補を作る：版番号を付け、毎回同じ手順（スクリプト）で書き出す。手で作ると、作るたびに中身が変わるおそれがある
③ 決めた手順で確かめる：自動テストの全部、全編の通しプレイ、配布物の中身の照合、開発の道具が入っていない PC へのインストールと起動、Steam のクライアントからの起動（Steam の機能が動くか）
④ マスターを決める：重大な不具合があれば直して次の候補へ進む。なければ、決める人が「この候補をマスターとする」と記録する
⑤ 提出する：Steam ならアップロードし、管理画面で公開するブランチに設定（Set Live）してから、ビルドの審査を申請する
⑥ 保管する：出したビルドを後から再現できる一式を残す（後述）

Steam へのアップロードは、Steamworks SDK に入っている steamcmd に、ビルドの設定ファイル（アプリ全体用と、配布物の中身＝デポ用の .vdf）を渡して行います。アップロードしたビルドには、Steam 側で BuildID という番号が付きます。設定ファイルの Desc（説明）欄は、管理画面の「Your Builds」で自分たちだけに見える説明で、アップロードの後でも変えられます。ここに版番号と日付を書いておくと、BuildID と版の対応が後から分かります。一般の購入者に届く default ブランチへの設定は自動ではできず、必ず管理画面で手作業で行います（Uploading to Steam）。審査に出す前に、パスワード付きのベータブランチに置き、キーで作品を有効にした別のアカウントで試す方法もあります。

開発中は、Steam の外からゲームを起動するために、実行ファイルの隣に AppID だけを書いた steam_appid.txt を置きます。Steamworks のドキュメントは、このファイルは Steam が渡す値を上書きするもので、配布するビルドに含めず、デポにアップロードするときは取り除くよう案内しています（Steamworks API の概要）。デポ用の設定ファイルの FileExclusion（除外の指定）に入れておくと、消し忘れを防げます。

配布物を、入れてよいファイルの一覧で選び、ハッシュで照合する流れ。実行ファイルとライブラリ2つだけを残し、撮影した画像・steam_appid.txt・ログ・テスト用の設定は除く — 図2：入れてよい物だけを複製し、ハッシュで照合する

ストアページ側の作業は「Steamストアページの作り方」、承認の後に発売のボタンを押すまでは「ゲームの発売（リリース）手順」で解説しています。

版番号の付け方

ひとことで：出したビルドを1つに特定できるよう、決まりに沿って版番号を付け、ゲームの画面とビルドの記録の両方に残します。

ゲームの版番号に、業界で決まった形はありません。よく借りられるのが、ソフトウェアの「セマンティックバージョニング 2.0.0」の形です。版を「メジャー.マイナー.パッチ」の3つの数で表し、互換性のない変更でメジャーを、互換性を保った機能の追加でマイナーを、互換性を保ったバグ修正でパッチを上げます（semver.org）。ゲームに当てはめると、例えば次のような使い方になります。

版	使い方の例
0.5.0／0.8.0	発売前の節目（αROM＝0.5.0、βROM＝0.8.0）
1.0.0	発売する版（マスター）
1.0.1	不具合の修正だけの更新
1.1.0	内容や機能を足した更新
2.0.0	セーブや通信の互換が切れるほどの大きな更新

版番号とは別に、ビルドごとの通し番号を持つと便利です。Steam にアップロードすると BuildID が付くので、それを使えます。リリース候補は「1.0.0 の候補2」のように、発売する版の番号と候補の番号で呼び、確かめたビルドをそのままマスターにします。版の文字だけを変えるために書き出し直すと、確かめたビルドとは別物になってしまうからです。

セマンティックバージョニングには、一度出した版の中身は変えず、どんな修正も新しい版として出す、という決まりもあります。ゲームでも同じで、マスターの後の変更は、小さくても新しい版にします。

版番号を出す場所

版番号は、タイトル画面か設定画面、クラッシュ時のログ、実行ファイルのプロパティ、Steam の Desc 欄に出します。プレイヤーから不具合の報告を受けたとき、どの版の話かがすぐ分かるようにするためです。筆者の「つみこめ！イカサマ魔法麻雀」では、セーブデータの全ファイルにも版番号を持たせています。新しい版で保存の形が変わっても、どの版で保存したかが分かれば読み替えられます。

版番号を何か所にも書くと、上げ忘れが起きます。正本を1か所に決め、ほかの場所（実行ファイルのプロパティ、変更履歴）と一致しているかを、テストで確かめます。

通信対戦のあるゲームでは、版番号の意味がさらに重くなります。筆者の麻雀ゲームの通信対戦は、版番号が同じ相手とだけつながる作りです。そのため、通信に影響する修正をしたら、必ず版番号を上げると決めています。上げ忘れると、古い版の人と新しい版の人が同じ卓に入り、進行が食い違うからです。

夕宮たいだ

メジャー、マイナー、パッチ……むずかしいねぇ。でも「出した後に直したら、番号を上げる」。これだけは覚えておこうねぇ。

ビルドと素材の保管

ひとことで：どのビルドを出したかを後から再現できるよう、ソース・設定・道具の版・成果物・ハッシュを一式で残します。

マスターを出した後にも、そのビルドを作り直したい場面は来ます。発売直後の不具合を、出した版のソースから直すとき。移植するとき。問い合わせを受けて、その版で不具合を再現するとき。素材の権利について確かめるとき。そのときに「どのソースと設定から作ったビルドか」が分からないと、直したつもりで別の不具合を入れることになります。

残すもの	具体例	後で使う場面
ソースのその時点	バージョン管理のタグ（例：v1.0.0）	発売後の修正を、出した版から始める
ビルドの設定と道具の版	書き出しの設定、エンジンと書き出し用テンプレートの版、ビルドのスクリプト、外部ライブラリの版	同じビルドを作り直す
成果物とハッシュ	配布したファイル一式と、SHA256 の一覧	手元のファイルが、出した物と同じか確かめる
提出の記録	Steam の BuildID と Desc、提出日、審査の結果	どのビルドが出ているかを特定する
素材の元データと権利の控え	絵の元ファイル、音のプロジェクト、購入した素材やフォントのライセンス	修正・移植・権利の問い合わせ
確認の記録	全テストの件数と結果、通しプレイの記録、既知の不具合の一覧	発売後の不具合が、出した時点からあったかを判断する

ハッシュ（SHA256 など）は、ファイルの中身から計算する指紋のような値です。中身が1文字でも変わると値が変わり、2つのファイルのハッシュが同じなら、中身も同じです。Windows なら、PowerShell の Get-FileHash（既定は SHA256）で計算できます（Microsoft Learn「Get-FileHash」）。

一式は、作業用の PC とは別の場所にも置きます。バージョン管理の考え方は「ゲームエンジンの選び方と開発環境」、ファイルの版の付け方は「アセット命名・バージョン規則」も参考になります。

版番号の付け方の例（0.5.0 から 1.1.0 まで）と、マスターで保管する6つのもの（ソースのタグ・ビルドの設定と道具の版・成果物と SHA256 の一覧・BuildID と提出日・素材の元データとライセンス・テストの記録） — 図3：出したビルドを後から再現できるよう、一式で残す（版番号の付け方は一例）

デイワンパッチとパッケージ版・ダウンロード版

ひとことで：デイワンパッチは、マスターを早く固めるパッケージ版で、その後の修正を発売日に届けるための更新です。

デイワンパッチは、発売日に配信する更新です。パッケージ版は製造のために早めに完成版を固めるので、その後の修正を発売日に配ります。Vlambeer の Rami Ismail は2016年に、パッケージ版は発売の1.5〜3か月前に認証へ提出され、その後も開発は続き、発売日のパッチは約1週間前に提出できるので、その間に直した分を発売日に配る、と説明しています（MCV/DEVELOP、2016年8月）。

ダウンロード専売、特に Steam には、製造の待ち時間がありません。ビルドは承認後も差し替えられるので、発売日用の修正を別に用意する必要は小さくなります。それでも、マスターを決めた後に入れた修正は、すべて新しい版として扱い、同じ確認を通します。

	パッケージ版（コンソール）	ダウンロード版（Steam）
マスターの締め切り	製造と認証の分だけ早い	審査の日数（通常3〜5営業日、7営業日前の申請を推奨）から逆算する
発売時の修正	デイワンパッチで配る	承認後のビルドを差し替える（再審査なし）
国内の年齢区分	CERO が必要	Steam は CERO を求めない（内容の申告から区分が作られる）
製造と在庫	製造・流通の費用と在庫がある	ない

国内のコンソールでも、ダウンロード専用のソフトは、条件つきで IARC（ダウンロード配信向けの国際的な年齢区分の仕組み）の区分で出せる場合があります（18歳以上向けは CERO が必要）。年齢区分は「ゲーム開発の権利と規約」、コンソールへの移植は「ゲームの移植とマルチプラットフォーム」で解説しています。

AIゲーム開発でのマスターアップ

ひとことで：配布ビルドづくり・ハッシュでの照合・提出前のチェックは AI とスクリプトで機械にし、「これで出す」の判断とアップロード・公開の操作は人が行います。

機械にする作業と、人に残す操作

マスターアップは、AI エージェント（Claude Code や Codex のように、指示を受けてコードを書き、動かし、確かめるところまで進める AI）とスクリプトで機械にしやすい工程です。手順が決まっていて、毎回同じことを確かめるからです。

配布ビルドを作るスクリプト：全テスト → リリース用の書き出し → 書き出したビルドの起動確認 → 配布に入れるファイルだけを複製 → ハッシュの照合、を1本にまとめる。毎回同じ手順になり、作るたびに中身が変わる事故を防げる
ハッシュの一覧と照合：配布するファイルの SHA256 を一覧にし、アップロード用のフォルダの中身と一致するかを確かめる
提出前のチェック：版番号の一致、入れてよいファイルの一覧との照合、steam_appid.txt や開発用のファイルが無いこと、ストアで宣言した言語に未翻訳が無いこと
保管一式の目録：タグ・ハッシュ・BuildID・テストの件数を、1枚の表にまとめる
文章の下書き：パッチノート（更新内容の説明）、既知の不具合の告知

一方で、次の判断と操作は人に残します。

「これで出す」の判断：既知の不具合を残したまま出すか、もう1つ候補を作るか。AI は判断の材料（残りの不具合と重さの一覧）を整えられますが、決めるのは人です
アップロードと公開の操作：Steam へのアップロード、default ブランチへの設定、審査の申請、発売のボタン。取り消しにくい操作は人が行います。Steam のアカウントのパスワードや認証のコードを、AI に渡す必要もありません
最後に自分で遊ぶ：開発の道具が無い PC に、買った人と同じ手順でインストールして、最初の数十分を遊びます
表記の最終確認：クレジット、権利表記、ストアの説明と中身の一致、AI の開示

作業が機械になるほど、人に残るのは「数は少ないけれど重い判断」です。確かめる手順が機械になったからといって、手順を省いてよいわけではありません。

筆者の実例：3ファイルの照合と、踏んだ3つの罠

筆者の麻雀ゲームでは、Claude Code が配布用のビルドを作り、配布に必要な3つのファイル（ゲームの実行ファイルと、Steam との連携に使うライブラリ2つ）だけをアップロード用のフォルダに複製して、ハッシュ（SHA256）で照合します。アップロードは筆者が行います。steam_appid.txt は配布物に入れない、通信に影響する修正では必ず版番号を上げる、の2つは決まりにしています。

この流れで、実際に踏んだ罠が3つあります。

設定のパスが二重になった：アップロードの設定ファイルは、アプリ全体用とデポ用の2つに分かれています。同じフォルダの指定を両方に書いたところ、デポ側の指定がアプリ側の指定に重ねて解釈されてパスが二重になり、「コンテンツの置き場所が正しくない」という趣旨のエラーで止まりました。デポ側から消して解決しました
Steam 全体の障害で、31%で止まった：アップロードが31%で止まり、やり直しても続けて失敗しました。接続のログを見ると、自分の回線の確認は通る一方で、Steam の接続先のサーバーとの通信が各地で失敗していました。Steam 側の障害だったので、復旧を待って最初からやり直し、成功しました
PowerShell で、先頭の & が抜けて失敗した：PowerShell では、引用符で囲んだパスをそのまま書くと、実行されずに文字列として扱われます。実行ファイルを動かすには、先頭に呼び出し演算子の & を付けます（Microsoft Learn「about_Operators」）

障害のように、自分では直せない原因もあります。アップロードが止まったら、まずログで「自分の側か、Steam の側か」を切り分けると、無駄なやり直しや設定の書き換えをせずに済みます。

夕宮たいだ

ぁぅ……アップロードが止まると焦るけど、まずはログを見ようねぇ。自分のせいじゃないことも、あるんだぁ。

落とし穴：直前の「ついでの修正」

AI に頼めば修正はすぐ終わるので、マスターを決めた直後に「ついでにここも直しておこう」と頼みたくなります。Steam のビルドは承認後も再審査なしで差し替えられるので、止める仕組みはありません。しかし、確かめていない変更は、どれほど小さくても確かめていない変更です。

マスターの後の変更は、必ず版を上げ、テストを全部通すと決めておきます。筆者の麻雀ゲームでは、小さな変更は約30秒の簡易版のテストで確かめますが、提出するビルドは必ず全テスト（約3.2万件）を通します。AI が「軽い修正なので簡易版で十分です」と提案してきても、提出するビルドでは全部を通します。

ほかに、次の落とし穴もあります。

ハッシュの一致を「正しさ」と思い込む：ハッシュが保証するのは「同じファイルであること」だけです。中身が正しいかは、テストと通しプレイで確かめます
公開の操作まで自動化する：アップロードのスクリプトに、公開の設定まで含めないようにします。Steam は default ブランチへの設定を自動ではできない仕組みですが、ベータブランチへの設定は自動にできるので、どのブランチに置くかを確かめます
手順が古いまま：Steam の画面や規則は変わります。AI が覚えている手順をそのまま使わず、公式ドキュメントで日付を確かめます

夕宮たいだ

マスターのあとに「ついでに」直すの、絶対ダメだよ！直すなら、番号を上げて、テストを全部。ね？

依頼文の例：リリース候補をまとめて照合する

Goal: リリース候補「1.0.0 の候補2」を、提出できる形にまとめて照合する
Context: 書き出しは build/release/。配布に入れるのは docs/release_files.txt の3ファイルだけ。
  版番号の正本は game/version.gd。アップロード用のフォルダは build/steam_content/
Done when: 全テストが失敗0。3ファイルだけを複製し、SHA256 の一覧が書き出し元と一致した。
  steam_appid.txt と開発用のファイルが無いこと、版番号が正本と一致することを表で報告した
Constraints: アップロード・Steamworks の操作・版番号の変更はしない（人が行う）

依頼文の書き方の基本は「Claude Code プロンプト設計」「Codexプロンプト設計」で解説しています。

マスターアップでよくある失敗と対処

ひとことで：多くは「最後に変える」「最後に確かめない」「出した物を残さない」のどれかです。

失敗	起きること	対処
直前の「ついでの修正」	確かめていない変更が製品に入る	マスターの後の変更は版を上げ、テストを全部通す
開発用のファイルが混ざる	容量が増える。steam_appid.txt が残る	入れてよいファイルの一覧で照合し、除外の指定に入れる
版番号の上げ忘れ	不具合の報告で版が分からない。通信が食い違う	版の正本を1か所にし、ほかの場所との一致をテストする
出したビルドを再現できない	発売後の修正で、別の不具合を入れる	タグ・設定・ハッシュ・BuildID を一式で残す
審査の日数を見込まない	発売日に間に合わない	7営業日前の申請に加え、差し戻し1回分の余裕を見る
開発機でしか確かめない	ほかの PC で起動しない	開発の道具が無い PC に、買った人と同じ手順で入れて遊ぶ
default への設定を忘れる・間違える	審査や購入者に古いビルドが届く	Set Live の後に、Steam のクライアントから版番号を確かめる
止まったアップロードを設定のせいだと決めつける	時間を無駄にする	ログで、自分の側か Steam の側かを切り分ける