- Claude Code Game Studiosは49の専門エージェント、72のスラッシュコマンド、12の自動フック、39のドキュメントテンプレートで、Claude Codeの単一セッションをゲーム開発スタジオに変えるOSSテンプレート。★8,999(2026年4月13日時点)。
- エージェントは3層のスタジオ階層(Director → Department Lead → Specialist)で組織され、質問→オプション提示→ユーザー決定→ドラフト→承認の5段階プロトコルで動く。自律型ではなく構造型。
- Godot 4、Unity、Unreal Engine 5のエンジン別スペシャリストセットを搭載。hooksはコミット時にハードコード値やJSON妥当性を自動検証し、rulesはパス単位でコーディング規約を強制する。
参照元
出典: Donchitos/Claude-Code-Game-Studios(GitHub)
何を解決しているのか——単一セッションの「構造不在」問題
Claude Codeでゲームを作るときの根本的な問題は、チャットセッションに構造がないことだ。マジックナンバーをハードコードしても、デザインドキュメントをスキップしても、スパゲッティコードを書いても、誰も止めない。QAパスもなければデザインレビューもない。「これ、本当にゲームのビジョンに合ってる?」と問う人居ない状況で開発を進めることになる。
出典: Donchitos/Claude-Code-Game-Studios README
Claude Code Game Studiosはこの「構造不在」を解決する。1人のAIアシスタントに全てを任せるのではなく、49の専門エージェントがスタジオの階層構造を模倣し、ビジョンを守るディレクター、ドメインを所有するリード、手を動かすスペシャリストが協調する。
出典: Donchitos/Claude-Code-Game-Studios README
3層のスタジオ階層——Director、Lead、Specialist
エージェントの組織は実際のゲームスタジオの構造を反映している。
Tier 1 — Director(Opus): Creative Director、Technical Director、Producer。ビジョンの整合性と優先順位を管理する意思決定層。
Tier 2 — Department Lead(Sonnet): Game Designer、Lead Programmer、Art Director、Audio Director、Narrative Director、QA Lead、Release Manager、Localization Lead。各ドメインの品質と方針を所有する。
Tier 3 — Specialist(Sonnet / Haiku): Gameplay Programmer、Engine Programmer、AI Programmer、Network Programmer、UI Programmer、Level Designer、Sound Designer、Writer、UX Designer、Performance Analyst、DevOps Engineer、Security Engineer、QA Tester、Accessibility Specialist、Live-Ops Designer、Community Managerなど30以上の専任ロール。
出典: Donchitos/Claude-Code-Game-Studios README
この階層は単なる装飾ではない。各エージェントには明確な責任範囲、エスカレーションパス、品質ゲートが定義されており、ディレクター層がプロジェクト全体のビジョンとの整合を担保する。
エンジン別スペシャリスト——Godot 4、Unity、Unreal Engine 5
テンプレートには3つの主要エンジンの専用エージェントセットが含まれている。
| エンジン | リードエージェント | サブスペシャリスト |
|---|---|---|
| Godot 4 | godot-specialist |
GDScript、Shaders、GDExtension |
| Unity | unity-specialist |
DOTS/ECS、Shaders/VFX、Addressables、UI Toolkit |
| Unreal Engine 5 | unreal-specialist |
GAS、Blueprints、Replication、UMG/CommonUI |
出典: Donchitos/Claude-Code-Game-Studios README
プロジェクトのエンジンに合わせてエージェントセットを選択する設計で、汎用的なアドバイスではなくエンジン固有のAPIやベストプラクティスに基づいた支援を受けられる。
5段階のコラボレーションプロトコル——自律ではなく構造
このテンプレートの最も注目すべき設計は、エージェントの動作プロトコルだ。全エージェントは以下の5段階を遵守する。
- 質問する — タスクの前提を確認
- オプションを提示する — 2〜4の選択肢とメリット/デメリットを表示
- ユーザーが決定する — 常に人間が最終決定権を持つ
- ドラフトを示す — 最終化前に作業内容を提示
- 承認して書き込む — ユーザーの署名なしにファイルは書き込まれない
出典: Donchitos/Claude-Code-Game-Studios README
これは「自律型AIエージェントが勝手に開発を進める」アプローチとは正反対だ。構造と専門性を提供しつつ、決定権は常にユーザーにある。エージェントは構造と専門性を提供し、人間が舵を取る。
自動検証——hooksとrulesの2層構造
12のフックはセッションの各ライフサイクルイベントで自動実行される。
| 代表的なフック | トリガー | 動作 |
|---|---|---|
validate-commit.sh |
git commit前 | ハードコード値、TODOフォーマット、JSON妥当性を検査 |
validate-push.sh |
git push前 | 保護ブランチへのプッシュを警告 |
validate-assets.sh |
ファイル書き込み後 | assets/内の命名規則とJSON構造を検証 |
detect-gaps.sh |
セッション開始時 | 新規プロジェクトや欠落するデザインドキュメントを検出 |
出典: Donchitos/Claude-Code-Game-Studios README
11のルールはパス単位でコーディング規約を強制する。src/gameplay/**ではデータ駆動値とデルタタイムの使用を要求し、src/networking/**ではサーバー権威とバージョン付きメッセージを強制する。design/gdd/**では8セクション必須と数式フォーマットを、tests/**ではテスト命名とカバレッジ要件を定める。
出典: Donchitos/Claude-Code-Game-Studios README
72のスラッシュコマンド——全フェーズをカバー
スラッシュコマンドは7フェーズのワークフロー定義に沿って設計されている。
- オンボーディング:
/start/help/project-stage-detect/setup-engine - デザイン:
/brainstorm/design-system/map-systems/quick-design - スプリント管理:
/create-epics/create-stories/sprint-plan/estimate - 実装:
/dev-story/prototype - 品質保証:
/code-review/qa-plan/smoke-check/regression-suite - チーム協調:
/team-combat/team-narrative/team-ui/team-release - リリース:
/release-checklist/launch-checklist/changelog/hotfix
出典: Donchitos/Claude-Code-Game-Studios README
設計思想——MDAフレームワークと自己決定理論
テンプレートの設計思想は、ゲームデザインの学術的フレームワークに基づいている。
- MDA Framework — Mechanics, Dynamics, Aestheticsの3層でゲームデザインを分析
- 自己決定理論 — Autonomy, Competence, Relatednessでプレイヤーの動機を設計
- Flow State Design — チャレンジとスキルのバランスで没入感を設計
- Bartle Player Types — 達成者、探検者、社会者、キラーでオーディエンスを設計
- Verification-Driven Development — 実装前にテストを書く開発手法
出典: Donchitos/Claude-Code-Game-Studios README
読み解くべき論点
このテンプレートを導入するかどうかは、以下の3点で判断したい。
エージェント数は最適か — 49エージェントは瞩目的だが、Claude Codeのコンテキストウィンドウとトークン消費を考えると、全エージェントを同時稼働するのは現実的ではない。実際には
/startがプロジェクトの段階を検出し、必要なエージェントのみを呼び出す設計になっている。トークン消費の実効性は運用次第。Opus層のコスト — Director(Creative Director、Technical Director、Producer)はOpusモデルを前提としている。SonnetやHaikuに比べて単価が高く、頻繁に呼び出すとコストが積み上がる。レビュー強度は
full/lean/soloの3段階で調整可能。テンプレートとしての拡張性 — ロックされたフレームワークではなく、エージェントの追加・削除、スキルの修正、ルールの追加が可能。独自のゲームドメインに合わせてカスタマイズする前提で設計されている。
MITライセンスで公開されており、git clone して /start を実行するだけで使い始められる。
引用元・参考リンク
免責事項 — 掲載情報は執筆時点のものです。料金・機能は変更される場合があります。最新情報は各公式サイトをご確認ください。