ゲーム開発のスケジュールとマイルストーン｜AI個人開発のスコープ管理

「いつ発売できるのか」「いまどこまで進んでいるのか」。この2つに答えるのがスケジュールです。ゲーム開発では、作業を日付に並べた予定表に加えて、「この日までにこの状態にする」という節目（マイルストーン）を置き、節目ごとにゲームを遊んで確かめながら進めます。工程の中では、企画とプロトタイプで作るものが見え、仕様書（GDD）を書いたあと、全体の予定を組む段階です。全体の流れは「ゲーム開発の全工程マップ」で確認できます。

本記事では、個人〜少人数のインディーゲームを例に、マイルストーンの置き方、見積もり、バッファ（予備の時間）とスコープ（作る範囲）の管理、削る判断、進捗管理、Steam の審査のような外部の待ち時間の組み込み方を解説し、AI エージェントで作る場合の変化もまとめます。Steam の規則と日数は2026年10月時点の公式ドキュメントによるもので、変わることがあります。

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

ひとことで：作るものを「いつまでに・どの状態にするか」の節目で区切り、遅れと問題を早く見つけるための計画です。

スケジュールは作業と日付を並べた予定、マイルストーンはその途中に置く節目です。節目には「何ができていれば通過か」という到達条件を決めておき、その時点のゲームを実際に遊んで判定します。予定表が「いつ何をするか」を示すのに対して、マイルストーンは「このまま進めてよいか」を判断する場所です。

ゲーム会社では、マイルストーンは社内の承認や、パブリッシャー（販売元）との開発契約の支払い条件と結びついています（ゲーム専門の弁護士 Tom Buscaglia の解説。Game Developer、2005年）。定義に業界で統一された基準はなく、会社や案件ごとに違います。個人開発では、節目を自分で決めて守ります。

置く目的は4つです。遅れを取り返しがつくうちに見つけること、続ける・変える・削る・やめるを決める日を先に作ること、審査や外注の納期のような動かせない日付に間に合わせること、仲間やパブリッシャーに現状と見通しを示すことです。

工程の区分と主なマイルストーン

ひとことで：開発を「プリプロダクション→プロダクション→仕上げ」に分け、その間にプロトタイプからマスターアップまでの節目を置きます。

3つの区分

区分	ひとことで	主な工程
プリプロダクション	作るべきか・作れるかを、企画と試作で確かめる段階	企画・プロトタイプ・仕様書、グレーボクシング（ステージ仮組）、バーティカルスライス
プロダクション	本制作（量産）の段階	素材と機能の量産、αROM（アルファ版）、プレイテスト、バランス調整、ローカライズ
ポストプロダクション（仕上げ）	発売前の仕上げの段階	βROM（ベータ版）、QA・デバッグ、マスターアップ

ポストプロダクションは資料によって意味が割れている言葉です。この連載では「βROM からマスターアップまでの、発売前の仕上げ」の意味で使いますが、資料によっては発売後の運営や開発の振り返りを指すこともあります。連載の記事は、企画からスケジュールまでを「企画」、ステージの仮組とバーティカルスライスを「プリプロダクション」として分けています。ストアページ・宣伝・体験版などの発売準備は、これらと並行して早めに始めます。

プリプロダクションは試して捨てることが中心で、予定どおりに進まないのが普通です。予定の精度が上がるのは、「どう作るか」と「1つ作るのにどれだけかかるか」が分かってからです。

主なマイルストーン

名前と到達条件は会社やパブリッシャーとの契約で違うので、ここでは指すことが多い意味を示します。

節目	指すことが多い意味	この節目で決めること	詳しい記事
プロトタイプ	遊びが成立するか（作るべきか）を確かめる、使い捨ての試作	この遊びで作るか、変えるか、やめるか	プロトタイプとは
バーティカルスライス	ゲームの一部分を製品版に近い品質まで作り、この品質で作れることを示す版	品質の基準と、全体を作るのにかかる時間	バーティカルスライスとは
αROM（アルファ版）	主な機能がそろい、最初から最後まで通して遊べる段階	機能の追加を止める時期と、残りの量産の量	αROM（アルファ版）とは
βROM（ベータ版）	機能と素材がそろい、不具合の修正と調整が中心になる段階	中身の追加を止める時期と、直すバグの優先度	βROM（ベータ版）とは
マスターアップ	製品版として確定し、量産や配信に回せる段階	発売してよいか	マスターアップとは

αROM・βROM は、α版・β版の段階で提出・確認用に作るビルド（ROM）を、日本の現場でこう呼ぶことがある言い方です（カートリッジの ROM の名残）。「αROM＝全機能」のような決まった基準はないので、到達条件は自分のプロジェクトで書いて決めます。主要な遊びが初めて通しで動く版を「ファーストプレイアブル」と呼ぶこともあります（会社によってはアルファと同じ意味）。

会社での節目の使われ方

元 BioWare の Mark Darrah によると、BioWare ではアルファの宣言にチェックリストを満たす必要がありました（WN Hub、2022年）。CEDEC+KYUSHU 2023 の講演（Orange Butterfly 中山貴伯氏）では、試作で全体の予算の約10%、αで20〜25%、βで残りを承認する例が紹介され、節目が「次の予算を出すか」の関所になっています（4Gamer、2023年）。期間は規模で大きく違い、Chandler の書籍（2009年）の2年の開発の例ではファーストプレイアブルが提出版の12〜18か月前ですが（Wikipedia）、個人の作品には当てはめません。

個人開発での置き方の例

個人なら、節目ごとに「自分で遊んで判定する日」を予定に入れ、到達条件をチェックリストにします（例：2Dアクションの αROM なら「全ステージを最後まで通して遊べる。仮の素材は残ってよい」「セーブとロードが動く」）。次の表は、小さなパズルゲームを個人で作り Steam で出す場合の一例です。期間はジャンル・規模・経験で大きく変わります。

節目	時期の例（全体で約8か月の場合）	到達条件の例
プロトタイプ	開始から約1か月	中心のルールで遊べ、続けるかを決められる
バーティカルスライス	約2か月	1ワールド分が製品に近い見た目と音で遊べ、1問を作る時間が分かる
ストアページの公開	バーティカルスライスの後	実際のゲーム画面でスクリーンショットがそろう（Steam ではコンセプトアートは不可）
αROM	約5か月	全ワールドを通して遊べる（仮の素材あり）。ここで機能の追加を止める
βROM	約7か月	素材と文章がすべて本番。以降はバグ修正と調整だけ
マスターアップ	約8か月	発売するビルドが確定し、ビルドの審査を通る

タスク分解と見積もり

ひとことで：作業を「終わったかどうか判定できる単位」まで分け、見積もりは外れる前提で幅をもたせます。

タスクの分け方

タスク分解は、大きな作業を小さな作業に分けて一覧にすることです（プロジェクト管理では WBS＝作業分解構成図とも呼びます）。基準は「終わったかどうかが、見て判定できるか」です。「ジャンプを作る」では終わりが曖昧ですが、「ジャンプの高さを3マスにし、着地で音を鳴らす」なら判定できます。機能（何ができるか）と中身（ステージ・キャラ・文章などの量）の2つの軸で分けると漏れが減ります。

作るもの	分け方の例
2Dアクションの「ジャンプ」（機能）	仕様を決める → 動きを実装 → 当たり判定 → 効果音と演出 → 数値の調整 → 確認
ノベルゲームの「1章」（中身）	本文 → 立ち絵と表情の指定 → 背景 → BGM と効果音 → 演出の組み込み → 通しの読み合わせ

忘れやすいのは、作る作業の外側の仕事です。調整とバグ修正、素材や翻訳の検収、仮の素材の差し替え、ストアページの文章と画像・予告編・体験版、登録や税務の書類、書き出しと審査への申請も、最初からタスクに入れます。

見積もりは幅で出す

見積もりは約束ではなく予想で、初めて作る仕組みほど外れます。1つの数字だと外れたときに予定が崩れるので、幅で出します。

書くもの	意味	使い道
最短	すべてうまくいった場合	参考程度
ふつう	よくある詰まりを含めた場合	予定表に入れる
最悪	大きくつまずいた場合	節目の日付とバッファを決める

「ふつう」と「最悪」の差が大きい作業は不確実さが大きいので、本格的に作る前に小さく試してから見積もり直します。精度を上げるいちばんの材料は自分の実績で、見積もりと実際にかかった時間を記録しておくと、似た作業の見積もりが当たるようになります。

バッファとスコープクリープ

ひとことで：予定には予備の時間（バッファ）を持ち、途中で増える仕様（スコープクリープ）は優先度で入れるかどうかを決めます。

バッファの置き方

バッファは、見積もりの外れや急な問題に備える予備の時間です。タスクごとに少しずつ足すと、その余裕は使い切られがちです（「仕事は使える時間いっぱいまで膨らむ」というパーキンソンの法則。1955年の英エコノミスト誌）。予備はタスクに混ぜず節目の前にまとめて置き、残りを見える形にします。大きさは、決まった割合より、見積もりの「ふつう」と「最悪」の差から決めると根拠を持てます。

スコープクリープとは

スコープは「作る範囲」、スコープクリープは、開発の途中で予定になかった機能や中身が少しずつ足されて全体が膨らむことです。足した機能には調整・テスト・翻訳・ストアの記載の修正が付いてきて、終盤の予定を押し出します。防ぎ方は、アイデアを捨てることではなく、入れる手続きを決めることです。

• 思いついたアイデアは「あとで検討する一覧」に書き、その場では作らない
• 一覧は節目でまとめて見直し、入れるなら優先度を付ける
• 1つ入れるなら、同じくらいの量を外すか、予定を延ばすかを同時に決める
• 「αROM の後は新しい機能を足さない」のように、追加を止める時期（フリーズ）を決めておく

優先度の付け方

機能や中身には「必須」「あれば良い」「入れない」の3段で優先度を付けます（ソフトウェア開発には Must・Should・Could・Won’t の4段に分ける MoSCoW 法もあります。1994年に Dai Clegg が考案）。大事なのは「入れない」を書き残すことで、書かれていないと同じ議論が何度も起きます。

優先度	基準	2Dアクションの例	ノベルゲームの例	カードゲームの例
必須	これがないと成り立たない。ストアに書く約束	ジャンプと攻撃、全ステージ、セーブ	全ルートの本文と選択肢、セーブ	1つのルールでの CPU 対戦
あれば良い	なくても成り立つが、あると満足度が上がる	ボスの第2形態	回想モード	対戦の記録
入れない（今回は）	範囲に入れない。発売後や次回作で検討	オンライン協力プレイ	フルボイス	オンライン対戦

削る判断の基準

ひとことで：コアの面白さへの効き目・かかる時間・不確実さ・他への影響・外への約束の5つで、残すものと削るものを決めます。

遅れたときの手は「締め切りを延ばす」「人を増やす」「範囲を削る」のどれかで、個人開発では範囲を削る判断が最も多くなります。

基準	問い	削りやすいもの
コアの面白さへの効き目	外すと、中心の遊び（コアループ）は弱くなるか	中心の遊びと関係の薄い寄り道の要素
かかる時間	残りの時間に対して、得られる価値は見合うか	手間のわりに遊ぶ人の目に触れにくい所
不確実さ	まだ作り方が分かっていない部分はあるか	初めて作る仕組みで、見積もりの幅が大きいもの
他への影響	外すと、別の作業や機能が止まるか	他から頼られていない、独立した要素
外への約束	ストアページや告知で、すでに約束していないか	まだどこにも書いていないもの

「外への約束」は見落としやすい基準です。Steam では、ストアページには発売時に入っている機能だけを載せるよう求められ、ビルドの審査ではストアに書いた機能が入っているかも確かめられます（2026年10月時点）。削ったら、ストアページや告知も同時に直します。

削り方は全部捨てるだけではなく、数を減らす、発売後に回す（約束として告知はしない）、簡単な表現に置き換える、作ったものを残して最初に出す範囲を絞る、といった方法もあります。筆者が開発中のカードゲームでは、7種目を作ったうえで、最初の発売では一部の種目だけを出すことにしました。出す範囲は1つの設定ファイルで切り替えられ、作った種目を捨てずに発売の範囲だけを絞れます。

個人開発の進捗管理

ひとことで：週ごとの目標を決めて進み具合を見える場所に置き、毎週「予定との差」と「バッファの残り」を確かめます。

個人開発では、締め切りを決める人も守らせる人も自分です。週を単位に「今週終わらせること」を判定できる形で書き（例：「1章の立ち絵を全員分、本番の絵に差し替える」）、週の終わりに、終わらなかった作業、バッファの残り、遅れの取り戻し方（削る・延ばす・やり方を変える）を確かめます。

進み具合は、かんばん方式（タスクを「やること」「作業中」「確認待ち」「完了」の列に並べ、進むたびに右へ動かす方法）で見える場所に置きます。「確認待ち」の列があると、確かめていない作業の溜まりがすぐ分かります。

遅れを長時間労働（クランチ）で取り返す計画は、体調を崩した時点で全体が止まるので、個人ほど危険です。先に範囲を見直します。少人数のチームなら、誰の確認を誰が待っているかもかんばんに書いて共有します。

外部の待ち時間を逆算に入れる

ひとことで：審査・イベントの締め切り・外注の納期など、自分では縮められない待ちを、発売日から逆算して先に予定へ置きます。

Steam で発売するまでの待ち

Steam で発売する場合の主な待ちと締め切りです（2026年10月時点の Steamworks 公式ドキュメント）。

項目	内容
登録料（Steam Direct）	1本ごとに $100。支払いから発売まで最低21日（2026年9月に公式ドキュメントが30日から21日に書き換わった。Steam Direct の紹介ページは30日のまま）
税務情報の照合	第三者のサービスで照合され、10〜15営業日かかることがある
ストアページの審査	通常3〜5営業日。公開したい日の7営業日前までの申請を推奨
近日登場ページ	発売前に最低2週間、近日登場（Coming Soon）として公開しておく
ビルドの審査	通常3〜5営業日。7営業日は見込む。ストアページを審査に出した後でないと申請できない
発売日の変更	予定日の2週間前を過ぎると変更できない
Steam キー	初めて作品を出す開発者は、アプリの作成から3週間たたないと申請できない

逆算のしかた

• ① 動かせない日付を先に書く（発売日、イベントの締め切り）
• ② そこから、審査と待ちの日数を前へ並べる
• ③ 審査の差し戻しに備えて、出し直す分の余裕を入れる
• ④ 時間のかかる素材（カプセル画像・スクリーンショット・予告編）は、開発と並行して早めに作り始める

発売日の2週間前には発売日を動かせなくなり、その時点で近日登場ページが公開済みである必要があります。ストアページはその7営業日前を目安に審査に出し、ビルドの審査も発売日より前に通します。その前に登録料の支払いと登録の手続きがあります。これは規則上の最短で、ウィッシュリストを集める期間は別に考えます（「インディーゲームの宣伝」）。

Steam Next Fest の締め切り

Steam Next Fest は、体験版のある未発売の作品が参加できる年3回（2月・6月・10月）の催しです。参加は1作品1回だけで、条件の1つが「本編のストアページが公開されていること」です。登録の締め切りは開催の約6〜7週間前（回ごとの公式ページで告知）、体験版のビルド審査の提出期限は開催の3週間前です。

回	開催（米国太平洋時間）	登録の締め切り（同）
2027年2月	2027年2月22日〜3月1日	2027年1月10日
2027年6月	2027年6月14日〜21日	2027年4月25日

2026年10月の回の登録は締め切り済みです。出るなら登録の締め切りまでにストアページを公開しておくのが安全で、そこから登録料の支払い・税務の照合・審査を逆算します（体験版は「体験版（デモ）の作り方」）。

Steam 以外にも、外注の納品と直しの往復、展示会の応募、契約の書類、パブリッシャーの承認といった待ちがあります。締め切りの日だけでなく、検収・直し・承認にかかる日数まで予定に入れます。

AIゲーム開発でのスケジュール

ひとことで：AI で「作る」時間は縮んでも、「決める・確かめる・待つ」時間は縮まないので、そちらを予定の中心に置きます。

縮むのは「作る」時間だけ

AI エージェント（Claude Code や Codex のように、指示を受けてファイルの編集やコマンドの実行まで行う AI）を使うと、作業は大きく速くなります。筆者の場合、同じエンジンから派生させたカードゲームは複製から1本目の完成まで2日、派生の試作は1日で形になり、ブラウザ版の霧将棋は依頼したその日に公開できました。

一方で、発売までの日数を決めたのは AI の速さではありませんでした。つみこめ！イカサマ魔法麻雀では、登録料の支払い→アプリの発行→ストアページの審査→近日登場から発売まで最短2週間→ビルドの審査、と外部の待ちが続き、初回のストアページの審査は差し戻しになって、直して出し直してから通りました。そこで、いちばん時間のかかる素材（カプセル画像・スクリーンショット・予告編）は、アプリの発行より前から並行して作り始めています。

時間の種類	中身	AI で縮むか
作る	実装、素材の初稿、文章の下書き、テストの作成	大きく縮む
決める	何を作り何を削るか、品質の基準、公開してよいか	縮まない（判断の材料集めは速くなる）
確かめる	遊んで手触りを見る、素材や翻訳の検収、AI の報告の裏取り	縮まない（作る量が増えると増える）
待つ	ストアの審査、イベントの締め切り、外注の納期	縮まない

AI に任せやすい計画の作業

• 仕様書からタスクの一覧を起こす（機能と中身の2つの軸で、判定できる単位まで分ける）
• タスクどうしの依存関係を洗い出し、着手の順番の案を作る
• 発売日や Next Fest の締め切りから逆算した日付の表を作る
• 「あとで検討する一覧」を、必須・あれば良い・入れないに仮分けする
• 削る候補ごとに、影響する機能・素材・ストアの記載を洗い出す

AI が作った日付の表は、営業日の数え方・祝日・時差（Steam の公式の時刻は米国太平洋時間）を人が見直します。

人が決めること・確かめること

何を作り何を削るか、節目を通過したか（遊んで判定する）、発売日やストアの記載のような外への約束、審査の申請や発売のボタンのような取り消しのきかない操作は、人が決めます。筆者は「筆者＝決める人（裁定・公開のボタン・コミット）」「Claude Code＝設計・実装・テスト・検収・文書」「Codex＝画像の初稿・翻訳の校正・試し遊び」と分けています。

予定に「検収の時間」を積む

AI に頼んだ作業は、人が確かめて受け取った時点で完了にします。「確認待ち」が溜まり始めたら、新しい依頼を止める合図です。依頼の量は人が確かめられる速さに合わせ、直しの分も各タスクに見込みます。

並列で作業させるときの段取り

複数のエージェントに同時に作業させるときは、次の段取りを先に決めます（「Claude Code サブエージェント・並列作業ガイド」）。

• 境界を分ける：同じファイルや仕組みを、2つの作業が同時に触らないように割り振る
• 完了の条件をそろえる：それぞれに「何ができたら終わりか」と確かめ方（テストの合格など）を渡す
• 合流の時間を取る：別々に作ったものをまとめ、全体のテストを通す時間を予定に入れる
• 同時に走らせる数を決める：人が確かめられる量と PC の余力で上限を決める（「ゲームエンジンの選び方と開発環境」）

AI の見積もりと「作れてしまう」罠

AI に「何日かかるか」と聞いても、何を前提にした日数かは分かりません。人のチームが作る前提の日数が返ってくることもあり、決める・確かめる・待つ時間は AI からは見えません。見積もりは自分の実績（依頼してから確かめて受け取るまでの時間）で作り直し、人の作業と外部の待ちは別の行にします。

もう1つの罠は、作れてしまうことによるスコープクリープです。「ついでにこれも」が数分で形になりますが、足した機能にはテスト・翻訳・調整・ストアの説明・発売後の不具合対応がついて回り、その多くは人の確認を必要とします。「入れない」と決めた一覧を指示ファイル（CLAUDE.md や AGENTS.md）に書き、依頼文にも「依頼にない機能は足さない」と書いておくと、エージェントが気を利かせて機能を増やすのを防げます。

依頼文の例

発売日から逆算した表を作ってもらう依頼の例です（Goal・Context・Done when の書き方は「Claude Code プロンプト設計」「Codexプロンプト設計」）。

Goal: 発売予定日から逆算したスケジュール表を docs/schedule.md に作る
Context: タスクは docs/tasks.md、発売予定日は docs/release.md にある。
  Steam の待ち（2026年10月時点）：登録料の支払いから発売まで最低21日、近日登場は2週間以上、
  ストアページとビルドの審査は通常3〜5営業日（7営業日前の申請を推奨）
Done when: 各行に「作業・開始日・締め切り・人の確認日・根拠」がある。
  人の確認と外部の待ちは別の行にする。営業日の数え方や祝日で迷った所は「未確認」と書く

よくある失敗と対処

ひとことで：多くは「幅のない見積もり」「入れる手続きのない追加」「外部の待ちと人の確認の見落とし」から起きます。

失敗	原因	対処
見積もりが毎回外れる	1つの数字で見積もり、実績を記録していない	幅で見積もり、実績を記録して直す
終盤に作業が膨れ上がる	調整・バグ修正・ストアの作業が一覧にない	作る作業の外側の仕事も、最初からタスクにする
機能が増え続ける	アイデアを入れる手続きがない	「あとで検討する一覧」に書き、節目で判断する
発売の直前に審査で詰まる	外部の待ちを逆算していない	審査と待ちの日数を逆算し、差し戻しの分も入れる
Next Fest に参加できない	登録の締め切りや条件を見落とした	回ごとの公式ページを確かめ、ストアページを早めに公開する
AI の作業が確認待ちで溜まる	検収の時間を予定に入れていない	人が確かめられる量だけ依頼する

チェックリスト

ひとことで：予定を組んだら確かめる8つの項目です。

• [ ] 節目ごとに到達条件（何ができていれば通過か）を書いた
• [ ] タスクを判定できる単位まで分け、調整・検収・ストアの作業・事務も入れた
• [ ] 見積もりを最短・ふつう・最悪の幅で出し、実績を記録している
• [ ] バッファを節目の前にまとめて置き、残りを毎週確かめている
• [ ] 機能と中身に「必須・あれば良い・入れない」を付け、「入れない」を書き残した
• [ ] 発売日やイベントの締め切りから、Steam の審査と待ちの日数を逆算した
• [ ] 時間のかかる素材（カプセル画像・スクリーンショット・予告編）を早めに作り始めた
• [ ] AI に頼む作業には、検収と直しの時間を積んだ

次に読む記事

ひとことで：予定と関わりの深い工程の記事です。

• ゲーム企画の立て方：作れる規模（スコープ）を企画の段階で見積もる
• αROM（アルファ版）とは：機能の追加を止める節目の到達条件
• Steamストアページの作り方：近日登場ページの公開と審査
• ゲームの発売（リリース）手順：価格・発売日から発売のボタンまで
• Claude Code サブエージェント・並列作業ガイド：AI に並列で作業させる方法