WorldX: 一文で生成するAI世界シミュレータの実装と導入判断

WorldXが埋めようとしている穴は何か

生成AIでゲーム世界を作る試みの多くは、静的なアセット生成で止まる。マップの絵は出るが、その上で誰が何をするかは人間が書く。WorldXはこの後半部分を引き受ける。READMEの主張は「一句话，生成一个鲜活的 AI 世界」であり、生成した地図とキャラクターの上でエージェントが意思決定し、関係を築き、会話し、記憶を積む。台本を書かずに物語が立ち上がることを狙っている。

対象は大きく二つに分かれる。一つは、LLMエージェントの創発的な振る舞いを観察したい研究者や開発者。もう一つは、生成AIを使ったシミュレーションの実装構造をコードとして読みたいエンジニアだ。前者にとっては「上帝模式」による介入、つまりイベントの注入やキャラクターの記憶・人格の編集が観察の道具になる。後者にとっては、4つのモデル役割をどう分離したかが読みどころになる。

商用ゲームエンジンとして見ると期待を裏切る。README自身がAlpha段階と明記しており、リリースは取得されていない。まず観察と実験の道具として捉えるのが正しい。

4つのモデル役割を分離した設計

WorldXの構成で最も特徴的なのは、モデルを一つに集約せず役割ごとに分けている点だ。READMEの表によれば、ORCHESTRATOR_が世界構造・キャラクター・ルールの設計、IMAGE_GEN_が地図美術とキャラクター立ち絵の生成、VISION_が地図品質の審査と領域・要素の位置特定、SIMULATION_が実行時のキャラクター行動の駆動を担う。

この分離はコスト構造に直結する。世界生成は一度きりだが、シミュレーションは時間の経過とともに何度も呼ばれる。READMEはSIMULATION_について「任意模型，便宜的就行」と述べ、例としてgemini-2.5-flashを挙げている。実際、混合構成の例ではORCHESTRATOR_とIMAGE_GEN_とVISION_にGoogle AI Studio、SIMULATION_にDeepSeekという組み合わせが示されている。高頻度呼び出しの部分だけ安いモデルに逃がす設計だ。

プロトコルはOpenAI互換のchat/completionsが基本で、IMAGE_GEN_のみIMAGE_GEN_PROVIDERでgoogle-nativeを選べる。つまり画像生成だけはOpenAI互換形式に縛られない。この非対称は、テキスト系と画像系でAPI仕様が異なる現状をそのまま反映している。

環境構築で最初に引っかかるNode.jsの版

WorldXはデータベースにNode.js組み込みのSQLite（node:sqlite）を使う。ネイティブモジュールのコンパイルが不要になる代わりに、Node.jsのバージョン制約が厳しくなる。READMEが示す完全な可用範囲は>=22.13 <23または>=23.4であり、22.5から22.12、および23.0から23.3は使えない。この期間はnode:sqliteが--experimental-sqliteフラグの背後にあったためだ。

推奨は24 LTSとされている。手元の環境が22.13未満なら、まずNode.jsを上げる作業から始まる。ここを飛ばしてnpm installに進んでも解決しない種類の制約である。

手順自体は短い。git cloneで取得し、cd WorldXの後、cp .env.example .envで設定ファイルを用意する。npm installを実行し、npm run devで起動するとhttp://localhost:3200が開く。READMEによれば、内蔵の2つの事前生成世界を使うだけならSIMULATION_の3行を埋めればよい。世界をゼロから作る場合は4組すべてのモデル設定が必要になり、http://localhost:3200/createに一文を入力する。コマンドラインからならnpm run create -- "赛博朋克风格的深夜拉面馆，黑客和仿生人在这里交换情报"のように渡す。

READMEには代理（プロキシ）の問題に関する記述が途切れた状態で含まれている。ネットワーク環境によっては追加の対処が要る可能性があるが、本文書からは詳細を確認できない。

画像生成モデルの選択が最終品質を決める

READMEで異例なのは、画像生成モデルについて具体的な推奨と警告を書いている点だ。nano banana2（gemini-3.1-flash-image）を推奨し、gpt-image-2については「指令遵循上依然有欠缺」と述べる。画風はnb2より好みであっても、本プロジェクトでは各種問題を引き起こし最終的な效果に影響しやすいという。

これは単なる好みの話ではない。WorldXでは地図を画像として生成し、その上にVISION_役割のモデルが領域や要素の位置を特定する。生成画像が指示に従わなければ、後段の位置特定が成立せず、シミュレーションの土台が崩れる。つまり画像生成モデルの指示追従性は、見た目の問題ではなくパイプラインの前提条件である。

この依存関係は、WorldXが画像生成の品質保証を自前で持たず、外部モデルの能力に委ねていることを意味する。VISION_による審査工程はその緩和策として読めるが、審査が通らない場合にどう再生成するかは、提供された資料からは確認できない。

記憶と人格、時間線という実行時の仕組み

READMEの特性リストによれば、キャラクターは過去の経験を記憶し、それに基づいて独自の行動パターンを形成する。昼夜サイクルをまたいだ複数日の進化にも対応し、同一世界から複数の時間線を生み出せる。

観察者としての関与も用意されている。イベントの放送、キャラクターの人格・記憶の編集、任意キャラクターとの架空対話ができる。これはシミュレーションを眺めるだけの玩具ではなく、条件を変えて結果を比べる実験装置として使えることを示す。時間線システムと組み合わせれば、同じ初期世界から分岐した系列を比較する使い方が想定できる。

ただし、これらが実際にどの程度安定して機能するかを示す情報は提供されていない。READMEはAlpha段階で「核心可用，持续优化中」と述べるにとどまる。記憶の保持期間、時間線間の分離の程度、多数エージェントを動かしたときの挙動は、自分で動かして確かめる以外にない。

向かないケースと代替の考え方

WorldXが向かないのは、決まった体験を確実に届けたい場合だ。LLMの出力は確率的で、同じ一文から同じ世界が再現される保証は資料からは読み取れない。テストの自動化や回帰検証を前提にした開発には組み込みにくい。

代替として、MinecraftのJava Editionのようにルールベースのシミュレーションを土台にし、LLMはテキスト生成だけに使う構成が考えられる。決定的な物理とワールド生成を持ち、エージェントの台詞や噂話だけをLLMに任せる形だ。WorldXは逆で、地図もキャラクターもエージェントの行動もLLMに委ねる。前者は挙動の予測可能性を、後者は予期しない物語の発生を優先している。どちらが優れているという話ではなく、何を欲しいかで選ぶ。

もう一つの代替は、シミュレーション部分を自作しWorldXのプロンプト設計だけを参考にする道だ。ORCHESTRATOR_とSIMULATION_の役割分離、VISION_による画像審査という構成は、他プロジェクトに流用できる考え方である。

ライセンスと保守の見通し

ライセンスはMITで、リポジトリのLICENSEファイルとバッジの両方で確認できる。MITは商用利用を含む幅広い利用を許すが、これは法的助言ではない。実際の利用条件は自分でLICENSE全文を確認すべきだ。

保守コストの観点で見えてくるのは、外部API依存の多さだ。4つのモデル役割それぞれにBASE_URL、API_KEY、MODELを設定するため、利用するプロバイダの仕様変更やモデル廃止が直接影響する。READMEの例に挙げられているモデル名にはpreview表記のものが複数含まれており、これらは予告なく差し替わりうる性質のものだ。

リリースは取得されておらず、バージョン番号による互換性の目安がない。アップグレード時はmainブランチの変更を直接追うことになる。フォークして自分の環境に固定する運用のほうが、継続的に追従するより現実的な場面もある。

導入前に確かめるべき3点

第一に、Node.jsのバージョン。node -vが>=22.13 <23または>=23.4のいずれかに該当するかを確認する。ここが合わなければ他の作業は無意味になる。

第二に、モデルの調達。内蔵世界を試すだけならSIMULATION_の3行で足りるが、自分の世界を作るなら4組すべてのキーが要る。混合構成の例のように、生成系と実行系でプロバイダを分けるとコストを抑えやすい。画像生成には指示追従性の高いモデルを選ぶ必要があり、READMEはnano banana2を推奨しgpt-image-2に警告を出している。

第三に、Alphaであることの受け入れ。READMEは核心部分は使えるとしつつ継続的に最適化中と述べる。生成した世界が期待通りにならない場合、原因がプロンプトかモデルかコードかを切り分ける作業が発生する。この手間を許容できるかどうかが、導入するかどうかの実質的な判断基準になる。

編集部の結論

WorldXは、LLMエージェントの創発行動を自分の目で観察したい開発者、または生成AIを使ったシミュレーションの構造をコードとして読みたい人に向く。逆に、安定したゲーム体験や本番サービスを求める用途には向かない。Alpha表記とリリース未取得という事実が示す通り、壊れることを前提に動かす姿勢が必要になる。導入前に確認すべきは、手元のNode.jsが22.13以上23未満、または23.4以上23.xのいずれかに該当するか、そして4つのモデル役割すべてにキーを用意できるかどうかだ。SIMULATION_のみで動く内蔵世界から試し、自分の世界生成に進む順序が現実的である。

公式情報源

1. Issues
2. License: MIT
3. README
4. YGYOOO/WorldX on GitHub