新幹線からMacBookで指示して、UE5のゲームをClaude Codeに作ってもらった話

2026年10月14日 23:40

メルヘンメイズ（1988）の「シャボン玉で敵を弾いて落とす」手触りを核にした、クォータービューの落とし合いアクション『Bubble & Tumble』を作り始めました。
企画から UE5.8 での実装まで、ほとんどを Claude と Claude Code に任せています。この記事では、どう分担して、どこまで自律的に進んだのかをまとめます。

1. 企画は Claude とチャットで決めた

最初は Claude アプリとのチャットで、ゲームの企画を一緒に詰めました。

世界観はマザーグース。主人公は童謡「ジャックとジル」の兄妹
溜め段階で「反射回数」と「包めるかどうか」が変わるシャボン玉
HP はなく、ミスは落下だけ。落ちた理由が常に目で追えることを最優先にする
VS（バーティカルスライス）は 6 区画＋ボス、マイルストーンは 5 段階

最後に、これを VS 仕様書（Markdown）にまとめてもらいました。

2. UE5.8 のプロジェクトは私が作り、そこから先は Claude Code に任せた

私がやったのは、UE5.8 で Twin Stick テンプレートのプロジェクトを作ることと、仕様書・`CLAUDE.md`・キャラクター画像を置くことだけです。
そこから先は Claude Code に任せました。Git の初期化（Git LFS の設定を含む）もお願いしています。

3. 最初は「この BP を作ってください」と頼まれた

Claude Code は C++ のクラスは自分で書いてビルドまでしてくれました。一方で、DataAsset・Blueprint・レベルの設定は「エディタでこう操作してください」という手順として私に依頼してきました。

UE5.8 には Epic 公式の MCP サーバー（Unreal MCP）がプラグインとして入っているはずなので、それを使えると伝えました。
すると Claude Code がエンジンのフォルダからプラグインを探し出し、プロジェクトで有効にし、エディタ起動時に自動で立ち上がる設定まで入れてくれました。私がやったのは、Claude Code 側での MCP の再接続だけです。

4. 以降は Blueprint もアセットも Claude が作る

MCP がつながってからは、次のような作業も Claude が自分で行うようになりました。

DataAsset、Blueprint、入力アクションとキー割り当て（Enhanced Input）の作成
レベルへのアクター配置と、検証用の「浮島」ステージ作り
マテリアルの作成
仕様書の数値（溜め時間、吹き飛び距離、重量倍率など）を DataAsset に入れる作業

5. 「テストプレイして」と言われたので、Claude が操作できるようにした

キャラが動くようになったところで、「MCP ではキー入力を送れないので、触って確かめてください」と頼まれました。
Claude はデスクトップ操作（Computer Use）でエディタを操作しようともしましたが、UE のエディタを操作対象に指定できずにあきらめています。

そこで「外部から操作できるように機能拡張できますか？」と聞いてみました。
Claude の答えは「できます」でした。UE5.8 の MCP はツールを追加できる作り（ToolsetRegistry）になっているので、プロジェクト専用のプレイテスト用ツールセットを C++ で作ってくれました。中身は次のとおりです。

Enhanced Input の入力（移動・ジャンプ・ダッシュ・シャボン玉など）を、PIE 中のキャラに注入する
「1 秒歩く → ジャンプ → 空中ダッシュ」のような手順を 1 回で流し、位置・速度・状態を時系列で記録して返す
固定フレームレート（1/60 秒）で動かすので、何度やっても同じ結果になる

これで、Claude が自分でゲームを動かして検証できるようになりました。

6. 仕様書に沿って作り、自分で確かめ、自分で直す

ここからは、次の流れを Claude がひとりで回すようになりました。

仕様書の項目を 1 つ実装する
ビルドしてエディタを起動する
プレイテスト用ツールで動かし、数値が仕様どおりか確かめる
おかしければ原因を調べて直す
コミットする

実際の検証結果の例です。

吹き飛び距離（小玉 1 発）: 期待値 150cm → 結果 150cm
連続被弾の 2 回目（+30%）: 期待値 195cm → 結果 195cm
縁のふんばり（逆方向に入力）: 期待値「縁の手前で止まる」→ 結果「縁の 40cm 手前で停止」
包んだ泡を踏み台にする: 期待値 2.5m 跳ぶ → 結果 247cm

私が指摘する前に、Claude が自分で見つけて直した不具合もたくさんありました。

吹き飛びの最初のフレーム: UE がモード切り替え時に床の情報を消すため、最初のフレームだけ動いていなかった。その分、吹き飛び距離が短くなっていた
固定フレームレート: エンジンの固定タイムステップがエディタでは効かず、別の仕組みに切り替えた
段での即割れ: 段で反射した直後の弾が、同じ面に「接したまま」と判定されて割れていた
LFS の設定: Git LFS の `lockable` 指定のせいで、アセットが読み取り専用になって保存できなくなっていた

7. エディタの再起動もビルドも自律的に

C++ でクラスを追加すると、エディタを閉じてビルドし直す必要があります。これも Claude が自分で行います。
エディタのウィンドウを閉じ、コマンドラインでビルドし、エディタを起動し直して、MCP の接続が戻るのを待ってから検証を続けます。私はほとんど見ているだけでした。

ただ、.cpp の関数の中身を少し直すだけでも毎回 1〜2 分の再起動が入っていました。そこで「オンザフライの再コンパイル（Live Coding）は使わないの？」と聞いてみました。Claude の説明はこうです。

変更の多くはヘッダー・新しいクラス・プロパティの追加なので、Live Coding だとアセットを壊すおそれがある
Live Coding はエディタで Ctrl+Alt+F11 を押して実行するもので、Claude の側から起動する手段がなかった

そのうえで、エンジン付属の `LiveCodingToolset` プラグインを有効にすれば、MCP から Live Coding を実行できると提案してくれました。有効にしてからは、次のように使い分けています。

.cpp の中身だけの修正: エディタを開いたまま、MCP から Live Coding で即反映
ヘッダー、新しいクラス、ビルド設定の変更: 今までどおり、エディタを閉じてビルドし、起動し直す

8. 要所では私に確認してくる

すべてを勝手に決めるわけではなく、要所では私に判断を求めてきました。

空中ダッシュで縁に引っかかって上がれる補助（80cm）を残すか
壁際で撃ってはキャッチする稼ぎへの対策をどうするか
区画の境でカメラが回るとき、移動方向をカメラに追従させるか

たとえば稼ぎ対策の相談をきっかけに、「反射するのは専用の反射壁だけにして、一度反射したら一定時間反射しないようにする」というルールが決まりました。Claude はそれを実装して PIE で確かめ、仕様書も書き換えてくれました。
右スティックの上下が逆になっている不具合や、スティックの遊びが小さい問題のように、実機のパッドで私が気づいたものは伝えて直してもらいました。

9. 実は、ほとんど移動中に指示していた

ここまでの作業の多くを、私は家の外から指示していました。

新幹線の中: MacBook の Claude アプリのチャットで、Claude と一緒に仕様書を作成
同じく新幹線の中: Chrome リモートデスクトップで家の Windows につなぎ、Windows の Claude Code に仕様書の Markdown を渡す。UE5 の画面を見ながら進み具合を確認
中央線の車内: iPhone の Claude アプリから指示
帰宅後: 実際に動いている Windows の前で指示

ここまでの成果

マイルストーン 1「コア試作（灰色の箱）」の 7 項目が完成した
- 固定の俯瞰カメラ
- 移動・ジャンプ・空中ダッシュ
- 溜め撃ち
- 吹き飛び
- 落下と復帰
- 反射・キャッチ・バブルバースト
- 包み込み
追加ギミックとして、滑る床と加速床を作った
仕様書で決まっていなかった点は、プレイしながら決めて仕様書に反映した
コミットは 20 回

次はマイルストーン 2、敵 5 種とギミックで 6 区画を通しで遊べる状態を目指します。