ChatGPTで仕様を考え、Codex CLIで実装する ― 初めてのMinecraft MOD開発記録

はじめに

「Groundedにあるようなジップラインを、Minecraftでも使えたら面白そう」
そんな思いつきから、MinecraftのMOD制作に挑戦してみました。

今回参考にしたゲームは、サバイバルアドベンチャーゲームのGroundedです。
Groundedには、拠点間をワイヤーでつないで移動するジップラインや、上り方向にも移動できる「ZIP.R」という装置があります。

これをMinecraftでも使いたいと思い、次のような機能を目標にしました。

• 支柱を自由に設置してワイヤーを張れる
• 1つの支柱から複数の支柱へ接続できる
• ワイヤーの途中から乗れる
• 下り坂では加速する
• GroundedのZIP.Rのように、装置があれば上り坂も移動できる
• サバイバルモードで素材を集めて建設できる

私は今回が初めてのMinecraft Java EditionのMOD制作でした。
そこで、ChatGPTに設計や実装手順を相談し、Codex CLIにコードの作成・修正を依頼するという方法で開発してみることにしました。

今回の開発では、Codex CLIへ渡す実装・修正用の指示文章も、すべてChatGPT（GPT-6）に作成してもらいました。
自分が作りたい機能や動作確認で見つけた問題をChatGPTに伝え、ChatGPTが作成した指示文をCodex CLIへ渡す、という進め方です。

最終的には、当初考えていた主要な機能をひととおり実装し、Minecraft内で動作確認するところまで進められました。

この記事では、完成したMODの紹介とともに、開発環境の構築、AIとの役割分担、実際にCodexへ渡した指示、何度も変更した仕様についてまとめます。

※この記事は、実際に開発した個人MODの記録です。記載しているバージョンは、開発時の環境に基づいています。

完成したもの：Trail Ziplines

作成したMODの名前は Trail Ziplines です。

Minecraft Java Edition 1.21.11向けのFabric MODとして作成しました。

主な機能

機能	内容
ジップライン支柱	ワールド内に自由に設置できる
多対多接続	1つの支柱から複数の支柱へ接続できる
支柱視点の建設モード	支柱を起点に周囲を見渡し、接続先を選択できる
ワイヤー	たるみのない直線として描画
ワイヤーへの乗車	ワイヤーを直接右クリックして滑走開始
途中乗車	ワイヤーの端だけでなく、途中からも乗れる
方向選択	プレイヤーが向いている方向へ進む
下り移動	傾斜に応じて加速する
上り・水平移動	Climber Driveを持っていれば可能
障害物との衝突	滑走中にブロックへ衝突すると離脱・落下
アニメーション・効果音	ぶら下がり姿勢や滑走音など
サバイバル対応	必要素材をクラフトして建設できる

Groundedそのものを再現するのではなく、Minecraftの操作やゲームシステムに合わせて調整しています。

追加した4種類のアイテム

今回のMODでは、ジップラインの建設と利用に必要な支柱ブロックと3種類のアイテムを追加しました。

① Zipline Anchor（ジップライン支柱）

ジップラインの始点・終点となる支柱です。

ワールド内に設置し、別の支柱とワイヤーで接続します。

1本の支柱から複数の支柱へ接続することもできるため、複数の拠点を結ぶジップライン網を作れます。

接続できる最大距離は64ブロックです。

② Zipline Connector（接続ツール）

支柱同士を接続するためのツールです。

支柱に向かって右クリックすると、支柱を起点とした建設モードに入ります。

建設モードでは、プレイヤー本体はその場に残り、視点だけが支柱へ移動します。

そこから周囲を見渡し、接続したい支柱を右クリックすることでワイヤーを張ることができます。

接続済みワイヤーの個別解除にも対応しています。

この仕組みは、通常のMinecraftのブロック設置とは違った操作感を目指して実装しました。

③ Zipline Wire（ジップラインワイヤー）

支柱同士を接続する際に消費する素材です。

サバイバルモードでは、支柱間の距離に応じた個数が必要になります。

必要数は次の式で計算します。

必要なZipline Wireの数 = ceil(支柱間の3次元距離 / 8)

例えば、25ブロック離れた支柱を接続するには4個必要です。

素材が足りない場合は接続できず、接続に失敗したときはアイテムを消費しません。

クリエイティブモードでは素材なしで接続できます。

④ Climber Drive（クライマードライブ）

上り方向や水平方向への移動を可能にする装置です。

Climber Driveを持っていない場合は、基本的に下り方向へ滑走します。

一方、Climber Driveを所持していれば、ワイヤーを上ることもできます。

装備スロットへ装着する必要はなく、手に持っている場合も、通常のインベントリに入れている場合も効果を発揮します。

サバイバルモードでも製作可能

これら4種類のアイテムには、Minecraftの既存素材を使用したクラフトレシピを追加しました。

アイテム	主に使用する素材
Zipline Anchor	鉄インゴット、チェーン、オークのフェンス
Zipline Connector	鉄インゴット、棒、レッドストーン
Zipline Wire	銅インゴット、糸
Climber Drive	鉄インゴット、銅インゴット、レッドストーン、ピストン、金インゴット

これにより、クリエイティブモードだけでなく、通常のサバイバルモードでもジップラインを建設して遊べるようにしました。

開発環境

今回使用した環境はこちらです。

項目	使用したもの
OS	macOS（Apple Silicon）
Minecraft	Java Edition 1.21.11
Java	Eclipse Temurin JDK 21
MODローダー	Fabric
Fabric Loader	0.19.5
Fabric Loom	1.14.10
Gradle	9.7.1
IDE	IntelliJ IDEA
AI（相談・設計・Codexへの指示文作成）	ChatGPT
AI（コード実装）	Codex CLI

最初はMinecraftのどのエディションで制作するか検討し、最終的にJava Edition向けのFabric MODとして制作することに決定しました。なお、開発にはApple Silicon搭載のMacを使用しています。

Fabricのテンプレートから開始

公式のFabric Template Mod Generatorでプロジェクトを生成しました。

• Mod Name：Trail Ziplines
• Mod ID：trailziplines
• Package：com.example.trailziplines
• Minecraft：1.21.11
• Language：Java
• Mappings：Mojang Mappings

最初の目標はシンプルで、「MODが読み込まれたMinecraftを起動すること」でした。

ChatGPTとCodex CLIの役割分担

今回の開発では、主に次の役割分担を採用しました。

ChatGPT：仕様の整理とCodexへの指示文作成

• 実装の優先順位を決める
• 仕様を文章に整理する
• Codexへ渡す指示文をすべて作成する
• エラーへの対応方法を検討する
• 動作確認項目を整理する

Codex CLI：実際のコードを書く

• 既存プロジェクトを調査する
• Javaのクラスを追加・修正する
• モデルやテクスチャなどのリソースを編集する
• 必要なテストを作る
• ビルドエラーを修正する

自分：作りたいものを伝え、Minecraftで動かして判断する

• 作りたい機能や操作のイメージをChatGPTに伝える
• ChatGPTが作成した指示文をCodexへ渡す
• ゲーム内で実際に操作する
• 想定した挙動になっているか確認する
• 不自然な操作や見た目を発見する
• 次に実装したい仕様を決める
• 修正後に再テストする

段階的に実装した16 STEP

最初から「Groundedのジップラインを全部作って」と依頼することはしませんでした。

代わりに、動作確認しやすい小さな段階へ分割しました。

STEP	実装した内容
1〜3	開発環境の構築、Fabric MODの起動
4	Zipline Anchorブロックの追加
5	支柱同士の接続と保存
6	下り方向の滑走
7	Climber Driveによる双方向移動
8	多対多接続への変更
9	ワイヤーの3D描画と選択
10	ワイヤー途中からの滑走
10.1	衝突落下と視線による方向選択
11	支柱視点の建設モード
12	Zipline Wireアイテムと距離別消費
13	傾斜による加速・減速
14	アニメーション・効果音・見た目
15	クラフトレシピとサバイバル対応
16〜16.1	操作性と描画の不具合修正

※STEP 10.1や16.1は、実装後に見つかった問題を修正するために追加した工程です。

特に最初は、支柱ブロックを1つ追加するところから始めました。
それが成功してから、接続、移動、描画へと進めています。
この進め方のおかげで、不具合が発生したときも、どの段階の変更が影響したのか考えやすくなりました。

実際にCodexへ渡した指示

今回の開発では、Codexに対して「ジップラインMODをすべて完成させてください」と一度に依頼したわけではありません。
機能ごとに要件と変更範囲を整理した指示文を、ChatGPTに作成してもらいました。

ここでは、開発終盤のSTEP 16で行った、アイテムを手に持ったままワイヤーに乗れるようにする修正を例に紹介します。

修正前の問題

STEP 16の修正前は、ジップラインへ乗るにはメインハンドを空にしてワイヤーを右クリックする必要がありました。
毎回素手へ切り替えて乗車するのは不便だったため、手に持っているアイテムに関係なく滑走できるようにしたいと考えました。

ChatGPTが作成した実際の指示文

以下は、当時ChatGPTが作成したSTEP 16用のCodex向けプロンプトからの原文抜粋です。

全文ではなく、今回の修正内容が分かる部分を掲載しています。

STEP 16で実際に渡した指示文を読む（原文抜粋）

# 修正②：アイテムを手に持った状態でもワイヤーに乗れるようにする

## 現在の問題

現在はメインハンドに何も持っていない状態でワイヤーを右クリックすると滑走できます。

しかし、アイテムを手に持っていると滑走できません。

Minecraft内で道具やブロックを持ち替えるたびに素手にする必要があり、不便です。

## 新しい仕様

ワイヤーを照準で選択している場合、メインハンドのアイテムに関係なく、右クリックで滑走できるようにしてください。

具体的には以下の状態すべてに対応してください。

- メインハンドが空
- ブロックを持っている
- ツルハシ、斧、シャベルなどの道具を持っている
- 剣などの武器を持っている
- Zipline Wireを持っている
- Zipline Connectorを持っている
- Climber Driveを持っている
- オフハンドにもアイテムがある

## 右クリック操作の優先順位

以下の優先順位を採用してください。

### 1. ワイヤーに照準が合っている場合

ワイヤーへの滑走操作を優先します。

手に持っているアイテムは消費しません。

ブロックを持っていた場合も、滑走開始と同時にブロックを誤設置しないようにしてください。

食べ物やその他の使用可能アイテムを持っている場合も、滑走操作で意図しないアイテム使用が起きないようにしてください。

### 2. Zipline Connectorで支柱を操作する場合

従来どおり、建設モードへ入ります。

この操作はワイヤー滑走に置き換えないでください。

建設モード中の右クリックは、接続確定・解除などの建設用操作として扱ってください。

### 3. ワイヤーや建設対象の支柱を選択していない場合

Minecraft本来の右クリック操作を維持してください。

実際の指示には、これに加えてClimber Driveの所持判定、サーバー側の検証、既存の滑走機能を維持する条件、テスト項目なども含めていました。

指示文の作り方で意識したこと

今回、自分がChatGPTに伝えたのは、主に「現在何が不便なのか」「どのような動作にしたいのか」という部分です。
ChatGPTはそれをもとに、Codexが作業しやすいよう、現在の問題、新しい仕様、既存機能への影響、確認事項などを整理した指示文を作成してくれました。
単に「アイテムを持っていても乗れるようにしてください」と依頼するのではなく、変更してはいけない動作や、確認すべき条件まで指示に含めていたことがポイントです。
このように、自分がすべての技術的な条件を考えて文章にする必要はなく、実現したい内容をChatGPTと相談しながらCodex向けの指示に落とし込むことができました。

仕様は開発途中で何度も変わった

作成開始時に仕様は固まっていなかったので、開発途中で何度も変更しました。

1. 支柱同士の接続を1対1から多対多へ

最初は、支柱Aと支柱Bを結ぶだけの仕組みでした。
しかし、それでは複数の場所を行き来するネットワークを作れません。

そこで、1つの支柱から複数の支柱へ接続できるように変更しました。
例えば、A-B、A-C、A-D、B-Dといった接続を同時に持てます。
接続を1本だけ解除する機能や、支柱破壊時に関連する接続だけを削除する機能も追加しました。
さらに、ワールドを終了しても接続情報が維持されるようにしています。

2. 支柱から乗るのではなく、ワイヤーをクリックして乗る

当初は支柱を右クリックすると滑走が始まる仕組みでした。
しかし、それだとワイヤーの途中から乗れません。
そこで、ワイヤーそのものに視線による選択判定を追加し、直接右クリックできるようにしました。
この実装では、見た目だけのワイヤーにクリック判定を持たせる必要がありました。

クライアント側で選択したワイヤーや位置を判定し、サーバー側でも接続・距離・遮蔽物などを確認する仕組みです。
結果として、ワイヤーの任意の位置から滑走できるようになりました。

3. 安全すぎて、なかなか乗れない問題

一度実装した滑走システムは、安全性を重視しすぎていました。

• 移動経路の途中に障害物がある
• 終点に安全な床がない
• 近くにブロックがある
• ワイヤーが急傾斜である

といった理由で、滑走を拒否する場面が多かったのです。

しかし、求めていた挙動は違いました。

ワイヤーが張られていれば乗れる。途中で障害物にぶつかったら、その地点で落下する。

というものです。

そこで、判定を次のように変更しました。

• 建設時：ワイヤーの中心線を障害物が遮っていないか確認する
• 乗車時：乗車位置にプレイヤーを配置できるか確認する
• 滑走中：実際に障害物へ衝突したら離脱する
• 離脱後：Minecraft本来の重力や落下ダメージを適用する

この変更によって、操作感が当初のイメージに近づきました。

見た目を作ると、また別の問題が出てくる

基本機能が完成してから、支柱やワイヤーの見た目、インベントリのアイテムアイコン、滑走中のぶら下がり姿勢、効果音などを追加しました。

しかし、ここでも問題がありました。
設置した支柱やワイヤーが、場面によってちらついて見えることがあったのです。
原因候補として、Z-fighting（重なった面の描画競合）やワイヤーの二重描画などを調査しました。

また、追加の動作確認では、手に持ったZipline Wireアイテム自体がちらつく現象も見つかりました。
このような問題は、コードがコンパイルできるかどうかだけでは判断できません。

実際にゲーム内でカメラを動かしたり、アイテムを持ち替えたりして、初めて気づくことがあります。最終的には、これらの描画上の問題も修正しました。

AIを使って開発してみて感じたこと

1. 実装を細かく区切ることが大切

今回、特に効果的だったと感じたのは、機能を細かいSTEPに分割して進めたことです。
最初から複雑なMODを完成させようとするよりも、
「まず支柱を置けるようにする」
「次は接続だけ作る」
「その次は滑走する」
という形で進めたことで、その都度成果を確認できました。

2. AIに任せる部分と、人間が判断する部分は違う

ChatGPTはCodexへ渡す指示文を作成し、Codexはコードの追加や修正を進めてくれました。
しかし、実際に遊んだときの違和感は、自分で操作しないと分からないことが多かったです。
「安全性を重視しすぎて乗れない」
「Shiftを押すより向いている方向へ進みたい」
「素手でしか乗れないのは不便」
といった変更は、実機で使ってみたからこそ出てきました。

3. 仕様変更を前提に設計した方がよい

今回、1対1接続を多対多へ変更したり、滑走開始操作を支柱からワイヤーへ変更したりしました。
あとから変更したくなることは十分にあります。
特に、データの保存方式や移動処理など、後続の機能が依存する部分は、最初から拡張を考えておくとよさそうです。

完成状況と今後の課題

Trail Ziplinesは、個人制作MODとしていったん完成としました。
現在は、ローカルの開発環境でMinecraftを起動し、主要機能の動作を確認できています。

一方で、今回の開発ではシングルプレイでの動作を中心に確認しており、MODとして幅広く配布するための検証や、ほかのMODとの組み合わせについては別途確認が必要です。

まとめ

MinecraftにGrounded風のジップラインを追加したい、という思いつきから始まった今回のMOD開発。

JavaやFabricの環境構築でつまずき、通信エラーに悩み、実装した機能が想定どおりに動かず、仕様を何度も変更しました。

それでも、ChatGPTに仕様の相談とCodexへの指示文作成を任せ、Codex CLIで実装し、Minecraftで実際に試すというサイクルを続けることで、最初に思い描いていた機能を形にできました。

今回学んだのは、AIがコードを書いてくれること以上に、人間が「何を作りたいか」「実際に使ってどう感じたか」を伝え続けることが大切だということです。

初めてのMOD開発でしたが、自分で考えた仕組みがMinecraftの世界で動いたときは、やはり楽しいものでした。

同じように「こんな機能をMinecraftに追加してみたい」と考えている方の参考になれば幸いです。

最後まで読んでいただき、ありがとうございました！