game-ci-cd-pipeline

ゲーム CI/CD パイプライン

一般的な DevOps の説明ではなく、次に選ぶべきゲームパイプラインの成果物が作業の中心となる場合に、このスキルを使用します。

game-ci-cd-pipeline は、実行ごとに関連する次の 2 つの質問に答える必要があります。

1. どのシグナル層／プロモーションレーンですか？
   • branch-gate — マージ／コミットを迅速に検証します
   • nightly-package-candidate — スケジュール実行または手動トリガーによる、時間のかかる QA／レビュー候補ビルドです
   • release-certification-candidate — 保護され、署名され、承認を多く必要とするリリースまたは認証候補です
2. この層で、次に作る最小かつ誠実な成果物はどのパケットですか？
   • パイプラインのセットアップ
   • ステージ分割
   • キャッシュポリシー
   • 事前チェックによる準備状況の確認
   • 成果物／リリースの衛生管理
   • CI シグナルの強化
   • またはログトリアージへの振り分け

パケットを選ぶ前に、以下を読んでください。

• references/intake-packets-and-route-outs.md
• references/pipeline-patterns.md
• references/signal-tiers-and-promotion-lanes.md

このスキルを使用する場合

• Unity または Unreal のチームが、過剰に複雑化することなく CI/CD を一からセットアップする必要がある場合。
• パイプラインが繰り返し不安定になったり、遅くなったり、不透明になったりしており、問題の本質が単独のログではなくワークフローの構造にある場合。
• ビルド、クック／パッケージ、キャッシュ、成果物、リリースの引き継ぎ手順が繰り返し失敗し、パイプラインへの信頼が損なわれている場合。
• チームがデモ／レビュー／リリースビルドを手動で出荷しており、最初の再現可能なパイプラインパケットが必要な場合。
• パブリッシャーのサポート担当者、請負業者、またはテクニカルリードが、簡潔なゲームパイプライン監査ブリーフを必要とする場合。

このスキルを使用しない場合

• 主な作業が、特定の Unity／Unreal ビルドログ内にある最初の対処可能な失敗の特定である場合 → game-build-log-triage
• 主な作業が、デザイン、QA、ビルドの負荷、ローンチ時期を横断するマイルストーン調整である場合 → bmad-gds
• 主な作業が、ランタイムのプロファイリングまたはフレーム時間のボトルネック診断である場合 → game-performance-profiler
• 主な作業が、Steam ページ／ウィッシュリスト／ローンチ時のストア運用である場合 → steam-store-launch-ops
• 主な作業が、一般的な Web／バックエンドリポジトリ向けのゲーム以外の CI/CD である場合 → 代わりにリポジトリの汎用 DevOps スキルを使用します。

手順

ステップ 1：まずシグナル層を分類し、次に主要なパケットタイプを 1 つ選びます

依頼を、シグナル層 1 つと主要なパケット 1 つに正規化します。

game_pipeline_packet:
  signal_tier: branch-gate | nightly-package-candidate | release-certification-candidate | unknown
  packet_type: pipeline-setup | stage-split | cache-policy | preflight-readiness | artifact-release | ci-signal-hardening | route-to-log-triage
  engine: Unity | Unreal | mixed | unknown
  ci_surface: GitHub Actions | Unity Build Automation | Jenkins | TeamCity | other | unknown
  target_platforms: Windows | macOS | Linux | Android | iOS | console | mixed | unknown
  release_context: prototype | internal QA | demo | playtest | certification | launch | live patch | unknown
  evidence_level: strong | partial | thin

シグナル層の意味：

• branch-gate — マージ／コミットを迅速に検証します。負荷の高いパッケージ処理は例外的なものにとどめます
• nightly-package-candidate — スケジュール実行または手動トリガーによる QA／レビュー／デモ候補ビルドで、通常のブランチ CI より負荷が高いものです
• release-certification-candidate — 保護され、承認を多く必要とし、署名済みで、ストアまたは認証機関向けの候補作業です

パケットの意味：

• pipeline-setup — 手作業が多すぎるチーム向けの、最初の再現可能なパイプライン計画です
• stage-split — リストア／ビルド／テスト／クック／パッケージ／公開を分離し、最初に失敗したステージを見えるようにします
• cache-policy — Library、Intermediate、Saved、DDC、またはパッケージキャッシュに関する場当たり的な判断をなくします
• preflight-readiness — 負荷の高いパッケージ処理の前に、SDK／署名／ツールチェーン／プラットフォームの前提条件を明らかにします
• artifact-release — 成果物の命名、保持期間、候補とリリースの明確な区別、QA への引き継ぎを改善します
• ci-signal-hardening — すべてを書き換えることなく、フィードバックの速度と信頼性を高めます
• route-to-log-triage — 依頼の大半が 1 つの失敗したビルド／ログに関するものであり、game-build-log-triage に移すべきです

ステップ 2：最低限の信頼できる根拠を集める

判断を正当化するために必要な、最小限の情報だけを集めます。

• エンジンとバージョン（判明している場合）
• 現在の CI の対象範囲、またはワークフローファイル
• 現在のトリガーの形態：PR／プッシュ、スケジュール／手動、保護されたリリースレーン、または不明
• 対象プラットフォームとリリースの状況
• 繰り返し発生する失敗パターン：コンパイル、パッケージ化、ツールチェーン、キャッシュ、アーティファクトの混乱、速度、または信頼性
• CI の完了後も手動で行っている作業
• 候補の昇格が問題に含まれる場合は、現在のアーティファクトの命名規則／保持期間、または承認ルール
• チームが特定の赤いビルドを繰り返し指摘している場合は、最近失敗したジョブ／ログを 1 件

根拠が乏しい場合は、確信度を低く保ち、見せかけの全面的な再設計ではなく、route-to-log-triage または範囲を絞ったパケットを優先します。

ステップ 3：シグナルのティアを明示的に選ぶ

パケットを提案する前に、どのレーンが問題を担当するかを判断します。

• branch-gate：PR／マージ検証が遅い、すべてのブランチで負荷の高いパッケージ化を行っている、または迅速なフィードバックが不十分という不満がある場合
• nightly-package-candidate：QA／レビュー／デモ用ビルドで、通常のブランチ CI の外部における、より負荷の高いパッケージ化、幅広い対象範囲、またはスケジュール／手動での昇格が必要な場合
• release-certification-candidate：承認作業が多い、署名が必要、ストア／認証に紐づいている、または通常の CI より厳格なアーティファクト保持が必要な場合
• unknown：入手できる根拠では、どのレーンかをまだ判断できない場合に限ります

ユーザーが複数のレーンを混在させている場合は、現在、信頼性のボトルネックになっているレーンを選び、ほかのレーンは後続の振り分け先として明記します。

ステップ 4：主な障害要因を分類する

主な障害要因を 1 つ選び、副次的な障害要因は多くても 1 つにします。

主な障害要因

• reproducibility-drift
• stage-boundary-blur
• dependency-cache-policy
• artifact-release-hygiene
• platform-toolchain-readiness
• feedback-speed-confidence
• single-log-not-pipeline
• unknown-needs-more-evidence

よくある対応づけ：

• 「あるマシンでは動くのに、CI では動かない」→ reproducibility-drift
• 「ワークフローが巨大なジョブ 1 つにまとまっていて、何が失敗したのか分からない」→ stage-boundary-blur
• 「通るまでキャッシュを削除し続けている」→ dependency-cache-policy
• 「QA がどのビルドが正しいのか、いつも分からない」→ artifact-release-hygiene
• 「Android／iOS／コンソール向けのパッケージ化が後半で失敗する」→ platform-toolchain-readiness
• 「ビルドが遅く、誰もシグナルを信頼していない」→ feedback-speed-confidence
• 「パッケージ化の失敗ログが 1 件ある」→ single-log-not-pipeline

ステップ 5：境界を確認する

助言を書く前に、レーンが適切か確認します。

1. これはパイプライン構造に関する質問ですか。それとも、単に失敗ログの問題ですか。
2. 選んだシグナルのティアは、実際のトリガー／承認／アーティファクトの問題に合っていますか。
3. 次に用意するのに最適な成果物は、上記のパケットの種類のいずれかですか。
4. 一般的な Web アプリの DevOps に逸れず、ゲームエンジンのパイプライン作業の範囲内にとどまっていますか。
5. エンジン固有の詳細は、入り口を複雑にするのではなく、診断に役立っていますか。

回答の大半が「失敗ログが 1 件ある」という内容なら、game-build-log-triage に振り分け、簡潔な引き継ぎパケットを残します。 回答の大半が「これは実際にはリリースゲートのポリシーに関する問題だ」という内容なら、ポリシーの判断は testing-strategies に振り分け、このスキルではゲームエンジンの実装の形に焦点を当てます。

ステップ 6：パケットの概要を作成する

次の正確な構造で返します。

# Game CI/CD Brief

## Packet choice
- Signal tier: branch-gate | nightly-package-candidate | release-certification-candidate | unknown
- Packet type: ...
- Engine: ...
- CI surface: ...
- Release context: ...
- Confidence: high | medium | low

## Evidence used
- Workflow / system context: ...
- Repeated failure pattern: ...
- Manual steps still outside CI: ...
- Gaps / assumptions: ...

## Primary blocker
- Bucket: ...
- Why it matters now: ...
- Evidence: ...

## Secondary blocker
- Bucket: ...
- Why it matters now: ...

## Recommended pipeline shape
1. ...
2. ...
3. ...

## Engine and platform checks
- Unity / Unreal specifics: ...
- SDK / signing / toolchain: ...
- Cache or artifact policy: ...

## Recommended next artifact
- Choose one: pipeline setup plan | workflow stage split brief | cache-key policy | platform preflight checklist | artifact/release checklist | CI-signal hardening plan | log-triage handoff packet

## Route-outs
- Skill: ...
- Why: ...
- Packet to pass: ...

## What not to do yet
- 1-3 bullets that avoid brittle rewrites or cargo-cult caching

Step 7: エンジンとシグナル階層に合わせてパケットを調整する

Unity の場合

• エンジン／エディターのバージョン固定に注意します
• Packages/manifest.json／ロックファイルの入力とプラットフォームモジュールが安定しているか確認します
• パッケージの復元、ビルド、テスト、パッケージ化の各ステージを分離します
• Library/ とパッケージキャッシュは、慣例的に削除するのではなく、明示的なポリシーとして扱います
• branch-gate では、迅速なコンパイル／テスト／スモークテストのフィードバックと、実行中の処理をキャンセルする動作を優先します
• nightly-package-candidate または release-certification-candidate では、候補の命名、ビルドターゲットのグループ化、署名、成果物の保持を明示します

Unreal の場合

• UBT/UHT、クック、パッケージ化、公開をそれぞれ別の工程として考えます
• プラグイン／モジュールのずれ、アセットリダイレクトの影響、AutomationTool の可視性を明確にします
• DDC／キャッシュに関する問題と、パッケージ化／ログを使った根本原因の調査を区別します
• 後工程で失敗する前に、プラットフォームのパッケージ化に必要な前提条件を明示します
• branch-gate では、プロジェクトのリスク上本当に必要な場合を除き、すべてのマージで完全なクック／パッケージ化が必須にならないようにします
• nightly-package-candidate または release-certification-candidate では、クック／パッケージ化にかかる時間、ターゲット固有の前提条件、公開／昇格のルールを明示します

Step 8: 不足している最小限のパケットを尋ねる

確信が持てない場合は、判断を左右する情報だけを求めます。

1. 現在のワークフローファイルまたはジョブの概要
2. トリガーの形態（PR／プッシュ、スケジュール／手動、保護されたリリースレーン）
3. エンジンのバージョンとターゲットプラットフォーム
4. 問題が single-log-not-pipeline の可能性がある場合は、最近失敗したジョブ／ログを1つ
5. 現在の成果物の命名／保持／承認のパターン
6. CI 完了後も手動で行っている作業

出力形式

常に短いゲームパイプライン概要を返します。

必須事項：

• シグナル階層を1つ、主要なパケットタイプを1つ選びます
• パイプラインの構造的な作業と、単発のログトリアージを分けます
• プラットフォーム全体の書き換えではなく、次に作る成果物を1つ推奨します
• ユーザーから追加の要望がない限り、300〜550語程度に収めます
• 優先順位が変わる場合は、リリース／デモの状況を明記します
• 回答が変わる場合は、候補の昇格／承認に関する実態を明確にします

例

例 1: Unity のキャッシュに関する思い込み

入力

Unity の GitHub Actions ビルドはローカルでは成功しますが、パッケージ更新後に失敗します。キャッシュを削除して、成功するまで再実行し続けています。

望ましい出力の方向性

• パケットタイプ：cache-policy
• 主なブロッカー：dependency-cache-policy
• 副次的なブロッカー：reproducibility-drift
• 次の成果物：cache-key policy
• 特定のログが本当の問題にならない限り、別の担当への振り分けは任意のままにします

例 2: すべてのブランチで重いパッケージ化を実行

入力

Android のパッケージ化をすべてのブランチで実行しているため、PR パイプラインに70分かかります。まず何を変えるべきですか？

望ましい出力の方向性

• シグナル階層：branch-gate
• パケットタイプ：ci-signal-hardening または stage-split
• 主なブロッカー：feedback-speed-confidence
• 次の成果物：CI-signal hardening plan または workflow stage split brief
• 完全なパッケージ化はすべてのマージゲートではなく、より重い候補レーンに置くべきであることを明記します

例 3: Unreal の巨大なジョブログ

入力

Unreal のパイプラインがありますが、パッケージ化に非常に時間がかかり、失敗が1つの巨大なログにまとまって表示されます。

望ましい出力の方向性

• シグナル階層：すべてのマージで完全なパッケージ化が本当に必要だとユーザーが示さない限り、通常は nightly-package-candidate
• パケットタイプ：stage-split
• 主なブロッカー：stage-boundary-blur
• 副次的なブロッカー：feedback-speed-confidence
• 次の成果物：workflow stage split brief

例 4: パッケージ化ログの失敗が1件

入力

昨夜、Unreal の Android パッケージ化ジョブが失敗しました。AutomationTool の出力はこちらです。

望ましい出力の方向性

• パケットタイプ：route-to-log-triage
• 主なブロッカー：single-log-not-pipeline
• game-build-log-triage に振り分けます
• 失敗したステージ、エンジンのバージョン、ターゲットプラットフォーム、ログの正確な抜粋を伝えます

例 5：手動の nightly／デモ候補プロセス

入力

すでにブランチビルドはすぐに作成できますが、QA には、アーティファクト名が明確な nightly の Windows + Steam Deck 候補が必要です。

望ましい出力の方向性

• シグナルの段階：nightly-package-candidate
• パケットの種類：artifact-release または pipeline-setup
• 主なブロッカー：artifact-release-hygiene
• 次のアーティファクト：artifact/release checklist または pipeline setup plan
• 候補の命名、保持期間、利用者への引き渡しを明示してください

ベストプラクティス

1. パケットより先にシグナルの段階を決める — branch-gate、nightly/package-candidate、release/certification の作業に、同じ架空のデフォルト回答を適用してはいけません。
2. 汎用的なインフラの講師ではなく、リリースエンジニアとして対応する — 繰り返し発生する問題を減らす、次のパケットを選んでください。
3. ログとパイプラインの境界を保つ — ビルドが 1 回失敗した場合も、構造を全面的に書き換える前に game-build-log-triage が必要なことがよくあります。
4. キャッシュをポリシーとして扱う — 何をキーにするか、何を共有するか、何を無効化するか、何を意図的に再生成するかを定義してください。
5. ステージの境界を明確にする — コンパイル、テスト、クック／パッケージ化、公開を、読みにくい 1 つの塊にまとめてはいけません。
6. リリースのコンテキストを見える状態に保つ — プロトタイプ、デモ、認定、ローンチでは、それぞれ異なるトレードオフが求められます。
7. 大規模な CI/CD マニフェストより、次のアーティファクトを 1 つ選ぶ。
8. 問題がエンジンパイプラインの構成ではなくガバナンスにある場合は、リリースゲートのポリシーを testing-strategies に振り分ける。

参考資料

• references/intake-packets-and-route-outs.md
• references/pipeline-patterns.md
• references/signal-tiers-and-promotion-lanes.md
• Unity Docs — よくある問題のトラブルシューティング • ビルドの自動化 • Unity Docs
• Unity Scriptable Build Pipeline — キャッシュサーバークライアント
• Epic Docs — プロジェクトのパッケージ化
• Epic Docs — Unreal Engine でのログ記録