十人能否用 AI 做出一款游戏：Harness 与 Loop 的兼容性分析

はじめに――「目的を渡すだけ」で、チーム開発は回るのか

AIに個別の実装を依頼し、別のAIにレビューさせ、指摘を戻して修正する。この往復を続けていると、次の疑問が出てきます。

「次に何をするかを毎回人間が指示するより、目的を渡して、自分で分解・実装・検証してもらったほうがよいのではないか」

こうした運用を考えるとき、実行環境を整えるハーネスエンジニアリングと、反復・継続の制御を設計するループエンジニアリングが論点になります。ただし、その有効性をプログラマ10人程度のゲーム開発に持ち込むと、話は単純ではありません。

コードが増えることと、ゲームが完成に近づくことは違います。ある機能が正しく動くことと、他の担当者が作った機能につながることも違います。さらに、仕様どおりに動くことと、遊んで面白いことは別の問題です。

本稿の結論は、10人それぞれがAIを使う共同開発は成立しうる。ただし、個人のAI作業を10本並べるだけでは足りず、担当間の合意と統合を支える共通の仕組みが必要になる、というものです。ハーネスはその共有基盤になり、ループは合意された範囲内の反復を担います。個別タスクの指示は古い方法ではなく、目的の指示と組み合わせる管理手段です。

以下でいう10人は、それぞれがAIを使い、同じゲームを共同開発する10人の人間のプログラマです。「AIに10人分の仕事をさせる」「1人が10体のAIを動かす」という意味ではありません。企画・アート・QAなどとの協業も含めますが、その人数や組織構成は固定しません。

1. ハーネスとループを、同じ意味で使わない

ハーネスは「何を知り、何を操作し、どう確かめられるか」

ハーネスを、長いプロンプトやルールファイルの別名として捉えると、議論が狭くなります。Anthropicは、モデルへの入力、ツール呼び出しの調整、結果の受け渡しなどを担い、モデルをエージェントとして動かすシステムと説明しています。評価対象も、モデル単体ではなくハーネスとの組み合わせです。^[1]

ゲーム開発に置き換えれば、仕様書への入口、変更可能な範囲、ビルド方法、テスト環境、実機への接続、ログ取得、権限、成果物の保存方法までを含む、と本稿では整理します。

たとえば「既存のセーブを壊さないこと」と書くだけでは、守られたか分かりません。旧バージョンのセーブを読み込む検証経路と、その結果を確認できる仕組みまで用意して、初めて実効性のある条件になります。

つまり、ハーネスが扱うのは、AIを賢く見せる説明ではなく、AIが正しく作業でき、間違いを発見できる環境です。

ループは「次の作業と停止を、誰が決めるか」

Addy Osmani氏は、ループエンジニアリングを、人間が都度エージェントに指示する代わりに、その指示を行う仕組みを設計することとして整理しています。一方、LangChainは、ツール実行、検証、イベントによる起動、ハーネス改善という複数のループを扱っています。用語の対象範囲には幅があります。^[2][3]

そこで本稿では、調査・実装・検証の結果を受けて次の行動を選び、必要なら人間に戻し、停止または再開する制御を「ループ」と呼びます。単に同じプロンプトを定期実行する仕組みだけを指すわけではありません。

また、両者は排他的ではありません。ハーネスの内部にツール実行のループがある場合もあります。ここで区別したいのは製品の分類ではなく、環境の設計と、仕事を継続させる制御の責任です。

「指示の抽象度」と「自動化の度合い」は別軸

個別タスクでも、ビルド失敗を修正するループは組めます。逆に、大きな目的を渡しても、AIが計画を作ったところで人間の承認を待つ運用は可能です。

したがって、「個別タスクから目的へ進むほど、自動化が成熟している」という一列の理解は適切ではありません。何を委ねるかと、どこまで自動で進めるかを別々に決める必要があります。

指示が短いことも、自律性の高さを意味しません。短い依頼の背後に、共有仕様、検証環境、権限の境界が整備されていれば成立します。逆に、それらがなければ、省略された条件をAIが推測しているだけかもしれません。

2. 公開事例は期待を持たせるが、そのままゲーム開発の証明にはならない

OpenAIの2026年2月の報告では、空のリポジトリから始め、当初3人、記事時点では7人のエンジニアがCodexを動かし、約5か月で社内向け製品を構築しています。重要なのは人数だけではありません。エージェントがUIやログを確認できる環境を整え、その成果が特定の構造とツールへの投資に依存することも、記事自身が明記しています。^[4]

この報告から読み取れるのは、「複数の人間が、共通の環境を通じてAIによる開発を進められる」という可能性です。「10人のゲームチームなら同じ生産性になる」「既存プロジェクトでも追加投資なしで動く」という結論ではありません。

ゲーム開発そのものの報告もあります。Luden.ioの2026年6月の記事は、バグ調査、QAシナリオ提案、仕様書の差分レビューなどの有効例と、ゲームプレイ機能の実装や自律的な通しプレイでうまくいかなかった例を分けています。これは一社の実践報告であり、全ゲームに通用する性能上限ではありません。^[5]

また、同年10月10日の「Your Game Is A Harness」は、ゲームの内部状態を読み取り、同じ状況を再現し、変更を検証できる入口を作ることを論じています。ゲーム向けの観測・操作環境に投資する理由は示されていますが、10人チームの指示方式を比較した実験ではありません。^[6]

Anthropicの長時間エージェントの報告も、上位目的だけでは不十分だった状況に対して、初期設定、機能の分割、セッションをまたぐ成果物の受け渡しを導入しています。目的の指示が、タスク分解を不要にしたわけではありません。^[7]

一方、2026年3月の別の報告では、モデルの能力向上に伴って、以前必要だった作業分割や評価の一部を減らしています。これは「チェックを増やすほどよい」とも限らないことを示す事例です。ただし、対象は長時間のアプリケーション生成であり、ゲームチームの比較実験ではありません。^[8]

逆方向のデータも、更新まで含めて読む必要があります。METRの2025年の実験では、経験豊富なOSS開発者16人が246タスクに取り組み、AIを利用できる条件で所要時間が19％長くなりました。これは当時のツールと対象作業についての結果です。^[9]

2026年2月の更新では、後続調査は加速方向の推定になった一方、統計的に明確な加速を示したわけではありません。参加者やタスクの選ばれ方による偏りも大きく、効果の大きさを強く結論できないとしています。^[10]

同年5月公表の349人への調査は自己申告です。便宜的に集めた標本であり、大きな選択の偏りがある可能性をMETR自身が注記しています。仕事の価値に関する三つの質問の中央値は1.4〜2倍、速度の中央値は3倍でした。いずれも実測の因果効果ではなく、「速さ」と「価値」も同じ指標ではありません。^[11]

これらは、ハーネスの採用可否を多数決で決める材料ではありません。対象、時期、比較条件、測っている成果が違うからです。

本稿で参照した資料の範囲では、人間のプログラマ約10人によるゲーム開発について、個別タスク方式と目的駆動方式を直接比較した証拠は確認できていません。以下は、条件を分解した推論です。

3. なぜ「10人くらい」は、期待と危険が同時に増えるのか

共通の困りごとを、複数人分まとめて減らせる

1人だけが使う環境では、便利な自動化を作っても、その人の作業でしか費用を回収できません。複数人が同じビルド、同じ素材チェック、同じ規約確認を繰り返すなら、共通化の便益を分け合えます。

たとえば、アセットの参照切れを調べる仕組みがあれば、UI担当、バトル担当、演出担当がそれぞれ手で確認する負担を減らせるかもしれません。同じ確認を繰り返す人数が増えるほど、仕組みにする候補が増えるという話です。

しかも、ハーネスはAIだけのために作る必要がありません。人間も同じコマンドで再現でき、同じ証拠を読めるなら、AI導入の効果が小さくても、開発基盤として便益が残ります。

便益は、同じゲームの基盤を共有することで生まれるものです。見るべきなのは会社の総人数ではなく、同じ基盤を実際に再利用する人数と回数です。

個人の成功を、そのまま10倍にはできない

1人で試作するときは、同じ人が仕様を決め、コードを書き、画面を見て、採用を決められます。多少の設計変更があっても、自分が納得すれば進められます。

チームでは、その裁量が分散します。UI担当が画面遷移を改善したつもりでも、バトル担当が前提としていた入力待ちの状態を消してしまう可能性があります。演出担当の変更が、セーブ可能なタイミングをずらすことも考えられます。

このとき、AIへの説明を各担当者が個別に改善しても、チーム全体の矛盾は解消されません。必要なのは、共有する仕様と、変更を決める人の一致です。

10人という人数に、特別な境界線があるわけではありません。この規模を検討する理由は、共有化の便益が見込める一方で、専任の基盤チームを無制限に増やせるとは想定できない、という両面にあります。

生成能力より、受け入れ能力が先に不足する可能性

全員が複数のAIを動かせば、作業中の変更は簡単に増やせます。しかし、変更を読んで、つないで、遊んで確認する能力まで同時に増えるとは限りません。

変更の到着量が、レビューと統合で処理できる量を上回れば、待ち行列ができます。待っている間にも他の変更が入り、前提が古くなり、再確認が必要になります。

したがって、「全員に同じだけAIを配る」より、「どこまで受け入れられるかに合わせて同時作業数を制御する」ほうが、チーム設計として重要になります。

必要性が高いことと、導入しやすいことは別

ゲームはコードだけで完結しないからこそ、観測や再現の入口を整える意味があります。しかし、その入口を作る費用が大きければ、導入直後は負担が増える可能性もあります。

したがって、「ゲームにはハーネスが必要だ」から「ゲームは自律ループと非常に相性がよい」へは飛躍できません。共通基盤としての再利用価値と、各仕事を自動で完遂できる度合いは、別々に評価するべきです。

4. 目的は「ゲーム全体・担当領域・今回の変更」の三段に分ける

同じ大目標を配っても、同じ判断になるとは限らない

10人全員のAIに「テンポのよいSRPGを作る」と渡した場面を考えます。

バトル担当のAIは演出時間を削り、UI担当のAIは確認画面を省き、育成担当のAIは報酬表示をまとめるかもしれません。それぞれは待ち時間を減らしています。しかし、統合すると、プレイヤーが戦闘結果や成長を理解する機会まで消える可能性があります。

問題は、目的が共有されていないことだけではありません。目的は共有されていても、何を守り、どの判断を優先するかが共有されていないことです。

そこで、ゲーム全体の狙い、担当領域が果たす役割、今回変更してよい範囲を分けます。全体の狙いは「判断の意味が分かるまま待ち時間を減らす」、戦闘の役割は「結果を一度だけ確定し、表示に渡す」、今回の変更は「演出スキップ後もその約束を守る」といった形です。

上位目的は下位の実装をすべて指定しませんが、下位の改善が上位の体験を壊していないかを判断する基準になります。

人間への委任と、AIへの委任も区別する

チームリーダーから担当プログラマへ「スキップ機能を完成させて」と委ねることと、その担当者がAIへ同じ一文を渡すことは、同じではありません。

担当プログラマは、会議で決まった背景や他担当の事情を知っていても、そのAIが同じ情報を持っているとは限りません。人間が引き受けた裁量を、そのままAIにも渡してよいわけでもありません。

人間が担当領域の成果責任を持ち、その内側でAIにどの粒度の仕事を渡すかを選ぶ体制を想定します。経験のある担当者が目的単位で委ねてもよく、まだ仕様を把握している途中の担当者が個別タスクから進めても構いません。

統一するのは指示文の長さではなく、共有仕様、変更権限、受入条件、提出する証拠です。全員を同じAI操作スタイルにそろえることが、共同開発の前提ではありません。

担当間の「契約」を小さく明文化する

ここでいう契約は法律文書ではなく、機能同士の接続に関する約束です。入力と出力だけでなく、いつ呼ばれるか、誰が状態を変更するか、失敗時にどうなるかを含みます。

戦闘結果の通知なら、データの型が一致しているだけでは足りません。UIは通知を受けた時点でHPを読んでよいのか、通知は再送されるのか、演出中断時にも届くのか。こうした意味の一致が必要です。

ただし、最初から将来の全機能を設計する必要はありません。今の変更で触れる接点を合意し、未決事項を明示すればよいのです。未決事項を隠してAIに埋めさせることと、仮の仕様として明示して試すことは別です。

仮仕様には採用状態「仮」と人間の確定責任者を付け、依存する実装を統合検証で明示します。確定時に再検証し、仮仕様上の合格を採用済みとは扱いません。

目的は進む方向をそろえ、契約は一緒に動ける範囲をそろえる。 この二つがあれば、担当内の実装方法を必要以上に統一せずに済みます。

5. 個別タスクの指示は、本当に非効率なのか

強みは、変更の境界を小さく保てること

個別タスク方式を、「人間がすべて考え、AIが言われたとおり書くだけ」と決めつける必要はありません。

人間が問題と責任範囲を切り、AIに調査と実装方法を任せる運用も、個別タスク方式です。「このクラスを直す」という依頼でも、内部のアルゴリズムまで指定する必要はありません。

この方式の利点は、担当者が前提を確認しやすく、レビュー対象を把握しやすく、失敗時の切り戻し範囲を狭めやすいことです。特に既存のゲームで、他機能との接点や過去の例外処理が十分に整理されていない場合、最初から裁量を広げない合理性があります。

一方で、タスクを小さく切るだけでは足りません。「敵のHPを0にする処理を追加する」と依頼すると、死亡通知、経験値、演出、セーブへの反映が抜けるかもしれません。局所的な変更指示にも、機能全体の中で何を成立させたいかが必要です。

人間が手順を決めすぎる問題もある

たとえば、ロード時間が長い原因を調べず、「この箇所にキャッシュを追加して」と指示したとします。AIが正確に従っても、遅延の原因が別にあれば、目的は達成できません。

これはAIの能力不足ではなく、人間が仮説を実装命令に変換してしまった問題です。

目的を伝える価値は、AIに何でも決めさせることではありません。「その方法では目的を達成できない」と指摘できる余地を残すことです。調査タスクと実装タスクを分けるだけでも、この問題は緩和できます。

最小限でも、目的と確認方法は渡す

次は指示の提案例であり、実在するリポジトリへ投入したものではありません。

目的：戦闘演出をスキップした直後に、HP表示が古いまま残る不具合を直す。
対象：戦闘結果をUIへ反映する部分。まず現在の更新経路を調べる。
条件：ダメージ計算、乱数の消費順序、セーブ形式は変えない。
確認：同じ初期状態・入力・乱数条件で、通常再生とスキップ後の
      HP表示が一致し、承認済みの期待値にも合うことを確認する。
停止：解決に戦闘進行や公開インターフェースの変更が必要なら、
      実装範囲を広げず、根拠と変更案を報告する。
提出：変更差分、再現条件、実行した検証、未実行の検証。

比較の再現性は、乱数条件だけでなく初期状態や入力順もそろえて確認します。演出が戦闘用乱数を消費していないかを先に調べ、未分離なら消費箇所とスキップ時の差を最初の調査タスクにします。条件がそろわなければ人間に戻し、AIが独断で乱数の分離などの設計変更を進めないようにします。

これは個別タスクですが、目的も含まれています。逆に、修正対象を明示していても、その範囲で直せないという報告を許しています。

そのため、個別タスク方式の評価基準は、指示の細かさではありません。境界の内側では考えられること、境界の外側に出るときは立ち止まれることです。

毎回の説明を減らす場所は、プロンプトの外にもある

依頼のたびにビルド方法や責務分離の規則まで書き直すなら、個別タスク方式は確かに重くなります。しかし、それは個別タスク方式の必然ではなく、共通情報が共有されていない問題です。

安定した規則は基盤へ、今回だけの目的は依頼へ、今回見つかった仕様の曖昧さは確認事項へ整理する。この整理は、目的駆動のループを導入する前にもできます。

まずこの状態を作らずに「個別指示は面倒だから目的だけ渡す」へ進むと、説明の負担がなくなるのではなく、推測と手戻りに姿を変える可能性があります。

6. 目的の指示が機能するのは、裁量と判定をセットで渡したとき

同じ問題でも、委ねる範囲は広げられる

先ほどの例で、原因がUI更新だけでなく、戦闘終了通知や入力解除の順序にまたがっていたとします。

個別タスクを細かく切りすぎると、人間が調査結果を受け取るたびに、次の修正指示を出すことになります。問題の範囲を把握できているなら、ここをまとめて委ねる価値があります。

「戦闘演出をスキップしても、通常再生と同じ戦闘結果が確定し、次の操作に進める状態にする」

この目的なら、AIに更新経路の調査、修正箇所の選択、検証ケースの追加まで任せられます。ただし、これだけでは、何を変えてよく、何を維持するかが不足しています。

目的は、品質・制約・停止条件と組み合わせる

目的駆動の指示では、人間が実装手順を詳しく書く代わりに、守る条件を詳しくする必要があります。次も提案例です。

目的：戦闘演出のスキップ後に、通常再生と同じ戦闘結果が確定し、
      次の手番の入力を受け付けられるようにする。
範囲：戦闘進行、演出終了通知、戦闘UIの連携部分。
前提：変更範囲は関係する人間の担当者と合意済みであること。
      対象コミット、承認済みの戦闘・UI接続仕様、合意記録の参照先を示す。
      演出の乱数消費と比較の再現性を確認済みであること。
不変条件：ダメージ式、戦闘用乱数、セーブ形式は変更しない。
      結果確定イベントの仕様上の回数を維持する。
受入条件：承認済みの通常戦闘・撃破・相打ち・連続戦闘のケースで、
      通常再生とスキップの双方が既知の期待結果に一致する。
      HP・経験値・次手番・入力受付・イベント回数を検証する。
証拠：対象コミット、実行環境、テスト結果、操作再現手順を保存する。
停止：前提不足、仕様の矛盾、合意外の変更、検証環境不足は、
      実装を進めず、根拠と必要な判断を人間に報告する。
      修正と再検証は最大3回。未達のまま条件を緩めない。

採用は人間側の工程です。自動マージせず、変更責任者が関係担当のレビューと統合後検証を経て採否を決めます。

最大3回は普遍的な適正値ではなく、この例の運用上限です。回数だけでなく実行時間や利用予算も別途制限します。また、対象ゲームに存在しないケースを、形式だけで受入条件に加える必要はありません。

この指示は短くありません。しかし、調査結果ごとに人間が次の手順を作る回数を減らせる可能性があります。目的指示の便益は、最初の文章量ではなく、途中の判断をどこまで安全に委ねられるかにあります。

目的だけでは、正解は一つにならない

「ロードを速くする」という目的には、先読み、遅延読み込み、データ削減、品質設定変更など、異なる解法がありえます。そのうちどれが許容されるかは、ゲームの設計と制作上の都合によります。

画質を落としてよいか、メモリを増やしてよいか、初回と2回目のどちらを重視するか。ここが未定なら、数値目標だけあっても十分ではありません。

目的の指示で委ねられるのは、最初から実装手段を一つに固定せずに進める裁量です。「何を犠牲にしてよいかまで未定でよい」という意味ではないと考えます。

逆に、方法を一つに決めつけず、守る境界を共有できれば、人間の思いつかなかった改善策を試せる余地が生まれます。ここは個別の実装手順を細かく指定する方式に対する、目的駆動の実質的な利点です。

タスク分解は消えず、担当が移る

目的を渡しても、AIの内部では調査、設計、実装、検証、修正という仕事が発生します。人間による分解を減らせても、依存関係そのものはなくなりません。

したがって、評価すべきなのは「目的を一文で渡せたか」ではなく、AIが作った分解が適切か、順番に無理がないか、担当範囲を越えていないかです。

10人のチームでは、目的単位で任せる前に「どこまでが一つの担当領域なのか」を合意するほうが先です。この合意なしに裁量を広げると、AIによる自律的な仕事の分解が、人間同士の担当分担と衝突します。

7. 10本の作業ループと、1本の統合ループを混同しない

各自のAIが合格しても、ゲームはまだ合格していない

ここでいう「1本」は、必ず単一サーバーや単一のAIで実装するという意味ではありません。最終的に同じ統合状態を判断する、共通の経路という意味です。

全員のAIを直接接続する専用システムも、必須とはしません。最初は人間が共通の課題票と変更依頼を介して受け渡し、実績がある部分だけを自動化する構成でも始められます。

各担当者の内側では、AIが調査、実装、テスト、修正を繰り返します。その外側では、担当間の前提を照合し、変更を組み合わせ、統合したゲームを実行して確かめます。

たとえばAさんのテストは旧版のUIを相手にして合格し、Bさんのテストは旧版の戦闘処理を相手にして合格するかもしれません。両方を同時に取り込んだ組み合わせは、どちらのテストでも確認されていません。

このため、本稿の提案では「担当内で検証済み」と「統合した状態で検証済み」を別の状態にします。AIが出した完了報告を十個集めても、後者の代わりにはなりません。

ファイルが競合しなくても、意味は競合する

戦闘担当が結果通知を一度だけ送るように修正し、UI担当は通知が二回来る前提で、二回目に画面を確定する処理を追加したとします。別々のファイルなら、Git上の競合は出ないかもしれません。しかし、組み合わせると二回目の通知が来ず、画面が確定しなくなります。

さらに、互いのAIが「相手側の処理が原因」と判断して、それぞれ相手の前提を打ち消す修正を続ければ、局所的には改善しているのに全体では振動する構図になります。

解決策は、AI同士に議論を無限に続けさせることではありません。どの層が結果を確定するか、重複を許すか、どこで防ぐかを関係者が合意し、その約束に戻して検証することです。

独立して進めてよいのは、作業場所が違うときではなく、変更の意味が独立しているときです。

境界を変更するときだけ、関係者を同期する

すべての変更を毎回10人全員で承認すると、今度は調整が開発を止めます。反対に、誰にも知らせず公開インターフェースを変えてよいことにすると、個人の自律性が他人の手戻りになります。

その中間として、実装内部の修正は担当者の裁量とし、共有イベント、データ形式、保存互換、アセット構成などの接点を変える場合だけ、影響する担当へ合意を求めます。

提案する順番は、変更案と影響先を示す、関係担当が契約を更新する、必要な互換対応を入れる、各担当が実装する、統合状態で再検証する、です。AIは影響先の洗い出しや変更案の作成を補助できますが、合意の不存在を埋め合わせる権限は持ちません。

緊急修正では手順を短縮する場合もあります。その例外を誰が認め、どの検証を後追いするかまで記録して、例外がいつの間にか通常運用になることを防ぎます。

判断が変わったら、動いているループにも伝える

共有仕様を更新しても、すでに実行中のAIが、その変更を自動的に認識するとは仮定しないほうが安全です。

そこで開始時に、対象コミット、仕様の版、担当者、変更範囲を作業記録に残します。接点の仕様が変わったら、影響する作業を判断待ちへ戻し、差分を読んだうえで続行かやり直しかを決めます。

重要なのは、常に最新資料を読むことだけではありません。「どの前提で作られた成果物か」を追跡できることです。古い仕様のもとで正しく作られた変更を、最新の約束に適合したものとして取り込まない仕組みが必要です。

担当者が席を外している間にも差分が増えうるため、合意の更新や停止を人間の記憶だけに依存させない点が重要になります。

10人全員を、一つのタスクに押し込めない

例として、バトル3人、UI2人、マップ・イベント2人、育成・セーブ1人、アセット・ツール1人、ビルド・検証基盤1人の計10人を考えます。全員がAIを使います。これは説明用の配置であり、推奨する固定組織図ではありません。

戦闘スキップに直接関わるのは、そのうち数人かもしれません。他の担当者は、同じゲームの別の機能を進めます。10人で共同開発することは、常に10人分の変更を一度に統合することでも、全員を同じ機能に参加させることでもありません。

また、ビルド担当だけに品質責任を集めません。バトル担当は戦闘の条件を、UI担当は表示と入力の条件を、自分たちのAIとともに確認します。統合を支える役割は必要ですが、全員が作ったものを最後の一人が全部読み直す体制は避けたいところです。

最初に決めるのは、担当表より「完成状態」

この例では、戦闘結果は演出の完了を待たずに一度だけ確定し、演出は確定済みの結果を表示する、という仕様を採用したと仮定します。既存ゲームにこの構造を無断で持ち込む提案ではありません。

完成状態は、通常再生でもスキップでも結果が一致し、表示が更新され、入力が戻り、必要な戦闘後イベントへ進めることです。見た目と音のつながりは、統合したビルドで別途確認します。

この完成状態が共有されていれば、バトル担当は結果確定を、UI担当は表示と入力を、イベント担当は戦闘後の進行を扱えます。各自のAIには、共通の接続仕様と、その担当で今回守る条件を渡します。

同じ機能の中でも、指示の粒度を混ぜる

結果確定の二重実行だけを直すなら、バトル担当は個別タスクを渡せます。UI担当は、表示と入力の復帰をまとめた目的として委ねてもよいでしょう。イベント担当は、まず既存の戦闘後イベントがどの通知に依存しているかを、調査だけ依頼するかもしれません。

三者の指示の粒度が違っても問題ありません。共通の完成状態へ接続し、変更範囲が衝突せず、未決事項を報告できれば、共同開発として整合します。

逆に、全員が同じ「目的駆動」を採用しても、各自が相手の担当まで直し始めれば破綻します。統一するべきなのはAIへの話し方ではなく、成果物の境界と受け渡しです。

統合では、縦につながった一連の操作を確かめる

担当内のテストでは、相手の機能を仮の実装に置き換えることがあります。これは先に進むためには便利ですが、仮実装に接続できたことを、ゲームで動いたことと同一視しません。

統合した状態では、戦闘開始、スキップ入力、結果表示、次の手番、戦闘後イベントまでを続けて確認します。途中の状態だけでなく、連続して操作したときにも問題がないかを見ます。

不具合が出たら、統合側のAIが全担当のファイルを独断で書き換えるのではなく、再現条件と破られた契約を整理し、変更責任者へ戻します。複数領域の修正が必要なら、関係者が一つの変更計画として合意します。

この工程で初めて、個別の成功がゲーム全体の成功につながったと判断できます。目的指示の導入効果も、ここまでの所要時間と手戻りで評価するべきです。

9. ゲーム開発には、閉じやすいループと閉じにくいループがある

「動く」と「遊びたい」を、別の判定にする

ゲームだからすべて主観的、という説明も適切ではありません。データ参照、セーブ復元、入力の状態遷移、戦闘結果、クラッシュ再現など、機械的に確認しやすい条件はあります。

一方で、「戦闘が気持ちよい」「初見で状況を理解できる」「もう一度挑戦したい」は、単一のテスト結果に置き換えにくい目標です。

Osmani氏の実践記事も、完了や良さの定義が曖昧な作業、主観的なデザイン、終わりのない創作探索を、無条件にループへ委ねることには慎重です。^[12]

この考え方に沿って、仕様への適合を確認する内側のループと、その仕様を採用する価値を判断する外側のループを区別します。

戦闘スキップの例なら、結果が一致し、入力が戻ることは内側で検証できます。しかし、スキップ時の暗転が唐突でないか、勝敗を理解できるかは、実際のプレイを含む別の判定として残します。

数値にできれば、目的を測れたことになるわけではない

たとえば「平均戦闘時間を短くする」だけを目標にすると、演出をすべて消す、敵を弱くする、確認画面を省く、といった方法でも達成できます。

しかし、ゲームが求めているのは、単なる短時間化ではなく、判断の密度を維持しながら待ち時間を減らすことかもしれません。

この差を放置して反復すると、ループは改善を積み重ねるのではなく、間違った指標への適合を積み重ねます。評価値が上がっていても、制作目的から離れている可能性があります。

対策は、指標を使わないことではありません。変えてよいもの、維持する体験、比較用のプレイ条件を分け、数値と人間の評価の対応を確認することです。

創作では「完成」より「比較可能な候補」を出口にする

主観がある仕事を、AIから取り上げる必要もありません。

たとえば、演出テンポを3案作り、同一の初期状態・入力列・乱数条件で同じ戦闘を各案で再生できるようにする。再現性の確認は第5章と同じです。UI導線の改善案を、同じ入力条件で比較できる試作にする。この目的なら、ループの出口を明確にできます。

出口は「面白くなるまで続ける」ではなく、「担当者が比較して選べる候補がそろった」です。候補の採否と、その後に目指す方向は人間が決めます。

この形なら、AIは探索を速め、人間は評価を引き受けられます。ただし、候補を無制限に増やせば選別が新しい負担になるため、案数や変更幅にも予算を置くべきです。

10. ゲーム向けの共有ハーネスで先に整えたいもの

以下の七つの小節で挙げる項目は、段階的に整えます。最初は、仕様の入口と変更所有者を決め、担当内検証・統合検証・採用を区別し、統合ビルドで対象機能を通して実行する経路を用意します。確認は手動からでも構いません。

全員展開に向けて、資源予約、権限分離の細分化、性能測定の専用経路を強化します。ただし、最小権限と機密保護は初回から、資源の競合回避は共有開始前から必要です。

基盤担当1人を単一障害点にしないよう、各領域担当が自領域の検証・復旧手順を持ち、共通基盤にも代替担当を置きます。第12章の属人化の評価にもつながります。

仕様の入口と、変更の所有者

最初に必要なのは、すべてを網羅した巨大な説明書ではありません。現在有効な仕様がどこにあり、誰が変更を決められるかをたどれる入口です。

本稿の提案では、共通ルール、領域別仕様、現在のタスク、過去の判断理由を分けます。コードの位置だけでなく、戦闘結果を確定させる責任、演出が変更してよい状態、UIが参照するタイミングも記録します。

特に重要なのは、旧仕様を新仕様と同じ扱いで置かないことです。AIに資料を大量に渡しても、どれが有効か分からなければ、情報量を増やしただけになります。

仕様の更新者と採用状態を付け、コード変更と一緒に更新する。これをAIのためだけでなく、新しく担当に入る人間にも読める形で整えます。

エンジンを操作できることと、検証できること

Unity Test FrameworkはEdit Mode、Play Mode、対象プラットフォームでのテストを提供しています。Unreal EngineにもAutomation Test Frameworkや、ゲームのセッションを起動して結果を検証するGauntletがあります。ゲームの実行を含めた検証基盤を組む入口は、すでに存在します。^[13][14][15]

ただし、これらを導入しただけで、操作、映像、サウンド、対象端末の性能をすべて確認したことにはなりません。検証は次の四層で扱います。

毎回すべてを同じ重さで実行する提案ではありません。変更の影響に応じて必要な層を選び、未実行の範囲を残すという提案です。

たとえばUnityの-nographicsはグラフィックスデバイスを初期化しません。その実行が成功しても、実描画の検証に合格したとは扱えません。-batchmodeと描画なしの実行も、同じ意味ではありません。^[16]

「コマンドを実行できる」と「必要な結果を観測できる」を区別しないと、自動化の範囲を過大評価してしまいます。

スクリーンショットだけでは、時間の問題を確かめられない

画面の配置や表示内容は、静止画で比較しやすい対象です。一方で、攻撃の予備動作、入力受付、カメラの復帰、SEと着弾の同期などは、時間の流れに関係します。

時間的な挙動を確かめるため、静止画、動画、状態ログを用途別に使います。動画が正しく見えても、内部で結果イベントが二重発火しているかもしれません。ログが正しくても、画面が一瞬だけ破綻しているかもしれません。

いずれか一つを万能な証拠にするのではなく、検証したい性質に合わせて組み合わせます。さらに、取得した証拠がどのコミット、どの端末、どの設定に対応するかを残します。

アセットの意味を保った変更経路

Unityでは、アセットの.metaを失うと参照が壊れることがあります。また、SceneやPrefabのマージを支援するSmart Mergeが用意されています。コード差分だけを見ていては、こうした参照関係の問題を見落とします。^[17][18]

このため、アセットの変更は何でもテキスト置換で行うのではなく、対象に適したエディター操作や検証手順を通す方針にします。共同編集が難しいファイルは、担当者や編集時間を分ける判断も必要です。

マージツールがあることは、統合結果の意味が正しいことの保証ではありません。Prefab内の参照がつながっていても、表示すべき対象を間違えていれば不具合です。統合後の実行確認を省かないことが重要です。

AIの種類は違っても、提出物の基準はそろえる

Codexを使う人とClaude Codeを使う人が混在する体制でも、同じ仕様、同じビルド手順、同じ受入条件へ接続するように設計できます。特定製品の会話履歴をチームの正本にしないことが、そのための出発点です。

個人設定は作業の好みとして許し、共通ルールを上書きする根拠にはしません。共通ルールを各ツールへどう読み込ませるかも確認対象にし、ファイルを置いただけで全AIに伝わったとは扱わないようにします。

また、AIが生成した変更についても、人間の変更責任者を明記します。その人は全行を手書きする必要はありませんが、何を変え、どこを確認し、どこに不確かさが残るかを説明できる必要があります。

作業場所と、共有する実行資源を分ける

Gitのworktreeは、一つのリポジトリに対して複数の作業ツリーを持つ仕組みです。各担当やAIの書き込み先を分ける入口になりますが、契約の衝突や、実行環境の競合まで解決するものではありません。また、worktree自体を権限分離の仕組みとは扱いません。^[19]

ゲームでは、作業コピーを分けても、ビルド出力先、テスト用セーブ、接続ポート、実機などを共有すれば干渉しえます。干渉を避けるため、実行IDごとに出力と証拠を分け、共有機器は予約し、同じ編集対象への同時操作を避ける設計にします。

Unityの公式資料も、同じプロジェクトをEditorで開いている間に、そのプロジェクトを別のbatch modeで開けないとしています。コードの並列化と、エンジンの同時実行は別に設計する必要があります。^[16:1]

共有CPUやGPUが混雑している状態で性能を測ると、コード変更による差と負荷による差を区別しにくくなります。性能測定は実装ループから予約制の経路へ分けるなど、確認したい性質に合う実行条件を用意します。

「しないで」と、実行権限を切り離す

本番配布、署名情報の利用、外部サービスへの書き込みなどは、文章の注意だけに依存させない設計を提案します。AIの通常作業環境には不要な権限を渡さず、保護された操作は人間の承認経路へ分けます。

同様に、共有ルールや受入基準をAIが提案として修正することと、そのまま全員へ適用することを分けます。一つの改善案を無審査で共有ハーネスへ取り込むと、誤った規則まで10人の作業へ展開してしまうためです。

共通基盤の変更も、小さく試し、影響を確認し、戻せる状態で展開します。AIの種類をそろえるより、共通基盤の更新に責任者と履歴を置くほうが重要だと考えます。

11. ループで最初に設計するべきなのは、続け方より止め方

AIが「完了」と言っただけでは、完了にしない

実装担当とレビュー担当を分けることには意味があります。ただし、別モデルを使っただけで、独立した証明が得られるわけではありません。

同じ曖昧な仕様を読み、同じ不足したテストだけを見れば、別のAIも同じ誤りを受け入れる可能性があります。実装側の説明に納得することと、成果物を検証することは違います。

レビュー側は対象コミットの実物、承認済み仕様、検証結果を確認し、必要なら別の入力や反例を試します。作者の報告だけを根拠に合格を付けないことを原則にします。

また、技術的な状態と採用の状態を分けます。テストに合格していても未承認はありえます。実機が使えず未検証でも、コードレビューまで終わっている場合はあります。たとえば「実装済み・担当内検証済み・統合検証済み・採用済み」を分け、未実行と不合格も区別します。それぞれを一つの「完了」に押し込めません。

検証条件を、実装と一緒に都合よく変えさせない

「テストが全部通るまで直して」とだけ指示すると、失敗するテストを削除する、期待値を実装に合わせる、タイムアウトを極端に伸ばす、という変更まで目的に沿って見える可能性があります。

もちろん、テスト側が間違っていることもあります。そのため、テストの変更を全面禁止するのも不適切です。

提案する運用は、受入基準の変更と、それを満たす実装の変更を別の判断にすることです。AIはテストの不備を報告し、修正案を提出できますが、成功条件を書き換えて自分で成功を確定させる権限は持たせません。

戦闘の比較テストは、第6章の受入条件どおり、承認済みの独立した期待結果とも照合します。

停止は、失敗だけではない

新しい情報が得られない反復、検証環境の欠落、仕様の矛盾、権限外の変更は、自動で押し切る対象ではありません。停止して人間の判断へ戻す対象です。

成功、予算上限、進展なし、判断待ち、環境不足は別の停止理由として記録します。同じコマンドの再試行でも、一時的な障害の再確認と、原因を理解しない無限反復を区別します。

停止したときには、現状、試したこと、分かったこと、未確定事項、再開に必要な条件を残します。「できませんでした」だけでも、「次はたぶん動きます」だけでも、次の担当者は仕事を引き継げません。

継続が得意な仕組みほど、止まった場所を明確にする価値があります。

12. 相性のよさは、個人の速さではなくチームの完成量で測る

比較する条件をそろえる

まず、今の作業で何に時間を使っているかを記録します。指示の準備、AIとの往復、レビュー、環境待ち、統合後の修正を分け、担当者の体感だけで成功を決めないようにします。

共有ハーネスを導入する効果と、目的単位の指示へ変える効果も分けます。新しいツール、強いモデル、速いビルド環境、指示方式を同時に変更すると、どれが効いたのか分かりません。

比較案は、共通のハーネスを使ったうえで、片方は人間が個別タスクに分け、もう片方は同程度の機能を境界付きの目的として渡すことです。品質条件と変更権限はそろえ、目的方式だけを自由に仕様変更できる有利な条件にはしません。

ただし、同じ課題を同じ人が二回解けば学習が入ります。性質と難度が近い複数の課題を選び、可能なら担当や順番を入れ替えます。少数の社内試行から厳密な因果効果までは断定せず、どの種類の仕事で得失が出たかを記録します。

「採用された変更」までの人間の時間を見る

コード生成が速くても、レビューの時間が倍になれば、チームにとって得とは限りません。見るべき対象は、実装の終わりではなく、必要な検証を通って統合・採用された状態です。観測期間は事前に決め、たとえば採用後の統合検証とプレイ評価を少なくとも1回ずつ通過するまでの手戻りを含めます。観測期間後に判明した不具合は、今回の方式比較には含めず、別の記録として追跡します。

人間の総作業時間は、依頼者だけでなく、隣接担当、レビュアー、統合担当が使った時間も含めます。AIが動いている時間や環境の待ち時間は、実作業時間とは分けて、着手から採用までの経過時間に反映します。

成果の量も、コミット数や行数ではなく、同程度の受入条件を満たした機能単位で見ます。そのうえで、統合後の不具合、差し戻し、再オープン、未検証の残り方を品質の制約として確認します。

AI利用料、実行機器、基盤整備と保守の負担も無視できません。未測定の費用や削減率を仮置きして採算がよいと結論することはしません。

少人数の成功と、10人運用の成功を別に確認する

最初から全員の仕事を変えるより、境界が見えている一つの領域で手順を試すほうが、失敗の原因を切り分けやすいでしょう。しかし、その結果だけで10人運用に合格を出してはいけません。

全員へ広げた段階で初めて、共有機器の待ち時間、レビュー待ち、複数目的の衝突、共通仕様の変更通知などが表面化する可能性があります。段階導入は有効性の証明ではなく、安全に本番規模の問題へ進むための方法です。

たとえば一人あたりの実装が速くなっても、統合待ちが増え続けるなら、AIの並列数をさらに増やす局面ではありません。仕掛かり中の変更を減らす、担当の境界を切り直す、検証資源を確保する、といった対応を検討します。

また、もっともAIに詳しい一人が毎回救済しているなら、その人の時間を費用に含めます。本人が不在でも他の担当が停止理由を理解し、再開できるかは、チームとして運用できているかを測る重要な条件です。

合わない領域では、戻すことも設計に含める

受入条件が安定したデータ検査や局所的な修正と、複数領域の責務を変える改修を、同じ自律性で扱う必要はありません。新規試作、量産、リリース前でも、許容できる変更の幅は変わります。

目的方式で範囲外の変更や手戻りが増える領域は、個別タスクへ戻してよいと考えます。それはAI活用全体の失敗ではなく、その目的を安全に委ねる条件がまだ足りない、という評価です。

反対に、担当者が毎回ほぼ同じ判断を仲介している領域は、その条件を共有仕様や検証へ移せる候補です。人間の判断を全部消すのではなく、繰り返し可能な部分を仕組みにし、残る判断へ時間を使います。

おわりに――10人の自律性を、ひとつのゲームへ接続する

10人がそれぞれAIを使うゲーム開発は、設計上は成立しうると考えます。ハーネスもループも、そのために使える手段です。ただし、人数だけから導入効果を保証できるわけではありません。

共有ハーネスの価値は、各自のAIに同じルールと検証経路を使わせ、人間もその結果を確かめられることにあります。ループの価値は、その合意の内側で調査・実装・検証の往復を委ねられることにあります。

そして、人間のチームに残る仕事は、単なるAIの監視ではありません。どの体験を目指すか、どこで担当を分けるか、何を共有の約束にするか、完成した変更をゲームへ採用するかを決める仕事です。

個別タスクの指示と目的の指示は、置き換えの関係ではなく、チームの裁量を配分する二つの手段です。 目的を共有したうえで、境界が曖昧なら小さく切り、判定できる範囲ならまとまって委ねる。その粒度は担当や工程によって違って構いません。

問うべきなのは、10人それぞれが使うAIがどれだけ長く動いたかではなく、10人が、互いの仕事を壊さず、同じゲームを完成へ近づけられたかです。そこまで含めて改善したときに初めて、相性がよいと言えるのだと思います。

参考資料

外部の事実を述べた箇所に脚注を付けています。それ以外の指示例、構成、運用手順、検証案は本稿の提案です。参照日は2026年10月15日。公式ドキュメントは参照した版での機能説明であり、利用するプロジェクトの版に合わせた確認が必要です。

脚注

1. Anthropic「Demystifying evals for AI agents」、2026-01-09。 ↩︎

2. Addy Osmani「Loop Engineering」、2026-06-07。 ↩︎

3. LangChain「The Art of Loop Engineering」、2026-06-16。 ↩︎

4. OpenAI「Harness engineering: leveraging Codex in an agent-first world」、2026-02-11。 ↩︎

5. Luden.io / Oleg Chumakov「AI Agents in Game Development: FOMO, Real Production Lessons, Failed Experiments, and AI Workshop Plan」、2026-06-10。 ↩︎

6. Kyle Kukshtel「Your Game Is A Harness」、2026-10-10。 ↩︎

7. Anthropic「Effective harnesses for long-running agents」、2025-11-26。 ↩︎

8. Anthropic「Harness design for long-running application development」、2026-03-24。 ↩︎

9. METR「Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity」、2025-07-10。 ↩︎

10. METR「We are Changing our Developer Productivity Experiment Design」、2026-02-24。 ↩︎

11. METR「Measuring the Self-Reported Impact of Early-2026 AI on Technical Worker Productivity」、2026-05-11。 ↩︎

12. Addy Osmani「Practical Loop Engineering」、2026-08-14。 ↩︎

13. Unity「About Unity Test Framework（1.4系）」。 ↩︎

14. Epic Games「Automation Test Framework」。 ↩︎

15. Epic Games「Gauntlet Automation Framework Overview」。 ↩︎

16. Unity「Unity Editor command-line arguments（Unity 6.0）」。 ↩︎ ↩︎

17. Unity「Asset metadata（Unity 6.0）」。 ↩︎

18. Unity「Smart Merge（Unity 6.0）」。 ↩︎

19. Git「git-worktree Documentation」。 ↩︎