game-studio-harness

ゲームスタジオ・ハーネス

プロデューサーが統括する5エージェント体制で、ゲーム制作サイクル全体を進行します。bmad-gds メソッド（インテークブリーフ → 1つの運用モード → 調整用成果物 → 専門担当へのルーティング → マイルストーンスレッド）に従い、数値による品質ゲートを設けます。 このハーネスは常設の体制です。ゲームがリリースされるまでサイクルを繰り返し、ライブ運用中も継続します。

実行を開始する前に、references/quality-gates.md、references/stage-cycle.md、references/artifact-contract.mdを読んでください。 references/quality-gates.mdのゲートしきい値は、このガイドの言い換えより優先されます。

このスキルを使う場面

• アイデア、GDD、プロトタイプ、または既存ビルドから新しいゲーム制作サイクルを開始する
• 進行中のサイクルを再開する（最初に_workspace/current/production/task-manifest.mdを読む）
• 現在のビルドでステージゲートレビュー（G1～G8の判定）を実施する
• プレイテストのフィードバック、不具合、マイルストーンのプレッシャーが重なった際に優先順位を再調整する
• ゲーム制作／バランス調整／収益化／QAのサイクルを1つのチームで回す

範囲の狭いタスクは、それぞれ専用のスキルに振り分けてください。ビルド／ログの障害対応 → game-build-log-triage、プロファイラーのキャプチャ → game-performance-profiler、フィードバックのみのトリアージ → game-demo-feedback-triage、ストアページ／ローンチ運用 → steam-store-launch-ops、プリプロダクションのアイデア出し → bmad-idea。

チーム

役割	テンプレート	担当範囲
game-production-director	templates/agents/game-production-director.md	インテーク、タスクマニフェスト、ゲート判定、裁定、振り返り
game-designer	templates/agents/game-designer.md	バランスシート、コンボマトリクス、コアループ、新規性スコアカード、世界観、演出仕様、トレンド調査
game-pm	templates/agents/game-pm.md	収益マップ、報酬帯（復帰率 ≤30％、無料／有料の同等性は10～20セッション、勝率差 ≤5％ポイント）、交渉記録、収益予測
game-programmer	templates/agents/game-programmer.md	アーキテクチャ契約、パフォーマンス予算（p95 ≤16.7ms、入力 ≤100ms）、移動経路の最適化、技術検証、テレメトリ、不具合への対応
game-qa	templates/agents/game-qa.md	アーキタイプのローテーション（5種類以上）、エクスプロイト登録簿、ベンチマーク調査、ゲート測定、不具合／リグレッション登録簿

コミュニケーションの構成：ディレクターが割り当てとゲート判定を行います。QAはエクスプロイトや発見事項をすべてのエージェントに共有し、フィードバックを求めます。デザイナーとPMは、報酬と収益の相互関係を署名済みの記録で交渉します。プログラマーはサイクル内ですべての不具合に回答し、fixedまたはdeferredとその理由を示します。

手順

ステップ0：準備

理由：すべての成果物を追跡可能にする必要があり、ワークスペースに存在できるライブフォルダーは1つだけです。

1. 対象リポジトリのルートに_workspace/current/{intake,design,pm,engineering,qa,ops,ui,production,messages,retrospectives}/を作成します。日付入りの実行ディレクトリは作成しないでください。run-id（{YYYYMMDD}-{cycle-label}）はドキュメント内に記録する値であり、アーカイブ時（_workspace/archive/{run-id}/）にのみディレクトリ名になります。
2. 再開する場合は、_workspace/current/production/task-manifest.mdと直近の振り返りを読みます。ステージ1ではなく、記録されたステージから開始してください。
3. サイクル終了時に、置き換え対象となったレーンの成果物をgit mvで_workspace/archive/{run-id}/に移動します。_workspace/内の成果物は決して削除しないでください。

ステップ 0.5：リポジトリのルールファイルを作成する

理由：ハーネスが適用されるのは、それを実行するセッションのみです。スタジオが学んだすべての内容――担当レーン、エンジンとの境界、各アセットクラスを担当するジェネレーター、Git の安全プロトコル――は、今後のすべてのセッションが必ず読む場所に書き残さない限り、このセッションが終わった瞬間に失われます。

1. templates/repo-rules.md を対象リポジトリのエージェント指示ファイル（Claude Code では CLAUDE.md。Codex／Gemini／OpenCode 用には、2つ目のコピーではなくポインターとして AGENTS.md にも反映します。契約が2つあると内容にずれが生じ、ずれた契約は契約がないよりも悪いためです）にコピーします。
2. すべての {PLACEHOLDER} を実際のリポジトリに照らして置き換えます。プレースホルダーが残っている場合は不備です。該当しないセクションは削除します。誰も守らないルールは、今後のセッションに「ルールは任意だ」と教えることになります。
3. 違反したくなるルールや、違反のコストが見えにくいルールには、その理由を併記します。Never rename X は無視されますが、X の名前を変更すると既存プレイヤー全員のセーブデータが孤立する なら守られます。
4. 実行開始時だけでなく、各サイクルの終了時にもルールを見直して導き出します。ルールファイルはサイクルごとの成果物です。current/ にレーンが追加されたとき、ジェネレーターが置き換えられたとき、あるいは苦労して見つけた不変条件があるときは、更新するまで内容が古いままです。

ステップ 1：チームを用意する

理由：セッション間でエージェントを再利用できるよう、エージェントはファイルベースにする必要があります。

• CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1 を使用する Claude Code の場合：templates/agents/*.md を対象リポジトリの .claude/agents/ にコピーします（ファイルがすでに存在し、一致している場合はスキップします）。その後、TeamCreate + SendMessage + TaskCreate/TaskUpdate を使用します。
• その他のランタイム（Codex、Gemini、OpenCode）またはチーム機能が無効の場合：references/stage-cycle.md に記載されたフェーズ順に、同じ役割を順次サブエージェントとして実行します。ピア間のメッセージは _workspace/current/messages/{seq}-{from}.md 内の番号付きファイルにします。

ステップ 2：インテーク（ディレクター）

リクエストを intake/production-brief.md に正規化します（bmad-gds スキーマ：game_type、team_shape、engine、current_stage、next_public_beat、source_packet、main_constraint、main_question）。サイクルで使用する運用モードを1つ選び、次の公開ビートを明示します。

ステップ 3：3段階の運用サイクルを実行する

references/stage-cycle.md に厳密に従います。概要：

• ステージ 1 — コンセプト、プレゼンテーション、アニメーション、リソース、コアビルド： デザイナー（コンセプト＋世界観＋数値の骨格＋survey スキルによるトレンド調査＋コアループ候補＋プレゼンテーション仕様）∥ PM（収益ポイントの草案）∥ QA（ベンチマーク調査＋テスト計画＋アーキタイプセット）。 続いてデザイナー↔PM の交渉ラウンド1を行い、その後プログラマーがコアループ＋プレゼンテーション／アニメーション＋リソースマニフェスト＋テレメトリー草案を作成します。 ゲート：G7 草案、G1 草案、G6-ops 草案。
• ステージ 2 — バランス調整、コアループの安定性、新規性の開発： QA がアーキタイプ全体でエクスプロイトを調査 → デザイナーが再調整 → PM が報酬帯を調整 → 交渉ラウンド2 → プログラマーがデータのみの変更を適用 → QA が再検証します。 ゲート：G2、G3、G5、G7 最終版、G8。
• ステージ 3 — 運用の安定性とプレイへの影響（演出／シナリオ／エフェクト）： プログラマーがパフォーマンス、メモリ、移動を最適化し、運用を強化 ∥ デザイナー＋プログラマーがプレゼンテーション／シナリオ／エフェクトの影響を確認 ∥ QA が全面的な回帰テストと没入度評価を実施 ∥ PM が収益の一貫性を予測します。 ゲート：G4、G6 最終版、G1 最終版。

ゲートの判定は PASS／FIX（修正ループは2回以下）／REDO（前のステージに戻る）です。 S1 の未解決の不備、または証拠の不足がある場合、PASS にはできません。

ステップ 4：サイクル終了（ディレクター）

1. retrospectives/cycle-{n}-retrospective.md を作成します。ゲートごとの測定値、未解決のリスク、次のサイクルへの移行判断（ステージ 1 のコンセプト転換か、ステージ 2 の再調整か）を記載します。
2. このサイクルでレーンを変更した、ジェネレーターを置き換えた、または適用すべき不変条件を発見した場合は、リポジトリルールファイルを再導出します（ステップ 0.5）。
3. 旧レーンの素材を git mv で _workspace/archive/{run-id}/ に移動します。current/ に残すのは次のサイクルに引き継ぐものだけです。_workspace/ の外に出してはいけません。

サイクルは繰り返されます。スタジオは一度限りのパイプラインではなく、常設の仕組みです。

ステップ 5：エラー処理

シナリオ	対応
エージェントのタイムアウト	1 回再試行 → タスクを failed としてマークし、部分的な状態で続行して、ゲートレビューでフラグを立てる
データの競合	conflicts.md に記録し、より新しい測定値を優先して、ディレクターが数値に基づき裁定する
出力の欠落	ゲートは PASS にできません。レビューで警告します
メッセージ送信の失敗	messages/ を介したファイルベースの代替手段を使用します

例

例 1：アイデアから新しいサイクルを開始する

入力：「ダークファンタジー RTS アイデアでゲーム制作サイクルを開始して」 期待される結果：run-id が作成され、制作概要が記述され、チームが編成されて、 ステージ 1 のタスクが割り当てられます。デザイナーのトレンド調査と QA のベンチマーク調査が survey スキルを使って実行されます。サイクルはレトロスペクティブと G1–G8 のゲート表で終了します。

例 2：既存ビルドのステージゲートレビュー

入力：「現在のビルドでステージゲートレビューを実行して」 期待される結果：QA がビルドで G1–G8 を測定し、ディレクターが根拠となるパスとともに ゲートごとの PASS/FIX/REDO 判定を出し、FIX 項目はマニフェストタスクになります。

例 3：バランス調整の緊急対応

入力：「QA が無限コンボのエクスプロイトを発見、サイクルに再参加」 期待される結果：エクスプロイト登録簿を事前に用意したうえで、ステージ 2 フェーズ 2a から開始します。 デザイナーが再調整し、PM が報酬の連動を確認し、プログラマーがデータのみを変更し、 QA がゲート終了前に対象範囲を再検証します。

ベストプラクティス

1. 1 サイクルにつき運用モードは 1 つにします。コンセプト作業とローンチ運用を 1 回のサイクルで混在させると、どちらも弱まります。
2. すべての判定は数値で行います。形容詞だけでゲートを通過することはありません（references/quality-gates.md）。
3. 発想の前に調査を行います。デザイナーのトレンド調査と QA のベンチマーク調査はステージ 1 の必須条件であり、任意の飾りではありません。
4. _workspace/ の成果物を保持します。成果物はサイクルをまたぐスタジオの記憶です。削除せず、アーカイブしてください。
5. ルールファイルは、スタジオにとって唯一の永続的な出力です。ビルドを出荷しても契約を残さないハーネス実行では、次のセッションに何も伝わりません。
6. マイルストーンの流れを維持します。すべてのタスクに、それが支える次の公開上の節目を明記します。
7. QA の情報共有を徹底します。すべてのエクスプロイトや発見を、明示的なフィードバック依頼とともに全エージェントへ共有します。QA の知見はスタジオ全体の知見です。

参考資料

• 品質ゲート G1–G8
• ステージサイクルの詳細
• 成果物の契約
• リポジトリルールファイルのテンプレート