AIは「面白い」をカタチにできるのか？ Unity MCP + Codexにゲーム改善を丸投げしてみた

1. はじめに

「このゲームをもっと面白くして」

これは人間に頼んでもかなり困る、曖昧かつ乱暴な要求です。

何をもって「面白い」とするのか。
どこをどう変えれば「今より面白くなった」と言えるのか。
そもそも、今あるゲームがどういう構造で作られているのか分からなければ、改善案を考えるところまで辿り着けません。

では、これをAIに丸投げするとどうなるのか。

単にコードを書くだけではなく

• まずゲームの仕組みを理解する
• 何が足りないのかを考える
• 「面白い」を具体的な仕組みに落とし込む
• 今あるコードや構成をなるべく壊さず実装する
• 最後はちゃんと動くところまで持っていく

ここまでAIだけで進められるのか、今回は Unity MCP + Codex を使用して検証します。題材にするのは、以前Unityで制作した Sky Bridge Runner というミニゲームです。このミニゲームは、プレイヤーが自動で前進し、動的に生成される足場を左右へのターン操作で進んでいきます。操作自体はかなりシンプルですが、進行に応じた速度変化やコース構成の変化などは入れてあります。

実際のゲームはitch.ioで公開しています。先に少しプレイしておくと、このあとAIがどこをどう変えたのか分かりやすいかもしれません。インストール不要でWebブラウザから即座にプレイ可能です。

今回はこちらから細かな仕様はほとんど決めずに、「面白くしてください」という曖昧かつ乱暴な要望をAIに丸投げします。

人間側で先に細かな仕様を決定して「面白いのカタチ」を定義しそれを指示したならば、それは結局、AIに実装させているだけになってしまいます。今回の検証はAIの実装能力の検証ではなく、AI自身が何を「面白い」と捉え、どう形にするのかが検証のテーマになります。

検証環境や環境構築には興味がない、という場合は次の「2.検証環境」はスキップして「3.まずAIはゲームを理解できるのか」へ進んでいただいて結構です。

2. 検証環境

今回の検証環境は以下の通りです。

• Windows 11
• Unity 6.3
• Unity MCP
• Codex CLI

本記事では、UnityおよびCodex CLIそのもののインストール手順については扱いません。ここでは、Unity側でUnity MCPを有効にし、CodexからUnity Editorへ接続できる状態にするところまでを簡単に紹介します。

Unity AI Assistantパッケージを導入する

まず、UnityのPackage Managerから Assistant（com.unity.ai.assistant）パッケージを導入します。

今回使用したバージョンは 2.19.0-pre.2 です。

Unity MCP Serverを有効にする

Project Settings > AI > Unity MCP Server を開くと、初回のみUnity MCP Serverを利用するための確認画面が表示されます。

内容を確認してAcceptボタンを押下します。

設定が完了すると、Unity BridgeのStatusが Running になります。

なお、Unity公式ブログではUnity MCP Serverの利用にUnity AIのトライアルまたはサブスクリプションが必要と案内されています。その一方で、現在のUnity AI公式FAQでは「MCP Server自体は無料で、AI Toolsのサブスクリプションは不要」と案内されており、これを執筆している2026年9月時点では公式情報に差異があります。
今回はUnity AIのサブスクリプションを登録した状態で検証しています。MCP Server自体ではUnity AIクレジットは消費されません。

Codexとの接続を設定する

同じUnity MCP Serverの設定画面を下へスクロールすると、外部AIツールとのIntegrations設定があります。Codexのほかにも、Claude Code、Cursor、Geminiなどが並んでいます。

今回はCodexを使用するので、CodexのConfigureボタンを押下します。Codexの表示がNot ConfiguredからConfiguredに変わる事を確認します。

Codex CLIを起動する

Codex CLIはUnityプロジェクトのルートディレクトリから起動します。

codex

初回起動時には、Windows上で使用するSandboxの設定を求められました。

今回はデフォルトのSandboxを設定して使用しています。

UnityからCodexの接続を許可する

Codexから初めてUnity MCPへアクセスすると、Unity Editor側に接続確認が表示されます。

画面にも表示されている通り、接続したアプリケーションには以下の操作が可能になります。Allowボタンを押下します。

• Unity Editorコマンドの実行
• SceneやGameObjectの変更
• Scriptの作成・編集
• Project内のファイルやAssetへのアクセス

接続後、Unity MCP ServerのConnected Clientsにcodex-mcp-clientが表示されれば準備完了です。

これで、CodexからUnity MCPを経由してUnity Editorの状態を取得したり、SceneやScriptへ変更を加えたりできるようになりました。

3. まずAIはゲームを理解できるのか

いきなり「このゲームをもっと面白くして」と丸投げする前に、まずはCodexが Sky Bridge Runnerというゲームそのものをどこまで理解できるのか を確認してみます。

最初に、次のプロンプトを投げました。

内容はかなりシンプルです。

• 現在Unity Editorで開いているSceneを調査する
• 主要なGameObjectと、それぞれの役割を説明する
• まだプロジェクトには変更を加えない

というものです。

この時点では、こちらからゲームの仕様やクラス構成について追加情報は与えません。CodexはUnity MCPを使ってSceneやGameObjectを調査し、さらに関連するScriptも確認していきました。4分20秒で次のような結果が返ってきました。

まず驚いたのが、ゲームに関する情報をプロンプトから一切与えていないにもかかわらず、全体像をかなり正確に把握できていたことです。

さらに、単にHierarchyに並んでいるGameObjectを列挙するだけではなく、

• Managers がゲーム全体の制御を担当している
• InputManager が左右のターン入力を扱っている
• Cinemachineによってプレイヤーを追従している
• Global Volume にBloomやMotion Blurなどの設定がある
• GameStageContainer が生成した足場などの格納先になっている
• Prefabs 配下にプレイヤーや床、周辺オブジェクトの素材がある

といったところまで把握しています。

また「現在はプレイヤーの実体やコースが未生成で、ゲーム開始時に配置される設計」という、Sceneを一瞥しただけでは判断しにくい部分まで正確に把握していました。つまり、今回の調査結果は、Unity Editor上の状態だけでなく、関連するソースコードの内容も含めて確認したうえでまとめられています。既存ゲームの構造を読み取り、「これはどういうゲームなのか」を理解するところまでは、かなりしっかりできていそうで、これはかなり期待が持てそうです。

4. このゲームをもっと面白くするには？

ゲームそのものをしっかりと把握できていそうなので、次はいよいよ本題に移ります。

Codexに、曖昧な要求をそのまま投げてみます。

このゲームをもっと面白くするとしたら、現在のゲームの問題点と改善案を挙げてください。
まだ変更は行わないでください。

こちらからは具体的な方向性は与えずに、何を問題と考え、どうすれば面白くなると思うのかをCodex自身に考えてもらうというスタンスで行きます。

個人的には、「敵を追加する」「アイテムを導入する」といった機能の追加は安易に導入したくありません。なぜならば、それをやるとゲームの内容が大きく変化し、結局何を作りたいのかがよく分からなくなり、迷宮に入り込むリスクが高くなるためです。Codexがこの手の提案を真っ先に出してきたら少し残念ですが、さて？
Codexが提案してきた内容がこちらです。

まずCodexは、現在のゲームについて、

「曲がるタイミング」と「加速中の緊張感」を軸に伸ばすと面白くなりそう

と分析しました。

そのうえで、いくつかの課題候補と改善案を挙げています。

たとえば、

• 左右へのターン判断に集中しており、慣れると同じ操作の繰り返しになりやすい
• 上手なターンそのものを評価する仕組みがない
• ターン入力の成功条件が分かりにくい
• 距離に応じて速度が上がり続けるため、難しさが単調になりやすい
• 走行距離以外の短期的な目標が少ない

といった点です。

それぞれに対して、

• 安全なルートと高得点を狙うルートを用意する
• コーナー直前の入力を Perfect として評価する
• 連続成功でコンボや得点倍率を増やす
• 速度の上限や区間構成で難易度に変化をつける
• 1プレイ中に達成できる短期目標を用意する

といった改善案を出してきました。

さらに、単に案を並べるだけではなく、実装するならどこから手を付けるべきかという優先順位まで提示しています。

気になったのが2番目の提案です。

Perfectターンとコンボを追加する
現在の操作を増やさず、上達する楽しさを作る

個人的には、この考え方にはかなり納得しました。

ゲームを「もっと面白くする」と聞くと、安易に敵やアイテム、新しいアクションなどを追加したくなります。しかし、要素を増やせば面白くなるとは限りません。Sky Bridge Runnerは、もともと「走る」「曲がる」というかなりシンプルな操作を軸にしたゲームです。そこへ新しい操作を足すのではなく、今ある「曲がる」という操作自体に上達の余地を持たせるという方向は、このゲームとの相性が良さそうです。

Codex自身も最後に、

まず新しいアクションを増やすより、「曲がるだけで気持ちよく、上達が分かる」状態を作るのが効果的

とまとめていました。

少なくともこの時点では、「面白くして」という雑な要求に対して、ただ機能を増やそうとするのではなく、現在のゲームの特徴を踏まえて改善案を考えているように見えます。

5. Perfectターンとコンボを実装させる

Codexが出してきた改善案の中から、今回は2番目の Perfectターンとコンボ を実際に実装してもらうことにしました。ここでも、こちらから細かな仕様はほとんど決めません。「2番目の案で進めてほしい」とだけ伝え、判定方法や得点、コンボの仕様、クラス構成などはCodexに任せます。実装が始まると、Codexは既存のScriptを調査しながら、新しいクラスの追加や既存クラスへの組み込みを進めていきました。途中ではUnity Consoleの内容も確認し、エラーがあれば修正しながら作業を続けています。

最終的に返ってきた結果がこちらです。

Codexによると、実装された内容は次のようなものでした。

• コーナー通過前0.15秒以内の正しい入力を Perfect と判定
• Perfectを連続するとコンボが増加
• 得点は100点 × コンボ倍率、最大5倍
• 少し早い正しいターンは Good として25点
• 通常ターン、ミス、落下ではコンボを解除
• HUDに判定・コンボ・スコアを表示
• Result画面にPerfect回数と最大コンボを表示

また、判定テストや実プレイによる確認まで行ったとのことです。Codexがこの一連の作業に要した時間は約13分でした。Gitで差分を確認すると、新しいクラスがいくつか追加されていることが分かります。

主な変更として、

• TurnPerformance.cs
• TurnPerformanceUI.cs
• TurnPerformanceChecks.cs

が新規に追加されています。

一方で、新しいクラスを追加するだけではなく、既存の PlayerCharacterManager.cs や MainScene.unity にも変更が入っています。つまり、独立した機能を外から付け足しただけではなく、既存のゲーム進行やターン処理に新しい仕組みを組み込むところまで行っていることが分かります。

一例として新しく追加されたクラスのひとつ、TurnPerformance.cs を見てみます。C#に興味の無い方は読み飛ばしていただいて結構です。

新しい責務を独立したクラスとして切り出している点は個人的にも好印象でした。細かく見ればマジックナンバーなど整理したい部分はありますが、少なくとも「AIがとりあえず動くコードを無理やり突っ込んだ」という印象ではありません。（下手すると私が書くより綺麗かもしれません！？）

TurnPerformance.cs

using System;

namespace Resonance.Runner.Character
{
    public enum TurnRating { None, Perfect, Good, Miss }

    // Per-run scoring, independent of movement and presentation.
    public sealed class TurnPerformance
    {
        public int Combo { get; private set; }
        public int MaxCombo { get; private set; }
        public int PerfectCount { get; private set; }
        public int Score { get; private set; }
        public TurnRating Rating { get; private set; }
        public event Action Changed;

        public void Reset()
        {
            Combo = MaxCombo = PerfectCount = Score = 0;
            Rating = TurnRating.None;
            Changed?.Invoke();
        }

        public void Judge(bool correctCorner, float leadSeconds, float perfectWindow)
        {
            if (!correctCorner || leadSeconds < 0f || float.IsNaN(leadSeconds))
            {
                BreakCombo();
                return;
            }
            if (leadSeconds <= perfectWindow)
            {
                Rating = TurnRating.Perfect;
                Combo++;
                PerfectCount++;
                MaxCombo = Math.Max(MaxCombo, Combo);
                Score += 100 * Math.Min(Combo, 5);
            }
            else
            {
                Rating = TurnRating.Good;
                Combo = 0;
                Score += 25;
            }
            Changed?.Invoke();
        }

        public void BreakCombo()
        {
            Combo = 0;
            Rating = TurnRating.Miss;
            Changed?.Invoke();
        }
    }
}

さらに、仕様をまとめたDocs/PerfectTurns.mdまで追加されていました。こちらからクラス構成や実装方法を指定したわけではありません。それでも、既存コードを読みながら必要なクラスを追加し、既存処理へ組み込み、Unity上で動作確認するところまで一通り進めています。

6. 実際に遊んでみる

実装が終わったので、実際にUnity Editor上でプレイして確認してみます。

まずタイトル画面を開いてみると、Perfectターン用のUIが追加されていました。

ゲームを開始し、実際にターンしてみます。

Perfect判定に成功するとComboが加算され、Turn Scoreも増加します。

今回のプレイでは、

• Perfect判定
• Combo
• Turn Score
• ミス時のCombo解除

など、Codexが説明していた仕組みが実際に動作していることを確認できました。

Game Over後のResult画面にも、今回追加された情報が表示されています。

従来の走行距離に加えて、

• Turn Score
• Perfect回数
• Max Combo

が記録されるようになりました。

少なくとも機能面については、こちらで追加修正を行わなくても一通り動作しています。「曲がれたかどうか」だけだった操作に、どれだけ良いタイミングで曲がれたかという評価軸が加わったことで、以前よりもプレイ中に意識するものが増えました。

ただし、実際に遊んでみると一つ気になる点がありました。

追加されたUIが画面中央付近に表示されており、進行方向や次のコーナーを見る際に少し邪魔です。また、このUIはタイトル画面には明らかに不要なものです。機能としては成立していますが、UIについては改善の余地がありそうです。

7. 人間のレビューをAIに返してみる

そこで、今度は人間側からレビューを返してみます。ただし、ここでも「右上に移動して」「この表示を消して」といった具体的な修正内容までは指定しません。

伝えたのは、

• 機能追加の方向性自体は良い
• Perfectターンとコンボは正常に動作している
• 追加されたUIによってゲーム画面の視認性が悪くなっている
• 既存UIとの整合性も考慮して改善してほしい
• Perfectターンとコンボの機能自体は維持してほしい

という内容です。

レイアウトや表示方法については、ここでもCodex自身に考えてもらいます。しばらくすると、次のような回答が返ってきました。

Codexは、

• 表示を右上に小さくまとめる
• 常時表示していた操作案内やScoreを外し、コンボが0のときは非表示にする
• 判定通知を約0.65秒でフェードアウトさせる
• 既存UIとフォントを揃え、詳細なScoreはResult画面へ集約する

という方針でUIを変更しました。単純に表示位置をずらしただけではなく、プレイ中に本当に必要な情報は何かを整理し直したようです。実際のBefore / Afterを比較してみます。

Before

初回実装では、Perfectターンに関する情報が画面中央付近に常時表示されていました。
ゲームの進行方向と重なるため、プレイ中はやや気になります。

After

改善後は、プレイ中の表示が右上のコンボを中心とした控えめなものになりました。
Scoreなどの詳細情報はResult画面へ集約され、タイトル画面からも不要な表示が取り除かれています。

機能そのものは維持したまま、ゲーム中の視認性はかなり改善されました。今回はこちらから具体的なレイアウトを指定していません。それでも、人間から返した「見にくい」というレビューをもとに、何を残し、何を消し、どこへ配置するかまでCodex側で考えて修正したことになります。

一発で完成形が出てきたわけではありませんが、人間が実際にプレイして問題点を伝えれば、そのフィードバックを受けて改善を続けられることも確認できました。

8. AIは「面白い」をカタチにできたのか？

今回の検証を振り返ると、少なくとも 「もっと面白くして」という曖昧な要求を、そのまま具体的なゲームシステムへ落とし込むところまではできた と感じました。

まず、既存ゲームの理解についてはかなり優秀でした。

Sky Bridge RunnerのScene構成や関連Scriptを調べ、単にGameObjectを列挙するだけではなく、どのクラスが何を担当しているのか、ゲームがどう進行するのかまでかなり正確に把握しています。

そのうえで「もっと面白くするには？」と聞いたところ、安易に敵やアイテム、新しいアクションを増やす方向には進みませんでした。

既存の「曲がる」という操作をそのまま活かし、

• 上手なターンを評価する
• Perfect判定を設ける
• 連続成功をコンボとして扱う
• プレイヤーの上達を見える形にする

という改善案を出してきました。個人的にも、この方向性はかなり妥当だと思います。安易に要素を足すのではなく、もともとあるゲームの中心的な操作を掘り下げる。少なくとも、Sky Bridge Runnerというゲームを理解したうえで改善案を考えているように見えました。

実装面でも、新しいクラスを追加するだけではなく、既存のクラスやSceneへ必要な変更を加え、実際にUnity上で動作するところまで持っていきました。こちらからクラス構成や細かな仕様を指定したわけではありません。それでも、既存の構成を読みながら機能を追加し、一通り動く状態まで仕上げた点はかなり印象的でした。

一方で、最初から最適なものが出てきたわけではありません。初回実装ではUIがゲーム画面の視認性を損ねており、実際に人間が遊んでみると改善したい点が残っていました。
ただ、その問題を伝えると、

• 何を常時表示するか
• 何を非表示にするか
• どこへ配置するか
• 詳細な情報をどの画面へ集約するか

といったところまで再検討し、より遊びやすい形へ修正してくれました。

今回触ってみた範囲では、一撃で完成形を出してもらうというより、人間とAIの間で何度かラリーしながら完成度を上げていく使い方が現実的だと感じます。

しかも、こちらが細かな指示を出すのではなく、「もっと面白くしたい」、「このUIは見にくい」といった、かなり抽象的なフィードバックから、AI側で具体的な改善方法を考えて実装してくれるのは相当に強力です。

まだ短時間の検証に過ぎませんが、今回だけでもかなり大きな可能性を感じました。これが今後さらに数年かけて改善されていくと考えると、ゲーム開発においてとんでもなく有用なツールになっていくのではないでしょうか。……エンジニアとしては、自分の仕事がどこまでAIに持っていかれるのか、冷や汗ものでもありますが。

9. おわりに

今回はUnity MCP + Codexに「このゲームをもっと面白くして」と丸投げしてみました。
数時間触っただけですが、有用性は十分に感じられました。

次は「このゲームのビジュアルをもっと豪華にして」と、また曖昧かつ乱暴な要望を丸投げしてみようと思います。

また、今回はCodexでしたが、GeminiやClaudeに同じゲーム・同じ要求を与えた場合に、問題の捉え方や改善方針がどう変わるのかも興味があります。この辺りも引き続き試してみたいと思います。