※本記事はAIを使用しています
前々からAIエージェントを自律で動かす実験をしてみたくて、ゲーム企画の初期資料づくりを丸ごと複数のAIエージェントに任せてみた。人数を増やせば早く終わるだろう、くらいの軽い気持ちで始めたが、実際にやってみると全然そんな甘い話ではなかった。
担当はプロデューサー、デザインマネージャー、技術責任者、マネージャー、日誌報告作成者、Qiita記事作成者、ストーリー作成者、校正者の8役。ストーリー、ゲームシステム、技術要件、UI/UXを並行して整理させて、最後に統合スライドへまとめる、という組み方にしてみた。
結論から言うと、エージェントを増やすだけでは、うまく回らない。うまく回り始めたのは、次の4つをきちんと言葉にしてからだった。
- 役割ではなく、最終決定権まで分ける
- Issueを依頼書として使う
- 統合後に独立した校正ゲートを置く
- 定期巡回の頻度と読む範囲を役割ごとに制限する
この記事では、実際にぶつかった失敗と、そこからどう運用を変えていったかを書く。この実験はおそらくしばらく続けるので、気づいたことがあればまた別の記事で書いていくつもりだ。
1. 「担当」と「決定権」は別物だった
最初にやったのは、単なる作業分担ではなく、誰が何を最終的に決められるかを決めることだった。作業を振るだけなら簡単だが、それだけだと後で「誰の判断を採用するか」で揉める。
今回はだいたいこんな感じで責任範囲を分けた。
| 役割 | 最終決定する領域 |
|---|---|
| プロデューサー | 設定、世界観、シナリオ |
| デザインマネージャー | UI/UX、ビジュアル、演出 |
| 技術責任者 | 機能・非機能要件、実装方針、技術選定 |
| マネージャー | タスク、依存関係、競合、Issueの交通整理 |
| ストーリー作成者 | 正式設定に沿った詳細化 |
| 校正者 | 整合性、破綻、表記、提出可否の確認 |
意識したのは、プロデューサーを「全部の上司」にしないことだ。プロデューサーは物語を決めてよいが、技術責任者の技術選定を、理由もなくひっくり返す権限までは持たせていない。
この境界がないと、最終統合を担当するエージェントが、悪気なく他の担当の決定を書き換えてしまう。人間のチームでもよくある話だが、生成が速いAIだと、矛盾が積み上がるスピードも段違いに速い。
2. Issueは「会話」じゃなく「非同期の依頼書」にする
エージェント同士の正式なやり取りにはGitHub Issueを使った。ただ、最初は短い一言指示で済ませていて、これが全然機能しなかった。
試行錯誤の末、実際に効いたのはこんな形だった。
## 依頼元 / 依頼先
- From: マネージャー
- To: 技術責任者
- 優先度: 緊急
- 期限: YYYY/MM/DD HH:MM
## 依頼内容
何を確定してほしいかを書く。
## 完了条件
- [ ] 技術スタックと採用理由がある
- [ ] 機能・非機能要件に検証可能な条件がある
- [ ] 未決定事項が列挙されている
## 対象範囲・制約
- 対象: 技術、機能・非機能要件
- 変更可能: 技術領域の決定
- 制約: 物語やデザインは各責任者へ確認
## 関連資料
- 必要な資料だけを列挙する
特に効いたのは「完了条件」と「変更可能な範囲」の2つ。
依頼内容だけを書くと、エージェントは「それらしい資料ができた時点で完了」と判断しがちだった。チェックできる完了条件を添えておくと、別のエージェントが後から「本当に要求を満たしているか」を検証できる。
あと、Issueを進捗コメントで埋めるのもやめた。コメントするのは完了・ブロック・判断が必要なときだけ、というルールにした。これでIssueが単なるチャットログではなく、状態と根拠を追える記録になった。
3. 並行作業はうまくいったのに、統合で壊れた
今回、技術責任者は18ページの技術要件スライドを作ってきた。中身はこんな感じだ。
- Unity LTS／URP／C#
- データ駆動設計
- オフライン優先のシステム境界
- 機能要件と非機能要件
- データ契約、進行契約
- 開発段階ごとの品質ゲート
この成果物自体は、校正でも問題なく通った。
デザイン側も、HUDの情報優先度、色覚対応、アクセシビリティ、チュートリアルの配色ルールなどをちゃんと固めてきた。警告表示は色だけに頼らず、色・形・文字・動き・音のうち2系統以上で伝える、という方針も決めていた。
ところが、55ページの統合版を見たとき、目を疑った。
技術責任者はUnityを採用していたはずなのに、統合版には「技術責任者がUnreal Engine 5を採用」と書かれていた。決定済みだった数値やIDも、いつのまにか未決定に巻き戻されていた。しかも、まだ校正を通していない資料が「Final Draft」として扱われていた。
つまり、各担当の成果物が正しくても、それを統合する側が正しくマージできるとは限らないということだ。コードに例えるなら、各ブランチの実装は正しいのに、マージコミットで仕様のほうが壊れているような状態だった。
4. 校正者にやらせたのは「文章チェック」じゃなく「統合テスト」
この矛盾を見つけたのは校正者だった。
校正では誤字やレイアウトだけでなく、次のようなことを確認させた。
- 専門担当の決定が統合版へ正しく反映されているか
- 決定権を越えて上書きしていないか
- 決定済みの項目が未決定へ戻っていないか
- 出典が実在する成果物を指しているか
- 全ページを描画したときに表示が壊れていないか
- 「最終版」という状態表示と実態が一致しているか
結果は、重大3件、高5件、中4件、低3件で不合格。
ここで大事だと思ったのは、不合格を「失敗」扱いしないことだ。むしろレビューゲートがちゃんと機能した証拠だと思っている。校正者がいなかったら、技術方式が矛盾したままの資料が最終成果物として残っていたはずだ。
AIエージェント開発における校正者は、文章の校閲者というより、仕様・権限・成果物をまたいで確認する統合テスト担当に近い。
5. 「たくさん巡回すれば安全」は、実は逆効果だった
最初のルールは、各エージェントが30分おきに共有フォルダとIssueを確認する、というものだった。一見丁寧に見えるが、実際にやらせてみると問題だらけだった。
- 変更がなくても同じ資料を何度も読む
- 自分に関係のないIssueまで確認する
- トークンと実行時間を消費する
- 複数エージェントが同時に動いて、同じ仕事を拾う
- 本来は週次でいい担当まで高頻度に起動する
そこで、最短巡回を1時間に伸ばし、頻度も役割ごとに変えた。Qiita記事作成者は週1回、マネージャーは1時間ごと、専門責任者は2〜6時間ごと、といった具合だ。
読む範囲も絞った。
巡回時に読むもの
- 自分宛のIssue
- 自分が起票した未完了Issue
- 自分の専門領域
- 現在タスクに直接関係する更新
巡回時に読まないもの
- 全Issue
- リポジトリ全体
- 設定資料の全件
- 完了済みIssueの全履歴
更新がなければ、それ以上は探しにいかず、そのまま終了する。
これは単なるコスト削減というより、エージェントの「見る範囲」を狭めることで、越権や重複作業、古い情報の使い回しを減らすための設計でもあった。
6. 成果物の保存範囲も役割ごとに分ける
複数のエージェントが同じワークスペースを触る以上、編集できる場所を分けておくのも必要だった。
例えば日誌報告作成者は日誌フォルダだけ、Qiita記事作成者は記事用フォルダだけを編集する。Qiita記事は公開前の原稿なので、リポジトリからは外してある。
この制限には2つの意味がある。ひとつは他担当の成果物をうっかり変更しないこと。もうひとつは、コミット時に他エージェントの未確定な変更が混ざらないようにすることだ。
Gitのブランチだけでなく、役割ごとの書き込み境界も用意しておくと、共有ワークスペースでの事故はだいぶ減る。
7. 今の運用フロー
改善したあとは、こんな流れで回している。
通常の依頼は直接委譲を優先していて、Issueを起票するのは、別セッションで追跡する必要があるもの、正式な記録として残したいもの、何かをブロックしているものだけにしている。
8. やってみて分かったこと
役割名だけでは、競合が起きたときに誰の判断を採用すべきか分からない。「プロデューサー」「技術責任者」と名付けるだけでなく、どこまで決めていいか、どこは上書きできないかを、あらかじめ言葉にしておく必要がある。
完了条件は「いい感じにまとめる」ではなく、「採用理由がある」「検証条件がある」「レビュー承認がある」のように、機械的に判定できる形まで分解する。それができていないと、確認する側も結局は感覚で判断することになる。
統合担当を信用しすぎないこと。これも今回学んだことのひとつだ。統合は要約ではなく、複数の決定を壊さずにマージする作業だ。専門の成果物と統合後の成果物は、別々にレビューしたほうがいい。
校正は最後のお飾りにしないほうがいい。提出を止める権限を持たせないと、校正はレビューではなく、ただの感想になってしまう。
定期巡回は、広さより差分だ。頻度そのものより、「誰が、どの差分だけを見るか」のほうが効いてくる。更新がないときにすぐ終われることも、長く運用するうえでは地味に効いてくる部分だった。
まとめ
複数のAIエージェントを使うと、ストーリー、技術、デザインの資料を並行して進められるようになる。ただし統合の場面では、決定権を越えた書き換えや、確定事項の巻き戻し、まだ承認されていない資料の最終版化といった問題が起きやすい。
今回効いたのは、役割ごとの決定権と編集範囲を決めておくこと、Issueに依頼元・依頼先・完了条件・制約・参照資料を書くこと、独立した校正者を統合テストとして置くこと、そして定期巡回を役割別・差分中心にすることの4つだった。
AIエージェント開発の難しさは、生成能力そのものより、複数の判断をどう整合させるかにある気がしている。エージェントを増やす前に、決定権や依頼の形式、レビューのゲート、巡回の範囲を先に決めておくと、あとがだいぶ楽になる。
この実験はまだ続いているので、また何か分かれば書くつもりだ。
想定タグ: AI AIエージェント GitHub ゲーム開発 プロジェクト管理