αROM（アルファ版）とは｜AIゲーム開発で通して遊べる仮完成の基準

2026年10月4日

「αROM（アルファ版）」は、ゲームの主な機能がそろい、最初から最後まで通して遊べるようになった段階を指す言葉です。企画・試作・バーティカルスライスを経て本制作（プロダクション）に入ったあと、最初に迎える大きな節目で、ここを境に「機能を作る」仕事から「作った機能を仕上げる」仕事へと重心が移ります。この工程が全体のどこにあるかは「ゲーム開発の全工程マップ」で確認できます。

本記事では、αROM の定義と英語の呼び方との対応、α の時点で確かめること、到達条件の例、α の後に新しい機能の追加を止める「フィーチャーフリーズ」、よくある失敗までを解説します。最初にお断りしておくと、α・β・マスターの基準は、会社やパブリッシャーとの契約によって違います。業界で統一された定義はありません。この記事では代表的な考え方と、個人・少人数で使える基準の例を示します。例として、2Dアクション（全5ステージ）とノベルゲーム（全6章）の2本を、この記事と「βROM（ベータ版）とは」「マスターアップとは」で続けて追いかけます。

夕宮たいだ

ふぁ……みんな〜、今日は「αROM」の話だよぉ。ゲームが最初から最後まで、はじめてつながる日のことなんだぁ。……絵はまだ仮だらけだけどねぇ。

αROM（アルファ版）とは

ひとことで：主な機能がそろい、最初から最後まで通して遊べるようになった段階と、その時点で作る確認用のビルドです。

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

α版の段階で提出・確認用に作るビルド（ゲームを実行できる形にまとめたもの）を、日本の現場では「αROM」と呼ぶことがあります。ROM（読み出し専用のメモリ）という呼び方は、ゲームがカートリッジの ROM で売られていた頃の名残といわれます。ディスクやダウンロードで配る今でも、提出用のビルドを ROM と呼ぶ現場があり、バーティカルスライスのような α 以外の提出物を「ROM」と呼ぶ例もあります。ROM は段階の名前ではなく「提出するビルド」を指す言葉、と押さえておくと混乱しません。

英語の呼び方との対応

英語の資料では、Alpha・Beta・Release Candidate・Gold master という言葉が使われます。日本の現場での呼び方との対応は、おおむね次のとおりです。意味は代表的な定義の例で、会社ごとの基準とは一致しないことがあります。

英語	日本の現場での呼び方	代表的な意味	出典の例
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 の引用による）：主要なゲームプレイの機能が実装され、素材は一部できている段階。遊べて主要な機能がそろった「フィーチャーコンプリート（機能完成）」の状態とされ、小さな機能が足されたり、予定していた機能が削られたりもする
Supergiant Games（『Transistor』の開発時のブログ、2014年）：内容はすべて入り、大きな新機能はもう足さない。仮素材は残るが、最終的な体験を表す形で最後まで遊べる
日本の解説（Autodesk AREA JAPAN「ゲーム開発のパイプライン」、2017年）：ゲームの開始から終了までの一連の流れ（ループ構造）を最初に作る段階。データの仕様（ポリゴン数・テクスチャの容量など）もここで決める
元 BioWare の Mark Darrah（2022年の発言の報道）：アルファを宣言するにはチェックリストを満たす必要があり、親会社の EA にも独自のアルファの定義がある

共通しているのは「ゲームの全体が一度つながる」「この後は大きな機能を足さない」の2点です。逆に、素材がどこまで本物か、内容がどこまで入っているかは資料によって違います。デジタルのゲームだけの考え方でもなく、CEDEC2026 では吉田賢志氏が、アナログのカードゲームの開発で α（約2か月・カードの種類を決める）→ β（約3か月・商品に近いカードの組で実戦テスト）→ マスター（約3か月・バランスを調整して入稿できる状態に）と進めた例を紹介しています（GameBusiness.jp、2026年9月1日）。

大きな会社では、α は予算の関門にもなります。CEDEC+KYUSHU 2023 では Orange Butterfly の中山貴伯氏が、試作の審査で予算の約10%、α の審査で20〜25%、β の審査で残りを承認する例を紹介しました（4Gamer、2023年11月30日）。パブリッシャーとの開発契約では、α・β・マスターの納品が支払いの条件として決められることもあります（ゲーム専門の弁護士 Tom Buscaglia の2005年の寄稿）。提出先のない個人開発でも、α は「このまま作り続けてよいか」を自分で判断する関門として使えます。

バーティカルスライス・ファーストプレイアブルとの違い

α と混同されやすい版が2つあります。バーティカルスライスは、ゲームの一部分を製品版に近い品質まで作り、この品質で作れることを示す版です。ファーストプレイアブルは、主要な遊びが初めて通しで動く版で、会社によってはアルファと同じ意味で使われます。

版	作る範囲	見た目の品質	確かめること
バーティカルスライス	一部分（例：1ステージ、1章）	製品版に近い	この品質で作れるか、作る手間はどれくらいか
ファーストプレイアブル	主要な遊び	仮でよい	主要な遊びが通しで動くか
αROM	全体（最初から最後まで）	仮が残る	全体がつながるか、量と面白さの見通し

バーティカルスライスが「一部分を本物に近づける」のに対し、α は「全体を仮のままつなぐ」もので、向きが逆です。『Fallout』の共同制作者の Tim Cain は、全エリアをおおまかに遊べるようにした版（この連載ではホリゾンタルスライス＝全体を荒く通した版、と呼びます）を、エリアのつながり・探索の順序・おおよそのプレイ時間をつかむために作ると説明しています（Game World Observer、2023年）。α は、この「全体を通す」考え方に、製品に必要な機能（セーブ・設定・メニューなど）をそろえた段階と考えると分かりやすくなります。バーティカルスライスの作り方は「バーティカルスライスとは」で解説しています。

プロトタイプからマスターアップまでの5段と、各段でそろっているもの。αROM の段に「ここから新しい機能を止める（フィーチャーフリーズ）」の旗 — 図1：αROM は「全体が仮のままつながる」段階。この後は新しい機能を足さない

夕宮たいだ

ほえ〜、バーティカルスライスは「一部分を本物に」、αは「全体を仮でつなぐ」なんだぁ。向きが逆なんだねぇ。

αROMで確かめること

ひとことで：ゲーム全体を一度通し、「このまま量産と仕上げに進んでよいか」を判断する材料を集めます。

α の目的は、作った機能を並べることではなく、全体を通したときに初めて見えるものを確かめることです。確かめることは次の5つです。

確かめること	見るポイント	2Dアクション（全5ステージ）の例	ノベルゲーム（全6章）の例
最初から最後まで通して遊べるか	進行が途切れない。セーブとロードを挟んでも続く	1面から5体目のボスを倒し、エンディングまで行ける	1章から、3つの結末すべてにたどり着ける
主な機能がそろったか	遊びの機能と、メニュー・セーブ・設定などの外枠	ジャンプ・ダッシュ・溜め撃ち、ステージ選択、設定画面	選択肢と分岐、バックログ、既読スキップ、オート
仕様の穴	つながっていない画面、考えていなかった組み合わせ	溜め撃ちしながらダッシュしたら？ボス戦の途中でポーズしたら？	既読スキップ中に選択肢が来たら？分岐の直前でセーブしたら？
ボリュームの見積もり	通しのプレイ時間、残りの素材と作業の量	通しで何分か。敵の絵は残り何体か	通して読むと何時間か。立ち絵と背景は残り何枚か
遊びの面白さの最終判断	通したときの山と谷、テンポ、難しさの上がり方	3面で同じ敵が続いて中だるみしていないか	4章の日常の場面が長すぎないか

面白さの最終判断はαが最後の機会

5つのうち、いちばん重いのが面白さの最終判断です。プロトタイプやバーティカルスライスでは部分の面白さを確かめましたが、通して遊んだときの流れ（序盤で飽きないか、中盤にだれる所がないか、難しさの上がり方は自然か）は、全体がつながるまで分かりません。そして α の後は、新しい機能を足さない約束（フィーチャーフリーズ）に入ります。遊びの根本に関わる変更をするなら、ここが最後の機会です。

α で大きな問題が見つかったら、機能を足して埋めるより先に、削る・入れ替える・ステージや章の順番を組み替える、といった手を考えます。足した機能は、テスト・説明・調整の手間を β まで連れていくからです。他人に遊んでもらう本格的なプレイテストを始めるのも、通して遊べるようになるこの時期です（「プレイテストのやり方」）。

ボリュームの見積もりと仕様の穴

ボリュームの見積もりも、α でしかできない仕事です。仮でも全体がつながると、通しのプレイ時間と、残りの素材と作業の量を数えられます。2Dアクションで「通しで2時間の予定が80分だった」と分かれば、ステージを足すのか、ストアでの見せ方や価格を見直すのかを、まだ間に合ううちに決められます。ノベルゲームなら、通して読んだ時間と残りの立ち絵・背景の枚数から、β までの作業量を見積もり直します。見積もりの直し方は「ゲーム開発のスケジュールとマイルストーン」で解説しています。

仕様の穴は、機能どうしの組み合わせで見つかります。機能を1つずつ作っているうちは、それぞれが仕様どおりに動いていても、組み合わせた状態は誰も考えていないことがあります。見つけた穴は仕様書に書き足し、直すのか、その組み合わせが起きないようにするのかを決めます。仕様書の書き方は「ゲームデザインドキュメント（GDD）の書き方」で解説しています。

αROMの到達条件の例

ひとことで：機能・内容・素材・不具合の4つに分けて「ここまで来たら α」と先に決め、当日は表で1行ずつ判定します。

何をもって α とするかは、先に決めて書いておきます。決めずに進めると、「だいたい α」のまま日が過ぎていきます。ここでは、この連載で置く到達条件の例を示します。個人〜少人数のインディーの規模に合わせた例で、業界の決まりではありません。

分類	到達条件の例	2Dアクションの場合	ノベルゲームの場合
機能	遊びの主な機能と、ゲームの外枠（タイトル→本編→エンディング→タイトル）がすべて動く。セーブとロード、設定（音量・操作）が使える	ジャンプ・ダッシュ・溜め撃ち、ボス戦の仕組み、ステージクリアでの保存	選択肢と分岐、バックログ、既読スキップ、オート、セーブとロード
内容	すべてのステージや章が、仮でも最初から最後までつながっている	5ステージすべてが仮の地形で遊べ、5体のボスを倒せる	全6章の本文が初稿で入り、3つの結末すべてに届く
素材	仮でよい。ただし最終の数・大きさ・名前で入っていて、1ファイルの置き換えで本物に差し替えられる	敵と背景は灰色の仮の絵、効果音は仮の音	立ち絵は線画、背景は単色に場所の名前、BGM は仮の曲
不具合	通しプレイを止める不具合（進行不能・強制終了）は0件か、回避の手順つきで一覧にある	4面の特定の床をすり抜けて落ちる不具合を、回避の手順つきで一覧に載せ、β までに直す予定を立てる	5章でセーブすると強制終了する不具合を、回避の手順つきで一覧に載せる

「素材は仮でよい」の但し書き

素材は仮でかまいませんが、最終の素材と同じ数・同じ大きさ・同じファイル名（または同じ置き場所）で入れておきます。立ち絵の枠の大きさ、背景の解像度、BGM のループの長さが最終と違うと、差し替えたときに画面の崩れや処理の重さが一度に出てくるからです。素材の一覧に「仮／本」の列を作り、仮のまま残っている数を数えられるようにしておくと、β の到達条件（仮素材が0）を判定するときにもそのまま使えます。素材の発注と差し替えの流れは「ゲームアセット制作の流れ」、ファイル名の付け方は「アセット命名・バージョン規則」で解説しています。

既知の重い不具合の扱い

α の時点で、不具合が0件であることは求めません。求めるのは、通しで遊ぶ人が最後までたどり着けることと、残っている重い不具合が一覧になっていて、β までに直す予定があることです。進行不能（先に進めなくなる）・強制終了・セーブデータの破損の3つは、見つけた時点で一覧の先頭に置きます。不具合の報告の書き方は「ゲームのデバッグとQA」で解説しています。

到達条件に入れないもの

逆に、α の到達条件に入れないものも決めておきます。最終の絵・音・文章の品質、細かい数値の調整、多言語の翻訳、本格的な最適化です。これらは β までの仕事です。ただし、重い場面がどこにあるかは α で把握しておきます。目標のフレームレート（1秒間に描く画面の数）に遠く届かない場面があると分かれば、作り方を変えるかどうかの判断がまだ間に合います。

判定のしかた

到達条件の表は α の予定日より前に読み合わせ、当日は1行ずつ「満たす／満たさない」を付けます。満たさない行が残ったら、日程を延ばすのか、その項目を削る（発売後の更新に回す）のかを決めます。どちらにするかを決めないまま「だいたい α」と呼ぶのが、いちばん避けたい状態です。チームなら、判定する人を1人決めておきます。

αROM の到達条件の例。機能・内容・素材・不具合の4行を、2Dアクション（全5ステージ）とノベルゲーム（全6章）で並べたチェック表 — 図2：到達条件は機能・内容・素材・不具合の4つに分け、1行ずつ判定する

夕宮たいだ

「ほぼα」は、αじゃないんだよぉ！満たしてない行は、満たしてないって書く。そこ、ほんとに大事だからねぇ。

αROMの進め方

ひとことで：到達条件を先に書き、機能の一覧で「α までに入れるもの」を絞り、通しで遊ぶ日を節目にして判定します。

α までの流れは次のとおりです。

① 到達条件と予定日を決める：バーティカルスライスが終わり、本制作に入る頃に、α の到達条件と予定日を文書にする
② 機能の一覧を分ける：作る予定の機能を「α までに必須」と「あれば良い」に分ける。「あれば良い」は、フィーチャーフリーズの後に入らなくても困らないものだけにする
③ 差し替えの仕組みを作る：仮素材を最終の数・大きさ・名前で入れ、一覧で「仮／本」を管理する
④ 通しプレイの日を入れる：予定日の前に、最初から最後まで通して遊ぶ日を設ける。かかった時間・詰まった所・不具合を記録する
⑤ 判定する：到達条件の表で1行ずつ判定し、満たさない行の扱い（延ばす／削る）を決める
⑥ αROM を作って残す：版番号（例：0.5.0）を付けてビルドを作り、どのソースから作ったかと一緒に保管する。β で比べる基準になる

大きな会社では、αROM をパブリッシャーやプラットフォームの担当者に提出して確認を受けます。英語圏では、アルファを「出荷の準備を始める段階から、実際に出荷していく段階へ移る点」とし、テストの体制を本格的に組み、コンソールの要件のテストもここから始める、と説明する開発者もいます（Mark Darrah）。個人や少人数なら提出先はありませんが、自分で判定会を開き、判定の結果と αROM を残しておく意味は大きいです。後から「あの時点ではここまでできていた」と比べられ、次の作品の見積もりにも使えるからです。

α までの期間に、決まった目安はありません。英語の教科書には「2年の開発の例」での時期（コードフリーズはコードリリースの3〜4か月前、など）が載っていますが、規模の違うインディーにそのまま当てはめるものではありません。自分の作品の残りの作業量から逆算します。α の後は、数値の調整が本格化します。進め方は「ゲームバランス調整の進め方」で解説しています。

α後のフィーチャーフリーズ

ひとことで：α を区切りに新しい機能の追加を止め、作った機能を仕上げる作業に切り替える取り決めです。

開発の後半には、「◯◯フリーズ」「◯◯ロック」という取り決めがいくつか出てきます。どれも、その種類の追加・変更を止める取り決めです。中身は会社によって幅があるので、何を止めるのかと、止めた後に何が許されるのかを、自分のプロジェクトで書いておくことが大切です。

α の後に置くのがフィーチャーフリーズです。多くの場合、新しい機能を足す作業を止め、不具合の修正と使い勝手の改善に移ることを指します。全体がつながったので、ここから先は「作る」より「仕上げる」に時間を使う、という宣言です。

対象	多くの場合、止めるもの	多くの場合、続けてよいもの
機能	新しい機能、新しいモードや画面、遊びの仕組みの追加	不具合の修正、使い勝手の改善（説明文、ボタンの配置、操作の反応）
数値	—	難しさ・速さ・確率などの調整
素材	—	仮素材から本素材への差し替え、α で決めた数の範囲での制作
技術	仕組みの大きな作り直し	最適化、多言語化の準備

調整と新しい機能の境目

迷いやすいのが、「調整」と「新しい機能」の境目です。目安は、仕様書に新しい項目が増えるかどうかです。

2Dアクションで、ジャンプの高さを3マスから2.5マスに変える → 調整（続けてよい）
2Dアクションに、2段ジャンプを足す → 新しい機能（止める）。ステージの作り、難しさ、説明まで変わる
ノベルゲームで、既読スキップの速さを変える → 調整（続けてよい）
ノベルゲームのバックログに、音声を再生するボタンを足す → 新しい機能（小さくても、フリーズの後は発売後の更新の候補に回す）

例外の決め方

どうしても入れたい機能が出てきたら、例外として扱います。理由・作業量・壊れるかもしれない範囲・テストの手間を書き、決める人が判断して記録に残します。例外を通すなら、代わりに何を外すかもセットで決めます。個人開発では止める人が自分しかいないので、入れたいものを書き留める置き場（発売後の更新や次の作品の候補の一覧）を作っておくと、フリーズを守りやすくなります。

フィーチャーフリーズの後には、素材や文言の追加を止める「コンテンツロック」、コードの変更を不具合の修正に絞る「コードフリーズ」が続きます。これらは β の段階の取り決めなので、「βROM（ベータ版）とは」で解説します。

α を境に、新しい機能・新しいモードと画面・仕組みの作り直しは止まり、不具合の修正・数値の調整・本素材への差し替え・使い勝手の改善・最適化は続く — 図3：α の後は新しい機能を止め、修正・調整・差し替えを続ける

夕宮たいだ

調整なのか、新しい機能なのか……むずかしいねぇ。「仕様書に新しい項目が増えるか」で見分けると、迷いにくいんだぁ。

AIゲーム開発でのαROM

ひとことで：AI で機能はすぐ足せるからこそ、何を入れて何を止めるかを人が決め、完了の条件とテストを先に書いておく工程になります。

作るより「止める」が難しくなる

AI エージェント（Claude Code や Codex のように、指示を受けてコードを書き、動かし、確かめるところまで進める AI）を使うと、機能の実装は大きく速くなります。その結果、α の工程でいちばん難しいのは「作ること」ではなく「止めること」になります。機能を1つ足すたびに、テスト・説明文・翻訳・バランス・不具合の窓口も増えますが、そのコストは足した瞬間には見えません。頼めばすぐできるので、α の直前まで「ついでにこれも」が続きます。フィーチャーフリーズは、AI を使うと前より守るのが難しくなる約束です。

もう1つの変化は、「動く」と「仕様どおり」の差です。AI は動くものを速く作りますが、動いたことをもって「完了」と報告しがちです。ジャンプの高さが3マスでなくても、ボタンを押して跳べば「実装しました」になります。α の判定の日にこの差に気づくと手戻りが大きいので、機能を頼む前に、完了の条件と、それを確かめるテストを先に書いておきます。

AI に任せやすい準備

α の工程で AI に任せやすいのは、判定の材料をそろえる作業です。

到達条件の表の下書き：仕様書と機能の一覧を読ませ、機能・内容・素材・不具合の表に起こしてもらう（判定は人が行う）
通しプレイの自動化：ノベルゲームなら、全分岐を機械的にたどって3つの結末に届くかを確かめるスクリプト。2Dアクションなら、無敵にした自動操作で全ステージを抜けられるかの確認。進行不能の不具合を、人が遊ぶ前に見つけられる
仮素材の残数の集計：ファイル名の印や素材の一覧から、仮のまま残っている数を毎日数える
完了の条件のテスト化：「ジャンプの最高点が3マス」「天井に当たったら落下に移る」のような仕様を、自動テストに書き起こす
確認用の機能の隔離：確認用のボタンや画面を、デバッグ用のビルドでだけ出る場所にまとめ、リリース用の書き出しで消えることもテストで確かめる
既知の不具合の一覧の整理：報告から再現手順を起こし、重さの案を付ける（重さを決めるのは人）

筆者の実例：開発中の機能は製品版から自動で消す

筆者の「つみこめ！イカサマ魔法麻雀」では、開発中の機能を、タイトル画面の「開発用デバッグ」ボタンの中にまとめて隔離しています。このボタンは、製品版の書き出しでは自動で消えます。使っているゲームエンジンの Godot には OS.is_debug_build() という関数があり、エディターやデバッグ用の書き出しでは true、リリース用の書き出しでは false を返します（Godot 4.7 のドキュメント）。これを使って、ボタンごと出し分けています。

ほかのエンジンにも、同じ考え方の仕組みがあります。Unity では、ビルドの設定で Development Build をオンにしたときと、エディターの中で、Debug.isDebugBuild が true になります（Unity 6.6 のスクリプトリファレンス）。Unreal Engine では、出荷用の Shipping 構成が、コンソールコマンドや統計の表示、プロファイリングの道具を取り除きます（Unreal Engine 5.8 のドキュメント）。

麻雀ゲームの通信対戦も、1つのフラグ（オン／オフの設定値）で丸ごと隠せるようにしてあります。発売までに検証が間に合わなかった場合に、機能を消さずに入口だけを隠せるようにするためです。同じエンジンから派生させたカードゲームでは、7種目を作ったうち、最初の発売では一部の種目だけを出すことにし、発売する範囲を1つの設定ファイルで切り替えられるようにしました。こうした切り替えは、機能を消すのではなく入口だけを隠す形にしておくと、後から戻すのも設定を1か所変えるだけで済みます。

どの機能も、AI が作って終わりにはしていません。機能ごとに確認用の実行ファイルを筆者が受け取り、実際に遊んでから、採否や直しを決めています。AI が速く作れるほど、この「遊んで決める」時間を先に予定へ入れておくことが大切になります。

夕宮たいだ

ほら、確認用のボタンがリリース用の書き出しで勝手に消えるの、便利でしょ？消し忘れの心配が、ひとつ減るんだぁ。

人が決めること：入れる・捨てる・遊んで判断する

何を入れて何を捨てるか：α までに入れる機能、フリーズの例外、削る機能。AI は選択肢と作業量の見積もりを出せますが、作品の形を決めるのは人です
通して遊んだ感触：テンポ、難しさの上がり方、中だるみ、操作の手触り。自動の通しプレイが確かめるのは「最後まで行けるか」で、「面白いか」は確かめません
α の宣言：表の各行を AI が「満たす」と報告しても、最後に α と判定するのは人です。特に「仕様どおりか」は、仕様を決めた人が見ます
仮素材の扱い：仮に AI で作った絵や音を使う場合、製品に残さない管理をします（次の落とし穴を参照）

落とし穴

機能が増え続ける：フリーズの日を先に決め、入れたいものは一覧に書き留めます。AI への依頼文にも「新しい機能は足さない」を入れます
「動く」を「完了」と受け取る：完了の条件とテストを先に渡し、テストが通ったことで判断します
仕様書と実装がずれる：AI が判断で足した動きは、仕様書に書かれていないことが多くあります。機能を頼むときは、仕様書の更新も同じ依頼に含めます
確認用の機能が製品に残る：AI が気を利かせて足した確認用のボタンやログが、そのまま製品版に出ることがあります。隔離の決まりを、プロジェクトの指示ファイル（「CLAUDE.md 完全ガイド」「Codex AGENTS.md完全ガイド」参照）に書いておきます
AI で作った仮素材が残る：仮のつもりの AI 生成の絵や音が製品に残ると、Steam では、プレイヤーが触れる内容として AI 生成コンテンツの開示の対象になります（2026年10月時点の公式ドキュメント）。権利の確認も必要になるので、仮素材には印を付けて残数を数え、β までに0にします（「ゲーム開発の権利と規約」参照）

夕宮たいだ

ぁぅ……AIだと「ついでに」がほんとに止まらないんだよねぇ。フリーズの日、先に決めておこうねぇ。

依頼文の例：到達条件を毎日確かめる

到達条件の判定を、AI に下準備させるときの依頼文の例です。書き方の基本は「Claude Code プロンプト設計」「Codexプロンプト設計」で解説しています。

Goal: α の到達条件を満たしているかを、毎日1回の実行で確かめられるようにする
Context: 到達条件は docs/alpha_criteria.md（機能・内容・素材・不具合の4分類）。
  仮素材はファイル名が tmp_ で始まる。確認用の機能はデバッグ用のビルドでだけ出す決まり
Done when: 条件ごとに「満たす／満たさない／人が判断」を表で出す。自動で確かめられる項目
  （全章の結末に届く・仮素材の数・確認用の機能がリリース用の書き出しで消える）はテストにした
Constraints: 新しい機能は足さない。「人が判断」の行は理由を添えて残す

αでよくある失敗と対処

ひとことで：多くは「止められない」「決めきれない」「差し替えられない」のどれかです。

失敗	起きること	対処
機能が増え続ける	α がいつまでも来ない。後ろの工程が詰まる	フィーチャーフリーズの日を先に決め、入れたいものは一覧に書き留める
「ほぼ α」のまま進む	未達の項目が β に持ち越され、β が仕上げにならない	到達条件の表で判定し、満たさない行は日程を延ばすか削るかを決める
仮素材のまま差し替えの仕組みがない	差し替えで画面が崩れる。仮素材が製品に残る	最終の数・大きさ・名前で仮を入れ、一覧で残数を数える
通しで遊ぶ人がいない	つなぎ目の不具合や中だるみに気づかない	通しプレイの日を決め、作った人以外にも遊んでもらう
面白さの判断を先送りする	β で作り直しになる	α の判定で「続ける・変える・削る」を決める
確認用の機能が混ざる	製品版に確認用のボタンが出る	デバッグ用のビルドでだけ出る仕組みにまとめる
見積もりを直さない	発売日に間に合わない	通しのプレイ時間と、残りの素材の数で見積もり直す