AIゲーム開発の流れと全工程マップ｜個人開発で企画から発売後まで

2026年10月4日

ゲームを作るには、「何を作るか決める」「作れるか確かめる」「作りきる」「出せる品質に仕上げる」「遊んでほしい人に届ける」「出したあとも面倒を見る」という段階を順に通ります。ゲーム会社ではこの流れを工程と呼び、段階の区切りごとに「マイルストーン」と呼ぶ到達点を置いて、進み具合と次へ進むかを確かめます。

本記事は、連載「インディーゲーム開発の全工程」の入口です。企画から発売後までの工程を順に短く紹介し、詳しい解説記事へ案内します。あわせて、工程の区分、マイルストーンの関係、工程が並行して進むこと、個人・少人数での進め方の例、AIエージェント（Claude Code や Codex のように、ファイルを読み書きしコマンドを実行しながら作業を進める AI）で工程がどう変わるかまで、1本で見渡せるようにまとめました。

工程の言葉の意味は、会社や資料によって違います。本記事では一般に多い使い方を示し、違いがある所はそう書いています。Steam の規則と数値は、2026年10月4日に Steamworks の公式ドキュメントで確認したものです。

夕宮たいだ

ふぁ……みんな〜、今日はゲーム開発の「全体の地図」の話だよぉ。αROM とかバーティカルスライスとか、言葉だけ聞いたことある人も多いと思うんだぁ。どこで何をするのか、一緒に並べていこ〜。

ゲーム開発の全工程を1枚で見る

ひとことで：企画から発売後までの6つの段階が、それぞれ1つの問いに答えながら連なっています。

ゲーム開発の工程は、「答える問いの順番」として見ると覚えやすくなります。各段階で作る試作や途中の版は、その問いに答えるための材料です。段階の中では「決める→作る→遊んで確かめる→直す」を小さく何度も回し、段階の終わりに「進む・変える・やめる」を判断します。

段階	答える問い	主な工程	終わりの目印（例）
企画	何を作るか。作る価値はあるか	企画、プロトタイプ、GDD、スケジュール、開発環境、資金の検討	試作の結論と企画書
プリプロダクション	この品質で作れるか	グレーボクシング、バーティカルスライス	バーティカルスライス
プロダクション	全部を作りきれるか	素材と音の制作、実装、プレイテスト、バランス調整、ローカライズ	αROM を経て、βROM へ進める状態
仕上げ	出してよい品質か	βROM、QA・デバッグ、最適化、提出	マスターアップ
発売準備（並行）	遊んでほしい人に届くか	ストアページ、宣伝、体験版、権利と規約	近日登場ページの公開、発売日の決定
発売と運用	出したあとも続けられるか	発売、アップデート、セール、移植	振り返り（ポストモーテム）

ゲームデザイナーの Mark Cerny 氏は2002年の講演で、プリプロダクションとプロダクションは「昼と夜ほど違う」と述べ、プリプロダクションの終わりに完成品質のゲームの一部分を作って、続けるか中止するかを決める進め方を紹介しました（VGC の解説記事による）。段階の区切りを判断の場にする考え方は、個人の開発にもそのまま使えます。

ゲーム開発の6段階（企画・プリプロダクション・プロダクション・仕上げ・発売・運用）とマイルストーンの流れ。プロダクションの途中から発売準備と Steam の手続きが並行し、権利の確認が企画から発売まで通して走る — 図1：開発の流れの横で、発売準備と Steam の手続きが同時に進む

工程の区分：プリプロダクション・プロダクション・仕上げ

ひとことで：試作で確かめる段階、本制作の段階、発売前に仕上げる段階の3つに分けるのが一般的です。

開発の中心部分は、次の3つに分けて呼ばれます。

プリプロダクション（pre-production）：作るべきか・作れるかを、企画と試作で確かめる段階
プロダクション（production）：本制作（量産）の段階。素材とプログラムの大部分をここで作る
ポストプロダクション（post-production）：この連載では「仕上げ（βROM〜マスターアップの、発売前の仕上げ）」の意味で使います。資料によっては発売後の運営を指すこともあり、ほかに「振り返り」や「アルファから発売まで」を指す資料もあります。意味が割れている言葉なので、本連載では迷ったら「仕上げ」と書きます

この連載では、企画と試作（プロトタイプ）までを「企画」、ステージの仮組とバーティカルスライスを「プリプロダクション」の記事として分けていますが、一般にはどちらもプリプロダクションに含まれます。また、ストアページや宣伝などの「発売準備」は、どこか1つの段階ではなく、開発と並行して進む別の流れとして扱います。

大きな会社では、段階の切り替わりで予算と体制を見直すことがあります。CEDEC+KYUSHU 2023 の講演では、試作の予算審査で約10%、α の予算審査で20〜25%、β の予算審査で残りの予算を承認する進め方が紹介されました（4Gamer の記事）。個人の開発でも、段階の終わりに「続ける・変える・やめる」を決める日を自分で決めておくと、終わりの見えないまま作り続ける事態を防げます。

夕宮たいだ

ポストプロダクションって、本によっては発売後のことなんだぁ……むずかしいねぇ。この連載では「発売前の仕上げ」の意味だから、迷ったら「仕上げ」って読み替えてねぇ。

マイルストーンのはしご

ひとことで：プロトタイプからマスターアップまで、完成度の段を1段ずつ上がり、段ごとに確かめることが決まっています。

マイルストーンは、開発の途中に置く「ここまでできたら次へ進む」到達点です。パブリッシャー（販売や宣伝を担う会社）と組む開発では、契約上の提出物と支払いの条件にもなります。ただし、どの段で何がそろっていればよいかに業界共通の基準はなく、会社や契約で違います。次の表は一般に多い使い方の例です。

日本の呼び方	英語	その時点の状態（例）	そこで確かめること
プロトタイプ	Prototype	中心の遊びだけが動く、見た目を作り込まない使い捨ての試作	遊びが成立するか（作るべきか）
ファーストプレイアブル	First Playable	主要な遊びが初めて通しで動く。会社によってはアルファと同じ意味	遊びの流れがつながるか
バーティカルスライス	Vertical Slice	ゲームの一部分（例：1ステージ、ノベルなら1章ぶん）が製品版に近い品質	この品質で作れるか。1区画を作る手間はどれくらいか
αROM（アルファ版）	Alpha	主な機能がそろい、最初から最後まで通して遊べる。仮素材が残っていてもよい	全体の流れと遊びの量。足すか削るかの最後の判断
βROM（ベータ版）	Beta	機能と素材がそろい、不具合の修正と調整が中心になる	出荷を妨げる不具合が残っていないか。性能と文言
マスターアップ	Gold Master（ゴールド）	製品版として確定し、量産や配信に回せる	提出・審査を通るか。発売してよいか

αROM・βROM は、α版・β版の段階で提出・確認用に作るビルド（実行できるゲームのファイル一式）を、日本の現場で「αROM」「βROM」と呼ぶことがある言い方です。ゲームがカートリッジの ROM で出ていた時代の名残です。「αROM＝全機能、βROM＝全素材」のような基準を見かけることがありますが、業界の決まりではありません。到達条件は、会社や契約ごとに文章で決めます。

段と段の間には、その種類の追加・変更を止める取り決め（フリーズ・ロック）を置くのが一般的です。新しい機能の追加を止める「フィーチャーフリーズ」（α を区切りにすることが多い）、素材や文言の追加・差し替えを止める「コンテンツロック（コンテンツフリーズ）」、バグ修正以外のコード変更を止める「コードフリーズ」などです。どの段に置くか、止めた後に何を許すか（多くの場合はバグ修正のみ）は会社や計画で違うので、計画の段階で決めておきます。

段の中身も固定ではありません。先に紹介した Cerny 氏の進め方では、プリプロダクションの終わりに作る「完成品質の一部分」を first playable と呼んでおり、ファーストプレイアブルとバーティカルスライスがほぼ同じものを指します。英語圏の資料では、マスターの直前に「リリース候補（Release Candidate）＝重大な不具合が出なければそのまま製品になる版」を置く例もあります。

プロトタイプからマスターアップまでの6つのマイルストーンを階段で示し、各段で確かめることと、αROM・βROM で追加を止める例を添えた図 — 図2：段ごとに確かめることが違う。到達条件は会社や契約で決める

夕宮たいだ

ほよ？ αROM の「ROM」って、カートリッジ時代の名残なんだぁ。ダウンロードで売る今でも、呼び方だけ残ってるんだねぇ。

企画：何を作るかを決める

ひとことで：一言で言える面白さを決め、小さく試して確かめ、作れる規模と道具を決める段階です。

ゲーム企画（コンセプトとコアループ）

コンセプトは「一言で言える面白さ」、コアループは「プレイヤーが何度も繰り返す行動の輪」です（例：ローグライクのアクションなら「探索→戦闘→強化→また探索」）。誰に向けるか、似た作品と何が違うか、作りきれる規模か（スコープ）もここで考え、1枚の企画書にまとめます。似た作品は Steam のタグやユーザーレビューで調べられます。詳しくは「ゲーム企画の立て方」へ。

プロトタイプ

遊びが成立するか（作るべきか）を確かめる、使い捨ての試作です。確かめる問いを1つに絞り（例：「敵の弾を跳ね返すアクションは、3分遊んで楽しいか」）、期間を区切って作ります。カードゲームなら紙で作ってもかまいません。結果を見て、続ける・変える・捨てるを決めます。詳しくは「ゲームのプロトタイプとは」へ。

GDD（仕様書）

GDD（ゲームデザインドキュメント）は、ゲームの設計をまとめた文書です。決まった型はなく、日本では「企画書」（提案・合意用）と「仕様書」（実装用）に分けて呼ぶこともあります。一度書いて終わりではなく、開発中に更新し続けます。詳しくは「ゲームデザインドキュメント（GDD）の書き方」へ。

スケジュールとマイルストーン

作業をタスクに分けて見積もり、マイルストーンを置き、予備の時間（バッファ）を確保します。多い失敗は、作る範囲が後からじわじわ広がる「スコープクリープ」です。必須と「あれば良い」を分け、削る基準を先に決めておきます。詳しくは「ゲーム開発のスケジュールとマイルストーン」へ。

ゲームエンジンと開発環境

Unity・Unreal Engine・Godot・RPGツクール・ティラノスクリプトなどのゲームエンジン（ゲーム作りの土台になるソフト）から、作るゲームに合うものを選びます。利用条件はエンジンごとに違います（例：Godot は無料ですが、ゲームのクレジットなどにライセンス表記が必要です）。あわせて、変更の履歴を残すバージョン管理（Git など）とバックアップを用意します。詳しくは「ゲームエンジンの選び方と開発環境」へ。

資金とパブリッシャー

自分で売るか（セルフパブリッシング）、パブリッシャーと組むかを考え始めます。パブリッシャーへの売り込みでは、企画書とバーティカルスライスが主な材料になります。詳しくは「インディーゲームの資金とパブリッシャー」へ。

プリプロダクション：作れるかを確かめる

ひとことで：ステージを仮組みして遊びと大きさを固め、一部分を製品版の品質まで作って、制作の基準を決める段階です。

グレーボクシング（ステージ仮組）

グレーボクシング（ブロックアウトとも呼ぶ）は、単純な形でステージを仮組みし、遊びと大きさを先に確かめる工程です。キャラの大きさや移動・ジャンプの性能と、それに合わせた通路・扉・段差の寸法ルール（メトリクス）を決め、遊んで直します。2Dのステージや、ノベルゲームの画面の仮組にも同じ考え方が使えます。詳しくは「グレーボクシングとは」へ。

バーティカルスライス

ゲームの一部分を製品版に近い品質まで作り、この品質で作れることを示す版です。品質の基準を決め、制作の流れを一度通して詰まる所を見つけ、残りの量の見積もりに使います。パブリッシャーへの売り込みにも使われます。作り込みすぎてプリプロダクションが終わらない、という罠もあります。詳しくは「バーティカルスライスとは」へ。

プロダクション：作りきる

ひとことで：決めた基準に沿って素材と機能を量産し、αROM で全体を通して遊べるようにして、遊んで直す段階です。

アセット制作

アセット（絵・3Dモデル・アニメーション・UI など、ゲームに入る素材）を一覧表（アセットリスト）で管理し、サイズ・形式・名前の規則を決めて作ります。最初は仮素材で組み、本番の素材に差し替えます。外注では発注書を書き、納品物を確かめて受け取り（検収）、必要なら直しを依頼します（リテイク）。詳しくは「ゲームアセット制作の流れ」へ。

BGM・効果音

場面ごとに必要な BGM と効果音を一覧にし、ループ・ファイル形式・音量の基準をそろえます。作曲の依頼・購入素材・生成AI のどれを使うかで、権利の確かめ方も変わります。詳しくは「ゲームのBGM・効果音の作り方」へ。

αROM（アルファ版）

主な機能がそろい、最初から最後まで通して遊べる段階です。仮素材が残っていても、全体の流れと遊びの量を確かめられることが大切です。α を区切りに新機能の追加を止めること（フィーチャーフリーズ）が多く、ここから先は「足す」より「直す・削る」が中心になります。詳しくは「αROM（アルファ版）とは」へ。

プレイテスト

他の人に遊んでもらい、意図どおりに遊ばれているかを観察して直す工程です。説明せずに見る、考えを声に出しながら遊んでもらう、アンケートと記録をとる、が基本です。不具合を探す QA とは目的が違います。詳しくは「プレイテストのやり方」へ。

バランス調整

難しさ・お金や資源の流れ（経済）・テンポ・確率などの数値を直す工程です。数値を表で管理し、1度に1つずつ変え、プレイテストとデータの両方で確かめます。CPU 同士を何百回も自動で対戦させて数字を測る方法もあります。詳しくは「ゲームバランス調整の進め方」へ。

ローカライズ（多言語対応）

ゲームを他の言語・地域向けに作り変える工程です。文章をプログラムの外に出す、フォントを用意する、訳すと伸びる文字数に備える、といった下準備（国際化）を早めに済ませ、翻訳の後はゲーム画面の中で訳文を確かめます（LQA）。詳しくは「ゲームのローカライズ（多言語対応）」へ。

仕上げ：出せる品質にする

ひとことで：機能と素材を固めて不具合を潰し、提出や審査を通せる完成品にする段階です。

βROM（ベータ版）

機能と素材がそろい、不具合の修正と調整が中心になる段階です。素材や文言の追加・差し替えを止め（コンテンツロック。コンテンツフリーズとも）、性能の最適化と、動作環境（遊べるパソコンの条件）の確認を進めます。オンラインゲームで一般の人に遊んでもらう「βテスト」とは別の意味です。詳しくは「βROM（ベータ版）とは」へ。

QA・デバッグ

QA（品質保証）は、テストの計画を立てて不具合を探し、報告し、直ったことを確かめる工程です。不具合は再現手順をつけて報告し、重さと優先度で並べます。直した後に他の所が壊れていないかを確かめる回帰テストや、自動テストも組み合わせます。詳しくは「ゲームのデバッグとQA」へ。

マスターアップ

製品版として確定し、量産や配信に回せる状態にする最終工程です。コンソールでは発売前にプラットフォーム側の認証（任天堂のロットチェックなど）を通し、Steam ではビルドの審査を受けます。版番号を決めて提出したビルドを保管し、発売日に配る修正（デイワンパッチ）が要るかも判断します。詳しくは「マスターアップとは」へ。

発売準備：届ける準備を並行で進める

ひとことで：ストアページ・宣伝・体験版・権利の確認は、開発と並行して早めに始める別の流れです。

Steam ストアページ

Steam で売るには、Steamworks（Steam の開発者向け管理サイト）に登録し、作品1本ごとに $100 の手数料（Steam Direct）を払って、ストアページを作ります。発売前のストアページは「近日登場」として公開し、新しい作品は発売前に最低2週間公開しておく必要があります（2026年10月時点）。詳しくは「Steamストアページの作り方」へ。

宣伝とウィッシュリスト

ウィッシュリスト（Steam の「欲しいものリスト」）に入れてもらうと、発売時や一定以上の割引時に Steam から通知が届きます。SNS・開発ログ・トレーラー・配信者やメディアへの紹介・イベントで、発売前から少しずつ知ってもらいます。詳しくは「インディーゲームの宣伝」へ。

体験版（デモ）

ゲームの一部を無料で遊べるようにした版です。Steam では本編と別のアプリとして作り、年3回開かれる体験版の祭典「Steam Next Fest」に参加する道もあります。どこまで遊ばせるか、セーブを本編に引き継ぐかを決めます。詳しくは「体験版（デモ）の作り方」へ。

権利と規約

素材・フォント・音楽のライセンス、使ったソフトの表記、タイトル名の商標、生成AI の利用規約と開示、年齢区分（レーティング）などを確かめます。素材を入れるたびに台帳へ記録しておくと、最後に慌てずに済みます。詳しくは「ゲーム開発の権利と規約」へ。

発売と運用：出してから続ける

ひとことで：価格と発売日を決めて出し、不具合対応とアップデートを続け、必要なら他の機種へ広げる段階です。

発売（リリース）

価格（地域ごとの価格や発売直後の割引）と発売日を決め、発売前のチェックリストを確かめます。Steam では審査が通っても自動では発売されず、管理画面のボタンを自分で押した時刻が発売時刻になります。完成前から売りながら作る「早期アクセス」という出し方もあります。詳しくは「ゲームの発売（リリース）手順」へ。

発売後の運用

急ぎの不具合修正（ホットフィックス）、アップデートの計画、レビューへの返信、コミュニティの運営、セール、追加コンテンツ（DLC）を進めます。一区切りついたら、うまくいったこと・いかなかったことを振り返る「ポストモーテム」を書き、次の作品に生かします。詳しくは「発売後のゲーム運用」へ。

移植とマルチプラットフォーム

別の機種（家庭用ゲーム機・スマートフォン・Web ブラウザ・Steam Deck など）で出すための作業です。入力・画面・性能・認証・年齢区分が機種ごとに違うので、移植しやすい作り方を最初から意識しておくと負担が減ります。詳しくは「ゲームの移植とマルチプラットフォーム」へ。

工程の言葉をまとめて引きたいときは、「ゲーム開発用語集」を辞書として使ってください。

工程は一直線ではなく並行する

ひとことで：開発の流れの横で、ストアページ・宣伝・体験版・審査の流れが同時に進むので、発売日から逆算して始めます。

工程を順に並べると一直線に見えますが、実際には複数の流れが同時に進みます。とくに Steam では手続きと審査に決まった待ち時間があり、完成してから準備を始めると発売日に間に合いません。2026年10月時点の公式ドキュメントでは、次のように決まっています。

項目	公式の条件（2026年10月時点）
Steam Direct（作品の登録）	1本ごとに $100。支払いから発売まで最低21日（2026年9月に公式ドキュメントが30日から書き換わった。紹介ページは30日のまま）
ストアページの審査	通常3〜5営業日。公開したい日の7営業日前までの申請を推奨
近日登場ページ	発売前に最低2週間公開する
ビルドの審査	通常3〜5営業日。ストアページを審査に出した後でないと申請できない
発売日の変更	予定日の2週間前を過ぎると変更できない
Steam Next Fest	年3回（2月・6月・10月）。1作品1回だけ。登録の締め切りは回ごとに告知（直近の回は開催の約6〜7週間前）

出典：Onboarding、Review Process、Coming Soon、Release Dates、Steam Next Fest

並行の代表的な例は次のとおりです。

ストアページと宣伝：遊べる画面を見せられるようになった頃（多くはプロダクションの途中）から始める。ウィッシュリストは近日登場ページの公開後にしか集まらない
体験版：βROM を待たずに準備する。範囲を決めて本編と同じ品質で切り出す作業が要り、Next Fest に出るなら締め切りから逆算する
翻訳：文言が固まる時期から逆算して発注し、仕上げの期間に画面での確認（LQA）を入れる
権利の確認：素材や道具を入れるたびに台帳へ記録する。最後にまとめると差し替えが間に合わない
内容の申告：Steam の Content Survey（年齢区分や生成AI の利用を申告する質問票）は、ストアページとビルドの審査より前に記入する

筆者の麻雀ゲーム「つみこめ！イカサマ魔法麻雀」でも、Steam 側は「$100 の登録→アプリの発行→ストアの審査→近日登場から発売まで最短2週間→ビルドの審査」と待ちが続きました。いちばん時間のかかる素材（カプセル画像・スクリーンショット・予告編）は、アプリの発行より前から並行して作り始めています。

夕宮たいだ

ぁぅ……「完成してからストアページ」だと、審査と2週間の待ちで発売日がずれちゃうんだよねぇ。発売日からの逆算、気をつけてねぇ。

個人・少人数の進め方の例

ひとことで：段階は大きな会社と同じでも、1人が複数の流れを持つので、段階の終わりの判断と並行の段取りがより大切になります。

個人・少人数では、企画・実装・絵・音・宣伝を同じ人が受け持ちます。工程の名前は同じでも、書類は軽く、判断は速くし、並行の段取りは自分で組みます。次の表は、1〜3人で2Dのアクションゲームを約1年で作る場合の例です。月数は説明のための目安で、業界の平均ではありません。作品の規模と、1日に使える時間で大きく変わります。

時期（例）	段階	主な作業	並行して進めること	終わりの目印
1〜2か月目	企画	コンセプト、プロトタイプ2〜3本、1ページの GDD、エンジンとバージョン管理	類似作の調査	続けるかを決める
3〜4か月目	プリプロダクション	グレーボクシング、1ステージのバーティカルスライス	残りの量の見積もり、外注先の検討	品質の基準が決まる
5〜8か月目	プロダクション	全ステージの素材と機能、プレイテスト	ストアページの公開、SNS と開発ログ	αROM
9〜10か月目	プロダクション〜仕上げ	バランス調整、ローカライズ、体験版	体験版の公開と宣伝	βROM
11〜12か月目	仕上げ〜発売	QA・デバッグ、Steam の審査	価格と発売日の決定、報道や配信者への案内	マスターアップ・発売

3か月で出す小さなパズルゲームなら、企画とプロトタイプを2週間に収め、プリプロダクションは「1面を完成品質で作る」だけに絞る、といった縮め方をします。一方、近日登場の2週間や審査の日数は、規模が小さくても縮みません。

規模の違う例も見ると、幅がつかめます。CEDEC2026 では、アナログのカードゲームを α（約2か月・カードの種類を決める）→β（約3か月・商品に近いカードセットで実戦テスト）→マスター（約3か月・バランスを調整して入稿できる状態に）と進めた例が紹介されました（GameBusiness.jp の記事）。大規模な開発の例では、Heather Chandler 氏の『The Game Production Handbook』（2009）が、2年の開発でファーストプレイアブルをコードリリース（出荷や審査に出せる版）の12〜18か月前、ベータを2〜3か月前に置いています（Wikipedia の解説による）。どちらも条件の違う例なので、月数ではなく、段階の順番と「何を確かめてから進むか」を借りてください。

AIゲーム開発の全体像

ひとことで：AI は「作る・試す・調べる」を速くしますが、何を作り何を捨てるかの判断と、外部の審査や待ち時間は速くなりません。

AIエージェントを使うと、多くの工程で手を動かす部分が速くなります。ただし工程そのものは消えません。どの工程も、人が決めること・人が確かめることが残り、むしろそちらが進み具合を左右するようになります。

工程ごとの早見表

段階	AI に任せやすいこと	人が決めること・確かめること
企画	類似作の調査の下書き、アイデアの叩き台を多数出す、企画書の体裁	何を面白いとするか、誰に向けるか、やらないこと
プロトタイプ	遊びの試作を数案、数値だけ変えた版を並べる	触って続ける・変える・捨てるを決める
仕様・スケジュール・環境	仕様の抜けの洗い出し、タスク分解の叩き台、ビルドとテストの仕組みづくり	優先度と削る範囲、締め切り、変更の記録（コミット）と公開の権限
プリプロダクション	グレーボックスの配置、バーティカルスライスの実装	この見た目・手触りで行くという品質の基準
アセット・音	画像や曲の初稿、規格の機械チェック、名前の付け替えや変換	絵柄と音の方向性、検収、権利
実装〜αROM	機能の実装、開発用のデバッグ機能、自動テスト	仕様どおりか、遊んで面白いか
プレイテスト・バランス	自動対戦での計測、指摘の再現と裏取り	どの指摘を採るか、難しさの狙い
ローカライズ	一次訳、未翻訳や文字あふれの検出	訳語の方針、母語話者による画面での確認
仕上げ〜マスターアップ	テストの大量実行、配布物の中身の検査	出してよいかの判断、版番号、提出
発売準備〜運用	説明文やタグ候補の下書き、翻訳、不具合の原因調査、パッチノートの下書き	作品の顔になる画像の選定、生成AI の開示、価格、公開のボタン

企画から発売と運用までの段階ごとに、AI に任せやすいことと、人が決める・確かめることを並べた図。下に、縮まない待ち（審査・近日登場の2週間・外注の納品） — 図3：AI で作業は速くなるが、決める・確かめる・待つは縮まない

重心は「作る」から「決める・確かめる・待つ」へ

試作が安くなるほど案が増え、選ぶ・捨てる判断が重くなります。実装が速くなるほど、遊んで確かめる時間と検収が進み具合を決めます。そして、Steam の審査や近日登場の2週間、外注した翻訳や音の納品、コンソールの認証といった外部の待ち時間は、AI を使っても縮みません。

筆者の開発でも同じでした。同じエンジンから派生させたカードゲームは複製から1本目の完成まで2日、ブラウザ版の「霧将棋」は依頼したその日に公開まで進みました。一方、麻雀ゲームを Steam に出す手続きは、前の節で書いたとおり登録と審査の待ちが続き、初回のストアの審査は「日本語の作品名が既定の欄にしか入っていない」「AI 利用の開示が薄い」の2点で差し戻されました。速さを決めたのは、AI の作業ではなく外部の手続きと人の判断です。

筆者の役割分担は、筆者が決める人（裁定・公開のボタン・変更の記録）、Claude Code が設計・実装・テスト・検収・文書、Codex が画像の初稿・翻訳の校正・試し遊び、です。たとえば先のカードゲームでは、Claude が20キャラ分の能力案に「通常のルールからの離れ具合」を○△×で付けた叩き台を出し、筆者が一括で裁定して、×の案はまとめて不採用にしました。

業界の調査の数字

GDC の「State of the Game Industry」2026年版（2026年1月発表・回答2,300人超）では、業務で生成AIツールを使う人は36%、生成AIが業界に悪影響を与えていると考える人は52%（同じ調査の2025年版では30%）でした。用途は調査・ブレスト（81%）、メールなどの日常業務とコード支援（各47%）、プロトタイピング（35%）の順です（GDC の発表）。

日本では、CESA（コンピュータエンターテインメント協会）の「ゲーム産業レポート2026」プレビュー版（2026年9月発刊）の開発者調査（有効回答1,349人・初めての調査）で、業務で生成AIを使う人は85.8%でした（CESA のお知らせ）。2つの調査は対象も聞き方も違うため、数字を並べて「日本の方が多い」「増えた」とは言えません。

AI でも省けない工程

プレイテスト：面白いか、意図どおりに遊ばれているかは、人が遊んで確かめる
品質の基準を決めること：バーティカルスライスで「この品質で行く」と決めるのは人
権利の確認と開示：Steam では、プレイヤーが触れる絵・音・文章などを生成AI で作った場合、Content Survey で申告する（コード補完など作業効率化のための利用は対象外。2026年10月時点の公式ドキュメント）
審査と待ち時間：手続きの日数は縮まらないので、逆算して並行で進める
公開の操作と最終責任：筆者は公開系の操作をすべて自分で行う。それでも、ブラウザ版のゲームのページを予約投稿したときに日付の設定を誤り、8本が約4分間公開されてしまったことがある

落とし穴と依頼文の例

AI 特有の落とし穴は、工程を問わず似ています。動くが仕様と違う、1か所直したら別の所が壊れる、画像の絵柄や体格が少しずつぶれる、テストが壊れたまま「合格」に見える、素材の権利や開示が漏れる、などです。筆者の麻雀ゲームでは、Codex に実際のビルドを遊ばせて指摘6件を受け取り、Claude がすべてをコードで裏取りしてから優先順に直しました。その過程で「実行時のエラーがテストの失敗に数えられていない」問題も見つかっています。

依頼文は、目的（Goal）・材料（Context）・守ること（Constraints）・完了の条件（Done when）を書くと、結果を確かめやすくなります。どの工程でも使える形の例です。

Goal: 2Dアクションの試作に、ジャンプの高さを切り替える設定を足す
Context: 仕様は docs/spec_jump.md。基準はジャンプの高さ3マス
Constraints: 既存のステージデータと素材は変えない
Done when: 2マス・3マス・4マスの3つの設定で起動して遊べ、
           自動テストがすべて通り、変更点の一覧が報告されている

書き方は「Claude Code プロンプト設計」と「Codexプロンプト設計」で詳しく解説しています。毎回伝える決まりごとは、指示書ファイル（「CLAUDE.md 完全ガイド」「Codex AGENTS.md完全ガイド」）にまとめておくと便利です。

夕宮たいだ

「AI があれば工程はいらない」は、絶対ダメだよ！速くなるのは手を動かす所だけで、決めるのと確かめるのは、ずっと人の仕事なんだぁ。

よくある失敗と対処

ひとことで：失敗の多くは、段階を飛ばすこと、基準を決めないこと、並行の流れを後回しにすることから起きます。

失敗	起きること	対処
プロトタイプを飛ばして本制作に入る	面白くないことに後で気づき、作り直しが高くつく	問いを1つに絞った試作で、先に確かめる
α・β の到達条件を決めない	「もうすぐ完成」が続き、締め切りが動く	到達条件を文章で決め、チームで合意する
作る範囲が後から広がる	いつまでも終わらない	必須と「あれば良い」を分け、フリーズの時期を決める
ストアページと宣伝を発売直前に始める	審査・近日登場の2週間・ウィッシュリスト集めが間に合わない	発売日から逆算し、プロダクションの途中から始める
体験版をβの後で考える	Next Fest などの締め切りを逃す	体験版の範囲を早めに決め、β より前から準備する
権利の確認を最後にまとめる	素材の差し替えや開示の漏れで審査が止まる	素材を入れるたびに台帳へ記録する
AI で作れる量に合わせて範囲を広げる	確かめる・直す量が人の手に余る	1日に確かめられる量に合わせて依頼を区切る