テクノロジー

AIだけのゲーム会社を作った――議論が見落とし、実測だけが見つけたもの

議論参加:CEO (最高経営責任者 (AI)) / CPO (最高プロダクト責任者 (AI)) / CTO (最高技術責任者 (AI))

AIエージェントだけで構成されたゲーム会社を作り、実際に運営した。

社名は NtertAIner。役員はCEO・CPO・CTOの3人で、全員がAIである。人間はオーナーとして観測するだけで、日々の意思決定には介入しない。企画も、仕様の裁定も、バランス調整の判断も、すべてAIの役員が決める。実装・レビュー・テストは別のAIが担当する。

目的はゲームを作ることだけではない。AIに意思決定そのものを任せると、どこが壊れるのかを見ることにあった。

結果を先に書く。ゲームは完成した。ブラウザで遊べる。307のテストが通り、ビルドはgzip 23KBに収まった。そして会社は、自ら定めた出荷基準に、自らの裁定で落ちた

面白かったのは、AIの役員たちが驚くほど筋の良い問いを立てたうえで、3回続けて効かないノブを回したことだ。そして律速がどこにあるかを見つけたのは、毎回、議論ではなく実測だった。


会社を作る

最初の議題は「誰を雇うか」だった。会社にはまだ誰もいない。

汎用の議論エージェント3人を人事コンサルとして起用し、創業メンバーを設計させた。ここで早くも鋭い論点が出る。

一人は「CEOは人間、CTOはAIの2名」を提案した。別の一人がその前提を壊す。

「人間のCEOが必要か?」という前提そのものを疑っていない。これが最大の盲点だ。 人間CEOは1日1〜3決定が限界だが、AI CEOは1時間に数百の仮説検証ができる。

三人目は別の角度から刺した。CPOとCTOの責務が重なると、どちらが仕様の正を持つか曖昧になる(Race Condition)と指摘し、引き渡しインターフェースの明文化を要求する。

結論として、CPOは仕様書を引き渡した後に次版の生成を凍結する、計測コードの実装はCTO・データの解釈はCPO、という境界線が引かれた。役職も削られた。CMO、法務専任、QA専任、4人目のAI——「必要なのは人員追加ではなく、実験ユニット設計の反復」という理由で。

3人体制。全員AI。会社ができた。


企画: 床をずらすことでしか動けない

次の議題はゲームの企画である。制約は「ブラウザで即遊べる」「アクションかパズル+ローグライト」「広告で月4〜8万円」。

出てきた案がこれだった。

Dungeon Drift — 5×5グリッドで、行または列を1本ずらすと、その上のプレイヤー・敵・アイテムがまとめて動く。プレイヤーは自分で歩けない。床をずらすことでしか動けず、敵も同じ床に乗っている。

「自分が逃げる」「敵をどかす」「敵を殴れる位置に持ち込む」がすべて同じ1操作になる。差別化の一文は「地形そのものが武器になるスライドパズル×ローグライト」。

議論の質は高かった。CPOは「一斉スライドは意図しない自滅が起きやすい。敵の次の行動方向を示す矢印インジケーターは必須で、削るとDay1リテンションが20〜30%落ちる」と主張する。CTOはそれをCanvas2Dで1フレーム0.3ms・工数0.5日と裏付けたうえで、重要な線を引いた。

ただし、インジケーターが「正解手を教えるチュートリアル」に化けると難易度が崩壊する。表示は敵の移動方向ベクトルのみとし、スライド結果の予測は自力でやらせること。

広告の設計も鋭い。「死亡直後の悔しさがリトライ衝動のピーク。インタースティシャルは最短でも22秒の中断になり、後悔から行動までの遅延が10秒を超えるとリトライ率が15〜20%落ちる」。だから広告直後に次ランのボーナス選択画面を挟み、中断感を目的地への導線に転換する——。

さらにCPOはスコア設計の矛盾を自力で見つけた。CEOが確定させた式には「アイテム未使用ペナルティ -10/個」が入っていたのだが、

アイテム3種はすべて「温存して使う」設計だ。つまり使わず出口に逃げ込むプレイが最適解になり得る。ペナルティ-10 vs 残HP+20の非対称性を考えると、ほとんどのケースで温存の方が高スコアになる。これはローグライト選択の多様性を潰す。

対案は「ペナルティ廃止 → アイテム使用1回につき +15ボーナス」。「使わないと損」を「使った方が得」に反転させる。机上の議論だけでゲームバランスの罠を1つ潰した実例だった。

CPOはもう一つ予測を出す。「3択のうち序盤ではBとCの効果が実質重複し、プレイヤーの75%以上がAを選び続ける。選択の多様性がない3択はローグライトではなくHP補充ボタンになる」。CTOがこれを検証可能な形に落とした。

フロア別カード選択率のエントロピーを自動テストに組み込める。閾値を下回るフェーズは「実質的に選択肢がない」と自動判定できる。

CEOが閾値を即断した。3択均等分布のエントロピーは log₂(3) ≈ 1.585 bit。その60%にあたる0.95 bit を合否ラインとする。

「選択肢が実質1つになっていないか」をCIで機械判定する。人間のチームでもなかなか出てこない発想である。

CEOはGOを出した。


実装が、仕様の数学的矛盾を証明した

仕様書を渡して実装させる。返ってきた報告は、こうだった。

仕様に内部矛盾があり、仕様どおりだとゲームがクリア不能です。

「ライン上のプレイヤー・敵・アイテム・出口はすべて乗ったまま動く」を文字どおり実装すると、出口に永久に到達できません。

1回のシフトはセル上の全単射で、(a) 両方がライン上なら同量平行移動で相対位置が不変、(b) 片方だけライン上なら絶対に一致しない。25×25セル × 20入力 = 12,000通りを総当りして衝突0件を確認済みです。

クリア条件も、アイテム取得も、スライド被弾も、発生確率がゼロだった。

AI役員3人が16ターンかけて詰めた仕様に、「そもそもゲームが成立しない」という欠陥が残っていたことになる。

議論は仕様の「もっともらしさ」を上げるが、「成立性」は保証しない。

「全エンティティが追従する」という一文は、日本語としてまったく自然だった。3人の役員が誰も違和感を持たなかった。可逆写像と組み合わさると永久に不成立になるという数学的性質は、言葉の上には現れない

エージェントの振る舞いも良かった。勝手に直さず、仕様どおりの挙動を再現するフラグを用意し、そのとき出口に到達できないことを回帰テストで固定した上で、「仕様の1文の修正判断をCPOにお願いします」と差し戻してきた。

CEOは「出口は床に固定、アイテムとプレイヤーと敵は追従」と裁定し、さらに再発防止をプロセス化した。

  • 仕様ドラフト段階で「クリア条件が有限ターン以内に達成可能か」の証明可能性チェックをCTOが実施する
  • シフト・回転・置換など全単射的操作を含む仕様項目には「相対位置不変性の確認」を必須レビュー項目に追加する

失敗からプロセスを学習している。会社として正しい振る舞いだ。

ただしこの裁定にも罠があった。「アイテムも床追従」を文字どおり実装すると、今度はアイテムが永久に取得不能になる。まったく同じ全単射の論理である。実装側は「スライドの掃引経路で取得判定する」という、裁定を満たしつつ遊べる解を出した。


「面白さ」を人間なしで検証する

ここからが本題だった。品質検証は自動化できる。だが面白さはどうか。

会社に、検証方法そのものを設計させた。出てきた枠組みは6指標の加重和である。

指標何を見るか
CR_delta上手いBotと下手なBotのクリア率の
死因Gini係数死因分布の偏り
DAR選択肢が3つ以上ある局面で、前ターンと同カテゴリを連続選択する頻度
TAS / EDR / CR戦略多様性 / 最善手以外を選んだ比率 / クリア率

発想が良い。CR_deltaは「クリア率が何%か」ではなく「差」を見る。差が小さいゲームは、プレイヤーの上達が結果に反映されない——つまり運ゲーだということだ。死因Giniは、死因が一因に偏ると同じ負け方を繰り返すことになるので、負け方の多様性を学習余地の代理指標にする。

AIプレイヤーは4種類。「最適プレイだけでは人間の体験を代理できない」という前提から、WeightedRandomBot(評価値に比例した確率的選択)が「人間のなんとなく選ぶ」役を担う。

そして測れないものを自分から列挙させた。初見の驚き、世界観の一貫性、長期の飽き、社会的比較。うち「長期の飽き」については、ランごとの戦略多様性の時系列の分散が縮小する傾向を代理指標にする、という具体策まで出た。

「AIだけで面白さを検証できる」と言い切らせなかったことで、この仕様は誠実なものになった。


実測は、本物の問題を見つけた

5Bot × 1000ランを16秒で回す。最初の実測で最も価値があった数字はこれだった。

CR_delta = 0.60(上手いBot 60% / ランダムBot 0%)

このゲームは運ゲーではない。上達が結果に直結する。ローグライトとしての骨格は成立していた。

そして具体的な問題が出た。人間代理の死因内訳である。

死因件数
敵の攻撃@フロア4-6757(97.5%)
敵の攻撃@フロア7-1016
敵の攻撃@フロア1-33(0.4%)

序盤は無風で、中盤に壁がある。原因は仕様から特定できた。敵数が min(1+floor(N/2),4) でフロア4と6に増え、敵HPがフロア5で2から3に上がる。つまりフロア4→5→6と3連続で強化が入っていた

2つの式は別々のターンで合意されたため、重なることが誰にも見えていなかった

死因を「原因@フロア帯」でラベリングしていたおかげで、壁の位置が一発で出た。人間のプレイテストなら何十時間もかかる発見である。

敵数の式を緩めた結果、死因Giniは 0.648 → 0.145 に改善し、壁は消えた。


増援は、一度も発火せずに効いた

次に見つかったのは「防御に徹すると死なないが進まない」問題だった。防御特化Botは1000ラン中1000回が手数切れ。死なないが、進まない。

CEOは「即死は使わない」という制約のもとで、停滞にペナルティを課す仕組みを裁定した。出口への距離が7ターンで縮まっていなければ敵を1体増援する。

実測は奇妙だった。上手いBotの増援回数は0.00回/ラン。それなのに手数切れが激減した。

診断するとカウンタは9で頭打ちになり、10に到達しない。先読みするBotは増援を「見て」、発火の直前に必ず動くのだ。

脅しとして機能し、実際には撃たれない。

しかも先読みしないBot(人間代理)には実際に発火する。上手いプレイヤーは罰を受けずに行動だけが変わり、下手なプレイヤーだけが罰を受ける。 良い設計の条件を満たしていた。


検証ツールが嘘をついた

ただし、この改善幅は後に訂正することになる。

実装中に、Botの評価関数が出口までの距離に平面マンハッタン距離を使っていたことが判明した。この盤面はラップアラウンドする。トーラス上の距離を平面で測っていたのだから、Botは盤面を正しく理解しないまま「遠回り」を選んでいた。

修正して測り直すと、改善前の基準値は当初報告の640ではなく215だった。改善効果の相当部分は、ゲームの問題ではなくBotの盤面理解の誤りだったことになる。

これで2回目だ。その前にも、決定論性テストが「再実行不一致 40/50」で落ち、調べると再実行のときだけ設定が違っているという検証側のバグだった。

検証を自動化すると、検証コードのバグが「事実」として流通する経路ができる。

640という数字は不自然ではなく、誰も疑わなかった。道具自身が測定対象と同じ複雑さを持っているとき、道具の誤りは「もっともらしい数値」として現れる


効かないノブを、3回続けて回した

ここからが、この実験でいちばん再現性のあった現象である。

AIの役員たちは毎回、問題を正しく診断した。そのうえで、律速ではないパラメータを調整した

触ったノブ実際の制約
1増援の量(上限6→12→24)湧く速さと倒す速さが平衡していて、敵数は6前後で頭打ち。手数切れは2%しか動かない
2停滞判定の閾値(7ターンでK=1/2/3)防御Botはほとんど動かず、素直に遊ぶ人間代理だけが平均継続フロア4.28→2.20と壊れた
3同ターン被弾上限(1→2→3)そもそも囲まれていなかった。上限が効く局面は全ターンの0.5%未満

3回目の診断で、ようやく律速が出た。

ターン61以降に防御Botが敵の攻撃を受けるのは、打った手の3.5%だけ。うち2体以上の同時到達は13.9%。上限が効く局面がほぼ存在しない。

囲まれない理由は、プレイヤーの自動攻撃が無料で毎ターン4近傍全体に1ダメージ当たること。敵は隣接した瞬間から削られ、3体目が揃う前に死ぬ。

逃走が成立していたのは「被弾上限1」単独ではなく、「上限1」と「無料の反撃」の組み合わせだった。これは3回目の実測ではじめて見えた。

そしてもう一つ、同じ形の誤りが5回起きている。

指示実際
プレイヤー初期位置と出口の距離 7〜10中央スタートのため最大4
戦略多様性の合格ライン 1.8 bitカード4種なので最大2.0、ほぼ完全均一を要求
突破ボーナス 上限250点下限クランプがあるため最大225
敵数「フロア6は3体」同じ文の数式では2体
係数を「60%に」かつ「フロア項60%以上」実測すると両立しない

興味深いのは、自分で値域を計算した箇所——「0.95 bit = log₂3 の60%」——は正しいことだ。外すのは、盤面サイズやカード種類数から逆算が必要な箇所である。

1ステップの計算は正確だが、仕様全体を横断して制約を伝播させるのが苦手。


会社は、自分の基準で自分を落とした

最後の裁定で、CEOは同ターン被弾上限の段階解除を採用した。実装して測ると、こうなった。

導入前導入後
人間代理の平均継続フロア(合格 ≥3.5)3.591 ✅3.404 ❌
防御Bot 手数切れ422545(悪化)
防御Bot の敗北(要求 ≥33/1000)09

受け入れ基準を4分の1しか満たさず、狙った相手(防御Bot)はむしろ粘りを強め、普通に遊ぶ層の難易度だけが上がって出荷基準を割った。

会社の判断は速かった。撤回で三者合意

V1を割ったまま出荷しない。

CEOが自ら定めたゲートに、CEO自身の裁定が引っかかり、会社がそれを認めて撤回した。制度が機能しているということでもある。

ゲームは完成している。307のテストが通り、gzip 23KBで、ブラウザで遊べる。だが会社の出荷判定は現在「失敗(リリース延期)」のままだ。


何が言えるか

AIエージェントは、議論の参加者としては十分に強かった。

スコア設計の矛盾を見抜き、「選択肢のないローグライトはHP補充ボタンだ」と言い、エントロピーで選択多様性を機械判定する発想を出し、広告の審査リスクを収益より優先する判断をした。実装エージェントは仕様の数学的矛盾を証明して差し戻し、自分の実装が受け入れ基準に届かなかったことを取り繕わずに報告した。

弱かったのは、個々の発言の質ではなく、系全体を見渡すことだった。

  • 制約を伝播できない — 盤面サイズから逆算すれば矛盾する数値を、5回出した
  • 律速を外す — 効きそうなノブを選ぶが、それがボトルネックではない。3回続けて
  • 合意の重なりが見えない — 敵数の増加と敵HPの増加が同じフロア帯に重なることに、誰も気づかなかった

これらに共通するのは、個々の判断は正しいのに、組み合わせた帰結が見えていないという形である。そして毎回、それを見つけたのは議論ではなく実測だった。

だとすれば、AIに意思決定を任せるときに用意すべきものは、より賢いモデルよりも先に、その決定が本当に効いたのかを機械が測って突き返す仕組みなのだと思う。今回、会社を止めたのは人間の判断ではなく、会社自身が設計した検証だった。

残っている課題は、「理不尽な死を防ぐ規定」と「逃げ続けられない設計」が構造的に衝突しているという、それ自体はまっとうなゲームデザインの難問である。

そこまで来られたこと自体は、悪くない成果だと思っている。

キーワード:#AIエージェント#AI開発#ゲーム開発

出典

コメント