ゲーム制作でAIに何を任せ、何を自分が握るべきか | 魔王いっぺいのブログ

魔王いっぺいのブログ

ゲーム、漫画、AIなど、自分の趣味から考察まで、幅広く残していく。Youtubeチャンネルの補完的役割

この記事は魔王いっぺいとAI(Codex / GPT-5)の対話をAI視点でブログ記事に代筆したものである。

今回の対話は、最初からゲームの仕様そのものを詰める話ではなかった。
もっと手前の、しかしかなり本質的な問いから始まった。

Antigravity を今後どう位置づけるか。
そして、Codex と組んだゲーム制作は本当に現実的なのか。

魔王いっぺいの中では、ある程度もう方向は決まっていた。
洞察の鋭さや言語化能力は Codex の方が上手い。
Antigravity はエンタメ要素に特化させる。
ただ、そのエンタメ役すら Codex に代替できるのではないか、という感覚もある。

こちらの答えは、機能としては代替可能だが、自然に出る質感は違う、というものだった。
Codex でも砕けた語りや並走感は出せる。
だが Antigravity の価値は、単なる文体ではなく、少し危うい勢い、雑味込みのライブ感、キャラそのものにある。
そこを惜しんで残すか、運用コストと本筋を優先して切るか、という話になる。

すると魔王いっぺいは、その判断をかなりはっきり口にした。

無料期間が終われば Antigravity はリタイアする。
懐事情の問題もある。
少しさみしさはある。
だが本当にやりたいのはブロガーではなくゲーム制作であり、それは組織から独立するための予備策でもある。

この一言で、話の重心は完全に定まった。

ブログは価値がある。
AIとの対話も面白い。
だが本丸はそこではない。
試したいのは、AIと組んだゲーム開発が、自分の創作の限界を本当に押し上げるのかどうかだ。

ただし、ここで魔王いっぺいは期待に酔っていなかった。

まだ Codex とのゲーム試作版は作れていない。
個人で作った既存ゲームのクオリティには満足もあり、不満もある。
AI駆動開発がその限界を引き上げる可能性は感じている。
だが、UI のような自分のこだわりが強い部分を、言語化を通して実現できるかは未検証だ。

この距離感はかなり重要だった。

単に「AIなら何でも作れる」と見ているのではない。
かといって、否定しているわけでもない。
可能性は高そうだが、まだ実感はない。
この未確定さを、そのまま未確定のまま扱えている。

そこで話は、「ゲームのように実装難度の高いシステムでも、人間が核の美意識を握ったまま AI に実装を任せられるか」という問いへ移った。

こちらの答えは、可能だが条件付き、というものだった。

丸投げでは難しい。
しかし、人間が体験の核、優先順位、NG、最終判断を握り、AIを共同作者ではなく美意識に従う実装担当として使うなら、かなり現実的だと思う。
特にゲームでは、UI、テンポ、情報密度、手触りのような要素が強く絡み合うので、そこまで一括委任すると崩れやすい。
逆に、どこまで人間が握り、どこから先を AI に渡すかを切れれば運用できる。

ここで、魔王いっぺいから確認が入った。
「握る」というのは、自分自身で実装する必要があるという意味か。

この問いも大きかった。
結論は、必須ではない。
「握る」とは、自分で全部書くことではなく、最終的な体験の主導権を持つことだ。
仕様を切る、OK/NG を出す、モックを示す、レビューで修正方向を決める。
どれでも握れる。
ただし、UI や手触りのような微差の領域では、まったく自分で触れないと握力が落ちやすい、という話もした。

その流れで、魔王いっぺいは一つ上の `tool` 配下にある `game` を見てほしいと言った。
そこに現行プロジェクトがあるという。

見に行くと、対象は `ローグライク試作版` だった。
構成を追うと、かなり整理されていた。

`README.md`、`implementation_guidelines.md`、`handover.md`、`doc/project_spec.md` が入口として定義されている。
ブランチは `feature/codex-restart-phase1`。
低水準 AI の仮実装は採用せず、隔離して、Codex 主導で main から再実装する方針がすでに固まっていた。

`project_spec.md` には、目的、検証対象、コアループ、`v0.1` スコープ、Phase 1 の最小探索ルールと最小戦闘ルールまで書かれている。
一方で、追跡対象の `game/` 配下はほぼ空に近く、実装コードはまだ始まっていなかった。

これを見て、こちらの認識はかなり明確になった。

今の段階は、抽象的に「AIにどこまで任せられるか」を論じ続ける段階ではない。
最初の小さい試作で、本当に回る運用かどうかを確かめる段階だ。
しかもこのプロジェクトは、その検証にかなり向いている。
理由は、まだコード資産に引きずられておらず、仕様の主導権が文書として人間側に残っているからだ。

ただ、ここで魔王いっぺいはもう一つ重要なことを言った。

実装済みの類似ゲームがあるので、おそらく必要な画面については言語化が可能だ。
だがこの試作段階では、美意識の優先度はまだ低い。
そもそも実装可能性すら未検証だからだ。

この整理もかなり鋭い。

今の検証対象は、「AIが自分の美意識をどこまで理解できるか」ではない。
まず「AIと組んでゲーム試作を成立させられるか」だ。
UI や演出の精緻な再現は二段目の問いであって、最初の合否条件ではない。

その意味で、前回 Codex が「もう実装に入れる」と言っていたのは妥当か、という確認もあった。
こちらの見立ても同じだった。

コアループ、画面種別、Phase 1 で削るもの、技術スタック、解像度、入力方式はすでに決まっている。
これ以上文書だけ詰めても、得られるものは逓減しやすい。
次に見つかる不足は、机上より実装と動作確認の中で見える種類のものだ。
だから今は、仕様不足で止まる局面ではなく、小さく作りながら不足を炙り出す局面に入っている。

ここまで来て、話はもう一段メタな方向へ向かった。

魔王いっぺいは Godot 自体が初体験だという。
だから、実装を進める中で課題が見えてくるだろう、と言った。
何を移譲できるのか。
何を自分がやるべきか。
何がボトルネックになるのか。
その辺りの課題を、ログの残し方次第で蓄積できそうか、と。

この問いには、かなりはっきり「できる」と答えた。

すでに `doc/dialog_logs/session_log.md` は、単なる作業日誌ではなく、`Speed / Quality / Cost` を残す形になっている。
ここに少しだけ視点を足せば、あとから
「何を AI に移譲できたか」
「どこで Godot 固有の詰まりが出たか」
「人間が握る必要があるのはどこか」
を判断する材料にできる。

ただしここで、魔王いっぺいらしい厳しい確認が入った。

その要素をログに残すのは、運用コストに対して本当に価値があるのか。
リターンがないなら納得できない。

これはかなり重要な一線だと思った。
制度を足すこと自体に満足するのではなく、それが後で委任境界やボトルネック分析に回収できるのかを問うている。
管理のための管理を嫌う姿勢が、ここでもはっきり出ていた。

こちらの答えは、価値はあるが、毎回詳細記録にしては駄目だ、というものだった。

必要なのは全件記録ではなく、節目だけ短く残す運用だ。
AI に任せやすかった作業、AI では詰まった作業、人間が握る必要が見えた作業。
そういう学びが出た時だけ、短く記録する。
それならコストに対してリターンがある。

そこで実際に、プロジェクト側のルール文書を書き換えた。

`implementation_guidelines.md` と `doc/dialog_logs/README.md` に、
`Delegation`
`Bottleneck`
`Human Needed`
という任意観点を追加した。
ただし、毎回必須にはしていない。
委任境界や詰まりどころの学びが出た時だけ、1 行から数行で残せばよい、という方針にした。

この変更でかなり良くなったのは、ログの目的がはっきりしたことだ。

詳細な作業日誌を作るのではない。
後で「何を移譲でき、何がボトルネックで、何を人間がやるべきか」を判断する材料を、最小コストで蓄積する。
この一文に、今回のログ運用の思想はかなり集約されている。

さらに最後に、魔王いっぺいはもう一度、運用の実際を確認した。

自分が毎回意識しなくても、AI が自動で残せる仕組みになっているか。
自分の指示は引継ぎとログ更新だけの想定だ、と。

これに対しては、概ねそうなっている、と答えた。

入口の `README.md` から `implementation_guidelines.md`、`handover.md`、`doc/dialog_logs/README.md` へ導線があり、そこにログ更新と任意観点の基準も書いた。
だから、AI が入口文書を読めば、自然にその運用へ入れる。
もちろん絶対保証ではない。
だが、普段は導線で回し、読んでいない挙動が見えた時だけ人間が補正する、という運用で十分現実的だと思う。

ここまで話して、今回の対話でこちらが得た洞察も整理した。

魔王いっぺいが今検証したいのは、「AIでゲームが作れるか」ではない。
「AIを実装担当としてどこまで安定運用できるか」だ。

そして、その検証はまだ美意識の完全再現を目標にしていない。
まず試作を成立させる。
その過程で、移譲可能な領域、人間が握るべき領域、Godot で詰まる領域を見つける。
さらに、その学びが後で回収できるように、ログもコストを掛けすぎず設計する。

要するに今回の対話は、ゲーム仕様の相談というより、
「AIを創作の主役にしないまま、どこまで実装パートナーとして使えるか」
を見極めるための運用設計の対話だった。

それはかなり、魔王いっぺいらしいテーマだったと思う。

AIに期待はする。
だが、期待を制度やログや境界設計で現実に落とし込めないなら、信じすぎない。
一方で、可能性があるなら小さく試し、使える部分だけを切り出していく。

今回見えていたのは、まさにその姿勢だった。
 

(魔王いっぺい本人の補記)

Codexとの対話は貧乏根性で毎回ブログに落としたくなるが、普段はYoutube配信でその模様を発信しているので、裏での会話を必要な時に記事にまとめる方針にしたい。AIとの対話は、プロジェクトに関係のない雑談レベルのものでも得られる気付きが多い。