βROM（ベータ版）とは｜AIゲーム開発の仕上げ段階とβテストとの違い

2026年10月4日

「βROM（ベータ版）」は、ゲームの機能と素材がそろい、不具合の修正と調整が中心になる段階を指す言葉です。αROM で全体がつながり、本制作で素材を作り終えたあとに迎える節目で、ここから先は「足す」のではなく「直して磨く」仕事が中心になります。この連載では、βROM からマスターアップまでの発売前の仕上げを「ポストプロダクション（仕上げ）」と呼びます（資料によっては、発売後の運営を指すこともあります）。この工程が全体のどこにあるかは「ゲーム開発の全工程マップ」で確認できます。

本記事では、βROM の定義、オンラインゲームの「βテスト」との違い、到達条件の例、β の間にすること（不具合の修正・調整・最適化と動作環境の確認・ローカライズの実機確認・クレジットと権利表記の確認）、素材や文言の追加を止める「コンテンツロック」とコードの変更を絞る「コードフリーズ」、よくある失敗までを解説します。α・β・マスターの基準は、会社やパブリッシャーとの契約によって違います。この記事では代表的な考え方と、個人・少人数で使える基準の例を示します。例には「αROM（アルファ版）とは」と同じ、2Dアクション（全5ステージ）とノベルゲーム（全6章）を使います。Steam の規則は2026年10月時点の公式ドキュメントで確認したもので、変わることがあります。

夕宮たいだ

ふぁ……みんな〜、今日は「βROM」の話だよぉ。仮の絵がぜんぶ本物になって、あとは直して磨くだけ……のはずの段階なんだぁ。

βROM（ベータ版）とは

ひとことで：機能と素材がそろい、不具合の修正と調整が中心になる段階と、その時点で作る確認用のビルドです。

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

β版の段階で提出・確認用に作るビルド（ゲームを実行できる形にまとめたもの）を、日本の現場では「βROM」と呼ぶことがあります。ROM（読み出し専用のメモリ）という呼び方は、ゲームがカートリッジの ROM で売られていた頃の名残といわれます。ディスクやダウンロードで配る今でも、提出用のビルドを ROM と呼ぶ現場があります。

英語の呼び方との対応は、おおむね次のとおりです。意味は代表的な定義の例で、会社ごとの基準とは一致しないことがあります。

英語	日本の現場での呼び方	代表的な意味	出典の例
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」、デジタルハリウッド「ゲーム制作の流れ」。

資料によって中身に幅がある

同じ「ベータ」でも、資料によって中身には幅があります。

英語の教科書（Chandler『The Game Production Handbook』、Bethke『Game Development and Production』。英語版 Wikipedia の引用による）：機能と素材がそろい（feature and asset complete）、バグの修正だけを行う版。出荷を妨げるバグはなく、機能や素材の変更はしない
日本の解説（デジタルハリウッド「ゲーム制作の流れ」、2026年）：素材や機能がほぼ本番の状態にそろい、以降は不具合の修正と調整が中心になる段階
日本の解説（Autodesk AREA JAPAN「ゲーム開発のパイプライン」、2017年）：α版で決めた仕様に沿って量産した、すべてのデータが入った段階。その β版をテストプレイして面白さが伝わるかを確かめ、ユーザーテストと QA（デバッグ）を行う段階を「ポストプロダクション」と呼んでいる
Supergiant Games（『Transistor』の開発時のブログ、2014年）：アルファの後の「コンテンツロック」で仮素材がなくなり、調整・ボイスのタイミング・実行性能まで、あらゆる面を固めていく
GDC 2026 のプロデューサー向けワークショップ：アルファから発売までを「post-production and closing」（仕上げと締めくくり）として扱う

β の時点で「バグの修正だけ」とする資料もあれば、「調整も続ける」とする資料もあります。この連載では、β を「新しい機能と素材は足さず、不具合の修正と調整を進める段階」とし、数値の調整は β の前半まで続ける置き方をとります。

オンラインゲームの「βテスト」との違い

「β」という言葉は、オンラインゲームの「クローズドβテスト」「オープンβテスト（公開テスト）」でもよく目にします。こちらは開発の段階の名前ではなく、外部のプレイヤーに遊んでもらう試験の催しです。英語版 Wikipedia でも、ベータ版は公開の範囲によってオープンとクローズドに分かれ、期間限定の体験版や宣伝の手法として使われることもある、と説明されています。

	βROM	クローズドβテスト	オープンβテスト
何か	開発の段階と、その時点の確認用のビルド	募集や抽選で選んだ人に遊んでもらう試験	誰でも参加できる公開の試験
遊ぶ人	開発チーム・QA・パブリッシャー	限られた外部のプレイヤー	一般のプレイヤー
主な目的	不具合を潰し、製品として仕上げる	遊びへの反応、サーバーやマッチングの確認	負荷の確認、最後の調整、宣伝

テストの名前に「β」と付いていても、開発の段階が β だとは限りません。外部の人に遊んでもらうのは、目的の違う別の仕事と考えます。Steam で外部の人に遊んでもらう方法には、次のようなものがあります（2026年10月時点の公式ドキュメント）。

Steam Playtest：本編に関連付けた別の AppID で行う無料の機能。独自のストアページはなく、本編のストアページに参加の申し込み欄が出る。申込者からランダムに選ぶ「限定」と、申し込めばそのまま参加できる「オープン」がある。有料にしてはいけない。秘密保持の契約はないので、機密のテストには向かない
ベータブランチ：ビルドを置く枝（ブランチ）を別に作り、パスワードを付けて限られた人に配る。遊ぶ人は、ライブラリでゲームの「プロパティ」から切り替える
発売前のキー：Release State Override キーは、発売前から遊べるキー。販売は禁止で、通常2,500本まで

外部に配る β では、未完成であることを起動時に伝えます。公開されている例として、Xbox の要件（XR-117）は、ベータ版のゲームに、起動してから遊び始める前に、プレリリース版であること、一部の機能が正しく動かず強制終了することがあることなどを伝える画面かメッセージを出すよう求めています（Microsoft Learn「XBOX Requirements for XBOX Games」、Version 16.4）。目的の決め方や意見の集め方は「プレイテストのやり方」、お金を取って開発途中の版を売る早期アクセスは「ゲームの発売（リリース）手順」で解説しています。

夕宮たいだ

ほよ？オンラインゲームの「βテスト」と、開発のβって別ものなんだぁ。名前が同じだと、まざっちゃうよねぇ。

βROMの到達条件の例

ひとことで：「仮のものが残っていない」ことを、素材・文章・機能・不具合・動作環境の5つで確かめます。

α の到達条件が「全体がつながったか」だったのに対し、β の到達条件は「仮のものが残っていないか」です。この連載で置く例を示します。個人〜少人数のインディーの規模に合わせた例で、業界の決まりではありません。

分類	到達条件の例	2Dアクション（全5ステージ）の場合	ノベルゲーム（全6章）の場合
素材	仮素材が0（素材の一覧がすべて「本」）	背景・敵・5体のボス・効果・BGM・効果音がすべて本番	立ち絵5人×表情10、背景30枚、BGM20曲、スチルがすべて本番
文章	本文・メニュー・説明文が確定し、翻訳に出せる	チュートリアル、メニュー、ボスの名前、実績の文	全6章の本文の推敲が終わり、選択肢とメニューの文も確定
機能	α の後に予定した改善が入り、新しい機能は無い。設定（音量・操作・画面・言語）がそろう	キーの割り当ての変更、コントローラーのボタン表示の切り替え	文字の速さ・既読スキップ・オートの設定、セーブの互換
不具合	進行不能・強制終了・セーブ破損の既知の不具合が0件。ほかは重さを付けて一覧で管理	どの順番でステージを選んでも、エンディングまで進める	3つの結末と、全選択肢の組み合わせを通しで確かめた
動作環境	最低スペックの候補の PC で、最後まで遊べる	最も重いボス戦でも、目標のフレームレートを保つ	画面の切り替えや演出の途中で止まらない

「仮素材が0」は、α で作った素材の一覧があれば、数えるだけで判定できます。β の判定でつまずきやすいのは、どれが仮なのか誰も覚えていない状態から始めた場合です。

文章の確定を β の条件に入れているのは、翻訳の都合です。翻訳に出したあとで原文が変わると、すべての言語で直し直しになります（後述のテキストロック）。版番号は、αROM を 0.5.0 としたなら βROM は 0.8.0 のように進めておくと、後から並べたときに分かりやすくなります。

βでやること

ひとことで：不具合の修正、調整、最適化と動作環境の確認、ローカライズの実機確認、クレジットと権利表記の確認、配布物の中身の確認を、締め切りの近いものから進めます。

不具合を見つけて直す

β の中心は、不具合を見つけて直すことです。全編を通す QA（品質の確認）を計画的に回し、不具合は再現手順（どうすれば起きるか）と重さを付けて、一覧で管理します。直したら、その不具合が直ったことと、直したことで別の所が壊れていないこと（回帰テスト）の両方を確かめます。

β では、テストの網を広げます。2Dアクションなら、ステージを順番どおりでなく選んで遊ぶ、ボス戦の途中でポーズやコントローラーの抜き差しをする、セーブした直後にゲームを強制終了する、といった「普通は遊ばない遊び方」も試します。ノベルゲームなら、全選択肢の組み合わせと、既読スキップ・オート・バックログの組み合わせを確かめます。テストの計画と不具合の報告の書き方は「ゲームのデバッグとQA」で解説しています。

調整

難しさ・テンポ・確率などの数値の調整も、β の前半までは続けます。素材がそろって初めて分かる手触りがあるからです。本物の効果音が付くと攻撃が強く感じられたり、背景が描き込まれて足場が見にくくなったりします。ただし、β の調整は数値と文言の範囲で行います。新しい仕組みを足して解決したくなったら、それはフィーチャーフリーズの例外として扱います。調整の進め方は「ゲームバランス調整の進め方」を参照してください。

最適化と動作環境の確認

β は、ゲームが自分の PC 以外でも快適に動くかを確かめる段階です。まず目標を決めます。フレームレート（1秒間に描く画面の数。30 や 60）、解像度、読み込み時間の上限です。次に、最も重い場面（敵がいちばん多い所、演出が重なる所）を一覧にし、そこで計測します。重い原因が CPU か GPU か、メモリかを計測で切り分けてから直すのが原則です。計測から始める最適化の進め方は、3DCG の記事ですが「リアルタイム最適化チェックリスト」が参考になります。

最低スペックと推奨スペックは、Steam のストアページのシステム要件に載せる情報です。決め方に公式の基準はないので、この連載では次のように置きます。

最低スペック：最も低い設定で、最も重い場面でも遊べること（例：2Dアクションなら 30fps を下回らない）を、実機で確かめた構成
推奨スペック：既定の設定で、想定どおりの快適さ（例：1920×1080 で 60fps）で遊べることを、実機で確かめた構成

どちらも「確かめた構成だけを書く」のが原則です。Steam のビルドの審査では、ストアに載せたすべての OS で起動するかが確かめられます（2026年10月時点の公式ドキュメント）。手元に性能の低い PC がなければ、知人の PC で遊んでもらう、ノート PC の内蔵 GPU で試すなど、開発機と違う環境を1台でも用意します。Steam が毎月公開している「Steam ハードウェア&ソフトウェア調査」では、利用者のメモリ・グラフィックボード・画面の解像度などの分布が見られます（2026年9月分では、主な画面の解像度は 1920×1080 が 47.91% で最多）。調査の数字は月ごとに動くので、見るときは何月の調査かを確かめます。

開発機では起きにくく、ほかの PC で起きやすい問題も確かめます。

ユーザー名に日本語などの全角文字を含むアカウントで、セーブと設定の保存ができるか
画面の拡大率（125%・150% など）や、複数のモニターで表示が崩れないか
ノート PC の省電力の設定で、極端に重くならないか
手元にある種類のコントローラーで全部の操作ができ、ボタンの表示が合っているか

携帯型の Steam Deck で遊ばれることも考えるなら、互換性の区分を知っておきます。2026年10月時点の公式ドキュメント（Steam Deck and Steam Machine Compatibility Review）では、区分は次の4つです。

区分	意味
Verified（認証済み）	すべてのチェックに合格し、設定作業なしで全機能を使える
Playable（プレイ可能）	動くが、利用者の手作業が必要なことがある
Unsupported（非対応）	互換性の問題で動かない
Unknown（不明）	まだレビューされていない

Verified の主な条件は、既定の操作設定でコントローラーから全内容に届くこと、画面のボタン表示が使っている入力と一致すること、文字の入力が必要なら画面キーボードを出せること、既定の設定で遊べるフレームレート（Steam Deck は 800p で 30fps）、1280×800 で文字が最小 9px（推奨 12px）であることなどです。レビューの結果は互換性の表示にだけ影響し、販売や発売の可否には影響しません。申請は通常のビルドの審査を済ませてから行い、申請の機能が使えるのは一部のパートナーに限られています。

動作環境の確認表の例。開発機・最低スペックの候補・推奨スペックの候補・Steam Deck の4列で6つの項目を確かめ、最低スペックの候補の重い場面だけ×で、計測して直す — 図1：開発機以外の環境でも同じ項目を確かめ、確かめた構成だけを書く

ローカライズの実機確認

多言語に対応するなら、翻訳した文章を実際の画面で確かめる LQA（翻訳の実機確認）を β で行います。文字が枠からはみ出す、フォントに無い文字が四角（いわゆる豆腐）で出る、改行の位置がおかしい、名前や数字の差し込みで語順が崩れる、画像の中の文字が翻訳されていない、といった問題は、実際の画面でしか見つかりません。

筆者の「つみこめ！イカサマ魔法麻雀」では、ウクライナ語に使う і・ї・є・ґ の文字が、同梱のフォントに無いことが分かりました。また、起動の引数（起動するときに渡す設定）で言語を指定したテストでは再現せず、通常の起動のときだけ表示が日本語に固定される不具合もありました。テストでの起動のしかたと、プレイヤーの起動のしかたが違うと見落とす、という例です。

Steam のストアに出す対応言語は、ゲーム内の言語設定で判定されます（2026年10月時点の公式ドキュメント）。ストアで宣言する言語は、ゲーム内で選べること、未翻訳の文字列が残っていないことを確かめます。準備から確認までの流れは「ゲームのローカライズ（多言語対応）」で解説しています。

クレジットと権利表記の確認

クレジット（制作者の一覧）と権利表記も、β の間に確定させます。確かめるのは次の点です。

制作に関わった人・会社の名前と役割、使った素材の提供元
エンジンのライセンス表記（例：Godot は MIT ライセンスで無料だが、ゲームのどこかに Godot のライセンス文を入れる必要がある）
同梱するフォントのライセンス（OFL のフォントなら、ライセンス文の OFL.txt も一緒に入れる。メイリオや游ゴシックなど Windows に付属するフォントは、ゲームに同梱できない）
MIT や Apache 2.0 などのライブラリのライセンス文と著作権表示
生成AIで作った素材がある場合、Steam の内容の申告（Content Survey）の AI の欄と、実際の中身が一致しているか

権利の考え方は「ゲーム開発の権利と規約」で詳しく扱います。ここに書いたことは法的な助言ではありません。最終確認は、各規約の原文や専門家で行ってください。

配布物の中身を確かめる

最後に、配る物そのものを確かめます。見るのはソースコードではなく、書き出した配布用のフォルダの中身です。入れてよいファイルの一覧と照合し、開発用のファイル（撮影した画像・ログ・テスト用の設定など）が混ざっていないか、実行ファイルのプロパティ（製品名・版・著作権表記）が正しいか、確認用の機能が消えているかを見ます。この確認でどんなものが見つかるかは、後の「AIゲーム開発でのβROM」で、筆者の実例として紹介します。

夕宮たいだ

ぁぅ……自分のPCで動いても、ほかのPCで動くとは限らないんだよねぇ。日本語のユーザー名とか、気をつけてねぇ。

コンテンツロックとコードフリーズ

ひとことで：β の途中で素材や文言の追加・変更を止め（コンテンツロック）、最後はコードの変更も承認した不具合の修正だけに絞ります（コードフリーズ）。

開発の後半には、変更を段階的に止めていきます。どれも「その種類の追加・変更を止める取り決め」で、何を止めて何を許すかは会社によって幅があります。代表的なものを、止める順に並べます（時期は例です）。

取り決め	多くの場合、止めるもの	止めた後に許されること（多くの場合）	時期の例
フィーチャーフリーズ	新しい機能	不具合の修正、調整、使い勝手の改善	α の後
テキストロック（ストリングロック）	原文（翻訳の元になる文章）の追加・変更	誤字や表示崩れの修正（翻訳と同時に直す）	翻訳に出す前
コンテンツロック	素材・内容の追加と差し替え	不具合の修正に必要な差し替え	β の途中
コードフリーズ	コードの変更	承認した不具合の修正だけ（一切変えないとする場合もある）	リリース候補を作る前

テキストロックは、翻訳に出すために原文を確定させる時点です。運営型のゲームの更新の流れで、アルファとベータの間に置く例があります（Gridly、2026年1月）。コンテンツロックは、Supergiant Games が『Transistor』の開発で使った言葉で、仮素材がなくなり、調整・ボイスのタイミング・実行性能まで、あらゆる面を固めていく段階と説明されています（Supergiant Games のブログ、2014年）。コードフリーズは、英語の教科書（Chandler）では「新しいコードを足さず、バグの修正だけを行う段階」とされ、2年の開発の例では、コードリリース（出荷や審査に出せる版）の3〜4か月前に置かれています。インディーの規模では、この月数をそのまま当てはめる必要はありません。

似た言葉に「コンテンツコンプリート」があります。すべての素材・内容が入った状態を指して使われる程度の言葉で、資料で決まった定義は見当たりません。

例の2本なら、ノベルゲームは全6章の推敲を終えた日にテキストロックをかけて英訳に出し、立ち絵と背景がそろった日にコンテンツロックをかけます。2Dアクションは、最後のボスの効果音まで本番の素材が入った日が、コンテンツロックの目安です。

小さなチームでの運用のコツは、ロックの日をスケジュールに書き、ロックの後の変更は「変更の申請」を通すことです。申請には、何を・なぜ変えるのか、影響する範囲、確かめ方を書き、決める人が許可したものだけを入れます。1人の開発でも、申請を自分あての記録として残すだけで、勢いでの変更が減ります。

変更を止める4つの取り決めの順番。α の直後にフィーチャーフリーズ、β の前にテキストロック、β の途中にコンテンツロック、リリース候補の前にコードフリーズ。それぞれ止めた後に許すことを添える — 図2：変更は段階的に止める。何を止め、止めた後に何を許すかを決めておく

夕宮たいだ

フリーズ、ロック、またフリーズ……むずかしいねぇ。「何を止めて、何なら許すか」を書いておけば、呼び方が会社ごとに違ってもだいじょうぶなんだぁ。

直す不具合と残す不具合の決め方

ひとことで：β を抜ける条件を先に決め、残った不具合は「直す」「直さずに出す」「発売後の更新で直す」に振り分けます。

β の終わりが近づくと、すべての不具合を直す時間はなくなります。そこで、β を抜けてリリース候補（そのまま製品になれる版）を作る条件を決めておきます。この連載での例は次のとおりです。

進行不能・強制終了・セーブ破損・遊べないほど重い場面の、既知の不具合が0件
全編を、最低スペックの候補の PC も含めて、通しで確かめた
ストアで宣言するすべての言語で、全画面を確かめた
クレジット・権利表記・AI の開示が確定し、中身と一致している
配布物の中身を、入れてよいファイルの一覧と照合した

残った不具合は、プレイヤーへの影響の大きさと、直すことの危険（直したら別の所が壊れるかもしれない範囲の広さ）の2つで振り分けます。影響が大きいものは、危険があっても直します。影響が小さく、直す範囲が広いものは、無理に直さず既知の不具合として一覧に残し、発売後の更新で直す選択肢もあります。発売が近いほど、修正で生まれる新しい不具合の方がこわくなるからです。

	直す範囲が狭い（危険が小さい）	直す範囲が広い（危険が大きい）
影響が大きい（進行不能・強制終了など）	すぐ直す	直す。テストを厚くし、時間を確保する
影響が小さい（見た目の小さな崩れなど）	余裕があれば直す	残す候補。既知の不具合として記録し、発売後の更新で直す

不具合を直すか残すかを、プレイヤーへの影響と直す範囲の広さの2軸で、すぐ直す・直してテストを厚く・余裕があれば直す・残して発売後に直す、に振り分ける — 図3：影響の大きさと、直すことの危険の2つで振り分ける

重さと優先度の付け方は「ゲームのデバッグとQA」、リリース候補から製品版を確定するまでは「マスターアップとは」、発売後の修正の出し方は「発売後のゲーム運用」で解説しています。

AIゲーム開発でのβROM

ひとことで：不具合の修正は AI で速くなる一方、直したら別の所が壊れる危険も増えるので、自動テストと配布物の機械の検査を関所にし、直す・残すは人が決めます。

速く直せるほど、関所が要る

β は、AI エージェント（Claude Code や Codex のように、指示を受けてコードを書き、動かし、確かめるところまで進める AI）がとても役に立つ工程です。不具合の報告を渡せば、原因を探して直すところまで短い時間で進みます。ただし速く直せるようになると、直した回数だけ「直したら別の所が壊れる」（回帰）の機会も増えます。修正が速くなった分、確かめる仕組み（関所）の重みが増す、というのが β での重心の動きです。人の仕事は、直す作業から、「どれを直し、どれを残すか」の判断と、直ったあとの手触りの確認へ移ります。

筆者の実例：配布物を開いて見つかった事故

筆者が麻雀ゲームと同じエンジンから派生させたカードゲームでは、提出用のビルドを確認する段階で、次のような事故が見つかりました。

開発用のスクリーンショット117枚（94MB）が、配布物に入っていた。プロジェクトのフォルダの中に置いていた画像が、書き出しの設定によって一緒に含まれていたもので、除外の設定に足すと、実行ファイルが 509MB から 424MB に減った
書き出しの設定と、クレジットの見出しが、複製元の麻雀ゲームのままだった
デバッグ用の「全部見える視点」が、配布版のメニューに出ていた

どれも、ソースコードを読んでいるだけでは気づきにくく、配布物そのものを開いて初めて分かるものです。例えば Godot の書き出しには「プロジェクトのすべてのリソースを書き出す」という設定があり、除外のフィルターを設定しないと、フォルダの中の画像も一緒に入ります（Godot 4.7 のドキュメント）。

通信対戦は、配布版どうしで実際に対局させ、両方の結果が一致することを確かめました。開発中の起動のしかたで一致していても、配布版で同じになるとは限らないからです。

自動テストも関所として使っています。提出するビルドでは、麻雀ゲームで約3.2万件、開発中の将棋ゲームで8.2万件、カードゲームで66万件のチェックを走らせ、失敗が0件であることを確かめています。小さな変更は約30秒の簡易版で確かめますが、簡易版でも最初に全スクリプトの文法チェックを走らせます。壊れたテストが実行されないまま、見かけだけ合格になるのを防ぐためです。

AI に任せる検査

β で AI に任せやすいのは、修正そのものと、機械で確かめられる検査です。

不具合1件ごとに、再現・原因・修正・テストを1組で：再現手順をなぞるテストを先に書き、失敗することを確かめてから直す
回帰テストの追加：直した不具合ごとに、同じ不具合が戻ってこないかを見るテストを足す
配布物の機械の検査：入れてよいファイルの一覧との照合、容量の変化、実行ファイルのプロパティ（製品名・版・著作権表記）、確認用の機能がリリース用の書き出しで消えているか
クレジットと素材の突き合わせ：素材・フォント・ライブラリの一覧と、クレジット・ライセンス表記の照合
翻訳の表示の検査：各言語で画面を撮影し、枠からはみ出す文字やフォントに無い文字を探す
動作環境の記録：起動時に版番号・OS・GPU をログに残す仕組みを入れ、不具合の報告で環境を特定できるようにする
ストアの記載との突き合わせ：ストアページに書いた機能・対応言語・コントローラーの対応が、ビルドに入っているかを一覧にする（Steam のビルドの審査でも、ストアに書いた機能が入っているかが確かめられる）

自動の検査と人の目の役割分担は、3DCG のアセットの話ですが、「レビュー・QAの設計」の考え方がそのまま使えます。

直す・残すは人が決める

どの不具合を直し、どれを残すか：AI は重さの案と、直す範囲の見積もりを出せますが、残して出す判断と、その説明（既知の不具合の告知）は人が行います
直ったあとの手触り：操作の気持ちよさ、演出のタイミング、文章の読み味は、テストでは分かりません。直した所は、人が遊んで確かめます
どの環境まで支えるか：最低スペックをどこに置くかは、売る範囲と問い合わせの量に関わる判断です
権利表記と開示の最終確認：AI が作った照合の表は助けになりますが、表記と開示の責任は作者にあります
外部に配るかどうか：β を外部のテストに出すか、何を見せるか、情報がどこまで漏れてもよいかを決めます

落とし穴

直したら別の所が壊れる：修正ごとに回帰テストを足し、全テストが通ったことで判断します。β の後半は、直す範囲が狭い修正だけにします
「直りました」を確かめない：AI の報告ではなく、再現手順でもう一度起こらないことを確かめます。テストを先に書かせると、この確認が自動になります
一度にまとめて直させる：1回の依頼で何件もの不具合を直させると、どの変更が何を壊したのか分からなくなります。1件ずつ直し、変更の記録（コミット）も分けます
症状だけを隠す修正：エラーを握りつぶす、その場合だけ処理を飛ばす、といった修正は、別の形で問題を残します。原因の説明を求め、変更の差分を読みます
テストを緩めて合格させる：テストが落ちたときに、テストの方を消したり条件を緩めたりする変更が混ざることがあります。依頼文の決まりに「テストを消したり緩めたりしない」を入れます
テストが本物のデータを汚す：筆者の麻雀ゲームでは、テストが筆者の実際のセーブデータを汚す事故（設定を既定値で上書きし、実績を書き込んだ）があり、退避と隔離の仕組みを入れました
関所の穴に気づかない：筆者の麻雀ゲームでは、Codex に実際のビルドを遊ばせた試しで、実行時のエラーがテストの失敗に数えられていない問題が見つかりました。テストが通っていても、関所そのものを時々点検します

夕宮たいだ

テストを消して合格にするの、絶対ダメだよ！それ、直ったんじゃなくて、見えなくなっただけなんだぁ。

依頼文の例：テストを先に書かせる修正

Goal: 不具合「3章で既読スキップ中に選択肢が来ると止まらない」を直す
Context: 再現手順は bugs/0042.md。βなので新しい機能・文言は足さない。
  直してよいのはスキップの処理（scripts/skip.gd）だけ
Done when: 再現手順をなぞるテストを先に書いて失敗を確かめ、修正後に成功した。
  全テストが失敗0で通り、原因と直し方を3行で説明した
Constraints: テストを消したり、条件を緩めたりしない。ほかの画面の動きは変えない

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

βでよくある失敗と対処

ひとことで：多くは、β なのに「足してしまう」ことと、「自分の環境でしか確かめない」ことから起きます。

失敗	起きること	対処
β に新しい機能を足す	新しい不具合が増え続け、β が終わらない	フィーチャーフリーズとコンテンツロックを守り、例外は申請で決める
仮の素材や文章が残る	発売後にプレイヤーが見つける	素材の一覧で仮が0か数え、文章に付けた仮の印を検索する
開発機だけで確かめる	ほかの PC で起動しない・重い	最低スペックの候補の PC で最後まで遊び、ログに環境を残す
翻訳を最後にまとめる	表示崩れが直しきれない	テキストロックの日を決め、早めに実機で確かめる
クレジットや権利表記が漏れる	表記が足りない、規約に反する	素材・フォント・ライブラリの一覧から作り、照合する
直したら別の所が壊れる	発売直前に重大な不具合が出る	回帰テストを足し、後半は直す範囲を絞る
配布物に余計な物が入る	容量が増える、開発用の物が見える	配布用のフォルダを、入れてよいファイルの一覧と照合する
「βテスト」と混同して外部に配る	情報が漏れる、未完成の評判が広まる	目的を決め、Playtest・パスワード付きのブランチ・キーを使い分ける