*本記事はAIを使用して作成しています
前回、AIエージェントに役割と決定権を割り振って、統合フェーズで起きた巻き戻り事故を校正でなんとか止めた話を書いた。あれから複数のAIエージェントでゲーム企画とプロトタイプ開発を進めていて、今度は別の問題にぶつかった。
今週は、75ページの統合企画資料が校正を通過し、Unity製のWindows向けプロトタイプも「移動・ジャンプ・射撃・敵撃破」という機能確認まで進んだ。
ここだけ読むと順調に見える。ところが、実際にプロトタイプを人間の目で確認してみると、次の問題が見つかった。
- 主役機の見た目が正式デザインから離れている
- 移動しても手足が動かず、モデル全体が平行移動して見える
- フィールドと背景の区別が弱く、プレイ領域を読み取りにくい
機能は動いている。ただ、これはどう見てもゲームとして完成とは言えない。特に手足が動かないまま滑るように移動する見た目には、正直ちょっと笑ってしまった。
この経験から、AIエージェント開発では「実装できた」「テストが通った」「見た目が承認された」「最終成果として合格した」を分けて管理する必要があると分かった。
この記事では、WIPの提示と最終承認を混同しないために導入した、役割別の承認ゲートと証跡設計を紹介する。
1. 自動テストが通っても、ユーザー体験は合格とは限らない
今回の初期プロトタイプには、自動検証も用意していた。
- EditModeテスト: 5/5合格
- PlayModeテスト: 1/1合格
- 移動、ジャンプ、射撃、敵撃破、ミッションクリアの基本フローを確認
これらは重要な成果だ。少なくとも、基本機能が壊れていないことは繰り返し確認できる。
ただ、自動テストだけでは次を判断できなかった。
- 主役機が魅力的に見えるか
- 歩行が接地して見えるか
- 足場と背景を瞬時に判別できるか
- HUDや攻撃予告が背景に埋もれないか
- 正式な世界観やデザイン方針に合っているか
「仕様どおり動く」と「遊べる見た目になっている」は、別の品質軸だと痛感した。
そこで、テスト結果を一つの合否へ潰さず、専門領域ごとの承認に分解することにした。
2. 一つの「承認済み」を、4種類の承認へ分ける
改善版では、次の順序で承認するようにした。
| ゲート | 担当 | 確認するもの |
|---|---|---|
| デザイン承認 | デザインマネージャー | 外観、動きの読みやすさ、フィールド、完成アプリ上の可読性 |
| 技術承認 | 技術責任者 | リグ、アニメーション、取込方式、性能、ビルド、回帰試験 |
| 独立QA | 校正者 | 受入条件、再現性、回帰、証跡。専門判断の代行はしない |
| 統合記録 | プロデューサー | 設定・世界観・コンセプト適合と、各専門承認の取りまとめ |
ここで重要なのは、プロデューサーが最後に確認しても、技術承認やデザイン承認を代行しないことだ。
最終責任者を一人に集約すると、確認していない領域まで「承認済み」と書いてしまう危険がある。最終統合者の役割は、専門承認を上書きすることではなく、承認が揃っていることを記録することだ。
3. 受入条件は「良くする」ではなく、観測可能な形にする
「モデルを良くする」「アニメーションを自然にする」「背景を見やすくする」だけでは、エージェントごとに完了の解釈が変わってしまう。
改善Issueでは、次のように受入条件を観測可能な形へ変えた。
- 正式デザインとの比較で、頭部、胸部、肩、前腕、脚、背部ユニットを判別できる
- 通常のカメラ距離で、主役機かつ味方機として判別できる
- 左右移動中に、脚の踏み出し、接地、腕振り、重心移動が見える
- 移動開始、停止、方向転換、ジャンプ、飛行、射撃の遷移が破綻しない
- 足の動きと実移動が大きく滑らない
- プレイ開始後1秒以内に、足場、背景、味方、敵、危険を指し分けられる
- 背景が照準、敵センサー、攻撃予告、HUDを妨げない
- 既存の戦闘・クリア・再開フローが維持される
- Windowsアプリとして直接起動できる
- 旧版を削除せず、新版として追跡できる
完了条件の中に、機能、見た目、操作感、回帰、配布形式、追跡可能性を含めている。
これにより、「自分の担当箇所を実装した」だけではIssueを完了できない。ユーザーが受け取る形まで検証する必要がある。
4. 他エージェントの未コミット変更を混ぜない
改善作業の途中で、技術担当が統合を開始できない状態になった。
原因は、デザイン資産とUnity側の変更が同じ作業ツリーにあり、どの担当の変更か、どこまで完成しているかを分離できなかったことだ。
技術担当は、ここで無理にコミットせず、BLOCKEDとして次の解除条件を記録した。
- デザイン担当が、デザイン資産だけを単独コミットする
- Unity側の既存変更について、引き継いでよい範囲を明示する
- cleanな基点から統合、ビルド、回帰試験を行う
その後、デザイン担当は25ファイルだけの独立コミットを作成した。
検証には、次の証跡を含めている。
- GLB内のノード、メッシュ、アニメーションクリップ数
- リグ、クリップ、ソケット名
- 表示モデルと衝突モデル
- SHA-256
- 旧版比較画像
- 通常プレイ距離のプレビュー
- 元コミットと公開コミットのtree hash一致
「ブロックを報告する」のは進捗停止ではない。品質を保ったまま再開できる条件を明確にする作業だ。
AIエージェントは、明示しないと善意で他人の変更までまとめてしまうことがある。そのため、コミットの単位自体を成果物の一部として扱っている。
5. 計画書より、実物の証跡を優先する
進捗確認では、説明文だけが増えて、実物が見えない状態になりがちだ。
そこで、進捗提示物に優先順位を付けた。
優先度1: 実行可能なWindowsビルド
優先度2: 30〜90秒の連続動画 + 通常プレイ距離の画像
優先度3: 動作画面 + 改善前後比較 + 阻害要因 + 解消手順
計画書や口頭説明だけ: 提示物として数えない
これは「常に完成ビルドを出せ」という意味ではない。期限に間に合わない場合でも、現時点で確認できる事実を、ユーザーが見られる形で出すための段階設計だ。
証跡の強さは、おおむね次の順になる。
右に進むほど、ユーザー自身が確認できる範囲と再現性が高くなる。
6. 「進捗プレビュー」と「最終合格」を別の状態にする
途中成果を見せるときに起きやすい問題が、プレビューを完成品として扱ってしまうことだ。
今回の運用では、進捗提示に次の条件を付けた。
- 「土曜日の進捗プレビュー」と明記する
- 対象コミットを書く
- 起動・閲覧方法を書く
- 既知の不具合と未達項目を書く
- 未完成部分を隠さない
- プレビューを提示してもIssueをCloseしない
- 既存の専門承認と独立QAを維持する
状態を簡略化すると、次のようになる。
TODO
↓
IN_PROGRESS
↓
WIP_PREVIEW ── ユーザーが方向性を確認できる
↓
TECH_APPROVED
↓
DESIGN_APPROVED
↓
QA_PASSED
↓
FINAL
WIP_PREVIEWは価値のある成果だが、FINALではない。
AIエージェントに「進捗を見せて」と頼むと、文章を整えて完成らしく見せる方向へ進みがちだ。そのため、状態名と不足事項を成果物に含める必要がある。
7. 独立QAは、専門担当の承認を代行しない
校正者には、独立QAを担当させている。ただし、校正者がすべてを承認するわけではない。
例えば、次のように分担している。
- 技術担当: アニメーション制御や性能が技術的に成立しているか
- デザイン担当: 動きや画面が視覚的に成立しているか
- 校正者: 受入条件を再現でき、証跡と状態表示が正しいか
校正者が「起動できた」ことを確認しても、モデルの最終デザインを承認したことにはならない。同様に、デザイン担当が見た目を承認しても、30fpsと60fpsでアニメーション時間が変わらないことの技術承認にはならない。
確認結果には、「何を確認したか」だけでなく「何は確認していないか」も記録する。
この境界が、権限の越境と誤った完了報告を防ぐ。
8. Issueテンプレートに追加したい項目
今回の経験から、実装Issueには次の項目があると運用しやすいと考えている。
## 現行判定
- 機能確認: PASS / FAIL / 未確認
- デザイン確認: PASS / FAIL / 未確認
- 技術承認: PASS / FAIL / 未確認
- 独立QA: PASS / FAIL / 未確認
- 最終状態: WIP / REVIEW / FINAL
## 担当と決定権
| 領域 | 担当 | 決定できること |
|---|---|---|
## 受入条件
- [ ] 観測可能な条件を書く
## 提示物
- パスまたはURL:
- 対象コミット:
- 起動・閲覧方法:
- 既知の不足:
## 承認記録
- 技術:
- デザイン:
- 独立QA:
- 統合:
単一のチェックボックス「完了」よりも、どの品質軸が確認済みかを追える形が重要だ。
9. 今週の結果
今週は、次の段階まで進んだ。
- 企画・要件の統合資料は、修正と再校正を経て75ページの最終版として合格
- 初期プロトタイプは基本機能と自動試験に合格
- ユーザー確認から、外観、アニメーション、フィールド可読性の改善要求を分離
- 改善Issueに10項目の受入条件と4段階の承認ゲートを設定
- デザイン資産を25ファイルの独立コミットとして検証・公開
- 技術方針はGLBを正本として直接取り込む方式へ整理
- 改善版のWindows統合、デザイン最終承認、独立QAは継続中
最後の行が大切だ。今週は大きく進んだが、改善版はまだ完成していない。
まとめ
AIエージェント開発では、生成速度が速いぶん、途中成果が完成品のように見えやすい。
「動いた」を「完成」にしないために効いたのは、自動テストと技術承認、デザイン承認、独立QAをきちんと分けること。受入条件を観測可能な文章にすること。他担当の未コミット変更を混ぜないこと。BLOCKEDには解除条件を書くこと。計画ではなく、静止画や動画、実行物そのものを証跡にすること。WIPプレビューと最終合格を別の状態として扱うこと。そして、最終統合者が専門承認を代行しないこと。この7つだった。
複数のAIエージェントをチームとして使う場合、重要なのは「誰が作るか」だけではない。誰が、何を、どの証拠で承認したのか。そして、まだ何が未確認なのか。
この状態を追跡できるようにしておくと、速さを保ちながら、誤った完成報告を減らせる。前回の統合フェーズの話といい、今回の話といい、AIエージェントは早く形にしてくれる分、こちらが「本当に終わっているか」を見極める仕組みを用意しておかないと、あっという間に「動いた」が「完成」にすり替わってしまうのだと思う。