Claude Media
Claude Codeでゲームジャムの48時間を回す — 範囲の切り方と毎時間のコミット

Claude Codeでゲームジャムの48時間を回す — 範囲の切り方と毎時間のコミット

ゲームジャムの48時間でClaude Codeを使うとき、開始時の範囲固定、動くものを先に作る指示、毎時間のコミット、提出前のビルド確認までを手順にまとめます。

ゲームジャムで時間を失う原因の多くは、コードの書き方より「何を作るか」が膨らむことと「最後に動かない」ことです。Claude Codeは速く書けるぶん、範囲が膨らむ速度も上がります。この記事は、48時間を「範囲の固定」「動くものを先に作る」「毎時間のコミット」「提出前の確認」に分けて回す手順です。

使う道具は、plan mode、CLAUDE.md、ビルドを強制するStop hook、/rewind、worktree、提出前の/verifyと/code-reviewです。

48時間の時間割を先に決める

最初に決めるのは、時間ごとの目標です。下は一例で、締め切りから逆算して置いています。

あゆみ

48時間の配分例

  1. 0〜3時間範囲を固定する

    お題を決め、遊びの核を1文にして、作らないものを書き出します。

  2. 3〜12時間動く最小版を作る

    見た目は仮のままでよく、起動して操作でき、終わりまで到達できる状態を目指します。

  3. 12〜36時間面白さを足す

    最小版を遊び、効きの薄いものを削って、効くものだけを足します。

  4. 36〜44時間仕上げと機能凍結

    新しい機能は入れず、バグ取りと説明文、音量などの調整に回します。

  5. 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. 1

    ビルドと起動を通す

    CLAUDE.mdのBuildとRunを実行し、動くことを確かめます。

  2. 2

    動く状態をコミットする

    「Claudeにコミットして」と頼むか、自分でgit commitします。メッセージは何が遊べるようになったかを1行で。

  3. 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を試すと、設定でつまずいて時間を失います。

  1. 空のリポジトリで、起動、ビルド、コミットの3つが通るテンプレートを作る
  2. CLAUDE.mdのCommandsを、使うエンジンの実際のコマンドで埋めておく
  3. Stop hookを入れ、わざとビルドを壊して、Claudeが直しに戻るのを確かめる
  4. /rewindを1度使い、どこまで戻るかを実際に見ておく

ジャムによっては規約でAIの利用を制限しています。参加前に規約の該当箇所を確かめておくと安心です。

まとめ

48時間を回すコツは、速さを足す前に、範囲と確認の仕組みを先に置くことです。SPEC.mdで作らないものを決め、最小版を縦に1本通し、毎時間コミットして、提出ビルドを提出と同じ手順で確かめる。この4つが、Claude Codeの勢いで範囲が崩れるのを防ぎます。

参照した一次ソース

この記事の記述は、次の一次ソースと照合しています。更新時に参照先が変わった場合は一覧も更新します。

  1. code.claude.com/docs/en/best-practices
  2. code.claude.com/docs/en/common-workflows
この記事を共有:XはてブLinkedIn