Claude Codeでゲームジャムの48時間を回す — 範囲の切り方と毎時間のコミット
ゲームジャムの48時間でClaude Codeを使うとき、開始時の範囲固定、動くものを先に作る指示、毎時間のコミット、提出前のビルド確認までを手順にまとめます。
ゲームジャムで時間を失う原因の多くは、コードの書き方より「何を作るか」が膨らむことと「最後に動かない」ことです。Claude Codeは速く書けるぶん、範囲が膨らむ速度も上がります。この記事は、48時間を「範囲の固定」「動くものを先に作る」「毎時間のコミット」「提出前の確認」に分けて回す手順です。
使う道具は、plan mode、CLAUDE.md、ビルドを強制するStop hook、/rewind、worktree、提出前の/verifyと/code-reviewです。
48時間の時間割を先に決める
最初に決めるのは、時間ごとの目標です。下は一例で、締め切りから逆算して置いています。
48時間の配分例
- 0〜3時間範囲を固定する
お題を決め、遊びの核を1文にして、作らないものを書き出します。
- 3〜12時間動く最小版を作る
見た目は仮のままでよく、起動して操作でき、終わりまで到達できる状態を目指します。
- 12〜36時間面白さを足す
最小版を遊び、効きの薄いものを削って、効くものだけを足します。
- 36〜44時間仕上げと機能凍結
新しい機能は入れず、バグ取りと説明文、音量などの調整に回します。
- 44〜48時間提出ビルドの確認
提出物と同じ手順でビルドし、まっさらな環境で動かします。
配分の数字に根拠のある標準はありません。大事なのは、機能を入れてよい期限(上の例では36時間目)を自分で決めておくことです。期限を決めないと、Claude Codeに頼んだ追加が最後まで続きます。
開始時に範囲を固定する
企画をClaudeに詰めさせる
企画が曖昧なまま実装に入ると、後半で作り直しになります。まだ決めきれていないときは、Claudeに自分へインタビューさせ、仕様をファイルに書かせる方法があります。ジャムなら次のように頼めます。
お題は「境界」。48時間で作る2Dのブラウザゲームの企画を詰めたい。
遊びの核・操作・終わり方・作らないものが決まるまで、私にインタビューして。
決まったらSPEC.mdに書いて。実装はまだしない。返ってくるのは選択式の質問です。何が範囲外かまで問われます。答えがそろうとSPEC.mdができ、これがその後48時間の「完成の定義」になります。仕様ができたら、新しいセッションで実装を始めます。会話の履歴がきれいな状態で、書かれた仕様だけを頼りに始められるからです。
SPEC.mdに「作らないもの」を入れる
ジャムで効くのは、作るものより作らないものの一覧です。SPEC.mdには、次の3つを必ず入れます。
- 遊びの核を1文で(例: 壁を壊して進む)
- 提出時点で動いているべきこと(起動、操作、クリアまたはゲームオーバー)
- 作らないもの(オンライン対戦、セーブ、設定画面など)
凍結する機能のリストも、ここに書いておきます。Claudeはリクエストを控えめに解釈して最小のものを作る傾向があり、「be ambitious」と書けば、空状態やエラー状態まで含めた厚い実装になります。ジャムの序盤は逆に、範囲を狭く保ちたい場面です。「SPEC.mdの範囲内だけ作る。足したいものがあれば実装せず提案だけ出す」と書いておくと、勝手な追加を止められます。
実装前にplan modeで計画を見る
大きめの機能は、plan modeで計画だけを出させます。claude --permission-mode planで起動するか、セッション中にShift+Tabを押して⏸ plan mode onを表示させます。この間、Claudeはファイルを読んで計画を出しますが、承認するまで編集しません。
ジャムでは、計画の中の「新しく作るファイル数」を見ます。想定より多いときは、機能が重いサインです。見積もりを表にする使い方はplan modeで影響範囲を数える手順で詳しく書いています。
プロトタイプを先に動かす指示
最初の依頼は「縦に1本通す」
動く最小版を先に作ります。画面、操作、判定、終わりの4つを、見た目を仮のままで通します。依頼の例です。
SPEC.mdの範囲で、起動して操作でき、クリアかゲームオーバーまで行ける最小版を作って。
画像は四角形と色だけでよい。音も後回し。
作ったら実行して、動いた証拠として起動コマンドとその出力を見せて。最後の一文が重要です。合格か不合格かが返るものを渡すと、Claudeは自分で実行して直すループを回せます。完了の報告だけでなく、実行したコマンドとその出力も見せさせると確実です。
実行するコマンドをCLAUDE.mdに書く
毎回コマンドを説明しなくて済むよう、CLAUDE.mdには次の程度だけを書きます。CLAUDE.mdはコードから読み取れない内容に絞り、行数は200未満に抑えます。
# Commands
- Run: npm run dev
- Build: npm run build
- Typecheck: npx tsc --noEmit
# Jam rules
- SPEC.mdの範囲だけ実装する。範囲外は提案だけ出す
- 機能追加の前後で、必ず上のBuildを実行して通ることを確認する
- 1つ動く状態になるたびにgit commitするこれは例です。npmのコマンドは、使うエンジンやツールに合わせて置き換えてください。UnityやGodotなど、エディターからビルドする環境では、コマンドラインで通せるビルド手順があるかを先に確かめます。ここで確認しないと、チェックを自動で回す仕組みが成り立ちません。
CLAUDE.mdの行は、ほとんどの場合に従われますが、毎回とは限りません。typecheckを必ず通させたいなら、CLAUDE.mdではなくhookで強制します。
ビルドが通るまで終わらせない
ビルドを通すことを強制するなら、Stop hookが使えます。Claudeが応答を終えようとするたびにスクリプトを走らせ、終了コード2を返すと作業に戻らせる仕組みです。ビルドを通すまで終わらせない設定は次のとおりです。
{
"hooks": {
"Stop": [
{
"hooks": [
{ "type": "command", "command": "npm run build 1>&2 || exit 2" }
]
}
]
}
}これを.claude/settings.jsonに置きます。ビルドの出力は標準エラーへ回し、Claudeに返すためです。間にツール呼び出しを挟まずにブロックが8回続くと、次のブロックは上書きされてターンが終わります。ビルドに時間がかかるプロジェクトでは、毎ターン待つことになるので、数十秒で終わるときだけ使うのが現実的です。
毎時間のコミット運用
コミットは「動く状態」ごとに切る
コミットの単位は、時刻ではなく「動いた状態」です。ただ、1時間たったら必ず区切ると決めておくと、ジャム全体の見通しが立ちます。毎時間やることは次の3つです。
毎時間の区切り
- 1
ビルドと起動を通す
CLAUDE.mdのBuildとRunを実行し、動くことを確かめます。
- 2
動く状態をコミットする
「Claudeにコミットして」と頼むか、自分で
git commitします。メッセージは何が遊べるようになったかを1行で。 - 3
SPEC.mdの進み具合を更新する
済んだ項目に印をつけ、次の1時間の目標を1つ書きます。
コミットがなければ、壊れたときに戻る先がありません。
失敗した試行は/rewindか別worktreeで
新しい仕組みを試して壊れたときは、/rewind(または空の入力欄でEscを2回)でコードと会話を以前の状態へ戻せます。大胆な方法を先に試して、だめなら巻き戻せるので、試行のリスクは低くなります。
ただし注意が必要です。チェックポイントが対象にするのは、Claudeが自分のファイル編集ツールで編集したファイルです。Bashコマンドだけで変更されたファイルは復元されません。チェックポイントはgitの代わりにはなりません。毎時間のコミットは/rewindの代わりではなく、/rewindで戻せない部分を守る保険です。
並行して別案を試したいときは、worktreeを使います。
claude --worktree alt-mechanic別名で2つ目のターミナルから起動すれば、編集が衝突しない並行セッションになります。リポジトリに最初のコミットがあることが前提で、なければFailed to resolve base branch "HEAD"で失敗します。ジャムの開始直後に空のコミットを1つ作っておく理由の1つです。
長時間のセッションは分ける
48時間を1つの会話で通すと、履歴が膨らみます。無関係な作業の間では/clearを使い、/compactでは残す内容を指定できます。2回直しても直らないときは、3回目の修正を足さず、/clearして学んだことを入れた新しい依頼を書く手があります。睡眠や休憩をはさんで続ける場合は、/renameで名前を付けておけば、claude --resume 名前で戻れます。長時間運用の習慣もあわせて参照してください。
提出ビルドの確認チェック
最後の数時間は、機能を増やさず、提出物が動くかの確認に使います。確認の観点は5つです。
- 提出と同じ手順でビルドしたか(開発サーバーではなく、本番ビルドで動かす)
- まっさらな環境(別のフォルダーや別のPC)で起動したか
- 初見の人が説明なしで操作できるか(説明文に操作方法があるか)
- 必須のアセットがビルドに入っているか(画像や音が参照できているか)
- リポジトリにAPIキーや秘密が入っていないか
Claude Codeには、完了後に/verifyを実行する方法があります。アプリをビルドして実行し、結果を見るので、テストや型チェックでは拾えない問題を拾えます。ジャムの提出前は、これを1回は通します。
また、差分を別の目で見るには、/code-reviewが使えます。会話を知らない新しいサブエージェントがdiffを見るため、実装時の考え方に引きずられません。ただし、問題を探すレビューは必ず何かを見つけるため、全部直すと抽象化や不要なテストが増えます。提出前は「正しさに影響する問題だけ」「スタイルは無視」と範囲を絞ります。
最後の観点にある秘密の混入は、公開リポジトリで提出するジャムで起きやすい事故です。コミットしてしまった後の手順はシークレットをコミットした後の対応にまとめています。
本番前の予行演習
最後に、ジャムの前日までにやっておくと効く準備です。48時間の本番で初めてhookやworktreeを試すと、設定でつまずいて時間を失います。
- 空のリポジトリで、起動、ビルド、コミットの3つが通るテンプレートを作る
- CLAUDE.mdのCommandsを、使うエンジンの実際のコマンドで埋めておく
- Stop hookを入れ、わざとビルドを壊して、Claudeが直しに戻るのを確かめる
/rewindを1度使い、どこまで戻るかを実際に見ておく
ジャムによっては規約でAIの利用を制限しています。参加前に規約の該当箇所を確かめておくと安心です。
まとめ
48時間を回すコツは、速さを足す前に、範囲と確認の仕組みを先に置くことです。SPEC.mdで作らないものを決め、最小版を縦に1本通し、毎時間コミットして、提出ビルドを提出と同じ手順で確かめる。この4つが、Claude Codeの勢いで範囲が崩れるのを防ぎます。
参照した一次ソース
この記事の記述は、次の一次ソースと照合しています。更新時に参照先が変わった場合は一覧も更新します。