シリーズ: Unity 初心者が Cursor の AI エージェントと3DアクションRPGを作る
- 第0回: ゲームプログラムが書けない私が、生成AIでゲームを作り始めた ― Phaser で2Dを1本、次は Unity × Cursor で3Dへ https://qiita.com/yasuharusmooth/items/8e8bd09d7f111fffbe40
- 第0.5回: 作りたい3DアクションRPGを、AIで作ったイメージボード3枚で紹介します ― いまできていること／これから作ること https://qiita.com/yasuharusmooth/items/aa0a8e2de2dae070e180
- 第1回: Unity 初めてで、AI に使い方を教わったのは最初の2回だけ。あとはエディタ作業ごと任せた話 https://qiita.com/yasuharusmooth/items/f2058b38d412b03d8c80
- 第2回: インスペクターの参照設定を人がやる意味はなかった ― Cursor × Unity MCP でエディタ設定まで AI に任せる https://qiita.com/yasuharusmooth/items/d9357e3d4d59d3dd286a
- 第3回: AI エージェントを増やしたら数字の確認ばかりに ― 「判断だけ聞いて、数字は仮で入れて」にした話（この記事）
- 番外編: ゲームのプログラムが書けなくても、主人公の3Dモデルは用意できた：Gemini → Meshy → Mixamo → Unity の流れ https://qiita.com/yasuharusmooth/private/35806e8a2ec0c0c94093
役割ごとにエージェントを分けて作業を任せられるようになったら、今度は私の確認作業が増えまくりました。そこで「判断だけ聞いて、数字や設定は自分で進めてくれ」としました。今回はその話です。
この記事で分かること
- マルチエージェントにすると、なぜ人の確認作業が増えたのか（私の場合）
- 「方針だけ聞く。数値は仮で入れる」をルールファイルにどう書いたか
- 仮の数値を、設計の記録にどう残しているか
結論（3行）
- エージェントを分けすぎて確認作業が増え、一番多かったのは数字の確認でした。
- 数字は触ってみないと判断できないので、仮の値で入れてもらい、Play で触って決める運用に変えました。
- ルールには「人に聞くのは方針だけ。数値は聞かない」と書き、記録にも仮の値は採用値として残さないようにしています。
最初の形: 役割を分けて、仕様は私が確認する
Unity 6（URP）で3DアクションRPGを個人開発しています。Cursor の本チャット（最初に話しかけるチャット）は進行役にして、設計の architect、実装の programmer、記録の reviewer、操作説明の unity-coach をサブエージェント（本チャットから呼び出す別の AI）に分けました。
最初は、設計担当の案を採用するかどうかを、私が1つずつ確認する形にしていました。そのときの ADR（設計の判断を1件ずつ残すメモ）です。
architect の仕様は、ユーザーが確認するまで提案のまま。
確認作業が増えまくった
マルチエージェント化しすぎた事で、私の確認作業が増えまくりました。
一番多かったのは数字の確認です。結局触ってみない事にはわからないので、数字だけで提案されても判断のしようがありませんでした。
判断だけ聞いて、数字は仮で入れてもらう
そこで、判断だけを聞いて、数字や設定は自分で進めてもらうことにしました。今のルールファイル（.cursor/rules/ に置く AI 向けの規約。常に読み込ませる設定）はこうなっています。
2. 仕様: つくりの方針（何を感じさせるか、状態の分け方、責務の切り方、入力の意味、作るものと作らないもの）が、既存の決定かユーザーの文から足りないときは、質問1つで止める。数値（速さ、ダメージ、時間、半径、体力など）は聞かない。方針が足りていれば、採用確認を挟まず実装へ進む。数値は仮としてデータに置く。
ユーザーが判断するのは、進める範囲、つくりの方針、手触りと見た目、外部素材、実機入力、Play で配置を受け入れるか、である。
実装担当のルールにも「数値はユーザーに戻さず、ScriptableObject か Inspector の仮の値にする」と書きました。ScriptableObject は設定値を Unity のファイルとして持つ仕組みで、第2回のインスペクターの画面がその例です。仮の値はそこに入り、私は Play（エディタ上でゲームを動かすこと）で触って判断します。
思い返すと、初日から「触って決める」やり方はしていました。仮の数値を含めた案を実装してもらい、Play の手触りを「OKです！」と受け入れた記録が残っています（ADR-0027）。今のルールは、このやり方を前提にしています。
記録の書き方もそろえた
数字を仮で入れるようになると、ADR に書く内容も変わりました。10-06 の ADR-0042 からは、次のような書き方が出てきます。
数値の変更は採用していない。仮の数値は書かない。
記録係（reviewer）の定義にも「仕様はユーザーが採用したものだけ記録する」「仮の数値は ADR にしない」と書いています。Play で私がまだ見ていないものは「受け入れは未確認」と書き分けています。
ちなみに、この切り替えは ADR ではなくルールファイルの書き換えで行いました。そのため ADR-0010 の「確認するまで提案のまま」という文面は、今もそのまま残っています。
まとめ
- 私の場合、エージェントを分けすぎて確認が増え、一番多かったのは数字の確認でした。
- 数字は触ってみないと分からないので、仮で入れてもらい、Play で判断するようにしました。人に聞くのは方針だけです。
- シリーズを通して、教わる → エディタ作業まで任せる → 判断だけ残す、の順で人の作業を減らしてきました。第1回はhttps://qiita.com/yasuharusmooth/items/f2058b38d412b03d8c80、第2回はhttps://qiita.com/yasuharusmooth/items/d9357e3d4d59d3dd286aからどうぞ。
アセットクレジット
このプロジェクトでは、Meshy の3Dモデル、Mixamo（Adobe）のリギングと一部のモーション、Unity Asset Store の複数の有料アセットを使用しています。
前作・SNS
- 前作の2Dゲーム「Princess Vanguard」（ブラウザで遊べます）
- 開発中の3Dアクション（YouTube）: https://youtu.be/SGDOwYSBr2s
- X: https://x.com/PuddingAthlete